Proof Pipeline — 5단계 증빙 파이프라인

Problem

공공 서비스 영역에서 "이 판단이 적법했는가?"라는 질문에 답하지 못하는 시스템이 너무 많다.

복지관에서 바우처를 승인하고, 재활센터에서 치료 세션을 기록하고, 지역 상권에서 쿠폰을 정산할 때 — 모든 의사결정은 감사 가능해야 한다. 하지만 현실은 다르다.

현재 대부분의 시스템이 가진 구조적 결함:

문제	결과
판단 근거가 로그에 흩어져 있다	감사 시 재구성 불가
정책 버전이 기록되지 않는다	"당시 기준" 검증 불가
승인 흐름이 비구조적이다	책임 소재 불명확
데이터 무결성 보장이 없다	사후 위변조 탐지 불가
AI 개입 여부가 불투명하다	규제 대응 불가

감사 대응은 언제나 사후적이다. 사건이 터지면 개발팀이 로그를 뒤지고, 데이터베이스를 조회하고, 담당자의 기억에 의존한다. 이 과정에서 수 주가 소요되며, 결과의 신뢰도는 낮다.

Cronozen은 이 문제를 설계 단계에서 해결한다. 모든 의사결정이 생성되는 순간, 그 증명이 함께 만들어지는 구조 — Proof Pipeline이 그것이다.

Solution

Proof Pipeline은 5단계 파이프라인으로 구성된 증명 생성 엔진이다.

핵심 원칙은 단순하다: 의사결정과 그 증명은 동시에 생성되어야 한다. 사후 보고서가 아니라, 판단이 이루어지는 바로 그 트랜잭션 안에서 증명이 함께 만들어진다.

이 파이프라인은 DPU(Decision Proof Unit)라는 단위를 출력한다. 하나의 DPU는 하나의 의사결정에 대한 완전한 증명 패키지다. 누가 판단했는지, 어떤 정책 아래에서 판단했는지, 어떤 근거로 판단했는지, AI가 개입했다면 어떤 방식으로 개입했는지 — 모두 하나의 봉인된 단위에 담긴다.

Before / After 비교:

관점	Before (기존 시스템)	After (Proof Pipeline)
감사 대응 시간	수 주 (로그 재구성)	즉시 (DPU 조회)
정책 추적	"아마 이 정책이었을 것이다"	Policy Snapshot으로 당시 기준 재현
책임 소재	불명확 (로그 해석 필요)	Responsibility Graph로 명시
데이터 무결성	보장 없음	SHA-256 Hash Chain
AI 거버넌스	없음	AI Mode + Risk Threshold 연동
Evidence 등급	단일 (있거나 없거나)	DRAFT → PARTIAL → AUDIT_READY 3단계 진행

Architecture

Proof Pipeline의 5단계는 순차적으로 실행되며, 어느 한 단계라도 실패하면 DPU 생성이 거부되고 그 사실 자체가 기록된다.

 ┌─────────────────────────────────────────────────────────────┐
 │                    PROOF PIPELINE                           │
 │                                                             │
 │  ┌──────────┐   ┌──────────┐   ┌──────────┐                │
 │  │ Stage 1  │──▶│ Stage 2  │──▶│ Stage 3  │                │
 │  │ Evidence │   │ Policy   │   │ Guard    │                │
 │  │Collection│   │ Matching │   │Validation│                │
 │  └──────────┘   └──────────┘   └────┬─────┘                │
 │                                     │                       │
 │                                     ▼                       │
 │                              ┌──────────┐   ┌──────────┐   │
 │                              │ Stage 4  │──▶│ Stage 5  │   │
 │                              │Hash Chain│   │  Audit   │   │
 │                              │ Sealing  │   │  Ready   │   │
 │                              └──────────┘   └──────────┘   │
 │                                                             │
 └─────────────────────────────────────────────────────────────┘
       ↑                                            │
   Input Sources                              DPU Output
   (User / AI /                          (Sealed, Chained,
    Voice / System)                        Audit-Ready)

각 Stage의 역할:

Stage 1 — Evidence Collection (증거 수집)

모든 증명은 증거에서 시작된다. 이 단계에서는 다양한 소스로부터 데이터를 수집하고 구조화한다.

• 입력 소스: 사용자 직접 입력, 시스템 이벤트, AI 분석 결과, 음성 입력
• 6W 추출: 모든 증거에서 Who, What, When, Where, Why, How를 자동 추출
• 데이터 민감도 분류: PUBLIC, INTERNAL, PII, PHI 4단계 자동 분류
• 음성 입력 시: 오디오 해시(SHA-256) 생성 → STT 전사 → 전사 신뢰도 점수 기록

