실시간 음성 에이전트 2026: STT/TTS가 아니라 ‘Audio-to-Audio’ 아키텍처 전쟁이 시작됐다

들어가며

2026년 3월 기준으로 “전화처럼 자연스럽게 끼어들고(barge-in), 끊김 없이 말하고, 짧게라도 바로 대답을 시작하는” 음성 AI가 제품 경쟁력의 핵심이 됐습니다. 단순히 STT→LLM→TTS를 이어 붙이는 수준을 넘어서, 대화의 타이밍(turn-taking)과 지연(latency) 자체가 UX를 좌우합니다.

최근 흐름은 크게 두 갈래입니다.

• Native speech-to-speech(=Audio-to-Audio): 입력도 음성, 출력도 음성. 한 세션에서 “듣기/생각/말하기”를 통합해 지연을 줄임 (예: OpenAI Realtime, Azure Voice Live, Gemini Live 계열). (platform.openai.com)
• 모듈형 파이프라인(STT→LLM→TTS): 각 컴포넌트를 최적 모델로 교체 가능. 다만 “경계 지점”이 병목이 되기 쉬움(중간 텍스트, 버퍼, 엔드포인트 탐지 등). 이를 WebRTC, streaming token, speculative 전략으로 완화.

또 한 가지 중요한 현실: 실시간 음성은 보안/프라이버시 요구가 텍스트보다 훨씬 큽니다. 브라우저/확장 프로그램이 mic 접근을 탈취할 수 있다는 사례도 보고되었고, 권한/격리 설계가 필수가 됐습니다. (itpro.com)

---

🔧 핵심 개념

1) Latency를 쪼개서 보라(“총 지연”이 아니라 “첫 반응”)

실시간 음성 UX에서 사용자가 체감하는 건 TTFV(Time To First Voice) 혹은 “첫 소리까지 걸리는 시간”입니다. 이를 구성 요소로 나누면:

1. Audio capture + transport: 마이크→네트워크(대개 WebRTC가 유리)
2. VAD/turn detection: 사용자가 말을 끝냈는지(또는 잠깐 멈췄는지) 판단
3. 인식(ASR/STT) 스트리밍: interim 결과를 얼마나 빨리 내는지
4. 추론(LLM) 스트리밍: 첫 토큰/첫 문장까지 시간
5. 합성(TTS) 스트리밍: 첫 패킷/첫 프레임까지 시간
6. Playback + barge-in: 에이전트가 말할 때 유저가 끼어들면 즉시 중단/전환

여기서 2)~5)가 특히 제품을 갈라놓습니다. 연구 쪽에서도 “첫 패킷 지연 74ms” 같은 수치로 streaming TTS의 ‘오디오 시작 속도’를 정면으로 다루는 논문이 2026년 3월에 나왔습니다(VoXtream2). (arxiv.org)
또, 빠른 응답 시작을 위해 두 경로를 병렬로 돌리는 speculative/dual-path 구조(빠른 path가 짧은 프리픽스를 즉시 말하고, 느린 path가 품질을 보강)가 제안됐습니다(RelayS2S, 2026-03-24). (arxiv.org)

2) “STT→LLM→TTS” vs “Audio-to-Audio(Realtime)”

• 파이프라인형: 모델 교체가 쉬워 최적화 여지가 큽니다. 하지만 turn detection과 경계(누적 버퍼, 문장 단위, punctuation)에서 지연/오류가 자주 납니다.
• Audio-to-Audio형: 단일 세션에서 음성을 직접 처리하니 “중간 텍스트 경계”를 줄일 수 있고, WebRTC/WebSocket으로 오디오를 스트리밍합니다. OpenAI는 Realtime API가 WebRTC/WebSocket을 지원하는 형태로 문서화되어 있고, gpt-4o-mini-realtime-preview 같은 모델을 제공합니다. (platform.openai.com)
• 클라우드 통합형: Microsoft는 Voice Live API를 “speech-to-speech를 통합 API로” 제공하며 Custom Speech/Custom Voice와의 결합을 강조합니다. (techcommunity.microsoft.com)
• Google 진영: Gemini 2.5 Flash Native Audio 업데이트를 “live voice agents” 맥락에서 다루고, 2026년에 Gemini API 쪽으로 경험을 확장하겠다고 언급합니다. (blog.google)

