Image

수십억 원대의 디지털 자산을 관리하는 기관 투자자와 펀드 매니저는 일반 사용자와 다른 보안 요구사항을 마주한다. 개인 투자자는 자신의 시드 구문 하나를 안전하게 보관하면 되지만, 기관은 여러 관리자가 자산에 접근해야 하는 동시에 무단 거래를 방지해야 한다. 또한 규정 준수 감시, 거래 기록 추적, 긴급 상황에서의 자산 동결 능력이 필수적이다.

Phantom Wallet은 멀티체인 비수탁형 지갑으로서 Solana, Ethereum, Polygon, Bitcoin을 지원하며, 브라우저 확장 프로그램과 모바일 앱으로 제공된다. 개인 키가 기기 내에 암호화되어 저장되고 외부 서버로 전송되지 않는다는 점에서 높은 수준의 통제권을 제공한다. 하지만 이 구조는 기관 규모의 운영을 염두에 두고 설계되지 않았다. 기관이 Phantom Wallet을 엔터프라이즈 환경에서 운영하려면 다중 서명, 접근 통제, 감사 로그 같은 추가 계층을 어떻게 구현할 수 있는지 이해해야 한다.

Phantom Wallet 엔터프라이즈 환경의 다중 서명 및 접근 통제 설정 인터페이스

비수탁형 지갑의 기관 운영 문제

기관이 중앙화된 거래소에서 자산을 보관하면 관리 편의성은 높지만 소유권 통제를 포기하게 된다. 거래소 서버에 개인 키가 저장되고, 기관은 고객으로서 플랫폼의 정책에 종속된다. 동결, 제재, 해킹, 내부자 거래 같은 리스크에 노출된다. 반대로 비수탁형 지갑은 개인 키를 기관이 직접 관리하게 함으로써 이런 위험을 제거한다. 하지만 직접 관리라는 것은 직접 책임을 의미한다.

일반적인 비수탁형 지갑에서 자산은 하나의 개인 키 또는 시드 구문으로만 통제된다. 펀드 매니저 A가 거래를 승인하면 즉시 실행되고, 기록할 방법이 없으며, 실수를 되돌릴 수 없다. 수십억 원의 자산을 움직일 때 이는 용인 불가능한 위험이다. 기관은 최소한 두 명 이상의 승인자가 필요하고, 모든 거래의 감시 추적을 원한다. Phantom cryptocurrency wallet이 비수탁형 지갑으로서 이런 기능을 어떻게 수용할 수 있는지가 문제다.

Phantom Wallet은 본래 개인 사용자를 대상으로 설계되었으므로, 기관 요구사항을 충족하려면 추가적인 기술 아키텍처가 필요하다. 기관은 Phantom 지갑 자체에만 의존할 수 없으며, 그 위에 거버넌스 계층을 구축해야 한다. 이것이 엔터프라이즈 보안 설정의 핵심이다. 기관은 개인 키의 통제권을 유지하면서도 접근 권한, 승인 프로세스, 감시 능력을 추가해야 한다.

다중 서명 구조의 설계 및 구현

다중 서명은 하나의 거래가 실행되기 전에 여러 당사자의 동의를 요구하는 기법이다. 예를 들어 3개 중 2개(2-of-3) 구조에서는 세 명의 관리자 중 두 명이 거래에 서명해야 한다. 한 명의 서명은 충분하지 않고, 한 명의 개인 키가 도용되어도 자산은 안전하다.

Phantom Wallet 자체는 기본적으로 단일 개인 키 구조를 제공하므로, 기관은 스마트 컨트랙트 기반 다중 서명 지갑을 별도로 구성해야 한다. Solana 기반 기관은 Squads, Realms, Gnosis Safe 같은 다중 서명 프로토콜을 활용할 수 있다. Ethereum 기반 기관은 Gnosis Safe, Safe{wallet}을 직접 사용할 수 있다. 이런 프로토콜은 블록체인 상의 스마트 컨트랙트로 구현되므로, 거래 승인 로직이 투명하고 변경 불가능하게 작동한다.

구체적인 구현 방식은 다음과 같다. 기관은 먼저 Phantom Wallet으로 관리자별 지갑을 생성한다. 예를 들어 CFO용, CTO용, 법무담당자용 지갑을 각각 만든다. 그다음 다중 서명 스마트 컨트랙트에 이 세 지갑의 주소를 등록한다. 실제 자산은 다중 서명 컨트랙트 주소에 보관되고, 거래 승인은 정해진 수의 서명이 수집될 때까지 보류된다. 각 관리자는 자신의 Phantom Wallet으로 승인 트랜잭션에 서명하며, 이는 블록체인에 불변적으로 기록된다.