6W 추출은 Proof Pipeline의 핵심 설계다. 복지관 사례 기록에서든, 약국 교품거래에서든, 쿠폰 사용 내역에서든 — 동일한 6W 구조로 정규화된다. 이것이 도메인을 가로지르는 통합 감사를 가능하게 한다.

  6W Structure (모든 DPU 공통)
  ┌───────────────────────────────────────┐
  │  Who   │ 행위자 이름, 역할, ID         │
  │  What  │ 행위, 설명, 카테고리          │
  │  When  │ 타임스탬프, 시간대            │
  │  Where │ 위치, 시스템, 컨텍스트        │
  │  Why   │ 사유, 정책 참조, 증빙 참조    │
  │  How   │ 방법, 도구, AI 개입 여부      │
  └───────────────────────────────────────┘

Stage 2 — Policy Matching (정책 매칭)

증거가 수집되면 해당 도메인의 활성 정책과 매칭된다.

• 정책 스코프: Global → Country → Region → Center 계층 구조
• 시간 유효성: validFrom, validUntil로 시간 범위 검증
• 조건 기반 액션: 정책 조건 충족 시 자동으로 후속 액션 트리거
• 충돌 해소: 동일 도메인 내 복수 정책은 우선순위 기반으로 해소
• 성능 최적화: 정책 규칙에 인덱스를 부여하여 매칭 속도 보장

중요한 점은, 매칭된 정책의 스냅샷이 이 시점에서 생성된다는 것이다. 정책은 시간이 지나면서 변경될 수 있지만, DPU에 기록된 Policy Snapshot은 "판단 당시의 정책"을 영구적으로 보존한다. 6개월 후 감사가 들어와도, 당시 적용된 정책 버전을 정확히 재현할 수 있다.

Stage 3 — Guard Validation (5 Governance Guards)

이것이 Proof Pipeline의 관문이다. 5개의 독립적인 Guard가 순차적으로 검증을 수행하며, 하나라도 실패하면 DPU 생성이 거부된다.

  5 Governance Guards
  ═══════════════════════════════════════════════════════

  Guard 1: Evidence Level Guard
  ┌─────────────────────────────────────────────────┐
  │  DRAFT ──────▶ PARTIAL ──────▶ AUDIT_READY      │
  │  (내부참고)     (부분증빙)      (감사대응가능)     │
  │                                                  │
  │  정책이 요구하는 최소 Evidence Level 충족 여부     │
  │  PHI 데이터 → AUDIT_READY 강제                   │
  └─────────────────────────────────────────────────┘

  Guard 2: Human Review Guard
  ┌─────────────────────────────────────────────────┐
  │  민감한 판단에 대한 인간 검토 강제                │
  │  - 검토자 ID + 역할 + 승인 시각 필수             │
  │  - 승인자 역할이 정책에 정의된 역할과 일치해야 함  │
  └─────────────────────────────────────────────────┘

  Guard 3: Risk Threshold Guard
  ┌─────────────────────────────────────────────────┐
  │  LOW ─── MEDIUM ─── HIGH ─── CRITICAL           │
  │                                                  │
  │  HIGH/CRITICAL → AI 자율(AUTONOMOUS) 모드 차단   │
  │  CRITICAL → 최소 2인 승인 강제                   │
  └─────────────────────────────────────────────────┘

  Guard 4: Dual Approval Guard
  ┌─────────────────────────────────────────────────┐
  │  정책이 2인 이상 승인을 요구하는 경우:            │
  │  - 첫 번째 승인자 + 두 번째 승인자 모두 필수     │
  │  - 동일인 승인 방지 (self-approval 차단)         │
  └─────────────────────────────────────────────────┘

  Guard 5: Compliance Logging Guard
  ┌─────────────────────────────────────────────────┐
  │  모든 Guard 실패를 감사 로그에 자동 기록          │
  │  - 실패 사유, 시도자, 시도 시각, 정책 코드       │
  │  - DENIED 로그는 삭제 불가                       │
  │  → Guard를 우회하려는 시도 자체가 증거가 된다     │
  └─────────────────────────────────────────────────┘

  ═══════════════════════════════════════════════════════

Guard 구조가 중요한 이유는 이것이다: DPU가 존재한다는 것 자체가 5개 Guard를 모두 통과했다는 증명이다. 감사관은 DPU의 존재만으로 정책 준수 여부를 확인할 수 있다.

