"AI 증빙? 좋은데, 실제로 돌아가나요?"
개발자 인프라에서 가장 많이 듣는 질문입니다. 데모는 멋지지만 프로덕션은 다릅니다. 엣지 케이스, 동시성, 기존 코드와의 충돌 — 실제 서비스에 붙여봐야 진짜가 드러납니다.
그래서 크로노젠은 Proof API v1을 출시하면서, 동시에 3개 실서비스에 바로 적용했습니다.
3개 버티컬, 하나의 증빙 인프라
아트테리어 (인테리어)
인테리어 매칭 플랫폼에서 접수부터 시공 완료까지의 정산이 발생합니다. 각 정산 건마다:
- 접수 생성 시점에
decision.record()— 누가, 왜, 얼마에 합의했는지 기록 - 센터장 승인 시점에
decision.approve()— SHA-256 해시로 봉인 - 이후 정산 분쟁 시
evidence.export()— 당시 승인 시점의 증빙 즉시 출력
슬로페이스 (재활)
재활 바우처 정산은 특히 증빙이 중요합니다. 정부 바우처 사업은 감사 대상이기 때문입니다.
- 치료 세션 완료 → 정산 생성 → 자동 증빙 기록
- 감독자 확인 → 승인 봉인
- 감사 요청 시 → JSON-LD 형식 보고서 즉시 제출
서초쿠폰 (지역 상권)
지역 쿠폰 정산은 소상공인과 지자체 간의 신뢰가 핵심입니다.
- 쿠폰 사용 → 정산 집계 → 의사결정 기록
- 상인회 확인 → 승인 봉인
- 지자체 보고 시 → 증빙 보고서 자동 생성
통합 방식: Non-blocking, Zero-risk
Proof 통합의 핵심 설계 원칙은 **"기존 흐름을 절대 방해하지 않는 것"**입니다.
// fireProof() — non-blocking 래퍼
// Proof 기록 실패가 정산 흐름을 중단시키지 않음
await fireProof(() =>
cz.decision.record({
type: "settlement_created",
actor: actorId,
action: "create",
input: { settlementId, amount }
})
)
환경변수(CZ_KEY)가 없으면 자동 비활성화. 새 서비스에 Proof를 적용할 때 설정 하나만 켜면 됩니다. 기존 코드 변경 없이, 점진적으로 활성화할 수 있습니다.
왜 "정산"부터 시작했나
모든 비즈니스 의사결정 중 **정산(Settlement)**은 가장 증빙이 필요한 영역입니다:
- 돈이 오가는 의사결정
- 승인 책임이 명확해야 하는 의사결정
- 감사/분쟁 시 "당시 상황"을 재현해야 하는 의사결정
정산에서 작동하면 나머지는 쉽습니다. 예약 승인, 회원 상태 변경, 콘텐츠 검수 — 모든 의사결정에 같은 패턴을 적용할 수 있습니다.
개발자가 알아야 할 것
SDK는 11.1KB, 외부 의존성 0개입니다.
| 항목 | 스펙 |
|---|---|
| 패키지 크기 | 11.1KB |
| 의존성 | Zero |
| 모듈 형식 | CJS + ESM + DTS |
| 타입 안전 | TypeScript 네이티브 |
| 에러 처리 | 7개 typed error class |
npm install cronozen
통합에 필요한 코드는 서비스당 5줄 이내입니다. 정산 생성 핸들러에 decision.record(), 승인 핸들러에 decision.approve() — 그게 전부입니다.
다음 단계
3개 서비스에서의 검증을 바탕으로:
- Proof Admin Console — 의사결정 타임라인 시각화, 감사 보고서 대시보드
- Webhook 알림 — 특정 유형의 의사결정 발생 시 실시간 알림
- 멀티 승인 정책 — 금액/위험도에 따른 자동 승인 루트 분기
Proof는 단순한 로깅 도구가 아닙니다. AI 시대의 의사결정 거버넌스 인프라입니다.
시작하기: docs.cronozen.com 데모 요청: hello@cronozen.com
AI가 결정을 내리는 시대. 증명은 선택이 아니라 인프라입니다.