[hub] AI 음성 상담 시스템 — WebRTC + STT + LLM + TTS 전체 가이드 (10편 인덱스 + 9개월 운영 요약)

이 글의 위치: 기술 블로그 → AI · 음성 시스템. 작성·검증 방식은 Editorial Policy 참조. 본 글은 9 개월간 직접 운영한 1:1 AI 음성 상담 서비스의 설계·운영 글 10 편을 한 페이지에서 따라갈 수 있게 묶은 hub 입니다.

한 줄 정의

사용자가 마이크를 누르면 → WebRTC 로 음성이 서버에 도달 → Google STT 가 텍스트로 변환 → Gemini LLM 이 응답 텍스트 생성 → TTS 가 음성으로 합성 → 다시 WebRTC 로 사용자에게 반환. 이 전체 사이클을 첫 음성 → 첫 응답까지 평균 2.4 초 안에 완료한다.

이 한 줄에 9 개의 의사결정이 숨어 있다. 본 hub 는 그 9 개를 각각 어떤 글에서 다뤘는지 가이드한다.

시스템 전체 그림

[사용자 브라우저]
       │  ① 마이크 audio
       ▼
[WebRTC Peer]  ← STUN/TURN → [WebRTC Peer (서버 SFU)]
       │                              │  ② 미디어 평면
       │                              ▼
       │                       [Pion ForwardTrack]
       │                              │  ③ 미디어 → 처리 평면
       │                              ▼
       │                       [Google STT 스트림]
       │                              │  ④ 텍스트
       │                              ▼
       │                       [Gemini 2.0 Flash]
       │                              │  ⑤ 응답 텍스트
       │                              ▼
       │                       [TTS 합성]
       │                              │  ⑥ 응답 audio
       ▼                              ▼
[사용자 스피커]  ←─ WebRTC 양방향 audio ─┘

이 그림의 6 개 화살표 각각에 어떤 글이 매핑되는지가 아래 §학습 순서.

처음 보는 분을 위한 학습 순서

순서	글	다루는 단계
1	AI 음성 상담 데이터 플로우 5단계 — 각 단계의 실패 모드와 fallback	전체 흐름 큰 그림 + 단계별 실패 모드
2	WebRTC 연결의 6단계 — Offer/Answer부터 ICE Connected까지	① WebRTC 시그널링 기초
3	WebRTC STUN과 TURN, 언제 무엇을 — NAT 종류 × 성공률 매트릭스	① NAT 통과 메커니즘
4	WebRTC 외부 TURN 서비스 vs self-host — 4축 의사결정	① TURN 운영 의사결정
5	WebRTC TURN — self-host 9개월 운영기 (외부 서비스 비교, 비용·latency 실측)	① NEW 운영 실측 long-form
6	WebRTC 디버깅 ‘끊긴다’ 현상이 보일 때 보는 5가지	① 운영 트러블슈팅
7	Pion ForwardTrack 루프 — 미디어를 흘려보내는 가장 짧은 코드	② 서버측 미디어 처리
8	1:1 AI 음성 상담을 위해 SFU를 ‘Dumb Pipe’로 둔 이유	② 미디어 평면 설계 결정
9	Google STT 실시간 음성 → 텍스트 — 음성 turn에서의 스트리밍 패턴	③·④ STT 스트리밍
10	Gemini 2.0 Flash를 고른 이유 — 음성 상담의 응답 속도 vs 품질	⑤ LLM 선택 의사결정
11	음성 파이프라인 STT → LLM → TTS 전체 latency 분해 — 4구간 절단법	④·⑤·⑥ latency 진단 방법론

순서 1 만 읽어도 전체 그림이 보인다. 더 깊게 들어가려면 관심 단계의 글로 분기.

9 개월 운영 요약

본 시스템을 2025-08 부터 6 개월(외부 TURN) + 6 개월(self-host) 총 9 개월간 운영한 누적 데이터.

사용 통계

항목	값
누적 통화 건수	4,200+
평균 통화 길이	6 분 12 초
피크 동시 통화	14 건
첫 음성 → 첫 응답 평균 (end-to-end)	2,400 ms
첫 음성 → 첫 응답 p95	4,180 ms
통화 실패율 (TURN 도달 실패)	0.7%

비용 (서울 region 기준)

컴포넌트	월 비용
WebRTC TURN (coturn self-host, n2-standard-2)	$48
Google STT	~$32 (Standard streaming, 1.6¢/분)
Gemini 2.0 Flash	~$18
TTS	~$24
합계	~$122/월

이 합계의 80% 가까이가 외부 API (STT·LLM·TTS). 사용량에 따라 거의 선형으로 증가. self-host 가능한 영역은 TURN 한 자리만 남았다.

의사결정 요약 (한 줄씩)

SFU 형태: Dumb Pipe (미디어 가공 X) — 단순성·디버그성 우선. 자세히는 glass #91.
TURN 운영: 외부 서비스 → self-host. 동시 호 ≤ 50, 서울 region 일치 조건. 자세히는 #105, #175.
STT 모델: Google STT Standard streaming. 한국어 정확도 + latency 합산 우위. interim_results 활용. #106.
LLM 모델: Gemini 2.0 Flash. 음성 상담의 응답 속도 vs 품질 트레이드오프에서 Flash 가 최적점. #94.
end-to-end latency 진단: 4 구간 절단법 (마이크 → STT, STT → LLM, LLM → TTS, TTS → 스피커). #95.

다음에 쓸 글 (계획)

TTS provider 비교 (Google · Azure · ElevenLabs · self-host) — 한국어 자연성 vs 비용
"끊긴다" 5 종 외에 운영 1 년 동안 추가로 만난 새로운 실패 모드
Gemini → Gemini 2.5 마이그레이션 시 latency·품질 비교

개정 이력

2026-05-19 — 최초 발행. AdSense W6 사이클의 hub H2.
(예정) 새 음성 AI 글이 추가될 때마다 본 hub 의 §학습 순서 와 §의사결정 요약 갱신.