음성 에이전트의 지연 시간(Latency)은 거짓말입니다. 당신이 신경 써야 할 숫자는 끼어들기 중단율(Barge-in interrupt

지난 분기에 우리는 음성 에이전트(Voice agent)를 프로덕션 환경에 출시했습니다. p99 엔드 투 엔드 지연 시간(End-to-end latency)은 280밀리초(ms)였습니다. 우리의 가장 큰 경쟁사는 450밀리초였습니다. 모든 대시보드에서 우리가 더 빨랐습니다.

하지만 우리의 사용자 조사 패널은 우리 에이전트가 더 느리게 느껴진다고 말했습니다.

"더 느리게 느껴진다"는 격차는 5점 리커트 척도(Likert scale)에서 8퍼센트 포인트였습니다. 통계적으로 유의미한 수치였습니다. 우리는 잘못된 것을 측정하고 있었던 것입니다.

패널이 실제로 무엇을 측정하고 있었는지 파악하는 데 2주가 걸렸고, 그 후 올바른 숫자를 수정하는 데 4주가 더 걸렸습니다. 잘못된 숫자는 엔드 투 엔드 지연 시간(End-to-end latency)이었고, 올바른 숫자는 끼어들기 중단율(Barge-in interrupt rate)이었습니다.

대시보드가 거짓말을 한 이유

음성 에이전트 벤치마크(Benchmarks)는 응답 시간(Response time)을 측정합니다. ASR(자동 음성 인식)이 음성을 텍스트로 변환하고, LLM(대규모 언어 모델)이 응답을 생성하며, TTS(텍스트 음성 변환)가 이를 오디오로 변환하여 전송합니다. 이때 보고되는 것은 엔드 투 엔드 시계(End-to-end clock)입니다.

하지만 그 시계는 사용자가 경험하는 "속도"가 아닙니다.

사용자가 경험하는 것은 에이전트의 말을 끊기 시작하는 시점과 에이전트가 입을 다무는 시점 사이의 루프(Loop)입니다. 만약 사용자가 문장 중간에 "잠깐만"이라고 말했는데 에이전트가 문장을 먼저 끝내버린다면, 사용자 관점에서는 1~2초의 정지 시간이 발생하는 것입니다.

그 격차, 즉 끼어들기 지연(Barge-in delay)은 우리의 경우 380밀리초였습니다. 경쟁사의 경우 60밀리초였습니다. 사용자들은 모든 끼어들기 상황에서 그 격차를 느꼈습니다.

끼어들기 중단율(Barge-in interrupt rate)을 측정하는 방법

지표: 에이전트가 말하는 동안 사용자가 말을 시작한 시도 중, X밀리초 이내에 에이전트가 양보하는 비율은 얼마인가?

두 가지 방법이 있습니다.

합성 방식(Synthetic). 이전 고객 지원 통화에서 추출한 500개의 녹음된 끼어들기 시도 코퍼스(Corpus)를 사용합니다. 각 오디오 세그먼트를 에이전트의 복제본에 입력하고, 첫 음절부터 에이전트가 말을 멈출 때까지의 시간을 측정했습니다.

# barge_in_eval.py (simplified)
def measure_barge_in(agent, recording):
...

실제 방식(Real). 프로덕션 오디오 파이프라인(Pipeline)에 계측을 적용하여, VAD(음성 활동 감지)가 작동할 때 하나의 스팬(Span)을 생성하고 TTS가 중단될 때 또 다른 스팬을 생성하도록 했습니다. 두 스팬 모두 OTel(OpenTelemetry)로 전송됩니다. 타임스탬프(Timestamp)를 빼면 통화당 끼어들기 지연 시간(Barge-in latency)을 얻을 수 있습니다.

100ms 임계값(threshold)에서의 끼어들기 중단율(Barge-in interrupt rate)은 41%였습니다. 250ms에서는 89%였지만, 250ms는 반응성이 느껴지기에 너무 느립니다.

우리가 변경한 세 가지 사항

1. 오디오 버퍼 페이지 고정 (Pin the audio buffer pages)

우리의 에이전트는 수명이 긴 Tokio 런타임(runtime)에서 실행되었습니다. 오디오 버퍼는 힙(heap)에 할당되었으며, 모델 가중치(model weights)가 활성화될 때 가끔 스왑(swap)으로 페이징(paged)되었습니다.

use libc::{mlock, c_void};

unsafe fn pin_buffer(buf: &[u8]) -> std::io::Result<()> {
...

이 조치 이후, VAD(Voice Activity Detection)는 첫 음절 발생 후 25ms 이내에 사용자의 음성을 감지했습니다.

2. VAD 임계값 튜닝 (VAD threshold tuning)

합성 코퍼스(synthetic corpus)를 사용하여 0.4에서 0.65 사이의 값을 A/B 테스트했습니다. 0.5가 가장 좋았습니다. 0.6일 때보다 감지 속도가 4% 빨라졌으며, 오탐(false positive)은 1.2%만 증가했습니다.

3. TTS 중단 경로 (TTS interrupt path)

결정적인 원인이었습니다. 우리의 TTS는 200ms 청크(chunk) 단위로 오디오를 스트리밍했습니다. VAD가 작동했을 때, 오디오 큐(queue)에는 여전히 400ms 분량의 버퍼링된 오디오가 남아 있어 끝까지 재생되었습니다. 사용자는 에이전트가 침묵하기 전 문장의 파편을 끝까지 말하는 것을 들어야 했습니다.

async fn handle_barge_in(state: &mut AgentState) {
    state.llm_handle.cancel();
    state.tts_queue.clear();
...

우리는 청크 크기를 30ms로 줄였고, VAD가 작동하는 즉시 큐를 비웠습니다(flush).

결과

4주간의 작업 결과, 100ms 임계값에서의 끼어들기 중단율(Barge-in interrupt rate)이 41%에서 89%로 개선되었습니다. "더 느리게 느껴지는" 격차는 한 번의 사용자 조사 주기(user research cycle) 내에 해소되었습니다.

더 작은 TTS 청크로 인해 실제 p99 지연 시간(latency)은 약간 상승했습니다(280ms에서 305ms로). 대시보드 수치는 나빠졌습니다. 하지만 사용자가 느끼는 수치는 극적으로 좋아졌습니다.

중요한 숫자

음성 에이전트의 지연 시간(latency)은 대시보드상의 숫자입니다. 끼어들기 중단율(Barge-in interrupt rate)은 사용자의 숫자입니다.

제가 대화해 본 대부분의 음성 에이전트 팀은 끼어들기 중단율을 측정하지 않습니다. 그들은 엔드 투 엔드 지연 시간(end-to-end latency)을 측정하고, 수치가 낮게 나오면 제품을 출시합니다. 그러고 나면 사용자들은 "당신의 에이전트는 형편없다"라고 말하고, 팀은 대시보드가 말하는 것과 사용자가 말하는 것 사이의 간극을 메우지 못합니다.

그 간극을 메울 수 있는 것이 바로 당신이 추적하지 않고 있는 지표입니다.

내가 여전히 튜닝 중인 것

8개월이 지난 지금, 나는 사용자 조사 패널(user research panel)보다 대시보드(dashboard)를 더 신뢰하는 것을 그만두었습니다. 대시보드는 정답이 되고 싶어 하지만, 패널은 그저 사실일 뿐입니다.

끼어들기 임계값(barge-in threshold) 자체는 내가 가장 확신하지 못하는 부분입니다. 우리의 목표는 100ms입니다. 경쟁사의 목표는 60ms입니다. 60ms가 우리가 서비스하는 사용자들에게 100ms보다 유의미한 UX 차이(delta)를 제공하는지는 아직 진심으로 알 수 없습니다.

의도적인 중단과 채우기용(filler) 중단을 구분하는 것이 다음으로 명확한 영역입니다. "잠시만요(wait)"라는 말에 양보하는 것은 맞습니다. "음(mhm)"이라는 말에 양보하는 것은 틀립니다. 우리는 현재 이 둘을 동일하게 취급하고 있습니다.

그리고 '느리게 느껴지는 정도(felt-slower)' 측정은 내가 가장 취약하다고 인지하고 있는 부분입니다. 우리가 가진 최선은 5점 리커트 척도(5-point Likert)이지만, 이것도 훌륭하지는 않습니다. 만약 누군가 엄격한 음성 에이전트 UX 연구를 수행하고 있다면, 그 방법론은 대시보드가 제공하는 그 어떤 것보다 나에게 더 유용할 것입니다.