[Xangle RWA Series] 지갑 인프라

1. 들어가며

2. 사용자 지갑 분류

3. 기업형 지갑 분류

4. 주요 지갑 인프라 벤더

5. RWA 지갑 벤더 비교

6. 결론

 

1. 들어가며

전편에서는 디지털자산을 누가 보관하고, 자산 이전에 필요한 키와 승인 권한을 어떻게 통제하는지를 다뤘다. 그러나 안전한 커스터디와 KMS를 마련하는 것만으로 투자자가 상품을 이용하고 기업이 온체인 업무를 수행할 수 있는 것은 아니다. 사용자는 자산에 접근하고 거래를 승인할 수단이 필요하고, 기업은 고객자산과 자체 자산을 목적에 맞게 나눠 운영해야 한다. 이 기반을 실제 서비스와 업무로 연결하는 접점이 지갑이다.

지갑이라는 이름 때문에 토큰이 지갑 애플리케이션 안에 들어 있다고 생각하기 쉽다. 그러나 실제 토큰은 지갑이 아니라 블록체인에 기록된다. 지갑은 사용자가 자신의 블록체인 계정에 접근해 잔고를 확인하고 거래를 승인할 수 있도록 돕는 도구다. 은행 앱에 돈 자체가 들어 있는 것이 아니라 계좌 정보를 앱으로 확인하는 것과 비슷하다. 다만 블록체인에서는 암호화 키로 거래를 승인하며, 이 키를 사용자가 직접 관리할 수도 있고 플랫폼이나 외부 수탁기관이 대신 관리할 수도 있다.

같은 RWA 상품이라도 투자자가 지갑을 사용하는 방식은 크게 다를 수 있다. Ondo의 OUSG는 온보딩을 마친 투자자가 자신의 외부 지갑을 연결하고 자산을 매수하는 구조를 사용한다. 반면 Franklin Templeton의 Benji에서는 투자자가 지갑을 따로 준비하지 않는다. 개인은 Benji Investments 앱으로, 기관은 Benji 기관용 웹 포털로 가입하며, 플랫폼이 투자자용 지갑까지 함께 제공한다. 투자자는 앱 안에서 지분을 보유하고 매수와 환매를 요청하며, 본인확인을 거쳐 화이트리스트에 등록된 주소로만 토큰을 주고받을 수 있다.

기업 관점에서도 지갑을 하나로 통합해 운영하기는 어렵다. 먼저 고객을 대신해 관리하는 자산은 기업 고유자산과 구분돼야 하며, 고객별 권리와 반환 수량을 확인할 수 있어야 한다. 기업이 직접 보유한 자산에서는 키를 회사가 직접 통제할지, 외부 수탁기관에 맡길지가 갈린다. 직접 통제하면 거래 속도와 자동화 범위를 회사가 정할 수 있지만 키관리와 내부통제 부담을 스스로 져야 하고, 외부에 맡기면 보관 책임을 전문기관에 넘기는 대신 출금 절차와 지원 자산 범위가 수탁기관의 정책을 따른다. 여기에 토큰 발행 / 동결이나 컨트랙트 변경처럼 상품 전체에 영향을 미치는 권한은 일반 송금과 같은 지갑에 두기 어렵다.

이에 따라 이 글은 지갑을 사용자와 기업이라는 두 관점에서 나눠 다룬다. 두 관점을 따라가면 반복해서 확인되는 사실이 하나 있다. 화면에 보이는 지갑 유형은 실제로 누가 자산을 통제하는지를 알려주지 않으며, RWA에 필요한 기능 상당수는 애초에 지갑 바깥에 남는다는 점이다. 지갑 인프라를 고르는 일과 규제 요건을 충족하는 상품 구조를 만드는 일은 그래서 서로 다른 과제다. 이 글의 목적은 그 경계가 어디에 그어지는지를 확인하는 데 있다.

먼저 사용자 지갑(Customer Wallet)을 지갑을 누가 제공하는지에 따라 외부지갑 연결형과 서비스 내 지갑 제공형으로 나누고, 서비스가 제공하는 지갑은 다시 서명 권한을 누가 통제하는지에 따라 사용자 통제형과 사업자 통제형으로 구분한다. 이어 기업형 지갑(Enterprise Wallet)을 자산의 귀속에 따라 고객자산 서비스 지갑과 기업자산 운영 지갑으로 나누고, 기업자산 운영 지갑은 키 통제의 위치에 따라 외부수탁형(Third-party Custody)과 직접수탁형(Self-custody)으로 구분한다. 두 분류는 상호 배타적인 지갑 유형이 아니라 사용자에게 보이는 접근 방식과 기업 내부의 운영 구조라는 서로 다른 계층을 설명한다.

그다음 각 영역의 대표 인프라를 소개한다. 사용자 지갑 인프라로는 Kresus, Privy, Dynamic을, 기업형 지갑 인프라로는 Anchorage Digital, BitGo, Fireblocks를 다룬다. 마지막으로 보안 / 규제, 지원 네트워크 / 자산, 토큰 / RWA 기능, 제품 제공 방식이라는 네 가지 기준으로 두 영역의 벤더를 각각 비교한다.

 

2. 사용자 지갑 분류

사용자가 RWA 서비스를 이용하기 위해 반드시 별도의 블록체인 지갑을 먼저 준비해야 하는 것은 아니다. 기존에 사용하던 지갑을 플랫폼에 연결할 수도 있지만, 회원가입 과정에서 서비스가 지갑이나 지갑 계정을 제공할 수도 있다.

따라서 사용자 지갑은 먼저 지갑을 누가 마련하는가를 기준으로 외부지갑 연결형과 서비스 내 지갑 제공형으로 구분할 수 있다. 외부지갑 연결형에서는 사용자가 서비스 밖에서 마련한 기존 지갑을 연결한다. 서비스 내 지갑 제공형에서는 사용자가 별도의 외부 지갑을 준비하지 않고, 서비스가 앱 안에서 이용할 지갑 환경을 제공한다. 서비스 내 지갑 제공형은 다시 지갑의 서명 권한을 누가 통제하는가에 따라 사용자 통제형과 사업자 통제형으로 나뉜다.

이 장에서 말하는 통제는 거래를 승인하고 실행할 수 있는 기술적 권한이 누구에게 있는지를 뜻한다. 고객자산을 법적으로 맡아 관리할 수 있는 지위, 즉 수탁의 문제는 자산의 귀속과 함께 3장에서 다룬다. 사업자가 사용자를 대신해 서명한다는 사실만으로 그 사업자가 수탁 인가를 갖췄다고 볼 수는 없으며, 그 반대도 마찬가지다.

2-1. 외부지갑 연결형

외부지갑 연결형은 사용자가 이미 보유한 블록체인 지갑을 RWA 서비스에 연결하는 방식이다. 개인이 MetaMask와 같은 지갑을 사용하는 경우에는 서비스 화면에서 연결 요청을 보내고, 사용자가 자신의 지갑에서 이를 승인한다. 이후 매수나 이전에 필요한 거래 요청도 연결된 지갑으로 전달된다. 앞서 언급한 Ondo의 OUSG가 이 방식을 사용한다. 온보딩을 마친 투자자가 자신의 지갑을 연결해 승인 주소로 등록하면, 이후 매수와 이전은 그 주소를 통해 이뤄진다.

