200ms 이하 실시간 음성 인식: 아키텍처 가이드

실시간 음성 텍스트 변환(STT)은 사람이 말하는 동안 오디오를 실시간으로 전사해 수백 밀리초 내에 텍스트로 반환합니다. 하지만 STT 지연 시간을 낮게 유지하는 일은 모델만큼이나 아키텍처의 문제이기도 합니다. 엔지니어는 전송, 청크 분할, 엔드포인팅, 캡처 경로를 모두 설계해야 하며, 각각이 지연 시간을 더합니다. 이 중 하나라도 비효율적이면 200ms 예산을 초과할 수 있습니다.

이 가이드에서는 전송 계층부터 실시간 음성 텍스트 변환 파이프라인을 구축할 때 활용할 수 있는 실용적인 시스템을 소개합니다. 중심으로 살펴볼 제품은 Scribe v2 Realtime이며, 약 150ms의 모델 지연 시간으로 부분 전사 결과를 제공하고, 90개 이상의 언어를 지원하며, PCM(8kHz~48kHz) 및 mu-law 오디오를 받아들입니다. 또한 세그먼트 확정을 위한 음성 활동 감지와 수동 커밋 제어를 제공합니다.

오디오가 서버에 도달하는 방식, 가설이 확정된 텍스트로 발전하는 과정, 스트림 내 기능의 비용, 그리고 오디오를 올바르게 캡처하고 전달하는 방법을 차례로 살펴보겠습니다.

요약

• 실시간 음성 텍스트 변환 시스템을 구축하려면 전체 파이프라인에서 지연 시간을 낮게 유지하도록 아키텍처를 세밀하게 조정해야 합니다.
• 대부분의 파이프라인에서는 WebSocket이 적합한 기본 선택지입니다. WebRTC도 다양한 이점을 제공하지만 더 복잡합니다.
• 음성 활동 감지는 핸즈프리 세그먼트 분할을 처리하며, 수동 커밋을 사용하면 대화 턴이 끝났음을 알 때 애플리케이션에서 이를 직접 제어할 수 있습니다.
• 부분 결과는 임시 상태이고 최종 결과는 확정 상태이므로, 서로 다르게 표시해야 합니다. 
• 약 100ms의 작은 PCM 청크를 사용하면 첫 부분 결과까지의 지연 시간을 최소화할 수 있습니다.

실시간 음성 텍스트 변환을 위한 WebSocket과 WebRTC 비교

전사가 시작되기 전에 오디오는 소스에서 음성 인식기로 이동해야 합니다. 선택하는 채널이 이후 모든 과정의 최소 지연 시간을 결정합니다. 오디오를 전사 계층으로 전달하는 실용적인 방법은 두 가지입니다.

WebSocket은 TCP 기반의 장시간 유지형, 순서 보장, 신뢰성 있는 양방향 채널입니다. 연결을 열고 바이너리 오디오 프레임을 전송한 뒤 전사 이벤트를 수신합니다. 클라이언트와 서버 모두에서 구현이 간단하고, 이미 HTTPS를 허용하는 기업 프록시와 방화벽을 통과하며, 모든 브라우저와 서버 런타임에서 지원합니다. 

WebSocket의 제약은 TCP 위에서 동작한다는 점입니다. 패킷이 손실되면 TCP는 재전송하고, 손실 구간이 채워질 때까지 이후 데이터를 대기시킵니다. 네트워크 상태가 좋으면 눈에 띄지 않습니다. 하지만 패킷 손실이 발생하면 헤드 오브 라인 블로킹이 생겨, 오디오가 잠시 쌓였다가 한꺼번에 도착합니다.

WebRTC는 실시간 미디어를 위해 설계되었습니다. UDP(SRTP 경유)로 미디어를 전송하므로 패킷이 손실되어도 스트림이 멈추지 않고 파이프라인이 계속 진행됩니다. 패킷 도착 시간의 변동을 흡수하는 지터 버퍼를 포함하며, ICE/STUN/TURN을 통해 NAT 통과를 협상하여 라우터 뒤의 피어도 연결할 수 있습니다. 자체 오디오 캡처와 인코딩 기능도 제공합니다. 

