Amazon Connect 인스턴스 생성 및 전화번호 연동

IT system

1. Amazon Connect 인스턴스 개설: AWS 콘솔에서 Amazon Connect 서비스를 찾아 새 인스턴스를 생성합니다. 인스턴스 이름, 관리자 계정 등을 설정하고 생성합니다. 인스턴스 생성 후 Access URL(접속 URL)을 확인할 수 있습니다.

2. 전화번호 연결: 인스턴스가 만들어지면 인스턴스 페이지의 전화번호(Phone numbers) 메뉴에서 번호를 연결합니다. Amazon Connect에서 지원하는 지역이라면 콘솔을 통해 시내전화(DID)나 080 등의 무료전화 번호를 Claim(구입)할 수 있습니다​

. 예를 들어 미국 등에서는 콘솔에서 즉시 지역번호나 toll-free 번호를 확보할 수 있습니다.

2. 만약 Amazon Connect에서 한국(02 등 지역번호)를 직접 제공하지 않는 경우, 기존 번호 포워딩 또는 가져오기를 고려해야 합니다. 예를 들어 현재 보유한 02-xxx-xxxx 번호로 걸려오는 전화를 Amazon Connect에서 구입한 다른 번호로 착신 전환(Forward)하는 방식으로 시험 운영하고, 완전히 이전할 준비가 되면 Amazon Connect 번호 포팅(porting) 절차를 통해 기존 번호를 이전할 수 있습니다​

. 이 접근법은 기존 시스템에서 Amazon Connect로 순차적으로 이전할 때 유용합니다.

2. 또는 SIP 트렁크 연동과 같은 BYOC(Bring Your Own Carrier) 방안을 사용할 수 있습니다. AWS 파트너사의 Amazon Connect SIP 게이트웨이를 활용하면, 자체 VoIP사업자/통신사의 회선과 Amazon Connect를 SIP로 연결하여 Amazon Connect에서 지원하지 않는 지역의 번호도 인입 전화로 활용할 수 있습니다​

avoxi.com

. 예를 들어 Comstice, AVOXI 등의 검증된 SIP 트렁킹 파트너를 이용하면 Amazon Connect와 직접 SIP 연결을 구축하여 로컬 번호를 사용할 수 있습니다​

avoxi.com

. 이 과정에서는 Amazon Connect 인스턴스의 Telephony 설정에서 SIP 트렁크를 허용하고, 파트너 가이드에 따라 방화벽 및 SIP 정보를 구성합니다.

3. 인바운드 콜 흐름 초기 설정: Amazon Connect 인스턴스를 열고 Contact flows(연락 흐름) 메뉴로 이동합니다. 기본적으로 제공되는 Sample inbound flow(샘플 인바운드 흐름)를 편집하거나 새로운 흐름을 생성합니다. 여기서 이후 단계에서 만들 Lex 연동, 콜백 처리 등의 로직을 Flow로 설계할 것입니다. 일단 인사 메시지나 대기 음악 등 기본 요소를 배치해 두고, 세부 구성은 Lex 봇 생성 후 진행합니다.

callbot

2. FAQ 데이터 준비 및 Amazon Lex 챗봇 구축

1. FAQ 데이터 정리: 우선 인천문화재단에서 제공할 FAQ 자료(구글 시트 또는 Excel)를 검토하여 질문과 답변 쌍을 명확히 구분합니다. 각 질문 패턴과 그에 대한 모범 답변을 준비해 두십시오. 필요하면 동일한 질문에 대한 여러 표현(말투)을 정리해두면 챗봇 인식률을 높이는 데 도움이 됩니다.

2. Amazon Lex 봇 생성: AWS 콘솔에서 Amazon Lex를 열어 새 Lex V2 봇을 생성합니다. 언어(locale)는 한국어(ko-KR)를 선택할 수 있습니다 (Amazon Lex는 한국어 음성 인식을 지원함). 봇 이름을 정하고 필요한 경우 한국어 음성 합성 설정도 선택합니다.

