Problem
기업이 AI를 도입하면 결정의 속도는 빨라진다. 그러나 한 가지 질문에 답하지 못하게 된다.
"이 결정이 왜, 어떤 근거로, 누구의 승인 하에 내려졌는가?"
바우처 자동 승인 시스템을 예로 들자. AI가 신청서를 분석하고, 점수를 매기고, 승인을 내린다. 감사에서 6개월 전 승인 건에 대해 질문한다. 그런데 당시 적용된 정책은 이미 세 번 변경되었고, 담당자는 퇴사했으며, AI 모델은 업데이트되었다. 결정의 근거를 재구성하는 것은 사실상 불가능하다.
현재 대부분의 시스템이 가진 구조적 한계는 다음과 같다.
| 문제 | 현재 상태 | 실제 영향 |
|---|---|---|
| 결정 근거 부재 | 로그에 "승인됨"만 기록 | 감사 시 소명 불가 |
| 정책 버전 미추적 | 현재 정책만 존재 | 과거 결정의 적법성 검증 불가 |
| AI 판단 블랙박스 | 모델 출력값만 저장 | 신뢰도 점수의 맥락 상실 |
| 책임 소재 불명 | 승인자 ID만 기록 | 결정 체인의 추적 불가 |
| 무결성 미보장 | 일반 DB 레코드 | 사후 변조 탐지 불가능 |
이 문제는 단순히 로그를 더 많이 남기는 것으로 해결되지 않는다. 결정 자체를 증명 가능한 단위로 설계해야 한다.
Solution
Cronozen은 DPU(Decision Proof Unit) 라는 개념을 설계했다.
DPU는 하나의 결정에 대해 입력 데이터, 적용된 정책, AI 판단 근거, 승인 흐름, 해시 체인을 하나의 봉인된 단위(sealed unit)로 묶는 증명 구조체다. 결정이 내려지는 순간의 모든 맥락을 포착하여, 이후 어느 시점에서든 동일한 조건으로 결정의 정당성을 검증할 수 있도록 한다.
DPU의 핵심 설계 원칙은 세 가지다.
1. 결정 시점의 완전한 스냅샷 (Point-in-Time Capture)
DPU는 결정이 내려지는 순간 적용된 정책의 스냅샷을 함께 저장한다. 정책이 이후에 변경되더라도, 해당 결정이 당시 기준으로 적법했는지를 언제든 검증할 수 있다.
2. 해시 체인 기반 무결성 (Hash Chain Integrity)
모든 DPU는 이전 DPU의 해시를 참조하여 순차적으로 연결된다. 체인 중간의 어떤 기록이라도 변조되면 이후 모든 해시가 불일치하게 되어 즉시 탐지된다. 블록체인의 원리를 차용하되, 블록체인의 비용과 복잡성은 배제했다.
3. 거버넌스 가드에 의한 강제 통제 (Governance Guards)
DPU가 생성되기 전에 반드시 통과해야 하는 일련의 검증 단계가 존재한다. 증거 수준, 인간 검토, 리스크 임계값, 이중 승인 등 — 정책으로 정의된 조건을 모두 충족해야만 DPU가 봉인된다.
┌─────────────────────────────────────────────────┐
│ DPU (Decision Proof Unit) │
│ │
│ ┌──────────┐ ┌──────────┐ ┌───────────────┐ │
│ │ 입력 데이터 │ │ AI 판단 │ │ 정책 스냅샷 │ │
│ │ Evidence │ │ AI Output │ │ Policy v2.3 │ │
│ └──────────┘ └──────────┘ └───────────────┘ │
│ │
│ ┌──────────┐ ┌──────────┐ ┌───────────────┐ │
│ │ 승인 체인 │ │ 리스크 등급│ │ 해시 체인 링크 │ │
│ │ Approvals│ │ Risk Level│ │ Chain Hash │ │
│ └──────────┘ └──────────┘ └───────────────┘ │
│ │
│ ═══════════════════════════════════════════════ │
│ Sealed Envelope | Hash: a7f3... | Immutable │
└─────────────────────────────────────────────────┘
Architecture
DPU 시스템은 세 개의 독립된 계층으로 구성된다. 각 계층은 명확한 책임 경계를 가지며, 외부 의존성 없이 동작하도록 설계되었다.
계층 구조
┌─────────────────────────────────────────────────────────┐
│ DPU Pro Layer │
│ │
│ Governance Guards · Compliance Engine · Audit │
│ 정책 준수 강제 · 규제 상태 판정 · 책임 추적 │
├─────────────────────────────────────────────────────────┤
│ DPU Core Layer │
│ │
│ Hash Chain · Canonicalization · Envelope · Policy │
│ 순수 연산 · 외부 의존성 제로 · 결정론적 출력 │
├─────────────────────────────────────────────────────────┤
│ Connector Layer │
│ │
│ Storage Adapter Interface → Prisma / PostgreSQL │
│ 데이터베이스 불가지론 · 구현체 교체 가능 │
└─────────────────────────────────────────────────────────┘
DPU Core — 순수 연산 엔진
DPU Core는 외부 의존성이 전혀 없는 순수 계산 엔진이다. 이 설계 선택은 의도적이다.
- Hash Chain 연산: 각 DPU는 이전 DPU의 해시를 입력으로 받아 순차적으로 연결된다. 체인의 무결성은 어느 시점에서든 독립적으로 검증할 수 있다.
- Canonicalization: 동일한 데이터가 시스템, 시간, 환경에 관계없이 항상 동일한 해시를 생성하도록 정규화한다. JSON 키 순서, 공백, 인코딩 차이로 인한 해시 불일치를 원천 차단한다.
- Policy Hash: 정책 문서 자체를 해싱하여 무결성을 보장한다. 생성 시점의 정책 해시와 현재 정책 해시를 비교하면, 정책 변경 여부를 즉시 확인할 수 있다.
- Envelope 생성: 모든 구성 요소를 하나의 봉인된 단위로 패키징한다. 봉인 이후에는 내용 변경이 해시 불일치로 즉시 드러난다.
Core가 외부 의존성을 갖지 않는 이유는 명확하다. 증명의 신뢰성은 계산의 결정론성에 의존한다. 동일한 입력은 언제, 어디서든 동일한 출력을 생성해야 하며, 외부 라이브러리의 버전 변경이 해시 결과를 바꿔서는 안 된다.
DPU Pro — 거버넌스 계층
DPU Pro는 Core 위에 조직의 거버넌스 규칙을 강제하는 계층이다. 5개의 Governance Guard가 순차적으로 실행되며, 하나라도 실패하면 DPU는 생성되지 않는다.
요청 ──→ Guard 1 ──→ Guard 2 ──→ Guard 3 ──→ Guard 4 ──→ Guard 5 ──→ DPU 봉인
│ │ │ │ │
증거 수준 인간 검토 리스크 이중 승인 추가 검증
검증 필수 여부 임계값 확인 요구 확인
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
실패 시 실패 시 실패 시 실패 시 실패 시
즉시 중단 즉시 중단 즉시 중단 즉시 중단 즉시 중단
Guard 1 — Evidence Level 검증
증거의 완전성을 세 단계로 평가한다.
| 수준 | 의미 | DPU 생성 가능 여부 |
|---|---|---|
DRAFT |
초안 수준, 핵심 증거 미비 | 정책에 따라 제한적 |
PARTIAL |
일부 증거 확보, 보완 필요 | 정책에 따라 조건부 |
AUDIT_READY |
감사 대응 가능한 완전한 증거 | 허용 |
Guard 2 — Human Review 검증
AI 판단에 대한 인간 검토가 정책상 필수인 경우, 검토 완료 여부를 확인한다. AI의 동작 모드(AIMode)에 따라 요구 수준이 달라진다.
| AI 동작 모드 | 설명 | 인간 검토 요구 수준 |
|---|---|---|
RECOMMENDATION |
AI가 추천만 제시 | 낮음 |
ANALYSIS / CLASSIFICATION |
AI가 분석/분류 수행 | 중간 |
DRAFT_GENERATION |
AI가 초안 작성 | 중간 |
PREDICTION |
AI가 예측 수행 | 높음 |
AUTONOMOUS |
AI가 자율적으로 결정 | 최고 — 반드시 인간 승인 필요 |
Guard 3 — Risk Threshold 검증
결정의 리스크 수준이 정책에서 허용하는 임계값 이내인지 확인한다. LOW, MEDIUM, HIGH, CRITICAL 네 단계로 구분되며, 데이터 민감도 수준(PUBLIC, INTERNAL, PII, PHI)과 결합하여 평가된다.
Guard 4 — Dual Approval 검증
고위험 결정에 대해 두 명 이상의 승인자가 서명했는지 확인한다. 단일 승인자의 판단 오류로 인한 리스크를 구조적으로 차단한다.
Connector Layer — 저장소 추상화
DPU Core는 DPUStorageAdapter라는 인터페이스를 정의한다. 이 인터페이스를 구현하는 것은 Connector의 책임이다. 현재 Prisma + PostgreSQL 구현체가 제공되며, Core는 Prisma의 존재를 알지 못한다.
DPU Core Connector Database
│ │ │
│ save(envelope) │ │
│ ─────────────────────→ │ │
│ │ INSERT INTO │
│ │ decision_proof_units │
│ │ ──────────────────→ │
│ │ │
│ verify(id) │ │
│ ─────────────────────→ │ │
│ │ SELECT + Hash Check │
│ │ ──────────────────→ │
│ result │ record │
│ ←───────────────────── │ ←────────────────── │
이 설계 덕분에 PostgreSQL을 MongoDB, DynamoDB, 혹은 파일 시스템으로 교체하더라도 Core와 Pro 계층의 코드는 한 줄도 변경할 필요가 없다.
Flow
바우처 자동 승인 시스템에서 하나의 신청서가 DPU로 봉인되기까지의 전체 흐름을 추적한다.
[1] 신청서 접수
│
▼
[2] Auto Decision Engine 분석
├── 서류 완전성 점수 산출
├── 신청자 신뢰도 평가
├── 정책 준수 여부 확인
└── 종합 신뢰도(Confidence Score) 계산
│
▼
[3] 분기 판정
├── 신뢰도 90% 이상 ──→ 자동 승인 경로
└── 신뢰도 90% 미만 ──→ 인간 검토 에스컬레이션
│
▼
[4] 정책 스냅샷 생성
└── 현재 시점의 정책을 캡처하여 동결
│
▼
[5] Governance Guards 순차 실행
├── [G1] 증거 수준: AUDIT_READY 확인 ── PASS
├── [G2] 인간 검토: 자동 승인이므로 정책 확인 ── PASS
├── [G3] 리스크 임계값: LOW 확인 ── PASS
├── [G4] 이중 승인: 저위험이므로 면제 ── PASS
└── [G5] 추가 검증 ── PASS
│
▼
[6] DPU Envelope 생성
├── 입력 데이터 + AI 판단 + 정책 스냅샷 통합
├── 이전 DPU 해시 참조하여 체인 연결
├── Canonicalization 적용 후 해시 생성
└── 봉인(Seal)
│
▼
[7] 저장 및 연결
├── decision_proof_units 테이블에 기록
├── ai_decision_logs에 AI 판단 이력 기록
├── decision_proof_audit_logs에 감사 로그 기록
└── 원본 엔티티에 dpu_id 연결
이 흐름에서 주목할 점은 단계 [4]의 정책 스냅샷이다. 3개월 후 감사에서 이 결정을 질문하면, 시스템은 현재 정책이 아닌 당시 스냅샷된 정책과 비교하여 적법성을 검증한다.
Example
6개월 전 자동 승인된 바우처 건에 대해 내부 감사가 진행되는 시나리오를 살펴본다.
감사 질문: "이 승인은 당시 정책에 부합했는가?"
기존 시스템의 대응:
감사관: "2025년 8월 승인 건 KR-2025-08-1847에 대해 설명해 주십시오."
담당자: "로그를 확인하겠습니다... '승인됨'이라고만 되어 있습니다."
감사관: "당시 어떤 정책이 적용되었습니까?"
담당자: "현재 정책은 있는데, 당시 정책은... 확인이 어렵습니다."
감사관: "AI가 어떤 근거로 판단했습니까?"
담당자: "확인할 수 없습니다."
→ 결과: 감사 지적, 시정 조치 요구
DPU 기반 시스템의 대응:
감사관: "2025년 8월 승인 건 KR-2025-08-1847에 대해 설명해 주십시오."
시스템 조회 결과:
┌─ DPU #1847 ──────────────────────────────────────────┐
│ │
│ 결정: 바우처 자동 승인 │
│ 일시: 2025-08-14 09:23:17 KST │
│ │
│ ■ AI 판단 │
│ 모드: RECOMMENDATION │
│ 신뢰도: 94.2% │
│ 요인: 서류 완전성 97% · 신청자 신뢰도 91% · 정책 준수 95% │
│ │
│ ■ 적용 정책 │
│ Policy v2.1 (해시: b4e2...) │
│ 현재 정책: v3.0 (해시: d8a1...) │
│ 정책 변경 감지: Yes — 그러나 v2.1 기준 적법 │
│ │
│ ■ Governance Guards 결과 │
│ 증거 수준: AUDIT_READY ✓ │
│ 인간 검토: 면제 (RECOMMENDATION 모드) ✓ │
│ 리스크: LOW ✓ │
│ 이중 승인: 면제 (저위험) ✓ │
│ │
│ ■ 해시 체인 │
│ 이전: DPU #1846 (해시: 7c9f...) │
│ 현재: a7f3e2... │
│ 체인 무결성: PASSED │
│ │
│ ■ 감사 상태 │
│ Compliance Status: PASSED │
│ Audit Status: PENDING → 검토 가능 │
│ │
│ ■ Responsibility Graph │
│ 신청 접수 → Auto Decision Engine → Guard 검증 → │
│ DPU 봉인 → 시스템 자동 승인 │
│ │
└───────────────────────────────────────────────────────┘
→ 결과: 당시 정책 v2.1 기준 적법함을 즉시 증명. 감사 통과.
Result
DPU Engine이 조직에 가져오는 변화를 정리한다.
정량적 효과
| 지표 | DPU 도입 전 | DPU 도입 후 |
|---|---|---|
| 감사 대응 소요 시간 | 수일~수주 | 즉시 조회 |
| 과거 결정 재검증 | 사실상 불가 | 정책 스냅샷 기반 자동 검증 |
| 데이터 변조 탐지 | 불가 | 해시 체인으로 즉시 탐지 |
| AI 판단 추적성 | 결과값만 존재 | 모드·신뢰도·요인 완전 기록 |
| 책임 소재 추적 | 승인자 ID만 기록 | Responsibility Graph로 전체 체인 추적 |
설계 원칙의 실현
증명 가능성 (Provability) — 모든 결정은 생성 시점의 맥락과 함께 봉인된다. "왜 이 결정이 내려졌는가"에 대해 기술적으로 완전한 답변이 가능하다.
변조 불가성 (Tamper Evidence) — 해시 체인으로 연결된 DPU는 단 하나의 레코드라도 변조되면 체인 전체가 불일치를 보고한다. 변조를 막는 것이 아니라, 변조를 숨길 수 없게 만든다.
시간 독립성 (Temporal Independence) — 정책이 변경되어도, 담당자가 퇴사해도, AI 모델이 업데이트되어도, 과거 결정의 정당성은 당시 스냅샷으로 독립적으로 검증된다.
저장소 불가지론 (Storage Agnosticism) — 증명의 핵심 로직은 특정 데이터베이스에 종속되지 않는다. PostgreSQL에서 시작하되, 조직의 인프라 변화에 유연하게 대응한다.
Roadmap
DPU Engine은 현재 v0.1.0이다. 핵심 개념의 구현이 완료되었으며, 다음 단계에서는 실시간 체인 검증 대시보드, 멀티 테넌트 정책 관리, 외부 감사 기관 연동 API를 계획하고 있다.
DPU는 로그가 아니다. 증명이다.
로그는 "무엇이 일어났는가"를 기록한다. DPU는 "왜 이 결정이 정당한가"를 증명한다. 이 차이가 감사에서 소명과 증명의 차이를 만든다.
Cronozen Living Technical Spec Series #1 시스템 아키텍처 — 왜 AI 거버넌스에 모노레포가 필요한가 #2 DPU Engine Concept — 모든 결정에 증명을 남기다 ← 현재 문서