지연 시간은 예산이다. 목표는 인간다움이다.

URL: https://www.youtube.com/watch?v=j4AmIK6OvHc 날짜: 2026-10-11 채널: aiDotEngineer

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==음성 에이전트의 목표는 단순히 가장 빠른 모델을 고르는 것이 아니라, 제한된 지연 시간 예산 안에서 사람처럼 듣고 말하고 행동하는 전체 시스템을 만드는 것이다.==

• 백그라운드 에이전트의 10초 지연은 대수롭지 않지만, 실시간 음성 대화에서의 침묵과 끼어들기 실패는 즉시 부자연스러움을 만든다.
• STT·LLM·TTS 각각의 리더보드 점수는 실제 사용자가 겪는 파이프라인 전체의 품질과 다르다.
• 측정 지연이 아니라 사용자가 실제로 듣는 첫 오디오까지의 지연을 재고, 1초를 넘는 작업은 대화와 분리해 비동기로 실행해야 한다.

실시간 음성 에이전트는 스피커를 붙인 챗봇이 아니라 사람처럼 감지하고 반응하는 실시간 시스템이다. 핵심은 약 1.5초의 종단간 창(window) 안에 전체 파이프라인을 맞추는 것이며, 600밀리초에 가까워질수록 대화가 인간적으로 느껴진다. 남은 예산은 의미 이해와 대화 품질에 쓰고, 사용자가 기다리는 동안에는 에이전트가 계속 듣고 말하면서 도구 작업을 수행해야 한다.

1. 속도가 아니라 인간다운 상호작용이 목표다

속도만 줄이는 최적화로는 듣기·턴테이킹·변경 대응이라는 인간다운 특성을 만들 수 없다.

1.1. 백그라운드 에이전트와 실시간 에이전트의 차이

1. 지연 시간을 기다릴 수 있는 작업

   1. 코드를 작성하거나 리서치를 수행하는 백그라운드 에이전트는 작업을 맡긴 뒤 사용자가 자리를 비울 수 있다.
   2. 사용자는 돌아왔을 때 결과만 확인하면 되므로 10초, 심지어 10분의 추가 지연도 대화 품질을 무너뜨리지 않는다.

2. 침묵이 곧 실패가 되는 작업

   1. 약국 처방전 리필, 항공사 문의, 자동차 대리점 전화처럼 사람은 이미 실시간 음성 에이전트와 통화하고 있다.
   2. 통화 중 사용자가 AI의 말을 덮어 말하면 음성 에이전트가 무너지는 경우가 많다. 사람에게는 가장 자연스러운 행동인 끼어들기가 시스템에는 예외 상황이 되기 때문이다.
   3. 업계의 흔한 처방은 더 빠른 모델, 더 낮은 지연, 100밀리초 추가 단축이지만, 이것만으로는 자연스러운 상호작용을 얻을 수 없다.

1.2. 인간다운 음성 에이전트가 해야 할 일

1. 듣는 동안 말하기

   1. 말하면서도 상대방의 음성을 계속 듣고, 상대가 생각을 끝낸 것인지 아직 말을 고르는 중인지 구분해야 한다.
   2. 사용자가 중간에 생각을 바꾸면 기존 계획을 고집하지 않고 새로운 의도에 맞춰 자연스럽게 진행해야 한다.

2. 모델과 파이프라인의 공동 설계

   1. 속도 하나만으로는 위 능력에 도달할 수 없다.
   2. 어떤 모델을 선택하고 파이프라인을 어떻게 구성하는지가 결과를 결정하지만, 모델 선택법을 알려주는 리더보드나 공급업체는 충분한 답을 주지 않는다.

2. 음성 파이프라인은 세 모델의 연쇄다

음성 에이전트는 여러 모델이 한 시스템으로 협력하는 cascade이며, 개별 부품의 순위가 전체 대화의 순위를 보장하지 않는다.

2.1. 세 개의 기본 슬롯과 늘어나는 선택지

1. 기본 구성

   1. 음성-텍스트 변환(Speech-to-Text, STT)이 사용자의 말을 텍스트로 바꾼다.
   2. 대규모 언어 모델(Large Language Model, LLM)이 의도를 해석하고 답변·행동을 결정한다.
   3. 텍스트-음성 변환(Text-to-Speech, TTS)이 답변을 실제 음성으로 만든다.

