솔라나(Solana)를 이해할 때 가장 먼저 알아야 할 개념 중 하나가 **계정 모델(Accounts Model)**입니다.
솔라나에서는 지갑부터 프로그램, 토큰 잔액, NFT 메타데이터, 애플리케이션의 상태 데이터까지 다양한 정보가 ‘계정(Account)’이라는 구조를 중심으로 관리됩니다.
이더리움 같은 다른 블록체인에서는 일반적으로 지갑과 스마트 컨트랙트를 서로 다른 유형으로 구분해서 생각합니다.
하지만 솔라나는 조금 다릅니다.
솔라나 블록체인에서는 지갑, 프로그램, 데이터가 모두 계정 구조를 기반으로 동작합니다.
이 구조를 이해하면 솔라나에서 왜 여러 개의 주소가 만들어지는지, SPL 토큰을 처음 받을 때 왜 소량의 SOL이 필요한지, PDA는 무엇인지 등을 훨씬 쉽게 이해할 수 있습니다.
솔라나에서 Account란 무엇인가?
솔라나에서는 거의 모든 것이 계정을 중심으로 구성됩니다.
사용자의 지갑도 계정이고, 프로그램과 프로그램이 사용하는 데이터 역시 계정 구조를 이용합니다.
토큰 잔액이나 NFT와 관련된 정보 역시 별도의 계정을 통해 관리됩니다.
각 계정에는 고유한 주소가 있습니다.
이 주소는 기본적으로 **32바이트 크기의 공개키(Public Key)**입니다.
계정 종류에 따라 사람이 가진 개인키를 통해 제어할 수도 있고 프로그램에 의해 관리될 수도 있습니다.
따라서 솔라나에서 계정은 단순히 ‘코인을 보관하는 지갑’만을 의미하지 않습니다.
블록체인 위에서 주소를 가지고 존재하는 데이터와 프로그램의 기본 단위라고 이해하는 편이 좋습니다.
솔라나 Account를 구성하는 주요 필드
솔라나의 각 계정에는 해당 계정이 무엇이고 어떻게 동작하는지를 나타내는 여러 정보가 포함됩니다.
| 필드 | 의미 |
|---|---|
| Public Key | 계정을 식별하는 주소 |
| Lamports | 계정이 보유한 SOL의 최소 단위 잔액 |
| Owner | 계정 데이터를 관리할 권한을 가진 프로그램 |
| Data | 계정이 저장하고 있는 데이터 |
| Executable | 실행 가능한 프로그램인지 나타내는 값 |
| Rent Epoch | 계정의 Rent 관련 상태와 연관된 필드 |
각각을 조금 더 자세히 살펴보겠습니다.
Public Key: 계정의 주소
Public Key는 해당 계정을 식별하는 고유 주소입니다.
쉽게 말하면 솔라나 블록체인에서 해당 계정이 어디에 존재하는지 찾아가기 위한 주소라고 생각할 수 있습니다.
사용자나 프로그램이 특정 계정을 찾고 상호작용할 때 이 주소를 사용합니다.
Lamports: SOL의 최소 단위
Lamport는 SOL을 표현하는 가장 작은 단위입니다.
1 SOL = 1,000,000,000 Lamports
즉 10억 Lamports가 1 SOL입니다.
솔라나 계정의 SOL 잔액은 내부적으로 Lamport 단위로 관리됩니다.
예를 들어 어떤 계정이 0.01 SOL을 보유하고 있다면 이를 Lamport로 표현하면 1,000만 Lamports입니다.
Owner: 계정을 관리하는 프로그램
Owner는 솔라나 계정 모델을 이해할 때 특히 중요한 개념입니다.
여기서 Owner는 일반적으로 우리가 생각하는 ‘이 지갑을 소유한 사람’이라는 뜻과 다릅니다.
솔라나 계정의 Owner 필드는 해당 계정의 데이터를 관리할 권한을 가진 **프로그램 ID(Program ID)**를 의미합니다.
따라서 블록 탐색기에서 Owner라는 항목을 봤을 때 이를 사람이나 지갑의 실제 소유자로 이해하면 혼동할 수 있습니다.
Data: 계정에 저장되는 실제 데이터
Data는 계정이 저장하고 있는 바이트 배열(Byte Array)입니다.
어떤 데이터가 저장되는지는 해당 계정을 사용하는 프로그램에 따라 달라집니다.
예를 들어 애플리케이션의 사용자 정보나 게임 기록, 토큰과 관련된 상태 정보 등이 계정 데이터에 저장될 수 있습니다.
Executable: 프로그램 실행 여부
Executable은 해당 계정이 실행 가능한 프로그램과 관련된 계정인지를 나타내는 값입니다.
실행 가능한 프로그램 코드와 관련된 계정은 이 값이 활성화됩니다.
반면 일반적인 데이터를 저장하는 계정은 실행 가능한 프로그램으로 취급되지 않습니다.
Rent Epoch
Rent Epoch는 과거 솔라나의 계정 Rent 구조와 관련된 필드입니다.
현재 신규 계정은 필요한 최소 잔액을 충족하는 Rent-exempt 상태로 생성되어야 하기 때문에 일반 사용자 입장에서는 예전보다 중요도가 낮아진 필드입니다.
Address·Balance·Owner·Data를 구분하면 이해가 쉬워진다
솔라나 계정을 이해하는 가장 간단한 방법은 각각의 역할을 구분하는 것입니다.
Address는 계정이 어디에 있는지를 나타냅니다.
Balance는 계정이 얼마나 많은 SOL을 가지고 있는지를 나타냅니다.
Owner는 어떤 프로그램이 해당 계정의 데이터를 관리하는지를 나타냅니다.
Data는 계정 안에 실제로 무엇이 저장되어 있는지를 나타냅니다.
Executable은 해당 계정이 실행 가능한 프로그램과 관련되어 있는지를 보여줍니다.
이 개념들을 이해하면 Solscan 같은 블록체인 탐색기에서 계정 정보를 확인하는 것도 훨씬 쉬워집니다.
솔라나의 Ownership은 어떻게 작동할까?
솔라나 프로토콜에서 계정의 Owner는 매우 중요한 역할을 합니다.
기본적인 원칙은 해당 계정을 소유한 프로그램만 계정 데이터를 변경하거나 정해진 규칙에 따라 Lamports를 감소시킬 수 있다는 것입니다.
다른 계정에서 Lamports를 보내는 것은 가능하지만 임의의 프로그램이 자신이 소유하지 않은 계정의 데이터를 마음대로 수정할 수는 없습니다.
솔라나 런타임이 이러한 규칙을 강제합니다.
일반 SOL 지갑을 예로 들어보자
일반적인 SOL 지갑 계정을 생각해 보겠습니다.
기본적인 지갑 계정은 System Program이 소유합니다.
사용자가 자신의 지갑에서 SOL을 보내려면 해당 지갑의 개인키로 트랜잭션에 서명합니다.
그러면 System Program이 관련 규칙에 따라 SOL 전송을 처리합니다.
여기서 중요한 것은 사용자의 개인키와 계정의 Owner 필드를 구분하는 것입니다.
사용자는 개인키를 통해 자신의 지갑에 대한 서명 권한을 가지고 있지만, 계정의 Owner 필드에는 System Program이 지정될 수 있습니다.
이러한 소유권 규칙 덕분에 관계없는 프로그램이 임의로 다른 계정의 데이터를 변경하는 것을 막을 수 있습니다.
솔라나 개발자에게 Account Ownership이 중요한 이유
솔라나에서 프로그램을 개발한다면 어떤 계정을 자신의 프로그램이 관리하고 어떤 계정은 단순히 읽거나 상호작용하는지를 명확하게 구분해야 합니다.
이 부분은 이더리움의 스마트 컨트랙트 구조와 차이가 있습니다.
이더리움에서는 일반적으로 컨트랙트의 코드와 상태를 하나의 컨트랙트 계정이라는 관점에서 이해할 수 있습니다.
반면 솔라나는 프로그램 코드와 상태 데이터를 분리해서 관리합니다.
| 구분 | Solana | Ethereum |
|---|---|---|
| 컨트랙트 상태 | 프로그램이 소유하는 별도 데이터 계정 | 컨트랙트 계정의 스토리지 |
| 코드와 데이터 | 분리 | 하나의 컨트랙트 계정 관점에서 관리 |
| 지갑과 프로그램 | 모두 Account 모델 기반 | 서로 다른 계정 유형으로 구분 |
따라서 솔라나 프로그램을 개발할 때는 프로그램 로직뿐만 아니라 어떤 계정을 읽고 어떤 계정을 변경할 수 있는지를 함께 설계해야 합니다.
Program Account와 Data Account의 차이
솔라나는 프로그램 코드와 프로그램이 사용하는 상태 데이터를 분리하는 구조를 사용합니다.
이를 이해하려면 Program Account와 Data Account의 차이를 알아두는 것이 좋습니다.
Program Account
Program Account는 실행 가능한 프로그램 코드와 관련된 계정입니다.
프로그램은 배포 이후 변경할 수 없도록 설정할 수도 있지만 업그레이드 가능한 형태로 운영되는 경우도 있습니다.
업그레이드 가능한 프로그램에서는 Upgrade Authority를 가진 주체가 이후 프로그램 코드를 변경할 수 있습니다.
이는 중요한 보안 요소입니다.
사용자 입장에서는 해당 프로그램의 Upgrade Authority를 누가 가지고 있는지에 따라 프로그램 운영자를 어느 정도 신뢰해야 하는 문제가 발생할 수 있기 때문입니다.
Data Account
Data Account는 애플리케이션이 실제로 사용하는 상태 정보를 저장합니다.
예를 들면 다음과 같습니다.
토큰 잔액, 사용자 프로필, 게임 점수, 애플리케이션 설정값 등입니다.
애플리케이션이 동작하는 과정에서 이러한 계정이 생성되고 데이터가 업데이트되며 필요가 없어지면 계정이 닫히기도 합니다.
솔라나가 병렬 처리를 할 수 있는 이유
코드와 상태 데이터를 분리하는 구조는 솔라나의 트랜잭션 처리 방식과도 연결됩니다.
솔라나 트랜잭션은 어떤 계정을 읽고 쓰는지가 명시됩니다.
따라서 런타임은 여러 트랜잭션이 서로 같은 계정에 동시에 접근하는지를 파악할 수 있습니다.
서로 충돌하지 않는 트랜잭션이라면 순서대로 하나씩 처리할 필요 없이 병렬로 실행할 수 있습니다.
이러한 계정 기반 구조는 솔라나가 높은 처리 성능을 구현하는 데 중요한 역할을 합니다.
PDA(Program Derived Address)란?
솔라나를 처음 공부할 때 많은 사람이 어려워하는 개념 중 하나가 **PDA(Program Derived Address)**입니다.
PDA의 가장 큰 특징은 일반적인 지갑 주소와 달리 대응되는 개인키가 존재하지 않는다는 것입니다.
PDA는 프로그램 ID와 하나 이상의 Seed 값을 이용해 결정적으로 생성되는 주소입니다.
따라서 사람이 개인키를 가지고 직접 해당 PDA에 서명하는 방식으로 동작하지 않습니다.
개인키가 없는데 PDA는 어떻게 사용할까?
프로그램은 PDA와 관련된 호출에서 invoke_signed와 같은 메커니즘을 이용해 해당 PDA가 서명한 것처럼 권한을 행사할 수 있습니다.
이를 통해 프로그램은 사람이 매번 개인키로 서명하지 않아도 자신이 관리하는 상태를 안전하게 제어할 수 있습니다.
그래서 많은 솔라나 온체인 애플리케이션이 PDA를 사용합니다.
예를 들어 탈중앙화 거래소(DEX)는 주문이나 시장 상태를 관리하기 위해 PDA를 활용할 수 있습니다.
NFT 마켓플레이스 역시 리스팅과 같은 데이터를 관리하는 데 PDA를 사용할 수 있습니다.
즉 PDA는 솔라나 프로그램이 자신의 상태와 권한을 관리하기 위한 핵심적인 주소 구조라고 이해하면 쉽습니다.
Solana Rent란 무엇인가?
솔라나 계정에는 데이터를 블록체인에 저장하기 위한 최소 SOL 잔액이 필요합니다.
계정이 저장하는 데이터가 많아질수록 필요한 최소 금액 역시 달라질 수 있습니다.
그 이유는 계정 데이터가 네트워크의 저장공간을 사용하기 때문입니다.
현재 신규 계정은 일반적으로 Rent-exempt가 되기 위한 최소 잔액을 확보한 상태로 생성되어야 합니다.
쉽게 말하면 계정을 만들 때 필요한 SOL을 미리 예치해 두는 방식입니다.
Rent는 수수료보다 보증금에 가깝다
Rent-exempt를 위해 넣어두는 SOL은 일반적인 트랜잭션 수수료와는 성격이 다릅니다.
계정을 유지하는 동안 일정 조건의 SOL이 계정에 남아 있어야 하지만 해당 계정을 정상적으로 닫으면 이 SOL을 회수할 수 있습니다.
따라서 사용자가 영구적으로 지불하고 사라지는 수수료라기보다 계정 저장공간을 확보하기 위한 예치금에 가깝게 이해할 수 있습니다.
개발자는 계정을 생성할 때 필요한 최소 잔액을 계산하고 해당 SOL을 함께 예치합니다.
이후 계정이 유지되는 동안 별도의 지속적인 Rent가 차감되는 방식은 아닙니다.
Rent-exempt 최소 잔액이 부족하면?
현재는 필요한 Rent-exempt 최소 잔액을 충족하지 못하면 신규 계정을 정상적으로 생성할 수 없습니다.
따라서 계정 생성 과정에서 필요한 SOL이 부족하면 트랜잭션이 실패할 수 있습니다.
또한 계정이 닫히면서 잔액이 정리되면 해당 계정이 사용하던 저장공간 역시 더 이상 유지되지 않습니다.
실제 사용 과정에서는 대부분의 지갑이나 개발 도구가 필요한 Rent-exempt 금액을 자동으로 계산해 처리하기 때문에 일반 사용자가 직접 신경 쓸 일은 많지 않습니다.
하지만 프로그램이 동적으로 많은 계정을 생성하는 서비스를 개발한다면 반드시 이해해야 하는 부분입니다.
일반 솔라나 사용자에게는 어떤 의미일까?
직접 솔라나 프로그램을 개발하지 않는 일반 사용자라면 대부분의 Account Model 구조는 지갑과 애플리케이션이 알아서 처리합니다.
그래도 몇 가지 개념을 알아두면 도움이 됩니다.
가장 중요한 것은 지갑에 표시되는 모든 자산이 하나의 계정 안에 단순히 숫자로 들어 있는 것은 아니라는 점입니다.
SOL을 보유하는 기본 지갑 주소와 SPL 토큰 잔액을 기록하는 계정 등이 별도로 존재할 수 있습니다.
따라서 새로운 SPL 토큰을 처음 보유하는 과정에서 별도의 토큰 계정이 생성될 수 있습니다.
SPL 토큰을 처음 받을 때 SOL이 필요한 이유
새로운 SPL 토큰을 보유하기 위한 토큰 계정이 생성되면 해당 계정을 Rent-exempt 상태로 만들기 위한 SOL이 필요합니다.
원문에서는 일반적인 토큰 계정을 생성하는 데 필요한 Rent-exempt 예치금을 약 0.002 SOL로 설명하고 있습니다.
따라서 사용자는 토큰을 전송하거나 처음 받는 과정에서 예상하지 못했던 소량의 SOL이 필요하다는 사실을 발견할 수 있습니다.
이는 단순히 토큰을 전송하는 네트워크 수수료뿐만 아니라 새로운 계정을 생성하기 위한 최소 잔액이 필요하기 때문일 수 있습니다.
사용하지 않는 토큰 계정을 닫으면 SOL을 돌려받을 수 있다
사용하지 않는 토큰 계정을 닫으면 해당 계정에 Rent-exempt 목적으로 예치되어 있던 SOL을 회수할 수 있습니다.
솔라나 생태계에 사용하지 않는 토큰 계정을 정리하는 도구들이 존재하는 이유도 여기에 있습니다.
여러 SPL 토큰을 거래하거나 에어드롭 등을 받아왔다면 사용하지 않는 토큰 계정이 남아 있을 수 있습니다.
이러한 계정을 정리하면 일부 SOL을 돌려받을 수 있습니다.
다만 계정을 닫기 전에는 토큰 잔액이 0인지, 실제로 더 이상 사용하지 않는 계정인지 반드시 확인해야 합니다.
지갑에서 계정 상세정보를 확인한 뒤 정리하는 것이 안전합니다.
솔라나 Account Model을 이해해야 하는 이유
솔라나의 Account Model은 단순한 기술적 세부사항이 아닙니다.
솔라나 블록체인의 기본 설계가 이 구조 위에 만들어져 있습니다.
Account Model을 이해하면 솔라나의 여러 특징이 자연스럽게 연결됩니다.
코드와 데이터가 분리되어 있는 이유, Owner가 계정 변경 권한을 결정하는 방식, PDA를 이용해 프로그램이 자체 상태를 관리하는 구조, SPL 토큰을 처음 받을 때 SOL이 필요한 이유 등을 이해할 수 있습니다.
개발자에게 Account Model은 선택적으로 공부할 수 있는 개념이 아닙니다.
솔라나 프로그램을 설계할 때 어떤 계정을 읽고 쓰며 어떤 프로그램이 해당 계정을 소유하는지를 결정해야 하기 때문입니다.
일반 사용자에게도 Account Model을 이해하면 지갑을 사용하면서 나타나는 여러 현상을 쉽게 이해할 수 있습니다.
왜 새로운 토큰을 받을 때 소량의 SOL이 필요한지, 왜 하나의 지갑을 사용하고 있는데 블록체인 탐색기에서는 여러 주소와 계정이 나타나는지 등을 이해하는 데 도움이 됩니다.
결론
솔라나의 Account Model은 솔라나 블록체인의 핵심 구조입니다.
솔라나에서는 사용자 지갑부터 프로그램과 애플리케이션 데이터까지 계정이라는 공통된 구조를 중심으로 관리됩니다.
각 계정에는 주소와 Lamports 잔액, Owner, Data, Executable 등의 정보가 있으며 특히 Owner는 어떤 프로그램이 해당 계정의 데이터를 관리할 수 있는지를 결정하는 핵심 요소입니다.
솔라나는 프로그램 코드와 상태 데이터를 분리하고, 트랜잭션이 접근할 계정을 미리 파악할 수 있도록 설계돼 있습니다. 이러한 구조는 서로 충돌하지 않는 트랜잭션을 병렬로 처리할 수 있는 기반이 됩니다.
PDA 역시 솔라나를 이해할 때 빼놓을 수 없습니다.
PDA에는 일반적인 개인키가 존재하지 않지만 프로그램이 정해진 방식으로 해당 주소에 대한 권한을 행사할 수 있기 때문에 다양한 탈중앙화 애플리케이션의 상태 관리에 활용됩니다.
마지막으로 Rent-exempt 구조를 이해하면 새로운 토큰 계정을 만들 때 왜 SOL이 필요하고, 사용하지 않는 토큰 계정을 닫았을 때 왜 일부 SOL을 돌려받을 수 있는지도 이해할 수 있습니다.
결국 솔라나를 제대로 이해하기 위한 출발점은 단순합니다.
솔라나에서는 프로그램과 데이터, 자산 상태가 모두 ‘계정(Account)’을 중심으로 연결되어 있다는 것입니다.