직접 연결할 수 없는 클라이언트에는 일반적으로 TURN 서버가 필요하며, 서버 측에서는 바이트 스트림을 읽는 대신 미디어 스트림을 종료 처리해야 합니다.

핵심 차이점은 다음과 같습니다.

대부분의 사용 사례에서는 WebSocket이 적합합니다. 클라이언트 연결 상태가 양호하고 캡처 경로를 제어할 수 있을 때 사용하세요. 예를 들면 서버 간 파이프라인, 데스크톱 앱, 광대역 환경의 브라우저 앱, 그리고 다른 방식으로 오디오가 이미 서버에 도착하는 대부분의 컨택센터 백엔드가 있습니다. 

불안정한 모바일 네트워크에서 소비자 기기로부터 직접 오디오를 캡처할 때, 양방향 오디오용 WebRTC 스택을 이미 운영 중일 때(예: 다시 음성으로 응답하는 음성 에이전트), 또는 구현 단순성보다 손실에 강한 실시간 동작이 중요할 때는 WebRTC를 선택하세요.

이 가이드의 나머지 부분에서는 음성 인식기 연결에 WebSocket 전송을 사용합니다. 구성 요소를 명확히 볼 수 있고 대부분의 팀에 적합한 출발점이기 때문입니다. 여기의 내용은 WebSocket에만 국한되지 않으므로, 이후 앞단에 WebRTC 미디어 연결을 추가하고 서버에서 오디오를 PCM으로 디코딩한 뒤 동일한 청크를 파이프라인으로 전달할 수 있습니다.

부분 결과와 최종 전사본: 중간 결과 이해하기

실시간 음성 인식기는 완전한 문장이 끝날 때까지 기다리지 않습니다. 대신 오디오가 더 들어올수록 정교해지는 추정 결과를 계속 내보내고, 이후 이를 확정합니다. 이 두 상태의 차이를 이해해야 생동감 있는 전사본과 어색한 전사본을 구분할 수 있습니다. 

부분(중간) 가설은 지금까지 수신한 오디오를 바탕으로 한 모델의 최선의 추정입니다. 부분 결과는 의도적으로 불안정합니다. 오디오가 더 들어오면 모델은 앞선 단어를 수정합니다. 예를 들어 "I want to"는 이후 맥락이 모호함을 해소하면 "I want two tickets"가 될 수 있습니다. 부분 결과는 빠르게 도착하며(~150ms 지연 시간 수치가 이를 의미함), 이후 덮어쓰기 위한 결과입니다.

최종 가설은 더 이상 변경되지 않는 확정 세그먼트입니다. 세그먼트가 확정되면 음성 인식기는 다음으로 넘어가고, 이후 가설은 뒤따르는 오디오를 설명합니다. 최종 결과는 저장하거나 LLM에 전달하거나 전사본으로 보관하는 데이터입니다.

부분 결과와 최종 결과의 차이는 다음 세 가지에 영향을 미치며, 이를 혼동하면 문제가 생깁니다.

• 사용자 경험: 부분 결과를 표시하면 전사본이 실시간으로 동작하는 느낌을 줍니다. 사용자는 말하는 대로 단어가 나타나는 것을 보며 마이크가 작동하고 시스템이 듣고 있음을 확인할 수 있습니다.
• 엔드포인팅: 부분 결과는 음성 활동에 대한 연속적인 신호를 제공합니다. VAD와 결합하면 화자가 실제로 말을 멈춘 시점을 판단할 수 있습니다.
• 후속 처리 타이밍: 음성 에이전트 파이프라인에서는 오디오 입력, 음성 텍스트 변환, LLM, 텍스트 음성 변환, 오디오 출력 순으로 처리됩니다. 부분 결과에서 예측 작업을 시작하고 최종 결과에서 이를 확정하면, 때때로 예측 작업을 버려야 하는 대가로 체감 응답 시간을 줄일 수 있습니다.

부분 결과와 최종 결과는 다르게 표시하세요. 간단하면서도 효과적인 패턴은 최신 부분 결과에 연결된 변경 가능한 단일 "현재 줄"을 유지하다가, 최종 결과가 도착하면 추가 전용 전사본에 확정하는 방식입니다.

