콘텐츠로 이동

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%를 확인하였다.


관련 문서