콘텐츠로 이동

v0.2

Layer 1 도입 여정 핵심 플로우 (Journey Core Stages)

1. Executive Summary

본 문서는 D'CENT Enterprise 커스터디 솔루션의 Layer 1 도입 여정 핵심 플로우를 정의한다. Phase 12에서 확정된 3계층 레이어드 문서 구조(Layer 1 Core Flow / Layer 2 Segment Delta / 배포 모델 Delta)에 따라, 배포 모델 중립적인 공통 여정 단계를 기술한다.

e2e-core-flow.md(Phase 14)와의 관계:

구분 e2e-core-flow.md 본 문서 (journey-core-stages.md)
관점 제품 사용 라이프사이클 도입 프로젝트 여정
범위 도입 -> 온보딩 -> 일상 -> 관리 -> 긴급 대응 평가(Day-0) -> 설정(Day-1) -> 안정 운영(Day-N)
Step 체계 A-Step / O-Step / D-Step / M-Step / E-Step J-Step 1 ~ J-Step 10
초점 "무엇을 하는가" (기능/절차) "언제, 어떤 순서로 도입하는가" (시간/게이트)
연계 A-Step/O-Step이 본 문서의 Day-0/Day-1 내에서 실행됨 J-Step이 e2e-core-flow.md의 해당 Step을 참조

적용 범위: S1~S8 전체 시나리오.

배포 모델별 시간 목표 요약:

배포 모델 목표 기간 Day-0 (평가) Day-1 (설정) 특성
SaaS 7일 2일 5일 최소 IT 부담, 즉시 시작
Hybrid 14일 4일 10일 서명 온프레미스 + 대시보드 클라우드
Zero Cloud 30일 9일 21일 모든 인프라 자체 운영, 최고 보안

Day-N(안정 운영)은 프로덕션 전환 후 지속되는 단계이므로 목표 기간에 포함하지 않는다. 위 기간은 "첫 실거래(프로덕션 전환 완료)"까지의 목표이다.

배포 모델 고유 절차는 본 문서에 포함하지 않는다. 각 배포 모델의 인프라 구축, 환경 설정, 운영 전환 상세는 아래 Delta 문서에서 다룬다:

  • journey-delta-zero-cloud.md — Zero Cloud 고유 절차 (S1, S2, S5)
  • journey-delta-hybrid.md — Hybrid 고유 절차 (S3, S6, S7)
  • journey-delta-saas.md — SaaS 고유 절차 (S4, S8)

2. 도입 여정 3단계 개요

D'CENT Enterprise 도입 여정은 3개 대단계(Day-0, Day-1, Day-N)와 10개 세부 단계(J-Step 1~10)로 구성된다. 각 대단계 사이에 통과 게이트(Gate)가 존재하여 준비도를 검증한다.

Day-0 (평가)                    Day-1 (설정)                        Day-N (안정 운영)
┌─────────────────────┐    ┌────────────────────────────┐    ┌──────────────────────────┐
│ J-Step 1: 초기 접촉  │    │ J-Step 4: 환경 구축        │    │ J-Step 8: 운영 안정화    │
│ J-Step 2: POC 환경   │    │ J-Step 5: 키 세레모니      │    │ J-Step 9: 운영 최적화    │
│ J-Step 3: POC 평가   │    │ J-Step 6: 파일럿 운영      │    │ J-Step 10: 확장 및 진화  │
│                     │    │ J-Step 7: 프로덕션 전환    │    │                          │
└─────────┬───────────┘    └──────────┬─────────────────┘    └──────────────────────────┘
          │                           │                              │
     [Gate 1]                    [Gate 2]                       [Gate 3]
   POC -> 파일럿              파일럿 -> 프로덕션            프로덕션 안정화 확인

3단계 요약:

대단계 목적 J-Step 범위 핵심 질문
Day-0 (평가) 솔루션 적합성 확인, POC 실행, Go/No-Go 결정 J-Step 1~3 "이 솔루션이 우리 조직에 맞는가?"
Day-1 (설정) 환경 구축, 키 세레모니, 파일럿, 프로덕션 전환 J-Step 4~7 "어떻게 안전하게 가동하는가?"
Day-N (안정 운영) 운영 최적화, 확장, 감사/컴플라이언스 유지 J-Step 8~10 "어떻게 지속적으로 운영하는가?"

J-Step과 e2e-core-flow.md A-Step/O-Step 매핑:

J-Step e2e-core-flow.md 참조 연계 내용
J-Step 1 A-Step 1 (보안 요건 평가) 초기 요구사항 수집 시 보안 요건 평가 실행
J-Step 1 A-Step 2 (배포 모델 선택) 배포 모델 사전 권고 및 선정
J-Step 2 A-Step 3 (물리 환경 결정) POC 환경 구성 시 물리 환경 계획 병행
J-Step 3 A-Step 4 (계약 및 라이선스) Go/No-Go 결정 후 계약 진행
J-Step 4 A-Step 5 (도입 킥오프) 인프라 환경 구축과 킥오프 병행
J-Step 5 O-Step 1~2 (조직 설정, 키 세레모니) 키 세레모니 절차 직접 실행
J-Step 6 O-Step 3~5 (지갑 생성, 정책 설정, 테스트) 파일럿 운영 시 온보딩 절차 실행
J-Step 7 O-Step 6~8 (교육, 운영 전환, 검증) 프로덕션 전환 및 핸드오버
J-Step 8 D-Step 1~2 (일상 서명, 모니터링) 초기 운영 안정화 모니터링
J-Step 9 D-Step 3~5 (정책 조정, 리포팅, 감사) 운영 최적화 및 감사 주기 확립
J-Step 10 M-Step 1~6 (관리 절차 전반) 확장/전환 시 관리 절차 활용

