매일 아침 주문을 하려다 보면, 모바일 앱에서는 잘 되는데 웹에서는 메뉴 탐색이 끊기고, 음성으로 말하면 대화 맥락이 다음 턴에서 어긋나는 순간이 생긴다. 이번 주에는 깃허브에 있는 배포형 레퍼런스가 “음성 주문을 모바일·웹·음성 인터페이스로 동시에” 처리하는 구조를 보여준다.

Amazon Bedrock AgentCore로 에이전트를 만들고 배포·운영하는 레퍼런스를 제공했음. 음성 상호작용은 Amazon Bedrock에서 제공되는 speech-to-speech 파운데이션 모델인 Amazon Nova 2 Sonic을 사용했음. 이 아키텍처는 인증을 처리하고 주문을 처리하며, 위치 기반 추천을 제공하는 인프라를 배포하도록 구성됐음. 프런트엔드·AI 에이전트·백엔드를 분리해 각각 독립적으로 개발·확장할 수 있게 했음.

예전에는 음성 인터페이스를 별도 파이프라인으로 붙여서, 모바일 앱/웹과 주문 상태를 동기화하는 데 비용이 커지는 경우가 많았다. 이제는 AgentCore Gateway가 백엔드 엔드포인트를 “에이전트가 쓸 수 있는 툴”로 노출하도록 API 통합을 구성하는 방식으로 바뀌었다. 또한 MCP(외부 데이터 소스·툴·워크플로를 연결하는 오픈 표준)를 에이전트와 백엔드 간 표준 통신 계층으로 두어, 백엔드 통합을 특정 프레임워크에 강하게 묶지 않게 설계했음.

개발자가 바로 체감하는 변화는 “음성 주문이 여러 터치포인트에서 같은 주문 워크플로로 흘러간다”는 점이다. 이 레퍼런스는 프런트엔드(AWS Amplify), 에이전트 게이트웨이(AgentCore Gateway), 런타임(AgentCore Runtime), 백엔드(REST API·Lambda·DynamoDB·위치 서비스)를 모듈로 나눠 재사용을 쉽게 만들었다. 결과적으로 운영 부담을 줄이면서도, 대화 턴이 이어지는 동안 주문 컨텍스트를 유지하는 구조를 코드로 가져올 수 있다.

배포가 실제로 만드는 구성요소(Section A~D)

이 솔루션은 4개 섹션으로 나뉘어 배포되도록 설명돼 있다. Section A는 백엔드 인프라로, 레스토랑 샘플 아키텍처를 인프라스트럭처 코드로 프로비저닝한다. 고객 정보, 주문, 메뉴, 카트, 위치를 위한 데이터 저장소를 만들고, 주소 처리와 매핑을 위한 위치 기반 서비스를 설정한다. 비즈니스 로직은 Lambda 함수로 구성하고, 외부 접근을 위한 API 레이어와 사용자 인증·인가 서비스를 둔다. 리소스는 의존성 순서에 맞춰 배포된다.

Section B는 AgentCore Gateway로, 필요한 IAM 서비스 권한을 프로비저닝하고 AgentCore Gateway 서비스를 생성하며, API 통합으로 백엔드 엔드포인트를 에이전트 접근용 툴로 노출하도록 구성한다. Section C는 AgentCore Runtime과 ECR 이미지로, 컨테이너 저장소로 Amazon ECR을 프로비저닝하고 소스 업로드용 Amazon S3, 빌드 자동화용 AWS CodeBuild, 필요한 IAM 권한을 둔다. AgentCore Runtime 서비스는 WebSocket 프로토콜로 구성된다. Section D는 AWS Amplify로, Amplify 호스팅을 배포 구성과 함께 프로비저닝하고 백엔드 출력에서 프런트엔드 설정을 생성한다. 완성 후 웹 애플리케이션은 Amplify URL로 접근 가능해진다.

배포 전 체크와 5단계 스크립트 흐름(명령·입력 포함)

시작 전에는 GitHub 저장소를 클론하고 프로젝트 디렉터리로 이동한 뒤 배포 스크립트를 실행해야 한다. 배포 스크립트는 두 파라미터가 필요하며, 이메일 주소로 임시 비밀번호가 전송돼 초기 Cognito 테스트 유저에 사용된다. 스크립트는 사전 점검(preflight checks)을 먼저 수행해 Node.js, Python, AWS CLI, CDK, 자격증명, CDK bootstrap, 그리고 Bedrock Nova 2 Sonic 모델 접근이 준비됐는지 검증한다. 실패 시 누락 항목을 보고, 자동 설치가 가능한 범위는 자동 설치를 제안한다.

사전 점검이 통과되면 스크립트는 5단계를 실행한다. 1~3단계는 완전 자동이며, 4단계(Synthetic Data)는 중심점으로 사용할 위치(도시, 우편번호, 주소 중 하나), 검색할 음식 종류(예: pizza, burgers, coffee shop, sandwich, tacos), 고객 집 주소를 재사용할지 여부, 그리고 생성 데이터를 DynamoDB에 쓰기 전 확인을 묻는다. 5단계(Password Setup)는 이메일로 온 임시 Cognito 비밀번호를 선택적으로 변경할지 묻고, “예”를 선택하면 이메일의 임시 비밀번호를 입력한 뒤 새 영구 비밀번호를 Cognito 정책(8+자, 대문자/소문자/숫자/기호 포함) 조건에 맞춰 설정한다. 완료 후에는 프런트엔드 URL(예: https://main.<app-id>.amplifyapp.com)이 출력되며, 이를 통해 애플리케이션에 접근한다.

API·DynamoDB·위치 서비스가 주문 흐름을 받치는 방식

API Gateway는 REST API를 생성해 프런트엔드를 백엔드 서비스에 연결하며, IAM 인증된 8개 엔드포인트와 Lambda 통합을 제공한다. 백엔드는 5개의 DynamoDB 테이블로 완전한 주문 워크플로를 지원한다. Customers 테이블은 프로필(이름, 이메일, 전화, 로열티 티어, 포인트)을 저장해 개인화 추천에 쓴다. Orders 테이블은 주문 이력을 저장하고 위치 데이터를 포함하며, 위치로 쿼리하기 위해 Global Secondary Index를 사용해 위치 기반 인기 항목을 식별한다. Menu 테이블은 레스토랑별로 가격과 가용성이 달라지는 위치 기반 메뉴 아이템을 저장한다.

Carts 테이블은 임시 장바구니를 저장하며 24시간 TTL로 자동 정리를 수행한다. Locations 테이블은 레스토랑 데이터(좌표, 영업시간, 세금률)를 저장해 주문 계산과 추천에 사용한다. DynamoDB on-demand capacity는 트래픽에 따라 자동으로 스케일한다. Location Services는 고객이 픽업 위치를 찾도록 돕는 위치 기반 기능을 제공하며, 배포되는 리소스로는 지오코딩과 주소 검색을 위한 Place Index(Esri), 경로 계산을 위한 Route Calculator(Esri) 등이 포함된다.

이 레퍼런스는 “음성 주문을 옴니채널로” 옮기는 데 필요한 연결 지점을 코드로 고정해 둔다.