Problem

시장에는 이미 수많은 SaaS가 존재한다. 센터 관리, 복지 행정, 상권 관리 각각을 위한 솔루션이 있고, AI를 탑재했다고 말하는 제품도 늘고 있다.

하지만 이 질문에 답할 수 있는 시스템은 거의 없다.

"이 결정이 AI에 의한 것이었다면, 그 판단의 근거를 지금 즉시 재현할 수 있는가?"

기존 시스템의 구조적 한계는 명확하다.

기존 시스템의 전형적 구조 결과
결정 로그를 텍스트로 남김 검색 가능하지만 증명 불가
AI를 블랙박스로 사용 결과만 있고 과정이 없음
단일 산업용으로 설계 산업 확장 시 재개발
규칙을 코드에 하드코딩 정책 변경마다 배포 필요
감사 대응을 사후에 준비 요청 시 수주 소요

Cronozen은 이 모든 문제에 대해 코드베이스 수준에서 검증 가능한 답을 가지고 있다. 아래는 10개 차원에서의 구조적 비교다.


Structure: 10차원 비교표

1. Decision Tracking — 의사결정 추적

차원 기존 시스템 Cronozen
기록 형태 텍스트 로그, 이벤트 로그 DPU Proof Chain
기록 내용 "무엇이 일어났는가" "왜, 누가, 어떤 정책으로, 어떤 증거 수준에서"
연결성 개별 로그 (단절) Hash Chain으로 순차 연결
재현성 불가 (당시 상태 미보존) 정책 스냅샷 + SHA-256 해시로 재현 가능

Cronozen의 차이:

DecisionProofUnit은 단순 로그가 아니다. 매 DPU는 previous_hash로 이전 DPU에 체인 연결되고, chain_hashSHA-256(content + previousHash + timestamp)로 계산된다. Genesis DPU부터 현재까지의 전체 체인을 검증하면, 중간에 하나라도 변조되었는지 즉시 감지할 수 있다. 이것은 블록체인 수준의 무결성을 데이터베이스 위에서 구현한 것이다.


2. AI Governance — AI 거버넌스

차원 기존 시스템 Cronozen
AI 사용 추적 없음 또는 단순 로그 5-Guard System
정책 강제 없음 도메인별 정책 자동 적용
AI 모드 통제 없음 AUTONOMOUS 차단 가능
위반 기록 없음 DENY 로그 + 정책 위반 상세 기록

5-Guard System 상세:

Guard 역할 위반 시
Guard 1: Policy Exists 해당 도메인에 활성 정책이 있는지 확인 DPU 생성 차단 + DENY 로그
Guard 2: Evidence Level 최소 증빙 수준 충족 확인 DPU 생성 차단 + DENY 로그
Guard 3: Human Review 사람 검토/승인 필수 여부 확인 DPU 생성 차단 + DENY 로그
Guard 4: Risk Threshold 리스크 수준별 AI 모드 제한 확인 DPU 생성 차단 + DENY 로그
Guard 5: Dual Approval CRITICAL 등급 이중 승인 확인 DPU 생성 차단 + DENY 로그

Guard를 하나라도 통과하지 못하면 DPU는 생성되지 않는다. 하지만 실패 자체도 DecisionProofAuditLogresult: 'DENIED'로 기록된다. "시도했으나 차단되었다"는 사실 자체가 감사 증빙이 된다.


3. Multi-Tenant & Multi-Vertical

차원 기존 시스템 Cronozen
산업 범위 단일 산업 전용 7 Verticals 동시 운영
테넌트 구조 고객별 커스텀 단일 코드베이스, tenant_id 기반 분리
확장 방식 새 산업 = 새 프로젝트 새 도메인 정책 추가만으로 확장

실제 Vertical 목록 (prisma/verticals/):

Vertical 도메인 데이터 민감도
Rehab 아동 발달 재활 PHI
Welfare 복지 사례관리 PII
Market 상권 쿠폰/정산 PUBLIC
Edu 교육 프로그램 INTERNAL
Mentor 멘토링 매칭 INTERNAL
Pharmacy 약국 거래 PHI
Interior 인테리어 시공 INTERNAL