여러 외부 지갑을 하나의 서비스에 연결하려면 지갑마다 다른 연결 방식을 서비스가 일일이 구현하지 않아도 되는 공통 규격이 필요하다. WalletConnect처럼 서비스와 외부 지갑 사이에 연결 세션을 만들고 서명이나 거래 요청을 사용자의 지갑으로 전달하는 표준이 널리 쓰이며, 이러한 연결 기능을 SDK 형태로 묶어 제공하는 지갑 인프라도 있다. 어느 쪽이든 서비스 사업자는 특정 지갑 하나에만 맞춰 연결 기능을 구축하지 않고 여러 지갑을 함께 지원할 수 있다.

외부지갑 연결형의 핵심은 누가 키를 관리하는지가 아니라 사용자가 서비스 밖에서 마련한 지갑을 가져온다는 점이다. 사용자가 직접 관리하는 MetaMask일 수도 있고, 기관이 운영하는 기업형 지갑이나 외부 수탁기관이 관리하는 지갑일 수도 있다. 개인 지갑에서는 사용자가 직접 서명하지만, 기관용이나 수탁 지갑에서는 조직 내부의 승인 절차 또는 수탁기관을 거쳐 거래가 실행될 수 있다.

이 방식에서는 하나의 지갑을 여러 온체인 서비스에서 계속 이용할 수 있다. RWA 상품이 외부 이전이나 온체인 활용을 허용한다면, 투자자는 보유한 토큰을 승인된 다른 주소로 옮기거나 다른 서비스와 연계할 수 있다. 이미 기관용 지갑 체계를 구축한 기업도 새로운 상품을 이용할 때마다 별도의 지갑을 만들 필요가 없다.

반면 서비스 가입 전에 지갑을 준비해야 한다는 진입장벽이 생긴다. 개인 사용자는 지갑 설치와 키 보관, 네트워크 선택, 거래 서명 방식에 익숙해야 한다. 거래 수수료를 직접 준비해야 하는 경우도 있으며, 잘못된 거래에 서명하거나 지갑 접근 권한을 잃으면 일반 금융 서비스처럼 비밀번호만 재설정해 해결하기 어렵다.

투자자 자격이나 이전 대상을 제한하는 규제형 RWA에서는 지갑 주소와 투자자 신원을 연결하는 절차도 필요하다. 사용자가 본인 확인을 마쳤더라도 플랫폼에 등록되지 않은 새 주소가 자동으로 승인되는 것은 아니다. 상품 조건에 따라 새로운 주소를 다시 등록해야 하고, 상대방 주소가 해당 상품을 보유할 자격이 없다면 거래가 서명됐더라도 이전이 거절될 수 있다.

2-2. 서비스 내 지갑 제공형

서비스 내 지갑 제공형은 사용자가 외부에서 지갑을 준비하는 대신, 서비스가 회원가입이나 온보딩 과정에서 지갑 또는 지갑 계정을 제공하는 방식이다. 사용자는 별도의 지갑 애플리케이션을 설치하지 않고 이메일이나 소셜 계정처럼 익숙한 방법으로 로그인해 자산을 확인하고 거래할 수 있다.

이 과정에서 서비스 가입과 지갑 생성이 하나의 과정으로 이어진다. 플랫폼은 본인확인을 마친 사용자에게 지갑을 제공하고 동시에 해당 주소를 승인된 투자자 주소로 등록할 수 있다. 사용자가 잘못된 네트워크의 지갑을 연결하거나 주소를 잘못 입력하는 문제도 줄일 수 있다.

지갑과 거래 과정도 서비스 화면 안에 포함할 수 있다. 여러 단계의 거래를 하나로 묶거나 네트워크 수수료를 서비스가 대신 부담하면, 사용자는 블록체인을 거의 의식하지 않고 RWA 상품을 이용할 수 있다. 기존 금융 앱에 익숙한 고객을 온보딩하기에 유리한 이유다.

다만 서비스가 지갑을 제공한다는 사실만으로 자산의 통제 주체가 정해지는 것은 아니다. 사용자가 거래를 최종 승인하도록 만들 수도 있고, 사업자나 외부 수탁기관이 사용자를 대신해 거래를 실행하도록 구성할 수도 있다. 서비스 내 지갑 제공형은 이에 따라 사용자 통제형과 사업자 통제형으로 나뉜다.

(1) 사용자 통제형

사용자 통제형은 서비스가 지갑을 만들어주지만, 자산을 움직이는 최종 권한은 사용자에게 남는 방식이다. 사용자는 서비스 안에서 거래를 직접 승인하며, 플랫폼은 사용자의 허용 없이 임의로 자산을 이전할 수 없다.

사용자가 통제권을 갖는다고 해서 모든 거래를 매번 직접 처리해야 하는 것은 아니다. 정기 매수나 반복적인 자산 운용처럼 사용자가 미리 정한 범위에서는 플랫폼이 일부 거래를 대신 실행하도록 권한을 위임할 수 있다. 다만 플랫폼이 행사할 수 있는 권한은 사용자가 지정한 자산과 금액, 기간, 거래 대상 안으로 제한되며, 사용자가 이를 변경하거나 회수할 수 있어야 한다. 위임 범위가 지나치게 넓거나 사용자가 권한을 회수할 수 없다면 이름만 사용자 통제형일 뿐 실질은 사업자 통제형에 가까워진다.

사용자 통제형은 외부지갑 연결형보다 가입 절차가 간단하면서도 사용자의 자산 통제권을 유지할 수 있다는 장점이 있다. 사용자는 별도의 지갑 애플리케이션을 설치하거나 시드 문구를 입력하지 않고 서비스에 가입할 수 있으며, 서비스는 본인확인과 지갑 생성, 승인 주소 등록을 하나의 흐름으로 구성할 수 있다.

대신 사업자는 사용자가 허용한 범위를 넘어서는 거래를 임의로 실행할 수 없다. 사용자가 위임을 철회하거나 지갑 접근 수단을 잃으면 정기 거래나 환매, 자산 이전과 같은 업무가 중단될 수 있으며, 상속과 분쟁, 법적 명령처럼 사용자의 즉각적인 승인을 기대하기 어려운 상황에도 사업자가 단독으로 대응하기 어렵다. 사용자가 지갑을 외부로 내보낼 수 있다면 서비스 밖에서 직접 거래할 수도 있어, 모든 활동을 플랫폼의 승인 절차 안에서 관리하기도 어렵다.

(2) 사업자 통제형

사업자 통제형은 서비스가 지갑이나 지갑 계정을 제공하고, 사업자 또는 그가 지정한 외부 수탁기관이 실제 서명 권한을 관리하는 방식이다. 사용자는 일반 금융 서비스처럼 플랫폼 계정에 로그인해 매수와 이전, 환매를 요청하고, 지갑을 통제하는 주체가 내부 정책에 따라 블록체인 거래를 실행한다.

이 구조에서는 사용자가 키를 직접 보관하거나 거래마다 서명할 필요가 없다. 하지만 더 중요한 차이는 사업자나 수탁기관이 고객 계정의 운영 주체로서 거래 실행과 예외 처리를 책임질 수 있다는 점이다. 사용자가 매수나 환매를 요청하면 사업자가 정해진 절차에 따라 거래를 완료하고, 로그인 수단을 잃은 경우에도 본인확인을 거쳐 계정 접근을 복구할 수 있다. 상속과 분쟁, 법적 동결처럼 사용자의 직접 서명을 받기 어려운 상황에도 미리 정해진 절차에 따라 대응할 수 있다.

