대부분의 고객 지원을 위한 AI 이니셔티브는 동일한 방식으로 시작됩니다. 설득력 있는 데모, 약 70~80%로 약속된 디플렉션(Deflection) 비율, 그리고 가장 간단한 질문들에서 잘 작동하는 파일럿 프로젝트가 그것입니다. 6개월 후, 시스템은 여전히 가동 중이지만 실제 디플렉션은 25%에 머물러 있고, 지원 팀은 여전히 업무 과부하 상태이며, 아무도 왜 수치가 목표에 도달하지 못했는지 정확히 설명하지 못합니다.

이 포스트는 제대로 작동하는 시스템과 그렇지 않은 시스템을 가르는 차이점, 즉 올바른 아키텍처(Architecture), 실제 실패 모드, 그리고 시스템이 프로덕션(Production)에 투입된 이후에 기대할 수 있는 것들에 대해 다룹니다.

왜 대부분의 지원 챗봇이 실패하는가

지배적인 실패 모드는 AI가 지원 질문에 답하지 못하는 것이 아닙니다. 문제는 시스템이 쉬운 질문에 답하도록 구축되었다는 점이며, 이러한 질문들은 티켓(Ticket)의 볼륨을 유발하는 핵심 질문들이 아니라는 것입니다. 진정으로 비용이 많이 드는 티켓들은 모호하며, 여러 시스템에 대한 접근을 요구하고, 정책 예외 사항을 포함하거나, 고객에게 단순히 절차적인 대응이 아닌 정서적인 대응이 필요합니다.

단순한 20%를 디플렉션하고 복잡한 80%를 라우팅(Routing)하는 챗봇은 문제를 해결한 것이 아닙니다. 그것은 단지 인간 상담사 앞에 추가적인 레이어(Layer)를 하나 더 만든 것에 불과하며, 이는 가장 중요한 티켓들의 해결 시간을 증가시킵니다.

두 번째 실패 모드는 AI를 위한 준비가 되지 않은 지식 베이스(Knowledge Base) 위에 구축하는 것입니다. 사람이 읽도록 작성된 문서들은 검색(Retrieval)에 유용한 문서들과는 구조가 다릅니다. 만약 지식 베이스에 모순이 있거나, 정보가 오래되었거나, 엣지 케이스(Edge Case)에 대한 공백이 있다면, 시스템은 이러한 문제들을 확신을 가지고 매우 빠른 속도로 재현할 것입니다.

올바른 시작점: 티켓 분류

응답을 생성하는 무언가를 구축하기 전에, 먼저 유입되는 티켓을 유형, 긴급도 및 필요한 조치에 따라 분류하는 것을 구축하십시오. 이 단일 단계만으로 즉각적인 가치를 창출합니다. 수동 분류(manual triaging) 없이 티켓을 적절한 팀으로 라우팅(routing)하고, 이후에 구축할 모든 생성형 시스템을 평가하는 데 필요한 라벨링된 데이터 세트(labeled dataset)를 생성합니다.

분류는 실제 볼륨의 분포를 파악할 수 있는 지점이기도 합니다. 거의 모든 경우에 있어, 초기 분석을 해보면 어떤 티켓이 가장 흔한지에 대한 팀의 직관이 틀렸음이 드러납니다. 모두가 드물다고 생각하는 유형의 티켓이 보통 전체 볼륨의 30%를 차지하며, 지배적이라고 생각했던 유형들은 그보다 훨씬 적은 비중을 차지하곤 합니다.

분류 데이터를 확보하면, 어떤 티켓 카테고리에 완전 자동화(full automation) 투자가 가치가 있는지, 어떤 카테고리가 완전 자동화 없이 상담사 지원(agent assistance)을 통해 이득을 얻을 수 있는지, 그리고 어떤 카테고리가 AI를 거치지 않고 즉시 인간 전문가에게 전달되어야 하는지에 대해 근거 있는 결정을 내릴 수 있습니다.

