수탁형 콜드 월렛 아키텍처 (Custodial Cold Wallet Architecture)

작성일: 2026-04-17
본 아키텍처는 Fireblocks Cold Wallet 플랫폼을 기반으로 한 수탁형(custodial) 가상자산 관리 서비스의 참조 설계입니다.
기반 리서치:
- Fireblocks Cold Wallet 리서치
- KISA 가상자산 이용자 보호법 리서치
- 규제-Fireblocks 매핑
- Fireblocks 공식 문서 15종 한글 번역

1. 설계 원칙 (Design Principles)

3. 워크스페이스 구조

📘 상세: docs/01

3.1 W-OPS (운영 워크스페이스, Hot + Warm)

3.2 W-COLD (수탁 워크스페이스, Cold-only)

3.3 워크스페이스 간 통신

• P2P Network 연결 사전 등록 (핫 환경에서 먼저 프로필 설정 → Cold 연결)
• Admin Quorum 승인 양측에서 필요
• 자금 이동 시 별도 온체인 전송 없이 네트워크 내부 라우팅 사용
• 유연한 라우팅(flexible routing) — 콜드 워크스페이스에서 Early Availability (CSM 활성화 필요)

4. Vault 구조 — 고객별 Segregated

W-COLD (수탁 워크스페이스)
├── Vault: customer-00001/
│   ├── BTC 주소 · 키 쉐어
│   ├── ETH 주소 · 키 쉐어
│   └── USDC(ERC20) 주소 · 키 쉐어
├── Vault: customer-00002/
│   └── ...
├── Vault: customer-N/
│   └── ...
└── Vault: internal-reserve/    ← 회사 자금 (Omnibus 허용)

핵심:
- 고객별 독립 Vault Account = 독립 온체인 주소 = 독립 키 쉐어
- 고객 자산과 회사 자산 절대 혼합 금지
- 고객 자산 간에도 혼합 금지 (Omnibus 금지)
- 내부 운영 자금(유동성, 수수료 수령 등)만 Omnibus 형태 허용

5. 역할 및 거버넌스

📘 상세: docs/04 · docs/13

5.1 W-COLD 역할 배치 (권장)

5.2 원칙

• Owner는 CISO 역할 — 일상 운영 배제, 서명 디바이스 승인 외 활동 금지
• Signer ≠ Approver — 서명자가 자신의 트랜잭션을 승인할 수 없도록 정책 구성
• 최소 3 Signer — 교대·휴가·사고 대비 (분실/퇴사 즉시 재프로비저닝)
• 사용자 관리는 지원 티켓 기반 — 현재 셀프 서비스는 Early Availability
• 연 1회 접근 권한 재검토 (Non-Signing Admin·Approver 중심)

5.3 Admin Quorum 설정

6. 정책(TAP) 레이어

📘 상세: docs/13

TAP는 첫 번째 일치 원칙(first-match) — 가장 제한적인 규칙부터 순서대로 정렬.

6.1 W-COLD TAP 권장 레이어

6.2 W-OPS TAP 권장

• API 자동 서명은 소액 + 화이트리스트만 허용
• 임계값 초과는 자동 실패 → Warm 모바일 승인 → 그래도 초과 시 W-COLD로 라우팅

6.3 Sweeping (W-OPS → W-COLD 정기 이체)

• W-OPS 잔고가 일정 임계값 초과 시 자동 Sweeping
• 정책 엔진이 초과분을 P2P Network 경유로 W-COLD로 송금
• 일 1회 또는 시간당 체크 (배치 주기는 운영 요구에 맞춤)

7. 키 관리 및 백업 아키텍처

📘 상세: docs/14 · docs/15

7.1 키 쉐어 배치

MPC-CMP 지갑 (3 key shares)
├── Share 1: Fireblocks 클라우드 (HSM 보호)
├── Share 2: 고객사 자체 저장소
│            ├─ W-OPS: API Co-Signer (온프렘 SGX TEE)
│            └─ W-COLD: 에어갭 iOS 기기 (Signer별 1대)
└── Share 3: 백업 저장소 (별도 지역)

7.2 백업 저장소 다변화 (권장)

7.3 패스프레이즈 정책

• 절대 디지털 저장 금지 (스크린샷·타이핑·클라우드 업로드 불가)
• 기록 매체: 내화·방수 금속 카드에 각인
• 디바이스와 별도 위치 보관 (SPOF 방지)
• Cold Wallet 앱 v2.0.16+ Verify Passphrase로 분기별 유효성 확인

7.4 복구 시나리오

7.5 DR 리허설 주기

• 분기별: Verify Passphrase (실제 복구 없이)
• 반기별: 테스트넷 워크스페이스에서 Soft Recovery
• 연 1회: 테스트넷에서 Hard Recovery Full Rehearsal

8. 입출금 트랜잭션 플로우

📊 요약 (의사결정자용): 아래 1장 다이어그램으로 입·출금 통제 구조 전체를 확인. 기술 상세 시퀀스는 이하 "개발자용 상세" 접기 블록에서 확인.

입금 플로우

출금 플로우

범례: ■ 고객 · ■ 은행 운영·정책 · ■ 커스터디·온체인 · ★ 고위험 통제 포인트
ⓘ 전 단계 감사 로그 7년 보존 · 한국 가상자산이용자보호법(2024-07 시행) 준수

