멀티 테넌트(Multi-Tenant) Voice AI: 클라이언트 번호, 과금 및 오프보딩(Offboarding) 격리하기

원래 BuildWithHermes 블로그에 게시되었습니다. 만약 단일 Vapi 또는 Retell 계정에서 3개 이상의 클라이언트를 운영하고 있다면, 당신은 아직 인지하지 못하고 있는 멀티 테넌시(multi-tenancy) 문제를 겪고 있는 것입니다. 여기 이를 방지하기 위한 아키텍처(architecture)가 있습니다.

대부분의 AI 음성 에이전시(voice agencies)는 근본적으로 잘못된 아키텍처를 운영하고 있으며, 아직 그 사실을 모르고 있습니다. 하나의 Vapi 계정. 하나의 Retell 계정. 그리고 이를 공유하는 5개의 클라이언트. 전화번호는 그것을 프로비저닝(provisioned)한 사람의 소유가 됩니다. 과금(Billing)은 클라이언트별 귀속 정보가 없는 단일 인보이스(invoice)로 처리됩니다. 그리고 만약 클라이언트가 해지한다면, 그들의 통화 녹음, 전화번호, 또는 연락처 데이터가 어떻게 처리될지에 대한 깔끔한 계획을 가진 사람은 아무도 없습니다.

이것은 소프트웨어 문제가 아닙니다. 아키텍처 문제입니다. 클라이언트가 5명에 도달하여 무언가 잘못되기 전까지는 이 문제가 눈에 보이지 않습니다. 예를 들어, 한 클라이언트를 위한 지식 베이스(knowledge base) 업데이트가 다른 에이전트(agent)로 흘러 들어가거나, 해지가 전화번호 소유권을 둘러싼 분쟁으로 이어지거나, GDPR 삭제 요청으로 인해 공유 계정 속에서 특정 회사의 모든 데이터를 찾아 헤매야 하는 상황 등이 발생할 수 있습니다.

실제 멀티 테넌시(multi-tenancy) 문제

멀티 테넌시(Multi-tenancy)란 각 고객의 데이터, 설정 및 리소스가 다른 모든 고객으로부터 완전히 격리된 상태에서, 여러 독립적인 고객에게 서비스를 제공하는 하나의 플랫폼을 운영하는 것을 의미합니다. 전통적인 SaaS에서는 이것이 기본 요건입니다. 하지만 기성 인프라 도구를 사용하는 음성 AI 에이전시에서는 거의 제대로 처리되지 않는데, 그 이유는 Vapi와 Retell이 많은 최종 클라이언트를 대신하여 에이전트를 관리하는 운영자를 위한 것이 아니라, 단일 테넌트(single-tenant) 제품을 출시하는 개발자를 위해 구축되었기 때문입니다.

DIY 스택을 사용하는 에이전시들은 클라이언트가 3명을 넘어서면 세 가지 구체적인 실패 모드(failure modes)에 직면하게 됩니다:

실패 모드 1: 데이터 교차 (data crossover). 공유 계정에서는 모든 에이전트 설정(agent configs)이 동일한 네임스페이스(namespace)에 존재합니다. 클라이언트 A를 위해 의도된 지식 베이스(knowledge base) 업데이트가 잘못된 에이전트에 적용되어 클라이언트 B의 통화에 즉각적인 영향을 미칠 수 있습니다. 더 심각한 버전은 세션 데이터(session data)입니다. 공유 음성 시스템에서의 부실한 세션 관리(session management)는 한 고객의 정보가 다른 고객의 대화 중에 노출되는 결과를 초래할 수 있습니다. 클라이언트 A가 치과이고 클라이언트 B가 법률 사무소라면, 이러한 교차는 보안 위반(breach)에 해당합니다.

실패 모드 2: 과금의 불투명성 (billing opacity). 클라이언트별 귀속 정보가 없는 단일 상위 인보이스(upstream invoice)는 가장 기본적인 운영 질문인 "이번 달에 어떤 클라이언트가 얼마만큼의 비용을 발생시켰는가?"에 답할 수 없음을 의미합니다. 결국 통화 로그(call logs)로부터 사용량을 역설계(reverse-engineering)해야 하며, 귀하의 리테이너(retainer) 마진은 추측에 의존하게 됩니다.