그 대신 사용자는 자산을 움직일 때 사업자나 수탁기관의 절차에 의존한다. 외부 지갑으로 자산을 이전할 수 있는지, 출금 승인이 얼마나 걸리는지, 서비스가 중단되거나 사업자가 지급불능 상태에 빠질 경우 자산을 어떤 절차로 반환받을 수 있는지가 중요해진다. 사용자별 블록체인 주소가 존재하더라도 사용자가 서명 권한을 갖지 않는다면 플랫폼 밖에서 독자적으로 거래할 수 없다.

그러나 사용자에게 보이는 지갑 유형만으로 기업이 고객자산을 실제로 어떻게 관리하는지까지 알 수는 없다. 외부지갑 연결형에서도 연결된 지갑을 외부 수탁기관이 관리할 수 있고, 사업자 통제형에서도 사용자마다 별도 주소를 만들거나 여러 고객의 자산을 하나의 지갑에 모아 내부 장부로 구분할 수 있다. 특히 사업자 통제형에서 서명 권한을 사업자가 직접 쥐는지 외부 수탁기관에 맡기는지는 사용자 화면에 드러나지 않는다. 다음 장에서는 고객자산과 기업자산을 누가 통제하고 어떤 구조로 운영하는지를 기업의 관점에서 짚는다.

 

3. 기업형 지갑 분류

사용자 지갑이 고객이 어떤 방식으로 서비스에 접근하는지를 보여준다면, 기업형 지갑은 그 뒤에서 기업이 자산을 어떤 구조로 운영하는지를 보여준다. 이때 고객에게 귀속되는 자산과 기업이 자체적으로 보유하는 자산은 구분해서 봐야 한다. 두 자산은 관리 목적뿐 아니라 지갑 구조를 결정하는 출발점도 다르기 때문이다.

따라서 기업형 지갑은 자산의 귀속에 따라 고객자산 서비스 지갑과 기업자산 운영 지갑으로 나눌 수 있다. 고객자산 서비스 지갑에서는 누구의 자산인지 명확히 구분하고 돌려줄 수 있는지가 핵심이고, 기업자산 운영 지갑에서는 그 자산의 키를 회사가 직접 쥘지 외부 수탁기관에 맡길지가 갈린다.

이 가운데 고객자산 서비스 지갑은 누가 고객을 대신해 자산 이전 권한을 통제하는지에서 출발한다. 사업자가 고객자산을 직접 통제한다면 수탁 인가나 기관 지위가 문제가 되고, 외부 수탁기관이 통제한다면 해당 기관과 사업자의 역할과 책임을 구분해야 한다. 이러한 수탁 지위와 키관리, 고객별 분리와 옴니버스 구조는 전편에서 자세히 다뤘다. 이번 글에서는 해당 내용을 반복하기보다, 고객자산의 수탁 구조가 지갑 인프라와 어떻게 연결되는지만 간략히 짚는다.

이 분류는 앞에서 다룬 사용자 지갑 유형과 별개의 기준이다. 고객이 외부 지갑을 연결하는 서비스에서도 기업은 수수료와 정산을 처리할 자체 지갑이 필요할 수 있다. 반대로 고객에게 사업자 통제형 지갑을 제공하는 서비스라면 고객자산 서비스 지갑과 기업자산 운영 지갑을 모두 운영해야 한다.

3-1. 고객자산 서비스 지갑

고객자산 서비스 지갑은 기업이 고객을 대신해 자산을 보관하거나 거래를 처리하기 위해 운영하는 지갑이다. 사용자가 사업자 통제형 지갑을 이용하거나 플랫폼 계정으로 자산을 매수하면, 실제 토큰은 이 지갑 구조 안에서 관리될 수 있다.

고객자산은 고객마다 별도 지갑을 배정해 보관할 수도 있고, 여러 고객의 자산을 하나의 지갑에 모은 뒤 내부 장부로 고객별 잔고를 구분할 수도 있다. 전자는 온체인에서도 고객별 자산을 식별하기 쉽지만 운영해야 할 주소가 많아진다. 후자는 자금 이동과 수수료를 효율적으로 관리할 수 있지만, 내부 장부의 고객별 잔고와 실제 온체인 잔고가 항상 일치하도록 대사해야 한다.

어떤 구조를 선택하더라도 고객자산은 기업자산과 구분되어야 한다. 시스템 화면에서 계정을 나누는 데 그치지 않고, 실제 지갑과 장부에서도 자산의 귀속을 확인할 수 있어야 한다. 서비스 장애나 사업 중단이 발생하더라도 고객별 보유 수량을 확인하고 다른 지갑이나 수탁기관으로 이전할 수 있는 절차도 필요하다.

특히 지갑 인프라 벤더를 이용하는 경우에는 벤더가 실제 자산을 수탁하는지, 지갑 생성과 거래 서명 기술만 제공하는지를 구분해야 한다. 기술 벤더가 고객별 지갑과 내부 장부를 제공하더라도 고객자산의 법적 분리와 반환 책임은 서비스를 운영하는 사업자와 실제 수탁기관의 계약 구조에 따라 달라진다.

이 구분은 자금이 잠시 머무르는 경우에도 유지된다. 청약대금이나 환매대금처럼 기업의 정산 흐름을 거치는 자금이라도 고객에게 귀속되는 자산이라면 기업자산이 아니라 이 장의 대상으로 봐야 한다. 결제 기능을 어느 지갑이 수행하는지와 자산이 법적으로 누구의 것인지는 서로 다른 문제다.

3-2. 기업자산 운영 지갑

기업자산 운영 지갑은 회사가 직접 소유하고 업무에 사용하는 디지털자산을 관리한다. 회사가 보유한 스테이블코인과 가상자산, 운영 예비자금, 네트워크 수수료용 자산 등이 여기에 해당한다.

기업자산이라고 해서 모두 같은 성격을 갖는 것은 아니다. 장기간 보관하는 재무자산, 지급과 정산에 반복적으로 사용하는 자금, 스마트 컨트랙트를 직접 호출하는 운영자산은 거래 빈도와 외부 노출, 사고가 발생했을 때의 파급 범위가 서로 다르다. 여기에 토큰 발행과 소각, 투자자 주소 등록, 이전 제한과 동결, 컨트랙트 업그레이드처럼 자산을 거의 보유하지 않으면서도 상품 전체에 영향을 미치는 관리자 권한이 더해진다.

이 차이는 지갑을 나누는 이유이지 지갑 구조 자체를 결정하는 기준은 아니다. 실제 구조를 가르는 것은 각 자산에 필요한 키 통제의 위치다. 거래가 드물고 금액이 큰 재무자산은 보관 책임을 전문기관에 넘기는 편이 유리할 수 있지만, 네트워크 수수료를 지급하고 컨트랙트를 호출하며 대량 지급을 자동화해야 하는 자산은 외부 기관의 출금 절차에 매번 의존하기 어렵다. 관리자 권한 역시 상품 운영 주체가 직접 통제하되 한 사람이 단독으로 행사하지 못하도록 나누는 문제다.

따라서 기업자산 운영 지갑은 키를 누가 통제하는지에 따라 외부수탁형과 직접수탁형으로 구분한다. 실제 기업은 둘 중 하나만 쓰기보다, 자산의 성격에 따라 두 방식을 함께 운영하는 경우가 많다.

