고객 지원 AI 에이전트 설계: 지식 출처, 작업 권한, 상담원 연결
고객 지원 AI 에이전트에는 세 가지 역할이 있습니다. 회사 정보를 설명하고, 허용된 다음 단계를 고객이 진행하도록 돕고, 사람이 개입해야 할 순간을 판단하는 것입니다. 자연스러운 답변은 이 흐름의 일부일 뿐입니다.
제가 만든 Make Agent Fast는 이 문제를 중심으로 설계한 제품입니다. 회사 자료를 수집하고, 에이전트 초안을 검토하고, 지식을 승인하는 과정으로 설정을 시작합니다. 이후 같은 에이전트를 웹사이트 위젯과 연결된 메시징 채널에서 사용할 수 있습니다. 이 글에서는 그 설계 판단과 출시 전 평가 방법을 설명합니다.
먼저 역할의 범위를 좁히기
“회사에 관한 모든 질문에 답하기”는 테스트하기 어렵습니다. “서비스를 설명하고 직원의 답변이 필요한 문의를 접수하기”가 더 명확한 출발점입니다. 사업자는 공개할 정보, 사람이 담당할 질문, 에이전트가 수집할 항목을 정할 수 있습니다.
예약 도우미에서는 예약 요청과 예약 확정을 구분해야 합니다. 시스템이 가능 시간을 확인하고 예약을 완료할 수 없다면, 답변도 요청을 접수했다는 수준에 머물러야 합니다. 표현은 실제로 수행된 작업과 일치해야 합니다.
설정에는 고객의 목적, 답변에 사용할 출처, 실행 가능한 작업과 필수 입력 항목, 상담원 연결 조건을 기록하는 것이 좋습니다.
수집한 지식을 게시 전에 검토하기
웹사이트 크롤링은 자료 수집을 편리하게 하지만, 수집된 페이지가 곧 현재의 회사 정책은 아닙니다. 오래된 가격, 중복 페이지, 초안, 누락된 예외 조건이 지식 베이스에 들어갈 수 있습니다.
Make Agent Fast에서는 크롤링과 자료 수집 뒤에 게시 전 검토 과정을 둡니다. PostgreSQL과 pgvector를 이용해 답변에 관련된 자료를 검색합니다. 검색은 모델에 맥락을 제공하지만 오래된 출처를 정확하게 바꾸지는 않습니다.
중요한 자료마다 담당자, 대상 독자, 현재 정확성을 확인하세요. 두 출처의 환불 기한이 다르다면 모델이 환불 질문에 답하게 하기 전에 충돌을 해결해야 합니다.
설명과 실행을 분리하기
예약 방법을 설명하는 것과 예약을 생성하는 것은 결과가 다릅니다. 각각을 명시적인 권한을 가진 별도 기능으로 취급해야 합니다.
고객이 “내일 전화해 주실 수 있나요?”라고 요청한다면 이름, 연락 방법, 희망 시간, 담당자가 이해할 간단한 맥락이 필요할 수 있습니다. 채팅에서 묻기 쉽다는 이유만으로 관련 없는 개인정보를 수집해서는 안 됩니다.
담당자용 수신함도 제품의 일부입니다. 상담원에게 넘길 때 요청, 필요한 대화 맥락, 시도한 작업의 상태가 함께 전달되어야 합니다. 직원은 접수가 완료되었는지, 실패했는지, 확인이 더 필요한지 구분할 수 있어야 합니다.
채널이 달라도 같은 규칙 적용하기
웹사이트와 메시징 채널의 대화는 같은 승인 지식과 작업 범위를 사용해야 합니다. 그렇지 않으면 정책이 바뀐 뒤에도 한 채널만 과거 기준으로 답할 수 있습니다.
Make Agent Fast 사례에서는 위젯과 메시징 커넥터가 에이전트 식별자, 지식, 대화, 상담원 연결 모델을 공유하도록 설계했습니다. 채널마다 전달 방식은 달라져도 비즈니스 규칙은 일관되게 유지하는 방식입니다.
음성은 여기에 추가되는 인터페이스입니다. 동의, 끼어들기, 이름과 연락처 인식이 실제 음성 대화에서 어떻게 작동하는지 확인해야 합니다. 텍스트 기록만으로 음성 경험까지 검증할 수는 없습니다.
출시 전에 실패 상황 테스트하기
| 상황 | 확인할 결과 |
|---|---|
| 승인된 답이 있는 질문 | 출처와 조건을 그대로 반영한 답변을 제공하는가. |
| 지식 베이스에 없는 질문 | 모르는 범위를 설명하고 적절한 다음 단계를 제안하는가. |
| 서로 충돌하는 출처 | 충돌을 해결하거나 담당자에게 전달하는가. |
| 정보가 부족한 예약 요청 | 부족한 정보만 묻고 예약 확정을 꾸며내지 않는가. |
| 외부 작업 실패 | 정확한 상태와 복구 방법을 알려주는가. |
| 상담원 연결 요청 | 필요한 맥락과 함께 수신함에 도착하는가. |
| 정책 변경 | 연결된 모든 채널에서 수정된 자료를 사용하는가. |
실제 고객 인터페이스와 담당자 수신함을 함께 확인하세요. 모델이 정상적으로 답했다고 해서 요청이 담당자에게 전달되었다고 볼 수는 없습니다.
메시지 수보다 유용한 결과 측정하기
메시지 수만으로 지원 품질을 판단하기는 어렵습니다. 대화가 길다는 것은 관심이 높다는 뜻일 수도 있지만, 간단한 요청을 이해하지 못했다는 뜻일 수도 있습니다.
승인 자료에 맞는 답변, 필요한 정보가 갖춰진 문의, 성공적인 상담원 연결, 문서 보완이 필요한 미해결 질문부터 살펴보세요. 프롬프트를 바꾸기 전에 실제 대화를 검토해야 합니다. 문제의 원인이 자료나 작업 흐름에 있을 수도 있습니다.
구현된 제품과 기술 구성은 Make Agent Fast 사례에서 확인할 수 있습니다. 다른 프로젝트를 살펴보거나 AI 제품의 업무 흐름에 대해 문의해 주세요.
관련 프로젝트 사례
Make Agent Fast
승인된 비즈니스 지식을 웹사이트와 메시징 채널의 고객 에이전트로 전환하고, 근거 기반 답변, 음성, 구조화된 액션, 사람 연결까지 제공하는 플랫폼을 구축하고 출시했습니다.
- 웹사이트 위젯, Telegram, WhatsApp, Messenger, Instagram, Discord, KakaoTalk에서 하나의 에이전트 워크플로를 출시했습니다.
- 회사 URL 하나를 검토 가능한 에이전트 초안, 승인된 지식 베이스, 임베드 위젯, 운영자 통합 수신함으로 전환했습니다.
프로젝트 시작하기
제품에 이런 수준의 사고와 실행이 필요하신가요?
제품을 구체화하고 인터페이스, 시스템, 개선 주기까지 실제로 출시할 파트너가 필요하다면 연락해 주세요.
프로젝트 시작하기