1시간 대화로 만드는 Amazon Connect Customer AI Agent [AICC Builder 시리즈 #1]

Amazon Connect Customer AI Agent가 무엇으로 이루어지는지 이해하고, 코드 한 줄 없이 전화받는 PoC까지 완성하기

이 블로그는 아래 데모 영상 속 AICC Builder를 활용해 Amazon Connect Customer AI Agent를 빠르게 만드는 방법을 가이드합니다. 아래 녹음과 같이 고객 응대를 하는 우리 회사만의 AI Agent를 빠르게 구성하는 방안을 안내합니다.

Amazon Connect Customer AI Agent가 배송 조회 해주는 통화 데모 듣기

블로그 시리즈 보기

시리즈 #1: 1시간 대화로 만드는 Amazon Connect Customer AI Agent
시리즈 #2: (발행 예정): S3 Files로 Agentic AI 애플리케이션에 파일 시스템 입히기

들어가며: “우리 회사 상담도 AI Agent가 받아줄 수 있을까?”

모든 비즈니스에는 고객이 있습니다. 그리고 고객이 있으면, 그들과 연락을 하는 채널도 응당 있습니다. 전화나 채팅, 이메일로 고객을 응대하는 비즈니스, 특히 전담 고객센터를 둘 정도로 고객이 많은 비즈니스라면 한 번쯤 이런 기대를 해봤을 것입니다. 예약 조회나 단순 문의처럼 반복되는 응대를 AI 상담원이 먼저 받아줬으면 하는 기대입니다. 최근 LLM의 발전과 AI Agent의 수준, 혹은 매일 사용하는 AI 어플리케이션을 보면 기술적으로는 충분히 가능한 일입니다.

다만 막상 도입을 검토하기 시작하면 질문이 쌓입니다. 어떤 서비스를 써야 하는지, 우리 상담 업무 규칙을 AI에게 어떻게 학습시키는지, 실제 전화로 받으려면 무엇이 더 필요한지가 좀처럼 정리되지 않습니다. 그러다 보니 외부 전문 인력을 고용하고 투입해 수 주, 혹은 수 개월을 들여야 하는 프로젝트로 느껴집니다. 그렇게 착수 자체가 미뤄지는 경우가 많습니다.

AWS는 직접 상담부터 상담사 지원까지, 상담 전반을 지원할 AI 상담원을 위한 기반을 이미 제공합니다.

Amazon Connect Customer: 전화와 채팅을 받고 컨택센터의 진입 흐름을 실행합니다.
Amazon Connect Customer AI Agent: 고객과 대화하고 업무 도구를 호출하며, 필요하면 사람 상담원에게 연결합니다.
Amazon Bedrock AgentCore Gateway: OpenAPI로 정의된 업무 도구를 AI Agent가 MCP로 호출할 수 있게 연결합니다.

그러나 AWS는 각 기업의 업무 방식까지 알 수 없습니다. 다음 내용은 기업이 직접 정의해야 합니다.

자동화할 업무와 예외 상황
본인 확인, 운영 시간, 상담원 이관, 응대 말투 등의 운영 규칙
참고할 FAQ와 연결할 데이터·API

AICC Builder는 약 1시간의 인터뷰로 요구사항을 명세로 정리하고, 이를 Amazon Connect Customer AI Agent PoC에 필요한 6종 배포 에셋으로 변환하는 AWS 오픈소스 샘플 웹 애플리케이션입니다. 사용자는 한국어로 비즈니스를 설명하고, 필요하면 회사 웹사이트나 기존 문서를 함께 제공하면 됩니다. 기술적인 선택은 툴이 추천값으로 채우므로, 반나절 안에 실제 전화로 동작을 검증할 수 있습니다.

이 블로그는 2편으로 구성됩니다. 1편에서는 Amazon Connect Customer AI Agent의 동작 구조와 AICC Builder가 여섯 에셋을 만드는 과정을 살펴보고, 온라인 리테일 회사 “AnyCompany”의 고객지원 AI 상담원을 인터뷰부터 실제 통화 검증까지 따라갑니다. 2편에서는 AICC Builder의 내부 Agentic AI 구조를 다룹니다.

1. Amazon Connect Customer AI Agent는 어떻게 동작하는가

AICC Builder가 무엇을 만드는지 이해하려면, 완성된 AI 상담원이 전화 한 통을 어떻게 처리하는지를 먼저 봐야 합니다. 최신 Amazon Connect Customer 기준으로는 음성/STT provider 선택지를 별도 계층으로 두고, 전체 흐름을 다섯 가지 역할로 나누어 볼 수 있습니다.

Amazon Connect Customer AI Agent의 동작 경로

Amazon Connect Customer가 인입된 전화와 채팅을 받습니다.
음성 및 STT 계층은 요구사항에 맞게 provider를 선택합니다. 선택지는 다음 세 가지입니다.
- Amazon native integrations: Amazon Polly(Standard, Neural, Generative voices), Nova Sonic V2, Lex(STT only)를 사용할 수 있습니다.
- Amazon Connect agentic voices: 표현력 있는 음성(expressive voices)과 ASR/STT 기능을 제공합니다. Connect Customer에서만 사용할 수 있습니다. 아래를 통해 샘플을 들어보세요.
- 3P TTS/STT integrations: Deepgram 또는 ElevenLabs API key를 연결합니다.
Connect Customer AI Agent가 관리자가 선택한 모델을 기반으로 (Claude의 Haiku, Sonnet 등) 대화를 이해하고, 자율적으로 MCP 기반으로 툴들을 호출하며, 대화를 위한 텍스트를 만들어냅니다.
Amazon Bedrock AgentCore Gateway가 AI가 호출할 툴을 MCP로 등록해 두는 MCP Gateway 역할을 합니다.
업무 백엔드(AWS Lambda와 같은 API 백엔드, Amazon RDS 및 DynamoDB와 같은 DB, 혹은 이외 자체 API 등)가 실제 업무를 처리하고 결과를 돌려줍니다.

완성된 AI 상담원은 이 다섯 단계로 실행됩니다. AICC Builder는 Amazon Connect Customer 위에 우리 회사만의 AI Agent를 만들기 위해 필수적인 기반 에셋들을 하나의 명세에 맞게 생성해 줍니다.

2. AICC Builder의 구조

AICC Builder가 요구사항을 구체화하고 배포 에셋을 생성하는 전체 구조를 살펴보겠습니다.

대화·웹사이트·기존 문서를 입력하면 AICC Builder가 인터뷰, 에셋 생성, 리뷰·재생성 단계를 거쳐 배포 에셋 6종을 만든다.

위 그림처럼 AICC Builder의 흐름은 세 파트로 나뉩니다. 왼쪽 Input에는 요구사항 대화, 회사 웹사이트, 기존 문서를 넣습니다. 가운데 AICC Builder에서는 인터뷰로 모호함을 해소하고, 명세를 바탕으로 에셋을 생성한 뒤, 리뷰와 재생성을 거쳐 수정 사항을 반영합니다. 오른쪽 Output은 그 결과로 나오는 배포 에셋 6종입니다. Output에 나온 에셋은 그 자체로 완성이 아닙니다. 앞서 살펴본 Amazon Connect Customer의 AWS 서비스와 결합해 배포될 때 비로소 전화를 받는 AI 상담원이 됩니다.

인풋부터 보겠습니다. 웹 인터페이스에서 대화를 시작하면 인터뷰어 에이전트가 사용자가 원하는 컨택센터의 모습을 함께 그려나갑니다. 이때 이미 쓰던 계획안이나 데이터베이스 스키마, 요구사항 문서가 있으면 업로드할 수 있고, 문서에 빠진 부분이 있으면 이를 채우기 위한 질문을 추가로 던집니다. 그 결과로 나오는 Output이 다음 여섯 가지 에셋이며, 각각의 역할은 다음과 같습니다.

생성 에셋	무엇인가	사용 용도
Lambda Functions	각 업무(예: check_order, track_shipment)를 실제로 처리하는 Python 코드	AI가 호출하는 백엔드 로직
OpenAPI Spec	AI가 호출할 툴의 입출력을 정의한 명세	AgentCore Gateway에 등록
AI Prompt	내 비즈니스의 말투·금지사항·업무 규칙이 담긴 설정	Amazon Connect Customer AI Agent
Contact Flow	전화가 들어왔을 때의 IVR 흐름 (Amazon Connect Customer Flow JSON)	전화/채팅 진입 흐름
CDK Infrastructure	Lambda + API Gateway + DynamoDB를 한 번에 올리는 배포 코드 (실제 DB 연동 희망 시 Mock DB는 생략됨)	AWS 인프라 배포
FAQ / Knowledge Base	AI가 참고할 우리 정책 문서	AI Agent 지식 베이스

이 흐름의 백엔드에는 AICC Builder Agent가 있습니다. Strands Agents SDK 기반의 Orchestrator 에이전트가 동작하며, 8개의 전문 Sub-Agent(Research, FAQ, Infrastructure, Lambda, OpenAPI, Prompt, Contact Flow, Reviewer)를 툴처럼 불러 세부 태스크를 할당합니다.

각각의 Sub-agent들은 자신이 맡은 영역에 대한 전문적인 프롬프트로 구성되어 있습니다. 필요한 분야에 대해서는 RAG 구축, 나아가 에셋들에 대한 정합성 검증 등의 로직이 다층적으로 구현되어 있습니다. 뒤에서는 9개의 AI 에이전트가 파일을 주고받으며 협업하는 셈입니다. 이 구조를 이렇게 짠 이유는 다음 편에서 자세히 다룹니다.

내 상황에 맞게 시작하는 세 가지 모드

AICC Builder는 지금 어느 단계에 있느냐에 따라 세 가지 모드 중 하나로 시작할 수 있습니다.

시작 화면

모드	대상	입력	출력
전체 빌드 (Full Build)	처음부터 새로 시작하는 경우	1시간 인터뷰	6종 에셋 전부
단일 세그먼트 (Single Segment)	특정 부분만 필요한 경우	짧은 대화	Contact Flow, AI 프롬프트, 또는 FAQ 중 1개
기존 에셋 개선 (Improve Existing)	이미 Amazon Connect Customer를 쓰고 있는 경우	기존 flow / prompt / 손그림 스케치 첨부	다듬어진 단일 에셋

첫 번째 모드는 위 설명과 같이 6개 에셋을 모두 생성하며 아무 것도 없는 상태에서 바로 우리 회사만의 AI Agent 콜봇/챗봇을 만들 수 있게 해줍니다.

두 번째 모드는 필요한 부분만 자연어로 바로 만들어냅니다. Amazon Connect Customer 기반 AI Agent를 위한 프롬프트, RAG를 위한 FAQ, 혹은 AI Agent와 무관하게 Amazon Connect Customer를 사용하기 위해 필수적인 IVR 흐름 역할을 하는 Contact Flow가 대상입니다.

세 번째 모드는 진입 장벽이 가장 낮습니다. 이미 컨택센터를 운영 중이라면 처음부터 새로 만들 필요 없이 지금 쓰고 있는 자산을 다듬는 데서 출발할 수 있습니다. 손으로 그린 화이트보드 스케치 한 장 등을 첨부하면 Amazon Connect Customer가 그대로 받아들이는 Contact Flow로 바꿔줍니다.

이러한 구조 때문에 AICC Builder는 일반 Amazon Connect Customer 기반 컨택센터를 구성하기 위해 필요한 Flow 등을 만드는 데에도 도움을 줄 수 있습니다.

3. 실제 사용 흐름 예시

이 글에서는 온라인 리테일 회사 AnyCompany의 고객지원 AI 상담원을 만드는 시나리오를 활용해 AICC Builder의 처음부터 끝까지 따라가 보겠습니다. 목표는 전화로 주문 조회, 배송 추적, 반품·교환을 처리하는 AI 상담원입니다.

AICC Builder를 배포한 후 웹 채팅 인터페이스에 로그인하면 곧바로 대화가 시작됩니다.

AnyCompany 시나리오로 실제 진행한 인터뷰 화면. 인터뷰어 에이전트가 상담원 이름·언어, 주문 조회 시 반환 항목 등 모호한 부분을 되물으며 확인한다.

인풋으로 넣을 우리 회사의 정보가 정리되어 있지 않다면?

본격적인 인터뷰에 앞서, 우리의 준비 부담을 줄여주는 기능이 하나 있습니다. Amazon Bedrock AgentCore Gateway의 웹 검색 기능을 활용하면, 회사 이름과 홈페이지 주소만 입력해도 AI가 웹에서 직접 조사를 해줍니다. 별도의 검색 API 키를 발급받지 않아도 됩니다.

AWS 네이티브하게, 권한 설정만으로 웹 상 정보를 가져옵니다. 정리되어 있는 문서가 있다면 이 작업은 생략됩니다. 없다면 홈, 서비스 소개, FAQ, 이용약관 페이지를 읽어 산업군과 주요 서비스, 정책을 알아서 파악한 뒤 첫 질문을 던집니다.

인터뷰: 우리 비즈니스에 적합한 AI 상담원을 만들기 위한 과정

AICC Builder는 엣지 케이스까지 고려하여 인터뷰를 진행하며 Spec을 잡아갑니다. 위 캡처와 같이 인터뷰가 시작된 후 진행되는 인터뷰를 축약하면 다음과 같이 진행됩니다.

초반: 어떤 비즈니스이고, 무슨 업무를 맡길 것인가

AI:  안녕하세요. 어떤 비즈니스의 AI 상담원을 만들어 드릴까요?
고객:  온라인 리테일입니다. 회사명은 AnyCompany예요.
AI:  고객이 AI 상담원에게 가장 자주 문의할 업무는 무엇인가요?
    운영 시간대와 대략적인 통화량도 같이 알려주시면 도움이 됩니다.
고객:  주문 조회, 배송 추적, 반품·교환 요청 세 가지입니다.
    평일 9시~18시(미 동부 시간) 상담원 운영이고, 그 외 시간엔 자동 응대만 됩니다.

중반: 업무 규칙의 예외 상황을 파고듭니다

AI:  주문 조회는 무엇을 기준으로 받을까요? 주문번호, 전화번호, 이메일 중에서요.
고객:  주문번호로 받되, 주문번호를 모르면 전화번호로도 찾게 해주세요.

AI:  주문 정보를 알려주기 전에 본인확인은 어떻게 할까요?
고객:  발신 전화번호를 자동으로 대조하고, 주문번호 뒤 4자리를 확인받는 정도면 됩니다.

AI:  반품·교환은 언제까지 가능한가요?
고객:  배송 완료일로부터 14일 이내입니다. 기한이 지났거나 반품 불가 품목이면 사람 상담원에게 연결해 주세요.

AI:  배송 추적은 무엇으로 받을까요?
고객:  주문번호로요.

AI:  아직 발송 전이라 운송장 번호가 없을 때는 어떻게 안내할까요?
고객:  "아직 준비 중이라 배송이 시작되지 않았다"고 안내해 주세요.

기존 우리 요구사항 안에는 미처 고려하지 못한 여러 모호함이 있고, 툴은 이를 하나씩 확인합니다. 평소 담당자의 머릿속에만 있던 업무 규칙을 툴이 질문으로 끌어냅니다.

후반: 데이터, 말투, 외부 연동

AI:  기존 주문 데이터베이스가 있으신가요? 있으시면 스키마를 업로드해 주세요.
    없으시면 DynamoDB로 새로 설계해 드리겠습니다.
고객:  새로 설계해 주세요.

AI:  발신자 전화번호로 고객을 미리 알아보고 개인화 인사를 할까요?
고객:  네, 전화번호로 고객을 먼저 조회해서 이름으로 인사해 주세요.

AI:  AI 상담원이 해결하지 못하는 상황에서 사람 상담원 연결 기준은 무엇인가요?
고객:  본인확인이 실패하거나, 분실 배송 조사가 필요하거나, 고객이 "사람 바꿔주세요"
    라고 하면요. 상담원은 평일 9시~18시(동부 시간)에만 있으니 그 외 시간엔
    콜백 예약을 안내해 주세요.

AI:  SMS, 이메일 같은 외부 연동이 필요한 업무가 있나요?
고객:  지금은 없습니다. 전화로 안내만 하면 됩니다.

기술 용어를 몰라도 툴이 선택지를 제시하고 추천값을 알려주기 때문에, PoC를 기준으로 “잘 모르겠으면 추천대로 해주세요”라고 답해도 합리적인 값으로 채워집니다.

마무리: 요약과 확인

AI:  지금까지 모인 요구사항을 정리해서 보여드리겠습니다.

    [업무]
    1. check_order    : 주문 조회 (주문번호 또는 전화번호 기준)
    2. track_shipment  : 배송 추적 (주문번호 기준, 발송 전엔 준비 중 안내)
    3. request_return  : 반품·교환 요청 (배송 완료 후 14일 이내)

    [정책]
    - 본인확인: 발신 전화번호 자동 대조 + 주문번호 뒤 4자리 확인
    - 반품·교환: 배송 완료일로부터 14일 이내, 초과 시 사람 상담원 연결
    - 상담원 운영: 평일 9시~18시(동부 시간), 그 외엔 콜백 예약 안내

    [말투 / 상담원 연결]
    - 친근하고 공감하는 음성 대화체
    - 본인확인 실패, 분실 배송 조사, 명시적 요청 시 사람 상담원 연결

    이 내용이 맞다면 "확인" 이라고 답해 주세요. 잘못된 부분이 있다면 지금 바로 고칠 수 있습니다.
고객:  확인.

AI:  인프라 → Lambda/OpenAPI/Prompt/Contact Flow → 리뷰 순으로 에셋을 생성하겠습니다.

각 단계에서 인터뷰어는 답이 모호하다고 판단하면 다음으로 넘어가지 않습니다.

4. 생성 에셋 검토 및 Amazon Connect Customer AI Agent 흐름 이해하기

인터뷰를 마치면 이를 기반하여 모든 Agent들이 참고하게 되는 Spec이 작성되고, 여섯 가지 에셋 생성이 시작됩니다. 결과적으로 아래의 아키텍처를 위한 에셋을 만들어 냅니다.

목표 아키텍처는 이와 같습니다. 왼쪽의 Amazon Connect Customer가 전화나 채팅을 받고, Contact Flow와 선택된 음성/STT provider를 통해 AI Agent로 대화를 넘깁니다. FAQ는 S3의 Knowledge Base에 배치되며, AI Agent가 MCP의 retrieve 기능으로 직접 조회하므로 AgentCore Gateway를 거치지 않습니다. OpenAPI 스펙은 AgentCore Gateway의 Target으로 등록되어 업무 툴 호출을 중계하고, 오른쪽의 비즈니스 백엔드(Lambda, API Gateway, DynamoDB)가 실제 업무를 처리합니다.

Amazon Connect Customer AI Agent 흐름

이 섹션에서는 AnyCompany 시나리오를 이어갑니다. 각 에셋이 어떻게 생겼고, 무슨 역할을 하도록 생성되며, 서로 어떻게 작용하여 하나의 AI 상담원이 되는지를 전화가 들어오는 순서대로 살펴봅니다.

4-1. Contact Flow: 전화가 들어오는 입구

고객이 Amazon Connect Customer 기반 컨택센터로 전화를 걸면 가장 먼저 IVR 흐름인 Contact Flow를 타게 됩니다. Contact Flow는 처음부터 끝까지 고객이 콜센터와 상호작용하는 경험을 정의하는 기능입니다. 생성 결과의 한쪽에는 이 흐름의 실제 파일인 JSON이, 그리고 이를 시각화한 다이어그램이 나옵니다.

생성된 Contact Flow 다이어그램

이 샘플 흐름을 보면 전화를 받아 1/ 전화번호로 고객을 먼저 조회하고(customer_lookup Lambda), 2/ 영업시간을 확인한 뒤 3/ Set Voice 블록에서 음성 provider를 설정하고, 4/ 판단은 AI 상담원에게 넘기도록 짜여 있습니다.

업무 도메인이 무엇이든 AI Agent 사용 시 “받고 → 준비하고 → AI에게 넘기고 → 결과에 따라 분기한다”는 뼈대는 유사합니다. 이 설정 파일을 Amazon Connect Customer 관리 콘솔에서 불러오기(Import)하면 바로 사용할 수 있습니다. Contact Flow는 정해진 블록 타입과 문법을 지켜야만 Amazon Connect Customer가 받아들이며, AICC Builder는 이를 잘 지키도록 RAG 구성 등이 짜여 있습니다.

4-2. AI Prompt: AI 상담원의 성격과 응대 규칙

전화를 받은 다음, 실제 응대를 하는 Connect AI Agent가 어떤 말투로 말하고, 어떤 규칙을 따르며, 어떤 툴을 언제 부르는지를 정해 주는 것이 핵심 요소가 AI Prompt입니다.

생성된 AI 프롬프트(Ava)

핵심만 간추리면 다음과 같습니다.

system: |
  당신은 온라인 리테일 회사 AnyCompany의 친절하고 전문적인 고객지원
  상담원 Ava입니다. 주문 조회, 배송 추적, 반품·교환 요청을 돕습니다.
  계정 정보에 접근하기 전에는 항상 고객의 신원을 확인합니다.

  <instructions>
  모든 대화는 다음 인사말로 따뜻하게 시작합니다:
    "AnyCompany 고객지원에 전화해 주셔서 감사합니다! 저는 가상 상담원 Ava입니다. 무엇을 도와 드릴까요?"
  고객이 주문에 대해 문의하면 check_order 툴을 사용합니다. 호출 전에 주문번호(orderId) 또는 전화번호(phoneNumber) 중 하나는 반드시 확보해야 합니다.
  database, API, knowledge base, tool 같은 기술 용어는 절대 사용하지 않습니다.
  운송장 번호는 한 글자씩 끊어서 읽어 줍니다.
  가능하면 응답은 두세 문장으로 짧게 유지합니다.
  </instructions>

페르소나(말투)와 인사말, 업무 규칙, 그리고 음성 대화에 맞춘 세부 지침(전문 용어 금지, 운송장 번호는 한 글자씩 읽어 주기 등)이 한 파일에 정리됩니다. 뒤에 붙일 Open API 스펙 파일 속 지침들 역시 이 프롬프트의 {{$.toolConfigurationList}} 변수로 추가하면 프롬프트의 일부가 됩니다.

4-3. FAQ: RAG 구성을 위한 사내 문서

AI Agent를 구성하는 또 하나의 에셋은 FAQ입니다. 이미 정리된 사내 FAQ가 있다면 그것을 그대로 써도 됩니다. AICC Builder에서는 관련 내용 인풋 및 웹 검색을 기반하여 비즈니스 종류에 맞춰 여러 문서를 생성하는 데에 도움을 줍니다. 각 문서는 AI Agent의 지식 베이스에 업로드되어 답변의 근거 자료가 됩니다. 아래 화면에서 보이듯, 이 샘플에서는 주문 조회·배송 추적·반품/교환·일반 지원 네 개의 정책 문서가 생성되었습니다.

생성된 가상의 FAQ 지식 베이스.

# 주문 조회 및 주문 상태 — 정책 및 FAQ

## 고객이 주문을 조회하는 방법
고객은 다음 중 하나로 주문을 조회할 수 있습니다:
- 주문번호 (형식: ORD- 뒤에 6자리, 예: ORD-1A2B3C)
- 주문 시 사용한 전화번호

주문 상세 정보를 안내하기 전에, 고객은 본인확인을 위해 주문번호 뒤
4자리를 확인해 줍니다.

## 주문 상태별 안내 문구
| 상태 | 고객에게 안내할 내용 |
|------|----------------------|
| 처리 중 | "주문이 준비 중이며 아직 발송되지 않았습니다." |
| 발송됨 | "주문이 배송 중입니다. 운송장 정보를 안내해 드릴 수 있습니다." |
| 배송 완료 | "저희 기록상 [날짜]에 배송이 완료되었습니다." |

FAQ는 위 양식을 꼭 따를 필요는 없지만, 가급적 질의나 항목 단위로 별도 txt 파일 등으로 나누어 저장하는 것을 권장합니다.

4-4. OpenAPI Spec: 툴들의 명세

AI Prompt에서 다룬 것처럼, AI Agent는 크게 두 가지, 프롬프트와 툴로 구성됩니다. 이때 AI에게 호출할 수 있는 툴의 항목은 프롬프트에 {{$.toolConfigurationList}}가 있으면 연결된 AgentCore Gateway의 OpenAPI Spec 파일이 프롬프트에 로딩됩니다. 다만 Amazon Connect Customer AI Agent의 MCP 타겟은 AgentCore Gateway의 타겟을 모두 지원하기 때문에 반드시 OpenAPI 기반으로 연결할 필요는 없습니다. Lambda 함수를 직접 연결하는 등의 구성 역시 자유롭게 가능합니다.

AI Agent가 “주문을 조회해야겠다”고 판단하면 OpenAPI Spec에 작성된 명세 기반으로 적절한 파라미터를 입력하여 툴을 호출합니다.

생성된 OpenAPI 스펙. 각 툴의 경로·operationId·입출력 스키마가 정의되어 있다

paths:
  /tools/check_order:
    post:
      operationId: check_order
      summary: "Look up an order by order number or phone number"
      x-amazon-connect-tool-name: check_order
      requestBody:
        content:
          application/json:
            schema:
              $ref: "#/components/schemas/LookupOrderRequest"
      responses:
        "200": { description: "Order(s) found" }
        "404": { description: "Order not found" }
components:
  schemas:
    LookupOrderRequest:
      type: object
      properties:
        orderId:
          type: string
          description: "The full order ID (e.g., ORD-123456)"
        phoneNumber:
          type: string
          description: "Customer phone number to look up orders via GSI (E.164)"

이 스펙은 Amazon Bedrock AgentCore Gateway에 그대로 업로드됩니다. 툴 이름 check_order는 앞서 프롬프트가 부르라고 지시한 바로 그 이름이고, 입력 필드 이름(orderId, phoneNumber)도 프롬프트가 참조한 이름과 정확히 같습니다. x-amazon-connect-tool-name처럼 x-로 시작하는 항목은 AI Agent에 툴을 추가할 때 표시되는 이름입니다.

4-5. Lambda Functions: 툴의 실제 백엔드

툴이 호출되면, 백엔드 서버 역할을 하는 Lambda입니다. 앞서 명세로 정의한 check_order 툴의 실제 구현이 여기 들어갑니다. 만약 자체 API를 사용한다면 당연히 Lambda가 아닌 어떤 백엔드 서버가 Lambda 함수들을 대신할 수 있습니다.

생성된 Lambda 함수(check_order). 주문번호 또는 전화번호로 DynamoDB를 조회하는 Python 코드

생성된 조회 로직을 요약하면 다음과 같습니다.

import os
import json
import boto3
from boto3.dynamodb.conditions import Key

dynamodb = boto3.resource("dynamodb")
table = dynamodb.Table(os.environ["ORDERS_TABLE_NAME"])
PHONE_GSI_NAME = "phoneNumber-index"

def handler(event, context):
    body = json.loads(event.get("body", "{}"))
    order_id = body.get("orderId")
    phone_number = body.get("phoneNumber")

    if not order_id and not phone_number:
        return create_response(400, {
            "success": False,
            "message": "Please provide either an order number or phone number.",
        })

    orders = []
    if order_id:
        # 주문번호가 있으면 기본 키로 바로 조회
        item = table.get_item(Key={"orderId": order_id}).get("Item")
        if item:
            orders.append(format_order(item))
    else:
        # 전화번호만 있으면 phoneNumber-index GSI로 조회
        resp = table.query(
            IndexName=PHONE_GSI_NAME,
            KeyConditionExpression=Key("phoneNumber").eq(normalize_phone(phone_number)),
        )
        for item in resp.get("Items", []):
            orders.append(format_order(item))

    if not orders:
        return create_response(404, {
            "success": False,
            "message": "No order found matching the provided information.",
        })

    return create_response(200, {"success": True, "orders": orders})

인터뷰에서 정리된 명세가 잘 작성된 것을 볼 수 있습니다. “둘 다 없는 경우”(400)나 “찾지 못한 경우”(404)처럼 정상 흐름을 벗어난 분기 및 전화번호 정규화 등의 로직도 구현된 것을 볼 수 있습니다.

4-6. CDK Infrastructure: 이 모두가 올라갈 기반 인프라

마지막으로, Lambda가 실제로 실행되어 데이터를 읽고 쓰려면 이를 감싸는 인프라, 즉 API Gateway나 목 데이터를 포함한 데이터베이스 테이블, 환경 변수 등과 IAM 권한이 필요합니다. 이 모두를 CloudFormation 템플릿이 처리합니다.

생성된 CloudFormation 템플릿. DynamoDB 테이블·Lambda·API Gateway·IAM Role 등

Resources:
  OrdersTable:
    Type: AWS::DynamoDB::Table
    Properties:
      TableName: !Sub "${ProjectName}-${Environment}-Orders"
      AttributeDefinitions:
        - AttributeName: orderId
          AttributeType: S
        - AttributeName: phoneNumber
          AttributeType: S
      KeySchema:
        - AttributeName: orderId
          KeyType: HASH
      GlobalSecondaryIndexes:
        - IndexName: phoneNumber-index
          KeySchema:
            - AttributeName: phoneNumber
              KeyType: HASH
          Projection:
            ProjectionType: ALL

  LookupOrderFunction:
    Type: AWS::Lambda::Function
    Properties:
      Runtime: python3.12
      Handler: index.handler
      Environment:
        Variables:
          ORDERS_TABLE_NAME: !Ref OrdersTable

AICC Builder는 빠른 PoC를 위해 임의의 DB는 DynamoDB 등을 기본으로 만들지만, 필요에 따라 기존 DB를 스캔하도록 하거나, API를 우리 API로 대체하게 할 수 있습니다. 하지만 그 어떤 것도 아직 없어도 이 모두를 만들어 주는 툴입니다.

여기까지가 하나의 AI 상담원을 이루는 여섯 가지 요소입니다. 각 부분은 모두 서로 맞물립니다. 전화를 받는 Contact Flow, 판단하는 AI Agent(Prompt·FAQ), 툴을 여는 OpenAPI, 일을 처리하는 Lambda, 그것이 올라갈 인프라로 구성됩니다.

5. 생성된 에셋 배포 및 Amazon Connect Customer AI Agent 완성하기

대화를 마치면 모든 에셋들은 하나의 ZIP 파일로 내려받을 수 있습니다. 이제 이 에셋을 실제 Amazon Connect Customer 위에 올릴 차례입니다. 동봉되는 deploy.sh 스크립트가 배포를 처리하는데, 실행 시 두 가지 범위 중 하나를 선택할 수 있습니다.

인프라부터 AI Agent·전화번호까지 전 과정을 CLI로 끝내는 전체 자동화
인프라까지만 자동화하고 Connect 콘솔 구성을 직접 해보는 코어 배포

5-1. 한 줄로 끝나는 자동 배포: deploy.sh

deploy.sh는 함께 패키징된 에셋 전체를 CloudShell 등에 올린 상태에서 사용하는 것을 권장합니다.

실행하면 배포 이름(같은 계정에 여러 PoC를 나란히 둘 수 있습니다)과 배포 범위를 묻고, 다음 순서대로 배포합니다. 모든 결정 지점은 계정에서 실시간 조회한 객관식 메뉴로 제시됩니다.

인프라 배포: 생성된 CloudFormation 템플릿을 배포
에셋 업로드: 모든 Lambda 코드를 올리고, OpenAPI 스펙과 FAQ 문서를 각각 S3에 배치
Amazon Connect Customer 준비: 인스턴스를 새로 만들거나 기존 것에 연결하고(필수 인스턴스 속성 활성화 포함), AI Assistant와 지식 베이스(Knowledge Base)를 생성·연결하며, 세션 연동 Lambda에 실행 권한까지 부여
AI 툴 연결: AgentCore Gateway와 API Key를 만들고, 생성된 OpenAPI를 AI가 호출할 툴(Target)로 등록. JWT Audience를 자동 교정·검증하고 MCP 서버를 Connect에 Integration으로 등록
전체 자동화 선택 시 추가: Lex 봇 생성(AI Assistant 연결, Nova Sonic · Advanced ASR 등 스피치 모델 선택), 음성 제공자 선택(Amazon Connect agentic voice 또는 Polly), Contact Flow Import(모든 placeholder 자동 해석), AI Agent 생성과 보안 프로필 부착(API로 부착 검증), 기본 셀프서비스 지정, 전화번호 발급까지 이어서 처리

약 10~15분 뒤 “✅ Deployment Complete!”와 함께 API Endpoint, Connect 인스턴스, AI Assistant ID, Gateway ID 같은 값이 출력됩니다. 스크립트는 멱등적이라 중단돼도 다시 실행하면 완료된 단계는 건너뛰고 이어서 진행합니다.

5-2. 콘솔에서 마무리하기 (코어 배포를 선택한 경우)

전체 자동화를 선택했다면 이 단계는 이미 끝나 있으므로 콘솔에서 결과를 확인만 하고 테스트로 넘어가면 됩니다. 코어 배포를 선택했다면 아래 항목을 콘솔에서 수행합니다.

AI 툴 권한 열기: AgentCore Gateway의 Allowed Audience를 확인하고, Connect에 MCP 서버로 등록
음성/STT provider 선택·설정: Connect Customer 콘솔의 Set Voice 블록과 bot speech configuration에서 Amazon native integrations(Polly, Nova Sonic V2, Lex STT-only), Amazon Connect agentic voices, 3P TTS/STT 중 PoC에 맞는 옵션을 선택·설정하고, 생성된 Contact Flow를 불러오기(Import). agentic voice의 언어별 세부 보이스는 콘솔에서만 미리 듣고 고를 수 있습니다
AI Agent 구성: 생성된 AI Prompt를 기반으로 AI Agent를 만들고, MCP 도구 접근 권한을 가진 보안 프로필을 부착해 셀프서비스 상담원으로 지정
전화번호 연결: 전화번호를 발급받아 Contact Flow에 연결

네 가지 모두 화면이 가이드에 그대로 실려 있어, 보면서 따라 하면 됩니다. 콘솔 작업 도중 막히면 ./deploy.sh를 다시 실행해 전체 자동화를 선택하면 나머지를 이어서 끝내 줍니다. 상세한 과정은 화면 단위로 정리된 가이드를 참조하세요: AWS Workshop 가이드

6. PoC 검증: 전화 해보기

전화를 걸기 전에, 콘솔의 Test chat(전화번호 발급 없이 채팅으로 테스트해 보는 기능)으로 먼저 확인해 보는 것을 권합니다. 음성 합성을 제외한 AI Agent의 판단과 툴 호출 흐름은 동일하기 때문에, AI Agent가 올바르게 동작하는지 테스트하기에 충분합니다.

이제 발급받은 번호로 전화를 걸어 실제 고객과 같이 전화합니다.

AnyCompany 상담원에게 고객이 “주문번호 ORD-100001 배송이 어디까지 왔는지 알려주세요”라고 말합니다. 이는 아래 경로를 따라 처리됩니다. 먼저 Amazon Connect Customer가 전화를 받고, 선택된 음성/STT provider가 고객 발화를 인식해 AI Agent가 처리할 수 있도록 전달합니다. AI 상담원이 track_shipment 툴(주문번호로 배송 상태를 조회)을 호출하기로 판단하면 AgentCore Gateway를 거쳐 Lambda가 실행됩니다. Lambda가 데이터베이스를 조회한 결과는 다시 선택된 TTS/voice provider를 통해 음성 답변으로 돌아옵니다.

이를 통해 비즈니스에 맞춘 AI 상담원 PoC가 실제로 동작하는 것을 확인할 수 있습니다. 통화를 마친 뒤에는 Amazon Connect Customer의 모니터링을 통해 AI가 어떤 툴을 어떤 값으로 호출했는지와 그 응답을 그대로 확인할 수 있습니다.

7. 마치며

AICC Builder를 써서 PoC를 만들면 달라지는 지점들은 다음과 같습니다.

구분	직접 손으로 할 때	AICC Builder 적용 후
시작	무엇부터 해야 할지 몰라 멈춤	채팅창에 비즈니스를 설명하면 시작
결과물	데모 수준이거나 미완성	내 비즈니스 규칙이 담긴, 배포 가능한 한 벌
일관성	파일끼리 이름이 어긋나기 쉬움	6종 에셋이 자동으로 맞아떨어짐
검증	도입을 결정하고 나서야 가능	전화 한 통으로 반나절 만에 확인
다음 단계	처음부터 다시 설계	생성된 코드를 그대로 확장

생성된 CDK 프로젝트는 개발팀이 이어받아 확장하는 시작 코드(starter kit)로 쓸 수 있습니다.

여기서 Kiro나 Claude Code 같은 범용 코딩 에이전트로도 같은 걸 할 수 있지 않을까 하는 의문이 들 수 있습니다. 그것도 맞습니다. AICC Builder는 기본적으로 웹앱입니다. 이 웹앱은 여섯 에셋이 생성되는 과정을 실시간으로 보여주고, Contact Flow 등을 가장 직관적으로 볼 수 있는 UI 등으로 시각화해 주기 때문에 코딩을 못해도 지금 무엇이 만들어지고 있는지 한눈에 따라갈 수 있다는 장점이 있습니다.

하지만 그럼에도 AICC Builder는 동일 Repo 내 Claude Skill과 Kiro Skill로도 패키징되어 있어, 이미 쓰고 있는 코딩 에이전트 안에서도 그대로 불러 쓸 수 있습니다. 대화형으로 처음부터 끝까지 진행 과정을 보고 싶다면 웹앱을, 이미 쓰는 에이전트 환경에 바로 통합하고 싶다면 Skill을 고르면 됩니다.

이 구조가 어떻게 짜였는지, 특히 AI가 만든 결과물을 믿지 않아도 되도록 시스템을 어떻게 설계했는지는 다음 편에서 세 가지 축으로 이어 다루겠습니다.

직접 써보고 싶다면 GitHub 저장소와 AWS Workshop 가이드를 참고해 주세요.

AWS 기술 블로그