실패 모드 3: 불가능한 깔끔한 오프보딩 (impossible clean offboarding). 공유 계정에서 클라이언트가 해지할 때, 깔끔한 단절이 이루어지지 않습니다. 그들의 전화번호, 녹음 파일, 연락처가 다른 모든 사람과 동일한 계정에 뒤엉켜 있어, 삭제 작업이 수동적이고 오류가 발생하기 쉬우며 컴플라이언스(compliance) 측면에서 책임 소지가 발생합니다.

적절한 멀티 테넌트(multi-tenant) 아키텍처의 모습

설계 단계부터 적용된 세 가지 격리 계층:

1. 워크스페이스 격리 (Workspace isolation). 각 클라이언트는 완전히 격리된 워크스페이스를 할당받습니다. 즉, 고유한 네임스페이스 내에 별도의 에이전트, 지식 베이스, 연락처 및 설정(config)을 보유합니다. 한 워크스페이스의 변경 사항은 다른 워크스페이스에 영향을 줄 수 없습니다.
2. 클라이언트별 전화번호 소유권 (Per-client phone number ownership). 전화번호는 명확한 소유권을 가지고 특정 클라이언트 워크스페이스에 프로비저닝(provisioned)되므로, 해지 시 해당 번호가 누구의 소유인지에 대한 분쟁이 발생하지 않습니다.
3. 독립적인 사용량 측정 (Independent usage metering). 모든 통화, 시간 및 리소스는 워크스페이스별로 측정되므로, 클라이언트별 비용과 클라이언트별 과금이 재구성된 데이터가 아닌 정확한 수치로 산출됩니다.

깔끔한 오프보딩 절차

클라이언트가 떠날 때, 아키텍처는 공유 계정 전체를 수동으로 뒤지는 것이 아니라 다음 다섯 단계를 독립적으로 수행할 수 있도록 만들어야 합니다:

1. 데이터 내보내기 (Data export): 클라이언트에게 녹음 파일, 전사 데이터 (transcripts), 그리고 연락처를 전달합니다.
2. 번호 전환 (Number transition): 첫날부터 소유권이 명시적이었으므로, 번호를 깔끔하게 포팅 (port) 하거나 해지합니다.
3. 데이터 삭제 확인 (Data deletion confirmation): 워크스페이스 (workspace)를 삭제하고 GDPR/컴플라이언스 (compliance)를 위해 서면으로 확인합니다.
4. 액세스 권한 취소 (Access revocation): 해당 워크스페이스에만 연결된 자격 증명 (credentials)을 취소합니다.
5. 과금 정산 (Billing settlement): 최종 클라이언트별 인보이스 (invoice)를 발행합니다. 처음부터 워크스페이스 단위로 미터링 (metering)이 이루어졌기에 정확한 정산이 가능합니다.

진정한 멀티 테넌시 (multi-tenancy)는 한 클라이언트의 오프보딩 (offboarding)을 비상 상황이 아닌, 단일하고 통제된 작업으로 만들어 줍니다.

BuildWithHermes가 적합한 이유

Hermes는 설계 단계부터 네이티브 워크스페이스 격리 (native workspace isolation)를 바탕으로 구축되었습니다: 격리된 클라이언트 워크스페이스, 클라이언트별 번호 소유권, 그리고 독립적인 워크스페이스별 사용량 미터링 (usage metering)을 통해 데이터 교차, 과금 불투명성, 그리고 복잡한 오프보딩 문제를 사후 패치가 아닌 설계 단계에서부터 제거했습니다. 하나의 플랫폼, 귀사의 브랜드, 기본적으로 멀티 테넌트 (multi-tenant) 구조입니다. Starter 플랜은 월 $149입니다.

전체 아키텍처 분석, DIY 대 네이티브 비용 비교, 그리고 10개 클라이언트 기준 레퍼런스 디자인: buildwithhermes.com