공백 3초가 임계값이다: 콜봇 루프의 데드에어 감지·복구 게이트 설계

데드에어는 하나의 원인이 아니다

콜봇이 말을 멈춘 뒤 다시 입을 열지 않는 구간은 증상 하나에 원인이 여럿 겹쳐 있습니다. Hamming의 분석에 따르면 같은 침묵이라도 RTP 스트림이 끊겨 통화 자체가 유실된 경우, 음성 활동 감지(VAD)의 엔드포인팅이 지나치게 길게 기다리는 경우, 음성인식(STT)이 파셜 결과만 내고 확정(finalize)하지 않는 경우, 조회 중인 툴콜이 지연되는 경우, TTS 생성이나 재생이 늦는 경우까지 원인이 전부 다릅니다. 레이어 하나를 고쳐도 다른 레이어의 침묵은 그대로 남습니다.

그래서 Hamming은 매 턴의 침묵을 턴 단위 이벤트로 로그에 남기고, 통신·VAD·STT 확정·LLM 첫 토큰·툴 실행·TTS 첫 오디오·재생이라는 구성 요소별 타임스탬프를 조인해 어느 레이어가 침묵을 만들었는지 귀속시키라고 권고합니다. 침묵 하나를 "느린 응답"으로 뭉뚱그리면 원인 레이어의 담당자에게 알람이 가지 않습니다.

임계값 하나로는 못 가른다

FutureAGI의 데드에어 평가 항목은 RMS 에너지 기반으로 통화 전체 침묵 비율 20%, 단일 공백 최대 3,000ms를 기본 임계값으로 제시합니다. 숫자 자체보다 중요한 건 이 임계값이 "평가 도구의 기본값"이라는 점입니다. 짧은 공백은 모델이 추론 중일 수도 있고 통신이 실제로 끊긴 것일 수도 있어, 전역 임계값 하나로는 두 경우를 가르지 못합니다.

AWS Connect의 에이전틱 보이스 가이드는 조회 같은 지연 구간에 보류 안내(holding prompt)를 재생하면서 바지인(barge-in)은 계속 열어 두라고 권고합니다. 침묵을 아예 없애는 것이 목표가 아니라, 길어질 구간을 미리 알고 그 구간만 다르게 다루는 설계가 목표입니다.

설계에서 운영까지: 데드에어 감지·복구 게이트 체크리스트

(a) 기획 단계에서 합격선을 수치로 먼저 건다. 단일 공백 경보선은 FutureAGI가 쓰는 3초를 1차 기준으로 걸고, 통화 전체 데드에어 비율은 20%가 아니라 더 보수적으로 15% 이내를 목표로 둡니다. 복구 성공률(공백 이후 통화가 끊기지 않고 이어진 비율)은 85% 이상, 복구가 안 될 때 상담원 핸드오프로 전환되는 지연은 5초 이내로 선언합니다. 이 숫자는 출발점이고, 자체 통화 데이터가 쌓이면 레이어별로 다시 쪼개 재조정합니다.

(b) 실패 패턴은 레이어마다 다르게 나타납니다. 첫째, RTP 스트림이 끊겼는데 애플리케이션 레이어는 통화가 살아 있다고 착각하는 경우. 둘째, VAD 엔드포인팅이 너무 길어 발화가 끝났는데도 몇 초를 더 기다리는 경우. 셋째, STT가 파셜 전사만 내고 finalize 이벤트가 오지 않아 다음 턴이 시작되지 못하는 경우. 넷째, 툴콜이나 TTS 생성·재생이 지연되는 동안 아무 소리도 나가지 않는 경우입니다.

복구는 원인 레이어에 따라 분기합니다. 통신 레이어 유실은 세션을 즉시 종료하고 재다이얼 로그를 남기고, VAD·STT 지연은 짧은 필러 문구로 턴을 이어가며, 툴콜·TTS 지연 구간은 AWS가 권고하는 보류 안내를 재생하면서 바지인을 열어 둡니다. 같은 통화에서 공백이 두 번 이상 경보선을 넘으면 사람 확인 없이 상담원 핸드오프로 자동 전환합니다.

(c) 운영 체크리스트는 턴 단위 로그부터 시작합니다. 통신·VAD·STT 확정·LLM 첫 토큰·툴 실행·TTS 첫 오디오·재생 타임스탬프를 같은 턴 ID로 묶어 저장해야 사후에 어느 레이어가 공백을 만들었는지 가를 수 있습니다. 배포 전에는 툴콜 지연과 TTS 생성 지연을 인위적으로 주입하는 시나리오 테스트로 보류 안내와 핸드오프 게이트가 실제로 발동하는지 확인합니다.

녹취에 보류 안내·필러 문구가 과도하게 반복되면 사용자 경험이 나빠지므로, 같은 통화에서 필러가 3회를 넘으면 핸드오프로 강제 전환하는 상한도 함께 둡니다. 로그에는 PII가 포함될 수 있는 오디오 구간을 마스킹해 저장합니다.

(d) 배포 이후에는 레이어별로 묶은 데드에어 이벤트를 매주 검토해 반복되는 원인(특정 STT 벤더, 특정 툴 API)을 엔드포인팅·타임아웃 튜닝에 역주입합니다. 데드에어 비율과 복구 성공률이 릴리스를 거치며 개선되는지를 게이트 자체의 성과 지표로 추적합니다.

바로 쓰는 체크리스트

데드에어는 증상 하나에 통신·VAD·STT·툴콜·TTS라는 서로 다른 원인이 겹쳐 있어, 전역 임계값 하나로는 가려내지 못합니다. 단일 공백 3초·통화 전체 15% 이내라는 경보선을 먼저 걸고, 레이어별 타임스탬프를 조인한 턴 단위 로그로 원인을 귀속시키고, 지연 구간은 보류 안내와 바지인으로, 반복되는 공백은 상담원 핸드오프로 분기하는 게이트를 두면 침묵이 곧 이탈로 이어지는 구간을 줄일 수 있습니다.

참고 링크

Voice Agent Dead Air Detection: Root Causes and Fixes — Hamming

Dead Air Detection — FutureAGI Docs

Agentic voice best practices — AWS Connect Admin Guide