3. Day-0: 평가 단계 상세

Day-0은 솔루션 평가, POC 실행, 기술/사업적 적합성을 확인하는 단계이다. 이 단계에서 조직은 D'CENT Enterprise가 자사 요구에 부합하는지 실증적으로 검증한다.

J-Step 1: 초기 접촉 및 요구사항 수집

항목 내용
소요 시간 0.5~2일 (배포 모델별 상이 -- Delta 참조)
참여자 고객: CISO/CTO, IT 담당자, 재무 담당자 / D'CENT: 영업팀, 솔루션 아키텍트
시작 조건 조직이 암호화폐 자산 관리 솔루션 도입을 결정

절차:

  1. 접촉 경로 선택
  2. D'CENT 영업팀 직접 접촉 (Enterprise 문의)
  3. 셀프서비스 시작 (SaaS 모델의 경우 -- [Delta] 참조)

  4. 파트너 채널 소개 (Fireblocks 등 보완 파트너 경유)

  5. 요구사항 수집 (e2e-core-flow A-Step 1 연계)

  6. 자산 규모 및 유형 (BTC, ETH, ERC-20 등)
  7. 예상 트랜잭션 빈도 및 금액 패턴
  8. 현재 자산 보관 방식 (거래소 위탁, 소프트웨어 월렛, 다른 커스터디 등)
  9. 규제 환경 (관할권, 적용 규제, 인증 요건)

  10. IT 역량 수준 (전담 인력, 인프라 운영 경험)

  11. 배포 모델 사전 권고 (e2e-core-flow A-Step 2 연계)

  12. IT 역량, 규제 요건, 자산 규모에 따른 초기 배포 모델 추천
  13. "시작은 쉽게, 성장은 자연스럽게" 전략에 따라 SaaS/Hybrid 우선 권고

  14. 상향 전환 경로 안내 (transition-paths-document-structure.md 참조)

  15. 물리 환경 사전 평가

  16. 콜드룸 구축 가능성 및 의향 확인
  17. 기존 물리 보안 시설 현황 파악
  18. 보안 등급 목표 사전 설정 (Grade A/B/C 또는 콜드룸)

산출물: - 고객 요구사항 평가 보고서 - 배포 모델 사전 권고서 - 물리 환경 초기 평가 결과

J-Step 2: POC 환경 구성

항목 내용
소요 시간 1~5일 (배포 모델별 상이 -- Delta 참조)
참여자 고객: IT 담당자 1~2명 / D'CENT: 온보딩 엔지니어
시작 조건 J-Step 1 요구사항 수집 완료

공통 절차 (배포 모델 중립):

  1. 테스트넷 기반 POC 환경 세팅
  2. 테스트넷(BTC testnet, ETH Sepolia) 기반 환경 구성
  3. POC 전용 테넌트/계정 생성

  4. 배포 모델별 인프라 구성은 [Delta] Day-0 J-Step 2에서 상세화

  5. 디바이스 프로비저닝

  6. D'CENT X 콜드월렛 1~2대 대여 (POC 전용)
  7. 디바이스 초기화 및 펌웨어 업데이트

  8. 테스트용 PIN 설정 및 키 생성

  9. 테스트 서명 시나리오 실행

  10. 단일 서명 테스트 (1-of-1)
  11. 다중 서명 테스트 (2-of-3 MuSig2 / Safe)
  12. QR 에어갭 통신 테스트 (TX 생성 -> QR 스캔 -> 서명 -> QR 반환)
  13. USB-C 에어갭 통신 테스트 (보조 채널)

  14. WYSIWYS 하드웨어 디스플레이 검증 (수신 주소, 금액 확인)

  15. 사용자 체험

  16. 주요 역할별(Admin, Initiator, Approver) 워크플로우 체험
  17. 대시보드 UI/UX 평가
  18. 오프라인 서명 앱 사용성 평가

산출물: - POC 환경 구성 완료 보고 - 테스트 시나리오 실행 로그

J-Step 3: POC 평가 및 Go/No-Go 결정

항목 내용
소요 시간 0.5~2일 (배포 모델별 상이 -- Delta 참조)
참여자 고객: CISO/CTO, 보안 위원회, 경영진 / D'CENT: 솔루션 아키텍트
시작 조건 J-Step 2 POC 환경 구성 및 테스트 완료

절차:

  1. POC 결과 리포트 작성
  2. 서명 성공률 (목표: 99% 이상)
  3. 에어갭 통신 응답 시간 (QR 스캔~서명 완료)
  4. WYSIWYS 검증 정확도 (100% 필수)
  5. 사용자 만족도 피드백 (최소 3명 참여자 평가)

  6. 발견된 이슈 및 해결 방안

  7. 보안 적합성 평가

  8. 에어갭 원칙 준수 여부 확인
  9. 키가 SE(Secure Element)에서만 존재하는지 확인

  10. 정책 엔진 동작 검증 (화이트리스트, 한도, 시간 제약)

  11. 비용-편익 분석

  12. 초기 투자 비용 (하드웨어, 인프라, 라이선스)
  13. 월간 운영 비용 (인프라, 인력, 라이선스)
  14. 기존 솔루션 대비 보안 향상도

  15. ROI 예상 (보험료 절감, 규제 준수 비용 절감 포함)

  16. Go/No-Go 결정

  17. 보안 위원회/경영진 최종 의사결정
  18. Go: Gate 1을 통과하여 파일럿 진입
  19. No-Go: 이슈 해결 후 재평가 또는 도입 보류
  20. Conditional Go: 특정 조건 충족 시 진행 (예: 추가 보안 조치 구현)

