"AI 나오면 SaaS 다 망하는 거 아닌가요?"
이 질문을 자주 받습니다.
GPT가 계약서를 쓰고, Claude가 코드를 짜고, Gemini가 보고서를 만드는 시대. 범용 AI가 이렇게 강력해지면, 특정 산업에 맞춘 SaaS는 존재 이유가 사라지는 것 아닌가?
결론부터 말하면, 틀렸습니다.
정확히 말하면 — "조건부로" 틀렸습니다. 모든 SaaS가 살아남는 것이 아니라, 구조를 가진 SaaS만 살아남습니다.
AI는 "생각"을 하고, SaaS는 "실행 구조"를 만든다
이 구분이 핵심입니다.
| 구분 | AI가 하는 것 | SaaS가 하는 것 |
|---|---|---|
| 계약 | 계약서 초안 작성 | 생성 → 검토 → 서명 → 저장 → 감사 연결 |
| 정산 | 금액 계산 | 승인 → 실행 → 증빙 → 정산 완료 → 감사 대응 |
| 매칭 | 최적 후보 추천 | 자격 확인 → 동의 → 배정 → 모니터링 → 평가 |
| 보고 | 보고서 텍스트 생성 | 데이터 수집 → 검증 → 포맷 → 제출 → 이력 관리 |
AI는 한 단계의 결과물을 만들어냅니다. SaaS는 그 결과물이 조직 안에서 실행되고, 흐르고, 기록되는 전체 구조를 만듭니다.
GPT에게 "계약서 써줘"라고 하면 텍스트가 나옵니다. 하지만 기업이 필요한 것은 텍스트가 아닙니다.
- 누가 검토했는지
- 어떤 조건으로 승인됐는지
- 언제 서명됐는지
- 변경 이력이 추적되는지
- 감사 시 제출할 수 있는지
이것은 AI의 영역이 아닙니다. **실행 구조(Execution Structure)**의 영역입니다.
버티컬 SaaS가 살아남는 진짜 이유
"버티컬 SaaS는 무조건 된다"도 틀린 말입니다. 정확히는 워크플로우와 데이터 구조를 가진 버티컬 SaaS만 됩니다.
경쟁력이 없는 것
- CSV 데이터를 보여주는 대시보드
- GPT 프롬프트를 감싼 래퍼 서비스
- 단순 CRUD에 AI 라벨을 붙인 앱
이것들은 범용 AI 도구가 더 잘합니다. ChatGPT에 파일 올리면 끝입니다.
경쟁력이 있는 것
- 로그 구조: 누가, 언제, 무엇을, 왜 했는지 연결된 기록
- 워크플로우 상태: 승인 → 실행 → 완료 → 감사까지의 상태 머신
- 증거 데이터: 변경 불가능한 방식으로 저장된 의사결정 근거
- 규제 매핑: 산업별 컴플라이언스 요건에 맞춘 데이터 흐름
병원 SaaS의 경쟁력은 "진료 기록을 예쁘게 보여주는 것"이 아닙니다. 환자 흐름 + 보험 구조 + 의료법 요건이 하나의 워크플로우로 연결되어 있는 것입니다.
교육 SaaS의 경쟁력은 "출결을 자동화하는 것"이 아닙니다. HRD-Net 보고 요건 + 훈련생 이수 기준 + 정산 증빙이 하나의 체인으로 묶여 있는 것입니다.
모델이 아니라 데이터 구조와 워크플로우가 경쟁력입니다.
그런데 구조만으로 충분한가?
여기서 한 단계 더 나아가야 합니다.
워크플로우가 있어도, 그 안에서 일어난 의사결정을 증명하지 못하면 결국 같은 문제가 반복됩니다.
기업이 실제로 겪는 상황
감사관: "이 AI 추천 결과를 왜 승인했습니까?"
담당자: "시스템이 추천해서요..."
감사관: "그 추천 근거를 보여주세요."
담당자: "..."
AI가 결과를 만들어주는 것은 쉬워졌습니다. 하지만 그 결과를 믿고 사용할 수 있는 구조는 대부분의 SaaS에 없습니다.
2026년 AI 기본법 시행 이후, 이 질문은 더 자주, 더 구체적으로 들어옵니다.
- AI가 만든 결과를 왜 채택했는지 증명할 수 있는가?
- 그 의사결정 과정이 변경 불가능한 방식으로 기록되어 있는가?
- 사후에 독립적으로 검증할 수 있는가?
SaaS 위에 필요한 것: 증빙 레이어
여기서 구조가 한 층 더 생깁니다.
┌─────────────────────────────────┐
│ 사용자 (조직) │
├─────────────────────────────────┤
│ SaaS (워크플로우 실행) │ ← 업무 처리
├─────────────────────────────────┤
│ AI (결과 생성) │ ← 추천·분석·자동화
├─────────────────────────────────┤
│ 증빙 레이어 (Proof Layer) │ ← 검증·기록·증명
└─────────────────────────────────┘
| 레이어 | 역할 | 예시 |
|---|---|---|
| AI | 결과를 만든다 | "이 강사를 추천합니다" |
| SaaS | 실행 흐름을 관리한다 | 추천 → 검토 → 승인 → 배정 |
| 증빙 레이어 | 그 실행이 맞았음을 증명한다 | 해시 체인 기록 + 감사 제출 |
일반적인 SaaS는 "업무를 도와준다"에서 끝납니다.
증빙 레이어가 있는 SaaS는 **"그 업무가 올바르게 수행되었음을 증명한다"**까지 갑니다.
이 차이가 단순한 기능 차이가 아닌 이유는, 책임의 차이이기 때문입니다.
크로노젠이 이 구조를 선택한 이유
크로노젠은 재활·복지·교육·약국·상권 등 7개 버티컬에서 운영 SaaS를 운영하고 있습니다.
이 과정에서 반복적으로 마주친 질문이 있습니다.
- 바우처 정산이 정확한지 어떻게 증명하지?
- AI가 추천한 매칭 결과를 왜 승인했는지 기록되나?
- 3년 전 의사결정을 지금 감사에서 소명할 수 있나?
이 질문들에 답하기 위해 만든 것이 **DPU(Decision Proof Unit)**입니다.
DPU가 하는 일
- 운영 의사결정이 발생합니다
- 결정의 맥락(누가, 왜, 어떤 근거로)을 구조화합니다
- SHA-256 해시 + 타임스탬프 + 이전 해시를 결합하여 변경 불가능한 체인에 기록합니다
- 감사 기관에 JSON-LD v2 표준 포맷으로 즉시 제출할 수 있습니다
이전 기록에 의존하는 체인 구조이므로, 중간 기록을 위변조하면 체인이 깨집니다. 이것이 증빙의 무결성을 보장합니다.
버티컬별 적용 예시
| 버티컬 | 증빙 대상 | 감사 시나리오 |
|---|---|---|
| 재활 | 바우처 매칭 승인, 치료 세션 기록 | "이 치료사는 어떤 근거로 배정됐나?" |
| 교육 | HRD-Net 출결, 훈련 이수 판정 | "이 훈련생의 이수 기준 충족 근거는?" |
| 복지 | 서비스 배정, 수급 자격 판단 | "이 수급자에게 왜 이 서비스를 배정했나?" |
| 정산 | 금액 산출, 청구 승인 | "이 정산 금액의 산출 근거를 제시하라" |
이것은 "AI 기능을 추가한 SaaS"가 아닙니다. 모든 운영 의사결정이 증명 가능한 구조 위에서 실행되는 시스템입니다.
AI 시대 SaaS 생존의 3가지 조건
정리하면, AI가 범용화되는 시대에 SaaS가 살아남으려면 3가지가 필요합니다.
1. 워크플로우 구조
단순히 "AI 결과를 보여주는 것"이 아니라, 그 결과가 조직 안에서 어떻게 흐르는지를 정의한 실행 구조.
2. 산업별 데이터 모델
범용 데이터가 아니라, 해당 산업의 규제·관행·요건에 맞춰 설계된 데이터 구조. 이것은 GPT가 만들어줄 수 없습니다.
3. 실행 증빙
워크플로우 안에서 일어난 의사결정을 사후에 독립적으로 검증 가능한 방식으로 기록하는 증빙 체계. 이것이 AI 시대에 새롭게 요구되는 조건입니다.
AI 시대 이전: 워크플로우 + 데이터 = 충분
AI 시대 이후: 워크플로우 + 데이터 + 증빙 = 필수
세 번째 조건이 추가된 이유는 명확합니다. AI가 의사결정에 개입하면서, "왜 그렇게 결정했는가"에 대한 설명 책임이 기업에 부과되기 시작했기 때문입니다.
결론: SaaS는 안 망한다. 대신 증명할 수 있는 놈만 산다
AI 시대에 SaaS가 사라진다는 주장은 AI와 SaaS의 역할을 혼동한 것입니다.
AI는 범용 도구입니다. 누구나 같은 모델을 씁니다.
SaaS는 실행 구조입니다. 산업별 워크플로우와 데이터 모델은 아무나 만들 수 없습니다.
그리고 그 실행 구조 위에 증빙 레이어가 올라가면, 단순한 업무 도구가 아니라 조직의 의사결정을 책임질 수 있는 시스템이 됩니다.
AI가 결과를 만들어주는 건 쉬워졌습니다. 하지만 그 결과를 책임질 수 있는 구조는 아직 대부분 없습니다. 그 구조를 만드는 것이 크로노젠이 하는 일입니다.
크로노젠의 증빙 레이어(Proof Layer)가 실제로 어떻게 동작하는지 궁금하다면, AI 플랫폼에 실행 증빙을 붙이는 3가지 방법에서 MCP 서버, SDK, REST API 연동 방법을 확인할 수 있습니다.