다중 서명 구조 선택 시 세부 고려사항이 있다. M-of-N 비율이 높을수록 승인이 어렵고 느려지지만 보안이 높다. 가장 엄격한 설정은 전수동의(unanimous approval)이지만, 이는 한 명의 거부 또는 불가능성이 모든 거래를 막을 수 있다. 일반적인 기관은 3-of-5 또는 2-of-3 같은 중간 수준을 선택한다. 타임락(timelock) 기능도 중요하다. 거래가 승인되었어도 24시간 또는 48시간 후에야 실행되도록 설정하면, 승인자가 오류를 발견하고 거래를 취소할 기회를 제공한다.

역할 기반 접근 통제 시스템 구축

거래 승인 외에도 지갑에 접근할 수 있는 권한을 단계적으로 제한해야 한다. 모든 직원이 모든 관리자 지갑에 접근하면 안 되고, 부서별로 필요한 권한만 부여해야 한다. 기관 보안의 기본 원칙은 최소 권한(principle of least privilege)이다.

기관이 구현할 수 있는 접근 통제 모델은 다음과 같다. 우선 역할을 정의한다. 예를 들어 스테이킹 관리자는 스테이킹 트랜잭션을 제안할 수 있지만, 인출(withdrawal)은 제안할 수 없다. 기금 운용 담당자는 특정 토큰의 매매만 승인하고, 관리자는 정책 변경과 승인자 추가 같은 고수준 결정만 할 수 있다. 이런 역할은 운영 문서에만 기록되어서는 안 되고, 기술적으로 강제되어야 한다.

스마트 컨트랙트는 호출자의 주소와 함수를 확인하여 권한을 검증한다. 예를 들어 Solana의 경우 다중 서명 프로토콜이 트랜잭션 제안자, 승인자, 실행자를 추적하고, 각 역할에 허용된 작업을 제한한다. 이는 내부 감시 체크리스트가 아니라 블록체인 상의 강제되는 규칙이므로, 이를 우회할 수 없다. 권한이 없는 직원이 지갑에 실제로 접근할 수 있더라도 기술적으로는 특정 거래를 서명할 수 없다.

실무적으로는 Phantom Wallet의 하드웨어 지갑 연동 기능도 이 계층에 포함된다. 각 관리자의 개인 키를 Ledger 하드웨어 지갑에 저장하고, Phantom을 통해서만 트랜잭션에 서명하도록 한다. 하드웨어 지갑은 물리적으로 분리된 기기이므로, 컴퓨터 해킹에도 개인 키가 노출되지 않는다. 또한 하드웨어 지갑의 디스플레이에서 거래 세부사항을 직접 확인할 수 있으므로, 악의적인 소프트웨어가 수신자 주소를 몰래 바꾸는 공격으로부터 보호된다.

거래 감시 및 감사 로그 시스템

기관은 과거에 어떤 거래가 실행되었는지, 누가 승인했는지, 언제 일어났는지를 모두 추적할 수 있어야 한다. 암호화폐 거래는 블록체인에 공개적으로 기록되지만, 기관이 자신의 맥락에서 이를 수집, 정리, 분석할 체계가 필요하다. 이것이 감사 로그다.

블록체인 자체가 불변적 기록을 제공하므로, 기관은 주기적으로 자신의 지갑 주소와 다중 서명 컨트랙트 주소의 트랜잭션 히스토리를 수집해야 한다. 공개 RPC 노드 또는 블록 익스플로러 API를 통해 모든 거래를 조회할 수 있다. 트랜잭션 해시, 시간, 보낸 주소, 받은 주소, 금액, 가스비, 상태(성공 또는 실패)가 모두 기록된다. 기관은 이 데이터를 자신의 내부 데이터베이스로 수입하여 정기적으로 검증해야 한다.

추가로 중요한 것은 오프체인 로그다. 각 거래가 제안되었을 때, 누가 제안했는지, 어떤 승인자들이 서명했는지, 최종 실행은 누가 했는지를 기록해야 한다. 이 정보는 블록체인에 직접 저장되지 않으므로, 기관이 자신의 시스템에서 추적해야 한다. 많은 다중 서명 프로토콜(예: Squads, Gnosis Safe)은 제안 및 승인 이벤트를 로그하는 기능을 제공한다. 기관은 이 이벤트를 파싱하여 중앙 감사 대시보드에 수집할 수 있다.

감시 시스템의 실용적 구현은 다음과 같다. 기관은 매일 또는 매주 자동화된 스크립트를 실행하여 지갑의 모든 트랜잭션을 검색한다. 각 거래와 승인 기록을 내부 Excel, SQL 데이터베이스, 또는 감사 소프트웨어에 입력한다. 이상 거래(예: 예상 범위를 벗어난 금액, 승인자가 없는 거래, 허용되지 않은 주소로의 송금)는 자동으로 경고한다. 정기적으로 (분기별 또는 반기별) 감시 관리자가 로그를 검토하고 경영진에 보고한다.

