[Xangle RWA Series] 커스터디/KMS

 

1. 들어가며

2. 수탁 인가와 기관 지위

3. 수탁 실행 구조

4. 벤더 비교: 수탁 지위와 실행 구조

5. 결론

 

 

1. 들어가며

Fireblocks가 전 세계 600명 이상의 금융기관 고위 의사결정자를 대상으로 진행한 2026년 리서치 The Financial Grid에 따르면, 금융기관의 88%가 디지털자산 인프라 예산을 집행했거나 집행 예정이지만, 실제 프로덕션 단계에 도달한 곳은 16%에 그쳤다. 특히 커스터디와 지갑 거버넌스가 완전히 프로덕션 준비됐다고 답한 기관은 15%에 불과했다. 이 수치는 디지털자산 도입의 병목이 관심 부족이 아니라 커스터디 아키텍처, 지갑 거버넌스, 규제 준수를 함께 맞춰야 하는 인프라 설계 문제임을 보여준다.

1-1. 전통 금융에서 커스터디가 해온 역할

전통 금융에서 커스터디는 고객 자산을 대신 보관하고 관리하는 제도적 기능에서 출발한다. 같은 “맡긴다”는 행위라도 예금과 커스터디는 구조가 다르다. 예금은 고객이 은행에 돈을 맡기는 순간 그 금전의 소유권이 은행으로 넘어가고, 고객은 은행에 대해 예금반환청구권을 갖는다. 반면 커스터디는 자산의 법적·경제적 귀속이 고객에게 유지된 상태에서 보관과 관리 권한만 수탁기관에 맡기는 구조다.

이 구조에서 고객은 자산의 소유권을 유지하고, 수탁기관은 보관과 운영 절차를 수행한다. 그래서 전통 금융에서 커스터디는 자산을 넣어두는 금고 역할에 머물지 않고, 기관이 자산을 안전하게 운용하고 거래 이후 절차까지 처리할 수 있게 하는 제도적 운영 장치로 기능한다.

1-2. 디지털자산에서 커스터디가 달라지는 이유

그러나 디지털자산에서는 보관의 대상 자체가 달라진다. 디지털자산은 물리적 실체 없이 블록체인 또는 분산원장 위의 기록으로 존재하고, 그 자산을 이전하거나 사용할 권한은 암호화 키로 행사된다. 금융기관이 고객의 디지털자산을 수탁한다는 것은 실물을 금고에 넣어두는 일이 아니라, 자산의 전송과 접근을 결정하는 키와 지갑 통제권을 관리하는 일이다.

이 차이는 보관 리스크를 훨씬 직접적으로 만든다. 키를 잃으면 자산에 접근할 수 없고, 제3자가 키를 탈취하면 자산이 그대로 이전될 수 있다. 잘못된 주소로 보내거나 승인 권한이 오남용되어도 블록체인상 거래는 되돌리기 어렵다. 그래서 디지털자산 커스터디는 키를 안전하게 보관하는 기술 문제에서 출발하지만, 실제 운영에서는 누가 출금을 승인하는지, 어떤 주소로 보낼 수 있는지, 사고가 났을 때 어떤 절차로 중단하고 복구하는지까지 포함한다.

디지털자산 커스터디는 기술적 보안, 법적 책임, 운영 프로세스를 함께 설계해야 한다. 기술 측면에서는 키의 생성부터 보관, 사용, 복구까지 전 과정이 보안의 기준이 된다. 운영 측면에서는 권한 분리, 승인 절차, 감사 로그, 비상 중단 절차가 중요해진다. 법적 측면에서는 고객 자산에 대한 통제권을 누가 행사하는지, 고객 자산이 사업자 고유 자산과 분리되는지, 도산 시 고객에게 반환될 수 있는지가 수탁 구조의 신뢰를 좌우한다.

1-3. 디지털자산 보관 인프라를 보는 두 층위

디지털자산 보관 인프라는 두 층위로 나눠 봐야 한다.

첫째는 수탁 지위다. 고객 자산을 누가 어떤 제도적 자격으로 맡는가를 보는 층위다. 은행, 신탁회사, 가상자산사업자, CASP, DPT 서비스 제공자처럼 어떤 자격 아래에서 고객 자산을 보관하는지에 따라 감독 체계와 고객자산 보호 의무가 달라진다.

둘째는 실행 구조다. 고객 자산을 실제로 어떻게 통제하고 운영하는가를 보는 층위다. 실행 구조는 다시 세 요소로 나뉜다.

1. 자산을 누가 움직일 수 있는지를 정하는 키관리와 서명 통제
2. 고객 자산이 누구의 재산으로 남는지를 정하는 고객자산 분리 구조
3. 거래 과정에서 자산이 어디에 노출되는지를 정하는 담보·정산 구조

