보이스 에이전트 지연 시간 최적화: 단계별 가이드

보이스 에이전트의 반응 속도는 사용자가 말을 마친 순간부터 에이전트가 답변을 시작할 때까지의 전체 지연 시간에 따라 결정됩니다. 이 지연은 한 가지 느린 요소 때문이 아니라 여러 독립적인 단계에서 각각 수십~수백 밀리초씩 누적되어 발생합니다. 각 단계별로 얼마나 시간이 소요되는지 파악해야만 지연을 줄일 수 있습니다.

보이스 에이전트 지연 시간 최적화란, 그 시간이 어디에 숨어 있는지 찾아내고 단계별로 줄여나가는 작업입니다.

이 글은 지연 시간 개념 개요의 보조 자료입니다. 해당 페이지가 지연 시간이 무엇인지 설명한다면, 이 글은 아키텍처와 측정 방법을 다룹니다. 읽고 나면 측정 가능한 지연 시간 예산과 실질적으로 실행할 수 있는 액션 플랜을 얻을 수 있습니다.

요약

• Time-to-first-audio(최초 오디오 출력까지의 시간)는 전체 파이프라인의 시간이며, 단일 모델 추론 시간만을 의미하지 않습니다.
• LLM의 최초 토큰 생성 시간과 엔드포인팅이 가장 큰 지연 요소입니다.
• 단계를 순차적으로 실행하는 대신 겹쳐서 실행하면 대부분의 지연 예산을 회수할 수 있습니다.
• 스트리밍, 코덱 선택, 플레이어 버퍼 조정만으로도 수십 밀리초를 줄일 수 있습니다.
• 각 지역별로 직접 측정하고, P50과 P95 값을 보고하세요.

보이스 에이전트 지연 시간 예산 정의하기

지연 시간 예산이란 파이프라인 각 단계별로 목표 time-to-first-audio(최초 오디오 출력까지의 시간)를 정하고, 각 단계에 할당량을 부여해 전체가 목표 이하가 되도록 하는 것입니다. 예산을 정의하는 것이 첫 단계이며, 이 과정에서 비슷해 보이지만 의미가 다른 두 숫자를 혼동해 문제가 생기기도 합니다.

첫 번째는 모델 추론 지연 시간입니다. 즉, 모델이 출력을 생성하는 데 걸리는 시간입니다. ElevenLabs의 Flash 모델의 경우, 일반적인 짧은 입력에 대해 약 75ms가 소요되며, 네트워크 및 애플리케이션 오버헤드는 제외한 수치입니다. 이 값은 내부 비교용으로 유용하지만, 사용자가 실제로 경험하는 시간은 아닙니다.

사용자 입장에서는 time-to-first-audio(TTFA), 즉 사용자가 말을 멈춘 순간부터 에이전트의 답변이 처음 들릴 때까지의 경과 시간에 집중하게 됩니다. TTFA는 항상 단일 모델 추론 시간보다 길며, 전체 파이프라인의 시간이 합산되기 때문입니다.

계단식 보이스 에이전트는 다섯 단계로 구성됩니다:

• 캡처(마이크) -> STT -> LLM -> TTS -> 재생

오디오는 마이크에서 캡처되어 텍스트로 전사되고, 언어 모델로 전송된 뒤, 모델의 텍스트가 다시 음성으로 합성되어 버퍼링 후 재생됩니다. 각 단계마다 지연이 추가되며, 예상과 달리 가장 큰 비용이 발생하는 단계가 따로 있을 수 있습니다.

다음은 사용자의 위치와 가까운 서버를 사용하는 영어 에이전트의 예시입니다. 숫자는 참고용 범위이며, 보장값이 아닙니다.

일반적으로 가장 큰 두 가지 지연 요소는 LLM의 최초 토큰 생성 시간과 체인의 시작점인 엔드포인팅 지연입니다.

표는 파이프라인을 시각화하는 데 유용하지만, 각 단계가 반드시 순차적으로만 실행된다는 오해를 줄 수 있습니다. 실제로는 여러 단계가 겹쳐 실행되며, 이 겹침에서 대부분의 지연 예산이 회수됩니다.

음성 인식: 전사 및 엔드포인팅 지연 시간 최적화

전사는 파이프라인의 두 번째 단계이며, 실제 비용은 전사 자체보다 사용자가 말을 마쳤는지 판단하는 데 있습니다. 이 섹션에서는 두 가지 모두를 다루어 보이스 에이전트 지연 시간을 최적화하는 데 도움을 드립니다.

