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

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

음성 에이전트 지연 시간 최적화란 시간이 어디에서 소모되는지 찾아내고 단계별로 회복하는 작업입니다.

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

요약

• 첫 오디오까지의 시간은 단일 모델의 추론 시간이 아니라 전체 파이프라인을 나타냅니다.
• 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뿐 아니라 사용자와도 같은 위치에 배치하는 것입니다. 사용자가 유럽에 있다면 사용자에서 서버까지의 구간이 짧도록 에이전트 백엔드를 유럽에서 운영하세요. 그러면 라우팅이 인근 클러스터에서 서버와 모델 사이의 구간을 처리합니다.

음성 에이전트 지연 시간 직접 측정

위 지연 시간 예산 표의 수치는 계획 수립을 위한 참고 범위입니다. 실제 서비스에서 기준으로 삼을 수치는 자체 배포 환경에서 다음과 같은 스크립트를 실행해 얻어야 합니다.

아래 계측 도구는 여러 번의 시도에 걸쳐 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번의 발화 차례 중 1번의 경험을 나타냅니다. 
• 위치 기반 실험: 서비스를 제공하는 각 리전에서 동일한 스크립트를 실행하고 결과를 분리해 보관하세요.
• 정확도를 위한 간격 두기: 요청 사이에 간격을 두세요(위의 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