WhatsApp에 봇을 도입하는 모든 고객 지원 팀은 결국 동일한 벽에 부딪힙니다. 봇은 쉬운 질문들은 잘 처리합니다. 그러다 고객이 답변할 수 없는 질문을 하거나, "상담원과 대화하고 싶어요"라고 입력하면 모든 것이 무너집니다. 봇은 무한 루프에 빠집니다. 고객이 이미 제공한 주문 번호를 다시 물어봅니다. 결국 상담원이 개입하지만, 상담원은 처음부터 다시 시작해야 하므로 고객은 모든 것을 두 번째 설명해야 합니다. 그때쯤이면 고객은 짜증이 나고 상담원도 짜증이 나며, 봇은 아예 없었을 때보다 상황을 더 악화시켜 놓은 상태가 됩니다.

실패의 원인은 거의 항상 봇의 답변 때문이 아닙니다. 바로 핸드오프 (Handoff) 때문입니다. 단일 비즈니스 번호 상에서 진행 중인 대화를 자동화에서 사람으로, 그리고 다시 자동화로 옮기는 것은 대부분의 기술 스택이 제대로 해결하지 못하는 설계 문제입니다. 이 글은 BowChat을 실제 사례로 사용하여 이 문제를 어떻게 제대로 해결할 수 있는지에 대해 다룹니다.

공개 사항: BowChat은 Boni 팀이 만든 저희 제품입니다. 현재 라이브 상태인 기능과 아직 파일럿 단계인 기능을 명확히 구분하여 설명하겠습니다.

잘못된 핸드오프의 실제 모습

"봇 루프"를 구성 요소별로 나누어 보면 해결책이 명확해집니다:

• 봇이 이미 두 번이나 실패한 질문에 대해 계속해서 답변하려고 시도합니다.
• 고객이 명시적으로 상담원을 요청했음에도 봇이 이를 무시하거나 옵션을 숨겨버립니다.
• 상담원이 업무를 인계받았지만 봇이 이미 수집한 정보를 볼 수 없어 다시 질문합니다.
• 두 명(또는 사람과 봇)이 동시에 답변하여 서로 모순되는 내용을 말합니다.
• 고객이 다른 전화번호나 "지원 포털 (support portal)"로 튕겨 나가 대화 흐름이 끊깁니다.
• 상담원이 문제를 해결한 후 아무도 제어권을 다시 넘겨주지 않아, 봇은 침묵 상태로 남거나 상담원이 종료된 티켓을 계속 붙들고 있게 됩니다.

좋은 핸드오프는 위 목록의 반대 상황입니다. 적절한 시점에 에스컬레이션 (Escalation)을 수행하고, 전체 이력과 읽기 쉬운 요약을 함께 전달하며, 적절한 담당자에게 연결되고, 동일한 번호를 유지하며, 상담원이 업무를 마쳤을 때 깔끔하게 자동화로 복귀합니다. 이제 하나씩 살펴보겠습니다.

언제 에스컬레이션해야 하는가

에스컬레이션 (Escalation)은 세 가지 독립적인 트리거 (trigger)에 의해 발생해야 하며, 그중 하나만 충족되어도 충분합니다.

명시적 요청 (Explicit request). 고객이 "사람과 대화하고 싶어요", "상담원", "실제 사람", 또는 "도움이 되지 않아요"와 유사한 내용을 입력하면 이는 즉각적인 중단 신호입니다. 봇은 한 번 더 영리한 답변을 시도하려 해서는 안 됩니다. 상황을 인지하고 경로를 지정해야 합니다. 이것은 가장 중요한 단일 규칙입니다. 왜냐하면 이 규칙을 무시하는 것이 사람들이 마주치는 모든 봇을 불신하게 만드는 원인이기 때문입니다.

낮은 신뢰도 (Low confidence). 자동화 계층이 요청을 이해했는지 확신할 수 없거나, 자신의 답변이 정확한지 확신할 수 없을 때는 추측하기보다 에스컬레이션해야 합니다. 실제로 이는 봇이 자신의 출력값에 대해 신뢰도 신호 (confidence signal)를 가지고 있으며, 특정 임계값 (threshold) 미만일 경우 대화를 중단하고 상담원을 호출해야 함을 의미합니다. 자신 있게 추측하는 것은 불확실성을 인정하는 것보다 더 나쁩니다.

반복된 실패 (Repeated failure). 이슈당 시도 횟수를 추적하십시오. 봇이 동일한 문제를 해결하려고 두세 번 시도했으나 실패했다면, 신뢰도와 상관없이 카운터 (counter)에 따라 에스컬레이션합니다. 같은 질문을 세 번이나 다시 표현한 고객은 이미 좌절한 상태입니다. 고객이 직접 탈출구를 찾게 만들지 마십시오.