산출물: - POC 결과 리포트 - Go/No-Go 결정 문서 (승인자 서명 포함) - (Go 시) 파일럿 계획서

4. Day-1: 설정 단계 상세

Day-1은 프로덕션 환경 구축, 키 세레모니 실행, 파일럿 운영, 그리고 최종 프로덕션 전환까지의 단계이다. 이 단계가 완료되면 실제 자산을 관리하는 프로덕션 운영이 시작된다.

J-Step 4: 인프라 환경 구축

항목 내용
소요 시간 0.5~7일 (배포 모델별 상이 -- Delta 참조)
참여자 고객: IT 담당자, 보안 담당자 / D'CENT: 온보딩 엔지니어, 인프라 엔지니어
시작 조건 Gate 1 통과 (POC -> 파일럿 전환 게이트 승인)

공통 절차 (배포 모델 중립):

  1. 대시보드 접속 환경 구성
  2. 프로덕션 테넌트/계정 생성
  3. 관리자(Admin) 초기 계정 설정
  4. SSO/LDAP 연동 (해당 시)

  5. 접속 IP 제한 설정 (해당 시)

  6. RBAC 초기 설정 (e2e-core-flow A-Step 5 연계)

  7. 역할 정의: Admin, Initiator, Approver, Viewer, Auditor
  8. 역할별 권한 매핑 확인

  9. 초기 사용자 계정 생성 및 역할 배정

  10. 배포 모델별 인프라 구축

  11. 이 단계의 핵심 차이는 배포 모델에 따라 결정된다

  12. [Delta] Day-1 J-Step 4: 각 배포 모델 Delta 문서에서 상세 기술

    • Zero Cloud: 서버 구축, 노드 동기화, 네트워크 격리 (7일)
    • Hybrid: 온프레미스 서명 환경 + 클라우드 대시보드 연결 (3일)
    • SaaS: 클라우드 프로덕션 계정 설정 (0.5일)

  13. 모니터링 및 알림 설정

  14. 시스템 모니터링 (가용성, 성능)
  15. 보안 이벤트 알림 (비정상 접근, 정책 위반)
  16. 감사 로그 수집 시작

산출물: - 인프라 구축 완료 보고서 - RBAC 설정 확인 문서 - 모니터링 대시보드 접속 확인

J-Step 5: 키 세레모니 실행

항목 내용
소요 시간 1~2일 (물리 환경에 따라 상이)
참여자 M-of-N 서명자 전원, Admin, 감사인(선택), D'CENT 온보딩 엔지니어
시작 조건 J-Step 4 인프라 환경 구축 완료

절차: (e2e-core-flow O-Step 1~2 연계)

  1. 사전 준비
  2. 키 세레모니 프로토콜 문서 배포 (역할별 체크리스트)
  3. 물리 환경 준비 확인 (콜드룸 또는 보안 등급 충족 공간)
  4. D'CENT X 디바이스 검수 (봉인 무결성, 펌웨어 버전)

  5. 참석자 신원 확인 및 출석 기록

  6. 마스터 키 생성

  7. 각 서명자가 개별 D'CENT X 디바이스에서 키 생성
  8. M-of-N 구성 설정 (예: 2-of-3, 3-of-5)
  9. BTC: MuSig2 다중 서명 키 설정

  10. EVM: Safe 멀티시그 컨트랙트 배포 (메인넷)

  11. 키 백업 절차

  12. BIP-39 시드 구문 기록 (금속 백업 매체 권장)
  13. Shamir Secret Sharing 적용 시: 시드 분할 및 분산 보관
  14. 백업 매체 봉인 및 보관 위치 기록

  15. 지리적 분산 보관 계획 실행 (최소 2개 사이트)

  16. 검증

  17. 생성된 주소 확인 (대시보드 표시 주소 = 하드웨어 디스플레이 주소)
  18. WYSIWYS 검증: 하드웨어 디스플레이에서 주소/금액 확인
  19. 테스트 서명 실행 (테스트넷 또는 소액 메인넷)

  20. 키 백업 복구 리허설 (별도 디바이스에서 시드 복원 확인)

  21. 키 세레모니 완료 문서화

  22. 키 세레모니 완료 보고서 (일시, 참석자, 결과)
  23. 키 메타데이터 기록 (공개키, 주소, M-of-N 구성, 생성 일시)
  24. 감사 추적 가능한 형태로 보관

산출물: - 키 세레모니 완료 보고서 - 키 메타데이터 문서 - 백업 보관 확인서

J-Step 6: 파일럿 운영

항목 내용
소요 시간 2~7일 (배포 모델별 상이 -- Delta 참조)
참여자 전체 운영팀 (Admin, Initiator, Approver), D'CENT 지원팀
시작 조건 J-Step 5 키 세레모니 완료

