v0.2
시나리오 전환 경로 정의 및 레이어드 문서 구조¶
Part A: 시나리오 전환 경로¶
1. Executive Summary¶
본 문서는 D'CENT Enterprise 도입 시나리오 매트릭스(scenario-matrix.md)에서 정의된 8개 유효 시나리오(S1~S8) 간의 전환 경로를 설계하고, 후속 Phase 13-15에서 사용할 레이어드 문서 구조를 확정한다.
핵심 전환 축 3개:
- 배포 모델 전환 (가장 빈번): SaaS -> Hybrid -> Zero Cloud 업그레이드 및 역방향 다운그레이드
- 물리 환경 전환: 비콜드룸(Grade C -> B -> A) -> 콜드룸 보안 상향 및 역방향 하향
- 세그먼트 전환 (드문 케이스): 셀프 커스터디 -> 수탁 사업자 사업 모델 전환
전환 원칙:
- 에어갭 불변: 어떤 전환에서도 콜드월렛은 네트워크에 연결되지 않는다
- 키 무이동: 키는 항상 고객의 D'CENT X SE에 존재하며, 전환 시 키 이동/재생성 불필요
- "Same digital flow, different physical envelope": 물리 환경 전환 시 디지털 플로우는 변경되지 않는다
- 단계적 전환 권장: 두 축 이상의 동시 전환보다 순차적 전환을 권장
"시작은 쉽게, 성장은 자연스럽게" 전략: 대부분의 고객이 S4(SaaS + 비콜드룸)에서 시작하여, 자산 규모 성장과 규제 요건 증가에 따라 S3 -> S2 -> S1 방향으로 자연스럽게 상향 전환한다. D'CENT Enterprise는 이 전환 경로를 마찰 없이 지원하도록 설계된다.
2. 전환 축 정의¶
시나리오 전환은 3개 독립 축에서 발생한다. 각 축의 전환은 독립적이다 -- 배포 모델만 바꾸면서 물리 환경을 유지하거나, 물리 환경만 상향하면서 배포 모델을 유지할 수 있다.
2.1. 배포 모델 전환 축¶
| 전환 방향 | 경로 | 빈도 | 난이도 |
|---|---|---|---|
| 업그레이드 | SaaS -> Hybrid -> Zero Cloud | Common | Medium -> High |
| 다운그레이드 | Zero Cloud -> Hybrid -> SaaS | Rare | Medium -> Low |
| 직접 전환 | SaaS -> Zero Cloud (2단계 건너뛰기) | Rare | High |
2.2. 물리 환경 전환 축¶
| 전환 방향 | 경로 | 빈도 | 난이도 |
|---|---|---|---|
| 보안 상향 | Grade C -> Grade B -> Grade A -> 콜드룸 | Common | Low -> High |
| 보안 하향 | 콜드룸 -> Grade A -> Grade B -> Grade C | Very Rare | Low |
2.3. 세그먼트 전환 축¶
| 전환 방향 | 경로 | 빈도 | 난이도 |
|---|---|---|---|
| 사업 확장 | 셀프 커스터디(SC) -> 수탁 사업자(CSP) | Rare | High |
| 역전환 | 없음 (수탁 -> 셀프 역전환은 사업 철수에 해당) | N/A | N/A |
3. 배포 모델 전환 경로 상세¶
3.1. SaaS -> Hybrid 업그레이드¶
| 항목 | 내용 |
|---|---|
| 전환 트리거 조건 | |
| - 자산 규모 | AUC $10M 초과 시 데이터 주권 니즈 증가 |
| - 규제 요건 | SOC 2 감사에서 인프라 통제 요구 발생 |
| - 보안 감사 | 내부/외부 감사에서 SaaS 의존도 리스크 지적 |
| - 보험 요건 | 사이버 보험사가 인프라 독립성 요구 |
| 전환 시 변경 요소 | |
| - 서버 인프라 | D'CENT 클라우드 -> 클라우드(Private VPC) + 온프레미스 서명 환경 분리 |
| - 정책 엔진 | SaaS 공유 -> Hybrid 전용 인스턴스 |
| - 데이터 저장소 | D'CENT 관리 DB -> 기업 관리 또는 전용 클라우드 DB |
| 전환 시 불변 요소 | |
| - 에어갭 서명 플로우 | MuSig2/Safe 프로토콜 동일. QR/USB-C 통신 동일 |
| - 콜드월렛 운영 | D'CENT X 디바이스, 키, PIN 전부 변경 없음 |
| - 사용자 인터페이스 | 대시보드 UI 동일 (호스팅 위치만 변경) |
| - WYSIWYS 검증 | 하드웨어 디스플레이 검증 동일 |
| 전환 절차 | |
| Step 1 | 온프레미스 서명 환경 구축 (서버, 네트워크, 보안 캐비닛) |
| Step 2 | 대시보드 데이터 Export (표준 JSON 포맷) -- TX 이력, 정책, 화이트리스트, 감사 로그 |
| Step 3 | Hybrid 인프라에 데이터 Import + 검증 |
| Step 4 | 병렬 운영 기간 (2주) -- SaaS와 Hybrid 동시 모니터링 |
| Step 5 | DNS/엔드포인트 전환 -> Hybrid 운영 시작 |
| Step 6 | SaaS 데이터 영구 삭제 확인 |
| 예상 소요 기간 | 1-2주 (온프레미스 구축) + 2주 (병렬 운영) = 총 3-4주 |
| 다운타임 | DNS 전환 시 1시간 이내 (서명 기능은 에어갭이므로 다운타임 무관) |
3.2. Hybrid -> Zero Cloud 업그레이드¶
| 항목 | 내용 |
|---|---|
| 전환 트리거 조건 | |
| - 데이터 주권 | 클라우드 부분 의존도 완전 제거 필요 (ISMS-P, GDPR 강화) |
| - 규제 강화 | CCSS Level 3 인증 추진, 제3자 클라우드 리스크 제거 |
| - 보안 사고 | 클라우드 제공자 보안 사고 후 독립 운영 결정 |
| 전환 시 변경 요소 | |
| - 대시보드 서버 | 클라우드(Private VPC) -> 기업 데이터센터 |
| - 데이터베이스 | 클라우드 DB -> 온프레미스 PostgreSQL |
| - 블록체인 노드 | 외부 RPC -> 자체 풀노드(BTC Core, Geth+Prysm) |
| - 모니터링 | 클라우드 모니터링 -> Prometheus + Grafana(자체) |
| 전환 시 불변 요소 | |
| - 에어갭 서명 플로우 | 완전 동일 |
| - 콜드월렛/키 | 변경 없음 -- 키는 SE에 있으므로 인프라 전환과 무관 |
| - 정책/화이트리스트 | 데이터 마이그레이션으로 이전 |
| 전환 절차 | |
| Step 1 | 데이터센터 인프라 구축 (서버, DB, 네트워크, 방화벽) |
| Step 2 | 블록체인 풀노드 구축 + 초기 동기화 (BTC 수일, ETH 수일) |
| Step 3 | 대시보드 데이터 마이그레이션 (Hybrid -> Zero Cloud) |
| Step 4 | 병렬 운영 기간 (2주) |
| Step 5 | 클라우드 연결 해제 + Zero Cloud 단독 운영 전환 |
| Step 6 | 클라우드 데이터 영구 삭제 확인 |
| 예상 소요 기간 | 2-4주 (인프라 + 노드 동기화) + 2주 (병렬) = 총 4-6주 |
| 다운타임 | 전환 시 2-4시간 (데이터 최종 동기화 + DNS 전환) |
3.3. SaaS -> Zero Cloud 직접 전환¶
| 항목 | 내용 |
|---|---|
| 가능 여부 | 가능하나 권장하지 않음 |
| 조건 | 기업이 이미 데이터센터 인프라와 IT 인력을 보유한 경우 |
| 위험 | Hybrid 과도기 없이 직접 전환하면 운영 학습 곡선이 급격. 장애 대응 역량 미검증 |
| 권장 대안 | SaaS -> Hybrid (2-3주 운영 안정화) -> Zero Cloud 순차 전환 |
| 절차 | 3.1 + 3.2를 병합하되, 병렬 운영 기간을 3주로 확대 |
| 예상 소요 기간 | 총 5-7주 |
3.4. 다운그레이드 경로 (Zero Cloud -> Hybrid -> SaaS)¶
| 항목 | 내용 |
|---|---|
| 다운그레이드 발생 조건 | |
| - 비용 절감 | 자체 인프라 운영 비용이 기대 대비 과다 |
| - 운영 부담 | IT 인력 확보 어려움, 블록체인 노드 운영 복잡도 |
| - 사업 축소 | 크립토 자산 규모 감소로 고보안 인프라 불필요 |
| 다운그레이드 시 보안 수준 변화 | |
| - Zero Cloud -> Hybrid | 데이터 주권이 부분적으로 줄어듦. 키/서명은 여전히 기업 통제 |
| - Hybrid -> SaaS | 대시보드 데이터가 D'CENT 인프라로 이전. 키/서명은 여전히 기업 통제 |
| 고객 동의 절차 | |
| - 다운그레이드 시 보안 수준 변화를 명시적으로 고지 | |
| - 고객이 변경된 보안 수준을 문서로 수용 확인 | |
| - 규제 기관 통보 필요 시 기업이 직접 수행 | |
| 데이터/키 관리의 연속성 | |
| - 키: SE 디바이스에 있으므로 인프라 변경과 완전히 무관 | |
| - 데이터: 마이그레이션 후 원본 삭제 확인 | |
| - 감사 로그: 연속성 보장 (시점 간 갭 없음) |
4. 물리 환경 전환 경로 상세¶
4.1. 비콜드룸 -> 콜드룸 전환 (보안 상향)¶
Grade C -> Grade B 전환¶
| 항목 | 내용 |
|---|---|
| 전환 트리거 | AUC $10M 초과, SOC 2 인증 준비 시작, 보안 감사 권고 |
| 변경 사항 | |
| - 물리적 통제 추가 | CC-PHY-01 보안 캐비닛, CC-PHY-02 이중 잠금, CC-PHY-07 백업 전용 금고 |
| - 절차적 통제 추가 | CC-PROC-01 듀얼 컨트롤, CC-PROC-04 디지털 체크리스트, CC-PROC-05 서명 독립 공간 |
| - 기술적 통제 추가 | CC-TECH-03 디바이스 접근 대장, CC-TECH-04 서명 세션 자동 로그 |
| - 조직적 통제 추가 | CC-ORG-01 정기 보안 감사, CC-ORG-02 역할 분리 강화 |
| 디지털 플로우 변경 | 없음 -- "Same digital flow, different physical envelope" 원칙 적용 |
| 투자 비용 | $500-4,000 (보안 캐비닛, 이중 잠금, 백업 금고 등) |
| 소요 기간 | 1-2주 (장비 설치 + 절차 수립 + 교육) |
Grade B -> Grade A 전환¶
| 항목 | 내용 |
|---|---|
| 전환 트리거 | AUC $50M 초과, CCSS Level 2 인증 추진, 보험사 요구 |
| 변경 사항 | |
| - 물리 환경 업그레이드 | 전용 보안실 구축 (독립 공간, 전용 접근 통제) |
| - 보완 조치 확대 | MUST + SHOULD 전체 적용 (18개 중 15개+) |
| - CC-PHY-03 앵커링, CC-PHY-05 RF 차폐 파우치, CC-PHY-06 프라이버시 스크린 추가 | |
| - CC-PROC-06 봉인 정기 검사, CC-TECH-05 지연 서명 추가 | |
| 디지털 플로우 변경 | 없음 |
| 투자 비용 | $4,000-10,000 추가 (보안실 개조 + 추가 장비) |
| 소요 기간 | 2-4주 (보안실 개조 + 장비 설치 + 절차 업그레이드) |
Grade A -> 콜드룸 전환¶
| 항목 | 내용 |
|---|---|
| 전환 트리거 | AUC $100M 초과, CCSS Level 3 추진, 규제 기관 권고, 보험사 의무 요구 |
| 변경 사항 | |
| - Faraday cage 설치 | 전자기 차폐 환경 구축 |
| - 맨트랩 구축 | 이중문 접근 통제 |
| - 전용 CCTV | 24/7 녹화 + 장기 보존 |
| - 운영 프로토콜 전면 강화 | 콜드룸 전용 SOP, 체인-오브-커스터디 절차 |
| 디지털 플로우 변경 | 없음 (서명 방식이 비동기 -> 동기로 변경될 수 있으나, 이는 정책 선택이지 기술 변경이 아님) |
| 투자 비용 | $50,000-200,000 (콜드룸 구축) |
| 소요 기간 | 4-12주 (설계, 시공, 인증 검사) |
4.2. 콜드룸 -> 비콜드룸 전환 (보안 하향, 드문 케이스)¶
| 항목 | 내용 |
|---|---|
| 발생 조건 | 사업 축소, 비용 절감 불가피, 콜드룸 유지보수 불가 (극히 드문 상황) |
| 전환 시 필수 조건 | |
| - 잔여 위험 수용 | threat-model-comparison.md의 Delta High 6개 항목에 대한 잔여 위험 명시적 수용 |
| - 보완 조치 즉시 적용 | 콜드룸 해제 전 Grade A 보완 조치 패키지 완전 적용 |
| - 규제 통보 | CCSS 인증 등급 변경 통보, 보험사 통보 |
| - 고객 통보 | 수탁 사업자의 경우 고객사에 보안 수준 변경 통보 필수 |
| 보안 수준 변화 | 콜드룸 등급(CCSS Level 3) -> Grade A(CCSS Level 2+). Delta High 6개 항목의 위험이 재발생 |
| 디지털 플로우 변경 | 없음 |
5. 복합 전환 시나리오¶
두 축 이상이 동시에 전환되는 경우에 대한 가이드라인이다.
5.1. 예시: S4 -> S1 전환 (SaaS + 비콜드룸 -> Zero Cloud + 콜드룸)¶
| 단계 | 전환 내용 | 소요 기간 | 시나리오 상태 |
|---|---|---|---|
| 현재 | S4 (SaaS + Grade C) | -- | 운영 중 |
| Step 1 | SaaS -> Hybrid (배포 모델 업그레이드) | 3-4주 | S3으로 전환 |
| Step 2 | Grade C -> Grade B (보안 상향) | 1-2주 | S3 (보안 강화) |
| Step 3 | Hybrid -> Zero Cloud (배포 모델 업그레이드) | 4-6주 | S2로 전환 |
| Step 4 | Grade B -> Grade A (보안 상향) | 2-4주 | S2 (보안 강화) |
| Step 5 | Grade A -> 콜드룸 (물리 환경 전환) | 4-12주 | S1 도달 |
| 총 소요 | 14-28주 |
5.2. 예시: S6 -> S5 전환 (Hybrid + 비콜드룸 -> Zero Cloud + 콜드룸)¶
| 단계 | 전환 내용 | 소요 기간 | 시나리오 상태 |
|---|---|---|---|
| 현재 | S6 (Hybrid + Grade A) | -- | 운영 중 |
| Step 1 | Hybrid -> Zero Cloud (배포 모델 업그레이드) | 4-6주 | CSP-ZC-NCR (과도기) |
| Step 2 | Grade A -> 콜드룸 (물리 환경 전환) | 4-12주 | S5 도달 |
| 총 소요 | 8-18주 |
5.3. 단계적 전환 권장 순서¶
복합 전환 시, 다음 순서를 권장한다:
- 먼저 배포 모델 전환 (인프라 변경)
- 그 다음 물리 환경 전환 (보안 상향)
이유: 배포 모델 전환은 데이터 마이그레이션과 인프라 구축이 필요하므로 기술적 리스크가 높다. 물리 환경 전환은 보완 조치 추가/콜드룸 구축이므로 상대적으로 독립적이다. 배포 모델이 안정된 후 물리 환경을 강화하는 것이 전환 리스크를 최소화한다.
동시 전환의 위험: - 두 축을 동시에 변경하면 장애 발생 시 원인 격리가 어려움 - 병렬 운영 기간에 양쪽 축의 변경이 중첩되어 검증 복잡도 증가 - 롤백 시 어느 축을 되돌릴지 의사결정이 복잡
완화 방안: - 시간적 여유가 없는 경우, 배포 모델과 물리 환경을 2주 이상 간격을 두고 순차 전환 - 각 전환 단계마다 안정화 기간(최소 1주)을 확보
6. 전환 경로 다이어그램¶
graph LR
subgraph 셀프커스터디["셀프 커스터디 기업"]
S4["S4<br/>SaaS + 비콜드룸<br/>Grade C"]
S3["S3<br/>Hybrid + 비콜드룸<br/>Grade B/C"]
S2["S2<br/>Zero Cloud + 비콜드룸<br/>Grade A/B"]
S1["S1<br/>Zero Cloud + 콜드룸<br/>콜드룸 등급"]
end
subgraph 수탁사업자["수탁 서비스 사업자"]
S6["S6<br/>Hybrid + 비콜드룸<br/>Grade A"]
S5["S5<br/>Zero Cloud + 콜드룸<br/>콜드룸 등급"]
end
subgraph 토큰발행["토큰 발행 주체"]
S8["S8<br/>SaaS + 비콜드룸<br/>Grade C"]
S7["S7<br/>Hybrid + 비콜드룸<br/>Grade B"]
end
%% 셀프 커스터디 전환 경로
S4 -->|"배포 업그레이드<br/>Medium / Common"| S3
S3 -->|"배포 업그레이드<br/>High / Common"| S2
S2 -->|"환경 상향<br/>High / Rare"| S1
%% 셀프 커스터디 다운그레이드
S3 -.->|"다운그레이드<br/>Low / Rare"| S4
S2 -.->|"다운그레이드<br/>Medium / Rare"| S3
%% 수탁 사업자 전환 경로
S6 -->|"배포 업그레이드 + 환경 상향<br/>High / Common"| S5
%% 토큰 발행 전환 경로
S8 -->|"배포 업그레이드<br/>Medium / Common"| S7
%% 세그먼트 전환 (드문 케이스)
S2 -.->|"사업 확장<br/>High / Rare"| S6
S3 -.->|"사업 확장<br/>High / Rare"| S6범례: - 실선 화살표(-->): 주요 업그레이드 전환 경로 - 점선 화살표(-.->): 다운그레이드 또는 드문 전환 - 각 엣지 라벨: 전환 유형 / 난이도(Low/Medium/High) / 빈도(Common/Rare)
ASCII 대체 다이어그램:
[셀프 커스터디 기업 성장 경로]
S4 (SaaS+NCR) ──Common──▶ S3 (Hybrid+NCR) ──Common──▶ S2 (ZC+NCR) ──Rare──▶ S1 (ZC+CR)
Grade C Grade B/C Grade A/B 콜드룸 등급
AUC <$10M AUC $10M-100M AUC $50M-500M AUC $100M+
[수탁 사업자 성장 경로]
S6 (Hybrid+NCR) ──Common──▶ S5 (ZC+CR)
Grade A 콜드룸 등급
AUC $50M-500M AUC $500M+
[토큰 발행 주체 성장 경로]
S8 (SaaS+NCR) ──Common──▶ S7 (Hybrid+NCR)
Grade C Grade B
AUC $5M-100M AUC $100M-5B+
7. 전환 시 불변 원칙¶
어떤 전환(배포 모델, 물리 환경, 세그먼트)에서도 절대 변하지 않는 것들이다. 이 불변 원칙은 전환의 안전성을 보장하는 근거이자, 고객에게 전환 리스크가 관리 가능함을 설명하는 핵심 메시지이다.
| 불변 원칙 | 설명 | 근거 |
|---|---|---|
| 에어갭 원칙 | 콜드월렛은 어떤 전환에서도 네트워크에 연결되지 않는다 | 에어갭은 디바이스 설계 수준 보호. 인프라/환경 변경과 무관 |
| 키 주권 | 프라이빗 키는 항상 고객의 D'CENT X SE 내부에 존재한다. 전환 시 키 이동, 재생성, 추출이 없다 | SE는 물리적으로 키 추출이 불가능한 설계(EAL5+). 인프라 변경은 키에 영향 없음 |
| 서명 프로토콜 | MuSig2(BTC), Safe(EVM), MPC-TSS(Warm) 방식은 전환과 무관하게 불변 | 서명 프로토콜은 블록체인 수준 결정. 배포/환경과 독립 |
| WYSIWYS 검증 | 모든 트랜잭션은 D'CENT X 하드웨어 디스플레이에서 확인 후 물리 버튼으로 승인 | WYSIWYS는 하드웨어 기능. 인프라/환경 변경 영향 없음 |
| 감사 로그 연속성 | 전환 전후의 감사 로그는 연속적으로 보존된다. 시점 간 갭이 없다 | 마이그레이션 프로토콜에 감사 로그 이관 포함 |
| M-of-N 설정 | 다중 서명 임계값(예: 3-of-5)은 전환과 무관하게 유지된다 | M-of-N은 정책 수준 설정. 인프라 독립 |
Part B: 레이어드 문서 구조¶
8. 레이어드 문서 구조 설계 배경¶
8.1. 문제 정의¶
8개 유효 시나리오(S1~S8) 각각에 대해 독립적인 사용자 플로우 문서를 작성하면: - 8개 x 12개 운영 시나리오(operational-scenarios.md 기준) = 96개 플로우 - 이 중 80% 이상이 중복 (디지털 서명 플로우는 동일하므로) - 유지보수 시 하나의 변경이 8개 문서에 반영되어야 하는 일관성 유지 비용
8.2. 해결: 3계층 레이어드 구조¶
"Same digital flow, different physical envelope" 원칙을 문서 구조에 직접 반영한다.
Layer 1: 핵심 플로우 (Core Flow)
├── 모든 시나리오에 공통인 디지털 플로우
└── 1개 작성 -> 8개 시나리오에서 참조
Layer 2: 세그먼트 델타 (Segment Delta)
├── 고객 세그먼트에 따라 달라지는 요소
└── 3개 작성 (셀프 커스터디 / 수탁 사업자 / 토큰 발행)
Layer 3: 환경 어노테이션 (Environment Annotation)
├── 물리 환경에 따라 달라지는 운영 절차
└── 2개 작성 (콜드룸 / 비콜드룸)
문서 수 감소: 96개 -> 1(Core) + 3(Delta) + 2(Annotation) = 6개 문서 조합으로 8개 시나리오를 완전히 커버
9. 3계층 문서 구조 상세 정의¶
9.1. Layer 1: 핵심 플로우 (Core Flow)¶
| 항목 | 정의 |
|---|---|
| 정의 | 모든 시나리오에 공통인 디지털 플로우. S1~S8 어디에서든 변하지 않는 단계 |
| 범위 | 서명 요청 -> 정책 승인 -> 에어갭 서명(QR/USB-C 통신) -> 브로드캐스트 |
| 포함 내용 | |
| - 번호부 단계별 절차 | 각 단계의 시작 조건, 액션, 종료 조건 |
| - 역할별 액션 | Initiator, Approver, Admin, Viewer 각 역할의 액션 |
| - 시스템 상호작용 | 대시보드 <-> 오프라인 앱 <-> 콜드월렛 간 데이터 흐름 |
| - WYSIWYS 검증 단계 | 하드웨어 디스플레이에서 확인해야 할 항목 목록 |
| - 에러/예외 처리 | 타임아웃, 서명 거부, 통신 오류 시 대응 |
| 표현 방식 | 번호부 스텝 (Step 1, Step 2, ...). 각 스텝에 [컴포넌트], [역할], [액션] 명시 |
| 적용 시나리오 | S1~S8 전체 |
Layer 1 작성 원칙: - 물리적 환경에 대한 언급을 포함하지 않는다 (물리 절차는 Layer 3에서 처리) - 세그먼트 특화 로직을 포함하지 않는다 (세그먼트 차이는 Layer 2에서 처리) - 오직 디지털 플로우와 시스템 상호작용만 기술
9.2. Layer 2: 세그먼트 델타 (Segment Delta)¶
| 항목 | 정의 |
|---|---|
| 정의 | 고객 세그먼트에 따라 달라지는 요소. Layer 1의 특정 단계에 대한 오버라이드/확장 |
| 범위 | 거버넌스 구조, 승인 체계, 테넌시 모델, 트랜잭션 패턴, 규제 요건 차이 |
| 3개 델타 문서 | |
| - 셀프 커스터디 델타(SC Delta) | S1~S4에 적용. 내부 거버넌스, 콜드/웜 비율 관리, 감사 대응 |
| - 수탁 사업자 델타(CSP Delta) | S5~S6에 적용. 멀티테넌트, 이중 승인(Level 0-3), 테넌트 격리, SLA |
| - 토큰 발행 델타(TI Delta) | S7~S8에 적용. 베스팅/배포, DAO 거버넌스 연계, 커뮤니티 투명성 |
| 표현 방식 | Layer 1의 특정 Step에 대한 오버라이드로 기술 |
| 표기 규칙 | [SC Delta] Step N: 또는 [CSP Delta] Step N: 형식 |
Layer 2 작성 원칙: - Layer 1의 Step 번호를 명시적으로 참조한다 - 해당 Step이 세그먼트에 따라 "어떻게 다른지"만 기술 - 차이가 없는 Step은 생략 (Layer 1이 그대로 적용됨을 의미)
9.3. Layer 3: 환경 어노테이션 (Environment Annotation)¶
| 항목 | 정의 |
|---|---|
| 정의 | 물리 환경에 따라 달라지는 운영 절차. Layer 1의 물리적 단계에 대한 환경별 변종 |
| 범위 | 디바이스 보관/반출, 서명자 집결 방식, QR/USB-C 교환의 물리적 절차, 사전/사후 점검 |
| 2개 어노테이션 문서 | |
| - 콜드룸 어노테이션(CR Annotation) | S1, S5에 적용. 콜드룸 입장 절차, 듀얼 컨트롤, CCTV, 봉인, 체인-오브-커스터디 |
| - 비콜드룸 어노테이션(NCR Annotation) | S2~S4, S6~S8에 적용. 보안 캐비닛 접근, 보완 조치(CC-ID) 적용, 봉인 확인 |
| 표현 방식 | Layer 1의 특정 Step 전/후에 삽입되는 물리 절차로 기술 |
| 표기 규칙 | [CR Annotation] Before Step N: 또는 [NCR Annotation] After Step N: 형식 |
Layer 3 작성 원칙: - Layer 1의 디지털 플로우를 변경하지 않는다 (절차 삽입만 허용) - 보완 조치 ID(CC-PHY-xx, CC-PROC-xx, CC-TECH-xx, CC-ORG-xx)를 참조한다 - 보안 등급별(Grade A/B/C/콜드룸) 차이가 있으면 등급별로 분기 표기
10. Phase 13/14/15 문서 작성 가이드라인¶
10.1. Phase 13: 서명 플로우 설계¶
Phase 13에서는 서명 플로우를 Layer 1(핵심 서명 플로우) 1개 + Layer 3(콜드룸/비콜드룸 어노테이션) 2개로 구성한다.
| 문서 | Layer | 내용 | 적용 시나리오 |
|---|---|---|---|
| signing-core-flow.md | Layer 1 | MuSig2/Safe/MPC-TSS 서명 절차. 에어갭 QR/USB-C 통신 프로토콜. WYSIWYS 검증 단계. 에러/타임아웃 처리 | S1~S8 전체 |
| signing-coldroom-annotation.md | Layer 3 (CR) | 콜드룸 입장 절차, 서명자 물리 집결, 디바이스 반입/반출 체인-오브-커스터디, 동기 서명 세션 운영, CCTV 녹화 확인 | S1, S5 |
| signing-noncoldroom-annotation.md | Layer 3 (NCR) | 보안 캐비닛 접근 절차, 개인 보안 환경에서의 비동기 서명, 보완 조치(CC-ID) 적용 체크리스트, 봉인 확인/갱신 | S2~S4, S6~S8 |
Phase 13 작성 규칙: - signing-core-flow.md는 물리 환경을 언급하지 않는다 (Layer 1 원칙) - 콜드룸/비콜드룸 어노테이션은 signing-core-flow.md의 Step 번호를 참조한다 - WYSIWYS 검증은 Layer 1에서 필수 단계(numbered step)로 명시한다 (Bybit 방지) - QR/USB-C 통신 변종(대용량 TX, 다수 서명자)은 Layer 1에 포함 (디지털 프로토콜)
10.2. Phase 14: 세그먼트별 사용자 플로우¶
Phase 14에서는 Layer 1(핵심 E2E 플로우) 1개 + Layer 2(세그먼트 델타) 3개 + Layer 3(환경 어노테이션) 2개로 구성한다.
| 문서 | Layer | 내용 | 적용 시나리오 |
|---|---|---|---|
| e2e-core-flow.md | Layer 1 | 도입->온보딩->일상 운영->관리->긴급 대응의 5단계 E2E 플로우. 모든 세그먼트에 공통인 단계 | S1~S8 전체 |
| segment-delta-self-custody.md | Layer 2 (SC) | 내부 거버넌스 정책 적용, 콜드/웜 비율 관리, 정책 변경 승인, 감사 대응 절차, 서명자 교체 | S1~S4 |
| segment-delta-custody-provider.md | Layer 2 (CSP) | 고객 온보딩 플로우, 테넌트 격리 설정, 이중 승인 체계(Level 0-3), SLA 관리, 규제 리포팅 | S5~S6 |
| segment-delta-token-issuer.md | Layer 2 (TI) | 베스팅 스케줄 설정, 배치 배포 플로우, DAO 거버넌스 연계, 온체인 투명성 리포팅 | S7~S8 |
| e2e-coldroom-annotation.md | Layer 3 (CR) | Phase 13의 콜드룸 어노테이션을 E2E 맥락으로 확장 | S1, S5 |
| e2e-noncoldroom-annotation.md | Layer 3 (NCR) | Phase 13의 비콜드룸 어노테이션을 E2E 맥락으로 확장 | S2~S4, S6~S8 |
Phase 14 작성 규칙: - e2e-core-flow.md는 세그먼트/환경 중립적으로 작성 (Layer 1 원칙) - 각 세그먼트 델타는 e2e-core-flow.md의 단계(Phase)와 Step 번호를 참조 - 수탁 사업자 이중 승인 체계(Level 0-3)는 segment-delta-custody-provider.md에서 각 레벨별 플로우를 상세 기술 - 테넌트 격리는 "보안 경계"로 설계 -- 단순 DB 필터가 아님을 명시
10.3. Phase 15: 도입 여정 플로우¶
Phase 15에서는 배포 모델이 주축이므로, Layer 1(공통 여정 단계) + 배포 모델 델타(Zero Cloud/Hybrid/SaaS)로 구성한다.
| 문서 | Layer | 내용 | 적용 시나리오 |
|---|---|---|---|
| journey-core-stages.md | Layer 1 | Day-0(평가)->Day-1(설정)->Day-N(안정 운영) 공통 단계. POC->파일럿->프로덕션 게이트 | S1~S8 전체 |
| journey-delta-zero-cloud.md | 배포 모델 Delta | Zero Cloud 인프라 구축 여정, 블록체인 노드 동기화, 콜드룸/보안실 설정, 운영 전환 | S1, S2, S5 |
| journey-delta-hybrid.md | 배포 모델 Delta | Hybrid 환경 설정 여정, 클라우드 연결, 온프레미스 서명 환경, 보완 조치 적용 | S3, S6, S7 |
| journey-delta-saas.md | 배포 모델 Delta | SaaS 즉시 시작 여정, 계정 설정, 디바이스 배포, 키 세레모니, 테스트 TX | S4, S8 |
Phase 15 작성 규칙: - journey-core-stages.md는 배포 모델 중립적으로 작성 - 각 배포 모델 델타는 journey-core-stages.md의 단계(Day-0/1/N)를 참조 - Graduate in place 패턴은 journey-core-stages.md에서 정의 (공통 개념) - 시간 목표(SaaS 7일, Hybrid 14일, Zero Cloud 30일)는 각 배포 모델 델타에서 단계별 분해
11. 문서 구조 적용 예시¶
"일상 BTC 출금 트랜잭션 서명" 플로우를 3계층으로 분해하여, 독자(Phase 13-15 실행자)가 레이어드 구조를 즉시 이해할 수 있도록 한다.
11.1. Layer 1: 핵심 플로우 (Core Flow)¶
Step 1: [대시보드] [Initiator] BTC 출금 TX 생성 (수신 주소, 금액 입력)
Step 2: [대시보드] [정책 엔진] 화이트리스트/한도/시간 정책 검증 -> M-of-N 승인 요구 결정
Step 3: [대시보드] [Approver x M] TX 상세 확인 -> 승인
Step 4: [대시보드] [시스템] MuSig2 세션 시작, Nonce 교환 QR 생성
Step 5: [오프라인앱->콜드월렛] [Approver x M] QR 스캔 -> 콜드월렛 nonce 생성 -> QR 반환
Step 6: [대시보드] [시스템] Aggregated nonce 계산 -> Round 2 QR 생성
Step 7: [오프라인앱->콜드월렛] [Approver x M] QR 스캔 -> WYSIWYS 확인 (수신 주소, 금액, 수수료)
-> D'CENT X 하드웨어 디스플레이에서 트랜잭션 상세 확인
-> 물리 버튼으로 승인 -> 부분 서명 생성 -> QR 반환
Step 8: [대시보드] [시스템] M개 부분 서명 집계 -> 단일 Schnorr 서명 -> TX 완성 -> 블록체인 전파
Step 9: [대시보드] [시스템] 확인 대기 -> CONFIRMED. 감사 로그 기록. 알림 발송
Layer 1은 물리 환경이나 세그먼트를 언급하지 않는다. "어디서" "누가" 모이는지가 아니라, "무엇을" "어떤 순서로" 하는지만 기술한다.
11.2. Layer 2: 세그먼트 델타¶
[SC Delta] -- 셀프 커스터디 기업:
[SC Delta] Step 2: 내부 승인 정책에 따라 M-of-N 서명자 결정.
금액별 티어: <$50K = 2-of-5, $50K-$200K = 3-of-5, >$200K = 4-of-5
시간 기반 제한: 영업시간(09:00-18:00 KST) 외 = +1 추가 승인자
[SC Delta] Step 3: 내부 Approver만 승인 참여. 외부 참여 없음.
[CSP Delta] -- 수탁 서비스 사업자:
[CSP Delta] Step 2: 고객사 승인 참여 Level에 따라 서명자 풀 구성.
Level 0: 내부 Approver만 (고객 미참여)
Level 1: 내부 승인 후 고객사 통보
Level 2: 내부 승인 + 고객사 1인 공동 승인
Level 3: 내부 + 고객사 공동 M-of-N (예: 내부 2 + 고객 1 of 5)
[CSP Delta] Step 3: 고객사 Approver 참여 시, 고객사 대시보드 포털에서 승인.
테넌트 격리: 고객사 A의 Approver는 고객사 B의 TX를 볼 수 없음.
[TI Delta] -- 토큰 발행 주체:
[TI Delta] Step 1: 베스팅 스케줄에 따른 자동 TX 생성.
스케줄 트리거: 월 1일 자동 언락 -> TX 큐에 추가 -> Step 2로 진행
[TI Delta] Step 2: 커뮤니티 거버넌스 투표 결과 반영.
DAO 투표 통과 시 -> 정책 엔진이 승인 자동 진행
DAO 투표 미통과 -> TX 보류, 재투표 또는 취소
11.3. Layer 3: 환경 어노테이션¶
[CR Annotation] -- 콜드룸:
[CR Annotation] Before Step 5:
(a) 서명자 전원이 콜드룸에 물리적으로 입장
- 맨트랩 통과: 배지 + 생체 인증
- 전자기기 반입 금지 확인 (오프라인 앱 전용 태블릿만 허용)
- CCTV 녹화 시작 확인
- 듀얼 컨트롤: 최소 2인 동시 입장
(b) 디바이스 봉인 확인
- tamper-evident bag 봉인 상태 검사
- 일련번호 인벤토리 대장과 대조
- 봉인 파손 시 -> 세션 중단, 보안 사고 프로토콜 발동
[CR Annotation] After Step 7:
(c) 서명 완료 후 디바이스 반납
- 새 tamper-evident bag에 재봉인
- 봉인 번호 인벤토리 업데이트
- 서명 세션 체크리스트 작성 (증인 서명 포함)
(d) 콜드룸 퇴장
- CCTV 녹화 종료 확인
- 맨트랩 퇴장 로그 기록
[NCR Annotation] -- 비콜드룸:
[NCR Annotation] Before Step 5:
(a) 서명자가 개인 보안 캐비닛에서 디바이스 반출
- CC-PHY-02 이중 잠금 해제 (2인 동시 - CC-PROC-01 듀얼 컨트롤)
- CC-PROC-02 디바이스 인벤토리 대장에 반출 기록
- CC-PHY-04 봉인 상태 확인, 파손 시 CC-TECH-02 attestation 즉시 수행
(b) 서명 환경 확보
- CC-PROC-05 서명 독립 공간(회의실 등) 확보 (Grade A/B 시)
- CC-PHY-06 프라이버시 스크린 적용 (Grade A 시)
[NCR Annotation] Before Step 7:
(c) 사전 attestation
- CC-TECH-02 디바이스 attestation 수행 (매 서명 세션 전 필수)
- attestation 실패 시 -> 세션 중단, 디바이스 교체
[NCR Annotation] After Step 7:
(d) 디바이스 반납
- CC-PHY-04 새 봉인으로 재봉인
- CC-PROC-02 인벤토리 대장에 반납 기록
- CC-TECH-04 서명 세션 자동 로그 확인
(e) 체크리스트 완료
- CC-PROC-04 디지털 체크리스트 모든 항목 체크 확인
11.4. 시나리오별 조합 방법¶
특정 시나리오의 완전한 플로우를 구성하려면 Layer를 조합한다:
| 시나리오 | Layer 1 | Layer 2 | Layer 3 |
|---|---|---|---|
| S1 (SC + ZC + CR) | Core Flow | SC Delta | CR Annotation |
| S2 (SC + ZC + NCR) | Core Flow | SC Delta | NCR Annotation |
| S3 (SC + HY + NCR) | Core Flow | SC Delta | NCR Annotation |
| S4 (SC + SA + NCR) | Core Flow | SC Delta | NCR Annotation |
| S5 (CSP + ZC + CR) | Core Flow | CSP Delta | CR Annotation |
| S6 (CSP + HY + NCR) | Core Flow | CSP Delta | NCR Annotation |
| S7 (TI + HY + NCR) | Core Flow | TI Delta | NCR Annotation |
| S8 (TI + SA + NCR) | Core Flow | TI Delta | NCR Annotation |
S2, S3, S4는 Layer 1과 Layer 2(SC Delta)가 동일하고, Layer 3(NCR Annotation)도 동일하다. 차이는 배포 모델뿐이며, 이는 Phase 15(도입 여정)에서 처리된다.
12. 문서 간 참조 규칙¶
Phase 13-15의 모든 문서에서 다음 ID 체계를 일관되게 사용한다.
| ID 유형 | 형식 | 예시 | 출처 |
|---|---|---|---|
| 시나리오 ID | S1~S8 | S1, S5, S8 | scenario-matrix.md (본 Phase 12) |
| 보완 조치 ID | CC-{분류}-{번호} | CC-PHY-01, CC-PROC-04, CC-TECH-02 | non-coldroom-compensating-controls.md (Phase 11) |
| 보안 등급 | Grade A/B/C/콜드룸 | Grade A, 콜드룸 등급 | non-coldroom-compensating-controls.md (Phase 11) |
| 공격 벡터 ID | {카테고리}-{번호} | PA-01, DV-02, OP-01 | threat-model-comparison.md (Phase 11) |
| 운영 시나리오 ID | S-{번호} | S-01, S-05, S-12 | operational-scenarios.md (Phase 3) |
| 아키텍처 제약 ID | AC-{영역}-{번호} | AC-TX-06, AC-AU-01 | Phase 5 아키텍처 문서 |
참조 표기 규칙:
- 시나리오 참조: [S1], [S5~S6]
- 보완 조치 참조: (CC-PHY-01 보안 캐비닛), (CC-PROC-01 듀얼 컨트롤)
- 보안 등급 참조: Grade A, 콜드룸 등급
- 문서 간 링크: (-> signing-core-flow.md Step 7), (-> segment-delta-custody-provider.md Section 3)
본 문서는 Phase 12 도입 시나리오 매트릭스의 두 번째 산출물로서, MATRIX-02(시나리오 간 전환 경로 정의) 요구사항을 충족한다. 8개 유효 시나리오(S1~S8) 간의 전환 경로를 배포 모델/물리 환경/세그먼트 3개 축에서 양방향으로 정의하였다. 3계층 레이어드 문서 구조(Layer 1 핵심 플로우 + Layer 2 세그먼트 델타 + Layer 3 환경 어노테이션)를 확정하고, Phase 13/14/15 각각의 문서 작성 가이드라인을 구체적으로 제공하였다. "Same digital flow, different physical envelope" 원칙이 문서 구조에 직접 반영되어, 8개 시나리오를 6개 문서 조합으로 효율적으로 커버한다.