[AICC] 음성 에이전트는 어떻게 평가할까? - Full-Duplex와 턴테이킹 벤치마크
말을 알아듣는 것만으로는 부족한 음성 에이전트, 무엇을 어떻게 평가해야 하는지 세 편의 벤치마크 논문으로 알아봅니다.
다루는 논문
VoiceBench: Benchmarking LLM-Based Voice Assistants (Chen et al., 2024)
Full-Duplex-Bench: A Benchmark to Evaluate Full-duplex Spoken Dialogue Models on Turn-taking Capabilities (Lin et al., 2025)
Talking Turns: Benchmarking Audio Foundation Models on Turn-Taking Dynamics (Arora et al., ICLR 2025)
1. 음성 에이전트의 품질은 “무슨 말을 하느냐(content)”와 “언제 말하느냐(timing)” 두 축으로 나뉨. 텍스트 LLM 벤치마크는 앞의 것만 봄
2. VoiceBench는 화자/환경/발화 내용의 변이에 대한 견고성을, Full-Duplex-Bench와 Talking Turns는 pause 처리, 맞장구(backchannel), 끼어들기(interruption) 같은 턴테이킹 능력을 측정함
3. 상담 voicebot은 task success 외에도 응답 지연, barge-in 처리, 잡음/억양 견고성, 끊김 없는 턴 전환을 함께 모니터링해야 함
본 포스트는 AICC(AI 컨택센터) 에이전트 평가 연구를 정리하는 미니 시리즈의 세 번째 글로, 음성 대화 평가와 관련된 세 편의 논문을 읽고 정리한 노트입니다.
원문은 여기에서 보실 수 있습니다.
VoiceBench, Full-Duplex-Bench, Talking Turns
Contents
- Intro - 말은 맞게 했는데 왜 고객은 화가 났을까?
- 배경: Cascade vs End-to-End, Half-duplex vs Full-duplex
- VoiceBench: 잡음과 억양 앞에서도 똑똑할까?
- Full-Duplex-Bench: 언제 듣고 언제 말할까?
- Talking Turns: 턴테이킹을 판정하는 Judge 모델
- AICC 관점: 상담 voicebot은 무엇을 측정해야 할까?
- 마치며
1. Intro - 말은 맞게 했는데 왜 고객은 화가 났을까?
이전 글들에서는 LLM-as-a-Judge로 상담 응답의 품질을 자동 채점하는 방법과, tau-bench로 사용자 시뮬레이터와 도구 호출, 정책 준수까지 포함한 에이전트의 task success를 측정하는 방법을 살펴봤습니다.
그런데 이 평가들은 모두 텍스트를 전제로 하고 있는데요.
컨택센터의 상당 부분은 여전히 전화, 즉 음성 채널로 들어옵니다. 음성 상담봇을 한 번이라도 만들어 보셨다면 이런 장면이 익숙하실 겁니다.
- 고객이 카드 번호를 “1234… (지갑 뒤적) …5678” 하고 불러주는데, 중간 침묵에서 봇이 “말씀하신 번호가 1234 맞으신가요?” 하고 끼어듦
- 봇이 약관을 길게 읽어주는 도중 고객이 “아니 그게 아니고요” 하고 말을 끊었는데, 봇은 꿋꿋이 끝까지 읽음
- 고객이 “네, 네” 하고 맞장구를 쳤을 뿐인데 봇이 이를 끼어들기로 오인해 말을 멈춤
텍스트 로그만 놓고 보면 위의 대화들은 모두 정답을 말한 성공 케이스일 수도 있습니다. 하지만 고객 입장에서는 짜증나는 통화였겠죠.
즉 음성 에이전트의 품질은 “무슨 말을 하느냐” 뿐만 아니라 “언제, 어떻게 말하느냐” 에도 크게 좌우됩니다.
이번 글에서는 이 문제를 정면으로 다룬 세 편의 벤치마크 논문을 살펴보겠습니다.
VoiceBench는 음성 입력의 다양한 변이 앞에서 에이전트가 얼마나 잘 알아듣는지 를, Full-Duplex-Bench와 Talking Turns는 에이전트가 언제 듣고 언제 말해야 하는지 를 다룹니다.
2. 배경: Cascade vs End-to-End, Half-duplex vs Full-duplex
본론에 들어가기 전에 음성 에이전트의 구조를 나누는 두 가지 축을 짚고 가겠습니다. 논문들의 결과를 해석할 때 계속 등장하는 개념입니다.
축 1. 파이프라인 구성: Cascade vs End-to-End
- Cascade (ASR → LLM → TTS): 음성을 ASR로 텍스트로 바꾸고, 텍스트 LLM이 답을 만들고, TTS가 다시 음성으로 읽어주는 방식. 각 모듈을 독립적으로 교체/튜닝할 수 있고, 중간 텍스트가 남아 로깅과 디버깅이 쉬움. 대신 모듈을 거칠 때마다 지연이 쌓이고, 억양/감정/망설임 같은 비언어적 정보가 텍스트로 바뀌는 과정에서 사라짐
- End-to-End (speech-to-speech): speech encoder가 음성을 바로 LLM의 표현 공간으로 넣고, 모델이 (텍스트를 거치거나 거치지 않고) 음성을 직접 생성하는 방식. Moshi, LLaMA-Omni, Mini-Omni, Qwen2-Audio 등이 이 계열. 이론적으로 지연이 짧고 비언어적 정보를 활용할 수 있지만, 학습이 까다롭고 텍스트 LLM이 가진 능력이 훼손되기 쉬움
축 2. 대화 방식: Half-duplex vs Full-duplex
- Half-duplex: 무전기처럼 한 번에 한 쪽만 말하는 방식. 사용자의 말이 끝났다고 판단(보통 VAD로 일정 시간 이상의 침묵을 감지)하면 그때 응답을 생성함. 대부분의 기존 음성봇이 여기에 해당
- Full-duplex: 전화 통화처럼 듣기와 말하기를 동시에 하는 방식. 사용자 음성 스트림과 모델 음성 스트림을 동시에 모델링하므로, 말하는 도중에도 사용자의 끼어들기를 듣고 반응하거나 상대가 말하는 동안 “음, 네” 같은 맞장구를 칠 수 있음
두 축은 서로 독립적입니다. Full-Duplex-Bench 논문의 분류에 따르면 Moshi나 dGSLM은 end-to-end full-duplex 모델이고, Freeze-Omni나 VITA는 텍스트를 거치는 cascaded 계열이지만 상태 예측 모듈 등을 붙여 full-duplex 동작을 흉내 냅니다.
현업에서 흔히 쓰는 “ASR + LLM + TTS에 barge-in 감지를 붙인 구조”도 넓게 보면 이렇게 cascade 위에서 full-duplex를 흉내 내는 구조라고 할 수 있겠네요.
3. VoiceBench: 잡음과 억양 앞에서도 똑똑할까?
문제의식: ASR 점수나 깨끗한 TTS 음성으로는 부족하다
VoiceBench(NUS, 2024년 10월)는 LLM 기반 voice assistant를 평가하는 벤치마크입니다. 저자들이 지적하는 기존 평가의 한계는 두 가지인데요.
- 기존 평가는 주로 ASR 성능이나, 고품질 TTS로 합성한 깨끗한 음성 질의응답에 집중함
- 실제 환경에서는 화자 특성(나이, 억양, 말 빠르기), 환경(잡음, 잔향, 원거리), 발화 내용(말더듬, 정정, 문법 오류)이 모두 제각각임
논문 서론에서 활용 예시로 아예 virtual customer service 를 언급하고 있어서, AICC 관점에서 읽기에 딱 좋은 논문입니다.
구성: 능력 평가 + 견고성 평가
위 그림처럼 VoiceBench는 크게 두 부분으로 나뉩니다.
능력 평가 는 5개 데이터셋으로 구성됩니다.
| 데이터셋 | 평가 대상 | 음성 | 샘플 수 | 지표 |
|---|---|---|---|---|
| AlpacaEval | 일반 지식/오픈 질의 | 합성 | 199 | GPT 채점 (1~5점) |
| CommonEval | 일반 지식/오픈 질의 | 실제 녹음 | 200 | GPT 채점 (1~5점) |
| SD-QA | 다양한 억양의 질의응답 | 실제 녹음 | 553 | 정확도 |
| IFEval | 지시 따르기 | 합성 | 345 | 규칙 기반 정확도 |
| AdvBench | 안전성 (유해 요청 거절) | 합성 | 520 | 거절률 |
합성 음성은 평가 대상 모델들의 학습에 쓰이지 않은 Google TTS로 만들었고, 특수문자 등은 GPT-4o로 먼저 “읽기 좋은 문장”으로 정규화했다고 합니다. 모든 모델이 음성 출력을 지원하는 것은 아니어서, 평가는 응답의 텍스트 내용 을 기준으로 합니다. 또한 같은 질문을 텍스트로 줬을 때와 음성으로 줬을 때를 비교해, 모달리티가 바뀔 때 얼마나 성능이 떨어지는지도 봅니다.
견고성 평가 는 세 종류의 변이를 인위적으로 주입합니다.
- 화자 변이: 말 빠르기, 나이, 음량, 음높이, 억양 (실제 11개 영어 억양 포함)
- 환경 변이: 원거리(low-pass filter), 신호 왜곡(clipping), 잔향(RT60), 패킷 손실, babble noise, white noise
- 내용 변이: 정정(repair), 반복, 머뭇거림(pause), 감탄사, false start, 잘못된 발음, 문법 오류
결과 1. 단순한 Cascade가 End-to-End를 이겼다
평가 대상은 end-to-end 모델 5종(DiVA, LLaMA-Omni, Mini-Omni, Qwen2-Audio, VITA)과, Whisper-large-v3 + LLaMA-3.1-8B-Instruct를 이어 붙인 Naive pipeline 입니다. 결과는 꽤 충격적인데요.
| 모델 | Overall (Text) | Overall (Speech) |
|---|---|---|
| Naive (Whisper + LLaMA-3.1-8B) | 80.27 | 74.50 |
| DiVA | 81.14 | 64.02 |
| Qwen2-Audio | 72.72 | 59.83 |
| Mini-Omni | 57.11 | 41.56 |
| LLaMA-Omni | 69.26 | 40.21 |
| VITA | 75.14 | 39.33 |
- 음성 입력 기준으로 Naive pipeline이 모든 end-to-end 모델을 10점 이상 앞섬
- Naive의 텍스트 대비 음성 성능 하락은 5.77점(대부분 ASR 오류 때문)인 반면, VITA는 35점 이상 떨어짐
- LLaMA-Omni는 Naive와 같은 base LLM을 쓰는데도, 음성 튜닝 과정에서 텍스트 입력 성능까지 11점 넘게 떨어짐 (특히 지시 따르기)
- 안전성도 문제. 텍스트로 준 유해 요청은 대부분 거절하지만, 음성으로 주면 LLaMA-Omni의 거절률은 98.46%에서 11.35%로, VITA는 95.19%에서 26.73%로 떨어짐
마지막 항목은 상담 도메인에서 특히 무섭습니다. 텍스트 채널에서 꼼꼼히 검증한 가드레일이, 같은 모델을 음성 채널에 붙이는 순간 무력화될 수 있다는 뜻이니까요.
또한 Qwen2-Audio 같은 모델은 ASR 지표만 보면 Whisper에 견줄 만한데도 음성 지시 수행에서는 큰 격차를 보였습니다. ASR 점수가 좋다고 음성 에이전트가 좋은 것은 아니다 라는 것이 이 논문의 핵심 메시지 중 하나입니다.
결과 2. 실제 녹음은 합성음보다 어렵다
CommonEval을 실제 녹음과 TTS 합성음 두 버전으로 비교하면, 모든 모델이 합성음에서 더 높은 점수를 받습니다. 특히 VITA는 실제 녹음 2.15점, 합성음 3.21점으로 차이가 큽니다.
개인 기기로 녹음된 실제 음성은 스튜디오 품질의 합성음보다 잡음이 많기 때문인데요, TTS로 만든 테스트셋만으로 voicebot을 평가하면 성능을 과대평가할 수 있다 는 점을 시사합니다.
결과 3. 잡음, 억양, 말더듬
위 그림은 환경 변이에 따른 응답 점수 변화입니다. 몇 가지 관찰을 정리하면 아래와 같습니다.
- 성능은 선형으로 떨어지지 않음: 일정 범위까지는 버티다가 임계점을 넘으면 급락하는 패턴. 예를 들어 패킷 손실(dropping rate)은 VITA를 제외한 대부분의 모델이 50% 근처까지는 버티다가 그 이후 급격히 무너짐
- Naive pipeline이 대부분의 조건에서 가장 견고함: 저자들은 ASR로 텍스트를 한 번 뽑는 과정이 일종의 암묵적인 denoising 역할을 한다고 해석함
- Whisper 계열 encoder를 쓴 모델들은 비슷한 견고성 을 보이는 반면, 자체 encoder를 쓴 VITA는 잡음, 아이 목소리, 높은 음높이, 억양 변화에 특히 취약함. speech encoder 선택이 견고성을 좌우한다는 가설
- 말 빠르기: end-to-end 모델은 0.5배속 미만, 1.5배속 초과에서 크게 떨어지지만 Naive는 0.25배속~2.0배속에서 안정적
- 억양: 호주/영국/미국 같은 고자원 억양에서는 비슷하지만, 인도(남/북부), 필리핀 등 저자원 억양에서 모든 모델이 눈에 띄게 하락. 이 하락은 합성 억양보다 실제 억양 녹음에서 더 큼
내용 변이 쪽에서는 문법 오류에는 꽤 관대하지만(평균 2.68% 하락) 잘못된 발음(평균 20.34% 하락)과 정정 발화(평균 12.55% 하락)에 취약했습니다.
정정 발화의 예시가 재밌는데요, “nocebo… 아니 placebo 효과가 뭐야?”라고 물으면 모델이 nocebo를 설명해버리는 식입니다. 상담에서는 “3월… 아 아니다, 4월 청구서요”처럼 이런 정정이 정말 자주 나오죠.
4. Full-Duplex-Bench: 언제 듣고 언제 말할까?
VoiceBench가 내용 을 봤다면, 이제부터는 타이밍 입니다.
Full-Duplex-Bench(NTU, UC Berkeley 등, 2025년 3월)는 full-duplex 음성 대화 모델(Spoken Dialogue Model, SDM)의 턴테이킹 능력을 자동 지표로 측정하는 벤치마크입니다. 본 글은 2025년 3월에 공개된 첫 번째 버전(v1)을 기준으로 정리했습니다.
네 가지 평가 차원
맨 위의 그림이 바로 이 벤치마크의 네 가지 평가 차원인데요, 하나씩 보겠습니다.
- Pause Handling: 사용자가 말하다가 잠깐 멈췄을 때, 끼어들지 않고 기다리는가?
- Backchanneling: 사용자가 길게 말할 때, 적절한 타이밍에 “음”, “네” 같은 짧은 맞장구를 치는가?
- Smooth Turn Taking: 사용자의 말이 끝나면 지체 없이 턴을 넘겨받는가?
- User Interruption: 모델이 말하는 도중 사용자가 끼어들면, 이를 알아채고 새 요청에 맞게 응답하는가?
평가 방식은 단순합니다. 사용자 음성 스트림을 모델에 흘려 넣고, 모델이 동시에 생성한 음성을 받아서, 타임스탬프가 정밀한 ASR(CrisperWhisper)로 두 스트림을 시간 정렬된 transcript로 만든 뒤 지표를 계산합니다.
핵심 지표: Takeover Rate(TOR)
먼저 backchannel 을 “1초 미만이면서 두 단어 미만인 짧은 발화”로 정의합니다. 그리고 모델이 침묵하거나 backchannel만 했다면 턴을 가져가지 않은 것(TO=0), 그 외의 발화를 했다면 턴을 가져간 것(TO=1)으로 봅니다. TOR은 이를 샘플 전체에서 평균한 값입니다.
\[\mathrm{TOR} = \frac{1}{N}\sum_{i=1}^{N} \mathrm{TO}_i\]같은 TOR이라도 차원마다 바람직한 방향이 다르다는 점이 포인트입니다.
- Pause Handling, Backchanneling: 사용자가 아직 말하는 중이므로 TOR이 낮을수록 좋음
- Smooth Turn Taking, User Interruption: 모델이 턴을 받아야 하므로 TOR이 높을수록 좋음
여기에 차원별로 보조 지표가 붙습니다.
- Backchannel 빈도(Freq): 초당 backchannel 횟수
- JSD: 모델의 backchannel 타이밍 분포 $P$와 사람의 backchannel 타이밍 분포 $Q$ 사이의 Jensen-Shannon Divergence. 사람 분포는 ICC 코퍼스에서 118명의 청자가 실제로 맞장구를 친 위치를 200ms 구간으로 집계해 만듦
- Latency: 사용자의 발화가 끝난 시점(또는 끼어든 시점)부터 모델이 말을 시작하기까지의 시간
- GPT-4o Score: 끼어들기 이후 모델 응답이 끼어든 내용과 얼마나 관련 있는지를 0~5점으로 채점. 여기서도 LLM-as-a-Judge가 등장하네요
데이터는 실제 대화 코퍼스(Candor, ICC)와 GPT-4o + ChatTTS로 만든 합성 데이터(끼어들기 200개, pause 137개)를 섞어 구성했습니다.
결과: 빠르면 무례하고, 공손하면 느리다
평가 대상은 speech-to-speech 추론 파이프라인이 공개된 세 모델, dGSLM과 Moshi(end-to-end), Freeze-Omni(cascaded)입니다.
| 모델 | Pause TOR (Candor) ↓ | Backchannel JSD ↓ | Turn-taking TOR ↑ | Turn-taking Latency(s) ↓ | Interrupt GPT-4o ↑ | Interrupt Latency(s) ↓ |
|---|---|---|---|---|---|---|
| dGSLM | 0.953 | 0.950 | 0.989 | 0.572 | 0.201 | 3.972 |
| Moshi | 0.989 | 0.977 | 0.996 | 0.112 | 0.765 | 0.037 |
| Freeze-Omni | 0.287 | 0.984 | 0.369 | 1.168 | 3.371 | 1.200 |
결과를 보면 하나의 모델이 모든 걸 잘하지 못한다는 게 잘 드러납니다.
- Moshi 는 0.112초 만에 턴을 받을 정도로 반응이 빠르지만, 사용자가 잠깐 멈추기만 해도 거의 항상 끼어들고(Pause TOR 0.989), 끼어들기 이후 응답 품질은 낮음(0.765점). 논문은 Moshi가 사용자가 말하는 동안에도 속삭이듯 계속 말한다고 표현함
- Freeze-Omni 는 말하기/듣기 상태를 예측하는 별도 모듈 덕분에 pause에서 덜 끼어들고(0.287), 끼어들기 이후 응답 품질도 가장 좋음(3.371점). 대신 텍스트를 생성한 뒤 TTS를 거치는 구조라 지연이 길고(1.168초), 턴을 받아야 할 때도 받지 못하는 경우가 많음(TOR 0.369)
- dGSLM 은 backchannel 빈도와 JSD 면에서 가장 사람에 가깝지만, 끼어들기 대응은 지연 3.972초, 품질 0.201점으로 매우 나쁨
저자들은 state-control 모듈이 pause 처리에 도움이 되므로 end-to-end 모델에도 통합할 만하다고 제안합니다.
또 하나 흥미로운 점은, 모든 모델의 backchannel JSD가 0.95 이상으로 사람의 맞장구 타이밍과는 거리가 멀다는 점입니다. 적절한 타이밍에 “네”라고 하는 것 이 생각보다 어려운 문제인 셈이죠.
5. Talking Turns: 턴테이킹을 판정하는 Judge 모델
침묵은 턴 종료의 신호가 아니다
Talking Turns(CMU, Apple, ICLR 2025)는 문제 제기부터 인상적입니다.
상용 음성 비서는 대부분 일정 시간 침묵하면 말이 끝났다고 보는 silence 기반 endpointing을 쓰는데, 선행 연구에 따르면 한 사람이 말하는 도중의 침묵(pause)이 화자가 바뀔 때의 침묵(gap)보다 오히려 더 긴 경향이 있다는 겁니다.
즉 침묵 길이만으로 턴 종료를 판단하는 것은 근본적으로 한계가 있다는 거죠. 카드 번호를 불러주다 멈칫하는 고객을 떠올려 보면 바로 와닿습니다.
위 그림은 논문이 정의한 턴테이킹 이벤트입니다. 200ms 이상의 침묵으로 구분되는 연속 발화 단위인 IPU(Inter-Pausal Unit), 같은 화자의 IPU 사이 침묵인 pause, 다른 화자로 넘어가는 침묵인 gap, 그리고 겹침 발화 중에서도 끼어든 사람이 턴을 가져가는 floor-taking interruption 과 결국 원래 화자가 계속 말하는 butting-in 을 구분합니다.
코퍼스 통계의 한계
기존 연구(dGSLM)에서는 IPU, pause, gap, overlap의 분당 횟수나 누적 시간 비율 같은 코퍼스 수준 통계 를 사람 대화와 비교했습니다. 저자들도 11명의 참가자가 Moshi와 cascaded 시스템(Silero VAD + Whisper tiny + SmolLM-135M-Instruct + MeloTTS)과 각각 약 4시간씩 대화한 데이터로 이 통계를 먼저 계산했는데요.
- Cascaded 시스템은 지연이 길어 gap이 전체 대화 시간의 약 32%를 차지하고 겹침이 거의 없음
- Moshi는 gap이 11.8%로 작고 겹침 발화도 있음
여기까지만 보면 Moshi가 더 사람 같아 보입니다. 하지만 이 통계로는 그 겹침이 적절한 맞장구였는지, 무례한 끼어들기였는지 알 수 없다는 것이 저자들의 지적입니다.
해법: 턴테이킹 예측 모델을 Judge로 쓰자
그래서 저자들은 사람 간 전화 대화(Switchboard)로 턴테이킹 judge 모델 을 학습시킵니다.
- 입력: 직전 30초의 (두 화자가 섞인) 음성, Whisper encoder로 인코딩
- 출력: 다음 40ms 구간에 일어날 이벤트를 C(계속), BC(맞장구), I(끼어들기), T(턴 전환), NA(침묵) 중에서 예측. 미래를 보지 않는 causal 모델
- 성능: ROC-AUC가 in-domain Switchboard 92.0, 도메인 밖의 Columbia Games 91.5, Fisher 91.0
LLM-as-a-Judge가 사람의 선호를 대신 판정하듯, 이 모델이 “이 시점에 사람이라면 말을 시작했을까?”를 대신 판정하는 구조입니다.
이 judge로 다섯 가지 능력을 평가하는데, AI가 듣는 입장일 때 (a) 언제 말을 시작할지 (b) 언제 맞장구칠지 (c) 언제 끼어들지, AI가 말하는 입장일 때 (d) 사용자에게 말할 차례를 신호로 전달하는지 (e) 사용자의 끼어들기를 잘 처리하는지를 봅니다.
결과: 둘 다 아직 갈 길이 멀다
| 지표 | 사람 (in-domain) | Moshi | Cascaded |
|---|---|---|---|
| (a) 사용자 pause 시 AI가 말을 시작한 비율 | 15.9% | 32.7% | 37.1% |
| (b) 맞장구 비율 | 0.30% | 0.01% | 0.01% |
| (d) AI pause 시 사용자가 말을 시작한 비율 | 15.9% | 46.5% | 24.2% |
| (e) 사용자 끼어들기가 턴 전환으로 이어진 비율 | 63.6% | 17.4% | 59.4% |
- Cascaded 시스템은 사용자가 잠깐 멈추면 37.1%의 경우 말을 시작해버림. 침묵 기반 endpointing의 한계를 그대로 보여줌
- 두 시스템 모두 맞장구를 거의 치지 않음
- Moshi는 끼어들기 타이밍이 나쁨: 겹침 발화는 사람처럼 있지만, judge 기준으로 보면 사람의 끼어들기는 예측 가능하고 협력적인 반면 Moshi의 끼어들기는 예상 밖이고 무례함
- Moshi는 사용자가 끼어들어도 대부분 계속 말함: 끼어들기 중 17.4%만 턴 전환으로 이어짐. 반대로 cascaded 시스템은 사용자가 단순히 호응만 해도 절반 넘게 턴을 넘겨버림(다만 표본이 적어 신뢰구간이 넓음)
- Moshi가 말하다 멈추면 사용자가 46.5%의 경우 말을 시작함. 즉 “아직 내 말 안 끝났어요”라는 신호를 잘 못 줌
추가로 Qwen-Audio 계열, SALMONN, Whisper + GPT-4o 등이 턴테이킹 이벤트를 예측할 수 있는지도 봤는데, 맞장구와 끼어들기 예측은 모두 무작위 수준(50%) 근처에 머물렀습니다.
물론 저자들도 judge와 사람 판단의 일치도가 여러 지표에서 80% 미만이고, 사용자 연구 참가자가 주로 저자와 동료들이었다는 한계를 명시하고 있습니다.
6. AICC 관점: 상담 voicebot은 무엇을 측정해야 할까?
세 논문을 상담 voicebot의 시선으로 다시 읽어보면, 평가 항목을 크게 네 층으로 정리할 수 있을 것 같습니다.
(1) 업무 성공: 여전히 기본
tau-bench에서 본 것처럼 정책을 지키면서 고객의 요청을 끝까지 처리했는지(task success, 정책 준수, 반복 실행 시의 일관성)는 음성 채널에서도 제일 중요합니다.
다만 VoiceBench 결과가 보여주듯, 같은 모델이라도 음성 입력에서는 성능과 안전성이 크게 달라질 수 있으므로 텍스트 평가 점수를 음성 채널에 그대로 가져오면 안 됩니다. 텍스트 시나리오를 TTS로 읽혀서 동일한 평가를 돌리고, 텍스트 대비 하락폭을 따로 추적하는 것이 좋겠습니다.
(2) 인식 견고성: 전화망은 깨끗하지 않다
상담 음성은 VoiceBench의 열악한 조건에 가까운 경우가 많습니다. 좁은 대역의 전화 음질, 이동 중 통화의 패킷 손실, 차량/거리 소음, 스피커폰의 잔향, 어르신 고객의 느린 발화, 지역 방언 같은 것들이죠.
- 테스트셋을 실제 통화 녹취 기반 으로 구성하고, TTS 합성 테스트는 보조로만 사용 (합성음은 성능을 과대평가함)
- 잡음/코덱/패킷 손실을 단계별로 주입해 성능이 급락하는 임계점 을 파악 (선형으로 떨어지지 않음)
- 연령대, 방언, 말 빠르기별로 세그먼트를 나눠 성능을 리포트
- “3월, 아니 4월이요” 같은 정정 발화 와 고유명사/숫자 오인식을 별도 테스트 케이스로 관리
(3) 턴테이킹: 끼어들기와 맞장구
Full-Duplex-Bench와 Talking Turns의 지표는 상담 현장의 언어로 바꾸면 아래와 같습니다.
| 논문의 개념 | 상담 voicebot에서의 의미 | 운영 지표 예시 |
|---|---|---|
| Pause Handling (TOR ↓) | 고객이 번호를 불러주다 멈칫할 때 끊지 않기 | 조기 endpointing 비율, 고객 발화 중 봇 발화 시작 비율 |
| Smooth Turn Taking (Latency ↓) | 고객 말이 끝나면 바로 응답하기 | 발화 종료부터 첫 음성까지의 지연 p50/p95 |
| User Interruption (barge-in) | 안내 멘트 도중 고객이 말하면 멈추고 새 요청 처리 | barge-in 후 TTS 정지까지 걸린 시간, 끼어든 내용 반영률 |
| Backchannel | 고객의 “네, 네”를 끼어들기로 오인하지 않기, 긴 설명 중엔 짧게 호응하기 | 오탐 barge-in 비율 (맞장구/잡음에 멈춘 횟수) |
| (d) 턴 신호 전달 | 봇이 말을 이어갈 때 고객이 끼어들지 않게 하기 | 봇 발화 중 고객-봇 겹침 발화 비율 |
특히 한국어 상담에서는 고객이 상담사 말 중간중간 “네”, “아 네”, “예예” 하고 호응하는 경우가 매우 많습니다. 이걸 모두 barge-in으로 처리하면 봇이 계속 말을 멈추게 되고, 반대로 barge-in을 둔감하게 만들면 “아니 그게 아니고요”를 무시하게 되죠. Talking Turns에서 Moshi와 cascaded 시스템이 정확히 이 양극단을 보여준 셈입니다.
Full-Duplex-Bench도 한계로 짚었듯 턴테이킹과 맞장구의 양상은 언어와 문화마다 다르기 때문에, 영어 벤치마크 수치를 그대로 믿기보다 자사 통화 데이터로 같은 방식의 지표를 다시 계산 하는 것이 필요합니다.
(4) 프로덕션에서 무엇을 남길까
이 지표들을 운영 중에 계산하려면 로그 설계가 먼저입니다.
- 고객/봇 두 채널을 분리 녹음 하고, VAD 구간과 ASR 타임스탬프를 함께 저장
- 턴마다 고객 발화 종료, ASR 확정, LLM 첫 토큰, TTS 첫 음성 시각을 남겨 지연을 구간별로 분해
- barge-in 이벤트마다 감지/TTS 정지 시각과 이후 봇 응답을 묶어 저장하고, 응답이 끼어든 내용을 반영했는지 LLM judge로 샘플 채점
- “여보세요?”, 같은 말 반복, 상담사 연결 요청을 턴테이킹 실패의 간접 신호 로 집계
정리하면 상담 voicebot의 품질은 task success × 인식 견고성 × 턴테이킹 의 곱에 가깝고, 어느 하나가 0에 가까우면 나머지가 아무리 좋아도 고객 경험은 무너진다고 보는 게 맞을 것 같습니다.
7. 마치며
세 논문을 한 줄로 요약하면 이렇습니다.
- VoiceBench: 음성 에이전트는 깨끗한 음성이 아니라 잡음, 억양, 말더듬 앞에서 평가해야 하며, 아직은 단순한 ASR + LLM 조합이 꽤 강력한 baseline임
- Full-Duplex-Bench: pause, 맞장구, 턴 전환, 끼어들기를 TOR과 지연 중심의 자동 지표로 측정하며, 빠른 모델은 무례하고 공손한 모델은 느린 trade-off가 드러남
- Talking Turns: 침묵 길이나 코퍼스 통계로는 턴테이킹의 적절성을 알 수 없고, 사람 대화로 학습한 judge 모델로 타이밍을 평가해야 함
개인적으로 가장 와닿았던 부분은 “침묵은 턴 종료의 신호가 아니다”라는 Talking Turns의 지적이었습니다. 음성봇을 만들 때 endpointing 침묵 임계값을 몇 ms로 할지 끝없이 조정해 본 경험이 있다면, 그게 애초에 한 개의 숫자로 풀 수 없는 문제였다는 게 묘하게 위로가 되기도 하네요.
또 텍스트 채널에서 잘 동작하던 가드레일이 음성 입력에서 무력화될 수 있다는 VoiceBench의 결과는, 채널을 추가할 때마다 평가도 처음부터 다시 해야 한다는 교훈을 줍니다.
이 논문들은 모두 영어, 그리고 비교적 짧은 대화를 다루고 있어서, 실제 상담처럼 목표가 있는 긴 음성 대화에서 업무 성공과 턴테이킹을 함께 평가하는 벤치마크는 아직 비어 있는 영역입니다. 시리즈의 다음 글들에서는 tau-bench가 이후 어떻게 확장되는지, 그리고 이런 음성 평가가 에이전트 벤치마크와 어떻게 만나는지 이어서 살펴보겠습니다.
개선을 위한 여러분의 피드백과 제안을 코멘트로 공유해 주세요. 내용에 대한 지적, 혹은 질문을 환영합니다.
출처
VoiceBench: Benchmarking LLM-Based Voice Assistants (arXiv 2410.17196)
VoiceBench GitHub
Full-Duplex-Bench: A Benchmark to Evaluate Full-duplex Spoken Dialogue Models on Turn-taking Capabilities (arXiv 2503.04721)
Full-Duplex-Bench GitHub
Talking Turns: Benchmarking Audio Foundation Models on Turn-Taking Dynamics (arXiv 2503.01174, ICLR 2025)
Leave a comment