전체 글 지도 — 파트별 모아보기

실시간 음성 AI / Speech-to-Speech의 설계·구현·운영을 다룹니다. 레이턴시 분석부터 현장 PoC 기록, KMS 실무까지 현업 관점으로 정리한 기술 시리즈 63편.

Part 1. 레이턴시 — 음성 AI 속도의 벽 (4/4편 발행)

Cascaded 구조의 지연 원인 분석부터 스트리밍 최적화까지

Part 2. E2E S2S — 텍스트를 거치지 않는 음성 (4/4편 발행)

End-to-End S2S 구조·비교·음성 토큰·감정 표현

Part 3. 실시간·에이전트화 (5/5편 발행)

인터럽트 감지, MCP 연동, 외부 API 호출, 세션 관리

Part 4. 인프라·세션·보안 (5/5편 발행)

컨텍스트 관리, WebRTC/WebSocket, 백엔드 아키텍처, 확장성, 보안

Part 5. 운영·품질·평가 (7/7편 발행)

에이전틱 워크플로우, Eval, Observability, 가드레일, 전환, A/B 테스트

Part 6. 한국어·UX·전화망·엣지 (5/5편 발행)

한국어 음성 AI 특수성, 턴테이킹, 보이스 디자인, SIP 연동, 온디바이스

Part 7. 도입·비즈니스 관점 (4/4편 발행)

멀티모달 한계, 온프렘 vs 클라우드 경제학, 글로벌 지형도, 도입 체크리스트

Part 8. LLM 콜봇 PoC 현장기 (6/6편 발행)

STT 정확도의 함정, TTFT 최적화, SLM 트레이드오프, PoC와 운영의 괴리

Part 9. 상담어시스트 — 상담사 화면을 바꾸는 실시간 AI (7/7편 발행)

실시간 STT·인텐트·KMS 검색이 상담사 화면을 바꾸는 구조와 운영

Part 10. 롤플레이 챗봇 — 직접 만든 RAG 에이전트 구축기 (8/8편 발행)

RAG 파이프라인, 멀티 LLM 스위칭, 페르소나 설계, 채점까지 직접 만든 기록

Part 11. KMS 실무 — 지식관리시스템의 설계와 운영 현실 (8/8편 발행)

벤더 선정, 레거시 마이그레이션, 검색 아키텍처, 시스템 정합성·운영 현실

이 지도는 새 글 발행 시 함께 갱신됩니다. 마지막 갱신 2026-10-06.

댓글

댓글 쓰기

이 블로그의 인기 게시물

STT 인식률 93%의 함정 — 왜 그 숫자는 콜봇 목표가 될 수 없는가

처음엔 STT(음성 인식) 인식률 93%라는 숫자를 그대로 목표치로 가져다 써도 괜찮아 보입니다. 일반 음성 AI 벤치마크에서는 꽤 좋은 성적으로 통하는 수치이기 때문입니다. 그런데 콜봇(전화 기반 자동 응대 시스템)에 적용해 보면 이야기가 달라져, 예상보다 훨씬 큰 문제가 드러나기 시작합니다. 이 글은 왜 일반 STT 벤치마크 수치와 콜봇 실사용 요구사항이 다른지, 그리고 실무에서 최소 기준을 어떻게 잡아야 하는지를 정리한 것입니다. [시리즈] S2S·LLM 음성 에이전트 엔지니어링 63편 · 현재 8-2편 ← 이전: 8-1 LLM 콜봇 PoC — 검증의 갭 / 다음 → 8-3 금융 콜봇에서 소수점이 중요한 이유 7-4 S2S 도입 검토자가 묻는 질문 8-1 LLM 콜봇 PoC — 검증의 갭 8-2 STT 정확도 93% 목표가 부족한 이유 (현재 글) 8-3 금융 콜봇에서 소수점이 중요한 이유 8-4 TTFT 1.5초, 콜봇 스트리밍 파이프라인 설계 전체 목차 펼치기 (63편) Part 1 — 음성 AI가 느린 이유: 레이턴시 진단 (4편) 1-1 AI 보이스봇이 답답한 이유 — Cascaded 레이턴시 1-2 1초의 벽 — 지연이 UX를 결정하는 이유 1-3 지연 줄이기 — 스트리밍·청크로 TTFT 단축 1-4 RAG 병목과 오디오 버퍼링 제어 Part 2 — 텍스트를 넘어: End-to-End S2S의 원리 (4편) 2-1 End-to-End S2S 작동 원리 2-2 OpenAI Realtime API vs 오픈소스 S2S 2-3 음성 토큰(Audio Token)이란 2-4 감정·톤 조절이 CS를 바꾸는 이유 Part 3 — 실시간 대화와 에이전트화: 인터럽트·MCP·도구 (5편) 3-1 실시간 인터럽트(끼어들기) 감지 3-2 실시간 음성에 MCP가 필요한 이유 3-3 스트리밍 중 MCP 초고속 데이터 룩업 3-4 통화 중 외부 API 도구 호출 3-5 실시간 세션 관리 — 통화 맥락·...
자세한 내용 보기

