UTXO vs. Account vs. Object: 크로스 체인 아키텍처를 형성하는 숨겨진 전쟁
Ethereum 개발자들이 Sui에서 빌드하려고 할 때, 기묘한 일이 발생합니다. 기존의 사고 방식(Mental model)이 무너집니다. 변수는 컨트랙트에 저장되지 않습니다. 상태는 예상한 곳에 존재하지 않습니다. 자산은 다르게 이동합니다. 그리고 비트코인을 이더리움에, 혹은 이더리움을 Sui에 연결하려는 브릿지 엔지니어들은 프로토콜의 차이보다 더 깊은 문제에 직면하게 됩니다. 그들은 "트랜잭션"이 무엇인지에 대한 근본적으로 호환되지 않는 세 가지 이론을 조정해야 합니다.
이것은 단순한 구현 세부 사항이 아닙니다. UTXO, 계정(Account), 객체(Object) 트랜잭션 모델 중 무엇을 선택하느냐는 블록체인 설계에서 가장 중대한 아키텍처 결정 중 하나입니다. 이는 트랜잭션이 검증되는 방식, 병렬화가 작동하는 방식, 프라이버시가 달성되는 방식, 그리고 2026년 현재 가장 중요한 요소인 서로 다른 블록체인 네트워크 간의 상호 운용 방식 등 모든 것을 결정합니다.
세 가지 모델, 세 가지 철학
UTXO 모델: 현금과 같은 회계 방식
비트코인의 미사용 트랜잭션 출력값(UTXO, Unspent Transaction Output) 모델은 세 가지 모델 중 가장 오래되었으며 철학적으로 가장 순수합니다. 이 모델에는 전통적인 의미의 "계정"이 없습니다. 대신 이전 트랜잭션에 의해 생성되고 새로운 트랜잭션에 의해 소비되는 개별 가치 단위인 '출력값(Output)'이 존재합니다.
이를 실제 현금처럼 생각해보세요. 대금을 받을 때 여러분은 특정한 지폐를 보유하게 됩니다. 그 돈을 쓸 때, 해당 지폐는 파괴되고 새로운 지폐들이 생성됩니다. 하나는 수취인에게 가고, 하나는 잔돈으로 돌아옵니다. 각 지폐는 단 한 번만 사용할 수 있습니다. 장부는 잔액이 아니라 지폐의 흐름을 추적합니다.
이 설계는 심오한 함의를 가집니다:
파편화를 통한 프라이버시. 지갑이 잔돈 출력값이 발생할 때마다 새로운 주소를 생성하기 때문에, 트랜잭션을 단일 신원과 연결하는 것이 매우 어렵습니다. 각 UTXO는 독립적으로 주소 지정이 가능하므로, 추가적인 프라이버시 레이어 없이도 사용자에게 자연스러운 익명성을 제공합니다.
독립성을 통한 병 렬화. 입력을 공유하지 않는 UTXO들은 동시에 검증될 수 있습니다. 비트코인 네트워크는 보호해야 할 공유 상태(Shared state)가 없기 때문에 독립적인 트랜잭션을 병렬로 처리할 수 있습니다. 초당 약 7~15건의 트랜잭션을 처리하는 비트코인은 가장 빠른 체인은 아니지만, 이론적으로 이러한 트랜잭션들은 병렬 검증이 가능합니다.
결정론 및 감사 가능성. 제네시스 블록부터 전체 트랜잭션 내역을 검증할 수 있습니다. 숨겨진 상태 전이는 없으며, 모든 UTXO는 증명 가능한 소유권 체인을 가집니다.
트레이드오프는 무엇일까요? 스마트 컨트랙트의 표현력이 떨어집니다. UTXO 시스템은 가치 전달을 훌륭하게 모델링하지만, 복잡하고 상태가 유지되는 로직을 처리하는 데는 어려움을 겪습니다. 카르다노(Cardano)의 확장된 UTXO(eUTXO) 모델은 UTXO가 임의의 데이터를 가질 수 있도록 하여 이를 해결하려 하지만, 프로그래밍 패러다임은 여전히 이더리움의 방식과는 근본적으로 다릅니다.
계정 모델: 데이터베이스와 같은 상태 관리
이더리움의 계정(Account) 모델은 정반대의 접근 방식을 취합니다. 개별 코인을 추적하는 대신, 계정 잔액과 컨트랙트 저장소에 대한 글로벌 상태 데이터베이스를 유지합니다. ETH를 보낼 때 여러분의 계정 잔액은 감소하고 수취인의 잔액은 증가합니다. 이는 현금 교환이라기보다 은행 송금에 가깝습니다.
이 모델은 프로그래밍 가능한 돈(Programmable money)을 직관적으로 느끼게 만들었습니다. Solidity 개발자들은 코인의 계보가 아니라 변수와 함수의 관점에서 생각합니다. 계정 모델은 AMM, 대출 프로토콜, 스테이킹 컨트랙트 등 공유 상태를 읽고 쓰는 것이 자연스러운 계정 모델 덕분에 DeFi의 폭발적인 성장을 가능하게 했습니다.
하지만 계정 모델은 근본적인 병렬화 문제를 안고 있습니다. 여러 트랜잭션이 동시에 동일한 계정에 접근할 수 있기 때문에, 네트워크는 각 트랜잭션이 수정할 상태를 미리 알지 못하면 이를 안전하게 병렬로 실행할 수 없습니다. 이더리움이 베이스 레이어에서 초당 약 30건의 트랜잭션을 처리하는 이유는 원시 연산 능력의 한계 때문이 아니라, 정확성을 위해 아키텍처상 순차적인 상태 전이가 필요하기 때문입니다.
EVM의 접근 방식은 단순합니다. 블록에 나타나는 순서대로 트랜잭션을 순차적으로 실행하는 것입니다. 낙관적 병렬화(Optimistic parallelization) 시도(Monad와 같은 이더리움 L2)가 존재하지만, 이들은 실패한 트랜잭션을 재실행하여 충돌을 처리해야 하므로 이론적인 처리량 이득을 제한하는 오버헤드가 발생합니다.
프라이버시 불이익. 계정 주소는 영구적이며 완전히 추적 가능합니다. 동일한 주소에서 발생하는 모든 트랜잭션은 서로 연결됩니다. 이더리움에서의 프라이버시는 믹서(Mixer), ZK 증명, 스텔스 주소와 같은 추가적인 레이어가 필요합니다. 이는 계정 모델의 설계가 전체 트랜잭션 그래프를 노출하기 때문입니다.
객체 모델: 명시적 소유권, 명시적 의존성
Move 프로그래밍 언어를 기반으로 구축된 Sui의 객체(Object) 모델은 최신 패러다임을 대변합니다. 잔액이 있는 계정(계정 모델)이나 코인 계보(UTXO) 대신, Sui의 모든 것은 '객체'입니다. 즉, 고유하고 유형이 지정되었으며 소유권 체인이 명시된 소유 자원입니다.
코인도 객체입니다. NFT도 객체입니다. 스마트 컨트랙트 권한(Capabilities)도 객체입니다. 그리고 결정적으로, 모든 트랜잭션은 자신이 접근할 객체를 명시적으로 선언합니다. 여기에는 독점적 소유권이 필요한지 아니면 단순히 공유 접근 권한이 필요한지도 포함됩니다.
이러한 명시성은 계정 모델을 괴롭히는 병렬화 문제를 해결합니다. 트랜잭션이 의존성을 미리 선언하기 때문에, 검증자 네트워크는 어떤 트랜잭션이 독립적인지 즉시 파악하고 동시에 실행할 수 있습니다. 단일 소유자 객체와 관련된 트랜잭션은 합의 과정을 완전히 우회하여 초저지연(Ultra-low latency)을 달성할 수 있습니다. 공유 객체 트랜잭션은 합의를 거치지만 여전히 객체 수준의 격리 이점을 누립니다.
그 결과, Sui는 벤치마크에서 초당 297,000건의 트랜잭션을 목표로 합니다. 다만 실제 성능은 트랜잭션의 혼합 구성에 따라 크게 달라질 수 있습니다. 앱토스(Aptos)는 다른 접근 방식인 Block-STM(낙관적 병렬 실행 엔진)을 사용합니다. 이는 모든 트랜잭션을 추측적으로 병렬 실행하고 충돌을 롤백하는 방식으로 유사한 목표를 달성합니다. 2025년, 앱토스는 충돌이 없는 작업 부하에 서 100만 TPS에 근접하는 이론적 처리량을 입증했습니다.
객체 모델은 특정 패턴에 대한 결합성(Composability)도 개선합니다. 계정 모델에서 사용자 잔액을 보유하는 DeFi 프로토콜은 공유 상태 문제인 재진입 공격(Reentrancy attacks)을 신중하게 관리해야 합니다. 반면 객체 모델 프로토콜은 개별 자산을 소유하므로, 특정 공격 벡터가 구조적으로 불가능해집니다.
크로스 체인 변환 문제
여기서부터 엔지니어링이 정말 까다로워집니다. 사용자가 비트코인(Bitcoin), 이더리움(Ethereum), 그리고 수이(Sui) 사이에서 자산을 이동시키고자 할 때, 그들은 브릿지 인프라에 서로 호환되지 않는 세 가지 현실 사이의 통역을 요청하는 것과 같습니다.
| 속성 | UTXO (비트코인) | 어카운트 (이더리움) | 오브젝트 (Sui / Aptos) |
|---|---|---|---|
| 상태 단위 | 미사용 출력 (Unspent output) | 계정 잔액 (Account balance) | 소유된 오브젝트 (Owned object) |
| 식별자 | 출력 참조 (Output reference) | 주소 (Address) | 오브젝트 ID (Object ID) |
| 스마트 컨트랙트 | 제한적임 | 풍부함 | 풍부함 (Move) |
| 병렬화 | 자연스러움 | 어려움 | 설계 단계부터 반영됨 |
| 개인정보 보호 | 기본 제공 | 추가 요소 필요 | 오브젝트 수준 |
| 이중 지불 방지 | UTXO 유일성 | 논스(Nonce) 기반 | 오브젝트 소유권 |
UTXO-어카운트 격차는 가장 오래되고 잘 알려진 문제입니다. 비트코인을 이더리움으로 브릿징(래핑된 BTC)할 때, 여러분은 차용증(IOU)을 생성하는 것입니다. 브릿지는 비트코인 체인의 UTXO에 실제 BTC를 잠그고, 이더리움에서 그에 상응하는 ERC-20 토큰을 발행합니다. 이 과정에서 자산의 기술적 식별자가 완전히 바뀝니다. 비트코인의 UTXO 참조는 이더리움의 어카운트 모델에서 아무런 의미가 없으므로, 브릿지는 별도의 매핑 정보를 유지해야 합니다.
이러한 변환은 공격 표면(Attack surfaces)을 만들어냅니다. UTXO를 제어하는 브릿지의 비트코인 측 수탁(멀티시그 또는 스마트 컨트랙트)은 이더리움 측의 발행 로직과는 완전히 다른 전제 하에 작동합니다. 어느 한 레이어에서의 보안 실패는 연쇄적인 반응을 일으킬 수 있습니다. 2021년에서 2023년 사이 발생한 6억 달러 이상의 브릿지 탈취 사건들은 대부분 이러한 변환 레이어가 불완전하게 구현되어 발생한 결과였습니다.
어카운트-오브젝트 격차는 비교적 최근의 일이지만 마찬가지로 어렵습니다. 이더리움 자산이 Sui로 이동할 때, 이더리움 주소는 Sui 오브젝트와 깔끔하게 매핑되지 않습니다. Sui의 소유권 모델은 자산이 검증 가능한 오브젝트 참조를 가진 명시적이고 추적 가능한 소유자를 가질 것을 요구합니다. 브릿지는 어카운트 모델의 자격 증명으로부터 오브젝트 식별자를 합성해내야 하는데, 이는 신중한 프로토콜 설계가 필요한 손실이 발생하기 쉬운 변환 과정입니다.
레이어제로(LayerZero)의 메시징 아키텍처는 자산 수준이 아닌 메시지 수준에서 작동함으로써 이를 해결합니다. 울트라 라이트 노드(Ultra Light Nodes)는 체인 A의 트랜잭션 모델을 완전히 이해하지 않고도 "체인 A에서 무언가 발생했다"는 사실을 검증합니다. 레이어제로가 2025년에 카르다노(Cardano) 지원을 추가하여 160개 이상의 체인을 연결했을 때, 엔지니어링 팀은 다른 곳에서는 이더리움 네이티브 추상화를 유지하면서 카르다노 측의 eUTXO 시맨틱을 처리해야 했습니다.
UTXO-오브젝트 변환은 아마도 가장 복잡할 것입니다. 비트코인의 코인 계보(Lineage)와 Sui의 오브젝트 계보는 모두 명시적 소유권 모델이지만, 세부 사항이 너무 달라서 단순한 변환은 실패합니다. 비트코인의 UTXO는 전통적인 의미의 소유자 "식별자"가 없으며, 소유권은 암호화 서명을 통해 증명됩니다. 반면 Sui의 오브젝트는 명시적인 소유권 필드를 가집니다. 브릿지는 증명 기반 소유권과 필드 기반 소유권 사이를 변환하면서 양쪽 모두에 대한 감사 가능성(Auditability)을 유지해야 합니다.
합의 모델 상호작용
트랜잭션 모델의 선택은 합의 메커니즘 설계에도 영향을 미치며, 이러한 호환 불가능성을 증폭시킵니다.
비트코인의 UTXO 모델은 작업 증명(PoW) 합의와 자연스럽게 어우러집니다. 채굴자는 독립적인 UTXO가 나타나는 순서대로 검증하며, 체인의 표준 순서는 누적된 해시 파워에 의해 사후에 결정됩니다. 순차적 상태 머신을 위해 트랜잭션을 사전 정렬할 필요가 없습니다.
이더리움의 어카운트 모델은 상태 충돌을 방지하기 위해 검증자가 강제하는 멤풀(Mempool) 순서와 같은 미 리 정해진 트랜잭션 순서가 필요합니다. 이것이 이더리움의 MEV(최대 추출 가능 가치) 문제가 심각한 이유입니다. 트랜잭션 순서 자체가 경제적 가치를 지니며, 검증자는 자신들의 이익을 위해 트랜잭션을 재정렬하여 이를 추출할 수 있습니다.
Sui와 Aptos는 모두 오브젝트 기반 실행 모델과 함께 작동하도록 특별히 설계된 비잔틴 장애 허용(BFT) 합의 변형을 사용합니다. Sui의 단일 소유자 오브젝트 트랜잭션은 수백 밀리초 내의 지연 시간을 달성하는 간소화된 합의 경로(패스트패스 또는 직접 완결성)를 사용하며, 이는 중앙 집중식 결제 시스템과 경쟁할 수 있는 수준입니다. 공유 오브젝트 트랜잭션은 전체 BFT 합의를 사용하지만, 이 경우에도 오브젝트 수준의 격리 덕분에 상태 머신의 복잡성이 줄어듭니다.
브릿지가 이러한 서로 다른 합의 모델 전반에서 완결성(Finality)을 검증해야 할 때, 엔지니어링의 난이도는 배가 됩니다. 비트코인 UTXO 트랜잭션을 검증하는 ZK 브릿지는 해당 트랜잭션이 충분한 PoW 깊이를 가진 블록에 포함되었음을 증명해야 합니다. 이더리움 어카운트 상태 업데이트를 검증하는 동일한 브릿지는 상태 루트가 올바른 BFT 확정 블록과 일치함을 증명해야 합니다. 그리고 Sui 오브젝트 전이에 대한 검증은 Sui의 DAG 기반 미스티케티(Mysticeti) 합의에 대한 검증을 요구합니다. 이는 단일 보안 논증으로 결합되어야 하는 세 가지의 서로 다른 암호학적 검증 문제입니다.
2026년 개발자를 위한 시사점
2026년에 구축 환경을 선택하는 개발자들에게 트랜잭션 모델은 나중에 고려할 문제가 아니라 최우선 고려 사항이 되어야 합니다.
다음과 같은 경우 UTXO 체인 (비트코인, 카르다노)에서 구축하세요:
- 애플리케이션이 주로 최소한의 상태 전이를 가진 가치 전송인 경우
- 프라이버시가 최우선 요구 사항인 경우
- 장기적인 감사 가능성과 추적성이 필수적인 경우
- 비트코인의 작업 증명에 보안을 고정하는 레이어 2 솔루션을 구축하는 경우
다음과 같은 경우 어카운트 모델 체인 (이더리움, BNB 체인, 아발란체)에서 구축하세요:
- 애플리케이션에 복잡한 공유 상태(AMM, 대출 프로토콜, DAO)가 필요한 경우
- 개발자 생태계와 툴링의 깊이가 가장 중요한 경우
- 가장 광범위한 DeFi 결합성 표면이 필요한 경우
- 이더리움 프리미티브에 대한 기관의 친숙함이 요구 사항인 경우
다음과 같은 경우 오브젝트 모델 체인 (Sui, Aptos)에서 구축하세요:
- 트랜잭션 처리량과 지연 시간이 핵심 요구 사항인 경우
- 애플리케이션이 게임 아이템, NFT 작업 등 자연스럽게 독립적인 상태를 갖는 경우
- 명시적인 자산 소유권 흐름을 설계하는 경우
- 병렬화 이점을 세심한 데이터 모델 설계를 통해 활용할 수 있는 경우
2025년에서 2026년 사이의 트렌드는 개발자가 여러 체인에서 동시에 구축하는 방향으로 흐르고 있습니다. 이는 크로스 체인 변환 문제를 단순한 인프라의 관심사가 아닌 애플리케이션 아키텍처의 문제로 만듭니다. 체인 A에서 상태를 표현하는 방식이 체인 B에서 해당 상태가 표현되는 방식을 결정짓게 됩니다.
인프라에 미치는 영향
2026년의 크로스 체인 인프라는 빠르게 성숙하고 있지만, 근본적인 번역 문제는 해결된 것이 아니라 추상화되었습니다. LayerZero, Axelar, Hyperlane과 같은 프로토콜은 UTXO, 계정(Account) 및 객체(Object) 모델 전반에서 작동하는 메시징 레이어를 제공합니다. ZK-브릿지 기술은 각 체인의 트랜잭션 모델을 해석하기 위한 신뢰할 수 있는 중개자 없이도 크로스 체인 이벤트의 비신뢰 검증(trustless verification)을 가능하게 합니다.
하지만 추상화에는 비용이 따릅니다. 각 번역 레이어는 지연 시간, 보안 가정 및 잠재적 실패 지점을 추가합니다. 가장 깔끔한 애플리케이션은 크로스 체인 의존성을 최소화하도록 설계된 경우가 많습니다. 즉, 각 체인을 해당 트랜잭션 모델이 가장 잘 수행하는 용도로 사용하고, 꼭 필요한 경우에만 브릿지를 이용하는 방식입니다.
더 깊은 통찰은 "블록체인 상호 운용성"이 단일 엔지니어링 문제가 아니라는 점입니다. 이는 브릿지의 양측에 있는 트랜잭션 모델에 의해 형성되는 일련의 문제들입니다. UTXO-to-Account 브릿지는 Account-to-Object 브릿지와는 다른 과제에 직면합니다. 그리고 상호 운용성을 보편적으로 해결한다고 주장하는 모든 프로토콜은 이러한 구체적인 복잡성에 비추어 평가되어야 합니다.
2026년 가을, 서로 다른 워크로드를 위해 실행 환경을 분리하는 이기종 존(heterogeneous zone) 아키텍처를 갖춘 LayerZero의 Zero 네트워크가 출시됨에 따라, 우리는 단일 트랜잭션 모델이 승리하지 않는다는 사실을 실질적으로 인정하게 되었습니다. 미래는 각 접점에서 신중하게 설계된 다중 모델 상호 운용성에 있습니다.
BlockEden.xyz는 Sui, Aptos, Ethereum 및 40개 이상의 다른 블록체인 전반에서 엔터프라이즈급 RPC API를 제공합니다. 개발자가 트랜잭션 모델 번역보다 애플리케이션 로직에 집중할 수 있도록 크로스 체인의 복잡성을 추상화합니다. 모든 주요 트랜잭션 모델을 아우르도록 설계된 인프라 위에서 빌드하려면 API 마켓플레이스 탐색하기를 방문해 보세요.