(1) 외부수탁형(Third-party Custody)

외부수탁형은 기업이 보유한 자산의 키를 외부 수탁기관이 관리하고, 기업은 계정 권한자로서 입출금과 운용을 지시하는 방식이다. 자산은 수탁기관이 운영하는 지갑 구조 안에 보관되며, 기업 임직원은 수탁기관이 제공하는 화면이나 API를 통해 거래를 요청한다.

기업이 이 구조를 선택하는 이유는 보관 자체를 잘하기 어렵기 때문이다. 키 생성과 백업, 물리적 보관, 접근 권한 관리, 사고 대응까지 갖추려면 전담 조직과 설비가 필요하다. 수탁 인가를 받은 기관을 이용하면 이러한 부담을 넘기면서 감사 대응과 보험, 자산 분리에 관한 제도적 기반도 함께 확보할 수 있다. 규제 대상 기관이 자산을 적격 수탁기관에 보관해야 하는 경우에는 선택의 문제가 아니라 요건이 되기도 한다.

대신 기업이 할 수 있는 일의 범위는 수탁기관의 정책 안으로 제한된다. 지원하는 네트워크와 자산의 목록, 출금에 걸리는 시간과 승인 절차, 임의의 스마트 컨트랙트를 호출할 수 있는지 여부가 모두 수탁기관에 따라 달라진다. 컨트랙트 호출을 지원하더라도 허용 목록에 등록된 프로토콜로 한정되는 경우가 많다.

수탁기관 자체가 새로운 위험이 된다는 점도 함께 봐야 한다. 해당 기관의 인가와 법적 지위, 고객자산이 기관의 고유자산과 분리되어 있는지, 도산 시 자산이 어떻게 처리되는지, 서비스가 중단되거나 계약이 종료될 때 자산을 다른 기관으로 옮길 수 있는지가 실사 항목이 된다.

(2) 직접수탁형(Self-custody)

직접수탁형은 기업이 자산의 키를 직접 통제하는 방식이다. 회사가 자체 설비에서 키를 관리할 수도 있고, 키관리 기술을 제공하는 인프라를 도입해 서명 권한만 회사가 보유할 수도 있다. 어느 쪽이든 거래를 최종적으로 승인하는 권한은 기업 내부에 남는다.

직접 통제한다는 것이 담당자 한 명이 키를 갖는다는 뜻은 아니다. 오히려 이 구조에서는 통제를 어떻게 나눌지가 핵심이 된다. 거래를 요청하는 사람과 승인하는 사람을 분리하고, 일정 금액 이상이나 새로운 수취인에게는 복수 승인을 요구하며, 미리 등록한 주소로만 출금하도록 제한하는 식이다. 스마트 컨트랙트를 호출하는 거래에서는 대상 컨트랙트와 함수, 함수에 입력되는 주소와 금액까지 조건으로 삼을 수 있어야 한다. 여러 주체가 키를 나눠 갖고 정해진 수 이상이 동의해야 서명이 완성되도록 구성하는 방법도 널리 쓰인다.

이 방식은 반복적인 지급과 정산, 컨트랙트 호출, 프로토콜 예치처럼 자동화와 속도가 필요한 업무에 적합하다. 기업의 주문 / 회계 시스템에서 지급 정보를 전달받아 거래를 생성하고, 완료된 결과를 다시 내부 장부에 반영하는 흐름을 만들 수 있다. 토큰 발행과 동결, 투자자 목록 변경, 컨트랙트 업그레이드 같은 관리자 권한도 상품을 운영하는 기업이 직접 보유하되 권한별로 서로 다른 승인 절차를 적용하는 편이 자연스럽다.

그 대신 통제 실패의 책임도 기업에 남는다. 키를 잃거나 유출됐을 때의 복구 절차, 담당자 퇴사와 조직 변경에 따른 권한 회수, 승인 이력의 기록과 감사 대응을 회사가 설계해야 한다. 자동화 범위가 넓어질수록 잘못된 조건 하나가 대량 거래로 이어질 수 있으므로, 거래를 실행하기 전에 어떤 자산이 어디로 이동하고 어떤 권한이 새로 부여되는지 확인하는 절차도 필요하다.

두 방식은 배타적이지 않다. 준비금은 수탁기관에 맡기고 일상적인 정산과 컨트랙트 거래는 직접 통제하는 지갑에서 처리하되, 필요할 때만 수탁 계좌에서 운영 지갑으로 자금을 옮기는 구성이 일반적이다. 이때 두 영역 사이의 자금 이동 자체가 별도의 승인 대상이 된다.

지금까지 사용자가 지갑을 이용하는 방식과 기업이 자산을 운영하는 방식을 정리했다. 다음 장에서는 이러한 구조를 실제로 구현하는 지갑 인프라 벤더를 사용자 지갑과 기업형 지갑으로 나눠 소개한다.

 

4. 주요 지갑 인프라 벤더

앞에서는 사용자가 지갑을 이용하는 방식과 기업이 자산을 통제하는 목적을 짚었다. 실제 서비스를 구축하려면 이러한 구조를 직접 개발하거나, 필요한 기능을 제공하는 지갑 인프라를 선택해야 한다.

지갑 인프라 벤더들은 모두 같은 문제를 해결하지 않는다. 사용자 지갑 인프라는 고객이 서비스에 접근하는 접점을 만들고, 기업형 지갑 인프라는 기업이 자산과 온체인 권한을 통제하는 절차를 제공한다. 이 장에서는 각 영역의 대표 벤더를 소개하되, 전편에서 다룬 수탁 인가나 MPC / HSM의 세부 구조를 반복하지 않는다.

4-1. 지갑 인프라 시장의 구성

지갑 인프라 시장은 앞 장의 분류와 같은 축으로 나뉜다. 사용자 지갑 인프라는 고객이 기존 지갑을 연결하거나 서비스가 지갑을 제공하도록 지원하고, 기업형 지갑 인프라는 기업이 자산을 외부에 맡기거나 직접 통제하도록 지원한다.

주목할 점은 이 시장이 최근 2년 사이 크게 재편됐다는 것이다. Stripe는 2025년 6월 11일 임베디드 지갑 인프라 Privy 인수를 발표했고, Privy는 Stripe 산하에서 독립 제품으로 운영된다. 같은 해 6월 2일 Consensys가 Web3Auth를 인수해 MetaMask에 편입했고, 10월 23일에는 Fireblocks가 지갑 개발 플랫폼 Dynamic을 인수했다. 세 건 모두 거래 금액은 공개되지 않았다. 개발자들이 독립성을 이유로 선택했던 임베디드 지갑 벤더 상당수가 1년이 채 되지 않는 기간에 결제 / 인프라 대기업의 산하로 편입된 셈이다.

이 재편은 벤더 실사에 새로운 항목을 더한다. 서비스가 종료되지 않더라도 제품 로드맵은 모회사의 전략을 따라가며, 지갑 인프라를 도입하는 기업은 자사의 방향과 벤더 모회사의 방향이 같은지를 함께 봐야 한다.