검색 기반 응답 vs 생성 기반 응답

대부분의 지원 유스케이스(use case)의 경우, 가장 좋은 아키텍처(architecture)는 새로운 응답을 생성하는 대신 관련 도움말 문서나 정책 문서를 검색하여 고객에게 제시하는 것입니다. 검색(Retrieval)은 출력값이 귀하가 직접 작성하고 승인한 문서이기 때문에 더 안전합니다. 생성(Generation)은 질문이 여러 소스의 정보를 합성(synthesize)해야 할 때 적절합니다. 우리는 그 기반이 되는 아키텍처를 RAG에서 다룹니다.

실질적인 차이점은 다음과 같습니다: 만약 정답이 귀하의 지식 베이스(knowledge base) 어딘가에 이미 존재한다면, 시스템의 역할은 그것을 다시 쓰는 것이 아니라 찾아내어 전달하는 것입니다. 순수 생성(Pure generation)은 불필요한 리스크를 초래합니다. 모델이 귀하의 정책과 모순되는 내용을 합성하거나 존재하지 않는 세부 사항을 꾸며낼(fabricate) 수 있기 때문입니다.

생성 (Generation)은 고객이 계정의 특정 정보를 포함하는 개인화된 답변을 필요로할 때, 지식 베이스 (Knowledge Base)에 직접적인 답변이 없을 때, 또는 여러 문서가 일관된 방식으로 결합되어야 할 때 의미가 있습니다. 이러한 경우, 생성은 명시적인 제약 조건 내에서 이루어져야 하며 더욱 엄격하게 평가되어야 합니다.

핸드오프 (Handoff) 문제

모든 AI 지원 시스템은 결국 대화를 인간에게 전달하게 됩니다. 이 핸드오프 (Handoff)가 어떻게 작동하느냐에 따라 고객이 AI가 도움을 주었다고 느낄지, 아니면 방해를 받았다고 느낄지가 결정됩니다. 실패하는 방식은 문맥 (Context) 없이 대화를 전달하는 것입니다. 이 경우 상담원은 처음부터 다시 시작해야 하고, 고객은 같은 말을 반복해야 하며, 좌절감이 쌓이게 됩니다.

AI는 이미 확립된 내용, 시도된 조치, 그리고 왜 에스컬레이션 (Escalation)이 발생했는지에 대한 구조화된 요약을 전달해야 합니다. 이 요약은 자유 형식의 텍스트 (Free text)여서는 안 됩니다. 티켓 시스템 (Ticket system)이 캡처할 수 있는 채워진 필드 세트여야 합니다: 보고된 문제, 이미 실행된 단계, 에스컬레이션 사유, 최근 대화에서의 고객 어조 등입니다.

핸드오프가 잘 작동하면, 상담원은 정보를 숙지한 상태로 대화에 참여하여 고객에게 이미 말한 내용을 다시 묻지 않고도 문제를 해결할 수 있습니다. 이 단 하나의 구현 디테일은 에스컬레이션이 포함된 티켓의 CSAT (고객 만족도)에 불균형적일 만큼 큰 영향을 미칩니다.

6개월 후의 운영 모습

출시 초기에는 시스템이 가장 흔하고 잘 문서화된 유형의 질문들을 처리합니다. 처음 두 달 동안은 평가 피드백 루프 (Feedback loop)를 통해 지식 베이스의 공백, AI가 잘못된 답변을 확신을 가지고 내놓은 사례, 그리고 고객이 체계적으로 AI의 답변을 거부하고 상담원을 요청하는 티켓 유형 등을 파악합니다.

3개월에서 6개월 사이에는 팀이 이러한 공백들을 체계적으로 해결해 나갑니다. 검색 (Retrieval)에 더 잘 작동하도록 문서들이 재작성됩니다. 평가 과정에서 식별된 엣지 케이스 (Edge cases)들이 문서화됩니다. 시스템이 정답을 맞히는 경우와 틀리는 경우의 실제 데이터를 기반으로 신뢰도 임계값 (Confidence thresholds)이 조정됩니다.