8.1 입금 플로우 (Deposit)

8.2 출금 플로우 (Withdrawal)

8.3 출금 제한 설계

임계값은 서비스 규모·가격 변동·규제 준수 상황에 맞게 주기적 조정

9. 모니터링·감사·컴플라이언스

9.1 로깅 · 감사

• Fireblocks Audit Log → Webhook으로 외부 SIEM 전송
• 모든 트랜잭션·승인·구성 변경·로그인 이벤트 수집
• 7년간 장기 보관 (국내 규제 요건)
• 고객사 SIEM: Datadog · Splunk · ELK 등 자체 선택

9.2 실시간 알림 트리거

9.3 정기 보고서

• 일일: 잔고·입출금 총계
• 주간: 고객별 거래 이상치 탐지
• 월간: Proof of Reserves 계산 · 감사팀 제출
• 분기: 사용자 접근 권한 재검토
• 연간: DR 리허설 보고 · 규제 당국 제출

10. 재해 복구(DR) 아키텍처

10.1 등급별 대응

10.2 RTO/RPO

• RPO: 0 (MPC 특성상 데이터 손실 없음 - 온체인 상태는 보존)
• RTO:
• L2: 1~2일
• L3: 3~5일
• L5: 수 일~1주 (테스트넷 리허설 경험에 따라 단축 가능)

10.3 워크스페이스 Freeze 절차

1. 손상 의심 감지 → 보안팀 에스컬레이션
2. Owner 또는 Non-Signing Admin이 즉시 Freeze 발동
3. 모든 사용자 역할이 Viewer로 자동 변경 → 발신 차단
4. 수신은 계속 (고객 입금 중단 회피)
5. Fireblocks 지원팀 + 포렌식 팀에 보고
6. 근본 원인 파악 후 Unfreeze 또는 신규 워크스페이스 마이그레이션

11. 물리 보안 및 인력 배치

11.1 디바이스 보관

11.2 공간 요구사항

• Signing Room: 콘솔 PC + 웹캠, Signer iOS 일시 반입, 녹화 CCTV
• Provisioning Room: macOS + Apple Configurator, 에어갭 물리 분리
• Safe Vault: 디바이스 장기 보관, 내화·방도, 이중 잠금
• DR Site: 본사와 타지역, 별도 권한자 관리

11.3 인력 요건

• 2인 통제(Two-Person Integrity) — 금고 접근·디바이스 반출 시 필수
• 퇴사자 처리: 24시간 이내 접근 해지 + 영향 디바이스 재프로비저닝
• 교차 훈련: 모든 Signer·Admin은 DR 절차 숙지
• 정기 훈련: 반기별 복구 훈련 필수 참여

12. 한국 규제 매핑

📘 상세: regulation-fireblocks-mapping

12.1 HSM 관련 참고

• 국내 규제는 HSM을 의무화하지 않음 — MPC로 대체 가능 (Fireblocks 클라우드 키 쉐어는 HSM 보호)
• FIPS 140-2 수준 자체 HSM을 추가 운영하는 경우는 리스크 다변화 목적

13. 초기 구축 로드맵

Phase 1: 사전 준비 (4~6주)

• [ ] Fireblocks 계약 · 콜드 월렛 워크스페이스 명시
• [ ] CSM 온보딩 세션 예약
• [ ] 하드웨어 구매 (iOS 기기 3~5대, macOS 프로비저닝 PC, 웹캠 PC)
• [ ] 물리 보안 공간 설계 · 금고 설치
• [ ] 역할 담당자 지정 (Owner, Signer 3명, Admin 2명, Security Manager 1명)

Phase 2: 워크스페이스 프로비저닝 (2~3주)

• [ ] W-OPS 프로비저닝 (API Co-Signer 포함)
• [ ] W-COLD 프로비저닝 (Owner 디바이스 온보딩 → Signer 디바이스 온보딩)
• [ ] 복구 패스프레이즈 생성 · 금속 카드 각인 · 분산 보관
• [ ] Workspace Key Backup Recovery Kit 생성

Phase 3: 정책 및 연결 (2주)

• [ ] P2P Network 연결 (W-OPS ↔ W-COLD)
• [ ] TAP 정책 테스트넷에서 검증 → 프로덕션 적용
• [ ] 화이트리스트 주소 초기 등록
• [ ] Sweeping 규칙 구성

Phase 4: 통합 및 감사 (2~3주)

• [ ] 백엔드 Fireblocks API 연동
• [ ] Webhook → SIEM 파이프라인 구축
• [ ] 실시간 알림 룰 작성
• [ ] 고객별 Vault 생성 자동화

Phase 5: 운영 리허설 (2주)

• [ ] 내부 테스트 거래 (소액 → 중액 → 대액)
• [ ] DR 리허설 (Soft Recovery · Verify Passphrase)
• [ ] 런북(Runbook) 작성 · 전원 훈련
• [ ] 보안 감사 · 외부 감사 준비

Phase 6: 제한 서비스 → 정식 오픈

• [ ] 내부 관계자 대상 소규모 베타
• [ ] 점진적 고객 온보딩
• [ ] 월별 Proof of Reserves 시작
• [ ] 분기별 정책 재검토 사이클 시작

부록: 체크리스트 요약

런북에 포함할 핵심 체크리스트는 fireblocks-cold-wallet-research 9절를 참조.