또 하나의 흐름은 두 계통의 경계가 흐려지고 있다는 점이다. Fireblocks는 Dynamic 인수를 두고 커스터디에서 소비자까지 아우르는 스택이라고 설명했고, Anchorage Digital도 수탁 서비스와 별도로 셀프 커스터디 지갑 Porto를 운영한다. 기관 수탁을 제공하던 벤더가 고객 지갑 영역으로, 고객 지갑을 제공하던 벤더가 기관 인프라 쪽으로 확장하는 셈이다. 다만 한 벤더가 두 영역을 모두 제공한다고 해서 고객자산과 기업자산의 통제 구조까지 하나로 합쳐지는 것은 아니다.

4-2. 사용자 지갑 인프라

사용자 지갑 인프라는 RWA 서비스와 고객 사이의 접점을 만든다. 완성된 지갑 제품을 브랜드만 바꿔 배포할 것인지, 지갑 기능을 직접 조립할 것인지, 외부 지갑 연결과 서비스 내 지갑을 함께 지원할 것인지에 따라 선택이 달라진다.

아래 세 벤더는 시장 점유율 순위가 아니라 도입 형태가 서로 다른 세 지점을 보여주기 위해 골랐다. 완성된 지갑을 통째로 납품하는 화이트라벨(Kresus), 지갑 기능을 부품 단위로 제공하는 SDK / API(Privy), 외부 지갑 연결과 서비스 내 지갑을 하나로 묶은 통합 SDK(Dynamic)다.

(1) Kresus

Kresus는 기업이 자체 브랜드의 지갑을 배포할 수 있도록 화이트라벨 지갑 인프라를 제공한다. 기존 제품에 삽입하는 임베디드 방식, 웹 기반 포털, 독립 앱 형태를 모두 지원하며 사용자 통제형과 사업자 통제형, 두 구조를 결합한 혼합 구성이 가능하다. 앞 장의 분류로 보면 서비스 내 지갑 제공형을 통째로 납품하는 제품이다.

제품 범위는 지갑에 그치지 않는다. Kresus는 RWA 토큰화 플랫폼 Kite와 스테이블코인 결제 / 정산 워크플로를 함께 제시하며, Kite는 기관 네트워크와 EVM 체인에서 실물자산의 발행과 관리, 결제를 다루는 인프라로 소개된다.

한국 시장과의 접점도 있다. Kresus는 2025년 12월 아부다비 파이낸스 위크 2025 현장에서 한화투자증권과 디지털자산 인프라 구축을 위한 업무협약을 체결했다. 협약 범위는 디지털 지갑 및 토큰화, 블록체인 기술 개발, 인적 교류로 안내됐다. 구체적인 구축 결과물이 공개된 단계는 아니지만, 지갑 인프라 벤더가 토큰화 파트너로 함께 들어오는 형태는 국내 금융기관이 실제로 마주할 가능성이 있는 조합이다.

다만 Kresus의 공개 자료는 제품 구성과 배포 방식 중심이며, 지원 네트워크별 구현 범위나 보안 인증의 구체적 범위는 개발자 문서 수준으로 공개돼 있지 않다. 통제 주체와 복구 구조, 데이터 이전 조건은 공개 자료가 아니라 개별 실사로 확인하는 편이 안전하다.

(2) Privy

Privy는 로그인과 지갑 생성을 서비스 안에 포함할 수 있도록 지원하는 임베디드 지갑 인프라다. 사용자를 위한 지갑을 만들어 통제권을 사용자에게 남길 수도 있고, 기업이 통제하는 지갑 묶음을 운영할 수도 있으며, 지갑 단위로 승인 권한을 지정하는 방식도 제공한다. 완성된 지갑을 받는 Kresus와 달리 화면과 흐름을 기업이 직접 설계하는 조립형이다.

키관리는 신뢰 실행 환경(TEE)과 키 분할을 결합한 구조를 사용하며, 세션 서명자와 정책 제어를 개발자가 직접 다룰 수 있도록 저수준 API로 공개한다. 정책 엔진으로는 허용 컨트랙트와 수취인, 최대 이전 금액, 컨트랙트 호출 데이터에 대한 제한을 설정할 수 있고, 거래에 다중 인증이나 복수 승인을 요구할 수도 있다. 가스비 대납도 기본 기능으로 제공한다.

문서화 수준이 높다는 점은 사전 검증에 유리한 요소다. 그러나 RWA에 필요한 투자자 적격성 확인과 명의개서, 상품별 이전 제한은 Privy가 완성해 주는 기능이 아니라 토큰 컨트랙트와 외부 시스템에 연결해야 하는 영역이다.

(3) Dynamic

Dynamic은 외부 지갑 연결과 임베디드 지갑, 멀티체인 연결을 하나의 SDK로 묶어 제공한다는 점을 내세운다. 임베디드 지갑과 소셜 로그인, 다수의 외부 지갑 연결을 같은 SDK에서 다루며, 이메일과 SMS, 패스키로 온보딩을 처리한다. 2장의 외부지갑 연결형과 서비스 내 지갑 제공형을 한 제품에서 함께 지원한다는 점이 다른 두 벤더와의 차이다.

임베디드 지갑은 통제권을 사용자에게 남기는 구조로, TSS-MPC를 사용해 사용자 기기에 저장되는 지분과 서버 지분으로 나누며 기본 2/2 구성을 2/3으로 조정할 수 있다. 사용자는 지갑을 내보내 다른 제공자나 저장 환경으로 옮길 수 있다. 키 이동성이 문서로 확인된다는 점은 서비스 종료나 벤더 교체를 검토할 때 참고할 만한 항목이다.

RWA 맥락에서 눈에 띄는 사례는 1장에서 언급한 Ondo다. Ondo Finance는 OUSG를 포함한 제품 전반에서 사용자가 기존 지갑을 연결하도록 하는 데 Dynamic을 활용하고 있다. 외부지갑 연결형 서비스가 연결 규격을 직접 구축하지 않고 인프라로 해결하는 전형적인 형태다.

4-3. 기업형 지갑 인프라

기업형 지갑 인프라는 3-2의 두 갈래에 대응한다. 자산을 외부 수탁기관에 맡길 것인지, 키를 직접 통제하되 통제 절차를 인프라로 구현할 것인지에 따라 검토 대상이 달라진다. 아래 세 벤더 역시 규모가 아니라 이 스펙트럼에서 차지하는 위치를 기준으로 골랐다. 규제 수탁기관(Anchorage Digital), 두 방식을 한 회사에서 함께 제공하는 사업자(BitGo), 직접 통제를 인프라로 구현하는 플랫폼(Fireblocks)이다.

(1) Anchorage Digital

Anchorage Digital은 외부수탁형의 전형이다. 미국 통화감독청(OCC)으로부터 국법은행 인가를 받았으며 이는 크립토 기업으로서는 최초였고, 싱가포르 통화청(MAS) 라이선스와 뉴욕주 BitLicense도 보유한다. 커스터디는 파산 격리와 분리 보관을 전제로 하며, 생체 인증 기반 승인으로 24시간 거래 권한을 부여하는 방식을 제공한다.

RWA 관점에서 중요한 것은 지원 자산의 성격이다. Anchorage의 인가는 토큰화 증권과 스테이블코인을 포함한 폭넓은 디지털자산의 수탁을 허용한다. 실제로 Etherfuse가 Stellar에서 발행한 멕시코 국채 토큰(CETES)의 기관 수탁을 맡은 사례처럼, 발행자가 토큰화하고 퍼블릭 또는 허가형 체인이 결제를 담당하며 규제 수탁기관이 투자자를 대신해 토큰을 보관하는 구조가 반복적으로 나타나고 있다. 2026년 6월 22일에는 은행이 예금을 토큰화해 발행하고 관리할 수 있는 인프라를 공개하면서, 블록체인 인프라와 지갑 관리, 스마트 컨트랙트는 Anchorage가 맡고 고객 관계와 프론트엔드는 은행이 유지하는 분담을 제시했다.