이 세 가지를 관통하는 설계 원칙은 다음과 같습니다: 봇의 역할은 모든 것에 답하는 것이 아닙니다. 할 수 있는 것에 답하고 자신의 한계를 조기에 인식하는 것입니다. 적절한 순간에 깔끔하게 핸드오프 (hand off)하는 봇이, 계속해서 밀어붙이다가 결국 실패하는 봇보다 더 똑똑하게 느껴집니다.

문맥을 유지하며 전달하기

이 단계는 모든 사람이 과소평가하는 부분입니다. 에스컬레이션 자체는 쉽습니다. 하지만 문맥 (context)과 함께 에스컬레이션하는 것이 핵심입니다.

대화가 사람에게 넘어갈 때, 두 가지 요소가 반드시 함께 전달되어야 합니다.

첫 번째는 **전체 이력 (full history)**입니다. 양방향의 모든 메시지가 순서대로 포함되어야 합니다. WhatsApp의 경우, 봇과 사람이 별개의 시스템에 머무는 대신 동일한 대화 스레드 (conversation thread)를 공유하기 때문에 자연스럽게 이 조건이 충족됩니다. BowChat에서는 대화가 공유 편지함 (shared inbox) 내의 하나의 연속된 스레드로 존재합니다. 대화를 넘겨받은 상담원은 화면을 위로 스크롤하여 고객이 무엇을 말했고 자동화 시스템이 어떻게 응답했는지 정확히 확인할 수 있습니다. 별도의 봇 로그 (bot log)에 숨겨진 내용은 아무것도 없습니다.

두 번째는 **구조화된 요약 (structured summary)**입니다. 전체 이력이 필요하긴 하지만 그것만으로는 충분하지 않습니다. 시간 압박을 받는 상담사가 40개의 메시지를 모두 읽고 싶어 하지는 않기 때문입니다. 핸드오프 (handoff) 시에는 짧고 구조화된 메모가 포함되어야 합니다. 즉, 고객이 원하는 것, 시도된 조치, 여전히 알 수 없는 내용, 그리고 왜 에스컬레이션 (escalation) 되었는지를 포함해야 합니다. BowChat에서는 이것이 현재 활성화되어 있는 내부 메모 (internal notes)로 매핑됩니다. 메모는 팀원들에게는 보이지만 고객에게는 절대 보이지 않으므로, 봇(또는 에스컬레이션 로직)이 대화에 비공개 요약을 남기면 수신 상담사가 몇 초 만에 이를 읽을 수 있습니다. 깊이를 위한 이력, 속도를 위한 메모입니다.

다음은 에스컬레이션 메모가 포함할 수 있는 예시적인 형태입니다. 이는 예시일 뿐이며, API 규약이 아닌 사고 모델 (mental model)로 취급하시고, 정확한 동작은 실제 제품 문서를 확인하십시오:

예시 에스컬레이션 메모 (실제 페이로드 아님):
- 의도 (Intent): 기존 예약 일정 변경
- 수집된 정보 (Collected): 예약 참조 번호, 선호하는 새로운 날짜
...

핵심은 상담사가 이미 상황을 파악한 상태에서 대화를 시작한다는 점입니다. 상담사는 예약 참조 번호를 다시 묻지 않습니다. 고객에게 상황을 다시 설명하게 만들지도 않습니다. '다시 묻지 않는 것' — 이 단 한 가지 요소가 핸드오프를 전문적으로 느껴지게 만듭니다.

적절한 담당자에게 도달하기

요약 정보가 구분되지 않은 더미 속에 던져진다면 그것은 낭비일 뿐입니다. 대화는 적절한 상담사 또는 적절한 큐 (queue)에 할당되어야 합니다.

BowChat의 할당(assignment) 및 점유(claiming) 모델이 오늘 출시되었습니다. 대화는 큐(queue)로 라우팅되어 사용 가능한 상담사가 이를 점유할 수 있거나, 직접 할당될 수 있습니다. 점유는 생각보다 중요합니다. 이는 두 명의 상담사가 동시에 동일한 고객에게 답변하는 것을 방지하며, 이는 그 자체로 일종의 봇 루프(bot loop) — 즉, 하나의 스레드에서 두 개의 목소리가 서로 모순되는 상황 — 를 방지합니다. 대화가 점유되면 명확한 소유자가 생기며, 팀의 다른 모든 구성원은 해당 대화가 처리 중임을 확인할 수 있습니다.

응답 시간 약속(response-time commitments)을 준수해야 하는 팀을 위해 그룹 SLA 타이머도 함께 출시되었습니다. 이는 에스컬레이션(escalated)된 대화가 단순히 할당되는 것에 그치지 않고, 타이머가 작동함을 의미합니다. 따라서 핸드오프(handoff)가 지연될 경우, 큐에서 조용히 방치되는 대신 가시적으로 드러나게 됩니다. 할당과 가시적인 타이머의 결합은 "봇이 포기했다"라는 상황을 "특정 담당자가 이 대화를 맡았으며 응답할 예정이다"라는 상황으로 전환해 줍니다.

