Eleven v4의 '100ms'는 대화 대기 시간이 아니다: 음성 AI의 3가지 함정 및 오늘 측정해야 할 응답 시간

게임 NPC나 음성 안내를 '100ms 음성 AI'로 만들려고 한다면, 그 시계가 어디서 움직이기 시작하는지 확인해 보길 바란다.

90개 이상의 언어. 블라인드 비교에서 약 75%의 선호도. 추론 시간은 중앙값으로 약 100ms.

• 90개 이상의 언어는 Eleven v4와 v4 Turbo가 지원하는 범위이다. - **약 75%**는 일반 버전 v4의 자연스러움 및 표현력을 질문한 비교에서, 동점으로 간주된 반승으로 계산한 선호도 수치이다.
• 약 100ms는 Turbo 버전의 추론 시간 중앙값이다.

이것이 ElevenLabs가 2026년 9월 28일에 발표한 음성 모델, Eleven v4 패밀리다. 더빙, 게임 캐릭터, 읽기 및 대화 모두를 목표로 한다.

하지만 같은 발표에는 또 다른 수치가 있다. Turbo의 '첫 발성까지'는 약 150ms이다. 그리고 각주에는 다음과 같이 적혀 있다.

network latency measured and removed for all systems.

네트워크를 제외한 150ms를, 사용자가 말을 마친 후 답변이 들릴 때까지의 150ms로 바꿔서는 안 된다.

발성 처리 속도와 그 전에 쌓이는 대기 시간을 무대로 비유한 생성 일러스트. 실제 기기나 측정 결과를 그린 것이 아니다.

정보 확인일은 2026년 10월 6일이다. 발표는 9월 28일, 참조한 발표 페이지의 최종 업데이트는 10월 5일이다. 성능, 지원 언어, 사양 수치는 ElevenLabs의 1차 자료를 따른다. 본 기사에서 음성 생성 API나 한국어의 품질 및 지연 시간을 실측한 것은 아니다. 후술하는 1000ms 예시는 가상의 계산 예시이며, 연결 코드는 미실행이다.

릴리스 안내, 모델 목록, WebSocket 비교 사양을 대조했다. 아래는 필자가 2026년 10월 6일 공개 정보로부터 구성한 표다.

여기까지는 '빠르고 표정이 풍부한 목소리'에 대한 이야기다. 재미있는 것은 그 너머이다.

목소리가 빠르게 나올 수 있다는 것과, 답변이 빠르다는 것 사이에는 아직 할 일이 남아있다.

예를 들어, 플레이어가 NPC에게 '다음은 어디로 가면 돼?'라고 말을 건넨다고 가정해 보자.

시스템은 발화가 끝났다고 판단하고, 단어를 인식하며, 게임 상태로부터 답변을 생성하고, 말할 수 있는 단위의 텍스트를 모으고, 음성을 생성하여, 단말기에서 재생한다. 미리 읽어주거나 병렬 처리는 가능하지만, TTS만 교체해서 모든 과정을 교체한 것은 아니다.

공식 지연 시간 설명도 추론 시간과 사용자 측에서 첫 소리가 나는 시간으로 나누고, 네트워크, 서버 처리, 재생 버퍼, LLM을 포함하는 앱의 처리를 언급하고 있다.

여기서 150 - 100 = 50ms

을 계산하여 '통신 외 오버헤드는 50ms'라고 확정하고 싶어진다. 정말 그럴까?

측정 대상과 집계 방법을 맞춘 동일 시행의 내역이 필요하다. 애초에, 별도로 집계된 중앙값의 차이는 각 시행의 차이의 중앙값이 아닐 수 있다. 공개 값에서 알 수 있는 것은 지표가 다르다는 점까지이다.

다음은 작동 원리를 이해하기 위한 가상의 요청입니다. 각 공정이 겹치지 않고 진행되며, 단위를 ms로 통일했습니다. 제품의 벤치마크는 아닙니다.