기업 입장에서 확인할 지점은 통제 범위다. 수탁기관이 제공하는 승인 체계 안에서 업무를 설계해야 하므로, 지원 자산과 네트워크 목록, 임의의 컨트랙트를 호출할 수 있는지, 출금과 승인에 걸리는 시간이 자사 정산 주기와 맞는지가 계약 전 확인 대상이 된다.

(2) BitGo

BitGo는 규제 수탁과 직접 통제를 한 회사에서 함께 제공한다는 점이 특징이다. 수탁 지갑은 BitGo Bank & Trust(국법 신탁), BitGo New York Trust Company, 유럽과 스위스 법인 등 규제 대상 신탁 법인을 통해 제공되며, 상세한 감사 추적과 보고 도구, 정책 적용 기능을 포함한다. 동시에 자체 통제 지갑과 규제 커스터디, 핫월렛과 콜드월렛을 독립적으로 또는 함께 배치할 수 있는 구성을 제시한다. 기술과 소프트웨어 제공 법인은 별도로 두어 비수탁 SaaS 제품을 담당한다.

자체 통제형 콜드월렛에서는 고객이 세 개의 키 중 두 개를 보유하고, 오프라인에서 부분 서명한 거래를 공동 서명 플랫폼으로 전달하는 방식을 사용한다. 3-2에서 설명한 통제 분산 구조를 제품 형태로 구현한 사례로 볼 수 있다.

2026년 1월 22일 BitGo는 뉴욕증권거래소에 BTGO로 상장했다. 상장 신청서 기준 플랫폼이 보관하는 자산 규모는 2025년 9월 30일 기준 약 1,040억 달러였다. 상장으로 재무 정보 공시가 늘어나 수탁기관 실사에서 참고할 만하다.

(3) Fireblocks

Fireblocks는 직접수탁형을 인프라로 구현한다. MPC와 하드웨어 격리를 결합해 키를 여러 주체에 분산하는 방식을 사용하며, 키가 나뉘어 있어 Fireblocks가 단독으로 고객 자산을 이전할 수 없다는 점을 전면에 내세운다. 자산 통제는 기업에 남고, 벤더는 승인 절차와 정책을 실행하는 층을 제공한다.

플랫폼은 커스터디뿐 아니라 트레저리 운영과 정책 통제, 네트워크 연결을 하나의 관리 화면에 묶는 구조로 설계돼 있다. 토큰화 관점에서는 대규모 발행과 소각, 투자자 화이트리스트의 무결성, 스마트 컨트랙트 거버넌스를 별도의 보안 요건으로 다루며, 스테이블코인 발행자에게는 준비금 계좌 통제와 발행 권한 정책을 애플리케이션이 아니라 하드웨어 수준에서 강제하는 방식을 제시한다. 지원 네트워크는 2026년 2월 발표 기준 퍼블릭 블록체인 150개이며, 2025년 한 해에만 46개가 추가됐다. 통합 대상에는 기관용 네트워크도 포함된다.

한편 Fireblocks도 수탁 영역을 함께 갖고 있다. 뉴욕주 금융서비스국(NYDFS)의 규제를 받는 Fireblocks Trust Company가 적격 수탁기관으로 운영되며, AML 스크리닝과 트래블룰 대응, 정책 엔진 등 컴플라이언스 기능도 플랫폼에 포함된다. 따라서 도입 시에는 어떤 계약 구조로 어느 법인과 거래하는지, 자산의 통제권이 실제로 어디에 있는지를 제품명이 아니라 계약 단위로 확인해야 한다.

관리형 플랫폼이라는 성격에서 오는 부담도 있다. 정책과 지갑 구조, 트레저리 운영 절차가 플랫폼에 깊이 결합될수록 벤더는 하나의 공급자가 아니라 업무 시스템의 일부가 된다. 계약 종료나 장애 상황에서 지갑과 승인 기록을 어떻게 이전하고 독립적으로 자산에 접근할 수 있는지는 3-2에서 정리한 직접수탁형의 실사 항목 그대로다.

세 벤더를 나란히 놓고 보면, 차이는 기능 목록보다 계약 구조에서 먼저 드러난다. 같은 회사의 제품을 쓰더라도 어느 법인과 계약하느냐에 따라 자산의 법적 취급과 사고 시 책임 소재가 달라지기 때문이다. 다음 장에서는 두 계통의 벤더를 각각 같은 기준으로 비교한다.

 

5. RWA 지갑 벤더 비교

앞 장에서는 Kresus, Privy, Dynamic이 고객 접점을 만드는 방식과 Anchorage Digital, BitGo, Fireblocks가 기업의 자산 통제를 지원하는 방식을 확인했다. 이 장에서는 각 벤더를 다시 소개하기보다 보안 / 규제, 지원 네트워크 / 자산, 토큰 / RWA 기능, 제품 제공 방식이라는 네 가지 기준으로 차이를 비교한다.

사용자 지갑 인프라와 기업형 지갑 인프라는 해결하는 문제가 다르므로 하나의 표에 섞지 않는다. 같은 기준을 적용하더라도 사용자 지갑에서는 고객 경험과 통제권 이전이, 기업형 지갑에서는 자산의 법적 취급과 내부통제가 답의 성격을 결정하기 때문이다.

5-1. 비교 기준

(1) 보안 / 규제

이 기준은 두 계통에서 서로 다른 것을 본다. 사용자 지갑 인프라는 기술 벤더이므로 회사의 운영체계가 외부 검증을 받았는지를 보고, 기업형 지갑 인프라는 자산을 맡을 수 있는 법적 지위를 갖췄는지를 본다. 두 계통을 하나의 잣대로 비교하면 성격이 다른 항목이 섞이므로, 아래 비교표에서도 축을 나눠 적용한다.

사용자 지갑 인프라에서 확인하는 것은 인증이다. SOC 2는 미국공인회계사회의 신뢰서비스 기준에 따라 보안, 가용성, 처리 무결성, 기밀성, 개인정보 보호 관련 통제를 외부 감사인이 검토하는 보고 체계이며, Type II는 일정 기간 통제가 실제로 운영됐는지를 확인한다. ISO/IEC 27001은 정보보안 관리체계의 요건을 정한 국제표준이다. 둘 다 회사가 시스템을 어떻게 운영하는지를 평가하며, 고객자산의 법적 분리나 도산 시 처리는 다루지 않는다.

기업형 지갑 인프라에서 확인하는 것은 인가다. 국법은행이나 신탁회사 인가, 주 단위 라이선스를 받은 기관은 자산 분리와 파산 격리, 보고 의무를 규제 요건으로 부담한다. 규제 대상 기관이 적격 수탁기관을 이용해야 하는 경우에는 벤더의 기술 수준이 아니라 이 지위가 도입 가능 여부를 가른다. 기술 인증을 보유한 플랫폼이라도 수탁 지위는 별도 법인이 갖는 경우가 있으므로, 계약 상대가 기술 제공자인지 수탁기관인지를 함께 확인해야 한다.