이 글은 이 두 층위를 기준으로 커스터디 시장을 살펴본다. 2장은 수탁 지위를, 3장은 실행 구조를 다룬다. 4장에서는 이 기준을 벤더 비교에 적용한다.

 

2. 수탁 인가와 기관 지위

수탁 지위가 답하는 질문은 고객 자산에 대한 통제권을 누가 행사하며, 그 주체가 어떤 제도적 자격 아래에서 책임을 부담하는가다. 규제당국은 회사가 스스로를 기술회사로 부르는지 거래소나 커스터디언으로 부르는지보다, 고객 자산에 대한 통제권을 실제로 행사하는지를 먼저 본다.

인가의 명칭도 구분해서 봐야 한다. 같은 인가처럼 보여도 가상자산 활동을 수행하도록 허용하는 활동 인가인지, 고객 자산을 맡아 관리하는 기관 지위인지에 따라 의미가 다르다. 활동 인가는 회사가 그 사업을 해도 된다는 허가에 가깝고, 기관 지위는 고객 자산에 대한 수탁 책임과 감독 체계를 함께 규정한다.

수탁 지위에 들어서는 두 진입 경로가 바로 이 구분에 따라 갈린다. 하나는 은행이나 신탁회사처럼 기존 금융기관의 기관 지위를 가상자산 수탁에 연결하는 편입 경로다. national trust bank, Limited Purpose Trust Company, MiCA Article 60의 통지 경로가 여기에 해당한다. 다른 하나는 가상자산 서비스 자체에 대한 전용 활동 인가를 받는 경로다. 뉴욕 BitLicense, EU의 CASP 인가, 한국의 VASP 신고가 여기에 해당한다.

이 구분이 중요한 이유는 활동 인가만 보유한 사업자가 그 사업을 할 자격은 갖췄어도 고객 자산을 맡는 수탁 책임까지 자동으로 갖추는 것은 아니기 때문이다. 게다가 뉴욕처럼 한 관할이 활동 인가와 기관 지위를 모두 두기도 해서, 벤더가 어느 관할에서 인가받았는지보다 어느 유형의 인가를 보유했는지를 봐야 한다. 다음 두 절에서 두 경로를 차례로 살펴본다.

2-1. 기존 금융기관의 편입 경로

은행, 신탁은행, 투자회사처럼 이미 금융당국의 감독을 받는 기관이 기존 인가 위에서 디지털자산 수탁 업무를 추가하는 방식이다. 감독당국은 이런 기관의 자본, 내부통제, 감사, 고객자산 보호 체계를 이미 검사하고 있으므로, 디지털자산 수탁 업무를 새로 볼 때도 기존 감독 체계와의 연결성을 함께 살핀다.

미국에서는 OCC와 NYDFS가 이 흐름을 대표한다. OCC는 고객을 위해 가상자산을 보관하고 관리하는 업무가 은행의 기존 수탁 업무 범위에 포함된다고 해석해왔다. 이 흐름을 대표하는 것이 national trust bank 지위다. 이는 예금과 대출 중심의 일반 상업은행이 아니라 신탁과 수탁 업무를 중심으로 인가받은 전국 단위 은행 지위다. 이 지위를 확보하면 디지털자산 수탁을 기술 서비스가 아닌 은행법상 감독을 받는 수탁 업무로 제공할 수 있다.

NYDFS는 가상자산 사업자에게 두 가지 경로를 둔다. BitLicense는 뉴욕에서 가상자산 매매, 이전, 보관 같은 사업 활동을 하기 위한 활동 인가다. Limited Purpose Trust Company는 고객 자산을 맡아 관리하는 신탁과 수탁 기능을 수행할 수 있는 기관 지위다. 기관투자자용 수탁 시장에서는 후자가 고객자산 보관 책임과 qualified custody 요건을 설명하는 데 더 직접적으로 쓰인다.

qualified custody는 투자자문사, 운용사, ETF 발행사, 프라임 브로커 고객이 요구하는 적격 수탁 체계를 뜻한다. 규제받는 법인이 자산을 분리 보관하고 장부와 감사, 보고 기준에 맞게 관리한다는 점을 보여주는 구조다.

같은 브랜드 안에서도 수탁 법인과 거래·기술 법인이 분리될 수 있다. Coinbase는 기관 고객의 수탁 자산을 별도 법인인 Coinbase Custody Trust Company에서 보관한다고 설명한다. Fireblocks도 지갑과 정책 엔진 인프라 회사로 알려져 있지만, NYDFS로부터 신탁회사 차터를 받은 Fireblocks Trust Company를 따로 두고 있다. 이 구분은 4장에서 벤더를 비교할 때 중요하다. 비교의 기준은 브랜드가 아니라 고객 자산을 맡는 법인과 그 법인의 규제 지위다.

