대부분의 운영 시스템이 놓치는 것

운영 소프트웨어는 보통 이렇게 만들어집니다.

  1. 데이터를 입력한다
  2. 상태를 변경한다
  3. 보고서를 출력한다

이것만으로 충분할까요?

현실에서는 이런 질문이 반복됩니다.

  • "이 매칭은 누가 승인했나요?"
  • "왜 이 바우처가 이 금액으로 정산됐나요?"
  • "이 치료 기록은 언제, 누가 작성한 건가요?"

이 질문들에 대한 답을 시스템이 스스로 증명할 수 없다면, 결국 사람이 기억에 의존하거나, 엑셀을 뒤지거나, 감사 때 허둥댈 수밖에 없습니다.

CRUD는 "무엇"을 기록하고, 증거 엔진은 "왜"를 증명한다

전통적인 운영 시스템은 **상태(state)**를 저장합니다.

매칭 상태: 승인됨
바우처 금액: 150,000원
치료 기록: 작성 완료

하지만 이것만으로는 부족합니다. 운영 의사결정에는 **맥락(context)**이 필요합니다.

매칭 승인 근거:
- 강사 자격 확인: 물리치료사 면허 #12345
- 바우처 유효성: 2026-03-01 ~ 2026-08-31
- 보호자 동의: 2026-03-05 14:23 서명
- 승인자: 센터장 김OO (ADMIN 역할)
- 승인 시각: 2026-03-05 15:01:23
- 해시: SHA-256(내용 + 이전해시 + 타임스탬프)

이 차이가 기록 시스템과 증거 시스템의 차이입니다.

감사·분쟁·정산에서 벌어지는 현실

복지, 재활, 교육, 공공 서비스 분야에서 감사는 일상입니다.

감사관이 물어보는 3가지

  1. 정확성: "이 기록이 실제 사실과 일치합니까?"
  2. 적시성: "기록이 사건 발생 시점에 작성됐습니까?"
  3. 무결성: "기록이 사후에 변경되지 않았습니까?"

일반적인 운영 시스템은 1번에만 답할 수 있습니다. 2번과 3번은 시스템 로그를 뒤져야 하고, 로그마저 조작 가능합니다.

일반 감사 로그 vs 증명 가능한 의사결정

일반 감사 로그 증명 가능한 의사결정 (DPU)
기록 내용 "사용자 X가 문서 Y를 수정함" "사용자 X가 근거 A, B, C를 바탕으로 의사결정 Y를 내림"
변조 방지 로그 삭제/수정 가능 해시 체인으로 한 건이라도 변조하면 전체 체인 파괴
시점 증명 서버 시간 의존 (조작 가능) 타임스탬프가 해시에 포함 (변조 불가)
외부 검증 내부 시스템 접근 필요 JSON-LD로 외부 독립 검증 가능
연속성 개별 로그, 관계 없음 Genesis → 현재까지 연속 체인

크로노젠의 접근: Decision Proof Unit

크로노젠은 **Decision Proof Unit(DPU)**라는 개념을 운영 시스템의 기반으로 사용합니다.

작동 원리

모든 운영 의사결정은 다음 구조로 기록됩니다.

DPU Record:
  content: 의사결정 내용 + 근거 데이터
  previousHash: 이전 DPU의 해시값
  timestamp: 기록 시각
  hash: SHA-256(content + previousHash + timestamp)

이 구조의 핵심은 체인입니다.

Genesis Block → DPU #1 → DPU #2 → DPU #3 → ...

하나의 기록을 변조하면 그 이후의 모든 해시가 깨집니다. 이것이 "변조하면 체인이 부러진다(tamper-evident)"는 의미입니다.

증거 수준 관리

DPU는 3단계 증거 수준을 가집니다.

  • DRAFT: AI 또는 시스템이 자동 생성한 초안
  • DOCUMENTED: 담당자가 검토하고 보완한 기록
  • AUDIT_READY: 최종 승인, 해시 체인에 봉인 (이후 수정 불가)

이 구조 덕분에 "AI가 만든 기록"과 "사람이 검증한 기록"이 명확히 구분됩니다.

5단계 거버넌스 가드

AI가 관여하는 의사결정에는 추가 거버넌스가 적용됩니다.

  1. 정책 존재 확인: 이 유형의 결정에 대한 정책이 있는가
  2. 증거 수준 확인: 충분한 증거가 수집됐는가
  3. 인간 검토 여부: 사람의 확인이 필요한 결정인가
  4. 리스크 임계값: 리스크 점수가 허용 범위 내인가
  5. 이중 승인: 고위험 결정에 대한 복수 승인이 필요한가

왜 이것이 "운영 OS"의 핵심인가

운영 OS는 단순히 기능이 많은 소프트웨어가 아닙니다. 운영 흐름 자체를 이해하고, 판단하고, 설명할 수 있는 시스템입니다.

기존 SaaS와 운영 OS의 차이를 정리하면 이렇습니다.

기존 SaaS 운영 OS
핵심 기능 데이터 입력·조회 의사결정 기록·증명
AI 역할 자동화 도구 거버넌스 하에서 판단 보조
감사 대응 로그 뒤지기 체인 검증 한 번으로 완료
확장 방향 기능 추가 새 버티컬에 같은 증거 엔진 적용

Palantir Foundry가 정부·국방·금융에서 강한 이유도 여기에 있습니다. 단순히 데이터를 시각화하는 것이 아니라, 의사결정의 근거와 흐름을 추적 가능하게 만드는 것이 핵심입니다.

크로노젠이 이 방향으로 가는 이유

크로노젠은 재활, 교육, 복지 등 규제가 강하고 감사가 일상인 분야에서 시작했습니다.

이 분야에서는 "기록"만으로는 부족합니다. 증명이 필요합니다.

  • 치료사가 실제로 서비스를 제공했다는 증명
  • 매칭 결정이 적절한 근거에 기반했다는 증명
  • 바우처 정산이 정확한 기록에 기반했다는 증명
  • AI 추천이 거버넌스 가드를 통과했다는 증명

이 모든 것을 코드 레벨에서 보장하는 것이 DPU이고, 이것이 크로노젠을 단순 Vertical SaaS가 아닌 AI 운영 OS로 만드는 기반입니다.

다음 단계

증명 가능한 의사결정은 시작일 뿐입니다. 운영 OS가 완성되려면 추가로 필요한 것들이 있습니다.

  • Policy Engine: 의사결정 규칙을 코드가 아닌 정책으로 관리
  • Knowledge Graph: 운영 데이터 간의 의미 관계를 그래프로 연결
  • Simulation Layer: 정책 변경의 영향을 사전에 시뮬레이션

이 레이어들이 DPU 위에 쌓이면, 시스템은 단순히 "기록"하는 것을 넘어 "이해하고, 판단하고, 설명"하는 수준에 도달합니다.

크로노젠은 이 방향으로 진화하고 있습니다.