테스트는 통과했는데 통화가 나빠졌다: 콜봇 루프 변경이 요구하는 회귀·섀도우 배포 게이트 설계

루프 변경이 회귀 테스트를 통과하고도 나빠지는 이유

콜봇 루프는 STT·LLM·TTS·재시도·핸드오프가 순서대로 얽힌 하나의 시스템이라, 프롬프트 한 줄이나 재시도 임계값 하나를 바꿔도 대화 전체의 체감 품질이 달라집니다. 그런데 상당수 팀은 텍스트 챗봇에서 쓰던 회귀셋(입력 문장→기대 응답)을 그대로 재사용합니다. 텍스트 회귀셋은 확인을 두 번 반복하거나 답변이 로봇처럼 들리거나 상담원 핸드오프 조건이 더 이상 걸리지 않는 것 같은 음성 특유의 퇴화를 애초에 측정하지 못합니다. 결과적으로 로그는 깨끗하고 유닛 테스트는 전부 초록불인데, 실제 통화에서는 이탈이 늘어나는 간극이 생깁니다.

회귀·적대적·리플레이 — 세 계층으로 나눠야 잡히는 실패

업계에서 통용되는 음성 에이전트 테스트 방식은 크게 세 계층으로 나뉩니다. 첫째, 정상 대화 흐름을 고정한 골든 대화셋으로 매 배포마다 같은 시나리오를 재현하는 회귀 계층입니다. 둘째, 소음·사투리·중간에 말 끊기 같은 조건을 일부러 주입하는 적대적(레드팀) 페르소나 계층입니다. 셋째, 실제 프로덕션 통화를 새 버전에 다시 흘려 이전 버전의 결과와 비교하는 리플레이 계층입니다. 세 계층 중 하나만 운영하면 나머지 두 계층이 잡아내는 실패 유형은 배포 뒤에야 드러납니다.

구축 로드맵과 함정: 콜봇 루프 변경 배포 게이트

배포 합격선은 변경에 착수하기 전에 코드로 선언합니다. 골든 대화셋 100개 이상 유지, 회귀 스위트 통과율 99% 이상, 섀도우(그림자) 트래픽 10~20% 구간에서 최소 24시간 관측 후 카나리 승급, 인터럽트(바지인) 처리 실패율 1% 이하를 출발 기준으로 삼습니다. 이 숫자가 없으면 "괜찮게 들린다"는 청취 인상만으로 배포 여부를 정하게 됩니다.

골든 대화셋은 시뮬레이터 대화를 저장해 늘립니다. Google Dialogflow CX의 테스트 케이스 기능은 시뮬레이터에서 나눈 대화를 저장하면 의도 매칭·플레이북 액션·활성화된 플로우와 페이지가 기대값으로 함께 저장되고, 이후 에이전트를 업데이트할 때마다 같은 대화를 재실행해 기대값과 비교하는 방식을 공식 문서로 제공합니다. 콜봇 루프에도 같은 원칙을 적용해 실패로 이어졌던 실제 통화를 매주 골든셋 후보로 승격시키면, 셋이 저절로 최신 실패 유형을 반영합니다.

실패는 세 갈래로 반복됩니다. 첫째, 텍스트 챗봇 회귀셋을 그대로 재사용해 발음·억양·끼어들기처럼 음성에서만 드러나는 문제를 놓치는 경우입니다. 둘째, 스테이징 환경이나 텍스트 인터페이스로만 테스트해 실제 전화 경로와 다른 경로를 타는 경우입니다. Twilio의 ConversationRelay 공식 운영 가이드는 실제 프로비저닝된 전화번호 뒤에 백엔드를 배포한 상태로 테스트해야 라이브 발신자와 동일한 음성 인식·LLM·음성 합성 경로를 검증할 수 있다고 명시합니다.

셋째, 인터럽트(바지인) 처리 로직의 회귀를 빼먹는 경우입니다. ConversationRelay는 메시지를 interruptible·preemptible로 표시하고 발화가 끊기면 로컬 대화 기록에서 끊긴 지점까지만 남기는 처리 흐름을 갖고 있는데, 재시도 로직이나 프롬프트를 바꾸면서 이 흐름을 검증하지 않으면 끼어들기 대응만 조용히 깨집니다. 복구 분기는 임계값으로 미리 선언해 둡니다. 회귀 스위트 통과율이 99% 아래로 떨어지면 배포 자체를 자동으로 막고, 섀도우 단계에서 완료율·핸드오프율·인터럽트 실패율이 이전 버전보다 나빠지면 카나리 승급을 멈추고 자동 롤백합니다.

배포 전 체크리스트에는 외부 시스템 의존성을 격리하는 절차를 넣습니다. 웹훅 호출을 토글로 끈 상태에서 순수 대화 로직만 먼저 검증하고, 켠 상태에서 통합 테스트를 별도로 돌리는 2단계 구성이 안전합니다. 통화 녹취와 이벤트 로그에는 배포 버전 태그, 회귀 통과율, 섀도우 비교 지표를 최소 필드로 남기고, PII 마스킹 여부도 게이트 항목에 포함합니다.

릴리스가 끝날 때마다 리플레이에서 걸러진 실패 통화를 골든셋에 역주입하고, 적대적 페르소나 비율(소음·사투리·중간 끼어들기 시나리오 비중)을 셋 전체의 일정 비율 이상으로 유지하는 것을 파이프라인 자체의 지표로 둡니다. 회귀셋 규모가 늘지 않는 릴리스가 반복된다면 테스트가 절차 문서로만 남아 있다는 신호입니다.

변경 로그는 코드 diff와 별도로 남깁니다. 이번 배포에서 프롬프트 몇 줄, 재시도 임계값 몇 개가 바뀌었는지를 한 줄로 추적할 수 있어야 섀도우 단계에서 지표가 흔들렸을 때 원인 후보를 좁힐 수 있습니다.

바로 쓰는 체크리스트

콜봇 루프를 바꿀 때 안전선은 로그가 깨끗하다는 인상이 아니라 회귀·적대적·리플레이 세 계층의 통과율로 세웁니다. 골든 대화셋 100개·통과율 99%·섀도우 24시간 관측을 배포 합격선으로 코드에 박아 두고 인터럽트 처리 흐름까지 회귀 대상에 포함하면, 재시도 로직 한 줄을 바꿔도 통화 품질이 조용히 무너지는 사고를 배포 전에 잡아낼 수 있습니다.

참고 링크

Test cases — Dialogflow CX, Google Cloud

Best practices for Conversation Relay — Twilio