3. FAQ 인텐트 구성: Lex 봇 안에 FAQ 질문별로 인텐트(Intent)를 생성합니다. 각 인텐트는 하나의 질문 주제를 나타내며 다음과 같이 구성합니다:

   • 인텐트 이름: 질문 주제에 맞게 지정 (예: “BusinessHoursIntent”, “LocationIntent” 등).

   • 샘플 발화(Utterances): 사용자가 그 질문을 할 때 말할 법한 문장을 여러 형태로 추가합니다. 예를 들어 “운영 시간은 언제인가요?”, “몇 시까지 운영해요?” 등의 변형을 등록합니다.

   • 응답 구성: 인텐트의 응답(Message) 또는 Lambda Fulfillment를 통해 준비한 답변을 설정합니다. 단순 FAQ 응답의 경우 인텐트의 응답 메시지로 미리 준비한 답변 내용을 입력하면 Lex가 해당 답변을 호출자에게 TTS로 읽어줄 수 있습니다.

   • (선택 사항) Lambda 함수 연동: FAQ 데이터가 매우 많거나, 시트 데이터베이스를 실시간 조회하도록 하려면 인텐트 Fulfillment 단계에 AWS Lambda 함수를 연결할 수 있습니다. 호출자의 질문을 Lambda로 전달하여 외부 지식베이스에서 답변을 찾아오는 구조입니다​

. 이 방법을 사용하면 모든 질문을 인텐트로 만들지 않아도 되지만, Lambda 스크립트를 개발해야 합니다. (예: Lambda에서 S3에 업로드된 Excel을 조회하거나, Amazon DynamoDB에 저장된 FAQ 자료를 검색하여 답변 반환). 개발 역량이 없는 경우에는 Lambda 없이 정적 응답 방식으로 설정하는 것을 권장합니다.

4. Fallback 인텐트 설정: Lex V2 봇에는 기본적으로 AMAZON.FallbackIntent라는 사전 정의된 폴백 인텐트가 있습니다. 이 인텐트는 사용자의 발화가 어떤 기존 인텐트와도 정확히 맞지 않을 때 매칭됩니다​

. FallbackIntent를 활성화하고, 응답 메시지에 “죄송합니다, 질문 내용을 이해하지 못했습니다.” 등의 문구를 넣어두세요. 다만 Amazon Connect와 연동된 시나리오에서는 이 FallbackIntent에서 바로 전화를 끊지 않고 다음 단계(콜백 요청 수집)로 흐름이 진행되도록 할 예정입니다. 필요하면 FallbackIntent의 Fulfillment로 Lambda 함수를 연결해 질문을 다른 시스템에 로깅하거나, 추가 처리를 할 수도 있습니다​

. 예를 들어 AWS 아키텍처 블로그에서는 Fallback 인텐트가 호출되면 Lambda로 외부 지식 그래프를 질의하여 답을 찾는 예시를 보여줍니다​

. 우리 시나리오에서는 Fallback을 사용해 “콜백 절차로 이동”하도록 흐름 제어만 할 것입니다.

5. 봇 빌드 및 테스트: 모든 FAQ 인텐트와 응답 구성이 끝났으면 Lex 콘솔에서 Build(빌드) 버튼을 눌러 봇을 빌드합니다. 빌드 후 Test(테스트) 창을 열어 샘플 질문 발화를 입력하거나 말로 해보면서 각 질문에 대해 올바른 답변이 나오는지 확인합니다. 한국어의 경우 발음이나 어휘에 따라 인식률을 시험해보고, 인식이 어려운 표현은 Utterance에 추가합니다.

6. 버전 및 alias 발행: 테스트가 완료되면 Lex 봇을 배포할 준비를 합니다. Lex V2에서는 봇을 사용하려면 버전(Version)을 생성하고 별칭(Alias)을 만들어야 합니다. Lex 콘솔의 Bot versions에서 버전 1을 생성하고​

, Aliases에서 예를 들어 “prod” 혹은 “test” 등의 이름으로 별칭을 만든 뒤 해당 별칭에 방금 만든 버전을 연결합니다​

. (별칭은 프로덕션에서 봇 버전을 교체할 때 유용하며, Amazon Connect에는 별칭 단위로 Lex 봇을 연동합니다.)

chat

3. Amazon Connect 연락 흐름에 Lex 챗봇 연동