EU에서는 MiCA가 기존 금융기관의 진입 경로를 비교적 명확하게 규정한다. 일반 사업자는 CASP 인가를 받아야 하지만, MiCA Article 60은 신용기관, 중앙예탁기관, 투자회사, 전자화폐기관, 펀드 운용사 같은 기존 금융기관이 감독당국에 통지하는 절차로 가상자산 서비스에 진입할 수 있는 경로를 둔다. 이 구조에서는 기존 금융기관의 자본, 내부통제, 감사, 고객자산 보호 체계가 가상자산 서비스 심사와 연결된다.

이 경로의 장점은 규제 신뢰와 기관투자자 호환성이다. 은행이나 신탁회사가 이미 금융감독 체계 안에 들어와 있으면, 고객은 지갑 기술뿐 아니라 자본, 감사, 내부통제, 이해상충 관리, 고객자산 보호 체계까지 기존 금융감독 문법으로 함께 평가할 수 있다.

2-2. 전용 가상자산사업자 인가 경로

전용 가상자산사업자 인가 경로는 은행이나 신탁회사 지위에 기대지 않고, 가상자산 서비스 자체에 대한 인가나 신고를 통해 수탁 업무에 진입하는 방식이다. 한국의 VASP 신고, EU의 CASP 인가, 두바이 VARA의 활동별 라이선스, 싱가포르의 DPT 서비스 규율이 여기에 해당한다. 명칭은 관할권마다 다르지만, 공통적으로 고객 자산 분리, 장부 관리, 콜드월렛 보관, 재담보 제한, 손실 발생 시 책임 같은 요건을 요구한다.

한국은 이 경로에 가장 가까운 구조를 가진다. 특정금융정보법은 가상자산의 보관과 관리를 가상자산사업자 규율 안에서 보므로, 디지털자산 수탁업자는 독립된 신탁은행 차터를 받는 방식이 아니라 FIU 신고와 자금세탁방지, 정보보호, 이용자 보호 요건을 통해 제도권에 들어간다. 이용자 예치금은 은행 분리예치나 신탁으로 관리하고, 이용자 가상자산은 사업자 고유 자산과 분리해 일정 비율 이상을 콜드월렛에 보관해야 한다.

이 경로의 장점은 디지털자산 운영에 맞춘 설계다. 처음부터 지갑, 키관리, 온체인 입출금, 스테이킹, 담보 관리를 중심으로 시스템을 구축할 수 있다. 다만 라이선스 보유만으로 기관 고객의 신뢰가 완성되지는 않는다. 고객 자산이 회사 고유 자산과 어떻게 분리되는지, 도산 시 어떤 법률 구조로 보호되는지, 서명 권한은 누가 통제하는지를 별도로 설명해야 한다.

2-3. 두 경로가 남기는 차이

두 경로는 모두 디지털자산 수탁을 제도권 안에서 수행하기 위한 방식이지만, 기관 고객에게 주는 신뢰의 언어가 다르다. 기존 금융기관 경로는 이미 검증된 금융감독 체계와 수탁자 책임, 감사와 내부통제 문법을 강점으로 한다. 전용 가상자산사업자 경로는 온체인 입출금, 멀티체인 지갑, 스테이킹, 거래소 연결, 정책 기반 출금 승인처럼 디지털자산 운영에 맞춘 설계를 강점으로 한다.

이 차이는 벤더 실사에서 그대로 드러난다. 은행이나 운용사는 national trust bank, Limited Purpose Trust Company, MiCA Article 60 같은 제도적 지위를 통해 규제 신뢰와 qualified custody 요건을 확인하려 한다. 헤지펀드나 마켓메이커는 수탁 지위와 함께 입출금 속도, 지원 체인, 담보 이동, 거래소 연결을 더 중요하게 본다. 같은 수탁기관이라도 고객 유형에 따라 실사 질문이 달라지는 이유다.

다만 수탁 지위는 벤더 평가의 출발점이다. 은행이나 신탁회사 지위는 법적 책임과 감독 체계를 설명하지만, 실제 고객 자산이 어떤 지갑 구조로 분리되는지까지 자동으로 보여주지는 않는다. 전용 가상자산사업자 인가는 온체인 운영에 유리하지만, 감사 가능성과 도산 시 반환 구조, 수탁자 책임을 별도로 입증해야 한다. 다음 장에서는 실제 상품과 계정, 운영 구조를 기준으로 고객 자산이 어떻게 통제되고 분리되는지 살펴본다.

 

3. 수탁 실행 구조

수탁 실행 구조는 법적 책임이 실제 운영에서 구현되는 방식이다. 디지털자산 수탁 사고는 대부분 이 층위에서 발생한다. 법적 지위가 있어도 출금 승인 정책이 허술하면 자산이 잘못 이동하고, 고객별 장부와 온체인 잔고가 맞지 않으면 도산 시 반환 범위가 흔들린다. 장외 정산을 쓰더라도 담보와 정산 실패 규칙이 불명확하면 거래소 예치 위험을 줄인 대신 새로운 상대방 위험이 생긴다.