type TranscriptState = {
  committed: string[]; // finalized segments, never rewritten
  current: string;     // latest partial, overwritten on each update
};

const onPartial = (s: TranscriptState, text: string): TranscriptState =>
  ({ ...s, current: text });

const onFinal = (s: TranscriptState, text: string): TranscriptState =>
  ({ committed: [...s.committed, text], current: "" });

시각적으로는 확정된 결과를 일반 텍스트로 표시하고, 현재 결과는 더 옅은 색이나 기울임꼴로 표시해 여전히 변경될 수 있음을 사용자가 알 수 있게 하세요.

엔드포인팅과 음성 활동 감지(VAD)

무엇을 말했는지 아는 것은 절반에 불과합니다. 음성 인식기는 발화가 언제 끝났는지도 알아야 합니다. 이 판단은 세그먼트를 언제 확정할지, 에이전트에서는 시스템이 언제 응답을 시작할지를 결정합니다. 

엔드포인팅은 발화가 끝났다고 판단하는 과정입니다. 너무 일찍 확정하면 사용자의 말을 문장 중간에 끊게 됩니다. 너무 늦게 확정하면 사용자가 분명히 말을 끝낸 뒤에도 에이전트가 응답하지 않습니다.

Scribe v2 Realtime은 함께 사용할 수 있는 두 가지 상호 보완적 기능을 제공합니다.

• 음성 활동 감지로 무음 기반 오디오 세그먼트 분할: 음성 인식기는 발화가 지속적인 무음으로 전환되는 시점을 감지하고, 그 경계를 사용해 세그먼트를 자동으로 확정합니다. VAD는 시간을 직접 추적하지 않아도 자연스러운 말하기 리듬에 맞춰 조정되므로 대화형 인터페이스에 적합한 기본값입니다.
• 수동 커밋 제어: 수동 커밋 제어를 사용하면 무음 여부와 관계없이 애플리케이션에서 현재 세그먼트를 확정할 시점을 결정할 수 있습니다. 커밋 신호를 보내면 음성 인식기가 현재 세그먼트를 닫고 최종 결과를 내보냅니다. 푸시 투 토크 버튼을 놓는 경우, "전송" 동작, 외부 턴 테이킹 정책처럼 애플리케이션이 이미 대화 턴이 끝났음을 아는 경우에 적합합니다.

이 두 기능은 함께 잘 작동합니다. 일반적인 음성 에이전트는 핸즈프리 작동에 VAD를 사용하고 수동 커밋을 재정의 수단으로 제공합니다. 따라서 생각하느라 잠시 멈춘 사용자의 말을 끊지 않으면서도, 버튼을 누른 사용자는 즉시 경계를 설정할 수 있습니다.

무음 임계값은 보편적으로 정답인 값이 없는 실질적인 트레이드오프입니다.

• 짧은 발화 종료 타임아웃(예: 약 200~400ms 무음 후 확정)은 시스템의 반응성을 높여 줍니다. 하지만 절 사이에서 자연스럽게 멈추는 사용자의 말을 끊어 하나의 생각을 여러 세그먼트로 나누고, 에이전트에서는 성급한 응답을 유발할 수 있습니다.
• 긴 타임아웃(예: 약 800~1200ms)은 자연스러운 멈춤을 허용하고 발화를 온전하게 유지하지만, 시스템이 반응하기까지 눈에 띄는 지연이 생깁니다.

여기에 적용할 전역 상수는 없습니다. 상호작용에 맞게 임계값을 조정하세요.

• 받아쓰기와 메모 작성에서는 사용자가 문장 중간에 생각할 수 있으므로 더 긴 멈춤을 허용해야 합니다. 타임아웃을 길게 설정하고 VAD에 더 의존하세요.
• 명령 제어 및 트랜잭션 에이전트는 대화 턴이 짧고 명확하므로, 짧은 타임아웃과 수동 커밋을 함께 사용하면 효과적입니다.
• 다국어 사용자나 비원어민 화자는 더 자주 멈추므로, 확정 전 무음 시간을 더 길게 잡으세요.

