20억 명의 사용자를 위한 단일 접점 멀티모달 인터페이스

20억 명 이상의 사용자가 이용하는 왓츠앱(WhatsApp) 플랫폼에서 단일 비즈니스 번호를 통해 텍스트, 음성노트, 실시간 전화를 모두 수용하는 통합 주문 시스템을 구축했다. 고객은 별도의 앱 설치나 로그인 과정 없이 왓츠앱 대화창에서 AI 에이전트와 상호작용하며 첫 인사부터 최종 주문 확정까지의 전 과정을 처리한다. 기업은 채널별로 파편화된 진입점을 하나로 통합하여 운영 효율을 높이고 고객 접점을 단순화한다.

시스템은 단일 백엔드와 교차 채널 메모리(Cross-channel memory)를 공유하여 고객의 이력을 통합 관리한다. 고객이 오늘 텍스트로 메뉴를 문의하고 내일 음성 전화로 주문을 완료하더라도, 시스템은 동일한 고객 식별자를 통해 이전 대화 맥락을 유지하며 응답한다. 이는 채널마다 별도의 봇을 구축할 필요 없이 하나의 통합된 메모리 계층에서 고객 상태를 추적하는 구조를 통해 구현된다.

사용자가 전송하는 데이터의 형태에 따라 처리 런타임(Runtime)은 분기되지만, 내부의 비즈니스 도구와 메모리 접근 권한은 동일하게 유지된다. 텍스트 메시지는 웹훅(Webhook)으로, 음성 데이터는 미디어 처리 파이프라인으로 수신되어 동일한 백엔드 로직으로 전달된다. 결과적으로 고객은 입력 매체를 변경하더라도 대화의 연속성을 경험하며, 운영자는 단일한 백엔드 관리 포인트만 유지한다.

Nova 2 Lite와 Sonic을 활용한 텍스트 및 음성노트 처리

텍스트 메시지 채널은 Amazon Nova 2 Lite 모델을 Amazon Bedrock Converse API로 호출하여 처리한다. 인바운드 웹훅이 메시지를 수신하면 Nova 2 Lite가 문맥을 분석해 응답을 생성하고, Sender Lambda가 이를 왓츠앱 API를 통해 사용자에게 최종 전달한다. 추론 속도가 빠른 Lite 모델을 배치함으로써 텍스트 기반 질의응답에서 발생하는 응답 지연 시간을 최소화하고 처리 비용을 절감했다.

음성노트 채널은 Amazon Nova 2 Sonic 모델의 speech-to-speech 기능을 사용하여 텍스트 변환 과정 없는 직접 응답 구조를 구현했다. 워커(Worker)가 왓츠앱에서 전송된 OGG Opus 바이트를 다운로드해 16kHz PCM으로 디코딩한 뒤, 이를 Nova 2 Sonic 세션에 직접 입력한다. 모델이 음성 신호를 직접 해석해 다시 음성으로 출력하는 voice-in, voice-out 방식을 통해 전사(Transcription) 단계를 제거함으로써 응답 속도를 높이고 화자의 뉘앙스를 보존한다.

텍스트와 음성노트의 모든 출력 결과물은 Sender Lambda라는 단일 전송 경로를 통해 왓츠앱으로 전달된다. 입력 매체에 따라 Nova 2 Lite와 Nova 2 Sonic으로 모델 호출 경로를 분리하지만, 최종 전송 단계에서는 파이프라인을 통합해 관리 효율을 확보했다. 이를 통해 운영자는 매체별 모델 성능을 개별적으로 제어하면서도 사용자에게는 일관된 응답 톤을 제공한다.

WebRTC와 KVS TURN 릴레이 기반의 실시간 음성 전화 구현

사용자가 왓츠앱에서 전화 기능을 실행하면 Meta Calling API가 WebRTC 세션 설명 프로토콜(SDP) 오퍼를 포함한 연결 웹훅을 시스템에 전달한다. 워커는 이 정보를 음성 전화 런타임으로 전달하며, 런타임은 공인 IP가 없는 내부망 환경 특성에 맞춰 중계 서버를 통해서만 데이터를 주고받는 `turnOnly` 모드로 동작한다. 이 과정에서 Meta의 Calling API와 AWS 런타임 간의 세션 연결이 확립된다.

중계 서버 운영을 위한 TURN 자격 증명은 Amazon KVS(Kinesis Video Streams)에서 생성하고 관리한다. Meta 플랫폼이 Trickle ICE 방식을 지원하지 않으므로, aiortc answerer가 모든 네트워크 경로 수집이 완료될 때까지 대기한 후 단일 샷 SDP 응답을 생성해 Meta로 반환한다. 이를 통해 WebRTC 미디어 연결을 위한 최적의 경로를 확정하고 실시간 음성 스트리밍 준비를 마친다.