개인 키 보관 및 복구 절차

엔터프라이즈 환경에서 시드 구문 관리는 특히 신중해야 한다. Phantom Wallet을 설치할 때 생성되는 12개 또는 24개 단어의 시드 구문은 해당 지갑의 모든 자산에 대한 완전한 통제를 부여한다. 한 명의 관리자가 시드 구문을 도용하면 기관의 자산 전부를 빼낼 수 있다. 따라서 시드 구문은 개인이 보관하면 안 되고, 기관 차원의 보안 인프라 내에 저장되어야 한다.

일반적인 기관 접근은 비밀 공유(secret sharing)를 사용하는 것이다. Shamir Secret Sharing(SSS) 또는 유사한 암호화 기법을 사용하여 시드 구문을 여러 조각으로 나눈다. 예를 들어 하나의 시드 구문을 5개의 조각으로 나누되, 그중 3개 이상이 있어야만 원래 시드를 복원할 수 있도록 한다. 각 조각을 서로 다른 사람과 서로 다른 장소(예: 금고, 은행, 감시 기관)에 보관한다. 이렇게 하면 3명 이상의 사람이 공모하지 않는 한 아무도 시드 구문을 복원할 수 없다.

하드웨어 지갑 사용은 이 위험을 더 줄인다. Ledger 같은 하드웨어 지갑의 시드 구문은 기기 내부에만 저장되고, 절대 외부로 노출되지 않는다. 기관이 관리자 개인 키를 하드웨어 지갑에 저장하면, 거래 승인을 위해서는 물리적 기기가 필요하다. 컴퓨터 해킹으로는 개인 키를 추출할 수 없고, 기기를 분실해도 별도로 백업한 시드 구문이 있으면 복구할 수 있다. 백업 시드는 보안 금고나 비밀 공유 방식으로 별도 보관한다.

복구 절차도 미리 계획되어야 한다. 만약 한 명의 관리자가 직무를 잃거나 개인 키를 잃어버리면 어떻게 하는가? 다중 서명 구조라면 나머지 승인자들이 계속 거래할 수 있으므로 자산이 동결되지 않는다. 하지만 권장되는 절차는 새로운 승인자를 추가하고 퇴직 승인자를 제거하는 것이다. 이는 다중 서명 스마트 컨트랙트의 승인자 목록을 수정하는 거버넌스 거래다. 시간 지연과 상위 승인이 필요하도록 설정하여 실수를 방지할 수 있다.

규정 준수와 감사 대비

암호화폐를 다루는 기관은 금융 감시, 자금 세탁 방지(AML), 테러 자금 조달 방지(CFT) 규제를 준수해야 할 수 있다. 관할권에 따라 암호화폐 보관자, 거래업자, 자산 운용업자로 분류되고 각각 다른 규정을 따르게 된다. 규제 당국은 기관이 자산의 출처를 확인할 수 있는지, 거래를 기록하고 보고할 수 있는지를 검증한다.

Phantom Wallet 같은 비수탁형 지갑은 본질적으로 중립적이므로, 기관이 규정 준수를 직접 구현해야 한다. 여기서 감사 로그가 중요하다. 기관은 정기적으로 지갑의 모든 거래를 내부 컴플라이언스 팀에 제출하고, 거래의 합법성을 확인해야 한다. 의심거래가 발견되면 보고 의무가 생길 수 있다. 또한 지갑의 잔액 변화, 스테이킹 보상, 토큰 에어드롭 같은 모든 자산 변동을 추적해야 한다.

감시 대비 측면에서 기관은 자신의 지갑이 제재 대상 주소와 거래하지 않았음을 증명할 수 있어야 한다. 미국의 OFAC(Office of Foreign Assets Control) 제재 목록, 유럽의 제재 대상자 목록 등을 정기적으로 확인하고, 자신의 거래 상대방이 목록에 있는지 조회해야 한다. 블록체인 분석 회사들(예: Chainalysis, Elliptic)은 주소의 위험 수준을 평가하는 서비스를 제공한다. 기관은 이런 도구를 사용하여 거래 상대방을 검증할 수 있다.

운영 효율성과 보안의 균형

강력한 엔터프라이즈 보안 설정은 운영을 복잡하게 만든다. 거래마다 여러 승인자의 서명이 필요하고, 감사 기록을 관리해야 하고, 규정 준수를 증명해야 한다. 이 과정이 너무 느리면 기관의 투자 기회를 놓칠 수 있다. 따라서 보안과 속도의 균형을 맞춰야 한다.