전사는 LLM에 도달하기 전에 이루어집니다.Scribe v2 실시간 (scribe_v2_realtime)은 약 150ms 내에 부분 전사 결과를 반환하며, 오디오를 청크 단위로 스트리밍합니다. 즉, 사용자가 말하는 도중에도 전사 결과가 생성됩니다. 8kHz~48kHz PCM과 mu-law 인코딩을 지원하며, 이는 아래 코덱 섹션에서 중요합니다. 150ms 부분 전사는 비용이 적습니다.

더 큰 지연 비용은 엔드포인팅, 즉 시스템이 사용자가 실제로 말을 마쳤다고 판단하는 순간입니다.

음성 활동 감지(VAD)는 침묵을 기준으로 음성을 구분하며, 이때 시간이 누적됩니다. 예를 들어, 700ms의 침묵이 감지되어야 턴이 끝났다고 판단한다면, 매 턴마다 700ms가 추가로 소요됩니다. 이 지연은 전사 정확도 벤치마크에서는 보이지 않지만, 실제 대화에서는 크게 체감됩니다. 전체 파이프라인에서 가장 크게 조절 가능한 지연이며, 조절이 가능하기 때문에 최적화의 출발점으로 좋습니다.

엔드포인팅은 반응성(빠른 응답)과 끊김(사용자 발언 중단) 사이의 균형입니다. 짧은 침묵 임계값은 빠른 응답을 가능하게 하지만, 자연스러운 멈춤에도 사용자의 말을 끊을 위험이 있습니다. 긴 임계값은 안전하지만 느려집니다. 실제로 음성 인식 지연을 최적화하는 세 가지 방법은 다음과 같습니다:

1. 침묵 임계값 미세 조정:사용자의 자연스러운 멈춤을 자르지 않는 최소값까지 침묵 임계값을 줄이고, 추측 대신 실제 운영 환경에서 끊김 비율을 측정하세요.
2. 물리적 제어 이벤트 삽입: 애플리케이션이 다른 신호(푸시투토크 해제, UI 이벤트 등)로 턴 종료를 알 수 있다면, VAD 타이머를 기다리지 말고 수동 커밋 제어를 사용하세요.
3. LLM 프로세스와 겹치기:부분 전사 결과를 미리 하위 단계로 전달하세요. 안정적인 부분 전사를 LLM에 입력하고, 최종 전사 결과가 다를 경우 수정하는 방식입니다. 이는 LLM 프롬프트 처리 시간 동안 엔드포인팅 지연을 숨기는 추측 실행(speculative execution)입니다.

자세한 내용은 Scribe v2 Realtime에 대해 음성 인식 기능 페이지와 실시간 음성 인식 제품 페이지에서 확인할 수 있습니다.

LLM의 지연 시간 기여도

언어 모델은 보통 TTFA에서 가장 큰 단일 지연 요소이므로, 이 단계에서 겹침을 활용하면 보이스 에이전트 지연 시간 최적화에 가장 큰 효과를 볼 수 있습니다. 여기서 핵심은, 에이전트가 답변 전체를 받아야만 말을 시작할 필요는 없다는 점입니다.

가장 많은 지연 예산을 회수하는 방법은 LLM에서 토큰이 생성되는 대로 스트리밍하여, 문장 또는 절 단위로 TTS에 전달하는 것입니다. 즉, 토큰을 문장 경계까지 버퍼링한 뒤 해당 문장을 합성하고, 다음 문장이 생성되는 동안 합성을 계속하는 방식입니다:

const SENTENCE_END = /(?<=[.!?])\s+/;

async function* speakLlmStream(tokens: AsyncIterable<string>) {
  let buffer = "";
  for await (const token of tokens) {
    buffer += token;
    const parts = buffer.split(SENTENCE_END);
    buffer = parts.pop() ?? ""; // keep the incomplete fragment
    for (const sentence of parts) {
      if (sentence.trim()) yield* synthesize(sentence.trim());
    }
  }
  if (buffer.trim()) yield* synthesize(buffer.trim());
}

async function* synthesize(text: string) {
  const stream = await elevenlabs.textToSpeech.stream("JBFqnCBsd6RMkjVDRZzb", {
    text,
    modelId: "eleven_flash_v2_5",
    outputFormat: "mp3_44100_128",
  });
  yield* stream;
}

