Voice agent 평가 프레임워크: 실행·결과·경험을 분리해서 측정하는 방법

Voice agent 평가는 텍스트 챗봇 평가보다 어렵습니다. 답변 내용이 맞는지만 보면 부족합니다. 사용자는 응답 지연, 끼어들기 처리, 목소리 흐름, 확인 질문, 업무 완료 여부를 함께 경험합니다. LangChain은 voice agent 평가를 execution, outcome, experience 세 축으로 나누라고 제안합니다. 이 구분은 실무에서 바로 쓸 수 있습니다. 에이전트가 지시를 잘 따랐는지, 실제 목표를 달성했는지, 통화 경험이 자연스러웠는지를 따로 봐야 개선 지점이 보입니다.

예를 들어 예약 agent가 있다고 합시다. 사용자가 날짜와 시간을 말했고, agent는 예약 도구를 호출했고, 성공 메시지를 줬습니다. execution만 보면 통과입니다. 그런데 timezone을 확인하지 않아 잘못된 시간으로 예약됐다면 outcome은 실패입니다. 반대로 업무는 해결했지만 6초씩 침묵하거나 사용자의 말을 자주 끊었다면 experience가 나쁩니다. 이 세 점수를 섞어 평균 내면 원인을 놓칩니다.

Execution: 지시와 절차를 지켰는가

Execution은 agent가 설계된 절차를 따랐는지 보는 축입니다. 예약 agent라면 availability check를 booking보다 먼저 했는지, booking tool에 날짜·시간·timezone이 모두 들어갔는지, 필수 고지문을 말했는지, 개인정보 동의를 받았는지 확인합니다.

이 축은 deterministic evaluator와 잘 맞습니다. trace에 tool call이 남아 있다면 규칙으로 검사할 수 있습니다. 예를 들어 check_availability가 book_appointment보다 먼저 호출됐는지, 같은 tool을 과도하게 반복 호출하지 않았는지, transcript에 “녹음될 수 있습니다” 같은 문구가 포함됐는지 확인합니다. 이런 검사는 빠르고 싸며 재현성이 좋습니다.

반면 의미 판단이 필요한 항목은 LLM judge를 씁니다. 사용자의 모호한 요청에 적절한 확인 질문을 했는지, 정책을 자연어 기준에 맞게 지켰는지, 답변이 제공된 컨텍스트에 근거했는지 같은 항목입니다. 단, rubric은 좁아야 합니다. “응답이 좋은가?”가 아니라 “예약 도구 호출 전에 날짜, 시간, timezone을 모두 구두로 확인했는가?”처럼 써야 점수가 안정됩니다.

Outcome: 사용자의 목적이 실제로 해결됐는가

Outcome은 대화 내부가 아니라 결과를 봅니다. 통화가 끝난 뒤 예약 레코드가 맞게 생성됐는지, 지원 티켓이 재오픈되지 않았는지, 사용자가 올바른 부서로 연결됐는지, 결제나 가입 같은 다음 단계가 실제로 완료됐는지 확인합니다.

이 축이 중요한 이유는 agent가 지시를 완벽히 따라도 제품 목표에는 실패할 수 있기 때문입니다. 프롬프트에 timezone 확인이 빠져 있으면 agent는 지시를 잘 따른 것입니다. 하지만 사용자는 잘못된 예약을 받습니다. 이런 문제는 execution 점수만 보면 발견되지 않습니다.

실무에서는 outcome metric을 업무 시스템과 연결해야 합니다. 예약 agent는 calendar 또는 booking DB와 연결하고, support agent는 ticket status와 reopen rate를 봅니다. sales agent는 미팅 생성, 참석, conversion까지 봅니다. transfer agent는 목적지 연결 성공 여부와 abandoned call을 봅니다. voice trace와 downstream record를 같은 request_id로 묶어야 평가가 가능합니다.

Experience: 통화 경험이 자연스러웠는가

