v0.0
운영 시나리오 문서¶
1. Executive Summary¶
본 문서는 D'CENT 엔터프라이즈 콜드월렛 커스터디 솔루션의 12개 운영 시나리오를 통해 Phase 3에서 설계한 모든 코어 기능의 실제 운영 적합성을 검증한다. 각 시나리오는 일상 운영, 긴급 상황, 관리 작업, 복구 상황 4개 분류로 구성되며, 단계별 흐름, 관련 역할, 참조 설계 문서, 에러/예외 케이스, 설계 갭을 포함한다.
시나리오 분류: | 분류 | 시나리오 수 | 범위 | |------|-----------|------| | 일상 운영 | 4개 (S-01~S-04) | 정기 출금, 배치 전송, 내부 이체, 화이트리스트 등록 | | 긴급 상황 | 3개 (S-05~S-07) | 긴급 출금, 서명자 비가용, 보안 침해 | | 관리 작업 | 3개 (S-08~S-10) | 서명자 교체, 정책 변경, 감사 대응 | | 복구 상황 | 2개 (S-11~S-12) | 디바이스 복구, 초기 설정 (Day-1) |
검증 결과: 12개 시나리오 중 10개 기능 설계(airgap-signing-flow ~ key-ceremony) 전체 커버. 4개 설계 갭 식별 (Phase 4-5 해결 대상).
2. 시나리오 작성 포맷¶
각 시나리오는 다음 구조를 따른다:
- 시나리오 번호/이름
- 분류 (일상 / 긴급 / 관리 / 복구)
- 전제 조건 (조직 구성, M-of-N, 현재 상태)
- 관련 역할
- 단계별 흐름
- 관련 기능 설계 참조
- 에러/예외 케이스
- 설계 갭 (있는 경우)
3. 일상 운영 시나리오 (4개)¶
S-01: 일상 BTC 출금¶
분류: 일상 운영 전제 조건: 조직 3-of-5 설정. 화이트리스트 등록된 거래소 주소 존재. 일일 한도 $200,000 이내.
관련 역할: Initiator (재무 담당), Approver 3명
단계별 흐름:
| Step | 컴포넌트 | 역할 | 액션 |
|---|---|---|---|
| 1 | 대시보드 | Initiator | MFA 로그인 → BTC 출금 TX 생성 (수신: 거래소 주소, 금액: 2 BTC) |
| 2 | 대시보드 (정책엔진) | 시스템 | 화이트리스트 확인 → 통과. 금액 한도 확인 → Tier 2 (3-of-5 쿼럼). 시간 확인 → 영업시간 내 |
| 3 | 대시보드 | 시스템 | PSBT 생성 (BIP-370 v2). 승인 요청 발송 (Approver 5명에게 알림) |
| 4 | 대시보드 | Approver 1 | TX 상세 확인 → 승인 (1/3) |
| 5 | 대시보드 | Approver 2 | TX 상세 확인 → 승인 (2/3) |
| 6 | 대시보드 | Approver 3 | TX 상세 확인 → 승인 (3/3). 상태: READY_TO_SIGN |
| 7 | 대시보드 | 시스템 | MuSig2 세션 시작. Nonce 교환 QR 표시 |
| 8 | 오프라인앱 → 콜드월렛 | Approver 1 | QR 스캔 → 콜드월렛 nonce 생성 → QR 반환 |
| 9 | 오프라인앱 → 콜드월렛 | Approver 2 | (동일) |
| 10 | 오프라인앱 → 콜드월렛 | Approver 3 | (동일) |
| 11 | 대시보드 | 시스템 | 3개 nonce 수집 → aggregated nonce 계산 → Round 2 QR 표시 |
| 12 | 오프라인앱 → 콜드월렛 | Approver 1 | QR 스캔 → WYSIWYS 확인 (주소, 금액, 수수료) → 물리 버튼 승인 → 부분 서명 → QR 반환 |
| 13 | 오프라인앱 → 콜드월렛 | Approver 2, 3 | (동일 과정) |
| 14 | 대시보드 | 시스템 | 3개 부분 서명 집계 → 단일 Schnorr 서명 → TX 완성 → 블록체인 전파 |
| 15 | 대시보드 | 시스템 | 6 확인 대기 → CONFIRMED. 감사 로그 기록. Initiator 알림 |
관련 설계 참조: airgap-signing-flow.md (4단계), multisig-workflow.md (MuSig2 에어갭 흐름), multichain-support.md (BTC PSBT), policy-engine.md (금액 검증)
에러/예외: MuSig2 nonce 교환 중 1명 지연 시 → 4시간 타임아웃 후 세션 재시작. WYSIWYS 불일치 시 → 서명 거부 + 보안 경고.
설계 갭: MuSig2 2라운드로 인한 에어갭 통신 횟수 증가 (서명자당 4회). UX 최적화 필요 (Phase 5).
S-02: 대량 배치 스테이블코인 전송¶
분류: 일상 운영 전제 조건: 2-of-3 설정. 급여일 USDC 20건 배치 전송. 일일 한도 $500,000.
관련 역할: Initiator (HR 재무), Approver 2명
단계별 흐름:
| Step | 컴포넌트 | 역할 | 액션 |
|---|---|---|---|
| 1 | 대시보드 | Initiator | 배치 전송 생성: 20개 수신 주소 + 금액 리스트 업로드 (CSV) |
| 2 | 대시보드 (정책엔진) | 시스템 | 20개 주소 화이트리스트 일괄 확인. 총액 합산 한도 확인. USDC 자산 필터 통과 |
| 3 | 대시보드 | 시스템 | 20건 개별 EIP-712 TypedData 생성 (ERC-20 transfer 호출) |
| 4 | 대시보드 | Approver 1, 2 | 배치 목록 검토 → 승인 (2/2). Safe execTransaction 준비 |
| 5 | 오프라인앱 → 콜드월렛 | Approver 1 | 20건 safeTxHash 순차 서명 (Animated QR로 배치 전달) |
| 6 | 오프라인앱 → 콜드월렛 | Approver 2 | (동일) |
| 7 | 대시보드 | 시스템 | 20건 각각 execTransaction 호출 → 블록체인 전파 |
| 8 | 대시보드 | 시스템 | 20건 확인 완료. ETH Gas 비용 집계. 감사 로그 20건 기록 |
관련 설계 참조: multichain-support.md (ERC-20 서명), policy-engine.md (누적 한도), whitelist-management.md (일괄 검증)
에러/예외: 1건 화이트리스트 미등록 → 해당 건만 차단, 나머지 19건 진행. Gas 부족 → ETH 잔액 사전 확인 경고.
설계 갭: 배치 서명 최적화 미설계 — 20건 개별 서명은 비효율. Phase 5에서 배치 서명 프로토콜 설계 필요.
S-03: 내부 월렛 간 자산 재배분¶
분류: 일상 운영 전제 조건: 콜드월렛 → 웜월렛 ETH 이체. 내부 주소 자동 화이트리스트.
관련 역할: Initiator (트레저리 매니저), Approver 2명
단계별 흐름:
| Step | 컴포넌트 | 역할 | 액션 |
|---|---|---|---|
| 1 | 대시보드 | Initiator | 내부 이체 생성: 콜드월렛 → 웜월렛, 50 ETH |
| 2 | 대시보드 (정책엔진) | 시스템 | 내부 주소 확인 → 간소화 승인 적용 (2-of-3 → 2-of-3 유지, 한도 완화) |
| 3 | 대시보드 | Approver 1, 2 | 승인 |
| 4 | 오프라인앱 → 콜드월렛 | Approver 1, 2 | 에어갭 서명 (Safe execTransaction) |
| 5 | 대시보드 | 시스템 | 전파 → 확인. 내부 이체 감사 로그 기록 |
관련 설계 참조: whitelist-management.md (내부 주소 차등), airgap-signing-flow.md, policy-engine.md
에러/예외: 웜월렛 잔액 상한 초과 시 → 정책 경고 (AC-TX-06 콜드/핫 비율 모니터링).
S-04: 신규 화이트리스트 주소 등록¶
분류: 일상 운영 전제 조건: 새로운 파트너사 BTC 수신 주소 등록 필요. 48시간 쿨다운.
관련 역할: Initiator (요청), Admin 2명 (승인)
단계별 흐름:
| Step | 컴포넌트 | 역할 | 액션 |
|---|---|---|---|
| 1 | 대시보드 | Initiator | 화이트리스트 등록 요청: 주소 bc1p..., 라벨 "PartnerCo 수신", BTC 체인 |
| 2 | 대시보드 | 시스템 | 주소 포맷 검증 (Bech32m). 블랙리스트 대조. 중복 확인 |
| 3 | 대시보드 | Admin 1 | 주소 정확성 확인 → 승인 |
| 4 | 대시보드 | Admin 2 | (동일) → 쿼럼 충족 |
| 5 | 대시보드 | 시스템 | 쿨다운 시작 (48시간). 상태: cooldown |
| 6 | (48시간 경과) | 시스템 | 쿨다운 완료 → 상태: active. 자동 활성화 |
| 7 | 대시보드 | Initiator | 해당 주소로 첫 TX 생성 가능 |
관련 설계 참조: whitelist-management.md (CRUD 워크플로우, 쿨다운), rbac-role-model.md (Admin 쿼럼)
에러/예외: 쿨다운 중 취소 가능 (Admin 단독). 긴급 등록 시 상위 쿼럼 + 쿨다운 스킵.
4. 긴급 상황 시나리오 (3개)¶
S-05: 긴급 출금 (보안 위협 감지)¶
분류: 긴급 상황 전제 조건: 대시보드에서 비정상 접근 패턴 감지. 자산 긴급 이전 필요. 3-of-5 → 축소 쿼럼 2-of-5.
관련 역할: Admin (긴급 발동), Approver 2명 (축소 쿼럼)
단계별 흐름:
| Step | 컴포넌트 | 역할 | 액션 |
|---|---|---|---|
| 1 | 대시보드 | 시스템 | 비정상 접근 패턴 감지 → 보안 경고 발생 |
| 2 | 대시보드 | Admin | 긴급 프로토콜 발동: priority "urgent" 설정 |
| 3 | 대시보드 (정책엔진) | 시스템 | 긴급 모드 활성화: 시간 제한 해제, 타임아웃 2시간, 축소 쿼럼 적용 |
| 4 | 대시보드 | Initiator | 긴급 TX 생성: 전체 자산 → 긴급 월렛 (사전 준비된 주소) |
| 5 | 대시보드 | Approver 1, 2 | 긴급 승인 (2/5 축소 쿼럼, 병렬 모드 강제) |
| 6 | 오프라인앱 → 콜드월렛 | Approver 1, 2 | 에어갭 서명 (시간 우선, QR 사용) |
| 7 | 대시보드 | 시스템 | 전파 → 확인. 긴급 TX 감사 로그 기록 |
| 8 | 대시보드 | Admin | 24시간 내 전체 Admin/Super Admin에게 긴급 TX 보고 |
| 9 | - | Admin | 72시간 내 사후 감사 완료. 보안 침해 원인 분석 |
관련 설계 참조: multisig-workflow.md (긴급 승인), policy-engine.md (긴급 오버라이드), disaster-recovery.md (DS-05), audit-trail.md
에러/예외: 축소 쿼럼에서도 최소 M=2 유지. 긴급 TX 24시간 내 최대 3건 제한.
S-06: 서명자 비가용 (장기 부재)¶
분류: 긴급 상황 전제 조건: 3-of-5 설정. Approver C 입원으로 30일 이상 부재. 대체 서명자 D 사전 지정.
관련 역할: Admin (대체 활성화), Approver D (대체 서명자)
단계별 흐름:
| Step | 컴포넌트 | 역할 | 액션 |
|---|---|---|---|
| 1 | - | Admin | Approver C 비가용 확인. 대체 서명자 활성화 결정 |
| 2 | 대시보드 | Admin (2명) | Approver D를 Approver C의 대체 서명자로 활성화 (쿼럼 승인) |
| 3 | 대시보드 | 시스템 | Approver D에게 서명 권한 부여 (최대 30일) |
| 4 | 대시보드 | Approver D | 대체 서명자로서 TX 승인/서명 수행 (자신의 별도 콜드월렛 사용) |
| 5 | (복귀 시) | Admin | Approver C 복귀 → Approver D 대체 비활성화 |
| 6 | (미복귀 시) | Admin | 30일 경과 → 서명자 교체 세레모니 (S-08 참조) |
관련 설계 참조: multisig-workflow.md (대체 서명자), rbac-role-model.md, disaster-recovery.md (DS-03)
에러/예외: 대체 서명자 미지정 시 → 즉시 Admin 쿼럼 승인으로 지정 필요.
S-07: 보안 침해 의심 대응¶
분류: 긴급 상황 전제 조건: 서명자 1명의 시드 노출 의심. 전체 자산 보호 필요.
관련 역할: Super Admin, Admin, 가용 Approver 전원
단계별 흐름:
| Step | 컴포넌트 | 역할 | 액션 |
|---|---|---|---|
| 1 | - | 탐지자 | 시드 노출 의심 보고 (물리적 금고 변조 흔적 발견 등) |
| 2 | 대시보드 | Admin | 즉시 격리: 의심 서명자 접근 차단, 대기 TX 동결 (5분 이내) |
| 3 | 대시보드 | Admin | 긴급 자산 이전 TX 생성: 전체 자산 → 긴급 월렛 |
| 4 | 대시보드 | Approver (축소 쿼럼) | 긴급 승인 + 에어갭 서명 |
| 5 | 대시보드 | 시스템 | 전파 → 확인. 자산 안전 확보 |
| 6 | - | Super Admin + Admin | 긴급 키 세레모니 실행 (key-ceremony.md 긴급 모드) |
| 7 | - | Approver 전원 | 새 키 세트 생성 → 새 다중 서명 월렛 구성 |
| 8 | 대시보드 | Admin | 긴급 월렛 → 새 영구 월렛으로 자산 최종 이전 |
| 9 | - | Admin | 침해 원인 분석, 규제 기관 보고 (필요 시) |
관련 설계 참조: disaster-recovery.md (DS-05 비상 절차), key-ceremony.md (긴급 복구), multisig-workflow.md (긴급 승인), audit-trail.md
에러/예외: 긴급 키 세레모니 중 증인 미확보 시 → 최소 1명으로 축소, 사후 보완 보고.
5. 관리 작업 시나리오 (3개)¶
S-08: 서명자 교체 (퇴사)¶
분류: 관리 작업 전제 조건: 3-of-5 설정. Approver B 퇴사. 신규 Approver E 합류.
관련 역할: Admin, Approver B (퇴임), Approver E (신규), 증인
단계별 흐름:
| Step | 컴포넌트 | 역할 | 액션 |
|---|---|---|---|
| 1 | 대시보드 | Admin | Approver E 온보딩 시작 (계정 생성, 역할 부여 — 쿼럼 승인) |
| 2 | - | Admin + 증인 | 키 세레모니 실행 (서명자 교체 모드) |
| 3 | - | Approver E | 새 콜드월렛에서 키 생성, 시드 백업, 검증 |
| 4 | - | Admin | Approver B 키 폐기 (SE 보안 삭제, 시드 물리적 파기) |
| 5 | 대시보드 | Admin | 다중 서명 재구성: BTC → 새 Taproot 트리 (E 포함, B 제거) |
| 6 | 대시보드 | Admin | EVM → Safe removeOwner(B) + addOwnerWithThreshold(E, 3) |
| 7 | 대시보드 | 시스템 | BTC: 기존 주소 → 새 주소로 전체 자산 이전 (키 로테이션) |
| 8 | 오프라인앱 → 콜드월렛 | 3명 Approver | 자산 이전 TX 에어갭 서명 (기존 키로 마지막 서명) |
| 9 | 대시보드 | 시스템 | 테스트 TX: 새 구성으로 소액 서명 테스트 |
| 10 | 대시보드 | Admin | Approver B 오프보딩 완료 (접근 완전 해제, 감사 로그 보존) |
관련 설계 참조: key-ceremony.md (서명자 교체), multisig-workflow.md (서명자 제거/추가), rbac-role-model.md (온/오프보딩)
에러/예외: BTC 자산 이전 중 수수료 급등 → RBF로 수수료 조정.
S-09: 정책 변경 (일일 출금 한도 인상)¶
분류: 관리 작업 전제 조건: 사업 성장으로 일일 출금 한도 $200,000 → $500,000 인상 필요.
관련 역할: Admin 2명
단계별 흐름:
| Step | 컴포넌트 | 역할 | 액션 |
|---|---|---|---|
| 1 | 대시보드 | Admin 1 | 정책 수정 요청: 일일 한도 $200,000 → $500,000 |
| 2 | 대시보드 (정책엔진) | 시스템 | 정책 시뮬레이션: "최근 30일 데이터 기준, 이 변경 시 추가 3건 TX가 상위 쿼럼 없이 통과했을 것" |
| 3 | 대시보드 | Admin 1 | 시뮬레이션 결과 검토 → 수정 요청 제출 |
| 4 | 대시보드 | Admin 2 | 시뮬레이션 결과 + 변경 내용 검토 → 승인 (쿼럼 2/2) |
| 5 | 대시보드 | 시스템 | 정책 버전 업데이트 (v1.0 → v1.1). 변경 diff 저장. 즉시 적용 |
| 6 | 대시보드 | 시스템 | 오프라인 앱에 정책 동기화 예약 (다음 QR/USB-C 교환 시) |
| 7 | 대시보드 | 시스템 | 감사 로그 기록: 정책 변경 이벤트, 승인자, 변경 diff, 시뮬레이션 결과 |
관련 설계 참조: policy-engine.md (정책 CRUD, 시뮬레이션, 버전 관리), rbac-role-model.md (Admin 쿼럼), audit-trail.md
에러/예외: 정책 변경 직후 기존 대기 TX에 새 정책 적용 → 영향 분석 표시.
S-10: 외부 감사 대응¶
분류: 관리 작업 전제 조건: SOC 2 Type II 감사. 외부 감사인에게 6개월 데이터 제공 필요.
관련 역할: Admin, Viewer (감사인), Compliance Officer (커스텀 역할)
단계별 흐름:
| Step | 컴포넌트 | 역할 | 액션 |
|---|---|---|---|
| 1 | 대시보드 | Admin | 외부 감사인 계정 생성: External Auditor 역할 (Viewer 기반, 6개월 범위 제한) |
| 2 | 대시보드 | Compliance Officer | 컴플라이언스 종합 리포트 생성: 기간 6개월, 전체 범위 |
| 3 | 대시보드 | Compliance Officer | Proof of Reserve 리포트 생성: 감사 기준일 스냅샷 |
| 4 | 대시보드 | 외부 감사인 | 리포트 조회: 거래 내역, 승인 체인, 정책 변경 로그, 자산 잔액 |
| 5 | 대시보드 | 외부 감사인 | 감사 로그 조회: 기간 내 모든 시스템 이벤트 |
| 6 | 대시보드 | 외부 감사인 | 감사 로그 해시 체인 무결성 검증: 변조 여부 확인 |
| 7 | - | 외부 감사인 | 감사 의견서 작성 |
| 8 | 대시보드 | Admin | 감사 완료 후 외부 감사인 계정 비활성화 |
관련 설계 참조: audit-trail.md (로그 무결성 검증), compliance-reporting.md (PoR, 종합 리포트), rbac-role-model.md (External Auditor 커스텀 역할)
에러/예외: 감사 로그 해시 체인 불일치 감지 시 → 보안 경고 + 변조 구간 식별.
6. 복구 상황 시나리오 (2개)¶
S-11: 디바이스 장애 복구¶
분류: 복구 상황 전제 조건: Approver A의 콜드월렛 고장 (화면 미작동). 3-of-5 설정에서 Approver A 서명 불가.
관련 역할: Admin, Approver A
단계별 흐름:
| Step | 컴포넌트 | 역할 | 액션 |
|---|---|---|---|
| 1 | - | Approver A | 콜드월렛 고장 보고 → Admin에게 알림 |
| 2 | - | Admin | 고장 원인 평가: 단순 하드웨어 고장 (시드 안전) |
| 3 | - | Admin | 복구 방법 결정: 옵션 A (시드 복원 — 빠름) |
| 4 | - | Admin | 백업 디바이스 수령 (Site B) |
| 5 | - | Admin | Approver A의 금속 시드 백업 수령 (Site A 금고) |
| 6 | - | Approver A | 백업 디바이스에 시드 입력 → 키 복원 (독립 공간에서) |
| 7 | - | Admin | 복원된 키의 주소 검증: 기존 주소와 일치 확인 |
| 8 | 대시보드 | Admin | 디바이스 교체 기록: 기존 일련번호 → 새 일련번호 |
| 9 | 오프라인앱 → 콜드월렛 | Approver A | 테스트 서명 수행 → 성공 확인 |
| 10 | 대시보드 | 시스템 | 정상 운영 재개. 감사 로그 기록 |
RTO 측정: Step 1~10 = 약 2-4시간 (RTO 4시간 목표 내)
관련 설계 참조: disaster-recovery.md (DS-01, 디바이스 교체 절차), key-ceremony.md (시드 복원)
에러/예외: 시드 복원 후 주소 불일치 → 시드 무결성 문제 → 옵션 B(새 키 + 자산 이전)로 전환.
S-12: 초기 시스템 설정 (Day-1)¶
분류: 복구 상황 (초기 설정) 전제 조건: 기업이 D'CENT 엔터프라이즈 최초 도입. 3-of-5 구성 목표.
관련 역할: Super Admin, Admin 3명, Approver 5명, 증인 2명
단계별 흐름:
| Step | 컴포넌트 | 역할 | 시간 | 액션 |
|---|---|---|---|---|
| 1 | 대시보드 | Super Admin | 1h | 시스템 초기화: 대시보드 설치/설정, 조직 프로필 생성 |
| 2 | 대시보드 | Super Admin | 30m | Admin 3명 계정 생성 + 역할 부여 |
| 3 | - | 전원 | 4-6h | 키 세레모니 실행 (key-ceremony.md 초기 설정 8단계) |
| 4 | 대시보드 | Admin | 30m | Initiator 계정 생성 (재무팀 2명) |
| 5 | 대시보드 | Admin | 30m | Viewer 계정 생성 (감사팀, 경영진) |
| 6 | 대시보드 | Admin (쿼럼) | 1h | 정책 설정: 금액 한도, 시간 제한, 자산 필터 |
| 7 | 대시보드 | Admin (쿼럼) | 30m | 화이트리스트 초기 등록: 내부 월렛 + 주요 외부 주소 |
| 8 | 대시보드 | Initiator | 30m | 테스트 TX: BTC 소액 출금 (전체 에어갭 흐름 검증) |
| 9 | 대시보드 | Initiator | 30m | 테스트 TX: ETH/USDC 출금 (EVM 흐름 검증) |
| 10 | 대시보드 | Admin | 30m | 감사 로그 확인: Day-1 모든 활동 정상 기록 확인 |
| 11 | - | Admin | 15m | 복구 드릴 일정 수립 (분기별) |
총 소요 시간: 약 10-12시간 (1.5 영업일)
관련 설계 참조: key-ceremony.md (초기 설정), rbac-role-model.md (전체 역할), policy-engine.md (정책 설정), whitelist-management.md (초기 등록), airgap-signing-flow.md (테스트 TX), audit-trail.md (Day-1 로그)
에러/예외: 키 세레모니 중 디바이스 초기화 실패 → 예비 디바이스로 교체.
7. 설계 갭 분석 요약¶
7.1. 식별된 설계 갭¶
| # | 갭 | 발견 시나리오 | 심각도 | 해결 Phase |
|---|---|---|---|---|
| G-01 | MuSig2 에어갭 UX 최적화 | S-01 | Important | Phase 5 (SYS-02) |
| G-02 | 배치 서명 프로토콜 | S-02 | Important | Phase 5 (SYS-02, SYS-04) |
| G-03 | 실시간 보안 경고 엔진 | S-05, S-07 | Critical | Phase 5 (SYS-06) |
| G-04 | Travel Rule 연동 인터페이스 | S-02 (해외 전송 시) | Important | Phase 5 (AC-GV-03) |
7.2. 갭 상세¶
G-01: MuSig2 에어갭 UX 최적화 - 문제: MuSig2 2라운드 프로토콜로 서명자당 4회 에어갭 통신 필요. 3명 서명자 시 총 12회 QR 스캔. - 영향: 일상 운영(S-01)의 소요 시간 증가 (30분+ per TX) - 해결 방향: USB-C 활용으로 nonce 교환 가속, Animated QR 프레임 최적화
G-02: 배치 서명 프로토콜 - 문제: 다건 TX 서명 시 개별 서명은 비효율 (S-02에서 20건 × 서명자 2명 = 40회 서명) - 영향: 급여일 등 대량 전송 시 수 시간 소요 - 해결 방향: 배치 서명 데이터 포맷 설계, 콜드월렛의 배치 승인 UI
G-03: 실시간 보안 경고 엔진 - 문제: S-05, S-07에서 "비정상 패턴 감지"를 전제로 하나, 감지 엔진 상세 미설계 - 영향: 보안 침해 감지 지연 가능 - 해결 방향: AC-AU-05 이상 패턴 자동 탐지 엔진 (Phase 5)
G-04: Travel Rule 연동 - 문제: 해외 전송 시 Travel Rule 정보 수집/전송 인터페이스 미설계 - 영향: EU/미국 시장 진출 시 규제 준수 불가 - 해결 방향: AC-GV-03 Travel Rule 메시지 생성/수신 인터페이스 (Phase 5)
8. 시나리오-기능 트레이서빌리티 매트릭스¶
| 시나리오 | airgap-signing | multisig-workflow | multichain | rbac-role | policy-engine | whitelist | audit-trail | compliance-reporting | disaster-recovery | key-ceremony |
|---|---|---|---|---|---|---|---|---|---|---|
| S-01 일상 출금 | P | P | P | - | P | - | S | - | - | - |
| S-02 배치 전송 | P | S | P | - | P | P | S | - | - | - |
| S-03 내부 이체 | P | S | - | - | S | P | S | - | - | - |
| S-04 화이트리스트 | - | - | - | P | - | P | S | - | - | - |
| S-05 긴급 출금 | P | P | - | - | P | - | P | - | S | - |
| S-06 서명자 비가용 | - | P | - | P | - | - | S | - | P | - |
| S-07 보안 침해 | P | P | - | - | - | - | P | - | P | P |
| S-08 서명자 교체 | S | P | - | P | - | - | S | - | - | P |
| S-09 정책 변경 | - | - | - | P | P | - | P | - | - | - |
| S-10 감사 대응 | - | - | - | P | - | - | P | P | - | - |
| S-11 디바이스 복구 | S | - | - | - | - | - | S | - | P | S |
| S-12 초기 설정 | P | S | S | P | P | P | P | - | - | P |
P = Primary (주요 참조), S = Secondary (보조 참조), - = 미참조
커버리지: 10개 기능 설계 문서 모두 최소 1개 이상의 시나리오에서 Primary로 참조됨. 100% 커버리지 달성.
9. 타겟 고객 세그먼트별 시나리오 적합성¶
9.1. 셀프 커스터디 기업 (최우선 타겟)¶
| 시나리오 | 적합도 | 비고 |
|---|---|---|
| S-01 일상 출금 | 높음 | 핵심 일상 운영. BTC/ETH 트레저리 관리 |
| S-02 배치 전송 | 중간 | 급여/벤더 지급 시 활용 |
| S-03 내부 이체 | 높음 | 콜드→웜 자산 재배분 |
| S-05 긴급 출금 | 높음 | 보안 사고 대응 필수 |
| S-08 서명자 교체 | 높음 | 인사 변동 시 필수 |
| S-12 초기 설정 | 높음 | 최초 도입 시 필수 |
9.2. 수탁 서비스 사업자 (차순위)¶
| 시나리오 | 적합도 | 비고 |
|---|---|---|
| S-02 배치 전송 | 높음 | 다수 고객 출금 처리 |
| S-10 감사 대응 | 높음 | SOC 2, 금감원 감사 필수 |
| S-04 화이트리스트 | 높음 | 고객 주소 관리 빈번 |
| S-09 정책 변경 | 높음 | 고객별 정책 차등 적용 |
추가 필요 시나리오 (수탁용): - 멀티테넌시 환경에서의 고객별 자산 분리 (Phase 4-5 범위) - 고객별 화이트리스트 독립 관리
9.3. 토큰 발행 주체 (보조)¶
| 시나리오 | 적합도 | 비고 |
|---|---|---|
| S-01 일상 출금 | 높음 | 트레저리 운용 |
| S-03 내부 이체 | 높음 | 트레저리 → 운영 월렛 |
| S-07 보안 침해 | 높음 | 대규모 토큰 보유로 공격 표적 |
본 문서는 Phase 3 Core Product Design의 최종 검증으로, 12개 시나리오가 10개 기능 설계 문서(airgap-signing-flow ~ key-ceremony)의 실제 운영 적합성을 검증한다. 설계 갭 4건은 Phase 4-5에서 해결 대상이며, 시나리오-기능 트레이서빌리티 매트릭스로 설계 커버리지 100%를 확인하였다.
관련 문서¶
- 에어갭 트랜잭션 서명 플로우 설계서 -- 제품 설계
- 감사 추적 체계 설계서 -- 제품 설계
- 컴플라이언스 리포팅 기능 정의서 -- 제품 설계
- 재해 복구 및 키 백업 절차 설계서 -- 제품 설계
- 키 세레모니 워크플로우 설계서 -- 제품 설계
- 멀티체인 지원 범위 및 우선순위 정의서 -- 제품 설계
- M-of-N 다중 서명 승인 워크플로우 설계서 -- 제품 설계
- 트랜잭션 정책 엔진 기능 정의서 -- 제품 설계
- RBAC 역할 체계 정의서 -- 제품 설계
- 화이트리스트 주소 관리 정책 설계서 -- 제품 설계