핸드오프는 대화의 끝이 아니라 새 세션의 시작이다
Google Cloud의 Dialogflow CX 문서는 가상 상담원이 사람 상담원에게 대화를 넘기는 신호(Live Agent Handoff)를 발신할 뿐, 세션 상태를 스스로 바꾸지는 않는다고 명시한다. Dialogflow CX는 이 신호를 측정 목적으로만 인식하며, 핸드오프 이후 무엇을 어떻게 넘길지에 대한 구조는 강제하지 않는다. 상담원 화면에 슬롯값과 대화 이력을 채우는 일은 결국 통합을 붙이는 팀의 몫으로 남는다. 신호만 잡고 컨텍스트 전달 설계를 뒤로 미루면, 상담원은 방금 대화를 처음부터 다시 물어야 하는 빈손 인계를 받는다.
신뢰 점수 하나가 아니라 누적 실패로 판단한다
Amazon Lex V2의 AMAZON.FallbackIntent는 후보 인텐트 전체의 신뢰 점수가 임계값 아래일 때, 발화가 기대 패턴과 어긋날 때, 재확인·슬롯 채움 재시도가 소진됐을 때 트리거된다. 공식 개발자 가이드는 이 폴백 발생 횟수를 세션 변수에 누적해 임계값 기반 분기 로직을 구현하도록 안내하며, 폴백 인텐트 자체에는 발화 예시나 슬롯을 넣을 수 없어 실제 판단 로직은 인텐트 정의 바깥에 둬야 한다. 한 번의 낮은 점수로 곧바로 상담원을 부르는 대신, 같은 세션에서 반복되는 실패를 셈으로써 오탐과 미탐 사이의 균형을 잡으라는 뜻이다.
구축 로드맵과 함정: 콜봇·챗봇 상담원 핸드오프 게이트
기획 단계에서는 핸드오프를 언제 부를지와 무엇을 넘길지 두 축으로 나눠 수치 목표를 세운다. 오탐률(넘기지 않아도 됐는데 부른 비율) 15% 이하, 미탐률(불렀어야 했는데 못 부른 비율) 5% 이하, 컨텍스트 패키징(슬롯값·직전 3턴 발화·세션 ID를 상담원 화면에 채우는 작업) 지연 500ms 이내를 배포 기준으로 삼는다. 오탐과 미탐은 같은 임계값을 반대 방향으로 움직이므로 두 지표는 항상 짝지어 추적해야 한다.
흔한 실패 패턴은 단발성 저신뢰 한 번에 곧바로 전환하는 경우다. 발음이 순간 뭉개진 한 턴만으로 상담원 큐에 밀어 넣으면 오탐이 쌓여 상담원 자원이 낭비된다. 복구 전략은 Lex 방식처럼 세션 변수에 폴백 횟수를 누적해, 동일 워크플로 단계에서 2회 연속 저신뢰가 나올 때만 전환하는 것이다.
반대되는 실패 패턴은 신뢰 점수가 임계값을 넘지 않아 재시도만 반복하다 사용자가 조용히 이탈하는 미탐 방치다. 복구 전략은 재시도 횟수 자체에 상한을 두고, 상한에 닿으면 신뢰 점수와 무관하게 강제로 핸드오프 신호를 발신하는 별도 안전망을 두는 것이다.
세 번째 패턴은 핸드오프 신호는 보냈지만 컨텍스트가 비어 있는 빈손 인계다. Dialogflow CX 문서가 명시하듯 세션 상태 전달은 시스템 몫이므로, 신호 발신과 컨텍스트 페이로드 구성을 같은 트랜잭션으로 묶지 않으면 신호만 먼저 도착하고 상담원 화면은 비어 있는 경합 상태가 생긴다.
배포 전 체크리스트에는 저신뢰 발화, 반복 재시도, 명시적 상담원 요청(예: 사람 바꿔줘) 세 시나리오를 재현해 핸드오프 발동 여부와 소요 시간을 검증하는 항목을 넣는다. 로그에는 폴백 누적 횟수, 핸드오프 트리거 사유, 컨텍스트 패키징 완료 시각, 상담원 첫 응답까지의 대기 시간을 표준 필드로 남긴다. 발화 원문과 세션 이력을 넘길 때는 결제 정보·주민등록번호 같은 PII를 마스킹한 뒤 전달해야 한다.
개선은 주간 단위로 오탐과 미탐 사례를 따로 떼어 검토한다. 오탐이 몰리는 인텐트나 시간대가 보이면 해당 구간의 폴백 누적 임계값을 조정하고, 미탐으로 이탈한 세션은 재시도 상한과 강제 핸드오프 조건을 다시 계산한다. 임계값 튜닝 로그와 워크플로 구조 변경 로그를 분리해 남겨야 다음 주 회귀 원인을 빠르게 좁힐 수 있다.
바로 쓰는 체크리스트
상담원 핸드오프는 신뢰 점수 한 번이 아니라 누적된 실패와 컨텍스트 전달까지 포함한 하나의 트랜잭션으로 설계해야 한다. 오탐률 15% 이하·미탐률 5% 이하·컨텍스트 패키징 500ms 이내를 배포 기준으로 잡고, 폴백 누적과 재시도 상한이라는 두 개의 안전망을 동시에 걸어두면 상담원 큐 낭비와 사용자 이탈을 함께 줄일 수 있다.