확정된 연결을 통해 음성 데이터는 DTLS 및 SRTP 프로토콜을 거쳐 KVS 관리 TURN 릴레이로 암호화되어 전송된다. 실시간 대화 생성은 Amazon Nova 2 Sonic의 speech-to-speech 기능을 활용하여 별도의 텍스트 변환 없이 음성-음성으로 즉각 응답한다. 이러한 구조는 실제 전화 통화와 유사한 낮은 지연 시간을 구현하여 사용자 경험을 최적화한다.

MCP 게이트웨이와 3계층 분리 아키텍처 설계

시스템은 왓츠앱 레이어(인터페이스), 에이전트 런타임(맥락 해석), 백엔드(데이터 관리)의 3계층 분리 아키텍처를 채택했다. 왓츠앱 레이어는 대화의 입구를 담당하고, 런타임은 채널별 미디어를 처리하며, 백엔드는 메뉴, 장바구니, 주문 내역 및 위치 정보를 관리한다. 이러한 물리적 분리를 통해 대화 채널이 추가되거나 변경되어도 핵심 주문 로직인 백엔드 시스템은 수정 없이 그대로 유지된다.

에이전트와 레스토랑 백엔드의 연결점에는 MCP(Model Context Protocol) 게이트웨이를 배치했다. MCP는 AI 모델이 외부 데이터 소스나 도구에 일관된 방식으로 접근할 수 있도록 돕는 표준 규격으로, 에이전트는 이 게이트웨이를 통해 백엔드 API에 접근한다. 백엔드의 세부 API 명세가 변경되더라도 게이트웨이 설정만 수정하면 되므로 모델 재학습이나 런타임 코드 수정 없이 유지보수가 가능하다.

트래픽 수신부는 단일 HTTPS 웹훅을 통해 모든 요청을 처리하며, 수신 즉시 `200 OK` 응답을 반환하는 비동기 처리 방식을 사용한다. 실제 비즈니스 로직은 큐(Queue)와 워커를 통해 후행 처리함으로써, 무거운 연산 과정이 왓츠앱 플랫폼의 응답 시간 제한을 초과하여 요청이 블로킹되는 현상을 방지한다. 이는 대규모 트래픽 상황에서도 주문 처리의 안정성을 보장하기 위한 설계다.

AWS CDK 배포 워크플로 및 실행 기준

AWS CDK는 VPC 구축, 백엔드 스택(DynamoDB, Location Service, REST API), Gateway 및 공유 메모리, 런타임, 웹훅 및 알림기 순으로 총 5단계의 스택을 순차 배포한다. 모든 리소스는 Amazon Nova 2 Lite, Sonic 및 AgentCore 런타임이 가용한 US East (N. Virginia, us-east-1) 리전에 배포해야 한다. 리전 선택은 최신 멀티모달 모델의 API 호출 가능 여부를 결정하는 필수 제약 사항이다.

에이전트 컨테이너 이미지는 AWS CodeBuild를 통해 ARM64 아키텍처 기반으로 빌드되어 Amazon ECR에 저장된다. 이 빌드 파이프라인을 통해 개발자는 로컬 환경에 Python, Docker 또는 복잡한 오디오 처리 툴체인을 직접 설치하지 않고도 표준화된 이미지를 생성할 수 있다. 빌드된 이미지는 각 채널별 런타임에 배포되어 실시간 요청을 처리한다.

Meta 비즈니스 플랫폼 설정은 AWS API로 자동화할 수 없으므로 사용자가 Meta 콘솔에서 직접 Meta 앱 생성 및 비즈니스 인증을 수행해야 한다. 사용자는 Meta Access Token, App Secret, Verify Token을 확보하여 AWS Secrets Manager에 저장함으로써 런타임 시 보안 연결을 유지한다. 실제 운영 환경 배포 전에는 Meta 샌드박스 테스트 번호를 활용해 비용 없이 기능을 검증할 수 있으며, 상세 설정값과 인프라 코드는 GitHub 샘플 저장소의 CDK 템플릿을 통해 적용한다.

채널별로 파편화된 고객 이력을 통합하고 구축 시간을 단축하려면, Meta 비즈니스 인증 전 샌드박스 환경에서 AWS CDK 기반의 표준 배포 경로를 통해 인프라를 먼저 검증하는 것이 가장 실용적인 실행 기준이다.