이 팁을 활용하면 효과적인 엔드포인팅 시스템을 구축하고 실시간 음성 텍스트 변환에 가까워질 수 있습니다.

스트림 내 기능: 언어 감지와 화자 분리

스트리밍 음성 인식은 단어를 생성하는 것 이상의 작업을 할 수 있습니다. 다만 요청하는 추가 신호마다 지연 시간과 안정성에 영향을 줍니다. 실시간 경험에 필요한 기능만 켜고, 나머지는 배치 처리로 미루는 것이 원칙입니다.

자동 언어 인식을 사용하면 미리 언어를 지정하지 않아도 Scribe v2 Realtime이 지원하는 90개 이상의 언어 중 발화 언어를 식별할 수 있습니다. 다만 모델이 확신 있는 판단을 내리려면 짧은 구간의 오디오가 필요하므로, 언어가 확정되는 동안 스트림의 초기 부분 결과는 다소 불안정할 수 있습니다. 이미 언어를 알고 있다면 지정하는 편이 이러한 모호성을 없애고 초기 부분 결과를 더 안정적으로 만드는 경향이 있습니다.

화자 분리는 발화를 서로 다른 화자에게 귀속시켜 누가 무엇을 말했는지 식별합니다. 배치 전사에서는 모델이 전체 파일을 볼 수 있어 비교적 쉽습니다. 스트리밍에서는 더 어렵습니다. 음성 인식기는 현재까지의 오디오만으로 화자 레이블을 할당해야 하며, 특정 화자의 음성을 더 듣게 되면 초기 오디오에 부여한 레이블을 수정해야 할 수 있습니다. 스트리밍 화자 레이블도 부분 텍스트와 마찬가지로 취급하세요. 세그먼트가 확정될 때까지는 임시 상태입니다.

단어 수준 타이밍과 엔터티 컨텍스트도 같은 원리를 따릅니다. 토큰별 메타데이터를 더 많이 요청할수록 모델과 전송 계층 모두가 처리해야 할 양이 늘어납니다. 대부분의 실시간 UI에서는 실시간 텍스트와 세그먼트 경계만 필요하며, 세부 메타데이터는 Scribe v2를 사용한 통화 후 배치 처리로 미룰 수 있습니다.

스트리밍용 오디오 형식: PCM과 mu-law

전송과 음성 인식 로직이 대부분의 주목을 받지만, 실제 환경의 버그 중 상당수는 한 단계 아래인 오디오 인코딩과 청크 분할 방식에서 발생합니다. 형식과 청크 크기를 올바르게 설정하는 것은 가장 비용 효율적인 음성 텍스트 변환 지연 시간 개선 방법입니다.

PCM(리니어, 16비트 부호 있음, 리틀 엔디언)은 캡처를 제어할 수 있을 때 사용할 형식입니다. 샘플링 레이트가 높을수록 더 많은 음향 세부 정보를 담습니다. 16kHz는 음성 인식의 표준 최소치이며 대체로 충분합니다. 8kHz는 전화 품질로 고주파 콘텐츠가 손실됩니다. 소스에 맞는 레이트를 사용하세요. 8kHz 전화 오디오를 48kHz로 업샘플링해도 복구할 정보가 없으므로 이점이 없습니다.

8kHz mu-law는 전화용 형식입니다. Twilio 같은 제공업체에서 통화를 수집하는 경우 오디오는 8kHz mu-law로 도착하므로, 두 번 트랜스코딩하지 말고 해당 형식으로 전달해야 합니다. 소스 형식을 일치시키면 리샘플링 아티팩트와 불필요한 변환 단계를 피할 수 있습니다.

청크 크기는 체감 지연 시간을 가장 직접적으로 결정하는 요소입니다. 오디오는 청크 단위로 전송하고, 음성 인식기는 청크가 도착할 때마다 부분 결과를 생성합니다. 청크가 작을수록 업데이트 빈도가 높아지고 첫 부분 결과까지의 지연 시간은 줄어듭니다. 청크가 클수록 메시지는 줄고 추론당 컨텍스트는 약간 더 늘어납니다. 실용적인 범위는 청크당 20~250ms의 오디오입니다. 구체적으로 16kHz 모노 16비트 PCM에서 오디오 1초는 32,000바이트이므로, 100ms 청크는 약 3,200바이트입니다.