실무적 전략은 거래 규모와 유형에 따라 다른 승인 프로세스를 설정하는 것이다. 예를 들어 $10,000 이하의 거래는 한 명의 승인자만 필요하지만, $1,000,000 이상의 거래는 3명의 승인자가 필요하도록 한다. 일상적인 스테이킹 작업은 간단한 다중 서명으로, 대규모 자산 이동은 더 엄격한 절차로 처리한다. 이는 스마트 컨트랙트 내에 임계값(threshold)을 설정하여 자동 강제된다.

또 다른 효율성 개선 방법은 권한 위임이다. 경영진이 모든 거래를 직접 승인할 필요는 없다. 거래 담당자는 일정 한도 내에서 자동 승인을 받을 수 있고, 초과분은 경영진 승인이 필요하도록 한다. 다만 이 한도도 기술적으로 강제되어야 하며, 감시 기록에 남아야 한다. 이렇게 하면 기관은 일상 운영의 민첩성을 유지하면서도 위험 통제를 잃지 않는다.

기술 아키텍처의 실제 구성

이상 모든 보안 계층을 구현하기 위한 구체적인 기술 스택을 정리하면 다음과 같다. 첫 번째 계층은 Phantom Wallet 자체다. 각 관리자가 자신의 Phantom 지갑을 설치하고, 하드웨어 지갑(Ledger)과 연동한다. 개인 키는 하드웨어 기기 내에 저장되고, Phantom은 거래 서명을 위한 인터페이스 역할만 한다.

두 번째 계층은 다중 서명 스마트 컨트랙트다. Solana 기반이면 Squads, Realms 또는 Marinade 같은 프로토콜을 사용한다. Ethereum 기반이면 Gnosis Safe를 사용한다. 이 컨트랙트에 다수의 관리자 주소를 등록하고, M-of-N 승인 규칙을 설정한다. 실제 자산(토큰, NFT, 스테이킹된 자산)은 이 컨트랙트 주소에 보관된다.

세 번째 계층은 모니터링 및 감시 시스템이다. 자동화된 스크립트가 정기적으로 블록체인을 조회하여 지갑의 모든 거래를 수집한다. 거래 데이터는 내부 데이터베이스 또는 감시 소프트웨어(예: Nansen, Arkham Intelligence, 자체 구축 시스템)에 저장된다. 이 시스템은 이상 거래를 탐지하고 경고를 발송한다.

네 번째 계층은 거버넌스 문서다. 거래 승인 정책, 역할 정의, 시드 구문 보관 절차, 복구 계획, 규정 준수 체크리스트가 문서화되어 있어야 한다. 기술만으로는 부족하고, 조직 절차와 일치해야 한다. 정기적인 감시 검증, 충격 테스트(위기 시나리오 시뮬레이션), 권한 재검증이 필수다.

자주 묻는 질문

Phantom Wallet 자체가 다중 서명을 지원하지 않는데, 어떻게 기관 수준의 승인 구조를 만들 수 있나?

Phantom Wallet은 개인 사용자 중심으로 설계되었으므로 기본 기능에 다중 서명이 없다. 기관은 Phantom을 거래 서명 도구로만 사용하고, 실제 자산은 Squads(Solana), Gnosis Safe(Ethereum) 같은 블록체인 기반 다중 서명 스마트 컨트랙트에 보관해야 한다. 관리자들이 각자 Phantom 지갑으로 스마트 컨트랙트의 거래에 서명한다.

블록체인 거래는 누구나 볼 수 있는데, 이것이 규정 준수 감시에 영향을 주나?

블록체인 거래의 공개성 자체는 감시를 어렵게 하지 않는다. 오히려 역이다. 모든 거래가 불변적으로 기록되므로 기관은 자신의 거래 히스토리를 완전하게 증명할 수 있다. 규제 당국이 거래를 감시할 수 있다는 점도 투명성을 강화한다. 기관이 해야 할 일은 블록체인 기록과 자신의 내부 로그를 일치시키고, 거래의 합법성을 문서화하는 것이다.

하드웨어 지갑과 비수탁형 지갑을 함께 사용하면, 기관 자산이 완전히 안전한가?

기술 수준의 보안성은 매우 높지만, 완전히 안전하다고 할 수는 없다. 개인 키가 물리적 기기에 격리되므로 소프트웨어 해킹으로부터는 보호된다. 그러나 내부자 위협(관리자의 배신), 물리적 도난, 사회 공학(거래 승인을 강압), 시드 구문 노출 같은 위험은 남아 있다. 따라서 기술 보안 외에도 조직 내부 통제, 직원 신원 조사, 역할 분리, 정기 감시, 보험이 필요하다.

\n\n\n