[Voice AI] 음성 에이전트 아키텍처: Cascading / Streaming / S2S + Latency Budget

voice agent architecture, cascaded pipeline, streaming pipeline, speech-to-speech, latency budget, end-to-end voice

정의

실시간 음성 AI 의 3가지 패턴. 각자 지연 vs 유연성 vs 비용 트레이드오프.

3 패턴 비교

flowchart TB
    subgraph Cascading["1. Cascading (순차)"]
        C1[STT] --> C2[LLM] --> C3[TTS]
        Note1["2-4초 지연 (직렬)"]
    end
    subgraph Streaming["2. Streaming (병행)"]
        S1[STT chunks] -.partial.-> S2[LLM streaming]
        S2 -.tokens.-> S3[TTS streaming]
        Note2["< 1초 지연 (병행)"]
    end
    subgraph S2S["3. Speech-to-Speech"]
        D1[Audio In] --> D2[Multimodal Model]
        D2 --> D3[Audio Out]
        Note3["< 300ms (직접 처리)"]
    end

	Cascading	Streaming	S2S
종단 지연	2-4초	< 1초	< 300ms
구현 난이도	쉬움	중간	어려움 (제약)
유연성	최고 (각 단계 교체)	높음	낮음 (벤더 lock)
비용	낮음	중간	높음
Function calling	OK	OK	제한
톤/감정 보존	X	X	예
한국어	모델 마다	모델 마다	일부 (Realtime API 한국어)
사용	MVP / 일반	프로덕션 표준	고급 UX

1. Cascading (순차)

sequenceDiagram
    User->>STT: 발화 (3초)
    Note over STT: 발화 종료 대기 + 전사 (500ms)
    STT->>LLM: 전체 텍스트
    Note over LLM: 응답 생성 (1500ms)
    LLM->>TTS: 전체 응답
    Note over TTS: 음성 합성 (800ms)
    TTS->>User: 음성 시작
    Note over User,TTS: 총: ~3초 지연

async def cascaded_pipeline(audio_url):
    transcript = await stt.transcribe(audio_url)   # 발화 끝나길 기다림
    response = await llm.chat(transcript)           # 전체 응답
    audio = await tts.synthesize(response)          # 전체 합성
    return audio

MVP 에는 OK. 프로덕션은 streaming 으로 진화.

2. Streaming (현재 표준)

sequenceDiagram
    User->>STT: 발화 (3초)
    par
        STT-->>LLM: partial "안녕"
        STT-->>LLM: partial "안녕하세요"
        STT-->>LLM: FINAL "안녕하세요, 오늘 회의"
        LLM-->>TTS: 토큰 "오늘은"
        LLM-->>TTS: 토큰 "수요일입니다"
        TTS-->>User: 오디오 청크 1
        TTS-->>User: 오디오 청크 2
    end
    Note over User: 음성 종료 후 < 1초 응답

async def streaming_pipeline(audio_stream):
    async for transcript_chunk in stt.stream(audio_stream):
        if transcript_chunk.is_final:
            async for token in llm.stream(transcript_chunk.text):
                sentence = aggregator.feed(token)
                if sentence:
                    async for audio_chunk in tts.stream(sentence):
                        yield audio_chunk

3. Speech-to-Speech (S2S)

sequenceDiagram
    User->>Realtime: 오디오 stream (WebRTC / WS)
    Note over Realtime: GPT-4o / Gemini Live<br/>(직접 오디오 처리)
    Realtime-->>User: 오디오 stream (< 300ms)

모델	출시	한국어	특징
OpenAI Realtime API (GPT-4o)	2024-10	우수	WebRTC / WS, function calling 부분
Gemini Live (gemini-live-2.5)	2024-12	우수	Google AI Studio
Moshi (Kyutai)	OSS	영어	full-duplex, 자체 호스팅

Latency Budget (지연 예산)

flowchart LR
    Mic["마이크 (사용자 발화 끝)"] -->|VAD endpointing 200-500ms| STT
    STT -->|"STT (100-500ms)"| LLM
    LLM -->|"LLM TTFT (200-2000ms)"| TTS
    TTS -->|"TTS TTFA (200-800ms)"| Speaker
    Speaker -->|<= 1000ms| User

단계	일반	최적
Network (Mic → Server)	30-100ms	20ms
VAD endpointing	500ms	200ms (시맨틱)
STT (final)	200-500ms	100ms
LLM TTFT (Time-to-First-Token)	500-2000ms	200ms
Sentence aggregation	50-200ms	0 (streaming)
TTS TTFB	200-800ms	90ms (Cartesia)
Network (Server → Speaker)	30-100ms	20ms
총	2-4초	< 700ms

단계별 최적화