(2) 지원 네트워크 / 자산

지원 네트워크는 지갑이 어느 블록체인에서 주소를 만들고 거래를 실행할 수 있는지를 뜻한다. 다만 지원 체인 수만으로 기능 범위를 판단하기는 어렵다. 어떤 네트워크에서는 지갑 생성부터 거래 제출, 정책 적용, 가스비 대납까지 지원하지만, 다른 네트워크에서는 주소 생성과 서명만 지원할 수도 있다.

자산 축을 함께 보는 이유는 수탁기관과 기술 인프라의 작동 방식이 다르기 때문이다. 기술 인프라는 해당 체인에서 임의의 컨트랙트를 호출할 수 있다면 새로운 토큰도 대체로 다룰 수 있다. 반면 수탁기관은 보관할 자산을 하나씩 심사해 지원 목록에 추가하므로, 특정 RWA 토큰을 맡기려면 그 토큰이 목록에 올라 있는지부터 확인해야 한다. 국내 기관이라면 여기에 허가형 네트워크 지원 여부가 더해진다.

(3) 토큰 / RWA 기능

실물자산 토큰화를 추진하는 기관은 토큰의 발행과 이전뿐 아니라 기초자산의 권리관계와 규제 요건을 함께 관리할 수 있는 기능을 요구한다. 대표적으로 투자자가 해당 상품을 보유할 자격이 있는지 확인하고, 승인된 투자자 사이에서만 토큰이 이전되도록 제한하며, 법적 명령이나 오류가 발생했을 때 토큰을 동결하거나 회수할 수 있어야 한다. 발행과 소각, 투자자 명부 변경과 같은 주요 작업에도 일반 송금과 구분되는 승인 절차가 필요하다.

일반적인 스테이블코인과 펀드 토큰 상당수는 ERC-20 또는 이와 호환되는 구조로 발행된다. ERC-20은 이더리움에서 대체 가능한 토큰의 잔고 조회와 이전, 제3자 사용 승인을 표준화한 기본 인터페이스지만, 투자자 자격 확인이나 이전 제한, 동결과 회수 같은 규제형 금융상품의 기능까지 정의하지는 않는다. 이러한 기능은 발행자가 별도의 스마트 컨트랙트 로직으로 추가하거나, 온체인 신원과 적격성 확인, 컴플라이언스 규칙을 결합한 ERC-3643 같은 규제형 토큰 표준을 활용해 구현할 수 있다.

다만 지갑이 특정 토큰 표준을 지원한다는 표현은 주의해서 봐야 한다. EVM 스마트 컨트랙트를 호출할 수 있는 지갑이라면 ERC-3643 토큰의 함수도 기술적으로 실행할 수 있기 때문이다. 실제 차이는 발행과 소각, 동결과 회수 같은 거래의 내용을 승인자에게 정확히 보여주는지, 각 작업에 별도의 승인 정책을 적용할 수 있는지, 투자자 명부와 KYC·명의개서 시스템을 연결할 수 있는지에서 발생한다.

(4) 제품 제공 방식

같은 지갑 기능이라도 어떤 형태로 받는지에 따라 기업이 직접 만들어야 하는 범위가 달라진다. SDK는 벤더가 만든 코드 묶음을 기업의 앱에 넣는 방식으로 로그인과 지갑 생성, 서명 요청처럼 사용자가 보는 화면이 대체로 함께 딸려 온다. API는 벤더의 서버에 요청을 보내는 방식이라 화면은 기업이 전부 만들어야 하지만, 사용자 화면을 거치지 않는 처리를 자동화할 수 있다. 정기 매수 실행이나 대량 지급, 백오피스에서의 주소 등록이 여기에 해당한다. 두 방식은 배타적이지 않아 대개 한 벤더가 함께 제공하며, 화면은 SDK로 붙이고 정책과 서명은 API로 다루는 구성이 일반적이다.

화이트라벨은 완성된 지갑을 기업의 이름과 디자인으로 배포하는 방식이다. 만들 것이 거의 없어 출시가 빠른 대신 화면 구성과 기능 범위가 벤더가 정해둔 틀 안으로 제한된다. 관리형 플랫폼과 수탁계약은 성격이 다르다. 앞의 셋이 기업이 만드는 제품에 기능을 넣는 방식이라면, 이 둘은 벤더가 운영하는 체계 안으로 기업의 업무가 들어가는 방식이다. 검토의 중심도 개발 범위가 아니라 계약 조건과 승인 절차, 종료 시 이전 방법에 놓인다.

5-2. 사용자 지갑 인프라 비교

세 벤더는 모두 기업이 고객에게 지갑을 제공하도록 지원하지만 출발점이 다르다. Kresus는 완성된 지갑 제품을, Privy는 조립할 수 있는 지갑 기능을, Dynamic은 외부 지갑 연결과 임베디드 지갑을 함께 묶은 SDK를 제공한다.

보안 항목에서는 공개된 정보의 양 자체가 갈린다. Privy는 SOC 2 Type II를 매년 갱신하고 Cure53, Zellic 등의 외부 점검을 분기 단위로 받으며, 트러스트 센터에서 아키텍처 문서와 점검 요약을 공개해 보안 검토를 진행할 수 있게 한다. Dynamic도 SOC 2 Type II를 갖추고 정기 외부 점검과 공개 버그바운티를 운영한다. 반면 Kresus는 제품 구성과 배포 방식 중심으로 자료를 공개하고 있어, 인증 범위는 개별 실사로 확인해야 한다.

네트워크와 자산에서는 세 벤더가 서로 다른 강점을 보인다. Dynamic은 임베디드 지갑과 소셜 로그인, 다수의 외부 지갑 연결을 하나의 SDK에서 다루므로 고객이 이미 보유한 지갑을 폭넓게 수용해야 하는 서비스에 유리하다. Privy는 EVM과 Solana를 중심으로 기능이 두텁고, Kresus는 소비자 지갑에서 지원하는 체인과 별개로 Kite를 통해 기관 네트워크와 EVM 체인에서 실물자산을 다루는 범위를 제시한다. 국내 기관이 허가형 네트워크를 검토한다면 Kresus가 Canton 생태계에 지갑과 토큰화 스택을 공급하고 있다는 점이 실제 접점이 될 수 있다.

RWA 기능에서 드러나는 차이가 가장 크다. Privy와 Dynamic은 지갑과 거래를 구성하는 범용 인프라이므로 투자자 적격성과 이전 제한, 명의개서는 토큰 컨트랙트와 외부 시스템에서 해결해야 한다. Dynamic은 이 경계를 명시적으로 밝힌다. 신원 확인과 자금세탁방지 심사, 거래 모니터링을 직접 수행하지 않고, 스크리닝과 정책 규칙, 감사 추적 같은 인프라 통제만 제공하며 실제 심사는 기업이 선택한 컴플라이언스 제공자가 담당한다. 반면 Kresus는 Kite를 실물자산 기반 토큰의 발행과 관리, 결제를 다루는 플랫폼으로 제시해 제품 범위를 지갑 밖까지 넓힌다. 다만 Kite는 화이트라벨 지갑과 구분되는 별도 제품이며 지원 표준이 공개 자료에 구체적으로 명시돼 있지 않다.