3-1. 자산 이전 권한: 키관리와 서명 통제

첫째 요소는 키관리와 서명 통제다. 고객 자산을 실제로 누가 움직일 수 있는지를 정하는 영역이다. 키관리는 프라이빗 키를 생성하고, 보관하고, 거래에 서명하는 데 사용하고, 사고가 났을 때 복구하는 전 과정을 뜻한다. 프라이빗 키는 블록체인상 자산을 이전할 수 있게 해주는 전자적 서명 수단이다. 키를 가진 쪽이 자산을 옮길 수 있으므로, 키관리 구조는 보안 기능을 넘어 자산 통제권의 구조가 된다.

전통적인 키관리 방식으로는 HSM과 KMS가 오래 쓰여왔다. HSM은 Hardware Security Module의 약자로, 키를 전용 하드웨어 안에서 생성하고 보관하도록 만든 장비다. 키가 장비 밖으로 빠져나가지 않게 하는 데 강점이 있어 은행과 결제, 인증 시스템에서 널리 쓰였다. KMS는 Key Management Service의 약자로, 키의 생성, 접근 권한 부여, 사용 기록, 교체, 폐기 같은 키의 생명주기를 관리하는 시스템이다.

디지털자산 수탁에서는 여기에 더해 MPC가 중요한 방식으로 자리 잡았다. MPC는 Multi-Party Computation의 약자로, 하나의 완성된 키를 한곳에 두지 않고 여러 참여자가 나눠 가진 키 조각으로 서명을 만드는 방식이다. 서명할 때 각 참여자는 자기 조각만 쓰고, 완성된 키 전체가 한곳에 모이지 않는다. 이 구조는 키 하나가 통째로 탈취될 위험을 줄이고, 여러 승인자나 여러 시스템이 함께 서명해야 거래가 실행되도록 만들 수 있다.

다만 MPC를 쓴다는 사실만으로 수탁 구조의 성격이 정해지지는 않는다. 책임 구조를 가르는 것은 키 조각을 누가 보유하느냐다. 수탁기관이 모든 조각을 통제하면 고객이 자산 이전 권한을 수탁기관에 맡긴 수탁형이 된다. 고객과 수탁기관이 조각을 나눠 보유하면 공동통제형 또는 하이브리드형이 된다. 고객이 조각을 전적으로 보유하고 사업자는 소프트웨어만 제공하면 비수탁형 구조가 된다. 키 조각의 보유 주체가 불분명하면 사고가 났을 때 복구 권한과 책임 소재도 불분명해진다.

여기에 정책 엔진이 함께 작동해야 한다. 정책 엔진은 누가, 언제, 어떤 자산을, 어떤 주소로, 얼마까지 보낼 수 있는지를 미리 정해두고 거래 승인 과정에 적용하는 시스템이다. 예를 들어 일정 금액 이상 출금에는 두 명 이상의 승인을 요구하거나, 미리 등록한 주소 목록에 없는 곳으로는 출금을 막거나, 체인과 자산, 상대방에 따라 다른 승인 절차를 적용할 수 있다. 키가 자산을 움직이는 기술적 권한이라면, 정책 엔진은 그 권한이 조직 내부 규칙에 맞게만 쓰이도록 제한하는 운영 장치다.

이 구조가 중요한 이유는 블록체인 전송이 되돌리기 어렵기 때문이다. 잘못된 주소로 서명된 거래가 확정되면 회수가 어렵다. 그래서 키를 누가 가졌는가와 함께 어떤 조건에서 서명이 생성되는가를 봐야 한다. 키가 안전하게 보관되더라도 승인 정책이 허술하면 내부자의 오남용이나 잘못된 출금 지시를 막기 어렵다.

3-2. 자산 귀속과 반환 가능성: 고객자산 분리 구조

둘째 요소는 고객자산 분리 구조다. 고객이 맡긴 자산이 누구의 재산으로 남는지, 위기 상황에서 돌려받을 수 있는지를 정하는 영역이다. 고객자산 분리 구조는 고객이 맡긴 자산이 사업자의 고유 자산과 섞이지 않도록 만드는 장치이며, 법률 구조와 계정 구조, 지갑 구조, 장부 구조가 함께 맞아야 작동한다.

먼저 고객 자산의 법적 성격이 분명해야 한다. 고객이 자산을 맡긴 뒤에도 그 자산의 실질적 권리를 계속 갖는지, 수탁기관은 보관과 관리만 하는지, 수탁기관이 그 자산을 자기 목적에 쓸 수 있는지에 따라 위험이 달라진다. 수탁기관이 고객 자산을 대여하거나 담보로 잡거나 운용할 수 있다면, 고객은 보관 서비스를 쓰면서도 수탁기관의 신용위험과 운용위험까지 함께 떠안게 된다. 규제 체계가 고객 자산의 임의 사용과 재담보를 제한하는 이유가 여기에 있다.