flowchart TB
    Opt[지연 줄이기]
    Opt --> S1[STT: 시맨틱 endpointing, partial 안 기다림]
    Opt --> S2[LLM: 작은 모델, TTFT 최우선, KV-cache]
    Opt --> S3[TTS: streaming + Cartesia급 모델]
    Opt --> Net[Network: WebRTC < WebSocket < HTTP]
    Opt --> Hop[Hop 축소: 같은 region, edge]

결정 트리

flowchart TD
    Q1{지연 요구}
    Q1 -->|< 300ms 필수| S2S_check{Function calling 필수?}
    Q1 -->|< 1초 OK| Stream[Streaming pipeline]
    Q1 -->|2-3초 OK + MVP| Cascade[Cascading]
    S2S_check -->|아니오| S2S[S2S 모델]
    S2S_check -->|예| Stream

한국 시장 권장

시나리오	권장
콜봇 (상담)	Streaming: CLOVA STT + GPT-4o-mini + CLOVA Voice
고급 음성 AI	Streaming: Deepgram + GPT-4o + Cartesia
비용 절감	Cascading: Whisper + GPT-3.5 + Edge TTS
톤/감정 critical	S2S: GPT-4o Realtime

흔한 함정

인프라 요구사항

네트워크

음성 에이전트는 낮은 레이턴시가 생명입니다.

프로토콜	지연	용도
WebRTC	최저	브라우저 / 모바일 클라이언트. 미디어 서버 (LiveKit, Daily) 경유.
WebSocket	낮음	서버-서버 또는 기기 연결. 텍스트/바이너리 양방향 스트림.
HTTP chunked	높음	단순 구현 가능하나 지연 큼. 프로토타입에만 권장.

VAD (Voice Activity Detection) 선택

발화 종료를 얼마나 정확히, 얼마나 빠르게 감지하느냐가 전체 latency budget 의 핵심입니다.

VAD 방식	지연	설명
에너지 기반	매우 낮음	단순 볼륨 임계값. 오탐 많음.
Silero VAD	낮음	경량 ML 모델 (5 MB). 정확도-속도 균형. 가장 많이 쓰임.
시맨틱 endpointing	중간	STT partial 결과를 LLM 으로 “문장이 끝났는가” 판단. 가장 자연스러움.

Sentence Aggregator

STT 의 partial transcript 를 LLM 에 넘길 적절한 단위로 묶는 컴포넌트.

• 너무 짧게 끊으면: LLM 이 컨텍스트 없이 처리 → 어색한 응답
• 너무 길게 기다리면: TTS 시작이 늦어짐

일반적으로 문장 완성 (마침표, 쉼표 후 길이 임계) 기준으로 aggregation.

프로덕션 체크리스트

배포 전 검증 항목:

항목	검증 방법
p50 / p95 / p99 latency	실제 통화 10,000 건 이상 메트릭 수집
Barge-in	사용자가 응답 도중 끊을 때 TTS 즉시 중단 + STT 재개
VAD 오탐 / 미탐	배경 소음 환경 테스트 (사무실, 카페)
LLM fallback	타임아웃 시 “잠시만 기다려 주세요” 응답
TTS 오류 복구	TTS API 오류 시 기본 합성 폴백
동시 세션 수	서버당 최대 동시 통화 수 부하 테스트
오디오 코덱	Opus 16 kHz mono (WebRTC 표준), G.711 (전화망)

모니터링 메트릭

flowchart LR
    Mic["사용자 발화 종료"] -->|VAD delay| STT_start["STT 시작"]
    STT_start -->|STT latency| LLM_start["LLM 호출"]
    LLM_start -->|TTFT| TTS_start["TTS 첫 청크"]
    TTS_start -->|TTFB| Speaker["스피커 출력 시작"]

추적해야 하는 메트릭:

• VAD endpointing delay: 실제 발화 종료 ~ STT 시작
• STT latency: 오디오 수신 ~ final transcript
• LLM TTFT (Time-to-First-Token): 프롬프트 전송 ~ 첫 토큰 수신
• TTS TTFB (Time-to-First-Byte): 텍스트 전송 ~ 첫 오디오 청크
• 종단 latency: VAD 종료 ~ 스피커 첫 소리

각 단계를 OpenTelemetry span 으로 기록하면 병목이 어느 단계인지 즉시 파악됩니다.

관련 위키

• STT 스트리밍
• TTS 스트리밍 + SSML
• Speech-to-Speech Realtime
• VAD Silero
• Turn Detection / Barge-in
• Latency 퍼센타일
• Pipecat + LiveKit
• Voice RAG (음성 에이전트 + RAG 결합)
• Voice-First 프롬프트 설계