브라우저에서 마이크 입력 캡처하기

브라우저에서는 Web Audio API와 AudioWorklet을 사용하는 것이 적합합니다. 워크릿은 오디오 렌더링 스레드에서 실행되고 작은 프레임 단위로 오디오를 수신하므로, 이전의 ScriptProcessorNode와 달리 메인 스레드 지연 현상의 영향을 받지 않습니다. 워크릿은 브라우저의 기본 float 샘플을 16비트 PCM으로 변환해 메인 스레드에 전달하고, 메인 스레드는 이를 WebSocket으로 전달합니다.

워크릿 프로세서의 핵심은 float를 PCM으로 변환하는 작업입니다.

// pcm-worklet.ts - registered via audioContext.audioWorklet.addModule()
class PCMWorklet extends AudioWorkletProcessor {
  process(inputs: Float32Array[][]) {
    const channel = inputs[0]?.[0]; // mono; Float32, range [-1, 1]
    if (!channel) return true;
    const pcm = new Int16Array(channel.length);
    for (let i = 0; i < channel.length; i++) {
      const s = Math.max(-1, Math.min(1, channel[i]));
      pcm[i] = s < 0 ? s * 0x8000 : s * 0x7fff;
    }
    // Transfer the buffer to the main thread without copying.
    this.port.postMessage(pcm.buffer, [pcm.buffer]);
    return true;
  }
}
registerProcessor("pcm-worklet", PCMWorklet);

코드로 살펴보는 파이프라인

파이프라인은 세 가지 구성 요소로 이루어집니다. 마이크를 캡처해 PCM을 서버로 스트리밍하는 브라우저 클라이언트, 오디오를 Scribe v2 Realtime으로 전달하고 전사본을 다시 전달하는 Node 서버, 그리고 파일이나 전화 브리지에서 PCM을 스트리밍하는 스크립트형 클라이언트입니다.

음성 인식기를 브라우저에 직접 노출하지 않고 서버가 중계하는 데에는 중요한 이유가 있습니다. ElevenLabs API 키는 비밀 정보이므로 클라이언트 측 코드에 절대 포함해서는 안 됩니다. 키는 서버에 보관해야 합니다. 브라우저가 음성 인식기와 직접 통신해야 한다면, 서버 측에서 수명이 짧은 일회용 토큰을 발급해 API 키 대신 클라이언트에 전달하세요.

브라우저 클라이언트

클라이언트는 서버에 WebSocket을 열고, 앞서 설명한 워크릿으로 마이크를 캡처한 뒤 생성되는 각 PCM 프레임을 전달합니다. 수신 이벤트(서버가 이미 { type, text } 형식으로 정규화함)는 앞서 설명한 부분/최종 상태를 업데이트합니다.

// client.ts - runs in the browser. ws is an open WebSocket to your server.
const audioContext = new AudioContext({ sampleRate: 16000 });
await audioContext.audioWorklet.addModule("pcm-worklet.js");

const mediaStream = await navigator.mediaDevices.getUserMedia({
  audio: { channelCount: 1, echoCancellation: true, noiseSuppression: true },
});

const source = audioContext.createMediaStreamSource(mediaStream);
const worklet = new AudioWorkletNode(audioContext, "pcm-worklet");

// Forward each PCM frame to the server the moment it is produced.
worklet.port.onmessage = (e: MessageEvent<ArrayBuffer>) => {
  if (ws.readyState === WebSocket.OPEN) ws.send(e.data);
};
source.connect(worklet);

// Manual commit: tell the server to finalize the current segment.
const commit = () => ws.send(JSON.stringify({ type: "commit" }));

서버 중계

서버는 클라이언트마다 하나의 음성 인식기 연결을 열고, API 키를 서버에 보관하며, 바이너리 PCM을 그대로 전달합니다. 또한 음성 인식기 이벤트를 클라이언트가 사용하는 안정적인 { type, text } 형식으로 정규화합니다.