3) 프로덕션에서 진짜 어려운 것: Turn-taking + Interrupt

실시간 음성 대화는 “정확한 STT”보다 대화 운영이 더 어렵습니다.

• Barge-in: 사용자가 끼어들면 즉시 TTS playback 중단, 동시에 “유저 발화”를 우선 처리
• Partial results: STT interim을 어디까지 신뢰할지(너무 빨리 쓰면 환각/오해, 너무 늦으면 답답)
• Endpointing: “말 끝”을 너무 빨리 잡으면 끊기고, 늦게 잡으면 반응이 늦음
• Cost control: 항상 연결된 세션에서 “침묵 시간”과 “반복 컨텍스트 전송”이 비용을 키움(캐시/세션 설계가 중요)

OpenAI 가격표에는 Realtime 계열의 cached input 가격이 명시되어 있고(오디오 캐시 포함), 이런 비용 모델이 설계에 직접 영향을 줍니다. (platform.openai.com)

---

💻 실전 코드

아래 예제는 브라우저(WebRTC) ↔ 서버(토큰 발급) ↔ OpenAI Realtime(WebRTC) 형태의 “최소 골격”입니다. 핵심은 클라이언트가 OpenAI에 직접 붙지 않고, 서버에서 ephemeral key(단기 토큰)를 발급받아 WebRTC를 맺는 패턴입니다. (WebRTC 세부 시그널링은 문서/SDK에 따라 달라질 수 있으니, 흐름 위주로 보세요.) (platform.openai.com)

// client.js (Browser)
// 1) 마이크를 가져오고
// 2) 서버에서 ephemeral key를 받아
// 3) OpenAI Realtime과 WebRTC PeerConnection을 맺은 뒤
// 4) 오디오 트랙을 업로드하고, 내려오는 오디오를 재생한다.

async function startVoiceAgent() {
  // (A) 마이크 캡처
  const stream = await navigator.mediaDevices.getUserMedia({ audio: true });
  const pc = new RTCPeerConnection();

  // 마이크 트랙 업로드 (uplink)
  for (const track of stream.getAudioTracks()) {
    pc.addTrack(track, stream);
  }

  // (B) OpenAI Realtime에서 내려오는 오디오를 재생 (downlink)
  const remoteAudio = new Audio();
  remoteAudio.autoplay = true;

  pc.ontrack = (event) => {
    // Realtime이 음성으로 응답하면 MediaStreamTrack이 내려옴
    const [remoteStream] = event.streams;
    remoteAudio.srcObject = remoteStream;
  };

  // (C) 서버에서 ephemeral key 발급 (OpenAI API key를 브라우저에 노출하지 않기 위함)
  const keyRes = await fetch("/api/realtime-token", { method: "POST" });
  const { ephemeral_key } = await keyRes.json();

  // (D) SDP Offer 생성
  const offer = await pc.createOffer();
  await pc.setLocalDescription(offer);

  // (E) Realtime SDP 교환 (예: HTTP로 offer를 보내 answer를 받는 방식)
  // 실제 엔드포인트/페이로드는 OpenAI 문서의 Realtime WebRTC 가이드를 따르세요.
  const sdpRes = await fetch("/api/realtime-webrtc-connect", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "Authorization": `Bearer ${ephemeral_key}`
    },
    body: JSON.stringify({
      sdp: pc.localDescription.sdp,
      model: "gpt-4o-mini-realtime-preview" // 모델명은 문서/가격표 기준으로 선택
    })
  });

  const { answer_sdp } = await sdpRes.json();
  await pc.setRemoteDescription({ type: "answer", sdp: answer_sdp });

  // 이제부터는 마이크가 실시간으로 업로드되고,
  // 모델이 생성한 음성이 내려오면 ontrack으로 재생됩니다.
}

startVoiceAgent().catch(console.error);

// server.js (Node/Express) - 개념 예시
// 핵심: (1) 클라이언트에 ephemeral key 발급, (2) SDP relay(또는 시그널링) 처리
import express from "express";

const app = express();
app.use(express.json());

app.post("/api/realtime-token", async (req, res) => {
  // 여기서 OpenAI 서버에 ephemeral key 발급 요청을 보낸다고 가정
  // (정확한 API 형태는 OpenAI Realtime 문서/SDK에 맞춰 구현)
  const ephemeral_key = await issueEphemeralKeyFromOpenAI(); 
  res.json({ ephemeral_key });
});