# 가상 값 계산 예시. 계산만 실행 확인됨.
parts = {
"발화 종료 판정 및 인식 잔여": 300,
...

합성(Synthesis)은 2배속입니다. 사용자 대기 시간은 1000ms에서 950ms로 단축되었습니다. 단축률은 5%입니다.

반대로, 이 예시에서 입력 대기 시간을 120ms 줄일 수 있다면, 합성(Synthesis)을 50ms 줄이는 것보다 더 큰 효과를 가져옵니다. 어느 부분에 투자해야 할지는 모델의 홍보 값이 아니라, 자신의 처리 내역으로 결정됩니다.

실제 시스템에서는 음성 인식(ASR), 텍스트 생성(NLG), 합성(TTS)이 중첩되므로, 위의 합산 값을 각 공정의 중앙값에 적용하지 않고, 동일한 요청 시각을 기록해야 합니다. 최초 음성 수신 로그를 기록한다면, 생각 방식은 다음과 같습니다.

# 측정 위치를 나타내는 가상 코드. 미실행.
t0 = 사용자 음성이 끝난 시각
t1 = 첫 응답 텍스트를 TTS로 전송하기 직전
...

같은 시계로 측정할지, 장치 간의 시계를 동기화해야 합니다. play()를 호출한 시각이 스피커에서 소리가 나온 시각과 같지는 않습니다. 게다가, 보낼 문장・목소리・지역・출력 형식을 통일하고, 성공 건수와 오류 건수를 남긴 후, 중앙값(median)과 p95를 각각 확인해야 합니다. p95는 95%의 시도가 그 시간 이내에 포함되는 경계입니다.

당신의 앱에서 가장 오래 걸리는 것이 응답 문장을 만드는 시간, 입력 대기 시간, 재생 버퍼 중 무엇이라고 생각하십니까? 여러분의 예상도 댓글로 알려주세요.

공개 자료만으로는 일본어의 특정 목소리・회선・단말에서의 응답 대기 시간을 확정할 수 없습니다.

완성된 스크립트와 생성 중인 응답을 나누어 테스트합니다. 이 차이만으로도, 음성 작품과 대화 앱에서 원하는 특성이 달라집니다.

아래는 공식 요청 형식을 기반으로 한 미실행 예시입니다. 자신의 API 키와 사용 가능한 음성 ID를 사용해야 합니다. 실행하면 계약에 따른 크레딧을 소모합니다.

게임 이벤트 대화나 학습 교재라면, 먼저 목소리 연기를 확인하고 싶습니다. Create dialogue의 예시를 기반으로 모델을 명시하여 파일로 저장합니다.

# 미실행. ELEVENLABS_API_KEY가 설정된 단말에서 사용.
# voice_id는 자신의 계정에서 사용할 음성으로 대체해야 함.
curl --fail-with-body --silent --show-error \
...

공식 예시와 같은 짧은 영어 대화를 출발점으로 삼아, 직접 만든 일본어 스크립트로 대체하고 고유명사와 연기 지시를 비교합니다. 이것은 음성 제작의 청취이며, 대화 지연 측정은 아닙니다.

실시간 대화 공식 가이드의 연결・등록・전송 절차에 수신 시각 기록을 추가합니다. 아래를 probe.py로 저장해야 합니다.

なお、TTDのAPIリファレンスにはv3のみとする記述も残るため、v4 Turboの対応経路は、それを明記するモデル一覧と実装ガイドで照合した。

# 미실행. 공식 가이드의 의존 패키지.
python -m pip install python-dotenv websockets

# 공식 가이드를 기반으로 한 측정용 수정 예시. API 연결은 미실행.
import asyncio
import base64
...

# 미실행. API 키와 자신의 음성 ID를 환경 변수 또는 .env에 설정하여 사용.
python probe.py

이 측정은 연결 확립 후부터 시작됩니다. 통신을 포함하며, 재생은 포함하지 않습니다. 파일을 마지막에 저장하므로, 표시 값을 '귀에 도달하는 시간'이라고 명명해서는 안 됩니다. 초기화 후 첫 전송일 수도 있고, 장시간 연결을 재사용했을 때의 정상 값과도 구분해야 합니다.

게임 응답을 한 단어씩 흘려보내는 것이 가장 빠할까요? 정말 그럴까요?

대화용 WebSocket 버퍼 사양에서는 일정 문자 수와 어구 수에 도달할 때까지 입력을 축적합니다. 대략 40자 및 8어가 기준입니다. 짧은 응답을 보낸 후 아무것도 하지 않으면, 모델 계산 이전에 대기 시간이 발생할 수 있습니다.

게다가, 기존 TTS용 chunk_length_schedule를 조정하는 방식이 아닙니다. 일본어에서 '8어'를 어떻게 구분할지도 이 설명만으로는 단정하기 어렵습니다.

대책: 의미가 확정된 짧은 응답은 {"flush": true}를 보내서 생성을 촉진해야 합니다.

연결을 종료할 때는 위의 단발 예시처럼 close_socket으로 나머지를 흘려보냅니다. 지속적인 대화에서 매번 끊을 필요는 없습니다. 반면, 도중에 확정하는 단위를 너무 세분화하면, 억양에 사용할 다음 문맥이 줄어듭니다. 짧은 글・긴 글 모두 들어보고 결정해야 합니다.

공식 프로토콜 비교에는 연결 목적지의 차이가 명시되어 있습니다.

Flash 계열: /v1/text-to-speech/{voice_id}/stream-input
v4 계열: /v1/text-to-dialogue/stream-input

전자는 URL로 목소리를 고정하고 text를 전송한다. 후자는 처음에 voices를 등록한 뒤, 이후에는 inputs 배열로 전송한다. 응답의 종단 필드를 포함하여 같은 통신 계약이 아니다.

대책: 모델명・URL・초기 메시지・본문의 형태를 함께 변경하는 것.

게다가 HTTP 버전 API 사양에서는 model_id의 기본값이 참조 시점 기준으로 eleven_v3이다. '최신 모델을 호출했다고 생각'하는 것을 피하기 위해, v4는 명시한다.

기존 TTS용 WebSocket의 감각으로, 게임에 등장하는 NPC 전원의 연결을 열어두면 다른 제약에 해당된다.

Text to Dialogue 동시 실행 사양에서는, 연결이 열려 있는 동안 별 풀(pool)의 대화 세션을 1개 유지한다. 생성하지 않는 시간도 대상이다. 자원을 다 사용한 상태에서의 신규 연결은 too_many_concurrent_requests로 거부된다.

대책: 실제로 대화하는 단위로 연결을 관리하고, 불필요한 연결을 닫는 것.

20초의 무통신 단절을 막는 keep_alive는 자원을 해제하라는 명령이 아니다. 살리는 연결과 닫는 연결을 분리할 필요가 있다.

타사의 '최속' 수치를 섞은 랭킹은 만들 수 없다. 시작점도 끝점도 다르다면, 숫자의 크기만 독주하게 된다.

여기서는 10월 6일에 읽은 모델 설명, 지연 최적화 가이드, 프로토콜 사양에서 같은 서비스 내의 3개 경로를 비교한다.

| 선택지 | 처음 시도할 용도 | 공개된 속도 지표 | 구현에서 나뉘는 점 |
|---|---|---|
| Eleven v4 | 대본이 있는 주고받음, 교재, 더빙 | 이 비교에서는 Turbo의 100ms를 유용하지 않다 | HTTP의 Text to Dialogue. 대화 WS에서는 최대 10개 음성 |
| Eleven v4 Turbo | NPC의 즉시 응답, 음성 안내 | 추론 중앙값 약 100ms / 발성 시작 약 150ms는 별도 지표 | Text to Dialogue WS, 등록은 1개 음성, 연결별 세션 |
| Eleven Flash v2.5 | 기존 단일 화자 스트리밍의 비교 기준 | 약 75ms는 모델 추론만 | TTS용 WS. 청크 제어와 동시 실행 개수 계산이 다르다 |

표에서 읽을 수 있는 것:

• 75ms 대 100ms만으로는, 대화의 승자가 결정되지 않는다. 같은 대사를 같은 단말기로 재생했을 때의 대기 시간이 필요하다. -
  복수 인물의 대본과, 1인의 즉시 응답은 다른 선택이다. Turbo의 'Dialogue'라는 이름에서, 1개 연결로 몇 명이라도 말할 수 있다고 읽지 마라.
• 실시간 생성이 불필요한 대사는 미리 제작해 둘 수 있다. 고정된 이벤트 대화라면, 재생 시 합성 대기 자체를 제외할 수 있는 설계상의 선택지가 있다.

연결 수가 선택을 좌우하기 때문에, 공개된 대화 WS의 한도도 뽑아낸다. 이것은 요금표가 아니라, 워크스페이스의 세션 상한이다.

{
"interactive_voice": {
"model_id": "eleven_v4_turbo",
...
}

✗ "100ms면 응답도 100ms" → 발화 종료 판정, 응답 생성, 통신, 재생은 별도로 남는다
✗ "150ms와의 차이 50ms가 고정비" → 지표와 시도가 맞지 않아, 중앙값의 빼기만으로 결정되지 않는다
✗ "단어씩 보내면 최속" → 대화용 WebSocket은 입력을 버퍼링한다
...

Eleven v4의 흥미로움은, 음성의 표정과 저지연을 동시에 노리며, 대본 제작과 실시간 대화를 다른 모델・경로에서 제공하고 있다는 점에 있다. 게임의 대사나 음성 교재를 만들 거라면, 숫자를 바라볼 뿐만 아니라, 자신만의 문장으로 목소리를 확인해 볼 가치가 있다.

그때, 속도의 주어를 틀리지 않아야 한다. 사용자가 기다리는 것은 모델 내부의 추론이 아니라, 다음 목소리다. 오늘, 평소의 응답을 하나 골라, '전송부터 수신'과 '발화 종료부터 들릴 때까지'의 두 개의 시계를 놓아주길 바란다.

Introducing Eleven v4, our most emotive model

ElevenLabs Changelog: 2026년 9월 28일

Eleven v4: 기능 및 모델 변형

모델 및 Text to Dialogue 동시성(concurrency)

지연 시간(latency) 이해하기

지연 시간 최적화

대화 생성(Create dialogue)

실시간 대화 스트리밍(Stream dialogue in real-time)

Text to Speech vs Text to Dialogue WebSocket

Text to Dialogue WebSocket API 참고 자료

음성 AI를 선택하는 데 도움이 될 것 같다면, 좋아요와 저장 부탁드립니다. 게임, 음성 안내, 교육 자료를 제작하는 팀에도 100ms의 주석과 함께 공유해 주시면 감사하겠습니다.

댓글로 알려주세요.

**목소리 연기(Voice acting)와 응답 속도 중, 사용 목적에 따라 무엇을 우선하시나요?****지금 측정하고 있는 것은 음성 데이터가 도착하는 시점인가요? 아니면 실제로 소리가 나는 순간인가요?**고정된 대사는 사전에 생성하나요? 모든 것을 실시간으로 만드나요?