하나의 DPU 시스템이 7개 Vertical에서 동일하게 작동한다. 도메인별 정책(DecisionProofPolicy)만 다를 뿐, 증빙 생성 엔진, Hash Chain, JSON-LD Export는 공유된다.


4. Policy Engine — 정책 엔진

차원 기존 시스템 Cronozen
정책 정의 코드에 하드코딩 Dynamic Policy Engine
정책 변경 코드 수정 + 배포 DB 레코드 수정 (무배포)
정책 버전 관리 없음 version + version_hash (SHA-256)
정책 적용 범위 전체 동일 scope(도메인), temporal(시간), priority(우선순위)
정책 이력 없음 effective_from / effective_until 기간 관리

정책 구조의 핵심 차이:

Cronozen의 DecisionProofPolicy는 policy_config를 JSON으로 저장한다. 여기에 AI 모드 제한, 최소 증빙 수준, 민감도 제약, 자동 승인 조건이 모두 포함된다. 정책이 변경되면 새 레코드가 생성되고 이전 정책은 effective_until로 만료된다. 과거 DPU는 policy_snapshot 필드에 생성 당시 정책을 통째로 보관하므로, 정책이 변경되어도 과거 판단의 재검증이 가능하다.

정책 티어 대상 주요 설정
LOW (SMB) Market, Family 자동 승인 가능, Human Review 불필요
MEDIUM (기관) Rehab, Edu, Mentor Human Review 필수, AUTONOMOUS 차단
HIGH (공공/금융) Welfare, Pharmacy 이중 승인, PHI 제약, AUDIT_READY 강제

5. Audit Readiness — 감사 대응

차원 기존 시스템 Cronozen
감사 준비 요청 후 수동 수집 (수주) Audit-Ready 자동화
Export 형식 PDF, 엑셀 수동 생성 JSON-LD v2.0 자동 Export
감사 로그 접근 로그 수준 DPU 단위 감사 로그 (PASSED/DENIED/FLAGGED)
감사 경로 내부 API 혼용 전용 읽기 전용 경로 (/api/audit/export/jsonld)

감사 시나리오 비교:

[기존 시스템에서 감사 요청이 왔을 때]
1. 감사 요청 수신
2. 관련 로그 검색 (어디에 있는지 불확실)
3. 엑셀/PDF 수동 정리 (3~5일)
4. 누락 발견 시 재수집
5. 최종 제출 (1~2주)

[Cronozen에서 감사 요청이 왔을 때]
1. 감사 요청 수신
2. /api/audit/export/jsonld?domain=rehab_care&from=2026-01&to=2026-03
3. JSON-LD 패키지 다운로드 (2분)
4. Hash Chain 무결성 자동 검증 포함
5. 제출 완료

6. Data Sensitivity — 데이터 민감도 분류

차원 기존 시스템 Cronozen
분류 방식 전체 데이터 동일 취급 4단계 분류 체계
처리 제약 없음 민감도별 AI 모드/증빙 수준 강제
정책 연동 없음 DataSensitivityLevel이 정책에 바인딩

DataSensitivityLevel 4단계:

Level 설명 AI 제약 Evidence 요구
PUBLIC 공개 가능 데이터 제한 없음 DRAFT 가능
INTERNAL 내부용 데이터 AUTONOMOUS 차단 권장 DRAFT 가능
PII 개인식별정보 AUTONOMOUS 차단 PARTIAL 이상
PHI 보건의료정보 허용된 모드만 가능 AUDIT_READY 강제

PHI 데이터(재활 치료 기록, 약국 거래)에 대해서는 Guard 4가 추가 제약을 강제한다. AI가 PHI 데이터를 처리할 때는 허용된 모드(RECOMMENDATION, ANALYSIS)만 사용할 수 있고, Evidence Level은 반드시 AUDIT_READY여야 한다.


