두 가지 길 사이에서
SaaS 플랫폼을 만들 때 자주 만나는 갈림길이 있습니다.
Vertical SaaS: 특정 산업에 특화된 솔루션을 만든다. 재활, 교육, 복지 등 하나의 분야에서 깊이 있는 기능을 제공한다.
Horizontal Platform: 산업에 관계없이 범용 인프라를 만든다. 인증, 결제, 워크플로우 같은 공통 기능을 제공한다.
대부분의 팀은 하나를 선택합니다. Vertical로 가면 시장 진입이 빠르지만 확장이 어렵고, Horizontal로 가면 시장이 넓지만 초기 고객 획득이 어렵습니다.
크로노젠은 제3의 길을 선택했습니다.
"Vertical SaaS처럼 팔리고, AI 운영 OS로 축적된다"
이 한 문장이 크로노젠의 전략입니다.
바깥에서 보면 크로노젠은 재활·복지·교육 기관을 위한 운영 SaaS입니다. 센터 관리, 매칭, 일정, 바우처 정산 같은 구체적인 문제를 해결합니다.
안쪽에서 보면 모든 운영 흐름이 증명 가능한 방식으로 기록되는 OS입니다. DPU 해시 체인, 멀티테넌트 격리, AI 거버넌스 가드가 모든 버티컬의 기반으로 작동합니다.
외부 (고객이 보는 것) 내부 (실제 구조)
───────────────────── ─────────────────
재활 센터 운영 SaaS Cronozen OS
교육 기관 관리 플랫폼 ├ Workflow Engine
복지 서비스 자동화 ├ Decision Proof (DPU)
├ Evidence Store
└ AI Governance
왜 이 전략인가
1. 순수 Vertical SaaS의 한계
Vertical SaaS만으로는 크로노젠의 코어가 아깝습니다.
크로노젠에는 이미 이런 것들이 있습니다.
- DPU(Decision Proof Unit): SHA-256 해시 체인 기반 의사결정 증명
- 5단계 거버넌스 가드: AI 결정에 대한 정책·증거·검토·리스크·승인 체계
- JSON-LD v2 export: 외부 독립 검증 가능한 증거 포맷
- 멀티테넌트 격리: 200+ 테이블, row-level isolation, scoped Prisma
이것들은 "재활 센터를 위한 기능"이 아닙니다. 모든 운영 흐름에 적용 가능한 인프라입니다.
이 인프라를 한 버티컬에만 가두면, 시간이 갈수록 다른 분야에서도 같은 것을 처음부터 만들어야 합니다.
2. 순수 Platform의 한계
반대로, 처음부터 "AI 운영 OS입니다"라고 말하면 시장에서 이해하기 어렵습니다.
- "운영 OS가 뭔데요?"
- "구체적으로 뭘 해주는 건가요?"
- "우리 업종에 맞나요?"
초기 고객은 추상적인 플랫폼이 아니라 당장 해결되는 문제를 삽니다.
재활 센터 원장은 "매칭 자동화"를 원하고, 교육 기관 담당자는 "HRD-Net 연동"을 원합니다. "증명 가능한 의사결정 엔진"은 그 다음 이야기입니다.
3. 그래서 Wedge 전략
Vertical SaaS는 시장 진입을 위한 **웨지(wedge)**입니다.
Step 1: 재활·복지·교육 운영 SaaS로 고객 획득
Step 2: 운영 데이터가 DPU에 축적
Step 3: 축적된 증거 데이터로 AI 운영 모델 학습
Step 4: 새 버티컬에 같은 OS를 적용하여 확장
Shopify도 처음에는 "온라인 쇼핑몰 만들기 도구"였지만, 지금은 "커머스 OS"입니다. Vertical에서 시작해서 OS로 진화한 것입니다.
코드에 이미 답이 있다
크로노젠의 코드 구조를 보면 이 전략이 이미 반영되어 있습니다.
OS 레이어 (모든 버티컬 공통)
@cronozen/dpu-core → 도메인 독립, DB 무관한 증거 엔진
@cronozen/dpu-pro → 거버넌스 확장
core/constants → 9개 SSOT 축
core/tenant → 멀티테넌트 격리
core/audit → 감사 추적
core/membership → 역할 기반 접근 제어
버티컬 레이어 (분야별 비즈니스 로직)
verticals/rehab → 재활 센터 운영
verticals/edu → 교육 기관 관리
verticals/market → 상권 분석
verticals/interior → 인테리어 관리
핵심은 OS 레이어가 버티컬에 의존하지 않는다는 것입니다. DPU는 재활이든 교육이든 동일하게 작동합니다. 매칭 워크플로우의 구체적인 규칙은 버티컬마다 다르지만, "의사결정을 기록하고 증명한다"는 구조는 공통입니다.
앞으로의 진화 방향
Phase 1: 버티컬 안정화 (현재)
지금은 재활·교육·복지 버티컬에서 고객을 확보하고, 운영 데이터를 축적하는 단계입니다.
이 단계에서 중요한 것은 모든 운영 흐름이 DPU를 거치도록 하는 것입니다.
보호자 신청 → DPU 기록
매칭 승인 → DPU 기록
세션 완료 → DPU 기록
정산 처리 → DPU 기록
기능을 추가할 때마다 "이 의사결정의 증거가 남는가?"를 확인합니다.
Phase 2: 워크플로우 엔진 추출
버티컬에서 반복되는 패턴을 공통 엔진으로 추출합니다.
신청 → 승인 → 배정 → 수행 → 완료 → 정산 → 보고
이 흐름은 재활이든 교육이든 본질적으로 같습니다. 다른 것은 각 단계의 구체적인 규칙뿐입니다.
워크플로우 엔진이 만들어지면 새 버티컬을 추가하는 비용이 급격히 줄어듭니다.
Phase 3: 증거 레이어 완성
DPU 위에 추가 레이어를 쌓습니다.
- Policy Engine: 의사결정 규칙을 코드가 아닌 정책으로 관리
- Knowledge Graph: 운영 엔티티 간의 의미 관계를 그래프로 연결
- Simulation Layer: 정책 변경의 영향을 사전에 시뮬레이션
이 레이어들이 갖춰지면 시스템은 "기록"을 넘어 "이해·판단·설명"이 가능해집니다.
Phase 4: AI 운영 OS 공개
OS 레이어를 독립 제품으로 노출합니다.
Cronozen OS
├ Workflow Builder
├ Evidence Engine
├ Policy Manager
├ Audit Timeline
└ AI Decision Assist
Cronozen Apps
├ Rehab
├ Edu
├ Welfare
└ (새 버티컬)
이 시점에서 외부 파트너가 Cronozen OS 위에 자신만의 버티컬을 만들 수 있습니다.
기능을 만들 때의 판단 기준
앞으로 새 기능을 추가할 때마다 하나의 질문을 합니다.
"이 기능은 버티컬 기능인가, OS 기능인가?"
| 버티컬 기능 (분야별) | OS 기능 (공통) |
|---|---|
| 재활 치료 기록 양식 | 승인 이력 관리 |
| HRD-Net 연동 규격 | 상태 전이 엔진 |
| 바우처 유형별 정산 규칙 | 증빙 파일 관리 |
| 교육과정 커리큘럼 구조 | 역할 기반 접근 제어 |
| 상권 분석 지표 | 감사 로그 |
| 인테리어 견적 양식 | 알림 근거 추적 |
OS 기능이면 반드시 core로 올립니다. 이 규칙만 지켜도 플랫폼은 자연스럽게 Vertical SaaS에서 AI 운영 OS로 진화합니다.
핵심 지표가 달라진다
이 전략에서 가장 중요한 KPI는 사용자 수가 아닙니다.
핵심 지표:
Evidence events → 증거 이벤트 수
Decision chains → 의사결정 체인 수
Workflow executions → 워크플로우 실행 수
즉, 운영 데이터 축적량입니다.
이 데이터가 축적될수록 AI 운영 모델의 정확도가 올라가고, 새 버티컬에 적용할 때 cold start 문제가 줄어듭니다.
사용자 1,000명이 매일 10건의 의사결정을 내리면 연간 365만 건의 증거 데이터가 쌓입니다. 이것이 크로노젠의 진짜 자산입니다.
크로노젠이 드문 이유
대부분의 SaaS는 이렇게 시작합니다.
CRUD → 기능 확장 → 기술 부채 축적 → 리팩토링
크로노젠은 다릅니다.
Evidence 기반 설계 → Workflow 구조화 → Audit 자동화
DPU, 해시 체인, 거버넌스 가드, JSON-LD export 같은 것들은 보통 제품이 커진 후에 추가하고 싶어하는 것입니다. 크로노젠은 이것을 처음부터 기반으로 깔았습니다.
그래서 "Vertical SaaS 중 하나"가 아니라 여러 SaaS를 만드는 운영 OS가 될 가능성이 있습니다.
이것이 크로노젠이 선택한 길입니다.