Problem
한국의 사회서비스 산업 — 아동발달재활, 복지급여, 교육센터, 건강관리 — 은 여전히 파편화된 레거시 시스템 위에서 운영되고 있습니다.
| 현실 | 결과 |
|---|---|
| 센터마다 별도 솔루션 도입 | 데이터 사일로, 중복 투자 |
| 수기 기록 + 엑셀 관리 | 감사 추적 불가, 컴플라이언스 리스크 |
| AI 도입 시도 | 의사결정 근거 부재로 신뢰 확보 실패 |
| 바우처·정책 변경 | 수동 반영, 오류 발생, 매출 누락 |
핵심 문제는 단순한 "디지털 전환"이 아닙니다. AI가 내린 의사결정을 누가, 어떻게, 왜 검증하는가 — 이 질문에 답할 수 있는 아키텍처가 존재하지 않았습니다.
기존 접근 방식과 Cronozen의 차이를 명확히 하면:
| 기존 센터 관리 솔루션 | Cronozen | |
|---|---|---|
| 아키텍처 | 단일 테넌트, 단일 도메인 | 멀티테넌트, 멀티도메인, 7개 버티컬 |
| AI 의사결정 | Black-box 또는 미지원 | DPU 기반 증거 체인 + 5중 거버넌스 |
| 정책 반영 | 수동 업데이트 | Policy Engine 자동 적용 (4계층 스코프) |
| 감사 대응 | 사후 로그 수집 | 실시간 해시 체인, Audit-Ready 상태 관리 |
| 데이터 보호 | 기본 암호화 수준 | 4단계 민감도 분류 + 동의 관리 체계 |
Solution
Cronozen은 Decision Proof Unit(DPU) 을 핵심 프리미티브로 하는 풀스택 플랫폼입니다. 모든 AI 의사결정, 데이터 변경, 정책 적용에 대해 암호학적으로 검증 가능한 증거 단위를 생성하고, 이를 해시 체인으로 연결하여 변조 불가능한 감사 추적을 제공합니다.
세 가지 설계 원칙:
1. 증명 가능한 의사결정 (Provable Decisions) AI가 "이 아동의 치료 스케줄을 변경합니다"라고 제안할 때, 그 결정의 근거·신뢰도·위험 수준·승인 경로가 하나의 DPU 엔벨로프에 봉인됩니다. DRAFT에서 AUDIT_READY까지 증거 수준(Evidence Level)이 추적됩니다.
2. 하나의 백엔드, 무한한 컨텍스트 (One Backend, Infinite Context) 재활센터, 복지기관, 교육센터, 건강관리 시설이 동일한 인프라 위에서 각자의 도메인·워크스페이스·정책을 가지고 운영됩니다. 코드는 하나, 컨텍스트는 테넌트별로 완전히 격리됩니다.
3. 정책이 코드가 되는 구조 (Policy as Runtime) 국가·지역·센터 단위 정책이 런타임에 자동 적용됩니다. 바우처 기준이 바뀌면 정책 엔진이 영향 범위를 계산하고, 조건부 트리거로 즉시 반영합니다.
Architecture
시스템 전체 구조
┌─────────────────────────────────────────────────────────────────┐
│ CLIENT LAYER │
│ │
│ withslow.com slowpace.co.kr cronozen.com [+ more] │
│ │ │ │ │ │
│ └───────────┬────┴────────────────┴───────┬───────┘ │
│ │ Domain Router │ │
│ ▼ ▼ │
├─────────────────────────────────────────────────────────────────┤
│ EDGE MIDDLEWARE │
│ JWT 인증 · RBAC · 테넌트 식별 · Rate Limit │
├─────────────────────────────────────────────────────────────────┤
│ │
│ APPLICATION LAYER │
│ (Next.js 14 + TypeScript) │
│ │
│ ┌──────────┐ ┌──────────────┐ ┌─────────────┐ ┌─────────┐ │
│ │ API │ │ AI System │ │ Policy │ │ Agent │ │
│ │ Routes │ │ │ │ Engine │ │ Orchest.│ │
│ │ │ │ Multi- │ │ │ │ │ │
│ │ REST + │ │ Provider │ │ 4-Scope │ │ 3 Agent │ │
│ │ Server │ │ RAG + NL→SQL │ │ Resolution │ │ Types │ │
│ │ Actions │ │ 6W Extract. │ │ Temporal │ │ │ │
│ └────┬─────┘ └──────┬───────┘ └──────┬──────┘ └────┬────┘ │
│ │ │ │ │ │
│ └───────────┬───┴─────────────────┴───────┬───────┘ │
│ ▼ ▼ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ DPU ENGINE (Decision Proof Unit) │ │
│ │ │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌────────────────┐ │ │
│ │ │ dpu-core │ │ dpu-pro │ │ dpu-connector │ │ │
│ │ │ │ │ │ │ -prisma │ │ │
│ │ │ Hash Chain │ │ 5 Govern. │ │ │ │ │
│ │ │ Canon. │ │ Guards │ │ DB Adapter │ │ │
│ │ │ Envelope │ │ Compliance │ │ │ │ │
│ │ │ Storage I/F │ │ Resp. Graph │ │ │ │ │
│ │ └─────────────┘ └─────────────┘ └────────────────┘ │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │ │
├──────────────────────────────┼──────────────────────────────────┤
│ DATA LAYER │
│ │
│ ┌──────────────────┐ ┌──────────────┐ ┌──────────────────┐ │
│ │ PostgreSQL │ │ pgvector │ │ Knowledge Base │ │
│ │ 315 Models │ │ Embeddings │ │ RAG Store │ │
│ │ Prisma ORM │ │ Similarity │ │ │ │
│ │ │ │ Search │ │ │ │
│ └──────────────────┘ └──────────────┘ └──────────────────┘ │
│ │
│ 보안: 4단계 민감도 분류 · 동의 관리 · 감사 로깅 │
└─────────────────────────────────────────────────────────────────┘
레이어별 상세 설명
1. Client Layer — 멀티도메인 라우팅
복수의 도메인이 단일 Next.js 애플리케이션으로 수렴합니다. Edge Middleware에서 요청의 Host 헤더를 분석하여 테넌트를 식별하고, 해당 테넌트의 설정(브랜딩, 기능 플래그, 정책 스코프)을 주입합니다.
각 도메인은 독립적인 서비스처럼 동작하지만, 실제로는 모듈형 테넌트 설정(Modular Tenant Config) 에 의해 동일한 코드베이스에서 분기됩니다. 새로운 버티컬을 추가할 때 별도 서버를 배포할 필요가 없습니다.
2. Application Layer — 7개 버티컬, 하나의 런타임
현재 지원하는 7개 버티컬:
| 코드 | 버티컬 | 설명 |
|---|---|---|
| Rehab | 아동발달재활 | 바우처 기반 치료 세션 관리 |
| Welfare | 복지급여 | 급여 신청·처리·정산 |
| Edu | 교육센터 | 수강·커리큘럼·출석 관리 |
| Health | 건강관리 | 건강 데이터 추적·분석 |
| Market | 상권활성화 | 쿠폰·프로모션·지역경제 연동 |
| Conference | 컨퍼런스 | 행사·세미나·참가자 관리 |
| Interior | 인테리어 | 공간 설계·시공 관리 |
각 버티컬은 센터(Center) 를 기본 격리 단위로 사용합니다. 센터는 워크스페이스를 가지며, 워크스페이스 안에서 모든 데이터·권한·정책이 스코핑됩니다.
3. AI System — 멀티 프로바이더 + RAG
단일 AI 벤더에 종속되지 않습니다. OpenAI, Claude, Gemini, Ollama(로컬)를 상황에 따라 선택적으로 사용하며, 각 프로바이더의 응답은 동일한 DPU 파이프라인을 통과합니다.
자연어 질의 ──→ 6W 추출 ──→ NL→SQL 변환 ──→ 데이터 조회
│ (누가, 무엇을, │
│ 언제, 어디서, ▼
│ 왜, 어떻게) pgvector RAG
│ 컨텍스트 보강
▼ │
음성 입력 ──→ Voice Processing ────────┘
│
▼
AI 의사결정 생성
│
▼
DPU Envelope 봉인
Auto Decision Engine은 신뢰도 90% 이상의 결정을 자동 실행합니다. 그러나 "자동"이 "무검증"을 의미하지는 않습니다. 모든 자동 결정은 DPU에 기록되며, Governance Guard를 통과해야 합니다.
4. Agent Orchestrator — 3가지 에이전트 타입
| 에이전트 | 역할 | 실행 조건 |
|---|---|---|
| Morning Routine | 일일 스케줄 최적화, 준비사항 알림 | 매일 업무 시작 전 자동 트리거 |
| Voucher Renewal | 바우처 만료 감지, 갱신 절차 안내 | 만료 임박 시 조건부 트리거 |
| Emergency Schedule | 긴급 일정 변경, 대체 치료사 배정 | 취소·변경 이벤트 발생 시 |
에이전트는 독립적으로 판단하되, 모든 액션이 DPU를 통과합니다. 이는 에이전트의 자율성과 감사 가능성을 동시에 보장하는 설계입니다.
5. Policy Engine — 4계층 스코프 해석
정책은 다음 4개 계층에서 정의되며, 충돌 시 우선순위 기반 해석(Priority-Based Resolution) 이 적용됩니다:
┌─────────────────────────────────────┐
│ Global (전역) │ ← 최저 우선순위
│ ┌─────────────────────────────────┐│
│ │ Country (국가) ││
│ │ ┌─────────────────────────────┐││
│ │ │ Region (지역) │││
│ │ │ ┌─────────────────────────┐│││
│ │ │ │ Center (센터) ││││ ← 최고 우선순위
│ │ │ └─────────────────────────┘│││
│ │ └─────────────────────────────┘││
│ └─────────────────────────────────┘│
└─────────────────────────────────────┘
핵심 속성:
- Temporal Validity: 모든 정책에 시간 유효 범위가 존재합니다. "2026년 3월 바우처 단가 변경"은 해당 시점에 자동 활성화됩니다.
- Condition-Based Triggers: "아동 연령이 만 18세를 초과하면 재활 바우처 자격 종료" 같은 조건부 정책이 런타임에 평가됩니다.
- Conflict Resolution: 센터 정책이 지역 정책과 충돌하면, 우선순위 점수에 따라 어느 정책이 적용되는지 결정됩니다. 이 해석 과정 자체도 DPU에 기록됩니다.
Flow
아동발달재활 센터에서 AI가 치료 스케줄을 자동 조정하는 시나리오를 통해 전체 아키텍처의 동작 흐름을 추적합니다.
시점: 오전 8:30, 치료사 A가 당일 병가 접수
[1] Event 발생
Emergency Schedule Agent 트리거
│
▼
[2] AI 분석
├─ 해당 치료사의 당일 세션 목록 조회 (NL→SQL)
├─ 아동별 치료 이력 + 바우처 잔여 횟수 조회 (RAG)
├─ 대체 가능 치료사 탐색 (6W: 누가, 언제, 어디서)
└─ 스케줄 재배치 후보안 3개 생성
│
▼
[3] DPU Envelope 생성
├─ Evidence Level: PARTIAL (AI 제안, 미승인)
├─ AI Mode: SUGGESTION
├─ Risk Level: MEDIUM (아동 치료 연속성 영향)
└─ 해시 체인에 연결 (이전 DPU의 해시 참조)
│
▼
[4] Governance Guards 통과
├─ [Guard 1] Evidence Level Check → PARTIAL 확인
├─ [Guard 2] Human Review Required → Yes (MEDIUM 이상)
├─ [Guard 3] Risk Threshold → MEDIUM, 자동 실행 불가
├─ [Guard 4] Dual Approval → 센터장 + 보호자 동의 필요
└─ [Guard 5] Policy Compliance → 바우처 잔여 확인 통과
│
▼
[5] Human Review
센터장에게 알림 → 후보안 중 1개 선택 → 보호자 동의 수신
│
▼
[6] DPU 상태 전이
Evidence Level: PARTIAL → AUDIT_READY
Audit Status: APPROVED
Responsibility Graph: 치료사A(병가)→AI(제안)→센터장(승인)→보호자(동의)
│
▼
[7] 실행 + 기록
스케줄 변경 반영 → 바우처 차감 → 알림 발송
전체 과정이 해시 체인으로 봉인 완료
이 흐름에서 주목할 점:
- AI가 제안했지만, 실행 권한은 사람에게 있습니다
- 모든 단계가 DPU에 기록되어 사후 감사 시 전체 의사결정 경로를 재현할 수 있습니다
- Responsibility Graph가 책임 소재를 명확히 합니다
- 정책 엔진이 바우처 규정을 실시간으로 검증합니다
Example
멀티테넌트 격리가 실제로 의미하는 것
동일한 Cronozen 인프라 위에서 두 센터가 운영되는 상황을 비교합니다:
┌──────────────────────┐ ┌──────────────────────┐
│ 서울 A 재활센터 │ │ 부산 B 복지관 │
│ Vertical: Rehab │ │ Vertical: Welfare │
│ Domain: withslow.com│ │ Domain: slowpace.co.kr│
├──────────────────────┤ ├──────────────────────┤
│ 정책 스코프: │ │ 정책 스코프: │
│ Global │ │ Global │
│ └─ Country: KR │ │ └─ Country: KR │
│ └─ Region: 서울 │ │ └─ Region: 부산 │
│ └─ Center: A │ │ └─ Center: B │
├──────────────────────┤ ├──────────────────────┤
│ 데이터: 완전 격리 │ │ 데이터: 완전 격리 │
│ AI 모델: 공유 가능 │ │ AI 모델: 공유 가능 │
│ DPU 체인: 독립 │ │ DPU 체인: 독립 │
│ 바우처 정책: 서울 기준 │ │ 급여 정책: 부산 기준 │
└──────────────────────┘ └──────────────────────┘
│ │
└────────── 공유 ─────────────┘
│
┌──────────────────┐
│ 공유 인프라 │
│ - DPU Engine │
│ - AI Providers │
│ - Policy Engine │
│ - PostgreSQL │
│ (315 Models) │
└──────────────────┘
두 센터는 인프라는 공유하되 컨텍스트는 완전히 격리됩니다. A센터의 치료 기록이 B센터로 유출되는 것은 아키텍처 수준에서 불가능합니다. 동시에, DPU Engine과 Policy Engine 같은 공통 로직은 중복 없이 재사용됩니다.
DPU의 Evidence Level 전이
모든 의사결정은 다음 상태를 순차적으로 통과합니다:
DRAFT ──────→ PARTIAL ──────→ AUDIT_READY
│ │ │
│ │ │
▼ ▼ ▼
초안 생성 증거 부분 확보 감사 대응 완료
AI 제안 단계 검토 진행 중 모든 Guard 통과
해시 생성 책임자 지정 해시 체인 봉인
이 3단계 전이는 단순한 상태 머신이 아닙니다. 각 전이 시점에 새로운 해시가 생성되고 이전 해시를 참조하여 체인을 형성합니다. 중간에 데이터를 변조하면 해시 불일치가 발생하여 즉시 탐지됩니다.
Result
이 아키텍처가 달성하는 것:
정량적 지표
| 항목 | 수치 |
|---|---|
| 단일 코드베이스로 지원하는 버티컬 수 | 7개 |
| 데이터 모델 수 (Prisma Schema) | 315개 모델 / 8,749 라인 |
| AI 프로바이더 지원 | 4개 (OpenAI, Claude, Gemini, Ollama) |
| DPU Governance Guard | 5중 검증 |
| 정책 스코프 계층 | 4단계 (Global → Center) |
| 데이터 민감도 분류 | 4등급 (PII, PHI, Internal, Public) |
| 자동 실행 임계치 | 신뢰도 90% 이상 |
아키텍처적 보증
감사 가능성 (Auditability) 모든 AI 의사결정, 정책 적용, 데이터 변경이 해시 체인으로 연결된 DPU에 기록됩니다. 사후 감사 시 "이 결정이 왜, 누구에 의해, 어떤 근거로 내려졌는가"를 완전히 재현할 수 있습니다.
확장 가능성 (Scalability) 새로운 버티컬 추가는 테넌트 설정 + 도메인 라우팅 + 정책 스코프 정의만으로 가능합니다. 별도의 서버 배포나 코드 분기가 필요하지 않습니다.
규제 대응력 (Compliance Readiness) 4단계 데이터 민감도 분류(PII, PHI, Internal, Public)와 동의 관리 체계가 개인정보보호법, 의료법, 사회서비스법의 요구사항에 구조적으로 대응합니다.
AI 신뢰성 (AI Trustworthiness) 5중 Governance Guard — Evidence Level 검증, Human Review 요구, Risk Threshold 평가, Dual Approval 처리, Policy Compliance 확인 — 가 AI의 자율성과 인간의 통제권 사이의 균형을 보장합니다.
벤더 독립성 (Vendor Independence) 멀티 프로바이더 AI 아키텍처와 로컬 실행(Ollama) 지원으로, 특정 AI 벤더의 가격 정책 변경이나 서비스 중단에 대한 리스크를 구조적으로 완화합니다.
다음 문서
이 Architecture Overview는 Cronozen Living Technical Spec 시리즈의 첫 번째 문서입니다. 후속 문서에서는 각 컴포넌트의 심층 설계를 다룹니다:
- [02] DPU Deep Dive — 해시 체인 설계, 3-Package 아키텍처, Governance Guard 상세
- [03] AI Pipeline — 멀티 프로바이더 전략, RAG 설계, Auto Decision Engine
- [04] Policy Engine — 정책 충돌 해석, Temporal Validity, 조건부 트리거
- [05] Multi-Tenant Design — 도메인 라우팅, 워크스페이스 격리, 버티컬 확장 패턴
- [06] Data Architecture — 315 모델 설계 원칙, 민감도 분류, 동의 관리
- [07] Security Model — RBAC, JWT, Edge Middleware, 감사 로깅
Cronozen은 AI가 내린 모든 결정에 "왜?"라고 물을 수 있는 플랫폼을 만듭니다. Every decision leaves a proof. Every proof tells a story.
blog.cronozen.com | Cronozen Living Technical Spec Copyright 2026 Cronozen. All rights reserved.