2. 실시간 모델의 추가

   1. 여러 기능을 한 모델이 처리하는 real-time model도 빠르게 좋아지고 있지만 모든 용도에 맞는 것은 아니다.
   2. 실시간 모델까지 선택지에 들어오면서 수백 개 모델, 수십 개 제공업체 중 어떤 조합을 쓸지 결정하는 문제는 더 복잡해진다.

2.2. 리더보드 함정(leaderboard trap)

1. 부품 점수와 실제 스택의 불일치

   1. 리더보드는 STT·LLM·TTS 같은 구성요소를 각각 채점하지만, 개발자가 배포하는 것은 이들을 연결한 대화 파이프라인이다.
   2. 따라서 “최고의 STT, LLM, TTS가 무엇인가?”와 “어떤 스택을 배포해야 하는가?”는 전혀 다른 질문이다.

2. 예약 날짜 오류 사례

   1. 사용자가 “화요일 3일(Tuesday the 3rd)”에 예약해 달라고 말했는데 STT가 “화요일 30일(Tuesday the 30th)”로 인식할 수 있다.
   2. 그 순간부터 LLM이 아무리 똑똑해도 틀린 날짜를 자신 있게 예약한다.
   3. 첫 오류는 아래 계층으로 계속 흘러가며, LLM·TTS는 앞 단계에서 잘못 들었다는 사실을 알 방법이 없다.

3. 현실의 소음

   1. 리더보드 점수는 조용한 방의 깨끗한 오디오로 산출된다.
   2. 실제 사용자는 스피커폰, 교통 소음, 뒷좌석의 아이들이 있는 차 안에서 전화한다.
   3. 조용한 실험실 리더보드는 사용자를 한 번도 만나지 않았으므로, 부품 점수만 보고 스택을 고르면 현실에서 놀라운 실패를 맞는다.

3. 대시보드의 지연과 사용자가 듣는 지연은 다르다

측정 지연(measured latency)이 아니라 지각 지연(perceived latency), 즉 사용자가 실제로 첫 소리를 듣기까지의 시간이 대화 경험을 결정한다.

3.1. TTS의 첫 바이트 함정

1. Time to First Byte의 한계

   1. TTS 공급업체는 time to first byte를 대시보드에 보여주며 수치가 매우 빠르게 보이게 한다.
   2. 그러나 바이트는 소리가 아니다.

2. 침묵을 포함한 첫 오디오

   1. 여러 인기 공급업체를 측정한 결과, 실제 오디오 앞에 수백 밀리초의 침묵이 붙어 있었다.
   2. 최악의 경우 첫 음성이 나오기 전에 최대 0.75초가 아무 소리도 없이 흘렀다.
   3. 호출자가 경험하는 지표는 time to first byte가 아니라 time to first audio여야 한다. 대시보드가 빠르다고 말해도 귀는 느리다고 판단할 수 있다.

3.2. LLM의 첫 토큰 함정

1. 토큰과 문장의 차이

   1. time to first token은 텍스트 모델의 지표다.
   2. TTS는 토큰 하나가 도착하자마자 자연스럽게 말할 수 없고, 보통 첫 번째 완전한 문장이 필요하다.

2. 실제 순위의 역전

   1. 토큰을 가장 빠르게 스트리밍하는 모델이 첫 문장을 가장 빨리 완성하는 모델이라는 보장은 없다.
   2. 음성 파이프라인은 토큰 속도보다 첫 완전 문장과 첫 가청 음성의 시점을 측정해야 한다.

4. 도구 호출은 비동기로 분리하고 대화를 계속 이어가라

에이전트가 실제 업무를 수행할 때는 모델 속도보다 도구 작업의 지연이 훨씬 커질 수 있으므로, 작업 중에도 대화를 멈추지 않는 구조가 필요하다.

4.1. 도구가 만드는 긴 지연

1. 실제 에이전트의 업무

   1. 주문을 조회하고, 재고나 이용 가능 여부를 확인하고, 객실을 예약하는 일은 단순히 답변을 생성하는 일이 아니다.
   2. 도구 호출은 2초, 10초, 40초 이상 걸릴 수 있다.