// server.ts - Node, using the `ws` library. ELEVENLABS_API_KEY and the
// recognizer URL come from the environment; see the Speech to Text reference
// for the exact path and query parameters.
import { WebSocketServer, WebSocket } from "ws";

new WebSocketServer({ port: 8080 }).on("connection", (client) => {
  // The API key stays on the server, never on the wire to the browser.
  const recognizer = new WebSocket(process.env.RECOGNIZER_WSS_URL!, {
    headers: { "xi-api-key": process.env.ELEVENLABS_API_KEY! },
  });

  // Browser -> recognizer: forward binary PCM, translate control messages.
  client.on("message", (data, isBinary) => {
    if (recognizer.readyState !== WebSocket.OPEN) return;
    if (isBinary) recognizer.send(data); // raw PCM bytes
    else if (JSON.parse(data.toString()).type === "commit")
      recognizer.send(sendCommit());
  });

  // Recognizer -> browser: normalize events into a stable shape.
  recognizer.on("message", (raw) => {
    const event = parseRecognizerEvent(raw.toString());
    if (event && client.readyState === WebSocket.OPEN)
      client.send(JSON.stringify(event));
  });

  // ... open handshake, queueing pre-open audio, and teardown on close/error
});

엔드포인트별 내용은 아래 두 어댑터 함수에만 한정됩니다. 필드 이름을 텍스트 음성 변환 레퍼런스의 정확한 이름으로 바꾸면 되고, 나머지 파이프라인은 변경되지 않습니다.

// The single place that knows the recognizer's wire format.
const sendCommit = (): string => JSON.stringify({ type: "commit" });

type NormalizedEvent =
  | { type: "partial"; text: string }
  | { type: "final"; text: string }
  | { type: "vad"; speaking: boolean };

function parseRecognizerEvent(raw: string): NormalizedEvent | null {
  const msg = JSON.parse(raw);
  if (msg.is_final === true || msg.type === "final")
    return { type: "final", text: msg.text ?? "" };
  if (msg.type === "vad") return { type: "vad", speaking: !!msg.speaking };
  if (typeof msg.text === "string")
    return { type: "partial", text: msg.text };
  return null;
}

스크립트형 백엔드 클라이언트

백엔드 파이프라인과 아래 벤치마크에서는 브라우저 없이도 동일한 음성 인식기 연결을 사용할 수 있습니다. 어떤 소스에서든 PCM을 읽고, 실시간 청크 주기에 맞춰 전송한 뒤 이벤트를 다시 읽으면 됩니다. API 키와 URL은 서버와 마찬가지로 환경 변수에서 가져옵니다.

// stream-stt.ts - pace ~100ms chunks at real time, then commit the tail.
const SAMPLE_RATE = 16000, CHUNK_MS = 100;
const CHUNK_BYTES = (SAMPLE_RATE * 2 * CHUNK_MS) / 1000; // 3200 bytes
const ws = new WebSocket(process.env.RECOGNIZER_WSS_URL!, {
  headers: { "xi-api-key": process.env.ELEVENLABS_API_KEY! },
});

// Send: walk the PCM buffer in 100ms chunks, sleeping between to mimic a
// live source. For audio that already arrives in real time, drop the sleep.
async function sendAudio(pcm: Buffer) {
  for (let off = 0; off < pcm.length; off += CHUNK_BYTES) {
    ws.send(pcm.subarray(off, off + CHUNK_BYTES));
    await new Promise((r) => setTimeout(r, CHUNK_MS));
  }
  ws.send(JSON.stringify({ type: "commit" })); // finalize the trailing segment
}

// Receive: print partials in place, append finals.
ws.on("message", (raw) => {
  const e = parseRecognizerEvent(raw.toString());
  if (e?.type === "final") console.log(`[final]   ${e.text}`);
  else if (e?.type === "partial") process.stdout.write(`[partial] ${e.text}\r`);
});

음성 텍스트 변환 지연 시간 및 단어 오류율 벤치마킹

지연 시간과 단어 오류율은 화자, 언어, 음향 조건, 오디오 길이, 각 제공업체의 가장 가까운 리전까지의 네트워크 경로, 각 서비스의 현재 부하에 따라 달라집니다. 

