음성 에이전트 Fallback 설계: 침묵 없이 실패를 회복하는 3개 레인

운영 환경의 음성 에이전트는 말을 잘하는 모델만으로 완성되지 않습니다. 실제 고객 통화에서는 STT(음성 인식) 지연, CRM(고객관리 시스템) 응답 실패, 긴 침묵, 고객의 갑작스러운 주제 전환이 한꺼번에 일어납니다.

실패도 설계 대상입니다

프로덕션 음성 에이전트에서 fallback(정상 흐름이 막혔을 때 넘어가는 대체 경로)은 에러 메시지보다 대화의 안전장치에 가깝습니다. 고객은 API timeout(외부 시스템 응답 시간 초과)을 알 필요가 없습니다. 에이전트가 다음 행동을 자연스럽게 고르면 됩니다.

좋은 fallback은 실패를 감추는 데서 그치지 않고, 고객이 다음 단계로 계속 나아가게 만듭니다.

대표적인 실패 지점은 3개입니다.

• 음성 인식이 불확실한 경우
• LLM 또는 Tool Server(외부 시스템을 조회하는 서버) 응답이 늦는 경우
• 고객 의도가 기존 플로우를 벗어나는 경우

2초 침묵은 이미 경험 품질 문제입니다

통화는 웹 화면보다 지연에 훨씬 민감합니다. 버튼 로딩은 기다려 주지만, 전화선 너머의 침묵은 “상담원이 못 알아듣고 있다”는 신호로 받아들여집니다.

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

이 숫자는 설계할 때 기준으로 삼는 참고 목표치이며, 실측 평균이나 업계 표준은 아닙니다. 요점은 fallback을 언제 시작할지 모델 판단에만 맡기지 않고, orchestration layer(대화 흐름을 조율하는 제어 계층)에서 시간 예산으로 관리하는 것입니다.

Fallback은 3개 레인으로 나눠야 합니다

“죄송합니다, 다시 말씀해 주세요” 한 문장으로는 부족합니다. BringTalk은 프로덕션 설계에서 fallback을 3개 레인으로 나눕니다.

1. Clarification fallback(되묻기): 고객 발화를 좁혀서 다시 묻습니다.
2. Tool fallback(도구 지연 대응): CRM·예약·결제 API가 늦을 때 대기 문장으로 침묵을 메웁니다.
3. Human handoff fallback(상담원 연결): 자동 처리보다 상담원 연결이 더 안전한 순간을 알아챕니다.

레인별로 실제 문장은 이런 식입니다.

• 되묻기: “예약을 바꾸시려는 건가요, 아니면 취소하시려는 건가요?”
• 도구 지연: “지금 예약 가능한 시간을 확인하고 있어요. 잠시만 기다려 주세요.”
• 상담원 연결: “이 부분은 담당 상담원이 더 정확하게 안내해 드릴 수 있어요. 바로 연결해 드릴게요.”

각 레인은 목적이 다릅니다. 되묻기는 이해도를 높이고, 도구 지연 대응은 침묵을 줄이며, 상담원 연결은 위험을 낮춥니다.

Context Injection이 fallback 품질을 좌우합니다

Fallback 문장은 고객 상태를 모르면 금세 기계적으로 들립니다. 같은 “확인해 보겠습니다”라도 신규 리드, 기존 고객, 결제 실패 고객에게 이어질 다음 질문은 다릅니다. 그래서 고객 맥락을 그때그때 넣어 주는 Context Injection(맥락 주입) 설계가 함께 필요합니다.

최소 context

에이전트가 fallback을 자연스럽게 처리하려면 최소한 다음 4가지 맥락이 필요합니다.

• 고객 여정 단계: 신규 문의, 견적, 재구매, 이탈 위험
• 직전 intent(고객 의도): 예약, 가격, 배송, 상담원 연결
• Tool 상태: 성공, 지연, 실패, 재시도 중
• 금지 행동: 민감정보 저장, 확정되지 않은 가격 안내, 무리한 약속

이 맥락은 LLM 프롬프트에 길게 붙여 두기보다 턴마다 필요한 만큼 넣어야 합니다. 그래야 응답은 짧고 판단은 정확해집니다.

운영팀이 볼 지표는 “성공률” 하나로 부족합니다

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(후속 연락 상담) 플로우에서는 이 지표가 리드 품질 판단과 후속 콜 전략으로 이어집니다. 특히 반복 fallback은 단순 오류로 넘길 일이 아닙니다. 스크립트, 데이터, API 중 하나가 고객의 실제 상황을 따라가지 못한다는 신호입니다.

운영 기준: 1회 fallback은 회복 설계, 2회 반복 fallback은 진단 신호, 3회 이상은 상담원 연결 후보로 다뤄야 합니다.