Stage 4 — Hash Chain Sealing (해시 체인 봉인)

모든 Guard를 통과한 증거는 Hash Chain에 연결되어 봉인된다.

  Hash Chain Structure (도메인별 독립 체인)
  ════════════════════════════════════════════

  [Genesis DPU]     [DPU #1]          [DPU #2]
  ┌───────────┐    ┌───────────┐    ┌───────────┐
  │ index: 0  │    │ index: 1  │    │ index: 2  │
  │ prevHash: │    │ prevHash: │    │ prevHash: │
  │  GENESIS  │◀───│  hash_0   │◀───│  hash_1   │
  │ chainHash:│    │ chainHash:│    │ chainHash:│
  │  hash_0   │    │  hash_1   │    │  hash_2   │
  │ policy:   │    │ policy:   │    │ policy:   │
  │ snapshot_0│    │ snapshot_1│    │ snapshot_2│
  └───────────┘    └───────────┘    └───────────┘

  chainHash = SHA-256(content + previousHash + timestamp)

  ════════════════════════════════════════════

이 단계에서 수행되는 핵심 연산:

• computeChainHash(): 현재 DPU의 내용 + 이전 DPU의 해시 + 타임스탬프를 결합하여 새 해시 생성. JSON 키 정렬(canonicalization) 후 SHA-256을 적용하여 데이터 순서에 무관한 일관된 해시를 보장
• generatePolicyHash(): 매칭된 정책의 버전, 설정, 민감도 레벨을 포함한 스냅샷을 별도로 해싱
• createDPUEnvelope(): 모든 증거, 정책 스냅샷, 해시 체인 링크를 하나의 위변조 방지 단위로 패키징

Hash Chain은 도메인별로 독립적으로 운영된다. 복지 도메인의 체인과 약국 도메인의 체인은 서로 간섭하지 않으면서, 동시 접근 시 Serializable 트랜잭션으로 체인 인덱스 충돌을 방지한다.

Stage 5 — Audit-Ready Output (감사 준비 완료)

봉인된 DPU는 즉시 감사 가능한 상태로 저장된다.

• 감사 상태 추적: PENDING → PASSED / DENIED / FLAGGED
• Responsibility Graph: 의사결정에 관여한 모든 행위자(인간 + AI)의 역할과 책임 범위를 그래프로 추적
• verifyHashChain(): 언제든 체인 전체의 무결성을 검증 — 중간에 하나라도 변조되면 그 이후 모든 해시가 불일치
• verifyDPUWithOriginalPolicy(): DPU에 기록된 Policy Snapshot과 현재 정책을 비교하여, "당시 기준" 준수 여부를 재검증

Flow

실제 운영 환경에서 하나의 판단이 DPU로 변환되는 전체 흐름이다.

  사용자 행위 (또는 시스템 이벤트)
       │
       ▼
  ┌─────────────────────────────────────────┐
  │ Stage 1: Evidence Collection            │
  │                                         │
  │  입력 소스 확인                          │
  │    ├─ 텍스트 입력 → 직접 구조화          │
  │    ├─ 시스템 이벤트 → 자동 캡처          │
  │    └─ 음성 입력 → SHA-256 해싱           │
  │                  → STT 전사              │
  │                  → 신뢰도 점수 기록       │
  │                                         │
  │  6W 추출                                │
  │    ├─ 수동 (manual)                     │
  │    ├─ LLM 자동 추출 (llm_extracted)     │
  │    └─ 음성 기반 추출 (voice_extracted)   │
  │                                         │
  │  DataSensitivityLevel 분류              │
  │    └─ PUBLIC / INTERNAL / PII / PHI     │
  └────────────────┬────────────────────────┘
                   │
                   ▼
  ┌─────────────────────────────────────────┐
  │ Stage 2: Policy Matching                │
  │                                         │
  │  도메인별 활성 정책 검색                  │
  │    ├─ effective_from ≤ NOW              │
  │    ├─ effective_until ≥ NOW (또는 null)  │
  │    └─ 우선순위 기반 정렬                 │
  │                                         │
  │  Policy Snapshot 생성                   │
  │    └─ 정책 코드, 버전, 설정, 민감도      │
  │       → SHA-256 해싱하여 별도 보존       │
  └────────────────┬────────────────────────┘
                   │
                   ▼
  ┌─────────────────────────────────────────┐
  │ Stage 3: Guard Validation               │
  │                                         │
  │  Guard 1 → Evidence Level 충족?         │
  │    ├─ Pass → 다음 Guard                 │
  │    └─ Fail → DENY + 로그 기록 → 종료    │
  │                                         │
  │  Guard 2 → Human Review 충족?           │
  │    ├─ Pass → 다음 Guard                 │
  │    └─ Fail → DENY + 로그 기록 → 종료    │
  │                                         │
  │  Guard 3 → Risk Threshold 충족?         │
  │    ├─ Pass → 다음 Guard                 │
  │    └─ Fail → DENY + 로그 기록 → 종료    │
  │                                         │
  │  Guard 4 → Dual Approval 충족?          │
  │    ├─ Pass → 다음 Guard                 │
  │    └─ Fail → DENY + 로그 기록 → 종료    │
  │                                         │
  │  Guard 5 → 전체 결과 기록               │
  │    └─ 통과/거부 모두 감사 로그에 기록    │
  └────────────────┬────────────────────────┘
                   │
                   ▼
  ┌─────────────────────────────────────────┐
  │ Stage 4: Hash Chain Sealing             │
  │                                         │
  │  도메인 체인의 최신 해시 조회             │
  │    └─ Serializable 트랜잭션으로 동시성   │
  │       충돌 방지                          │
  │                                         │
  │  chainHash 계산                         │
  │    └─ SHA-256(content + prevHash + ts)  │
  │                                         │
  │  DPU Envelope 생성                      │
  │    └─ 증거 + 정책 스냅샷 + 체인 링크     │
  │       → 단일 레코드로 패키징             │
  └────────────────┬────────────────────────┘
                   │
                   ▼
  ┌─────────────────────────────────────────┐
  │ Stage 5: Audit-Ready Output             │
  │                                         │
  │  DPU 저장 (audit_status: PENDING)       │
  │  감사 성공 로그 생성                     │
  │  Responsibility Graph 구성 가능          │
  │                                         │
  │  이후 언제든:                            │
  │    ├─ verifyHashChain() → 무결성 검증   │
  │    ├─ verifyDPUWithOriginalPolicy()     │
  │    │   → 당시 정책 기준 재검증           │
  │    └─ Responsibility Graph 조회         │
  │       → 행위자별 책임 추적               │
  └─────────────────────────────────────────┘

Example

Proof Pipeline이 세 가지 실제 도메인에서 어떻게 작동하는지 살펴본다.

---

사례 1: 재활 — 바우처 승인부터 치료 기록까지

재활센터에서 치료사가 바우처를 승인하고, 치료 세션을 진행하고, 진행 상황을 기록하는 전체 과정이다.

  바우처 승인 요청
       │
       ▼
  [DPU #0] 바우처 승인
  ├─ 6W: Who=치료사, What=바우처승인, Why=치료계획
  ├─ Evidence Level: PARTIAL
  ├─ Guard: Human Review 통과 (치료사 승인)
  ├─ Guard: Risk=MEDIUM (의료 판단)
  └─ Chain: hash_0 (Genesis)
       │
       ▼
  [DPU #1] 치료 세션 기록
  ├─ 6W: Who=치료사, What=세션진행, How=음성입력
  ├─ Voice: transcript + confidence 0.94
  ├─ Audio Hash: SHA-256(원본 음성)
  ├─ Evidence Level: PARTIAL → AUDIT_READY (세션 완료 후)
  └─ Chain: hash_1 ← hash_0
       │
       ▼
  [DPU #2] 진행 추적 평가
  ├─ 6W: Who=수퍼바이저, What=진행평가
  ├─ Guard: Dual Approval (치료사 + 수퍼바이저)
  ├─ Evidence Level: AUDIT_READY
  └─ Chain: hash_2 ← hash_1

  → 3개의 DPU가 하나의 Hash Chain으로 연결
  → 바우처 사용 전 과정이 감사 가능

---

사례 2: 복지 — 급여 신청에서 지급까지

복지관에서 수급자의 급여 신청을 접수하고, 자격을 확인하고, 지급을 결정하는 흐름이다.

  급여 신청 접수
       │
       ▼
  [DPU #0] 사례 등록 (CASE_REGISTERED)
  ├─ 6W: Who=복지사, What=사례등록, Why=급여신청
  ├─ Evidence Level: DRAFT
  ├─ DataSensitivity: PII
  ├─ Risk: MEDIUM
  └─ Chain: hash_0 (Genesis)
       │
       ▼
  [DPU #1] 자격 심사 (ASSESSMENT_COMPLETED)
  ├─ 6W: Who=복지사, What=자격심사, How=AI분석보조
  ├─ AI Mode: RECOMMENDATION (AI가 추천, 인간이 결정)
  ├─ Guard: Human Review 통과 (복지사 확인)
  ├─ Evidence Level: PARTIAL
  └─ Chain: hash_1 ← hash_0
       │
       ▼
  [DPU #2] 지급 결정 (CONTRACT_SIGNED)
  ├─ 6W: Who=팀장+복지사, What=지급승인
  ├─ Guard: Dual Approval 통과 (복지사 + 팀장)
  ├─ Guard: Risk Threshold 검증
  ├─ Evidence Level: AUDIT_READY
  ├─ Policy Snapshot: 급여 지급 정책 v2.3 기록
  └─ Chain: hash_2 ← hash_1

  → AI 추천이 있었음에도 인간이 최종 판단
  → 감사 시 AI 개입 범위와 인간 판단 영역이 명확히 분리됨

---

사례 3: 지역 상권 — 쿠폰 발행에서 정산까지

지역 상권에서 이벤트 쿠폰을 발행하고, 고객이 사용하고, 가맹점에 정산하는 과정이다.

  이벤트 쿠폰 발행
       │
       ▼
  [DPU #0] 쿠폰 발급 (COUPON_EVENT_CLAIM)
  ├─ 6W: Who=고객, What=이벤트쿠폰수령, Where=이벤트페이지
  ├─ Evidence Level: DRAFT
  ├─ Risk: LOW (금액 소규모)
  └─ Chain: hash_0 (Genesis)
       │
       ▼
  [DPU #1] 쿠폰 사용 (COUPON_QR_USE)
  ├─ 6W: Who=가맹점, What=QR스캔사용, How=QR_SCAN
  ├─ Evidence: serial_number, discount_amount 기록
  ├─ Evidence Level: DRAFT
  └─ Chain: hash_1 ← hash_0
       │
       ▼
  [DPU #2] 정산 처리
  ├─ 6W: Who=시스템, What=정산, Why=쿠폰사용확정
  ├─ Evidence Level: AUDIT_READY
  ├─ 정산 금액, 가맹점 정보, 원가 기록
  └─ Chain: hash_2 ← hash_1

  → 쿠폰 1장의 전 생애주기가 DPU Chain으로 추적 가능
  → 지자체 보조금 감사 시 쿠폰별 정산 근거 즉시 제출

---

세 사례에서 공통적으로 드러나는 패턴:

패턴	설명
Chain 연결	모든 도메인에서 DPU는 Hash Chain으로 순서를 보장한다
Evidence 진행	DRAFT → PARTIAL → AUDIT_READY로 증빙 등급이 성숙된다
6W 정규화	도메인이 달라도 동일한 6W 구조로 통합 감사가 가능하다
Policy Snapshot	판단 당시 정책이 DPU 안에 영구 보존된다
Non-blocking	DPU 생성 실패가 업무 흐름을 차단하지 않는다

Result

Proof Pipeline은 다음을 달성한다.

감사 대응의 패러다임 전환:

감사가 "조사"에서 "조회"로 바뀐다. DPU가 존재하면 정책을 준수한 것이고, DPU가 거부되었으면 그 거부 사실과 사유가 기록되어 있다. 감사관이 로그를 재구성하거나 담당자를 인터뷰할 필요가 없다.

구조적 보장:

보장 항목	메커니즘
무결성	SHA-256 Hash Chain — 체인 중간 변조 시 이후 전체 불일치
시점 정합성	Policy Snapshot — 판단 시점의 정책을 DPU에 봉인
책임 추적	Responsibility Graph — 인간/AI 역할을 명시적으로 분리
증빙 성숙도	Evidence Level 3단계 — DRAFT에서 시작, AUDIT_READY로 진행
우회 방지	Guard 실패 자체가 DENIED 로그로 영구 기록
도메인 독립성	6W 정규화 — 재활, 복지, 상권이 동일 구조로 감사 가능

투자자와 심사위원에게 의미하는 것:

Proof Pipeline은 Cronozen이 "규정 준수를 보고하는 시스템"이 아니라 "규정 준수를 구조적으로 보장하는 시스템"임을 증명한다. 정책이 변경되어도 과거 판단의 적법성은 보존되고, AI가 개입해도 인간의 최종 판단권이 Guard로 강제되며, 모든 의사결정은 생성 순간부터 감사 가능한 상태로 존재한다.

이것이 compliance-by-design이다. 사후 대응이 아닌, 설계에 내재된 규정 준수.

---

Living Technical Spec #3 — Proof Pipeline Cronozen Decision Proof Architecture