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

음성 에이전트의 응답성은 사용자가 말을 마친 시점부터 에이전트가 답변을 시작하는 시점까지의 전체 지연 시간으로 결정됩니다. 이 지연은 단일한 느린 구성 요소 때문에 발생하는 경우가 드뭅니다. 각각 수십 또는 수백 밀리초를 차지하는 여러 독립 단계에서 누적되며, 이를 줄이려면 각 단계가 얼마나 시간을 쓰는지 알아야 합니다.

음성 에이전트 지연 시간 최적화란 시간이 어디에서 소모되는지 찾아내고, 단계별로 이를 줄여 나가는 작업입니다.

이 글은 지연 시간 개념 개요를 보완합니다. 해당 페이지에서 지연 시간이 무엇인지 설명한다면, 이 글에서는 아키텍처와 측정을 다룹니다. 따라서 측정 기준으로 삼을 수 있는 지연 시간 예산과 실행 가능한 구체적 조치를 얻을 수 있습니다.

요약

• 첫 오디오까지의 시간은 단일 모델의 추론 시간이 아니라 전체 파이프라인을 나타냅니다.
• LLM의 첫 토큰까지의 시간과 엔드포인팅이 가장 큰 두 항목입니다.
• 단계를 순차적으로 실행하는 대신 겹쳐 실행하면 대부분의 예산을 확보할 수 있습니다.
• 스트리밍, 코덱 선택, 플레이어 버퍼 조정은 각각 측정 가능한 밀리초 단위의 시간을 줄여 줍니다.
• 자체 배포 환경을 기준으로 지역별 측정을 수행하고 P50 및 P95를 보고해야 합니다.

음성 에이전트 지연 시간 예산 정의

지연 시간 예산은 파이프라인 단계 전체에 걸쳐 정한 첫 오디오까지의 총 목표 시간이며, 각 단계에는 목표 시간 내 합계가 되도록 할당량이 부여됩니다. 이를 정의하는 것이 첫 단계이자, 비슷해 보이지만 의미가 다른 두 수치를 엔지니어가 혼동하기 때문에 지연 시간 작업에서 가장 자주 문제가 발생하는 지점이기도 합니다.

첫 번째는 모델 추론 지연 시간, 즉 모델이 출력을 생성하는 데 걸리는 시간입니다. ElevenLabs의 Flash 모델의 경우 네트워크 및 애플리케이션 오버헤드를 제외하면 일반적인 짧은 입력에서 약 75ms입니다. 이는 내부 지표이며 모델 간 비교에 유용합니다. 사용자가 체감하는 수치는 아닙니다.

사용자 관점에서는 첫 오디오까지의 시간(TTFA)에 집중해야 합니다. 이는 사용자가 말을 멈춘 시점부터 에이전트 답변의 첫 샘플을 듣는 시점까지의 경과 시간입니다. TTFA는 전체 파이프라인을 합산하므로 항상 단일 모델의 추론 지연 시간보다 큽니다.

계단식 음성 에이전트는 다음 5개 단계로 이루어진 체인입니다.

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

마이크에서 오디오를 캡처하고, 이를 텍스트로 전사해 언어 모델로 전송한 뒤, 모델의 텍스트를 다시 음성으로 합성하고, 해당 음성을 버퍼링하여 재생합니다. 각 단계는 지연 시간을 추가하며, 여러 단계에서 가장 큰 비용은 예상과 다를 수 있습니다.

다음은 사용자와 서버가 비교적 가까운 영어 에이전트의 예시입니다. 수치는 보장값이 아닌 예시 범위입니다.

일반적으로 가장 큰 두 지연 시간 항목은 LLM의 첫 토큰까지의 시간과 체인 시작 부분의 엔드포인팅 지연입니다. 

표는 파이프라인을 시각화하는 데 유용하지만, 단계가 엄격하게 순차 실행된다는 인상을 줍니다. 실제로는 그렇지 않습니다. 가장 중요한 음성 에이전트 지연 시간 최적화 중 상당수는 단계를 겹쳐 실행하는 데서 나오며, 아래 예산의 대부분도 이러한 중첩을 통해 확보됩니다.

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

전사는 파이프라인의 두 번째 단계이며, 실제 비용은 전사 자체보다 사용자가 말을 멈췄다고 판단하는 데 있습니다. 이 섹션에서는 음성 에이전트 지연 시간을 최적화할 수 있도록 두 측면을 모두 다룹니다.

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

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

