Voice Agent Architecture는 음성 입력, 전사, 추론, 응답 생성, 합성 음성, 통화 제어를 하나의 흐름으로 묶는 설계입니다. 2026년 기준으로는 단순한 TTS 데모가 아니라, STT, LLM, TTS, telephony, barge-in, turn taking을 함께 설계해야 운영 가능한 시스템이 됩니다.
이 글은 voice agent architecture를 처음 잡는 팀이 무엇부터 나눠야 하는지, 어떤 컴포넌트를 어디에 둬야 하는지, 그리고 실무에서 자주 깨지는 지점을 어떻게 줄일지 정리합니다.
왜 중요한가 #
- 음성 UX는 텍스트 채팅보다 지연에 훨씬 민감합니다.
- STT, LLM, TTS를 단순히 직렬 연결하면 운영 중 병목이 바로 드러납니다.
- 전화, 웹, 앱에서 요구하는 제어 방식이 달라서 아키텍처를 미리 나눠야 합니다.
Vapi,LiveKit Agents,Retell같은 플랫폼을 비교할 때도 구조를 알아야 판단이 됩니다.
구성 요소 #
| 구성 요소 | 역할 |
|---|---|
| Audio input | 마이크, 전화, WebRTC 입력을 받습니다 |
| STT | 음성을 텍스트로 바꿉니다 |
| Orchestrator | turn taking, memory, tool 호출을 조절합니다 |
| LLM | 다음 응답과 행동을 결정합니다 |
| TTS | 답변을 다시 음성으로 합성합니다 |
| Transport | WebRTC, SIP, 전화망을 연결합니다 |
| Observability | 지연, 끊김, 실패를 추적합니다 |
음성 시스템은 이 중 하나라도 느리면 전체 품질이 떨어집니다. 그래서 agent orchestration보다 먼저 audio path와 control path를 구분하는 편이 좋습니다.
왜 주목받는가 #
- 고객지원, 예약, 콜백, 안내 같은 반복 업무를 자동화하기 쉽습니다.
voice bot은 텍스트 챗보다 체감 가치가 빨리 드러납니다.phone agent,web voice agent,call center AI로 바로 이어질 수 있습니다.
빠른 시작 #
- 입력 채널을 먼저 고릅니다. 전화인지, 웹인지, 앱인지부터 정합니다.
- STT와 TTS를 분리할지 통합할지 정합니다.
- LLM은 스트리밍 응답을 지원하는 모델로 둡니다.
- barge-in, interruption, timeout 규칙을 정합니다.
- 실패 시 fallback 문구와 human handoff를 준비합니다.
최적화 방법 #
- STT는 partial transcript를 빠르게 반환하는 구성을 우선합니다.
- TTS는 첫 음성 바이트가 빨리 나오는지를 봐야 합니다.
- LLM은 짧은 turn에서 과도한 추론을 하지 않도록 prompt를 줄입니다.
- tool 호출은 비동기로 분리해 음성 흐름을 막지 않게 합니다.
- observability는 turn 단위로 기록해서 지연 원인을 찾기 쉽게 만듭니다.
체크리스트 #
- STT, LLM, TTS, transport가 각각 어디에 있는지 정리했는가.
- interruption과 timeout 정책을 정의했는가.
- fallback, escalation, human handoff를 설계했는가.
- 전사 로그와 응답 로그를 연결할 수 있는가.
- 전화와 웹을 같은 코드 경로로 처리해도 되는지 확인했는가.
결론 #
Voice Agent Architecture는 음성 에이전트를 “만드는 것"보다 “운영 가능한 시스템으로 나누는 것"이 핵심입니다. 먼저 입력, 추론, 출력, 제어, 관측을 분리해 두면 이후에 Vapi, LiveKit Agents, Retell 같은 플랫폼을 붙이거나 교체하기가 훨씬 쉬워집니다.