AI SaaS 이면의 숨겨진 아키텍처: 엔터프라이즈 자동화 플랫폼 구축을 통한 교훈

AI 기반 SaaS 플랫폼을 구축하면서 저는 처음에 과소평가했던 한 가지를 배웠습니다:

어려운 부분은 LLM (Large Language Model)을 호출하는 것이 아닙니다.

어려운 부분은 실제 비즈니스 환경 내에서 AI가 작동하게 만드는 것입니다.

처음에는 모든 것이 관리 가능한 것처럼 보입니다.

당신은 이렇게 생각할 것입니다:

• API 키는 그저 생성된 비밀값일 뿐이다.
• SSO (Single Sign-On)는 그저 ID 제공자(Identity Provider)를 연결하는 것이다.
• 빌링 (Billing)은 그저 Stripe을 연결하는 것이다.
• 모니터링 (Monitoring)은 그저 대시보드를 추가하는 것이다.
• 배포 (Deployment)는 그저 Docker와 Kubernetes를 사용하는 것이다.
• AI는 그저 OpenAI, Mistral, Anthropic 또는 다른 제공자를 호출하는 것이다.

그러다 플랫폼이 실제로 구축되기 시작합니다.

그리고 모든 "단순한" 주제들이 하나의 아키텍처 시스템으로 변합니다.

API 키는 단순한 API 키가 아니다

처음에 API 키는 다음과 같이 보입니다:

키 생성
해시 저장
비밀값 1회 반환

하지만 실제 SaaS 환경에서 API 키는 빠르게 다음과 같이 변합니다:

스코프 (Scopes)
만료 (Expiration)
취소 (Revocation)
...

키는 다음과 같은 질문에만 답해서는 안 됩니다:

이 키가 유효한가?

다음 질문에도 답할 수 있어야 합니다:

이 키의 소유자는 누구인가?
어느 테넌트 (Tenant)에 속해 있는가?
어떤 리소스에 접근할 수 있는가?
...

그 순간 당신은 API 키가 단순한 인증 (Authentication) 모델이 아니라, 권한 부여 (Authorization) 모델의 일부라는 것을 깨닫게 됩니다.

SSO는 단순한 로그인이 아니다

SSO는 테넌트를 다루기 전까지는 단순해 보입니다.

Keycloak, Google, Microsoft 또는 그 어떤 OIDC (OpenID Connect) 제공자를 연결하는 것이 가장 어려운 부분은 아닙니다.

어려운 부분은 무엇을 신뢰할지 결정하는 것입니다.

이메일 도메인을 신뢰할 것인가?

Subject Claim을 신뢰할 것인가?

그룹을 신뢰할 것인가?

외부 IdP (Identity Provider)에서 오는 역할을 신뢰할 것인가?

테넌트 관리자가 역할을 매핑할 수 있는가?

테넌트 관리자가 실수로 플랫폼 관리자를 생성할 수 있는가?

사용자가 여러 테넌트에 속해 있을 때는 어떤 일이 발생하는가?

토큰이 유효하지만 다른 대상(Audience)을 위해 발급되었다면 어떤 일이 발생하는가?

실제 SSO 아키텍처는 다음과 같이 변합니다:

발행자 검증 (Issuer validation)
대상 검증 (Audience validation)
Nonce 검증 (Nonce validation)
...

엔터프라이즈 SaaS에서 로그인은 단지 진입점일 뿐입니다.

진짜 질문은 다음과 같습니다:

사용자, 테넌트 (Tenant), 프로젝트 및 실행 컨텍스트 (Execution contexts) 전반에 걸쳐 신원을 신뢰할 수 있는가?

AI 사용은 단순히 모델을 호출하는 것이 아닙니다

모델을 호출하는 것은 쉽습니다.

하지만 AI를 운영하는 것은 쉽지 않습니다.

AI가 제품의 일부가 되면, 다음과 같은 사항들을 고려해야 합니다:

토큰 소비 (Token consumption)
비용 가시성 (Cost visibility)
제공업체 사용량 (Provider usage)
...

데모용이라면 모델의 응답만으로 충분합니다.

하지만 비즈니스 플랫폼이라면 다음 질문에 답할 수 있어야 합니다:

어떤 테넌트 (Tenant)가 모델을 사용했는가?
어떤 워크플로 (Workflow)가 이를 트리거했는가?
어떤 사용자가 실행을 시작했는가?
...

이 지점에서 AI는 단순한 기능(Feature)을 넘어 운영 시스템 (Operational system)이 됩니다.

빌링 (Billing)은 단순히 Stripe가 아닙니다

Stripe는 결제를 처리할 수 있습니다.

하지만 Stripe가 귀하의 제품 모델을 대신 정의해주지는 않습니다.

진지한 SaaS라면 빌링을 다음과 같은 요소들과 연결해야 합니다:

플랜 (Plans)
할당량 (Quotas)
기능 (Capabilities)
...

만약 귀하의 제품이 다음과 같이 배포될 수 있다면:

매니지드 SaaS (Managed SaaS)
고객 클라우드 (Customer cloud)
온프레미스 (On-prem)
...

그때 빌링은 단순한 결제 그 이상이 됩니다.

그것은 상업적 거버넌스 (Commercial governance)가 됩니다.

시스템은 다음을 이해해야 합니다:

고객이 무엇을 사용할 수 있는가?
제품이 어디에 배포되었는가?
구독 (Subscription)이 활성 상태인가?
...

이곳이 바로 가격 책정 (Pricing), 아키텍처, 그리고 런타임 강제 적용 (Runtime enforcement)이 만나는 지점입니다.

Kubernetes를 사용한다고 해서 자동으로 확장 가능한 것은 아닙니다

Kubernetes를 사용한다고 해서 플랫폼이 자동으로 확장 가능해지는 것은 아닙니다.

진정한 실행 플랫폼은 워크로드 (Workloads)를 고려해야 합니다.

어떤 작업은 가볍습니다.

어떤 작업은 AI 호출을 실행합니다.

어떤 작업은 파일을 처리합니다.

어떤 작업은 문서를 생성합니다.

어떤 작업은 지식을 수집 (Ingest)합니다.

어떤 작업은 긴 워크플로 (Workflows)를 실행합니다.

이는 다음과 같은 요소들을 분리하기 시작해야 함을 의미합니다:

큐 (Queues)
워커 (Workers)
레인 (Lanes)
...

어느 시점에 이르면, "배포 (Deployment)"는 실행 아키텍처 (Execution architecture)가 됩니다.

다음 사항들을 파악해야 합니다:

어떤 큐 (Queue)가 포화 상태인가?
어떤 워커 (Worker)가 실패하고 있는가?
어떤 작업이 지연되고 있는가?
...

이러한 가시성 (Visibility) 없이는 확장은 대부분 추측에 불과합니다.

관찰 가능성 (Observability)은 선택 사항이 아닙니다

자동화가 비즈니스 운영의 일부가 될 때, 모니터링은 기술적인 보너스가 아닙니다.

그것은 제품의 일부입니다.

다음과 같은 지표 (Metrics)가 필요합니다:

큐(queue) 깊이
실행 성공률 (execution success rate)
실행 실패 (execution failures)
...

엔지니어에게 관찰성 (observability)은 다음 질문에 답합니다:

무엇이 고장 났는가?

경영진에게 관찰성 (observability)은 다음 질문에 답합니다:

가치가 어디에서 창출되는가?
시간이 어디에서 절약되는가?
비용이 어디에서 증가하는가?
...

이것은 차원이 다른 가시성 (visibility)입니다.

설정 (Configuration)은 결국 제품의 표면 (Product Surface)이 된다

처음에는 환경 변수 (environment variables)만으로 충분합니다.