음성 활동 감지(VAD)는 무음을 기준으로 음성을 분할하며, 시간이 누적되는 지점도 바로 여기입니다. 예를 들어 발화가 끝났다고 선언하기 전에 700ms의 무음을 기다린다면, 전사 시간에 더해 모든 턴에 700ms가 추가됩니다. 이 지연은 전사 정확도 벤치마크에서는 보이지 않지만 실제 대화에서는 매우 분명하게 드러납니다. 이는 전체 파이프라인에서 제어 가능한 지연 시간 중 가장 큰 경우가 많으며, 제어할 수 있기에 시작하기 좋은 지점입니다.

엔드포인팅은 응답성과 끊김 사이의 절충입니다. 무음 임계값이 짧으면 에이전트가 빠르게 응답하지만, 자연스러운 휴지 중에 사용자의 문장을 중간에 끊을 위험이 있습니다. 임계값이 길면 안전하지만 응답이 느립니다. 실제로 음성 인식의 지연 시간을 최적화하는 세 가지 변경 사항은 다음과 같습니다.

1. 무음 임계값 미세 조정: 사용자의 자연스러운 휴지를 자르지 않는 최소값까지 무음 임계값을 낮추고, 추측하는 대신 프로덕션 환경에서 끊김 비율을 측정하세요.
2. 물리적 제어 이벤트 삽입: 애플리케이션이 다른 신호(푸시투토크 해제, UI 이벤트)로 발화 종료를 알 수 있다면 VAD 타이머를 기다리지 말고 수동 커밋 제어를 사용하세요.
3. LLM 처리와 중첩: 부분 결과를 일찍 다운스트림으로 전달하세요. 안정적인 부분 결과를 LLM에 입력하고 최종 전사문이 다르면 수정합니다. 이는 엔드포인팅 지연을 LLM 프롬프트 처리 뒤에 숨기는 추측 실행의 한 형태입니다.

자세한 내용은 음성 인식 기능 페이지 및 실시간 음성 인식 제품 페이지에서 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을 사용하는 것이 좋습니다. 열린 연결을 통해 매 문장마다 연결 설정 비용을 다시 지불하지 않고 텍스트를 점진적으로 받을 수 있습니다. 모델이 실제로 오디오를 생성하는 시간만 동시성 한도에 포함되므로, 유휴 상태의 열린 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)보다 더 빠르게 합성됩니다. 엄격한 지연 시간 요구 사항이 있는 에이전트라면 Flash와 IVC 또는 기본 음성의 조합이 가장 낮은 지연 시간 옵션입니다.

스트리밍 청크 크기 선택

토큰은 TTS로 흐르고 오디오는 다시 돌아오는 상황에서, 다음으로 결정할 사항은 조각의 크기와 재생 시작 전 플레이어가 버퍼링할 양입니다.

작은 청크는 더 많은 메시지와 약간 더 높은 청크당 오버헤드를 대가로 플레이어에 더 빨리 도달하여 첫 바이트 지연 시간을 줄입니다. 큰 청크는 전송 효율이 더 높지만 사용자가 첫 청크를 더 오래 기다려야 합니다. 대화형 에이전트에서는 발화 초기에 작은 청크를 우선시하세요. 사용자가 기다리는 것은 첫 청크이며, 이후 청크는 오디오가 이미 재생되는 동안 도착하므로 크기의 중요성이 낮습니다.

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

• 안정적인 연결(서버 측 재생, 동일 위치의 클라이언트)에서는 보통 50~150ms 버퍼가 안전하며 TTFA를 눈에 띄게 줄일 수 있습니다.
• 지터가 큰 모바일 또는 지역 간 연결에서는 더 큰 버퍼가, 그로 인한 지연 시간보다 더 불편한 청각적 끊김을 방지합니다.

여기서 선택하는 정확한 구성은 현재 사용 사례와 우선순위에 따라 달라집니다.

코덱 선택

오디오의 전송 목적지에 따라 요청할 코덱을 결정해야 합니다. ElevenLabs는 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, 즉 요청부터 첫 오디오 청크까지 걸리는 시간을 측정하고 백분위수를 보고합니다. 개발 머신이 아니라 서버가 실행되는 동일한 리전에서 실행하세요. 앞서 사용한 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 보고: 평균 대신 이 수치에 집중하세요. 평균은 긴 꼬리 구간을 가리고, 바로 그 구간이 에이전트를 신뢰할 수 없게 느끼게 합니다. 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