다음으로 계정 구조가 중요하다. 고객마다 별도 지갑을 쓰는 방식이 있고, 여러 고객의 자산을 하나의 지갑이나 지갑 묶음에 모아두되 내부 장부로 고객별 잔고를 구분하는 방식이 있다. 앞을 개별 지갑 구조, 뒤를 옴니버스 구조라 부른다. 개별 지갑 구조는 고객별 자산을 식별하기 쉽지만 운영 비용과 주소 관리 부담이 커진다. 옴니버스 구조는 운영이 효율적이지만 내부 장부와 온체인 잔고가 어긋나지 않도록 엄격히 관리해야 한다.

옴니버스 구조에서 중요한 것은 온체인 총량과 내부 장부상 고객별 권리가 맞아야 한다는 점이다. 하나의 온체인 주소에 여러 고객 자산이 함께 들어가 있으면 외부에서는 합산 잔고만 보인다. 이때 내부 장부가 틀어지면 특정 고객에게 얼마를 돌려줘야 하는지 불분명해질 수 있다. 반대로 내부 장부상 고객별 잔고는 맞아 보여도 실제 지갑 잔고가 부족하면 수탁기관이 실제로 자산을 갖고 있는지가 문제 된다. 내부 장부의 고객별 잔고와 실제 온체인 잔고를 비교해 맞추는 절차를 대사라 하며, 분리 구조에서 대사가 중요한 이유가 여기에 있다.

지갑 운영 방식도 보호 수준에 영향을 준다. 콜드월렛은 인터넷과 분리된 환경에서 키를 보관하는 지갑이고, 핫월렛은 입출금 처리를 위해 온라인에 연결된 지갑이다. 기관 수탁에서는 출금 수요와 거래 빈도, 보안 기준, 규제 요건에 따라 두 방식을 조합한다. 이때 중요한 것은 콜드월렛 비율 자체보다 어떤 자산이 어느 지갑에 있고, 그 지갑의 서명 권한이 누구에게 있으며, 내부 장부와 얼마나 자주 대사되는지다.

서브커스터디도 확인해야 한다. 서브커스터디는 수탁기관이 고객 자산의 보관이나 운영 일부를 다른 수탁기관이나 인프라 제공자에게 맡기는 구조다. 이 경우 고객이 계약한 수탁기관과 실제 키를 통제하는 주체가 달라질 수 있다. 해킹, 출금 중단, 회계 오류, 수탁기관 도산이 발생하면 법률 구조와 지갑 분리, 대사 주기, 서브커스터디 여부가 고객의 반환 가능성을 결정한다.

3-3. 거래 중 자산 노출: 담보·정산 구조

셋째 요소는 담보·정산 구조다. 거래 과정에서 고객 자산이 어디에 머물고 어떤 상대방 위험에 노출되는지, 거래 결과를 어떻게 확정하고 정산하는지를 정하는 영역이다. 여기서 담보는 거래소가 거래 한도를 내주거나 포지션 손실에 대비해 요구하는 자산이고, 정산은 거래 결과에 따라 누가 누구에게 얼마를 보내야 하는지 확정하고 실행하는 절차다.

기관투자자가 디지털자산을 거래할 때 가장 익숙한 방식은 사전 예치, 곧 프리펀딩이다. 매매를 위해 자산을 거래소에 미리 보내두는 것이다. 이 방식은 단순하지만, 거래소가 해킹되거나 지급불능에 빠지거나 출금을 막으면 투자자가 매매와 직접 관계없는 예치 위험까지 떠안는다.

이 예치 위험을 줄이는 대표적 해법이 OES다. OES는 Off-Exchange Settlement의 약자로, 자산을 거래소에 직접 예치하지 않고도 거래소 유동성에 접근해 거래 결과를 정산하는 구조다. OES에서는 고객 자산이 수탁기관이나 별도 담보 지갑에 머물고, 거래소에는 담보 배정이나 거래 한도 정보만 전달된다. 거래가 체결되면 미리 정한 주기나 조건에 따라 손익과 담보, 최종 정산 금액이 처리된다.

담보·정산 구조를 볼 때는 세 가지를 확인하면 된다. 첫째, 고객 자산이 거래소 지갑으로 이동하는지, 수탁기관 지갑에 남아 있는지다. 둘째, 거래소가 그 자산에 대해 어떤 권리를 갖는지다. 거래 한도만 확인하는 구조인지, 손실이 발생했을 때 담보 이전이나 청산을 요구할 수 있는 구조인지에 따라 고객 자산의 위험이 달라진다. 셋째, 거래가 끝난 뒤 손익을 언제 정산하고, 정산이 실패하면 어떤 절차가 작동하는지다.