6개월간의 운영 후 실질적인 디플렉션율 (Deflection rate)은 공급업체의 데모에서 보여주는 80%가 아니라, 유입량의 3050% 수준입니다. 이는 지식 베이스 (Knowledge base)가 업데이트되었고, 피드백 루프 (Feedback loop)가 작동하며, 지원 팀이 개선 프로세스에 참여하고 있다는 것을 전제로 합니다. 이 3050%만으로도 전체 인간 작업량에 미치는 영향은 상당할 수 있는데, 디플렉션된 티켓들은 대개 가장 단순하고 반복적인 것들이기 때문입니다.

중요한 지표들

디플렉션율은 AI가 인간의 개입 없이 얼마나 자주 티켓을 해결하는지를 측정합니다. 하지만 해결 방식이 올바르지 않다면 디플렉션은 가치가 없습니다. AI가 처리한 티켓의 CSAT (고객 만족도)를 인간이 처리한 티켓과 분리하여 별도로 추적하십시오. 두 지표 사이에 큰 차이가 있다면, 이는 시스템이 표면적인 티켓은 해결하고 있지만 고객을 불만족스럽게 만들고 있다는 가장 명확한 신호입니다.

에스컬레이션 (Escalation) 비율과 그 원인을 추적하십시오. 시스템은 각 에스컬레이션이 왜 발생했는지 기록해야 합니다: 낮은 신뢰도, 범위를 벗어난 질문, 고객의 명시적 요청, 또는 부정적인 어조 감지 등입니다. 이러한 데이터는 무작정 조정하는 대신 목표가 명확한 개선을 가능하게 합니다.

CSAT가 낮은 상태에서의 60% 디플렉션율은 해결하는 것보다 더 많은 문제를 일으키고 있는 것입니다. 목표는 디플렉션을 극대화하는 것이 아닙니다. 최소한의 인간 개입으로 고객이 만족할 수 있도록 티켓을 해결하는 것입니다.

지원 컨텍스트를 위한 가드레일 (Guardrails)

지원용 AI는 오류가 고객과의 관계를 직접적으로 손상시키는 컨텍스트에서 작동합니다. 따라서 가드레일 요구사항은 내부 도구용보다 훨씬 엄격해야 합니다. 시스템은 신뢰도가 낮은 질문에 대한 답변을 거부하고 에스컬레이션을 제안해야 합니다. 정책, 가격 또는 특정 계정 정보에 대한 세부 사항을 절대로 허위로 만들어내서는 안 됩니다.

이러한 제한 사항들은 추측하는 것이 아니라 명시적으로, 그리고 정기적으로 평가되어야 합니다. 출시 시점에 작동하던 가드레일(guardrail)이라도 지식 베이스(knowledge base)가 업데이트되거나 이례적인 질문 유형의 볼륨이 증가할 때 실패할 수 있습니다. 우리는 AI 가드레일 (AI guardrails)에서 이보다 더 넓은 주제를 다룹니다.

고객 지원에서 가장 중요한 가드레일은 정직한 에스컬레이션(escalação honesta)입니다. 시스템이 모를 때는 틀릴 수도 있는 그럴듯한 답변을 생성하는 대신, 모른다고 말하고 연결을 넘겨야 합니다. 고객들은 "확실하지 않으니 도움을 줄 수 있는 담당자에게 연결해 드리겠습니다"라는 말은 잘 받아들입니다. 하지만 확신에 찬 태도로 잘못된 정보를 제공하는 것은 용납하지 않습니다.

원문은 studiolabsai.com에 게시되었습니다. Studio Labs는 엔터프라이즈 팀을 위한 프로덕션용 AI를 구축합니다. 상담 예약하기.