절차: (e2e-core-flow O-Step 3~5 연계)

  1. 소액 실거래 테스트 (메인넷)
  2. 단계적 금액 증가: $100 -> $1,000 -> $10,000
  3. 각 단계에서 서명/브로드캐스트/확인 전 과정 검증
  4. MuSig2(BTC)와 Safe(EVM) 모두 테스트

  5. WYSIWYS 하드웨어 검증 매회 실행

  6. 정책 엔진 규칙 검증

  7. 화이트리스트 주소 제한 테스트 (비화이트리스트 주소 전송 차단 확인)
  8. 금액 한도 테스트 (한도 초과 시 추가 승인 요구 확인)
  9. 시간 제약 테스트 (업무 시간 외 전송 제한 확인)

  10. M-of-N 정족수 미달 시 거부 확인

  11. 사용자 교육 및 절차 숙달

  12. 역할별 교육 세션 (Admin, Initiator, Approver, Viewer, Auditor)
  13. 실습 중심 교육 (실제 파일럿 환경 사용)
  14. 표준 운영 절차(SOP) 문서 배포 및 숙지 확인

  15. 비상 연락 체계 확립

  16. 사고 대응 리허설

  17. 디바이스 분실/도난 시나리오 대응 연습
  18. 서명 거부 / 비정상 트랜잭션 대응 연습
  19. 키 백업 복구 시나리오 테이블탑 훈련

산출물: - 파일럿 운영 로그 (전체 트랜잭션 기록) - 정책 엔진 테스트 결과 보고서 - 교육 수료 확인 명부 - 사고 대응 리허설 보고서

J-Step 7: 프로덕션 전환

항목 내용
소요 시간 0.5~2일 (배포 모델별 상이 -- Delta 참조)
참여자 CISO/CTO, Admin, D'CENT 온보딩 엔지니어
시작 조건 Gate 2 통과 (파일럿 -> 프로덕션 전환 게이트 승인)

전환 방식 선택:

프로덕션 전환 시 두 가지 방식 중 하나를 선택한다:

방식 설명 적합 상황
Graduate in Place POC/파일럿 환경을 프로덕션으로 전환 인프라 변경 없이 설정만 전환하는 경우
클린 프로덕션 구축 새로운 프로덕션 환경 구축 후 마이그레이션 배포 모델 변경, 대규모 인프라 변경 시

공통 전환 절차:

  1. 전환 방식 결정
  2. Graduate in Place 적합성 평가 (섹션 7 참조)
  3. 클린 프로덕션 구축 필요 여부 판단

  4. 전환 계획 수립 및 승인

  5. 실제 자산 이전

  6. 단계적 이전: 소액(5%) -> 중액(20%) -> 대액(나머지)
  7. 각 단계 이전 후 잔액 확인 및 서명 기능 검증

  8. 이전 완료 후 기존 보관소(거래소/소프트웨어 월렛)의 잔액 zero 확인

  9. 운영 핸드오버

  10. D'CENT 온보딩팀 -> 고객 운영팀 공식 핸드오버
  11. 기술 지원 채널 전환 (온보딩 지원 -> 운영 지원)
  12. 에스컬레이션 경로 확인
  13. 운영 핸드오버 서명 문서

산출물: - 프로덕션 전환 보고서 - 자산 이전 확인서 (트랜잭션 해시, 잔액 확인) - 운영 핸드오버 문서

5. Day-N: 안정 운영 단계 상세

Day-N은 프로덕션 전환 후 지속적인 운영 최적화, 확장, 감사/컴플라이언스를 유지하는 단계이다.

J-Step 8: 운영 안정화 (Day 1~30)

항목 내용
소요 시간 30일 (프로덕션 전환 후)
참여자 운영팀 전원, D'CENT 기술 지원팀
시작 조건 J-Step 7 프로덕션 전환 완료