OES는 이 세 가지를 거래소 예치 방식과 다르게 설계하려는 구조다. 고객 자산을 거래소에 계속 맡겨두지 않고 수탁기관 안에 두면서 거래 한도와 정산만 연결한다. 다만 OES를 쓴다고 위험이 사라지는 것은 아니다. 담보 재사용이 허용되는지, 거래소와 수탁기관 사이의 정산 실패가 어떻게 처리되는지에 따라 고객이 부담하는 위험은 달라진다.

OES를 쓰는 대표 사례로 Copper ClearLoop, BitGo Go Network, Anchorage Atlas, Zodia Interchange, Komainu Connect가 있다. 이들은 거래소 예치 위험을 줄이려는 목적은 같지만, 신탁 구조, qualified custody, 기관 간 정산 네트워크처럼 서로 다른 법적 장치를 쓴다. 4장에서는 이 차이를 벤더별로 비교한다.

3-4. 정리

수탁 실행 구조는 키관리, 고객자산 분리, 담보·정산으로 나뉜다. 키관리는 고객 자산을 움직일 권한을, 고객자산 분리는 자산의 귀속과 반환 가능성을, 담보·정산은 거래 과정에서 발생하는 노출을 다룬다. 다음 장에서는 이 세 요소를 기준으로 벤더별 차이를 비교한다.

 

4. 벤더 비교: 수탁 지위와 실행 구조

앞에서 본 두 층위를 벤더에 적용하는 순서는 단순하다. 먼저 그 벤더가 수탁 지위를 직접 보유하는지를 본다. 보유하면 고객 자산의 최종 수탁 책임을 직접 지는 규제 수탁기관이고, 보유하지 않은 채 키관리와 지갑 운영 도구만 제공하면 기관이 자체 운영체계를 구축하도록 돕는 기술 인프라다. 수탁 지위가 유형을 가르는 일차 기준이고, 실행 구조의 세 구성요소는 유형을 가르는 기준이 아니라 같은 유형 안에서 벤더가 어떻게 다른지를 보여준다. 두 유형 어디에도 깔끔히 들어맞지 않는 사업자는 마지막 절에서 따로 짚는다.

이 장은 특정 벤더를 추천하지 않는다. 같은 커스터디 시장 안에 있는 사업자들이 법적 책임과 실행 구조에서 어떻게 다른지를 정리하는 것이 목적이다. 임베디드 지갑이나 사용자 온보딩에 가까운 벤더, 예컨대 Privy나 Web3Auth는 별도 지갑 인프라 리서치에서 다루는 편이 자연스러워 여기서는 제외한다.

4-1. 규제 수탁기관

규제 수탁기관은 수탁 지위를 직접 부담하면서 키관리와 자산분리, 담보·정산을 자체 제공하는 벤더다. 비교의 출발점은 고객 자산이 어떤 법인과 어떤 인가 아래 보관되는가다. 2025년 12월 OCC가 BitGo와 Fidelity Digital Assets의 주 신탁회사를 national trust bank로 전환 승인하고 Ripple과 Circle에 신규 인가를 내주면서, 미국에서는 규제 수탁기관이 연방 신탁은행 지위로 수렴하는 흐름이 뚜렷하다. 다만 Coinbase의 신청은 이 명단에 들지 않아 Coinbase Custody는 여전히 뉴욕 신탁회사 지위로 운영되고, Gemini Trust Company도 뉴욕 banking law상 limited purpose trust 차터를 보유한 qualified custodian으로 2025년 9월 나스닥에 상장했다.

출신과 지역으로 보면 결이 갈린다. Zodia Custody, Komainu, Sygnum Bank는 전통 금융기관 또는 규제 금융기관의 문법으로 디지털자산 수탁을 제공한다. Anchorage Digital, BitGo, Coinbase Custody, Gemini Trust Company, Fidelity Digital Assets, Fireblocks Trust Company는 미국 신탁, national trust bank, NYDFS 신탁회사 같은 포지션으로 기관 고객의 수탁 요건을 설명한다. Hex Trust는 홍콩·싱가포르·두바이 등 아시아·중동 규제 허브를 중심으로 성장한 지역 특화 수탁기관이고, Copper는 은행 차터 없이 영국 FCA에 등록된 규제 MPC 수탁기관이다.

같은 규제 수탁기관 안에서도 실행 방식은 갈린다. 키관리는 Anchorage의 HSM·생체인증부터 BitGo의 멀티시그·MPC, Fireblocks Trust·Sygnum·Copper의 MPC, Komainu의 MPC·HSM 선택형까지 나뉘고, 자산분리도 옴니버스 장부와 온체인 개별 분리로 갈린다.

