콜봇 루프가 반복하는 것은 대화가 아니라 상태 전이
콜봇의 한 턴은 ASR(음성인식)이 발화를 받아 NLU·LLM이 의도를 해석하고 TTS(음성합성)로 응답하는 한 바퀴입니다. 이 사이클이 실패해 같은 단계를 다시 도는 것이 루프 반복이며, 턴과 반복을 같은 지표로 세면 언제 개입해야 하는지 판단할 기준이 사라집니다.
예산(budget)은 이 반복에 턴 수·벽시계 시간·통화당 비용이라는 상한을 미리 선언하는 장치이고, 서킷브레이커는 같은 실패가 임계치를 넘는 순간 재시도를 끊고 대체 경로로 전환하는 런타임 장치입니다. 재시도는 일시적 오류를 다시 시도하는 것이고 서킷브레이커는 지속적 실패 앞에서 시도 자체를 멈추는 것이라는 차이를 팀이 같은 정의로 공유해야 합니다.
무엇이 갇힌 루프인가: 반복 발화 탐지
같은 발화가 연속 2회 이상 반복되거나 의도 분류가 동일한 실패 코드로 되풀이되면 이는 대화가 아니라 루프에 갇힌 상태로 봐야 합니다. no-input·no-match 이벤트별로 별도 카운터를 두고 상한(예: 2회)에 도달하면 다른 표현으로 리프레이즈를 강제해야 사용자가 같은 문장을 세 번째 듣는 상황을 막을 수 있습니다.
기획부터 에스컬레이션까지: 콜봇 루프 예산·서킷브레이커 실무 가이드
(a) 기획·목표 수치: 콜봇 루프에 예산을 세 축으로 선언합니다 — 턴 수 상한(같은 페이지에서 no-input·no-match 합산 최대 3회), 벽시계 시간 상한(콜 시작부터 15초 내 첫 유의미한 응답, 콜 전체 90초 초과 시 강제 분기), 비용 상한(통화당 STT·LLM·TTS 합산 요금 상한액). 세 축 중 하나라도 넘으면 예산 소진으로 간주해 다음 단계로 넘어갑니다.
(b) 실패 패턴 3가지: 첫째, 재시도를 턴 단위가 아니라 스테이지 단위(ASR·LLM·TTS 각각)로 따로 설정해 개별로는 정상 범위인데 합산 시 예산을 넘기는 경우입니다. 둘째, no-match 카운터를 세션 전체가 아니라 페이지별로 리셋해 사용자가 흐름을 넘나들며 같은 답변을 5번 넘게 듣는 경우입니다. 셋째, 서킷브레이커가 트립된 뒤 대체 경로(사람 상담·DTMF 대체 채널)가 준비되지 않아 트립 즉시 통화가 끊기는 경우입니다.
(b') 복구 분기: 스테이지별 재시도는 공유 재시도 예산(예: 콜당 총 4회)에서 차감하는 방식으로 합산하고, 예산 소진 시 즉시 리프레이즈 1회 후에도 실패하면 사람 상담으로 넘깁니다. 서킷브레이커가 트립되면 라우팅을 재배포 없이 DTMF 메뉴나 상담원 대기열로 전환할 수 있게 구성해야 트립이 곧 통화 종료로 이어지지 않습니다.
(c) 운영 체크리스트: 배포 전 no-input·no-match·반복 발화 세 시나리오를 각각 스크립트로 재생해 예산 상한과 에스컬레이션 트리거가 실제로 작동하는지 확인합니다. 로그에는 턴 카운트, 스테이지별 재시도 횟수, 서킷브레이커 트립 여부, 예산 소진 사유를 표준 필드로 남기고, 통화 녹취·전사 로그의 개인정보(전화번호·계좌번호 등)는 저장 전에 마스킹합니다.
(d) 개선 루프: 주간 단위로 서킷브레이커 트립률과 트립을 유발한 상위 의도(intent)를 집계해, 반복적으로 트립을 일으키는 의도는 리프레이즈 문구를 바꾸거나 첫 턴에서 다른 흐름으로 분기시킵니다. 예산 상한 값 자체도 트립률이 목표치(콜 5% 이하)를 벗어나면 재조정 대상으로 다룹니다.
바로 쓰는 체크리스트
콜봇 루프를 안전하게 운영하려면 턴 수·시간·비용 세 축의 예산을 코드로 선언하고, 스테이지별 재시도를 공유 예산으로 합산하며, 서킷브레이커가 트립될 때 대체 경로가 항상 준비돼 있어야 합니다. Dialogflow CX가 권장하는 no-match·no-input 최대 3회 규칙을 지키는 것만으로도 사용자가 같은 질문을 무한히 듣는 상황을 막을 수 있습니다.
참고 링크
Building Effective AI Agents — Anthropic
Voice agent design best practices — Dialogflow CX, Google Cloud