2. 모델 교체로 숨길 수 없는 지연

   1. 아무리 빠른 모델을 골라도 40초 이상의 백엔드 지연을 감출 수는 없다.
   2. 인간 접수원은 예약 시스템이 로딩되는 동안 얼어붙지 않는다. “잠시만요, 계정을 조회하고 있어요”라고 말하며 시간을 벌고 계속 상대방의 말을 듣는다.

4.2. 대화 스레드와 도구 스레드 분리

1. 비동기 도구 호출의 핵심

   1. 일반 도구 호출 코드에서 첫 번째 업데이트가 마이크를 에이전트에게 돌려준다.
   2. 도구는 백그라운드에서 계속 실행하고, 에이전트는 그 결과를 기다리는 동안 대화의 흐름을 유지한다.

2. 구조적 효과

   1. 대화와 도구가 같은 스레드를 공유하지 않게 된다.
   2. 사용자는 로딩 침묵을 듣지 않고, 에이전트는 필요한 작업을 수행하면서 듣고 말할 수 있다.

4.3. 호텔 예약 시연에서 확인된 동작

1. 초기 예약

   1. Live Oak Hotel의 접수원이 전화를 받으며 객실 예약 날짜와 투숙 인원을 묻는다.
   2. 호출자는 10월 10일부터 12일까지, 두 명이라고 답한다.
   3. 에이전트는 퀸 침대 두 개, 킹, 더블, 퀸, 스위트룸을 제시하고 도시 전망인지 바다 전망인지 묻는다.
   4. 호출자가 바다 전망을 고르자 예약자 이름을 묻고, Jesse Hall 명의로 처리한다.
   5. 킹룸·바다 전망·10월 10~12일·카드 끝 네 자리 1111·총액 582.40달러를 확인한 뒤 진행할지 묻는다.

2. 통화 중 변경

   1. 호출자는 갑자기 날짜를 12월 20일부터 24일까지로 바꿔야 한다고 말한다.
   2. 에이전트는 새 날짜를 되짚고 총액이 1,164.80달러로 바뀐다고 말한 뒤 다시 진행 여부를 묻는다.
   3. 호출자가 동의하자 예약을 완료한다.

3. 인간다운 이유

   1. 시연에서는 시간 제약 때문에 일부 구간이 빨라졌지만, 에이전트는 어색한 공백 없이 대화를 이어갔다.
   2. 호출자가 말을 끊어도 흐름이 깨지지 않았고, 호출자가 중간에 마음을 바꿔도 에이전트는 자연스럽게 새 요청에 맞췄다.
   3. 이 결과는 단일 모델의 능력이 아니라 인프라·프레임워크·모델이 함께 만든 시스템의 능력이다.

5. 턴테이킹은 음성 자체로 판단해야 한다

사람은 주로 말투만으로 수백 밀리초 안에 발화 순서를 협상하므로, 전체 자막이 끝날 때까지 기다리는 파이프라인은 이미 늦다.

5.1. 오디오 기반 턴 감지

1. 사람의 신호

   1. 억양, 음의 높낮이(pitch), 말의 인토네이션과 운율을 통해 상대가 발화를 끝냈는지 판단한다.
   2. 완성된 transcript가 도착한 뒤에야 판단하면 실제 대화의 타이밍을 놓친다.

2. LiveKit의 턴 감지기

   1. 음성 자체에서 신호를 듣는 end-of-turn detector를 구축했다.
   2. 같은 지연 예산에서 가장 좋은 대안은 사용자의 말을 9.9% 잘못 끊었지만, 이 방식은 4.5%로 낮췄다.
   3. 평가 하네스는 오픈소스로 공개되어 있으므로 특정 주장을 믿지 않고 자신의 데이터를 넣어 결과를 재현할 수 있다.

5.2. 마지막 음절에서 첫 음성까지의 창

1. 겹쳐 실행되는 단계

   1. end-of-turn 감지는 transcript가 도착하기 전에 오디오에서 먼저 발화 종료를 감지한다.
   2. LLM은 provisional transcript로 이미 실행을 시작한다.
   3. 최종 단어가 잠정 인식 결과와 일치하면 약 0.5초를 절약한다.
   4. TTS는 마지막 토큰이 아니라 첫 번째 완전한 문장이 준비되는 즉시 시작한다.