app.post("/api/realtime-webrtc-connect", async (req, res) => {
  // 클라이언트 offer SDP를 받아 OpenAI Realtime에 전달하고 answer SDP를 받아 반환
  const { sdp, model } = req.body;

  const answer_sdp = await exchangeSdpWithOpenAIRealtime({
    offerSdp: sdp,
    model
  });

  res.json({ answer_sdp });
});

app.listen(3000);

포인트는 3가지입니다.

1. WebRTC 채택: 실시간 오디오 전송은 WebRTC가 사실상 표준(에코 캔슬/네트워크 적응/NAT traversal)입니다. (livekit.com)
2. 키 보호: 브라우저에 장기 API key를 절대 두지 말고, ephemeral/단기 토큰으로만 세션을 여세요.
3. 모델/비용 설계: Realtime 모델은 cached input 가격 구조가 있으므로, “대화 컨텍스트를 매번 풀로 보내는 방식”을 피하고 캐시/세션 전략을 고민해야 합니다. (platform.openai.com)

---

⚡ 실전 팁

1) Turn detection을 “고정 timeout”으로 하지 말 것

• 300~600ms 무음이면 끝으로 치는 단순 규칙은 언어/화자/환경에 따라 오탐이 많습니다.
• 실무에서는 VAD + punctuation 기반 endpointing + “사용자 끼어들기 우선권”을 같이 둡니다.
• 가능하면 “듣는 중에도 답을 준비”하는 구조(예: speculative prefix, partial planning)를 고려하세요. (arxiv.org)

2) TTS는 ‘품질’보다 ‘첫 소리’와 ‘중단 가능성’을 먼저 보라

• 긴 문장을 완성한 뒤 한 번에 합성하면 자연스럽지만, 실시간 대화에서는 늦습니다.
• streaming TTS(첫 패킷 지연, mid-utterance 제어 가능 여부)가 승패를 가릅니다. VoXtream2처럼 “중간에 speaking rate를 바꾸는” 제어도 제품적으로 의미가 큽니다. (arxiv.org)

3) 보안: mic 권한 + 브라우저 확장 위협 모델을 포함하라

• 음성 에이전트는 사용자의 민감정보(음성 자체, 주변 소리)를 다룹니다.
• 브라우저 환경에서는 확장 프로그램/권한 상승 이슈가 실제로 터졌습니다. 최소권한, 권한 요청 타이밍, 세션 격리, 서버 프록시/토큰 만료를 “기능”만큼 중요하게 설계하세요. (itpro.com)

4) 벤더 종속을 피하려면 ‘오디오 이벤트 인터페이스’를 표준화하라

• LiveKit 같은 프레임워크는 STT/LLM/TTS를 플러그인으로 바꾸는 접근을 강조합니다. (livekit.com)
• 추천 패턴: 내부 이벤트를 audio_in_chunk, partial_transcript, agent_partial_text, tts_audio_chunk, barge_in, tool_call처럼 정해두고, 공급자별 어댑터만 교체 가능하게 만들기.

---

🚀 마무리

2026년 3월의 실시간 음성 에이전트는 “STT 정확도 경쟁”을 넘어 대화 지연(특히 첫 소리), turn-taking, barge-in, streaming TTS가 핵심 전장입니다. 그리고 기술적으로는 WebRTC 기반 전송 + Audio-to-Audio(Reatime) 통합 모델이 빠르게 보편화되는 중입니다. (platform.openai.com)

다음 학습/실험 추천:

• OpenAI Realtime WebRTC 가이드 흐름을 따라 “브라우저↔Realtime” 최소 예제를 먼저 완주하기 (platform.openai.com)
• VAD/endpointing을 고도화하고, barge-in 시나리오(중단/재개/요약)를 제품 요구사항으로 문서화하기
• speculative/dual-path 응답 구조를 도입해 TTFV를 줄이는 실험(RelayS2S 같은 아이디어를 제품 관점으로 재해석) (arxiv.org)

원하면, 위 예제를 (1) 순수 WebSocket 기반 Realtime, (2) LiveKit Agents 기반, (3) STT/LLM/TTS 모듈형 파이프라인 3가지로 나눠서 “동일 기능을 서로 다른 아키텍처로 구현”하는 비교 튜토리얼로 확장해 드릴게요.