1. Lex 봇 인스턴스 연동: Amazon Connect 콘솔에서 Routing(라우팅) - Contact flows(연락 흐름)로 이동합니다. 좌측 하단에 Amazon Lex 섹션이 있는지 확인합니다. (만약 안 보이면 Amazon Connect 인스턴스 생성 시에 Lex와의 IAM 연동 권한이 없을 수 있으므로, Connect 인스턴스의 Overview 페이지에서 Allow Lex 관련 설정을 확인해야 합니다​

1. Lex 섹션에서 봇을 추가하려면, Region 드롭다운에서 Lex 봇이 있는 리전을 선택하고, Lex Bot 드롭다운에서 앞서 만든 봇 이름을 선택합니다. 그리고 Alias 드롭다운에서 방금 생성한 별칭(예: “prod”)을 선택한 뒤 + Add Lex bot 버튼을 클릭합니다​

. 추가된 봇은 목록에 표시됩니다. (Amazon Connect 인스턴스에 Lex 봇을 추가하면, Connect가 해당 Lex 봇을 호출할 수 있도록 필요한 리소스 정책이 설정됩니다​

2. Contact Flow 편집: 이제 실제 전화 응대 흐름을 만들 차례입니다. Contact flows에서 인바운드 흐름(예: Sample inbound flow)을 열거나 새 Inbound 흐름을 생성합니다. 흐름 편집기에서 다음과 같이 블록을 구성합니다:

   • 고객 입력 받기(Get customer input) 블록: 이 블록을 사용하여 고객의 음성 입력을 받아 Lex 봇으로 전달합니다​

. 편집기 오른쪽의 블록 목록에서 Interact 섹션 안의 Get customer input 블록을 끌어와 Entry point에 연결합니다​

. 이 블록을 클릭하여 속성(Properties)을 설정합니다. 우선 프롬프트(고객에게 들려줄 안내)로 텍스트 또는 사운드를 지정합니다. 예를 들어 TTS(Text-to-Speech)로 “안녕하세요, 인천문화재단입니다. 궁금한 사항을 말씀해주세요.” 라고 입력할 수 있습니다.

2. Get customer input 블록의 고객 응답 처리 부분에서 Amazon Lex 탭을 선택합니다​

. 여기서 Name 드롭다운에 앞서 Connect에 연동한 Lex 봇 이름을 선택하고, Alias에 해당 봇의 별칭을 지정합니다. 이렇게 하면 이 블록에서 고객의 음성 입력을 받아 지정된 Lex 챗봇으로 전달하게 됩니다.

2. 오디오 입력 설정: 동일한 Get customer input 블록에서 무응답 타임아웃, 최대 음성 길이 등을 조정할 수 있지만 기본값으로 충분합니다. (예: 최대 발화 시간 12초, 무응답 시 재시도 등​

2. 분기 구성: Get customer input 블록은 기본적으로 Success(성공) 분기와 Error(오류) 분기를 가집니다. Lex 봇이 어떤 인텐트(Intent)를 성공적으로 매칭하면 Success로 흐르고, 입력이 없거나 오류/예외 상황이면 Error로 흐릅니다​

. Lex에서 FallbackIntent로 끝난 경우도 사용자의 질문이 봇에서 답변을 찾지 못했다는 의미이므로, 이 경우 Contact Flow 상에서 특별한 오류로 처리하거나 재시도하게 할 수 있습니다. (Fallback도 일종의 성공 응답으로 간주되지만, 별도로 IntentName을 확인하는 방법이 있습니다.) 편의상, FAQ 매칭이 되면 Success로, 안 되면 Error로 간주하여 흐름을 나누겠습니다.

2. Success 분기: 고객 질문이 FAQ에 매칭되어 Lex가 답변을 제공한 경우입니다. 이때 Lex 봇이 이미 TTS로 답변을 말했으므로 별도의 안내가 필요 없을 수 있습니다. 원한다면 Play prompt(안내 음성) 블록을 Success에 연결하여 “더 필요한 사항이 있으시면 말씀해주세요.” 등의 추가 안내를 할 수 있고, 다시 Get customer input으로 연결하여 여러 질문을 연속 처리하게 만들 수도 있습니다. 또는 한번 답변 후 통화를 끝낼 것이라면 Success 분기에서 바로 Disconnect(연결 종료) 블록으로 통화를 종료합니다.

3. Error 분기: Lex가 답변을 찾지 못한 경우 또는 입력 오류가 발생한 경우입니다. Error 분기에서는 다음 단계로 콜백 요청을 자동으로 수집하는 흐름을 구성합니다 (다음 단계 참조).

4. 저장 및 테스트: 흐름 편집을 완료하면 상단 Save로 저장하고 Publish(게시)를 눌러 활성화합니다. 그런 다음, Amazon Connect 인스턴스의 전화번호로 전화를 걸어 방금 만든 흐름이 작동하는지 시험합니다. FAQ에 있는 질문을 하면 Lex 봇의 답변이 들리는지 확인합니다.

   
   

   

   
   

4. FAQ에 없는 질문 처리 – 콜백 요청 정보 수집

1. 콜백 흐름 진입: FAQ에 없는 질문을 받은 경우 (즉, Lex 봇에서 인텐트 매칭 실패/Fallback 발생 시)에는 Error 분기로 연결된 흐름을 따라 콜백 정보를 수집합니다. Error 분기에 Play prompt 블록을 연결하여 안내 멘트를 제공합니다. 예: “죄송합니다. 해당 질문에 대한 답변을 찾지 못했습니다. 연락처를 남겨주시면 확인 후 안내드리겠습니다.” 라고 TTS로 설정합니다.

2. 전화번호 수집: 안내 후에는 고객의 전화번호를 받습니다. 두 가지 방식이 있습니다:

   • DTMF 입력: 사용자가 키패드로 번호를 누르도록 유도합니다 (예: “전화번호를 남겨주시려면 번호를 눌러주세요”). 그런 다음 새로운 Get customer input 블록을 추가하여, 이번에는 DTMF 입력만 수신하게 구성합니다 (이 블록의 Prompt는 “전화번호를 입력한 뒤 우물 정자를 눌러주세요” 등으로 안내). DTMF 설정에서 입력 자리수 제한(예: 11자리 휴대전화번호) 및 종료 키(우물정자 #) 등을 지정합니다. 이렇게 하면 고객이 누른 번호가 해당 블록의 Stored customer input으로 저장됩니다.

   • 음성 입력: 고객이 말을 해서 전화번호를 불러주도록 할 수도 있습니다. 이 경우 Amazon Lex의 슬롯 타입 등을 활용해야 하므로 약간 복잡합니다. 간단한 구현을 원하면 DTMF를 사용하는 것이 정확합니다. (음성인식으로 전화번호를 받으려면 새로운 Lex 인텐트를 만들어 전화번호 슬롯을 받고, 해당 인텐트를 Amazon Connect 흐름에 또 하나 연결해야 합니다. 그러나 숫자를 음성으로 받을 때 인식 오류가 생길 수 있으니 DTMF 권장.)

   • 번호를 받는 블록이 완료되면, Set contact attributes 블록을 이용하여 받은 번호를 사용자 정의 속성에 저장합니다. 예를 들어 User input (고객 입력) 값인 Stored customer input을 불러와 Attribute 이름 “CallbackNumber”에 저장합니다. 이렇게 하면 이후 흐름에서 이 번호를 사용하거나 기록할 수 있습니다.

3. 요청 내용 수집: 다음으로, 어떤 문의였는지 요청 내용을 받아둡니다. 이 역시 음성으로 받아 텍스트 변환을 하거나, 간단히 카테고리만 선택하게 할 수 있습니다. 구현 난이도를 낮추기 위해 몇 가지 옵션을 안내합니다:

   • 카테고리 선택: FAQ에 없던 문의를 몇 가지 범주로 나눌 수 있다면 (예: 정책 문의, 행사 문의, 기타 등), 메뉴 형식으로 제공해 입력을 받습니다. Amazon Connect에서 Menu를 만들려면 다시 Get customer input 블록을 사용하여 “1번 정책 문의, 2번 행사 문의, 3번 기타 문의” 식으로 안내하고 DTMF 입력을 받습니다. 입력값 1/2/3에 따라 서로 다른 속성 (예: InquiryType=“Policy”)을 저장해 둘 수 있습니다.

   • 음성 메모 받기: 고객이 구체적인 문의 내용을 말하도록 유도할 수도 있습니다. Amazon Connect에서는 통화 녹음 기능이 있지만, 녹음 파일을 바로 텍스트로 변환해 주지는 않습니다. 따라서 음성->텍스트 변환을 하려면 Amazon Lex로 짧은 발화를 받아 문자열 슬롯에 저장하는 방법이 있습니다. 예를 들어 “문의 내용을 짧게 말씀해주세요”라고 안내한 뒤, 새로운 Lex 봇 인텐트 (예: “CaptureInquiryIntent”)를 만들어 {Inquiry}라는 슬롯 하나에 사용자가 말한 어떤 내용이든 담도록 설정합니다 (샘플 발화로 “{Inquiry}” 등). 그리고 이 인텐트를 Connect의 Get customer input 블록으로 받아오면, 사용자가 말한 문장을 Lex가 텍스트로 캡쳐하여 슬롯값으로 얻을 수 있습니다. 이 문자열을 Lambda 없이 Connect 내에서 바로 쓰긴 어렵지만, contact attribute로 저장해 둘 수는 있습니다.

   • 간단한 방법: 만약 위 방식이 어렵다면, 상담원 연결로 대체할 수도 있습니다. 즉, 답을 찾지 못한 경우 바로 “상담원에게 연결해드리겠습니다”로 안내한 뒤 대기열에 넣고 실제 직원이 받게 하는 것입니다. 그러나 요청은 콜백으로 받는 게 요구사항이므로, 최소한 문의의 요지라도 남기도록 음성 입력을 받아두는 편이 좋습니다.

   • 수집한 문의 내용 또는 선택한 카테고리도 Set contact attributes 블록을 통해 예를 들어 “CallbackRequest”라는 속성에 저장합니다.

4. 콜백 요청 기록: 이제 고객의 연락처와 문의 내용을 확보했으므로 이를 자동으로 저장해야 합니다. 개발자가 직접 구현한다면 AWS Lambda로 해당 정보를 DynamoDB나 S3에 기록할 수 있지만, 비개발자 친화적인 방법으로 Amazon Connect의 Tasks 기능을 활용할 수 있습니다. Amazon Connect Tasks를 사용하면 통화 흐름 중에 Create task 블록으로 후속 작업을 생성할 수 있습니다​

development

.

4. Create task 블록 추가: 문의 내용을 받은 후 Create task 블록을 추가합니다. 이 블록의 속성에서 Title(제목), Description(설명) 등을 입력할 수 있습니다. 예: 제목을 “FAQ 콜백 요청” 등으로 하고, 설명에 “${CallerId} 에서 문의: ${Attributes.CallbackRequest}” 등의 정보를 넣어둡니다 (콜러ID나 저장한 속성을 불러와 삽입 가능합니다).

5. 연락처 및 시간 지정: Create task 블록에 CallbackNumber (전화번호 속성)를 고객 연락처(Customer contact info)로 지정하면, 나중에 상담원이 해당 Task를 보고 바로 전화를 걸 수 있습니다. 또한 Schedule 옵션을 사용해 특정 시간 이후로 Task를 생성하도록 예약할 수도 있습니다 (예: “응답 가능 시간” 정보를 받았다면, 해당 시간에 맞춰 작업 생성)​

. 기본값으로 즉시생성을 해두면 Task가 바로 생겨 상담원이 바로 전화를 걸 수도 있습니다.

4. Task 할당: Task를 받을 대상을 정해야 합니다. Create task 블록에서 명시적 라우팅으로 특정 Queue(대기열)나 Agent(상담원)에게 할당할 수 있습니다. 예를 들어 “CallbackQueue”라는 별도 대기열을 만들어두고, 이 대기열을 Create task 블록에서 지정하면, 해당 콜백 요청 Task가 큐에 쌓입니다. 상담원이 Amazon Connect의 CCP(컨택트 컨트롤 패널)에서 이 Task를 받아 처리를 시작할 수 있습니다.

5. 태스크 생성 확인: Create task 블록이 성공하면 Success 분기로 흐릅니다. 여기서 Play prompt 등을 통해 “요청이 접수되었습니다. 곧 연락드리겠습니다, 감사합니다.” 등 멘트를 전달한 뒤 Disconnect로 전화를 종료합니다. (만약 Task 생성에 실패하면 Error 분기로 갈 텐데, 권한 문제일 수 있으므로 Connect 인스턴스의 서비스 역할에 connect:StartTaskContact 권한이 있는지 확인해야 합니다​

4. 이렇게 하면 통화가 끝난 뒤 Amazon Connect의 Tasks 대시보드나 Contact search에서 해당 콜백 요청 내용이 남습니다. 혹은 대기열에 할당했으므로 실시간 대기열 모니터링에서 Task가 건 수로 잡히게 됩니다.

5. 참고: Task를 쓰지 않고 Lambda로 외부 DB 저장을 원한다면, Invoke AWS Lambda 블록을 사용하여 Lambda 함수를 호출, 입력 파라미터로 콜백 정보를 보내고 함수 내에서 DB 저장을 수행할 수 있습니다. 하지만 이 방식은 코딩이 필요하므로 Tasks 사용을 권장합니다. Contact Flow 상의 Task 생성은 코드 없이도 문의 리스트를 체계화하는 편리한 방법입니다​

.

5. 콜백 흐름 테스트: 이제 전체 흐름을 테스트합니다. FAQ에 없는 질문으로 전화를 걸어보면, 봇이 답을 못 찾고 사과멘트 → 전화번호 수집 → 문의 내용 수집 → 종료로 진행될 것입니다. 통화 후 Amazon Connect 관리 화면에서 Tasks나 Contact records를 조회하여 방금 남긴 콜백 요청이 제대로 기록되었는지 확인합니다. 기록에는 통화한 고객의 번호와 문의 내용(속성으로 저장한 값) 등이 포함되어 있을 것입니다.

   
   

   

   CloudWatch

   
   

5. 대시보드 및 모니터링 설정

1. CloudWatch 로그 활성화: 콜센터 성능과 챗봇 상호작용을 추적하려면 로그와 지표를 수집해야 합니다. Amazon Connect 인스턴스 설정에서 Contact Flow Logs를 활성화하여 CloudWatch로 흐름 로그를 전송합니다. 이렇게 하면 각 통화에 대해 어떤 블록을 탔는지, 오류는 없었는지 등이 CloudWatch Logs에 기록됩니다. 또한 Amazon Connect는 통화/큐/태스크에 대한 메트릭을 1분 간격으로 CloudWatch에 자동 전송합니다​

1. Lex 대화 로그: Amazon Lex V2의 conversation logs(대화 로그) 기능을 사용하여, 봇이 인식한 발화와 인텐트 결과를 CloudWatch Logs나 S3에 저장할 수 있습니다. Lex 콘솔에서 해당 봇의 Logging 설정으로 가서 Text 로그를 활성화하고 로그 그룹이나 S3 버킷을 지정합니다​

. 이를 통해 어떤 질문이 들어왔고 (사용자 발화), Lex가 어떤 인텐트로 처리했는지 또는 Fallback됐는지, confidence score는 얼마였는지 등을 남길 수 있습니다.

1. 실시간 모니터링: Amazon Connect 콘솔의 Real-time metrics(실시간 메트릭)에서도 현재 대기중인 Task 수, 진행중인 콜 수 등을 모니터링할 수 있습니다. CloudWatch에 쌓인 Connect 지표를 이용하면 직접 커스텀 대시보드를 구성할 수도 있습니다​

.

2. 기본 지표 확인: 요구 사항에 언급된 콜 카운트, 응답 성공률, FAQ 매칭률 등을 계산하는 방법은 다음과 같습니다:

   • 콜 카운트: 일정 기간 동안 접수된 총 인입 콜 수를 나타냅니다. Amazon Connect의 CloudWatch 메트릭스 중 ContactCount 등을 통해 인입 연락 건수를 가져올 수 있습니다. 또는 Connect CTR(Contact Trace Record) 로그를 사용하면 세부 내역까지 확인 가능합니다. (CTR은 각 통화의 상세 기록으로, Connect 설정에서 Kinesis 스트림을 통해 S3로 내보낼 수 있습니다.)

   • 응답 성공률: 이는 봇이 전화를 받아 성공적으로 FAQ 답변을 제공한 비율로 정의합니다. 전체 콜 중에서 FAQ 답변으로 해결된 콜의 비율을 계산하려면, Fallback 없이 종료된 콜 vs Fallback 발생한 콜 수치를 알아야 합니다. Lex의 대화 로그를 분석하면 FallbackIntent 발생 횟수를 알 수 있고, Connect 흐름 로그로도 어느 분기로 통화가 흘렀는지 추적할 수 있습니다. 예를 들어 CloudWatch Logs Insights로 Connect 로그를 검색하여 Task 생성 블록이 실행된 건수를 센다면, 그것이 곧 FAQ로 답을 못 찾아 콜백이 필요한 케이스 수가 될 것입니다. 성공률 = (전체 콜 수 - 콜백된 콜 수) / 전체 콜 수 * 100%로 계산합니다.

   • FAQ 매칭률: 이것도 사실 성공률과 유사하게, 봇이 사용자의 질문을 FAQ 인텐트로 정확히 매칭한 비율입니다. Lex의 오류율 지표나 fallback intent 카운트를 확인하면 도움이 됩니다. Amazon Lex는 각 인텐트별 성공 횟수, 실패 횟수 등의 지표를 CloudWatch에 제공합니다. FallbackIntent 발생을 모니터링하여 FAQ 매칭률을 파악하세요. (예: 100건 중 95건은 FAQ 인텐트 매칭, 5건 Fallback → 매칭률 95%).

   • 이러한 값들은 CloudWatch 대시보드로도 볼 수 있지만, 보다 시각화된 리포트는 QuickSight로 구성하는 것이 좋습니다.

3. Amazon QuickSight 대시보드: QuickSight를 활용하여 경영진이나 비개발자도 보기 쉬운 대시보드를 만듭니다. 이를 위해 먼저 데이터 준비가 필요합니다.

   • CTR 및 로그 데이터 수집: Amazon Connect CTR 데이터를 S3로 내보내도록 설정합니다 (Kinesis Firehose -> S3 경로 설정). 또한 Amazon Lex 대화 로그가 S3에 적재되도록 했다면 그 S3 경로도 준비합니다. 이렇게 쌓인 JSON/CSV 데이터를 Athena를 통해 쿼리할 수 있게 스키마를 생성합니다. 예를 들어, CTR 로그에서 통화별 ContactId, 연결 결과, Task 생성 여부(특정 블록 도달 여부는 ContactFlowLogs 참고) 등을 추출하고, Lex 로그에서 같은 ContactId (또는 대화 ID)별로 fallback 여부를 추출하여 조인할 수 있습니다.

   • QuickSight 데이터셋 생성: QuickSight에서 S3에 저장된 CTR/로그 데이터를 직접 가져오거나, Athena의 쿼리를 연동하여 데이터셋을 만듭니다. 예를 들어 “일별 콜 수”, “콜백 요청 수”, “FAQ 응답 성공률” 등의 쿼리를 미리 만들어 두고 이를 QuickSight에 연결합니다​

.

3. 시각화 만들기: QuickSight에서 데이터셋이 준비되면 새 분석(Analysis)을 생성하여 차트와 KPI를 만듭니다. 권장되는 시각화 예시는 다음과 같습니다:

   • 전체 콜 수 추이: 날짜별 인입 콜 수 (막대 또는 선 그래프).

   • FAQ 응답 성공률: 기간별 성공률을 백분율 게이지나 라인으로 표시.

   • 콜백 발생 건수: FAQ로 답변하지 못해 콜백으로 전환된 건수를 누적 막대 등으로 표시.

   • 주요 문의 유형: 어떤 FAQ 인텐트가 가장 많이 언급되었는지 (Lex 인텐트 이름별 호출 횟수 순위) – 이를 통해 어떤 질문이 자주 오는지 파악 가능.

   • 기타 품질 지표: 평균 통화 시간, 상담원 연결률 등 (필요에 따라).

4. 대시보드 공유: 완성된 Analysis를 대시보드로 게시하고 관계자에게 권한을 부여하면, AWS 콘솔에 로그인하지 않더라도 이메일 등을 통해 대시보드를 모니터링할 수 있습니다.

5. 참고로 AWS에서는 Connect 챗봇 성능을 분석하기 위한 예시로 CTR, Lex 로그, QuickSight를 연계하는 방법을 제시하고 있습니다​

. 해당 가이드에 따라 구현하면 보다 자세한 대시보드를 구축할 수도 있습니다. (해당 자료에서는 Athena로 대화 로그와 CTR을 조인해 QuickSight로 시각화하는 방법을 다룹니다.)

4. 모니터링 요약: CloudWatch를 통해 실시간에 가까운 모니터를 하고, QuickSight를 통해 역사적인 성과와 비율을 한눈에 보는 이중 체계를 갖춥니다. 또한 경보(Alarm) 설정을 통해 중요한 지표에 임계치 알람을 걸어둘 수도 있습니다. 예를 들어 Fallback 발생률이 일정 수준 이상이면 관리자가 확인하도록 CloudWatch에서 커스텀 지표를 만들어 알람을 설정할 수 있습니다. (CloudWatch Logs Insights로 Lex 로그를 분석하여 일정 주기별 fallback 건수를 산출 -> CloudWatch Metrics로 발행 등의 고급 설정 가능). 기본적인 것은 Amazon Connect 자체의 모니터링 화면과 QuickSight 대시보드로도 충분합니다.

6. 비용 모니터링 및 관리

1. AWS 비용 대시보드 확인: Amazon Connect를 포함한 AWS 서비스 사용 비용은 AWS Billing 콘솔에서 확인할 수 있습니다. 먼저 결제 알림(Billing Alert) 기능을 활성화합니다. Billing & Cost Management 콘솔의 Billing preferences에서 “Receive CloudWatch Billing Alerts” 옵션을 켜면 계정 비용이 CloudWatch 지표로 전달됩니다​

. 이렇게 하면 현재까지 누적된 월간 사용료를 나타내는 지표 (EstimatedCharges)를 CloudWatch에서 볼 수 있고, 이를 바탕으로 알람을 만들 수 있습니다​

.

2. 예산(Budget) 설정: AWS에서는 AWS Budgets 서비스를 통해 예산 한도를 정하고 알림을 받는 것을 권장합니다​

. Billing 콘솔의 Budgets에서 예산을 생성합니다. 예를 들어 이번 프로젝트를 위한 월간 예산을 100만 원으로 정하고, 50% 사용 시 알림, 80% 사용 시 알림 등을 이메일로 받도록 설정할 수 있습니다 (Budget 생성 시 알림 임계값을 설정)​

. 또한 비용 상승 이상징후를 포착하는 Cost Anomaly Detection도 활성화해두면 갑작스런 비용 폭증 시 알려주므로 안전장치가 됩니다​

.

3. Cost Explorer 활용: AWS Cost Explorer를 켜면 서비스별 비용 추이를 시각적으로 볼 수 있습니다. Cost Explorer를 통해 Amazon Connect, Lex, Lambda, S3 등 서비스별로 일/월별 비용을 확인하세요​

. 예를 들어 Amazon Connect의 비용은 통화 시간(분 단위 요금), 전화번호 월 사용료, 메시지 처리(스마트 컨택트 센터 기능) 등으로 구성됩니다. Amazon Lex는 호출 횟수/문자 수 기반으로 과금됩니다. Cost Explorer에서 Service별 필터를 걸어두면 어떤 부분에서 비용이 많이 발생하는지 한눈에 볼 수 있습니다.

4. 비용 최적화 및 관리: AWS 비용을 효율적으로 관리하려면 다음을 고려합니다:

   • 태깅(Tagging): 이번 프로젝트와 관련된 리소스(Amazon Connect 인스턴스, Lambda 함수 등)에 공통 태그를 지정하면 비용 분석 시 편리합니다. 예를 들어 Project=IncheonCulturalFAQ 같은 태그를 달아두면 Cost Explorer에서 해당 태그로 필터링하여 이 프로젝트와 연관된 비용만 모아서 볼 수 있습니다.

   • 리소스 관리: Amazon Connect는 사용한 만큼 비용이 부과되므로, 사용량에 따른 최적화 외에 추가적인 예약 인스턴스 개념은 없습니다. 다만 QuickSight는 표준 에디션의 경우 사용자/세션 당 과금되므로, 필요 이상의 사용자 계정을 만들지 않도록 합니다.

   • 월별 청구서 검토: 매달 AWS 청구서를 확인하고, 설정한 예산 대비 초과 요인이 있었는지 점검합니다. 예를 들어 통화량이 예상보다 많았다면 번호를 080번호(수신자 부담)로 전환할지, 또는 콜백 대신 FAQ 답변을 더 확충해 통화 시간을 줄일지 등의 조치를 검토할 수 있습니다.

   • AWS 비용 도구 활용: 비용 탐색, 예산 외에도 Cost and Usage Report(CUR)를 세부 분석에 활용하거나, Amazon QuickSight로 비용 데이터를 시각화하는 것도 가능합니다. (필요시 CUR을 설정하고 Athena 테이블로 분석). 그러나 기본적인 모니터링은 예산 알림과 Cost Explorer로도 충분합니다.

5. 사용자 비용 모니터링 교육: 인천문화재단 담당자가 직접 AWS 비용을 모니터링할 수 있도록 Billing 콘솔 접근 권한을 부여하고, Billing Dashboard 보는 방법을 안내합니다. 결제 대시보드에서는 이번 달 예산 대비 사용량 퍼센트, 서비스별 예산 사용률 등을 한눈에 볼 수 있습니다. 이를 통해 지속적으로 비용을 추적하면 예산 내 운영이 가능할 것입니다.

   AI 상담사는 단순한 문의를 빠르게 해결하고, 복잡한 상담은 상담사에게 연결하는 스마트한 금융 고객센터 솔루션입니다.

   📞 더 궁금하신가요? 지금 AI 상담사를 체험해보세요! 🚀

   
   

The good call-bot service company is (주)Binarity