한 도시의 노트북에서 측정한 결과를 다른 도시의 프로덕션 환경에 일반화할 수는 없습니다. 프로덕션과 유사한 인프라에서 실제 입력과 유사한 오디오로 테스트를 실행하고, 단일 수치 대신 범위와 분포를 보고하세요.

중요한 지연 시간 및 정확도 수치는 프로덕션과 유사한 인프라에서 자체 오디오로 측정한 결과뿐입니다. 다음은 음성 텍스트 변환 지연 시간 벤치마킹 가이드입니다.

음성 텍스트 변환 지연 시간에서 측정할 항목

실시간 음성 텍스트 변환 지연 시간을 벤치마킹할 때 측정해야 하는 주요 지표는 다음과 같습니다.

• 첫 부분 결과까지의 시간: 첫 오디오 청크를 전송한 시점부터 비어 있지 않은 첫 부분 결과를 수신할 때까지의 시간입니다.
• 부분 결과에서 최종 결과까지의 지연: 발화의 마지막 오디오 청크부터 최종 가설까지의 시간입니다.
• 단어 오류율(WER): 모든 시스템에서 동일한 방식으로 계산한, 사람의 참조 전사본 대비 확정 전사본의 WER입니다.
• 안정성 변동: 확정 전까지 부분 결과가 몇 번 다시 작성되는지입니다. 이 측정값은 실시간 UI가 얼마나 자주 바뀌어 보일지를 나타내는 대리 지표입니다.

통제 항목

신뢰할 수 없는 데이터를 피하려면, 일관성을 유지할 수 있도록 실험에 몇 가지 통제 항목을 적용해야 합니다.

음성 텍스트 변환 지연 시간 벤치마킹에 사용할 주요 통제 항목은 다음과 같습니다.

• 동일한 오디오: 모든 시스템에 같은 파일, 같은 샘플링 레이트, 같은 인코딩을 입력하세요.
• 동일한 전송 주기: 모든 시스템을 동일한 실시간 청크 주기(예: 100ms 청크)로 스트리밍하세요.
• 반복 실행 및 분포 보고:하루 동안 각 파일을 여러 번 실행하고 중앙값과 꼬리 지표(p50/p95)를 보고하세요.
• 동일한 참조 및 평가:WER를 계산하기 전에 텍스트를 동일한 방식으로 정규화하세요(대소문자, 문장 부호, 숫자).
• 리전 및 네트워크 공개:테스트가 실행된 위치와 각 제공업체까지의 경로를 명시하세요.

이 모든 요소를 동일하게 유지하면 더 정확한 지표를 얻을 수 있습니다.

테스트 하니스 골격

측정 코어는 제공업체 어댑터를 받아 첫 부분 결과까지의 시간, 확정 지연, 부분 결과 변동을 기록합니다.

// benchmark.ts - measurement core; one StreamFn adapter per provider.
type StreamFn = (
  audioPath: string,
  onEvent: (kind: "partial" | "final", text: string) => void,
  result: RunResult
) => Promise<void>; // adapter sets result.lastChunkSentAt on the final chunk

interface RunResult {
  firstPartialMs?: number;
  finalLagMs?: number;
  hypothesis: string;
  partialEdits: number;
  lastChunkSentAt: number;
  startedAt: number;
}

async function measure(streamFn: StreamFn, audioPath: string): Promise<RunResult> {
  const result: RunResult = {
    hypothesis: "", partialEdits: 0, lastChunkSentAt: 0,
    startedAt: performance.now(),
  };
  let prevPartial = "";

  await streamFn(audioPath, (kind, text) => {
    const now = performance.now();
    if (kind === "partial") {
      if (text && result.firstPartialMs === undefined)
        result.firstPartialMs = now - result.startedAt;
      if (text !== prevPartial) { result.partialEdits++; prevPartial = text; }
    } else { // final
      result.hypothesis = result.hypothesis ? `${result.hypothesis} ${text}` : text;
      if (result.lastChunkSentAt)
        result.finalLagMs = now - result.lastChunkSentAt;
    }
  }, result);

  return result;
}