2. 사용자가 기다림을 멈추는 순간

   1. 마지막 음절과 에이전트의 첫 가청 음성 사이의 간격이 사용자가 실제로 기다리는 시간이다.
   2. 모든 모델 선택은 이 고정된 크기의 창 안에 나타난다.
   3. 종단간 시간이 1.5초 이내면 대화가 유지되지만, 그 지점은 한계선이다.
   4. 약 600밀리초에 가까워지면 상호작용이 정말 인간적으로 느껴진다.

3. 최적화 질문의 전환

   1. 질문은 “얼마나 빨리 만들 수 있는가?”가 아니다.
   2. “이 창 안에 넣을 수 있는 가장 인간다운 에이전트는 무엇인가?”가 올바른 질문이다.
   3. 지연 시간은 예산이며, 인간다움이 목표다.

6. 구성요소가 아닌 완성된 에이전트를 벤치마크하라

모델 선택 문제를 해결하려면 부품을 따로 점수 매기지 말고 실제 업무를 수행하는 에이전트 전체를 동일한 조건에서 비교해야 한다.

6.1. 실제 백엔드가 있는 시뮬레이션

1. 완성된 호텔 접수원

   1. 첫 번째 기준 에이전트는 방금 들은 호텔 접수원이며, 실제 예약을 처리하고 실제 백엔드를 사용한다.
   2. 에이전트와 벤치마크 구현은 모두 오픈소스라서 저장소를 직접 확인할 수 있다.

2. 현실적인 호출자 시뮬레이터

   1. 수백 명의 시뮬레이션 호출자를 에이전트에 연결한다.
   2. 시뮬레이터는 실제 호출자처럼 말을 끊고, 중얼거리고, 중간에 마음을 바꾼다.
   3. 평가 대상은 막연한 “느낌”이 아니라 사람에게 요구할 법한 결과와 행동이다.

6.2. 성공과 실패를 함께 채점하는 기준

1. 결과의 정확성

   1. 올바른 예약이 데이터베이스에 기록됐는지 확인한다.
   2. 호출자가 말을 끝내기 전에 끊었는지, 이름과 날짜가 정확한지 확인한다.
   3. 존재하지 않는 도구 호출을 만들어냈는지, 개인정보를 유출했는지도 검사한다.

2. 완료 점수의 허점 보정

   1. 완료만으로는 충분하지 않다. 모델은 우연히 추측해서 완료 점수를 얻을 수 있다.
   2. 필요하지 않은 질문을 했거나, 두 단계면 될 일을 열 단계로 처리했다면 완료 결과가 맞아도 감점한다.
   3. 성공 결과뿐 아니라 사람이라면 보이지 않았을 불필요한 행동과 비효율까지 벌점에 포함한다.

3. 공정한 모델 교체

   1. 같은 에이전트와 같은 시나리오를 유지한 채 모델 스택만 교체한다.
   2. 모든 모델에는 바이트 단위로 완전히 동일한 입력을 제공한다.
   3. 에이전트가 달라질 때마다 그 에이전트에 맞는 벤치마크가 생긴다. 따라서 벤치마크는 추상적인 하나의 표가 아니라 각 개발자가 자신의 에이전트에 대해 실행하는 것이다.

6.3. 공개 방법론과 LiveKit의 중립성

1. 재현 가능한 평가

   1. 방법론, 평가 세트, 기준 에이전트가 모두 공개되어 있다.
   2. 같은 평가를 자신의 에이전트에 적용하고 성능을 비교한 뒤 결과를 공유할 수 있다.

2. 모델을 직접 만들지 않는 위치

   1. LiveKit은 STT·LLM·TTS 모델을 직접 만들지 않는다.
   2. 모든 공급업체가 스택에 연결되므로 특정 모델을 밀어야 할 이해관계가 없다.
   3. 다양한 모델을 대량으로 실행하며 관찰하기 때문에 실제 음성 파이프라인에서 승자를 자신 있게 고를 수 있다.

7. 사례로 제시된 고품질 음성 LLM

실제 음성 평가와 지연 예산을 함께 적용하면 모델의 명목상 속도보다 생산 환경에 맞춘 튜닝과 전체 대화 성능이 중요해진다.

7.1. LiveKit Inference의 Gemma 4 31B