장시간 대화에서는 TTS 웹소켓을 사용하는 것이 좋습니다. 오픈된 연결로 텍스트를 점진적으로 받을 수 있어, 매 문장마다 연결을 새로 맺는 오버헤드를 줄일 수 있습니다. 모델이 실제로 오디오를 생성하는 시간만 동시 처리 한도에 포함되므로, 대기 중인 WebSocket은 거의 비용이 들지 않습니다.

텍스트 음성 변환: 스트리밍과 음성 선택

텍스트 음성 변환 단계에서는 지연 시간을 가장 정확하게 조절할 수 있습니다. 주요 조절 요소는 오디오 스트리밍 방식과 선택하는 음성입니다.

Flash v2.5 (eleven_flash_v2_5)는 에이전트에 적합한 모델입니다. 짧은 입력에 대해 약 75ms의 모델 추론 속도를 제공하며, 32개 언어를 지원하고, 요청당 최대 40,000자까지 입력할 수 있습니다.

75ms 수치는 추론 시간만을 의미합니다. 위 예산표의 TTS TTFA는 네트워크 왕복 시간과 서버 스케줄링이 추가되어 더 커집니다.

여기서 가장 큰 조절 요소는 스트리밍입니다. 전체 오디오를 한 번에 요청하면, 사용자는 전체 클립이 합성될 때까지 기다려야 합니다. 스트리밍을 사용하면, 첫 번째 청크가 생성되는 즉시 들을 수 있고, 나머지는 듣는 동안 도착합니다. 스트리밍이 모델을 더 빠르게 만드는 것은 아니지만, 생성 중에도 바로 사용자에게 출력할 수 있습니다.

스트리밍 가이드에서는 HTTP 스트리밍을, 실시간 WebSocket 가이드에서는 LLM에서 토큰을 받아올 때 사용할 WebSocket 경로를 다룹니다.

클라이언트를 한 번 초기화한 뒤, 아래 모든 호출에서 재사용하세요:

import { ElevenLabsClient } from "@elevenlabs/elevenlabs-js";

const elevenlabs = new ElevenLabsClient({ apiKey: process.env.ELEVENLABS_API_KEY });

그 다음 스트림을 설정하고, 들어오는 대로 전달하세요:

const stream = await elevenlabs.textToSpeech.stream("JBFqnCBsd6RMkjVDRZzb", {
  text: "Your call is connected. How can I help today?",
  modelId: "eleven_flash_v2_5",
  outputFormat: "mp3_44100_128",
});

for await (const chunk of stream) {
  // forward each chunk to your audio sink as it arrives
}

또 다른 조절 요소는 음성 선택입니다. 기본 음성, 합성 음성, Instant Voice Clone(IVC)은 Professional Voice Clone(PVC)보다 더 빠르게 합성됩니다. PVC는 모델 복잡도가 높아 생성마다 추가 오버헤드가 발생하기 때문입니다. 엄격한 지연 시간이 필요한 에이전트라면 Flash와 IVC 또는 기본 음성 조합이 가장 저지연 옵션입니다.

스트리밍 청크 크기 선택

토큰이 TTS로 들어가고 오디오가 다시 돌아올 때, 다음으로 결정할 것은 청크 크기와 플레이어가 재생을 시작하기 전 버퍼링 양입니다.

작은 청크는 플레이어에 더 빨리 도달해 최초 바이트 지연을 줄이지만, 메시지 수가 늘고 청크당 오버헤드가 약간 증가합니다. 큰 청크는 전송 효율이 높지만, 첫 청크를 기다리는 시간이 길어집니다. 인터랙티브 에이전트라면, 발화 초반에는 작은 청크를 선호하세요. 사용자는 첫 청크를 기다리기 때문입니다. 이후 청크는 오디오가 이미 재생 중일 때 도착하므로 크기가 덜 중요합니다.

플레이어는 남은 지연 시간 중 상당 부분을 차지합니다. 대부분의 오디오 플레이어는 첫 바이트에서 바로 재생하지 않고, 스트림이 잠시 느려져도 끊기지 않도록 소량을 버퍼링합니다. 500ms 기본 버퍼가 흔하며, 이 값이 체감 지연에 직접 추가됩니다. 버퍼를 줄이면 끊김 위험이 약간 늘지만 TTFA가 줄어듭니다. 적정 값은 서버와 클라이언트 간 네트워크 지터에 따라 달라집니다:

• 연결이 안정적일 때(서버 측 재생, 같은 위치의 클라이언트), 50~150ms 버퍼가 안전하며 TTFA를 눈에 띄게 줄일 수 있습니다.
• 모바일이나 지역 간 연결처럼 지터가 큰 경우, 더 큰 버퍼가 오히려 지연보다 더 심각한 끊김을 막아줍니다.

여기서 어떤 설정을 선택할지는 실제 사용 사례와 우선순위에 따라 달라집니다.

코덱 선택

오디오가 어디로 전송되는지에 따라 요청할 코덱을 결정해야 합니다. mp3_44100_128, mp3_22050_32, pcm_16000, pcm_24000, ulaw_8000 등 다양한 포맷을 제공합니다. 전송 방식의 기본 포맷과 맞추면 트랜스코딩 단계를 줄여 보이스 에이전트 지연 시간 최적화에 도움이 됩니다.

Twilio 등 전화망에서는 ulaw_8000을 사용하세요. 전화망은 처음부터 끝까지 8kHz mu-law이므로, 직접 요청하면 파이프라인에서 트랜스코딩 단계를 생략할 수 있고, 통신사 요구와도 일치합니다. 더 고음질로 합성해도 전화망에서 바로 다운샘플링되므로, 지연만 늘고 실제로 들리는 품질은 달라지지 않습니다.

WebRTC나 브라우저 재생에서는 PCM(pcm_24000 또는 pcm_16000)이나 MP3 포맷을 사용하세요. PCM은 압축되지 않아 클라이언트에서 디코딩 단계가 없으므로, 청크당 지연이 약간 줄고 Web Audio 파이프라인에 바로 연결할 때 편리합니다. MP3는 전송 시 더 작아 네트워크가 제한적일 때 유리하지만, 클라이언트에서 가벼운 디코딩이 필요합니다.

지리적 위치와 네트워크 거리

위의 모든 최적화는 데이터가 짧은 거리를 이동한다고 가정합니다. 지리적 위치는 지연 시간 예산의 최소값을 결정하므로, 다른 튜닝 전에 반드시 확인해야 합니다.

ElevenLabs는 북미, 유럽, 동남아시아 클러스터에서 요청을 처리하며, 각 요청을 자동으로 가장 가까운 클러스터로 라우팅합니다. 공용 인터넷을 통한 네트워크 왕복 시간은 지리적 거리 따라 보통 20~200ms이며, 인프라 위치를 바꾸지 않는 한 줄일 수 없습니다.

샌프란시스코처럼 북미 클러스터와 가까운 곳에서는 즉각적인 반응이 느껴지지만, 남아시아처럼 트래픽이 바다를 두 번 건너야 하는 지역에서는 느리게 느껴질 수 있습니다.

해결 방법은 애플리케이션 서버를 ElevenLabs뿐 아니라 사용자와도 가까운 곳에 두는 것입니다. 사용자가 유럽에 있다면, 에이전트 백엔드를 유럽에 배포해 사용자-서버 구간을 짧게 하고, 이후 서버-모델 구간은 ElevenLabs가 가까운 클러스터로 라우팅합니다.

직접 보이스 에이전트 지연 시간 측정하기

위 예산표의 숫자는 계획용 참고 범위입니다. 실제 배포 환경에서 측정한 값으로 계획을 세워야 합니다. 아래와 같은 스크립트를 사용해 직접 측정하세요.

아래 계측 코드는 TTS 단계의 TTFA, 즉 요청부터 첫 오디오 청크까지의 시간을 여러 번 측정해 백분위수로 보고합니다. 서버가 실제로 운영되는 지역에서 실행해야 하며, 개발 PC에서 실행하면 안 됩니다. 앞서 사용한 elevenlabs 클라이언트를 가정합니다:

const VOICE_ID = "JBFqnCBsd6RMkjVDRZzb";
const TEXT = "Thanks for waiting. I have pulled up your account and I can help with that now.";
const TRIALS = 50;

async function measureTtfa(): Promise<number | null> {
  const start = performance.now();
  const stream = await elevenlabs.textToSpeech.stream(VOICE_ID, {
    text: TEXT,
    modelId: "eleven_flash_v2_5",
    outputFormat: "mp3_44100_128",
  });
  for await (const _chunk of stream) {
    return performance.now() - start; // first chunk -> stop the clock
  }
  return null;
}