단어 오류율은 정규화된 텍스트에 대한 표준 토큰 수준 Levenshtein 거리입니다. 계산 전에 참조문과 가설문 모두를 동일하게 소문자화하고 문장 부호를 제거해야 합니다. 그렇지 않으면 모델이 아니라 정규화기를 측정하게 됩니다. 네트워크 변동의 영향이 큰 단일 샘플 대신, 제공업체별로 각 파일을 약 10회 실행하고 첫 부분 결과까지의 중앙값과 중앙 WER(p50/p95)를 보고하는 루프로 이 측정값을 감싸세요.

실행하려면 두 가지를 준비해야 합니다. 먼저 시스템별로 StreamFn 어댑터를 하나씩 작성하세요. 위의 스크립트형 클라이언트가 이미 하나이며, 다른 어댑터도 동일한 (audioPath, onEvent, result) 계약을 따르고 마지막 오디오 청크를 전송할 때 result.lastChunkSentAt을 설정하면 됩니다. 다음으로 오디오 파일과 참조문을 불러와 전체 파일에 대해 measure를 호출하세요. 배포 환경을 대표하는 머신에서 사용자 오디오를 대표하는 입력으로 실행하면 재현 가능한 비교 결과를 얻을 수 있습니다.

실시간 음성 텍스트 변환을 구현하는 방법 요약 

이 글에서는 시스템을 점진적으로 개선하고 실시간 음성 텍스트 변환에 가까워지도록 하는 다양한 아키텍처 변경 사항을 살펴보았습니다.

프로덕션 환경의 실시간 STT 시스템은 몇 가지 핵심 결정으로 요약됩니다.

• 전송: 단순성과 제어된 네트워크가 중요하면 WebSocket을 선택하고, 손실 허용이 필요하거나 소비자 기기에서 캡처한다면 WebRTC를 선택하세요.
• 부분 결과와 최종 결과: 부분 결과는 임시 상태, 최종 결과는 확정 상태로 처리하고 다르게 표시해 사용자가 실시간 텍스트를 신뢰할 수 있게 하세요.
• 엔드포인팅: 핸즈프리 세그먼트 분할에는 VAD를, 재정의 수단으로는 수동 커밋을 사용하고, 고정 상수가 아닌 상호작용에 맞게 무음 임계값을 조정하세요.
• 스트림 내 기능: 실시간 경험에 필요한 경우에만 스트림 내 기능을 켜고, 나머지는 Scribe v2를 사용한 배치 처리로 미루세요.
• 오디오 형식: 작은 PCM 프레임으로 캡처하고 약 100ms 청크로 전송하며, 전화 오디오에는 소스 형식을 맞추세요.
• 벤치마킹: 자체 오디오와 목표 지표를 기준으로 정확도와 지연 시간의 균형을 실증적으로 조정하세요.
• API 보안: API 키를 서버에 보관하거나, 직접 클라이언트 연결에는 일회용 토큰을 발급하세요.

음성 에이전트의 지연 시간을 최적화하는 방법이 궁금하다면, 관련 가이드도 준비되어 있습니다.

Scribe v2 Realtime으로 실시간 음성 텍스트 변환 시스템 구축하기

Scribe v2 Realtime은 약 150ms의 모델 지연 시간으로 부분 결과를 제공합니다. 사용자가 이 수치를 경험할지, 더 큰 지연 시간을 경험할지는 주변 아키텍처에 달려 있으며, 이는 직접 제어할 수 있는 부분입니다. 이 글에서 소개한 전략을 적용하면 지연 시간을 줄이고 고객 경험을 개선하는 향상된 파이프라인 아키텍처를 구축할 수 있습니다. 

더 자세히 알아보려면 텍스트 음성 변환 기능 개요를 확인하고, 전체 기능 및 언어 목록은 모델 레퍼런스에서 살펴보세요. 실시간 제품 페이지도 방문해 보세요: 실시간 텍스트 음성 변환 API 및 실시간 텍스트 음성 변환.

개발을 시작할 준비가 되었다면 무료 ElevenLabs 계정 만들기를 통해 오늘 첫 전사본을 스트리밍하세요.

실시간 음성 텍스트 변환 지연 시간 FAQ