고객에게는 보이지 않게 유지하기

이 중 그 어떤 것도 상대방(고객)에게는 보여서는 안 됩니다. 고객 입장에서는 하나의 WhatsApp 번호로 하나의 비즈니스에 메시지를 보내는 것이며, 봇이 답변하든 사람이 답변하든 동일한 번호로 계속 메시지를 보냅니다. 다른 라인으로의 전환도 없습니다. "포털로 연결해 드리는 동안 잠시 기다려 주세요"라는 안내도 없습니다. 새로운 스레드도 생기지 않습니다.

연락처 마스킹(Contact masking)이 이 기능을 가능하게 하며 오늘 출시되었습니다. 고객은 항상 비즈니스 번호만 보게 되며, 상담사 개인의 번호는 절대 볼 수 없습니다. 따라서 상담사가 대화를 가져와 문제를 해결한 뒤 다시 돌려놓더라도, 고객은 특정 상담사가 개입했는지 또는 봇이 개입했었는지조차 알 수 없습니다. 비즈니스는 하나의 일관된 정체성을 유지합니다. 그 정체성 뒤에서 제어권은 자동화와 사람 사이를 자유롭게 이동합니다. 이러한 비가시성이 핵심입니다. 고객이 핸드오프를 느낄 수 있다면, 그것은 잘못된 핸드오프입니다.

봇에게 다시 넘기기

돌아오는 과정도 에스컬레이션 (Escalation)만큼이나 중요합니다. 상담원이 투입된 특정 사안이 해결되면, 대화는 깔끔하게 자동화 (Automation) 단계로 돌아갈 수 있어야 합니다. 즉, 상담원이 대화를 해제하면 봇이 고객이 끊김을 느끼지 못하는 사이에 일상적인 후속 조치를 다시 처리할 수 있어야 합니다. 동일한 공유 스레드(Shared thread), 동일한 번호, 동일한 문맥(Context)이 유지되어야 합니다. 상담원의 메모는 계속 연결되어 있으므로, 나중에 대화가 다시 에스컬레이션되더라도 다음 담당자가 여전히 그 흔적을 따라갈 수 있습니다.

피해야 할 안티 패턴 (Anti-pattern)은 일방통행식 구조로, 사람이 한 번 개입하면 그 대화에 영원히 묶여버리는 경우입니다. 지원 볼륨 (Support volume)은 그런 모델에서 살아남을 수 없습니다. 잘 설계된 스택 (Stack)은 봇과 상담원을, 티켓을 담장 너머로 던지는 두 개의 분리된 시스템이 아니라, 하나의 연속된 스레드 위에서 동일한 물체를 주고받는 두 손처럼 취급합니다.

솔직한 상태

솔직하게 말씀드리겠습니다. 공유 인박스 (Shared inbox), 대화 할당 및 점유, 내부 메모, 그룹 SLA 타이머, 그리고 고객이 항상 비즈니스 번호를 볼 수 있도록 하는 연락처 마스킹 (Contact masking)과 같은 상담원 측 기능은 현재 BowChat에서 라이브로 제공되고 있으며, 이에 대해서는 자신 있게 말씀드릴 수 있습니다. AI 보조 및 봇 운영 (Bot-ops) 측면인 자동화된 신뢰도 임계값 (Confidence thresholds), 자동 생성된 에스컬레이션 요약, 자동 핸드백 (Hand-back) 기능은 현재 파일럿 및 얼리 액세스 (Early access) 단계에 있습니다. 이는 실재하며, 초기 사용자들에게 라이브로 제공되고 있고 성장 중이지만, 아직 엔터프라이즈급 (Enterprise-grade)이라고 부를 만큼 성숙하지는 않았으며 여전히 격차를 줄여가는 과정에 있습니다. 만약 상담원 핸드오프 (Human-handoff) 메커니즘을 위해 BowChat을 검토 중이라면, 지금 바로 해당 기능들을 활용하실 수 있습니다. 만약 자동화된 에스컬레이션 루프 (Escalation loop)를 원하신다면, 얼리 액세스 파트너로 참여하여 저희와 함께 기능을 만들어가기를 기대합니다.

BowChat은 WhatsApp 우선 (WhatsApp-first) 방식으로, WhatsApp 비즈니스 플랫폼 (WhatsApp Business Platform)을 기반으로 구축되었으므로, 위의 모든 기능은 고객이 이미 사용 중인 채널에서 이루어집니다.

WhatsApp에서 봇-상담원 핸드오프를 연결하려는데 반복되는 문제에 지쳤다면, BowChat에서 시작하세요: bow.chat.

원문은 BowChat 블로그에 게시되었습니다.