1. 생산 환경 맞춤 튜닝

   1. LiveKit Inference에서 공개될 Gemma 4 31B가 사례로 소개됐다.
   2. 일반적인 오프더셸프 Gemma 4 31B를 그대로 제공하는 것이 아니라, 긴 프롬프트·많은 도구·빡빡한 지연 예산을 가진 생산 음성 에이전트에 맞게 조정했다.

2. 평가와 속도

   1. 음성 평가를 88% 통과한다.
   2. 약 380밀리초 만에 말하기 시작한다.
   3. 다음 모델보다 두 배 이상 빠르며, 고품질 음성 LLM 가운데 실제로 가장 빠른 모델이라고 소개됐다.
   4. LiveKit Inference에 다음 날 출시될 예정이라고 발표됐다.

주요 발언 모음

“Latency is a budget, and humanlike is the goal.”

“속도만으로는 인간다운 에이전트에 도달할 수 없다. 어떤 모델을 고르고 파이프라인을 어떻게 구성하는지가 그곳으로 데려간다.”

“바이트는 소리가 아니다.”

“질문은 얼마나 빨리 갈 수 있느냐가 아니라, 이 창 안에 넣을 수 있는 가장 인간다운 에이전트가 무엇이냐이다.”

“음성 에이전트는 스피커를 얹은 챗봇이 아니다. 인간다운 인프라다.”

“대화를 멈추지 않도록 1초를 넘는 작업은 비동기로 처리하라.”

핵심 데이터 & 수치

• 기본 파이프라인: STT·LLM·TTS 세 모델 슬롯이 협력하며 real-time model은 추가 선택지를 만든다.
• 현실의 도구 지연: 주문·재고·예약 도구는 2초, 10초, 40초 이상 걸릴 수 있다.
• TTS 침묵: 일부 인기 공급업체는 첫 오디오 전에 수백 밀리초의 침묵을 보내며, 최악의 경우 최대 0.75초다.
• 턴 감지 오류율: 같은 지연 예산에서 최선의 대안은 9.9%의 끼어들기 오류를 냈고, 오디오 기반 방식은 4.5%였다.
• 잠정 transcript 최적화: 최종 단어가 일치하면 약 0.5초를 절약한다.
• 대화 유지선: 종단간 지연 1.5초 이내면 대화가 유지되지만 한계에 가깝다.
• 인간다움의 기준점: 약 600밀리초에 가까워질수록 대화가 정말 인간적으로 느껴진다.
• Gemma 4 31B 사례: 음성 평가 통과율 88%, 발화 시작 약 380밀리초, 다음 모델보다 2배 이상 빠르다.
• 호텔 예약 금액: 10월 10~12일 킹룸·바다 전망은 582.40달러였고, 12월 20~24일로 바꾸자 1,164.80달러가 됐다.

결론 및 시사점

1. 먼저 예산을 정하라: 모델을 고르기 전에 허용 가능한 종단간 지연 예산을 정한다.
2. 사용자가 듣는 시간을 재라: time to first byte나 time to first token 대신 마지막 음절부터 첫 가청 오디오까지의 perceived latency를 측정한다.
3. 남은 예산은 품질에 투자하라: 의미 이해와 자연스러운 대화를 개선하는 데 예산을 쓰며, 실제로 체감되지 않는 명목상 속도에는 집착하지 않는다.
4. 긴 작업은 비동기로 바꿔라: 1초를 넘는 도구 호출은 대화 스레드와 분리하고, 에이전트가 계속 듣고 말하게 한다.
5. 턴테이킹을 오디오로 판단하라: 완성된 transcript를 기다리지 말고 억양·피치·인토네이션에서 발화 종료를 감지한다.
6. 부품 대신 대화를 테스트하라: 동일한 입력과 시나리오로 실제 에이전트를 평가하고, 예약 정확성·중단·개인정보·도구 호출·불필요한 단계를 모두 채점한다.
7. 운영 환경에서 계속 검증하라: 오픈소스 벤치마크로 배포 전 평가를 수행한 뒤, 실제 프로덕션에서도 지속적으로 테스트한다.
8. 최종 기준을 바꿔라: 음성 에이전트를 스피커가 달린 챗봇으로 다루지 말고, 사람처럼 감지하고 반응하는 인간다운 실시간 인프라로 설계한다.