월 150통의 부재중 전화와 Amazon Nova 2 Sonic의 등장
저녁 피크 타임의 식당은 전쟁터다. 홀 직원은 손님 안내와 테이블 정리에 치여 전화벨이 울려도 즉각 대응하기 어렵다. 전화를 받으러 직원을 불러내면 홀 서비스가 지체되고, 그대로 두면 주문을 놓친다. 실제 통계에 따르면 식당은 지점당 월평균 150통의 전화를 놓치며, 이 중 약 60%는 실제 주문이나 예약 시도다. 앱이나 웹사이트 주문 기능을 도입해도 전화 주문을 선호하는 고객층의 이탈은 막지 못해 직접적인 매출 손실로 이어진다.
이 문제를 해결하기 위해 Amazon Nova 2 Sonic과 Bedrock AgentCore를 활용한 실시간 음성 AI 시스템을 도입한다. Nova 2 Sonic은 사용자의 말을 듣고 즉각 반응하는 음성-음성 상호작용에 최적화된 모델이다. 여기에 AI 에이전트를 호스팅하는 Bedrock AgentCore를 결합하면 인사부터 주문 확정까지 전 과정을 AI가 처리할 수 있다. 특히 전사 과정과 턴 테이킹, 사용자 끼어들기 등을 단일 양방향 스트림에서 처리해 자연스러운 대화를 구현한다.
시스템의 핵심은 MCP(Model Context Protocol)를 통해 AI 에이전트와 메뉴 및 주문 관리 백엔드를 완전히 분리하는 것이다. MCP는 에이전트가 외부 도구에 연결되는 방식을 규정한 개방형 표준이다. 기존에는 메뉴판이 바뀌거나 주문 로직이 변경되면 에이전트 자체를 다시 설계하고 배포해야 했으나, MCP를 적용하면 AgentCore Gateway가 백엔드 API를 MCP 도구로 노출하므로 에이전트 재배포 없이도 기능을 변경할 수 있다.
전화망부터 DB까지, 3계층으로 분리된 음성 AI 아키텍처
이 시스템은 통신망과 지능형 에이전트를 분리해 유지보수 공수를 줄인 3계층 구조로 설계되었다. 첫 관문인 Telephony Layer는 Amazon Chime SDK Voice Connector가 SIP 트렁크와 전화번호를 제공해 외부 전화를 수신한다. 여기서 `drachtio-server` SIP 게이트웨이가 전화망의 RTP 패킷(UDP 기반)을 AI 모델이 이해할 수 있는 WebSocket 프레임으로 변환한다.
변환된 데이터는 Agent Layer로 전달된다. AgentCore Runtime은 각 통화 세션을 독립된 마이크로VM에서 실행해 세션 간 간섭을 차단한다. 여기서 Amazon Nova 2 Sonic 모델이 음성-음성 상호작용을 직접 처리하며, 메뉴 확인이나 주문 입력이 필요할 때 MCP 도구를 호출해 백엔드 계층에 요청을 보낸다.
마지막 Backend Layer는 실제 비즈니스 로직과 데이터를 관리한다. Amazon API Gateway가 REST 엔드포인트 입구를 담당하고, AWS Lambda가 메뉴 조회, 장바구니 담기, 주문 확정 기능을 수행한다. 모든 데이터는 Amazon DynamoDB에 저장되며, 배달 주소 좌표 계산 및 최적 경로 탐색은 Amazon Location Service가 처리한다. 이 계층은 요청받은 데이터를 정확히 처리하고 반환하는 역할에만 집중하며, 입력 채널이 전화인지 앱인지와 무관하게 작동한다.
기존 방식과 달라진 지점
기존 AI 에이전트 구축 방식은 외부 도구를 추가할 때마다 시스템 전체를 다시 배포해야 하는 강한 결합 구조였다. 예를 들어 포인트 적립 기능을 추가하려면 에이전트의 도구 정의를 수정하고 AWS CodeBuild로 컨테이너 이미지를 다시 빌드해 ECR에 푸시한 뒤 런타임에 재배포해야 했다. 이 과정에서 모델 프롬프트를 수정하고 도구 호출 정확도를 다시 검증하는 회귀 테스트가 필수적이었으며, 이는 작은 변경에도 시스템 가동 중단 위험을 높였다.
반면 MCP를 도입한 이 시스템은 AgentCore Gateway가 백엔드 API를 MCP 도구 형태로 노출하므로, 에이전트는 게이트웨이가 제공하는 표준 규격만 따르면 된다. 백엔드 API 명세가 바뀌거나 새로운 도구가 추가되어도 에이전트를 다시 배포할 필요 없이 Gateway 설정만 변경하면 즉시 새로운 기능을 사용할 수 있다. 이는 배포 횟수와 검증 시간을 줄여 운영 효율을 높인다.
또한 백엔드 레이어는 전송 계층의 차이로부터 독립적이다. 전화망은 RTP 패킷 기반의 UDP 통신을 사용하고 앱이나 키오스크는 HTTP 기반의 JSON 통신을 사용하지만, MCP 기반 구조에서는 이러한 차이가 백엔드 로직에 영향을 주지 않는다. 동일한 에이전트와 백엔드 구성을 유지한 채 입력 인터페이스만 교체하면 전화 주문 로직을 그대로 앱 챗봇이나 무인 단말기에 적용할 수 있어 인프라 확장 비용이 낮아진다.
AWS CDK 기반의 배포 워크플로와 '무음 구간' 제거
실무적으로 시스템을 구축하려면 Node.js, AWS CLI, git, AWS CDK bootstrap 설치와 Amazon Bedrock 모델 액세스 권한이 필요하다. preflight check 과정을 통해 누락된 도구를 먼저 검증하는 것이 시행착오를 줄이는 방법이다. 배포는 Nova 2 Sonic과 AgentCore Runtime이 지원되는 us-east-1 리전에서 진행하며, 리소스 의존성에 따라 다음 순서로 구축한다: DynamoDB/Lambda 백엔드 $ ightarrow$ AgentCore Gateway $ ightarrow$ S3/CodeBuild/ECR 기반 AgentCore Runtime $ ightarrow$ Chime SDK Voice Connector 및 SIP 게이트웨이.
사용자가 전화를 받는 순간 AI가 즉시 응답하게 하려면 '웜업(Warm-up)' 기법이 필수적이다. 호출자가 수신 버튼을 누르기 전, 벨이 울리는 동안 에이전트 세션을 미리 활성화해 두어 무음 구간인 데드 에어(Dead air)를 제거하는 방식이다. 이를 통해 서버리스 환경의 콜드 스타트나 모델 로딩 시간을 벨소리 구간으로 숨겨 매끄러운 대화 시작을 가능하게 한다.
전체 구현 과정과 코드는 GitHub 저장소(https://github.com/aws-samples/amazon-bedrock-agentcore-restaurant-voice-ordering)에서 확인할 수 있다. 저장소를 클론한 뒤 배포 스크립트를 실행할 때 리소스 접두사(prefix)를 지정하면 동일 계정 내에서도 여러 환경을 독립적으로 구축할 수 있다. 특히 첫 배포 시 CodeBuild의 컨테이너 이미지 빌드 과정에서 수 분이 소요되므로 완료될 때까지 대기해야 하며, 배포 후 터미널에 출력된 전용 번호로 실제 주문 시나리오를 테스트할 수 있다.
한국 F&B 시장의 보이스봇 도입 시 고려할 실무 포인트
인프라 비용 측면에서 이번 아키텍처는 AWS Lambda와 Amazon DynamoDB를 활용한 서버리스 구조를 채택했다. 호출량이 적은 시간대에는 비용이 거의 발생하지 않고, 피크 타임에만 사용량에 비례해 비용이 산정되므로 소규모 사업장의 초기 진입 장벽을 낮춘다.
한국어 환경 적용 시에는 응답 지연 시간(Latency) 검증이 핵심이다. 전화 주문 고객은 1~2초의 정적만으로도 연결 상태를 의심해 대화를 중단하는 경향이 강하다. 특히 소음이 많은 식당 환경에서는 음성 인식과 생성 과정의 지연이 사용자 경험을 급격히 떨어뜨리므로, 리전 설정과 모델 최적화를 통해 체감 속도를 실제 통화 수준으로 맞추는 작업이 선행되어야 한다.
또한 MCP를 활용하면 카카오톡 알림톡이나 네이버 예약 시스템 같은 국내 필수 접점을 효율적으로 통합할 수 있다. 채널이 추가될 때마다 에이전트 로직을 다시 짤 필요 없이, 백엔드 API만 MCP 도구로 노출하면 에이전트가 이를 스스로 인식해 사용한다. 동일한 주문 로직을 유지하며 인터페이스만 확장하는 방식은 개발 공수를 줄이면서 서비스 접점을 빠르게 늘려야 하는 국내 시장 환경에 적합하다.
저녁 피크 타임에 울리는 전화벨을 놓치지 않는 것은 단순한 자동화를 넘어 실질적인 매출 방어의 문제다. Nova 2 Sonic과 Bedrock AgentCore, 그리고 MCP를 통해 지능과 로직을 분리했다면 이제 고객 접점의 제약은 사라진다. 전화에서 앱이나 키오스크로 채널이 바뀌어도 백엔드 수정 없이 에이전트만 연결하면 되는 확장성이 도입의 성패를 결정한다. 터미널에 출력된 전용 번호로 실제 주문 시나리오를 테스트하며 우리 매장에 맞는 최적의 응답 흐름을 확정하는 것으로 실무 적용을 마무리하자.