그러다 고객들이 다양한 설정을 요구하기 시작합니다.

다양한 제공업체 (providers).

다양한 제한 사항 (limits).

다양한 ID 구성 (identity configurations).

다양한 스토리지 (storage).

다양한 보안 정책 (security policies).

다양한 통합 (integrations).

다양한 배포 모델 (deployment models).

그러다 갑자기, 모든 변경 사항마다 재배포를 하는 것은 수용 불가능한 일이 됩니다.

그때가 바로 설정 (configuration)이 관리자 인터페이스 (admin surface)로 이동해야 할 시점입니다.

물론 모든 것을 UI에서 편집할 수 있어야 하는 것은 아닙니다.

하지만 진지한 플랫폼이라면 다음과 같은 것들을 구분해야 합니다:

부트스트랩 설정 (bootstrap configuration)
런타임 설정 (runtime configuration)
테넌트 설정 (tenant configuration)
...

제품이 엔터프라이즈화될수록, 백오피스 (back office)는 제품 그 자체의 일부가 됩니다.

진정한 SaaS + AI의 상관관계

가장 큰 교훈은 이러한 시스템들이 고립되어 설계될 수 없다는 것입니다.

이들은 서로 연결되어 있습니다.

비즈니스 모델 (Business model) ↔ 플랜 (Plans)
플랜 (Plans) ↔ 기능 (Capabilities)
기능 (Capabilities) ↔ 역할 (Roles)
...

한 부분이 취약하면 플랫폼 전체를 운영하기가 더 어려워집니다.

거버넌스 (governance)가 없는 워크플로 엔진 (workflow engine)은 위험해집니다.

미터링 (metering)이 없는 AI는 비용이 많이 듭니다.

테넌트 격리 (tenant isolation)가 없는 SSO는 위험합니다.

관찰성 (observability)이 없는 Kubernetes는 눈먼 상태가 됩니다.

런타임 강제 적용 (runtime enforcement)이 없는 빌링 (billing)은 겉치레에 불과합니다.

백엔드 강제 적용 (backend enforcement)이 없는 관리자 기능은 보안 연극 (security theater)이 됩니다.

진짜 질문들

CEO에게 질문은 단지 이것만이 아닙니다:

우리가 AI를 사용할 수 있는가?

진짜 질문은 이것입니다:

우리가 운영 역량을 회복하고, 그 영향을 측정하며, 이를 안전하게 확장할 수 있는가?

CTO에게 질문은 단지 이것만이 아닙니다:

우리가 이것을 구축할 수 있는가?

진짜 질문은 이것입니다:

우리가 실제 환경 전반에서 이를 거버넌스(Govern)하고, 보안(Secure)을 유지하며, 배포(Deploy)하고, 모니터링(Monitor)하며, 유지보수(Maintain)할 수 있는가?```

AI 책임자(Heads of AI)에게 질문은 단지 이것만이 아닙니다:

어떤 모델을 사용해야 하는가?```

진짜 질문은 이것입니다:

어떻게 하면 AI를 고립된 실험에서 통제된 비즈니스 실행(Business Execution)으로 전환할 수 있는가?```

## 마지막 생각 (Final Thought)

AI SaaS를 구축하는 가장 어려운 부분은 프롬프트(Prompt)가 아닙니다.

첫 번째 데모도 아닙니다.

첫 번째 통합(Integration)도 아닙니다.

어려운 부분은 아이덴티티(Identity), 데이터(Data), 권한(Permissions), 비용(Costs), 인프라(Infrastructure), 워크플로우(Workflows), 관측성(Observability), 그리고 사용자 경험(User Experience)이 함께 움직이도록 만드는 것입니다.

그 지점에서 AI는 엔터프라이즈급(Enterprise-ready)이 됩니다.

그리고 바로 그 지점에서 SaaS 아키텍처는 진지한 전문 영역(Discipline)이 됩니다.