음성 에이전트 Fallback 설계: 침묵 없이 실패를 회복하는 3개 레인
프로덕션 음성 에이전트에서 fallback은 에러 처리보다 고객 경험을 지키는 운영 설계에 가깝습니다.
운영 환경의 음성 에이전트는 “잘 말하는 모델”만으로 완성되지 않습니다. 실제 고객 통화에서는 STT 지연, CRM 응답 실패, 긴 침묵, 고객의 갑작스러운 주제 전환이 동시에 발생합니다.
실패는 예외가 아니라 설계 대상입니다
프로덕션 음성 에이전트에서 fallback은 에러 메시지가 아니라 대화의 안전장치입니다. 사용자는 API timeout을 알 필요가 없습니다. 대신 에이전트가 다음 행동을 자연스럽게 선택해야 합니다.
좋은 fallback은 실패를 숨기는 기술이 아니라, 고객이 다음 단계로 계속 이동하게 만드는 운영 설계입니다.
대표적인 실패 지점은 3개입니다.
- 음성 인식이 불확실한 경우
- LLM 또는 Tool Server 응답이 늦는 경우
- 고객 의도가 기존 플로우를 벗어나는 경우
2초 침묵은 이미 경험 품질 문제입니다
통화에서는 웹 UI보다 지연에 훨씬 민감합니다. 버튼 로딩은 기다릴 수 있지만, 전화선 너머의 침묵은 “상담원이 못 알아듣고 있다”는 신호로 해석됩니다.
Reference fallback budget
0.0s ─ customer utterance ends
0.7s ─ first acknowledgement should start
1.5s ─ tool wait phrase or clarification path
2.0s ─ fallback branch must be visible to caller
이 숫자는 절대 기준이 아니라 운영 reference target입니다. 핵심은 “언제 fallback을 시작할지”를 모델 판단에만 맡기지 않고, orchestration layer에서 시간 예산으로 관리하는 것입니다.
Fallback은 3개 레인으로 나눠야 합니다
하나의 “죄송합니다, 다시 말씀해주세요”는 충분하지 않습니다. BringTalk이 보는 프로덕션 설계는 fallback을 3개 레인으로 분리합니다.
- Clarification fallback — 고객 발화를 다시 좁혀 묻습니다.
- Tool fallback — CRM·예약·결제 API가 늦을 때 대기 문장을 제공합니다.
- Human handoff fallback — 자동 처리보다 상담원 연결이 더 안전한 순간을 감지합니다.
각 레인은 목적이 다릅니다. Clarification은 이해도를 높이고, Tool fallback은 침묵을 줄이며, Human handoff는 리스크를 낮춥니다.
Context Injection이 fallback 품질을 좌우합니다
Fallback 문장은 고객 상태를 모르면 금방 기계적으로 들립니다. 같은 “확인해보겠습니다”라도 신규 리드, 기존 고객, 결제 실패 고객에게 필요한 다음 질문은 다릅니다.
최소 context
에이전트가 fallback을 자연스럽게 처리하려면 최소한 다음 4개 context가 필요합니다.
- 고객 여정 단계: 신규 문의, 견적, 재구매, 이탈 위험
- 직전 intent: 예약, 가격, 배송, 상담원 연결
- Tool 상태: 성공, 지연, 실패, 재시도 중
- 금지 행동: 민감정보 저장, 확정되지 않은 가격 안내, 무리한 약속
이 context는 LLM prompt에 길게 붙이는 것이 아니라, turn마다 필요한 만큼 주입되어야 합니다. 그래야 응답은 짧고, 판단은 정확해집니다.
운영팀이 봐야 할 지표는 “성공률” 하나가 아닙니다
Fallback을 넣었다고 끝나는 것이 아닙니다. 실제 운영에서는 fallback 이후 고객이 계속 대화를 이어갔는지, 상담원 연결이 적절했는지, 같은 실패가 반복되는지를 봐야 합니다.
Fallback dashboard checklist
- fallback_rate by intent
- recovery_rate after fallback
- repeated_fallback_count per call
- human_handoff_reason
- tool_timeout_source
BringTalk의 LQA·FUA 플로우에서는 이 지표가 리드 품질 판단과 후속 콜 전략으로 연결됩니다. 특히 repeated fallback은 단순 오류가 아니라 “스크립트/데이터/API 중 하나가 고객 현실을 따라가지 못한다”는 신호입니다.
운영 기준: 1회 fallback은 회복 설계, 2회 반복 fallback은 진단 신호, 3회 이상은 human handoff 후보로 다뤄야 합니다.
