AI SaaS 뒤에 숨겨진 아키텍처
AI SaaS 플랫폼을 구축하며 한 가지를 배웠습니다.
어려운 점은 LLM을 호출하는 것이 아닙니다. 진짜 비즈니스에서 AI가 제대로 작동하게 만드는 것이 어려운 점입니다.
처음에는 모든 것이 간단해 보입니다. 다음과 같이 생각하죠:
- API 키는 그냥 비밀번호일 뿐이다.
- SSO는 그냥 연결일 뿐이다.
- 결제는 그냥 Stripe일 뿐이다.
- 배포는 그냥 Docker일 뿐이다.
- AI는 그냥 OpenAI 호출일 뿐이다.
그러다 플랫폼이 실체화되면, 모든 간단한 주제들이 복잡한 시스템으로 변합니다.
API Keys API 키는 단순한 문자열이 아닙니다. 엔터프라이즈 SaaS에서 키는 다음을 처리해야 합니다:
- 스코프(Scopes) 및 만료.
- 취소(Revocation) 및 감사 로그(audit logs).
- 테넌트 경계 및 속도 제한(rate limits).
- 플랜 기반 액세스.
키는 누가 소유하는지, 어느 테넌트에 속하는지, 그리고 무엇에 접근할 수 있는지를 답할 수 있어야 합니다.
SSO and Identity 제공업체를 연결하는 것은 쉽습니다. 어려운 점은 무엇을 신뢰할지 결정하는 것입니다.
- 이메일 도메인을 신뢰할 것인가, 아니면 그룹을 신뢰할 것인가?
- 테넌트 관리자가 플랫폼 관리자를 생성할 수 있는가?
- 사용자가 여러 테넌트에 속해 있다면 어떻게 되는가?
실제 SSO에는 발행자 검증(issuer validation), 역할 매핑(role mapping), 세션 격리(session isolation)가 필요합니다.
Operating AI 모델을 호출하는 것은 쉽습니다. AI를 운영하는 것은 어렵습니다. 다음 사항들을 추적해야 합니다:
- 토큰 소비량 및 비용.
- 제공업체 사용량 및 지연 시간(latency).
- 재시도(retries), 타임아웃(timeouts), 폴백(fallbacks).
- 프롬프트 거버넌스 및 데이터 경계.
데모는 응답만 있으면 되지만, 비즈니스 플랫폼은 어떤 테넌트가 어떤 모델을 사용했는지, 그리고 정확히 비용이 얼마나 들었는지를 알아야 합니다.
Billing and Governance Stripe는 결제를 처리하지만, 제품을 정의하지는 않습니다. 제대로 된 SaaS는 결제를 다음 사항들과 연결합니다:
- 할당량(Quotas) 및 기능 게이트(feature gates).
- 테넌트 제한 및 구독 상태.
- 온프레미스(on-prem) 또는 고객 클라우드와 같은 배포 모드.
결제는 상업적 거버넌스가 됩니다. 고객이 무엇을 사용할 수 있는지 제어하는 역할을 합니다.
Execution and Scaling Kubernetes가 자동으로 확장성을 보장해주지는 않습니다. 다음을 분리하여 워크로드를 관리해야 합니다:
- 큐(Queues)와 워커(workers).
- 리소스 제한 및 오토스케일링(autoscaling).
- 네트워크 정책 및 관찰 가능성(observability).
어떤 워커가 실패하고 있는지, 어떤 테넌트가 가장 많은 부하를 일으키는지 알아야 합니다.
Observability 모니터링은 보너스가 아닙니다. 제품의 일부입니다.
- 엔지니어는 무엇이 고장 났는지 알아야 합니다.
- 리더는 어디에서 가치가 창출되고 어디에서 비용이 상승하는지 알아야 합니다.
가장 큰 교훈은 이 시스템들이 서로 연결되어 있다는 것입니다. AI에 미터링(metering)이 없으면 비용이 많이 들게 됩니다. SSO에 격리가 없으면 위험해집니다. 결제에 강제성(enforcement)이 없으면 형식적인 것에 불과하게 됩니다.
AI SaaS 구축에서 가장 어려운 부분은 프롬프트가 아닙니다. 아이덴티티, 데이터, 비용, 그리고 인프라가 함께 움직이도록 만드는 것입니다.
Optional learning community: https://t.me/GyaanSetuAi