Experience는 사람의 체감 품질입니다. latency, interruption handling, speech clarity, pause, turn-taking, 불필요한 반복, 감정 톤, 말 속도 같은 요소가 들어갑니다. 이 축은 텍스트 transcript만으로는 부족합니다. 녹음, timestamp, 음성 이벤트, VAD 상태, tool latency를 함께 봐야 합니다.

예를 들어 agent가 “확인해보겠습니다”라고 말한 뒤 8초 동안 침묵하면 사용자는 끊긴 줄 압니다. transcript에는 문제가 없어 보입니다. 또 사용자가 말을 끝내기 전에 agent가 계속 끼어들면 답변 정확도와 무관하게 불쾌합니다. 반대로 약간 긴 시간이 걸려도 agent가 “예약 가능 시간을 확인하고 있습니다. 잠시만 기다려 주세요”라고 말하면 경험은 나아집니다.

Experience 평가는 정량과 정성을 섞습니다. 평균 응답 지연, p95 지연, interruption count, silence duration, fallback utterance count를 숫자로 보고, LLM judge나 human review로 자연스러움을 봅니다. 특히 초반에는 human review 샘플을 반드시 둬야 합니다. 음성 경험은 숫자만으로 잡히지 않는 문제가 많습니다.

평가 데이터셋을 어떻게 만들까

처음부터 1,000개 통화 데이터셋을 만들 필요는 없습니다. 먼저 critical path 20~50개를 만듭니다. 예약 성공, 예약 실패, 정보 부족, 사용자가 말을 바꾸는 경우, 정책상 거절해야 하는 경우, 배경 소음, 긴 침묵, 중간 끼어들기, tool error 같은 케이스를 넣습니다.

각 케이스에는 expected execution, expected outcome, expected experience risk를 따로 둡니다. 예를 들어 “사용자가 날짜만 말하고 시간대를 말하지 않음” 케이스의 expected execution은 timezone 확인 질문입니다. expected outcome은 예약이 생성되지 않거나 timezone 확인 후 생성되는 것입니다. experience risk는 확인 질문이 너무 길거나 사용자를 탓하는 톤을 쓰지 않는 것입니다.

이 데이터셋은 prompt 변경, 모델 변경, STT/TTS 변경, tool schema 변경 때마다 회귀 테스트로 돌립니다. 음성 agent는 한 부분만 바꿔도 전체 경험이 변합니다. 특히 STT 모델 변경은 transcript 품질뿐 아니라 tool argument 추출과 사용자 의도 판단까지 흔듭니다.

운영 대시보드에 넣을 지표

Voice agent 운영 대시보드는 세 축을 따로 보여줘야 합니다. Execution에는 required tool order pass rate, policy disclosure pass rate, tool error rate, repeated tool call count를 둡니다. Outcome에는 booking success rate, resolution rate, reopen rate, transfer success rate, conversion rate를 둡니다. Experience에는 first response latency, turn latency p95, silence over threshold, interruption count, user barge-in rate, call abandonment를 둡니다.

세 지표를 함께 보면 원인 추적이 쉬워집니다. execution은 높은데 outcome이 낮으면 지시나 도구 권한이 부족한 것입니다. outcome은 높은데 experience가 낮으면 latency, TTS, 대화 설계 문제입니다. experience는 좋은데 execution이 낮으면 agent가 친절하지만 위험한 행동을 하는 상태입니다.

실행 체크리스트

• voice agent 평가를 execution, outcome, experience로 분리한다.
• tool order, 필수 문구, 필수 argument는 deterministic evaluator로 검사한다.
• 의미 판단은 좁은 rubric의 LLM judge로 평가한다.
• downstream 업무 결과를 trace와 같은 request_id로 연결한다.
• transcript만 보지 말고 녹음, timestamp, tool latency를 함께 본다.
• critical path 20~50개로 작은 회귀 데이터셋을 먼저 만든다.
• STT, TTS, model, prompt 변경 때마다 회귀 테스트를 돌린다.
• p95 latency와 긴 침묵 구간을 별도 지표로 본다.
• human review 샘플을 유지해 숫자가 놓치는 경험 문제를 잡는다.
• 세 축 점수를 평균 내지 말고 별도 원인 분석에 사용한다.