세 벤더를 나란히 놓고 보면 차이보다 공통점이 먼저 눈에 띈다. 투자자 적격성 확인과 이전 제한, 명부 관리처럼 RWA를 RWA로 만드는 기능은 어느 쪽을 고르든 지갑 바깥에 남는다. 지갑 인프라는 고객이 자산에 접근하는 경로를 만들 뿐, 그 자산이 누구에게 갈 수 있는지까지 정해주지는 않는다. 벤더 비교만으로는 이 부분이 해결되지 않으므로, 토큰 표준과 명부 관리 주체, 적격성 확인 절차를 먼저 정한 뒤 그 구조에 필요한 연결 지점을 지갑 인프라에서 확인해야 한다.

5-3. 기업형 지갑 / 수탁 인프라 비교

세 벤더는 기업형 지갑의 수탁 방식에서 각각 서로 다른 지점을 차지한다. Anchorage Digital은 외부수탁형에, Fireblocks와 BitGo는 두 방식을 한 회사에서 함께 제공한다.

보안 / 규제 축에서는 인가의 범위가 갈린다. Anchorage Digital은 OCC 국법은행 인가와 MAS 라이선스, 뉴욕주 BitLicense를 함께 보유해 여러 관할에 걸친 규제 기반을 갖췄다. BitGo는 국법 신탁과 뉴욕 신탁회사, 유럽 / 스위스 법인 등 규제 대상 신탁 법인을 통해 수탁을 제공하고, 기술과 소프트웨어는 별도 법인이 담당한다. Fireblocks는 기술 플랫폼이 본체이며 수탁은 뉴욕주 감독을 받는 신탁 법인이 적격 수탁기관으로 담당한다. 세 회사 가운데 둘이 두 방식을 함께 제공하는 만큼, 이 축에서 확인할 것은 인가의 개수도 벤더의 평판도 아니라 자사가 계약하는 법인이 기술 제공자인지 수탁기관인지다.

네트워크와 자산에서는 접근하는 단위가 다르다. Anchorage와 BitGo는 자산을 하나씩 심사해 지원 목록에 올리는 방식이고, 그중 BitGo는 지원 폭 자체를 내세워 2026년 1분기 기준 시가총액 상위 250개 자산 중 186개를 다룬다고 밝힌다(자사 집계). Fireblocks는 자산 목록이 아니라 체인 단위로 접근해 퍼블릭 블록체인 150개를 지원한다. 특정 RWA 토큰을 다뤄야 한다면 앞의 두 곳에서는 그 토큰이 지원 목록에 있는지, Fireblocks에서는 그 토큰이 올라간 체인을 지원하는지가 곧 도입 가능 여부가 된다.

토큰 / RWA 기능에서는 맡겠다고 나서는 구간이 다르다. Anchorage는 보관과 결제에 선다. BitGo는 규제 자산 전용 체인 Polymesh를 커스터디에 통합했고, Brassica 인수로 확보한 SEC 등록 명의개서대리인을 통해 앞 절에서 지갑 바깥에 남는다고 정리한 명부 영역까지 들어와 있다. Fireblocks는 발행과 소각, 화이트리스트 무결성 같은 권한 실행에 서며, 발행 권한 정책을 하드웨어 수준에서 강제한다. 3-2의 관리자 권한 통제에 직접 대응하는 것은 Fireblocks뿐이고, 나머지를 선택한다면 그 권한 설계는 기업이 떠안는다.

제공 방식의 차이는 도입 이후의 의존 구조로 이어진다. Anchorage의 수탁계약은 내부 구축 부담이 가장 작은 대신 업무 범위가 계약 조건 안으로 제한되고, BitGo의 2-of-3 공동 서명은 고객이 세 개 키 중 두 개를 보유해 통제를 나눠 갖는 중간 형태이며, Fireblocks처럼 정책과 트레저리 절차를 플랫폼에 결합하면 효율은 높아지되 벤더가 업무 시스템의 일부가 된다. 세 방식은 한 회사 안에서도 병행되므로, 실사는 벤더가 아니라 지갑 단위로 정리해 두는 편이 유리하다.

세 벤더는 하나의 기능을 두고 경쟁하기보다 기업이 통제권을 어디까지 가져갈지에 따라 선택지가 갈린다. 단순히 어떤 벤더가 더 좋고 나쁘다의 기준보다는 자사가 다루는 자산이 법정 분리 의무의 대상인지, 컨트랙트 호출과 자동화가 업무에 필수인지, 관리자 권한을 누가 나눠 가질지를 먼저 정한 뒤 대응하는 벤더를 검토하는 순서가 자연스럽다.

 

6. 결론

디지털자산 지갑은 토큰을 담아두는 저장소가 아니며, 단순한 전송 화면에도 그치지 않는다. 블록체인에 기록된 자산에 접근하고 거래를 승인하는 인터페이스이자, 사용자 경험과 기업의 내부통제를 연결하는 서비스 인프라다.

이 두 층위는 겉으로 드러나는 화면과 일치하지 않는다. 간편한 로그인 뒤에 사용자가 통제하는 지갑이 있을 수도, 사업자가 서명하는 계정이 있을 수도 있다. 사업자 통제형 서비스에서 실제 키를 사업자가 쥐는지 외부 기관이 쥐는지도 고객 화면에는 나타나지 않는다. 지갑을 평가할 때 기능 목록보다 통제 주체와 복구 경로가 먼저인 이유가 여기에 있다.

벤더 선택도 같은 맥락에 놓인다. 지원 기능이 가장 많은 인프라를 고르는 문제가 아니라, 어떤 지갑을 어떤 용도로 운영할지 먼저 정한 뒤 그 구조에 맞는 인프라를 찾는 문제다. 확인할 항목도 계통에 따라 다르다. 사용자 지갑 인프라는 기술 벤더이므로 보안 인증과 문서화 수준, 키 이동성이 검토 대상이고, 기업형 지갑 인프라는 수탁 인가와 자산 분리, 계약 상대가 기술 제공자인지 수탁기관인지가 먼저다. 인증과 인가는 서로를 대체하지 않는다. 여기에 최근 2년의 시장 재편이 항목 하나를 더한다. 벤더의 로드맵이 모회사의 전략을 따라가는 이상, 장기 계약에서는 제품 기능과 함께 소유 구조와 이전 가능성도 검토 대상이 된다.

이번 비교에서 드러난 또 하나의 사실은 RWA에 필요한 기능 상당수가 지갑 바깥에 남는다는 점이다. 투자자 적격성 확인과 이전 제한, 투자자 명부와 명의개서는 지갑 벤더가 완성해 주는 영역이 아니라 토큰 컨트랙트와 외부 시스템에서 해결해야 한다. 일부 벤더가 토큰화 플랫폼을 함께 제공하지만 그 역시 지갑 제품과는 구분되는 별도 구성요소다. 지갑 인프라를 선정하는 일과 규제 요건을 충족하는 상품 구조를 설계하는 일은 순서가 다른 과제다.

앞으로 기관이 확인해야 할 질문도 여기서 나온다. 서비스가 종료된 뒤에도 사용자가 자산에 접근할 수 있는가, 고객자산과 기업자산이 실제 지갑과 장부에서 구분되는가, 토큰 발행과 동결 같은 강한 권한이 적절히 분리돼 있는가. RWA 시장이 확대될수록 지갑 경쟁의 핵심도 단순한 키 보안을 넘어, 규제 요건과 사용자 경험, 기업 내부통제를 얼마나 자연스럽게 연결하는지로 이동할 것이다.