7. AI Transparency — AI 투명성

차원 기존 시스템 Cronozen
AI 결과 블랙박스 (결과만 제공) Responsibility Graph + Hash Chain
책임 귀속 "AI가 그랬어요" 집행자-승인자-증빙 3자 관계 명시
모델 추적 없음 ai_model, ai_prompt_hash 기록
판단 재현 불가 정책 스냅샷 + 해시로 재현

Responsibility Graph 구조:

DPU 하나에서 추출되는 책임 그래프는 3종의 노드로 구성된다.

Node Type 역할 예시
Executor 실제 행위 수행자 치료사, 복지사, AI 모델
Approver 승인/검토자 센터장, 수퍼바이저
Evidence 증빙 자료 세션 기록, 동의서, 바우처

이 3자 관계가 그래프로 연결되어 있으므로, "이 결정에 AI가 어떤 역할을 했고, 누가 최종 승인했으며, 어떤 증빙이 뒷받침하는가"를 그래프 탐색으로 즉시 확인할 수 있다.


8. Evidence Management — 증빙 관리

차원 기존 시스템 Cronozen
증빙 형태 파일 첨부 (PDF, 이미지) EvidenceLevel 단계적 진행
증빙 수준 있음/없음 이분법 3단계 (DRAFT -> PARTIAL -> AUDIT_READY)
증빙 무결성 파일 해시 없음 SHA-256 해시 + 체인 검증
증빙 진행 없음 (정적) 업무 진행에 따라 자동 승격

EvidenceLevel 3단계 진행:

Level 의미 법적 무게 전형적 상태
DRAFT 초기 기록 참고 수준 접수, 초기 등록
PARTIAL 부분 검증 보조 증빙 계획 수립, 계약, 평가
AUDIT_READY 감사 대응 가능 법적 증빙 실행 완료, 종결

Pharmacy Vertical의 거래 증빙은 이 진행을 가장 명확하게 보여준다.

  1. 거래 생성 시: DRAFT (DPU 생성, Hash Chain 연결)
  2. 첫 번째 서명 시: PARTIAL (한쪽 서명 완료)
  3. 양자 서명 완료 시: AUDIT_READY (법적 증빙력 확보)

기존 시스템에서 "파일을 첨부했느냐"가 전부였다면, Cronozen에서는 증빙의 성숙도가 업무 흐름에 따라 자동으로 진행된다.


9. Consent Management — 동의 관리

차원 기존 시스템 Cronozen
동의 방식 단일 체크박스 4종 세분화 동의
동의 이력 최초 동의만 기록 동의/철회 전체 이력 + 타임스탬프
감사 추적 없음 consent_audit_logs
법정대리인 미지원 또는 별도 guardian_info 동의 통합 관리

동의 관리 비교:

[기존 시스템]
"개인정보 수집에 동의합니다" [체크]
--> DB: consent = true
--> 끝. 언제 동의했는지, 철회했는지 추적 불가

[Cronozen]
personal_info: true (2026-01-15 14:30:00)
sensitive_info: true (2026-01-15 14:30:05)
third_party: false (미동의)
guardian_info: true (2026-01-15 14:31:00, 법정대리인: 김OO)
--> consent_audit_logs에 모든 변경 기록
--> 2026-02-10 sensitive_info 철회 --> withdrawn_at 기록
--> 감사 시: "2026-01-15에 동의, 2026-02-10에 민감정보 동의 철회" 즉시 재현

10. Scalability — 확장성

차원 기존 시스템 Cronozen
확장 방식 고객별 커스텀 코드 단일 코드베이스, Multi-Vertical
새 산업 진입 별도 프로젝트 도메인 정책 + Prisma 스키마 추가
공통 기능 중복 개발 DPU, Hash Chain, Guard 공유
패키징 불가 npm 패키지 분리 완료

npm 패키지 구조:

Package 범위 라이선스
@cronozen/dp-schema-public Types, Enums, JSON-LD Schema, Constants Apache-2.0 (공개)
@cronozen/dpu-core Hash Chain, Canonicalization, Adapter Interface Apache-2.0 (공개)
@cronozen/dpu-connector-prisma Prisma Storage Adapter Apache-2.0 (공개)
@cronozen/dpu-pro Governance Guards, Compliance Engine, Audit Private (유료)

핵심 인프라(dp-schema-public, dpu-core)는 오픈소스로 공개되어 있고, 거버넌스 엔진(dpu-pro)은 상업 라이선스로 분리되어 있다. 이 구조는 커뮤니티 채택과 상업적 수익을 동시에 추구한다.


Flow: 통합 의사결정 경로

기존 시스템과 Cronozen의 의사결정 경로를 나란히 비교하면 구조적 차이가 명확해진다.

기존 시스템의 의사결정 경로:

사용자 요청
    --> 비즈니스 로직 실행
    --> 결과 반환
    --> (선택적) 로그 기록
    --> 감사 요청 시: 로그 검색 + 수동 정리

Cronozen의 의사결정 경로:

사용자 요청
    --> 도메인 정책 조회 (Guard 1)
    --> Evidence Level 확인 (Guard 2)
    --> Human Review 확인 (Guard 3)
    --> Risk Threshold 확인 (Guard 4)
    --> Dual Approval 확인 (Guard 5)
    --> [모든 Guard 통과]
        --> Hash Chain Link 생성 (SHA-256)
        --> DPU 생성 (정책 스냅샷 포함)
        --> 감사 로그 기록 (PASSED)
        --> 비즈니스 로직 실행
        --> 결과 반환
    --> [Guard 실패]
        --> DENY 로그 기록 (위반 사유 상세)
        --> 거부 응답 반환
    --> 감사 요청 시: JSON-LD Export 즉시

Result: 왜 Cronozen인가

10차원 종합 비교 요약

# 비교 차원 기존 시스템 Cronozen
1 Decision Tracking 텍스트 로그 DPU Proof Chain + Hash Chain
2 AI Governance 없음 5-Guard System
3 Multi-Vertical 단일 산업 7 Verticals, Multi-Tenant
4 Policy Engine 하드코딩 Dynamic Policy (scope, temporal, priority)
5 Audit Readiness 수동 준비 (수주) Audit-Ready 자동화 (2분)
6 Data Sensitivity 균일 처리 PII/PHI/INTERNAL/PUBLIC 4단계
7 AI Transparency 블랙박스 Responsibility Graph + Hash Chain
8 Evidence Management 파일 첨부 EvidenceLevel 3단계 자동 진행
9 Consent 단일 체크박스 4종 세분화 동의 + 감사 로그
10 Scalability 고객별 커스텀 단일 코드베이스 + npm 패키지

구매 결정자를 위한 한 문장

Cronozen은 AI를 "잘 쓰는" 시스템이 아니라, AI를 "책임질 수 있게" 만드는 시스템이다.

CTO를 위한 기술적 근거

DPU의 5-Guard는 하드코딩이 아니라 DB 정책 기반으로 작동하므로, 새로운 규제가 추가되면 코드 배포 없이 정책 레코드 하나로 대응한다. Hash Chain은 블록체인 없이 SHA-256 체인으로 무결성을 보장하며, 핵심 라이브러리는 npm 패키지로 분리되어 있어 독립적 테스트와 버저닝이 가능하다.

심사위원/투자자를 위한 확장 구조

7개 Vertical이 하나의 DPU 인프라 위에서 작동한다는 것은, 새로운 산업 진입 비용이 "도메인 정책 1개 + Prisma 스키마 1개"라는 뜻이다. 이미 Rehab, Welfare, Market, Edu, Mentor, Pharmacy, Interior에서 검증된 동일한 증명 인프라가, 다음 산업에도 그대로 적용된다.

이것이 기존 시스템과 Cronozen의 구조적 차이다. 기능의 차이가 아니라, 아키텍처의 차이.