절차:

  1. 초기 모니터링 강화 기간
  2. 프로덕션 전환 후 처음 2주: 일 단위 운영 리뷰
  3. 이상 징후 즉시 에스컬레이션 (D'CENT 지원팀 + 내부 보안팀)

  4. 서명 응답 시간, 시스템 가용성, 에어갭 통신 안정성 추적

  5. 정책 미세 조정

  6. 실제 운영 데이터 기반 정책 규칙 조정
  7. 화이트리스트 주소 추가/제거
  8. 금액 한도 재설정 (실제 트랜잭션 패턴 반영)
  9. 시간 제약 조정 (업무 패턴 반영)

  10. M-of-N 정족수 적정성 재평가

  11. 사고 대응 절차 리허설 (e2e-core-flow E-Step 연계)

  12. 실제 환경에서 모의 보안 사고 대응 훈련
  13. 디바이스 분실 대응 (키 격리, 정족수 재구성)
  14. 비정상 트랜잭션 대응 (긴급 동결, 원인 분석)
  15. 대응 시간 측정 및 SLA 충족 여부 확인

산출물: - 30일 운영 리포트 (가용성, 사고, 정책 변경 기록) - 조정된 정책 규칙 문서 - 사고 대응 리허설 결과 보고서

J-Step 9: 운영 최적화 (Month 1~3)

항목 내용
소요 시간 Month 1~3 (프로덕션 전환 후)
참여자 운영팀, 보안팀, 재무팀
시작 조건 J-Step 8 운영 안정화 완료 (30일 무사고 달성)

절차:

  1. Cold/Warm 비율 최적화
  2. 실제 트랜잭션 패턴 분석 (빈도, 금액, 시급성)
  3. Cold(80-95%) / Warm(5-15%) 최적 비율 도출
  4. 자동 리밸런싱 임계값 설정

  5. 계절적/주기적 패턴 반영 (예: 분기말 정산, 베스팅 일정)

  6. 서명 워크플로우 효율화

  7. 서명 소요 시간 분석 및 병목 식별
  8. 승인자 가용성 패턴 분석 (시간대별, 요일별)
  9. 긴급 서명 절차 최적화

  10. QR vs USB-C 채널 선택 기준 정립 (데이터 크기별)

  11. 감사 로그 리뷰 주기 확립 (e2e-core-flow D-Step 5 연계)

  12. 일일/주간/월간 감사 로그 리뷰 스케줄 수립
  13. 이상 패턴 자동 탐지 규칙 설정
  14. 외부 감사 대비 문서 세트 사전 준비
  15. SOC 2 / CCSS 감사 대응 프로세스 확립

산출물: - 운영 최적화 보고서 - 조정된 Cold/Warm 비율 및 리밸런싱 규칙 - 감사 대비 문서 세트

J-Step 10: 확장 및 진화 (Month 3+)

항목 내용
소요 시간 지속적 (Month 3 이후)
참여자 경영진, 운영팀, D'CENT 어카운트 매니저
시작 조건 J-Step 9 운영 최적화 완료

절차:

  1. 지원 체인/자산 확장
  2. 신규 블록체인 네트워크 추가 지원 요청
  3. ERC-20/TRC-20 등 토큰 표준 추가

  4. 배포 모델별 인프라 확장 ([Delta] Day-N J-Step 10 참조)

  5. 배포 모델 상향 전환 검토 (transition-paths-document-structure.md 참조)

  6. 전환 트리거 조건 모니터링 (자산 규모, 규제 요건, 보안 감사 결과)
  7. SaaS -> Hybrid 전환: AUC $10M 초과 시 검토
  8. Hybrid -> Zero Cloud 전환: 데이터 주권/CCSS Level 3 요구 시 검토

  9. 전환 시 불변 원칙 6개 확인:

    1. 에어갭: 콜드월렛은 네트워크에 절대 연결되지 않는다
    2. 키 주권: 키는 고객의 D'CENT X SE에만 존재한다
    3. 서명 프로토콜: MuSig2/Safe 프로토콜은 변경되지 않는다
    4. WYSIWYS: 하드웨어 디스플레이 검증은 항상 실행된다
    5. 감사 로그 연속성: 전환 전후 감사 로그가 연속된다
    6. M-of-N 설정: 전환 시 서명 정족수는 유지된다

  10. 물리 환경 보안 등급 상향 검토

  11. Grade C -> B -> A -> 콜드룸 순차 상향 경로
  12. 보안 등급별 추가 요구사항 확인 (non-coldroom-compensating-controls.md 참조)
  13. 콜드룸 구축 타당성 분석 (비용 $53K-125K, 기간 4-8주)

산출물: - 확장 로드맵 - 전환 타당성 보고서 (해당 시) - 연간 운영 리뷰 보고서

6. POC -> 파일럿 -> 프로덕션 통과 게이트

각 대단계 사이에 통과 게이트가 존재한다. 게이트는 다음 단계로 진행하기 위한 최소 요건을 정의하며, 스톨(지연) 감지 기준을 포함한다.

Gate 1: POC -> 파일럿 전환 게이트

항목 내용
위치 J-Step 3 완료 후, J-Step 4 시작 전
승인자 보안 위원회 + IT 책임자

증거 요건:

# 요건 기준 검증 방법
1 테스트넷 서명 성공률 >= 99% POC 테스트 로그
2 WYSIWYS 검증 정확도 100% 하드웨어 디스플레이 확인 기록
3 에어갭 통신 정상 동작 QR/USB-C 모두 성공 에어갭 통신 테스트 로그
4 사용자 만족도 피드백 최소 3명 평가, 부정 0건 피드백 설문 결과
5 보안 적합성 확인 에어갭 준수, 키 SE 내 존재 보안 점검 체크리스트

타임라인:

배포 모델 Gate 1 도달 목표 비고
SaaS Day-0 시작 후 3일 이내 인프라 세팅 최소, POC 속도 빠름
Hybrid Day-0 시작 후 5일 이내 온프레미스 구성 포함
Zero Cloud Day-0 시작 후 10일 이내 자체 인프라+노드 동기화 필요

스톨 감지 기준:

  • 기준: 예상 타임라인의 150% 초과 시 에스컬레이션
  • SaaS: 4.5일 초과 -> 에스컬레이션
  • Hybrid: 7.5일 초과 -> 에스컬레이션
  • Zero Cloud: 15일 초과 -> 에스컬레이션
  • 스톨 시 조치:
  • D'CENT 기술 지원팀 긴급 투입
  • 블로커 원인 분석 (기술적 이슈 / 조직적 지연 / 리소스 부족)
  • 블로커별 해결 방안 수립 (기술 지원 강화 / 의사결정 촉진 / 리소스 재배치)
  • 일정 재수립 (최대 1회 연장, 이후 재평가)
  • 반복 스톨 시: 배포 모델 하향 검토 (예: Zero Cloud -> Hybrid)

Gate 2: 파일럿 -> 프로덕션 전환 게이트

항목 내용
위치 J-Step 6 완료 후, J-Step 7 시작 전
승인자 CISO/CTO + 경영진 + (해당 시) 규제 담당자

증거 요건:

# 요건 기준 검증 방법
1 메인넷 소액 거래 성공 최소 10건 이상 트랜잭션 해시 + 블록 확인
2 정책 엔진 규칙 전수 테스트 전체 규칙 통과 정책 테스트 보고서
3 키 백업/복구 리허설 1회 이상 성공 복구 리허설 보고서
4 사고 대응 절차 탁상 훈련 1회 이상 완료 훈련 보고서
5 사용자 교육 수료 역할별 최소 2명 교육 수료 확인서
6 감사 로그 연속성 POC -> 파일럿 전 구간 감사 로그 일관성 검증
7 SLA 충족 파일럿 기간 중 SLA 미달 0건 운영 리포트

타임라인:

배포 모델 Gate 2 도달 목표 (파일럿 시작 후) 비고
SaaS 3일 이내 인프라 안정성은 D'CENT 보장
Hybrid 7일 이내 온프레미스-클라우드 연동 검증 포함
Zero Cloud 14일 이내 풀노드 안정성 + 인프라 검증 포함

스톨 감지 기준:

  • 기준: 예상 타임라인의 200% 초과 시 게이트 재검토
  • SaaS: 6일 초과 -> 게이트 재검토
  • Hybrid: 14일 초과 -> 게이트 재검토
  • Zero Cloud: 28일 초과 -> 게이트 재검토
  • 스톨 시 조치:
  • 게이트 요건 재검토 (불필요하게 높은 기준 조정 가능 여부)
  • 부분 프로덕션 전환 검토 (소액 자산만 우선 전환, 나머지는 파일럿 유지)
  • 블로커가 배포 모델 고유 이슈인 경우: 배포 모델 변경 검토
  • 조직적 지연인 경우: 경영진 에스컬레이션 + 의사결정 촉진
  • 최종 판단: 프로젝트 일시 중단 또는 범위 축소

Gate 3: 프로덕션 안정화 확인 게이트

항목 내용
위치 J-Step 8 완료 후 (프로덕션 전환 30일 경과)
승인자 CISO + 운영팀장

증거 요건:

# 요건 기준 검증 방법
1 무사고 운영 기록 30일 연속 보안 사고 0건 사고 대응 로그
2 SLA 충족 서명 응답 시간 SLA 충족 운영 리포트
3 감사 대비 문서 완비 필수 문서 세트 100% 작성 감사 체크리스트
4 정책 규칙 안정화 최근 7일간 정책 변경 0건 정책 변경 로그
5 사용자 역량 확인 전 역할 독립 운영 가능 독립 운영 관찰 기록

스톨 감지 기준:

  • 기준: 30일 내 보안 사고 2건 이상 발생 시 안정화 기간 연장
  • 스톨 시 조치:
  • 사고 원인 심층 분석 (운영 미숙 / 설정 오류 / 시스템 이슈)
  • 원인별 시정 조치 이행
  • 안정화 기간 30일 재시작 (시정 조치 완료 시점부터)
  • 3회 연속 안정화 실패 시: 전면 재검토 (아키텍처, 운영 절차, 인력 역량)

7. Graduate in Place 패턴

7.1. 개념 정의

Graduate in Place는 POC/파일럿 환경을 재구축 없이 프로덕션으로 전환하는 패턴이다. 새로운 프로덕션 환경을 별도로 구축하고 마이그레이션하는 대신, 기존 환경의 설정과 정책을 프로덕션 수준으로 강화하여 그대로 운영 환경으로 승격한다.

핵심 가치: - 도입 시간 단축 (환경 재구축 불필요) - 데이터 연속성 보장 (감사 로그, 설정 이력 유지) - 사용자 학습 곡선 최소화 (동일 환경에서 계속 작업) - 비용 절감 (이중 환경 운영 불필요)

7.2. 전제 조건

Graduate in Place를 적용하려면 다음 전제 조건이 모두 충족되어야 한다:

# 전제 조건 확인 방법 비고
1 POC 키가 프로덕션 적합 메인넷 키 생성 여부 확인 테스트넷 전용 키는 불가
2 인프라가 프로덕션 요건 충족 보안 점검 체크리스트 통과 네트워크 격리, 모니터링, HA
3 정책 엔진 규칙 프로덕션 완비 전수 테스트 통과 화이트리스트, 한도, 시간제약
4 배포 모델 변경 없음 도입 계획 확인 배포 모델 변경 시 클린 구축 필요
5 보안 등급 대폭 상향 없음 등급 비교 확인 2단계 이상 상향 시 클린 구축 권장
6 감사 추적성 확보 감사 로그 무결성 확인 POC부터의 전체 이력 보존

7.3. 전환 절차 (6단계)

Stage 1: 환경 감사

  • POC/파일럿 환경의 프로덕션 적합성 종합 점검
  • 체크리스트:
  • [ ] 서버/인프라 보안 설정 (OS 하드닝, 패치, 방화벽)
  • [ ] 네트워크 격리 (에어갭 영역과 네트워크 영역 분리)
  • [ ] 데이터 암호화 (전송 중 + 저장 시)
  • [ ] 접근 통제 (RBAC, MFA, IP 제한)
  • [ ] 모니터링/알림 (시스템, 보안 이벤트, 감사 로그)
  • [ ] 백업/복구 (정기 백업, 복구 테스트 완료)
  • [ ] 디바이스 무결성 (D'CENT X 봉인, 펌웨어 버전)
  • 산출물: 환경 감사 보고서 (적합/부적합 판정 + 부적합 항목 시정 계획)

Stage 2: 보안 강화

  • 테스트/POC 용도 설정 제거 및 프로덕션 보안 정책 적용
  • 조치 항목:
  • 테스트 계정 삭제 또는 비활성화
  • 디버그/로깅 레벨 프로덕션 수준으로 조정
  • 테스트용 API 키/토큰 폐기 및 재발급
  • SSL/TLS 인증서 프로덕션용으로 교체
  • 방화벽 규칙 프로덕션 수준으로 강화

Stage 3: 키 전환 결정

선택지 조건 장점 단점
기존 키 유지 메인넷 키가 이미 생성됨, 감사 추적 필요 연속성 보장, 추가 비용 없음 POC 이력이 프로덕션에 포함됨
새 키 세레모니 테스트넷 전용 키만 존재, 또는 깨끗한 시작 선호 깨끗한 출발점 키 세레모니 비용/시간 추가
  • 기존 키 유지 시: 감사 추적성 확인 (POC부터 연속된 로그 보존)
  • 새 키 세레모니 시: J-Step 5 절차 재실행

Stage 4: 정책 활성화

  • 프로덕션 정책 규칙으로 전환
  • 전환 항목:
  • 화이트리스트: 테스트 주소 제거, 프로덕션 주소만 등록
  • 금액 한도: 프로덕션 운영에 맞는 한도 설정
  • 시간 제약: 업무 시간/비업무 시간 정책 활성화
  • 승인 정족수: 프로덕션 M-of-N 설정 확인/조정
  • 알림 규칙: 프로덕션 알림 수신자 및 채널 설정

Stage 5: 자산 이전

  • 단계적 자산 이전으로 리스크를 최소화한다
단계 이전 비율 대기 시간 확인 사항
Step A 5% (소액) 24시간 수신 확인, 잔액 확인, 서명 기능 검증
Step B 20% (중액) 24시간 대량 이전 시 성능/안정성 확인
Step C 나머지 (대액) - 전체 이전 완료, 기존 보관소 잔액 zero
  • 각 단계 사이 24시간 대기: 블록 확인, 잔액 검증, 이상 없음 확인 후 다음 단계
  • 이상 발생 시: 즉시 이전 중단, 원인 분석, 시정 후 재개

Stage 6: 운영 전환 선언

  • 공식 프로덕션 운영 시작 선언
  • 선언 내용:
  • 프로덕션 운영 시작 일시
  • 운영 책임자 지정
  • SLA 적용 시작
  • 모니터링 강화 기간 진입 (J-Step 8)
  • 산출물: 프로덕션 전환 선언 문서 (CISO/CTO 서명)

7.4. Graduate in Place 불가 시나리오

다음 상황에서는 Graduate in Place를 적용할 수 없으며, 클린 프로덕션 구축 + 자산 마이그레이션이 필요하다:

# 불가 시나리오 사유 대안
1 POC가 테스트넷 전용 메인넷 키가 존재하지 않음 클린 구축 + 새 키 세레모니
2 배포 모델 변경 인프라 아키텍처가 근본적으로 다름 클린 구축 + 데이터 마이그레이션
3 보안 등급 2단계 이상 상향 인프라 보안 요건이 크게 다름 클린 구축 + 보안 환경 재구성
4 규제 요건으로 깨끗한 감사 추적 필요 POC 이력이 규제 감사에 부적합 클린 구축 + 새 감사 기록 시작
5 심각한 보안 이슈 발견 POC 환경 무결성 신뢰 불가 클린 구축 + 보안 점검 강화

불가 시 대안 절차:

  1. 새 프로덕션 환경 구축 (J-Step 4 재실행)
  2. 새 키 세레모니 (J-Step 5 재실행)
  3. 데이터 마이그레이션 (정책, 화이트리스트, 설정)
  4. 자산 마이그레이션 (기존 주소 -> 새 주소, 단계적 이전)
  5. 기존 POC 환경 폐기 (데이터 삭제, 디바이스 초기화)

8. 배포 모델별 시간 목표 분해

8.1. SaaS (목표: 7일)

단계 J-Step 설명 소요 시간 누적
Day-0 J-Step 1 초기 접촉 및 요구사항 수집 0.5일 0.5일
Day-0 J-Step 2 POC 환경 구성 (즉시 시작) 1일 1.5일
Day-0 J-Step 3 POC 평가 및 Go/No-Go 0.5일 2일
- Gate 1 POC -> 파일럿 전환 승인 0.5일 2.5일
Day-1 J-Step 4 환경 구축 (계정 설정만) 0.5일 3일
Day-1 J-Step 5 키 세레모니 1일 4일
Day-1 J-Step 6 파일럿 운영 2일 6일
Day-1 J-Step 7 프로덕션 전환 0.5일 6.5일
- Gate 2 파일럿 -> 프로덕션 전환 승인 0.5일 7일

SaaS 시간 단축 요인: - 인프라 구축 불필요 (D'CENT 클라우드 즉시 사용) - 셀프서비스 POC 가능 (영업팀 접촉 없이 시작 가능) - Graduate in Place가 가장 자연스러운 전환 방식

8.2. Hybrid (목표: 14일)

단계 J-Step 설명 소요 시간 누적
Day-0 J-Step 1 초기 접촉 및 요구사항 수집 1일 1일
Day-0 J-Step 2 POC 환경 구성 (하이브리드 구성) 2일 3일
Day-0 J-Step 3 POC 평가 및 Go/No-Go 1일 4일
- Gate 1 POC -> 파일럿 전환 승인 1일 5일
Day-1 J-Step 4 환경 구축 (온프레미스+클라우드) 3일 8일
Day-1 J-Step 5 키 세레모니 1일 9일
Day-1 J-Step 6 파일럿 운영 3일 12일
Day-1 J-Step 7 프로덕션 전환 1일 13일
- Gate 2 파일럿 -> 프로덕션 전환 승인 1일 14일

Hybrid 시간 요인: - 온프레미스 서명 환경 구축에 3일 소요 (서버 설정, VPN/mTLS 구성) - 클라우드-온프레미스 간 연동 검증 필요 - 파일럿 기간에 이중 환경(클라우드+온프레미스) 안정성 확인

8.3. Zero Cloud (목표: 30일)

단계 J-Step 설명 소요 시간 누적
Day-0 J-Step 1 초기 접촉 및 요구사항 수집 2일 2일
Day-0 J-Step 2 POC 환경 구성 (자체 인프라) 5일 7일
Day-0 J-Step 3 POC 평가 및 Go/No-Go 2일 9일
- Gate 1 POC -> 파일럿 전환 승인 1일 10일
Day-1 J-Step 4 환경 구축 (전체 인프라) 7일 17일
Day-1 J-Step 5 키 세레모니 2일 19일
Day-1 J-Step 6 파일럿 운영 7일 26일
Day-1 J-Step 7 프로덕션 전환 2일 28일
- Gate 2 파일럿 -> 프로덕션 전환 승인 2일 30일

Zero Cloud 시간 요인: - 블록체인 풀노드 동기화: BTC 3-5일, ETH 2-3일 (J-Step 4 병목) - 전체 인프라 자체 구축: 서버, 네트워크, 모니터링, 백업 (7일) - 파일럿 기간 연장: 풀노드 안정성, HA 페일오버 등 추가 검증 - 키 세레모니 2일: 콜드룸 사용 시 물리 보안 절차 추가

8.4. 시간 목표 비교 요약

SaaS (7일)      ████░░░░░░░░░░░░░░░░░░░░░░░░░░
Hybrid (14일)   ████████████████░░░░░░░░░░░░░░
Zero Cloud (30일) ██████████████████████████████████████████████████████████████
                 Day-0  |Gate1|      Day-1           |Gate2|  Day-N...
비교 항목 SaaS Hybrid Zero Cloud
Day-0 비율 29% (2일) 29% (4일) 30% (9일)
Day-1 비율 71% (5일) 71% (10일) 70% (21일)
최대 병목 키 세레모니 (1일) 환경 구축 (3일) 환경 구축+노드 동기화 (7일)
Gate 1 도달 2일 4일 9일
Gate 2 도달 7일 14일 30일
Graduate in Place 적합도 높음 중간 낮음 (인프라 재사용 가능 시 중간)

9. 문서 참조 규칙

9.1. 배포 모델 Delta 참조 형식

본 문서에서 배포 모델 고유 절차를 참조할 때는 다음 형식을 사용한다:

[Delta] Day-{0/1/N} J-Step {N}: {배포 모델명} 고유 절차 설명

예시: - [Delta] Day-0 J-Step 2: Zero Cloud POC 환경 구성 (자체 인프라) - [Delta] Day-1 J-Step 4: Hybrid 환경 구축 (온프레미스+클라우드) - [Delta] Day-N J-Step 10: SaaS 성장 경로 (Hybrid 상향 전환)

9.2. e2e-core-flow.md 참조 규칙

e2e-core-flow.md의 Step을 참조할 때는 원래 접두사를 유지한다:

  • A-Step N — Adoption 단계 Step
  • O-Step N — Onboarding 단계 Step
  • D-Step N — Daily Operations 단계 Step
  • M-Step N — Administration 단계 Step
  • E-Step N — Emergency Response 단계 Step

9.3. 시나리오 ID 참조

scenario-matrix.md의 시나리오 ID(S1~S8)를 참조할 때는 괄호 내 설명을 포함한다:

시나리오 구성 배포 모델 Delta 문서
S1 SC + Zero Cloud + 콜드룸 journey-delta-zero-cloud.md
S2 SC + Zero Cloud + 비콜드룸 journey-delta-zero-cloud.md
S3 SC + Hybrid + 비콜드룸 journey-delta-hybrid.md
S4 SC + SaaS + 비콜드룸 journey-delta-saas.md
S5 CSP + Zero Cloud + 콜드룸 journey-delta-zero-cloud.md
S6 CSP + Hybrid + 비콜드룸 journey-delta-hybrid.md
S7 TI + Hybrid + 비콜드룸 journey-delta-hybrid.md
S8 TI + SaaS + 비콜드룸 journey-delta-saas.md

9.4. CC-ID 및 Grade 참조

비콜드룸 보완 조치를 참조할 때는 non-coldroom-compensating-controls.md의 CC-ID를 사용한다: - CC-ID XX — 보완 조치 식별자 - Grade A/B/C — 비콜드룸 보안 등급

10. 핵심 원칙 요약

본 문서의 모든 여정 단계에 적용되는 핵심 원칙:

  1. 에어갭 불변: 어떤 여정 단계에서도, 어떤 배포 모델에서도 콜드월렛은 네트워크에 연결되지 않는다
  2. 키 주권: 프라이빗 키는 항상 고객의 D'CENT X SE 내부에만 존재한다. D'CENT는 키에 접근할 수 없다
  3. "Same digital flow, different physical envelope": 물리 환경(콜드룸/비콜드룸)은 디지털 플로우를 변경하지 않는다
  4. "시작은 쉽게, 성장은 자연스럽게": 대부분의 고객이 SaaS/Hybrid에서 시작하여 자연스럽게 상향 전환한다
  5. 단계적 검증: POC -> 파일럿 -> 프로덕션 각 단계에서 게이트를 통과해야 다음 단계로 진행한다
  6. 전환 시 불변 원칙 6개: 에어갭, 키 주권, 서명 프로토콜, WYSIWYS, 감사 로그 연속성, M-of-N 설정은 어떤 전환에서도 유지된다

Phase 12(scenario-matrix.md, transition-paths-document-structure.md), Phase 13(signing-core-flow.md), Phase 14(e2e-core-flow.md) 산출물을 기반으로 작성됨. 배포 모델별 고유 절차는 journey-delta-zero-cloud.md, journey-delta-hybrid.md, journey-delta-saas.md에서 상세화한다.

관련 문서