담보·정산에서 가장 큰 차이는 OES 제공 여부다. Anchorage Atlas, BitGo Go Network, Zodia Interchange, Komainu Connect, Copper ClearLoop, 그리고 Fidelity의 Collateral Account Suite는 거래소에 자산을 예치하지 않고 정산하는 OES를 제공하는 반면, Gemini, Fireblocks Trust Company, Hex Trust는 OES를 별도 제공하지 않아 거래 시 프리펀딩 등 다른 방식에 기댄다. Coinbase는 수탁·거래·프라임을 수직통합해 자체 생태계 안에서, Sygnum은 Sygnum Connect라는 정산 네트워크로 결제를 처리해 둘 다 외부 거래소를 상대로 한 OES와는 결이 다르다.

OES를 제공하는 경우에도 쓰는 법적 장치가 다르다. Copper ClearLoop은 전용 계정에 English Law Trust를 설정하고 Copper가 보안 수탁자로 자산을 보유해 파산 절연을 만들며 담보가 Copper 수탁을 떠나지 않는 반면, BitGo의 Go Account는 신탁이 아니라 BitGo의 수탁 지위와 오프체인 장부 위에서 정산을 처리한다. 그래서 OES는 3-3에서 정리한 기준, 곧 자산이 어디에 머무는지, 거래소가 담보에 어떤 권리를 갖는지, 정산 주기와 실패 처리가 어떤지로 비교해야 한다.

또한 같은 브랜드도 수탁 법인과 거래·기술 법인으로 나뉜다. Coinbase Custody와 Coinbase Prime, Fireblocks Trust Company와 Fireblocks Platform이 그 예이며, 표는 브랜드가 아니라 법인 단위로 읽어야 한다.

4-2. 기술 인프라

기술 인프라는 수탁 지위 없이, 기관이 직접 키관리와 지갑 운영 체계를 구축할 때 쓰는 도구를 제공하는 벤더다. 이들은 최종 수탁기관이 아니므로 2b 자산분리와 2c 담보·정산은 대체로 그 인프라를 쓰는 기관이 직접 설계하며, OES는 수탁을 전제하므로 자체 제공할 수 없다. 따라서 비교 기준은 인가 지위가 아니라 키 조각을 누가 보유하는지, 서명 승인과 복구 권한이 어떻게 설계되는지다.

키관리 방식부터 서로 다르다. Fireblocks Platform은 MPC-CMP로 키 조각을 고객·Fireblocks 인프라·독립 복구 파트너에 분산하고, Turnkey는 AWS Nitro Enclaves 같은 TEE 안에서 완성된 키가 밖으로 나가지 않는 비수탁 방식을 쓴다. Dfns는 키를 MPC 노드에 분산하고 키 조각을 HSM·enclave·온프렘에 보관하는 선택지를 제공하며, GK8은 인터넷에 연결되지 않는 에어갭 콜드 볼트와 고빈도 거래용 MPC 지갑을 결합하고, Taurus-PROTECT는 Thales HSM 기반에 MPC를 더해 은행용 수탁·토큰화 인프라를 제공한다.

여기서 Fireblocks Platform은 이 표의 기술 인프라로, 4-1의 Fireblocks Trust Company와는 다른 법인이다. 키관리 도구를 강력하게 제공한다는 사실과 고객 자산을 법적으로 수탁한다는 것은 다른 층위의 문제다.

4-3. 표에 넣지 않은 벤더

앞의 두 표는 디지털자산 수탁의 실행 구조를 직접 제공하거나 그 도구를 파는 벤더를 담았다. 여기서는 그 표에 넣지 않았지만 기관이 커스터디를 설계할 때 마주치는 두 부류를 짚는다. 표에서 빠진 이유 자체가 두 층위 틀이 무엇을 묶고 무엇을 가르는지를 거꾸로 보여준다.

범용 KMS인 AWS KMS, Google Cloud KMS, HashiCorp Vault는 키와 시크릿을 생성하고 보관하고 접근을 통제하는 일반 인프라다. 3-1에서 본 KMS의 정의, 곧 키의 생성·접근·교체·폐기라는 생명주기 관리에 해당하므로 실행 구조의 2a 키관리는 제공한다. 그러나 이들은 디지털자산 전용이 아니다. 온체인 이전 권한을 통제하는 정책 엔진, 고객 자산을 사업자 자산과 가르는 2b 자산분리, 거래 중 노출을 다루는 2c 담보·정산은 제공하지 않는다. 그래서 범용 KMS는 그 자체로 수탁 솔루션이 아니라 기관이 자체 수탁 체계를 구축할 때 키관리 백엔드로 끼워 넣는 구성요소이며, 실제로 Dfns 같은 인프라가 이런 KMS를 키 저장 계층으로 활용한다. 표에 들어가지 않는 이유는 기능이 부족해서가 아니라 채우는 자리가 세 구성요소 중 2a 하나뿐이기 때문이다.