function percentile(values: number[], p: number): number {
  const v = [...values].sort((a, b) => a - b);
  const k = (v.length - 1) * (p / 100);
  const lo = Math.floor(k);
  const hi = Math.min(lo + 1, v.length - 1);
  return v[lo] + (v[hi] - v[lo]) * (k - lo);
}

const samples: number[] = [];
for (let i = 0; i < TRIALS; i++) {
  const ttfa = await measureTtfa();
  if (ttfa !== null) samples.push(ttfa);
  await new Promise((r) => setTimeout(r, 300)); // space requests, don't measure your own queueing
}

console.log(`trials: ${samples.length}`);
console.log(`P50:    ${percentile(samples, 50).toFixed(0)} ms`);
console.log(`P95:    ${percentile(samples, 95).toFixed(0)} ms`);

기억해야 할 점:

• P50, P95 보고:평균값보다 P50, P95에 집중하세요. 평균은 꼬리값을 숨기며, 꼬리값이 에이전트의 신뢰도를 좌우합니다. P95는 20번 중 한 번의 경험입니다.
• 지역별 실험: 각 서비스 지역에서 같은 스크립트를 실행하고 결과를 분리해 관리하세요.
• 정확도 향상을 위한 분산 실행:요청을 일정 간격(setTimeout)으로 분산하세요. 한 번에 모두 보내면 서비스가 아닌 자체 큐잉 시간을 측정하게 됩니다. 동시 처리 한도를 초과하면 요청이 우선순위에 따라 대기하며, 보통 50ms 정도 추가되고, 한도를 넘으면 HTTP 429가 반환됩니다.
• 전체 지연 체인 측정:같은 타이밍 패턴을 다른 단계에도 적용하세요. STT 완료, LLM 최초 토큰, 플레이어 시작도 performance.now()로 감싸면, 직접 측정한 값으로 전체 예산표를 채우고 어디를 먼저 개선할지 알 수 있습니다.

이 팁들을 따르면 직접 보이스 에이전트 지연 시간을 측정할 수 있습니다. 이후에는 우선순위가 명확해집니다.

보이스 에이전트 지연 시간을 가장 많이 줄이는 방법은?

빠르게 집중할 액션 아이템이 필요하다면, 아래가 가장 효과적인 변화입니다.

영향도 순으로, 다음 방법들을 활용해 에이전트 지연 시간을 줄일 수 있습니다:

• 엔드포인팅 지연을 숨기기 위해 안정적인 STT 부분 결과로 LLM 작업을 미리 시작하세요.
• 문장 경계마다 LLM 토큰을 TTS로 스트리밍해, 첫 번째 문장 합성과 두 번째 문장 생성을 겹치세요.
• TTS 오디오를 플레이어로 스트리밍하고, 네트워크 지터가 허용하는 최소값까지 플레이어 버퍼를 줄이세요.
• 최저 지연 TTS를 위해 Flash와 기본 음성 또는 IVC를 사용하고, 전송 방식에 맞는 코덱(전화망은 ulaw_8000, 브라우저/WebRTC는 PCM 또는 MP3)을 선택하세요.
• 서버를 사용자와 같은 지역에 배치하고, 지역별로 측정하세요. 네트워크 구간은 실제로 존재하며, 지역마다 다릅니다.

더 구체적인 기술은 지연 시간 최적화 개발자 가이드를 참고하세요. 실행 가능한 예제는 API 퀵스타트와 스트리밍 가이드에 모두 포함되어 있습니다.

최적화된 에이전트 파이프라인을 더 빠르게 사용하고 싶으신가요?ElevenAgents는 이미 겹침 최적화가 적용된 파이프라인을 구현합니다.

ElevenAgents로 저지연 보이스 에이전트 구축하기

보이스 에이전트 지연 시간 최적화는 각 단계를 측정하고, 느린 단계가 이미 진행 중인 작업 뒤에서 실행되도록 겹치는 것이 핵심입니다. 위의 패턴을 활용해 여러 번 반복하며 직접 구축할 수도 있고, 이미 최적화가 적용된 파이프라인에서 바로 시작할 수도 있습니다.

ElevenAgents는 스트리밍 STT부터 토큰 단위 LLM 연동, Flash TTS까지 전체 파이프라인을 겹침 기법과 함께 구현합니다. 처음부터 직접 만들 필요 없이, 원하는 성능에 맞게 임계값만 조정하면 됩니다.

지금 바로 ElevenAgents로 에이전트 만들기 또는 영업팀 문의로 자세한 정보를 받아보세요.

보이스 에이전트 지연 시간 최적화 FAQ