AI 보이스봇이 답답한 이유: Cascaded 구조 레이턴시 완전 분석

AI 음성 상담봇과 통화해 보고 '왜 이렇게 느리냐'고 답답했던 경험이 있으신가요? 도입한 곳들의 평가는 의외로 한 곳에 모입니다. "말귀를 못 알아듣는다"가 아니라 "답답하다"입니다. 질문을 던지고 봇이 입을 떼기까지의 침묵, 길어야 2~4초인 그 공백이 통화 전체의 인상을 결정합니다. 정확도는 합격점인데 체감 만족도가 낮다면, 원인은 대부분 모델의 똑똑함이 아니라 응답 속도에 있습니다. 그리고 이 느림은 튜닝 부족이 아니라 구조에서 나옵니다. 이 글에서는 오늘날 대부분의 AI 보이스봇이 채택한 Cascaded(직렬 연결) 아키텍처를 해부하고, 레이턴시가 어느 단계에서 어떻게 누적되는지 진단합니다. [시리즈] S2S·LLM 음성 에이전트 엔지니어링 63편 · 현재 1-1편 ← 시리즈 시작 / 다음 → 1-2 1초의 벽 — 지연이 UX를 결정하는 이유 1-1 AI 보이스봇이 답답한 이유 — Cascaded 레이턴시 (현재 글) 1-2 1초의 벽 — 지연이 UX를 결정하는 이유 1-3 지연 줄이기 — 스트리밍·청크로 TTFT 단축 전체 목차 펼치기 (63편) Part 1 — 음성 AI가 느린 이유: 레이턴시 진단 (4편) 1-1 AI 보이스봇이 답답한 이유 — Cascaded 레이턴시 (현재 글) 1-2 1초의 벽 — 지연이 UX를 결정하는 이유 1-3 지연 줄이기 — 스트리밍·청크로 TTFT 단축 1-4 RAG 병목과 오디오 버퍼링 제어 Part 2 — 텍스트를 넘어: End-to-End S2S의 원리 (4편) 2-1 End-to-End S2S 작동 원리 2-2 OpenAI Realtime API vs 오픈소스 S2S 2-3 음성 토큰(Audio Token)이란 2-4 감정·톤 조절이 CS를 바꾸는 이유 Part 3 — 실시간 대화와 에이전트화: 인터럽트·MCP·도구 (5편) 3-1 실시간 인터럽트(끼어들기) 감지 3-2 실시간 음성에 MCP가 필요한...
자세한 내용 보기

음성 토큰(Audio Token)이란? LLM이 소리를 이해하는 원리

대형 언어 모델에 사람의 목소리를 그대로 넣을 수는 없습니다. LLM은 문장을 놀랍도록 잘 다루지만, 본질적으로 "다음에 올 토큰"을 맞히도록 훈련된 기계이고, 소리는 초당 수천~수만 개의 표본으로 디지털화해야 할 만큼 촘촘한 연속 신호이기 때문입니다. 둘 사이에는 반드시 번역기가 필요하며, 그 번역기의 출력물이 바로 음성 토큰(Audio Token)입니다. 이 글에서는 파형 한 조각이 어떤 과정을 거쳐 LLM이 읽을 수 있는 토큰으로 바뀌는지, 그리고 그 과정에서 어떻게 말의 내용뿐 아니라 감정과 뉘앙스까지 함께 실려 나가는지를 정리합니다. [시리즈] S2S·LLM 음성 에이전트 엔지니어링 63편 · 현재 2-3편 ← 이전: 2-2 OpenAI Realtime API vs 오픈소스 S2S / 다음 → 2-4 감정·톤 조절이 CS를 바꾸는 이유 2-1 End-to-End S2S 작동 원리 2-2 OpenAI Realtime API vs 오픈소스 S2S 2-3 음성 토큰(Audio Token)이란 (현재 글) 2-4 감정·톤 조절이 CS를 바꾸는 이유 3-1 실시간 인터럽트(끼어들기) 감지 전체 목차 펼치기 (63편) Part 1 — 음성 AI가 느린 이유: 레이턴시 진단 (4편) 1-1 AI 보이스봇이 답답한 이유 — Cascaded 레이턴시 1-2 1초의 벽 — 지연이 UX를 결정하는 이유 1-3 지연 줄이기 — 스트리밍·청크로 TTFT 단축 1-4 RAG 병목과 오디오 버퍼링 제어 Part 2 — 텍스트를 넘어: End-to-End S2S의 원리 (4편) 2-1 End-to-End S2S 작동 원리 2-2 OpenAI Realtime API vs 오픈소스 S2S 2-3 음성 토큰(Audio Token)이란 (현재 글) 2-4 감정·톤 조절이 CS를 바꾸는 이유 Part 3 — 실시간 대화와 에이전트화: 인터럽트·MCP·도구 (5편) 3-1 실시간 인터럽트(끼어들기) 감지 3-...
자세한 내용 보기