Fuze는 VARA에서 Custody Services가 아니라 Broker-Dealer Services 인가를 받은 VASP로, 은행·핀테크가 디지털자산 상품을 자사 앱에 임베드하도록 돕는 B2B2C 인프라다. 수탁 기능은 자체 제공하지 않고 Hex Trust 같은 규제 수탁기관과의 파트너십으로 결합한다. Fuze가 표에 들어가지 않는 이유는 범용 KMS와 다르다. 범용 KMS는 실행 구조의 한 구성요소라도 제공하지만, Fuze는 수탁 지위도 실행 구조도 자체로 갖지 않고 양쪽을 모두 외부 수탁기관에 맡긴 채 접근과 유통만 담당한다. 따라서 Fuze는 두 유형 어디에도 속하지 않는 접근·유통 레이어로 따로 본다.

4-4. 비교 결과 요약

같은 커스터디 시장의 벤더들도 서로 다른 문제를 푼다. 벤더를 가르는 일차 기준은 수탁 지위이고, 고객 자산의 법적 책임을 직접 지는 규제 수탁기관과 그 책임 없이 키관리·지갑 운영 도구만 제공하는 기술 인프라는 애초에 다른 일을 한다. 그 위에서 같은 유형의 벤더를 구분하는 것이 실행 구조의 세 구성요소다. 규제 수탁기관들은 같은 수탁 지위를 갖지만 키관리는 HSM·생체인증부터 멀티시그·MPC·에어갭 콜드까지, 자산분리는 옴니버스와 온체인 개별 분리로, 담보·정산은 OES 제공 여부와 그 법적 장치로 갈린다. 결국 벤더 비교는 브랜드를 고르는 일이 아니라, 수탁 지위로 큰 갈래를 나눈 뒤 키관리·자산분리·담보·정산이라는 세 구성요소로 어느 벤더가 어느 문제를 어떻게 푸는지 확인하는 일이다.

 

5. 결론

디지털자산 커스터디는 법적 수탁 책임, 키관리, 지갑 운영, 고객자산 분리, 거래소 연결, 담보·정산 구조가 결합된 인프라다. 전통 금융에서 커스터디가 보관과 결제, 장부 관리, 권리 행사를 지원했다면, 디지털자산에서는 여기에 암호화 키와 온체인 지갑 통제, 출금 승인 정책, 거래소 예치 위험 관리가 더해진다.

기관이 커스터디를 검토할 때는 먼저 고객 자산에 대한 법적 책임을 누구에게 맡길지 정해야 한다. 외부 수탁기관에 맡길 것인지, 자체 인프라를 구축할 것인지, 수탁기관과 기술 인프라를 조합할 것인지가 첫 번째 판단이다. 이 단계에서 national trust bank, 뉴욕 신탁회사, qualified custodian, VASP, CASP 같은 지위가 의미를 가진다. 다만 각 명칭이 모두 같은 수준의 수탁 책임을 뜻하지는 않으므로, 고객 자산을 실제로 맡는 법인과 그 법인의 감독 체계를 확인해야 한다.

그다음에는 실행 구조를 봐야 한다. 자산 이전 권한을 누가 통제하는지, 고객 자산이 회사 자산과 어떻게 분리되는지, 거래소 예치 위험과 담보·정산 구조를 어떻게 관리하는지가 실무상 더 큰 차이를 만든다. 같은 수탁 지위를 보유한 벤더라도 HSM을 쓰는지 MPC를 쓰는지, 개별 지갑을 쓰는지 옴니버스 장부를 쓰는지, OES를 제공하는지 프리펀딩에 의존하는지에 따라 위험 구조가 달라진다.

국내 기관에도 같은 시사점이 있다. 해외 벤더의 라이선스 명칭만 볼 것이 아니라, 그 라이선스가 어떤 수탁 책임을 의미하는지, 고객 자산이 어떤 구조로 분리되는지, 키와 승인 권한이 누구에게 있는지, 거래 과정에서 자산이 어디에 머무는지를 함께 봐야 한다. 디지털자산 커스터디는 특정 벤더명을 고르는 문제가 아니라, 자산의 법적 귀속과 이전 권한, 운영 통제, 정산 위험을 어떤 구조로 배치할지 정하는 문제다.

이 때문에 기관용 커스터디 시장은 단일 승자가 모든 기능을 대체하는 방향으로만 전개되기 어렵다. 규제 수탁기관, 커스터디 운영 인프라, 거래·정산 네트워크, 지갑·KMS 기술은 서로 다른 역할을 맡고 조합될 가능성이 크다. 커스터디 벤더 비교도 그 구조를 분해해 보는 데서 출발해야 한다.