음성 에이전트 엔지니어링 - 레이턴시, 품질, 그리고 확장성
📺 원본 영상: Engineering voice agents: Latency, quality, and scale — Rishabh Bhargava, Together AI 🎙️ 채널: AI Engineer 📅 정리 일자: 2026-06-01 ⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.
개요
Together AI에서 Voice AI 팀을 이끄는 Rishabh Bhargava가 음성 에이전트를 프로덕션 수준으로 구축하기 위해 반드시 해결해야 할 기술적 과제들을 체계적으로 분석한 강연이다. 강연은 현재 업계에서 지배적으로 사용되는 파이프라인 아키텍처(STT → LLM → TTS)의 각 구성 요소를 레이턴시와 품질 관점에서 심층 분석하고, 이를 넘어서는 차세대 Speech-to-Speech 모델의 가능성과 한계를 함께 다룬다. 2026년은 단순한 데모 수준을 넘어 실질적인 엔지니어링 문제로서 고품질 음성 대화를 구현할 수 있는 시대가 시작되었음을 강연자는 강조한다.
왜 지금 음성인가 - 새로운 인터페이스의 부상
매년 수십억 건의 전화 통화가 여전히 사람의 손을 거쳐 처리되고 있다. 고객 지원 센터에 전화해 주문 현황을 확인하거나, 병원에 전화해 예약을 잡고, 그 과정에서 긴 대기 음악을 들어야 했던 경험은 사실상 모든 사람이 공유하는 보편적인 불편함이다. AI 에이전트가 이 통화들을 대신 처리할 수 있다면 그것만으로도 거대한 시장이 열리는 셈이다.
그러나 강연자가 더욱 강조하는 것은 통화 자동화보다 더 근본적인 변화다. 음성은 컴퓨터 시스템과 상호작용하는 완전히 새로운 인터페이스로 자리잡고 있다는 것이다. 인간은 글을 배우기 전에 말을 먼저 배운다. 말하기는 우리에게 가장 자연스러운 의사소통 방식이며, 이것이 ChatGPT의 Advanced Voice Mode, 그리고 Cursor나 Claude Code에 직접 말을 걸어 작업을 처리하는 방식이 빠르게 확산되는 이유다. 강연자는 2026년의 핵심 과제가 바로 이 풍부하고 고품질의 음성 대화를 구현하는 것이라고 말하며, 이는 더 이상 SF나 연구의 영역이 아니라 순수하게 엔지니어링으로 해결해야 할 문제라고 정의한다.
음성 에이전트 구축의 4대 과제
강연자는 음성 에이전트를 프로덕션에서 동작하게 만들기 위해 반드시 동시에 해결해야 할 네 가지 핵심 과제를 제시한다. 이것은 선택의 문제가 아니라 AND 조건이다. 하나라도 충족되지 않으면 실패한다.
첫 번째는 **레이턴시(Latency)**다. 인간은 대화에서 상대방의 발화에 약 300밀리초 안에 반응한다. AI가 500밀리초를 넘기면 사람들은 어색함을 느끼기 시작하고, 1~2초가 걸리면 통화를 끊어버린다. 음성 에이전트는 이 가혹한 시간 예산 안에서 모든 처리를 완료해야 한다.
두 번째는 **지능(Intelligence)**이다. 실제 업무 처리를 위해서는 복잡한 지시사항을 이해하고 모호성을 처리하며, 무엇보다 도구 호출(tool calling)을 정확하게 수행할 수 있어야 한다. 도구 호출은 에이전트가 실세계와 연결되는 유일한 통로이기 때문에, 이를 위한 기본적인 지능 수준을 충족하지 못하면 에이전트는 아무런 실질적인 역할을 할 수 없다.
세 번째는 **자연스러운 음성 품질(Voice Naturalness)**이다. 음성은 충분히 자연스럽고 듣기 좋아야 한다. 사용자의 언어와 악센트에 맞게 말할 수 있는가, 이름이나 제품명을 정확하게 발음하는가, 상황에 맞는 감정 표현이 가능한가 등 다양한 요소가 여기에 속한다.
네 번째는 **신뢰성과 확장성(Reliability at Scale)**이다. 한 명이 통화하는 데모를 만드는 것과, 100건, 1,000건, 10,000건의 통화를 동시에 처리하는 것은 완전히 다른 문제다. 규모가 커질수록 신뢰성은 단순한 품질 지표가 아니라 시스템의 생존 조건이 된다.
파이프라인 아키텍처 - 현재의 지배적 방식
오늘날 음성 에이전트를 프로덕션에서 구축하는 지배적인 방법은 파이프라인(또는 캐스케이딩) 아키텍처다. 개념적으로는 비교적 단순하다. 사용자의 오디오 청크가 스트리밍되어 Pipecat이나 LiveKit 같은 에이전트 오케스트레이터로 전달되고, 이 오디오가 Speech-to-Text(STT) 시스템을 거쳐 텍스트로 변환된 뒤 LLM으로 전달된다. LLM은 도구 호출 여부를 결정하고 텍스트 응답을 생성하며, 이 텍스트가 Text-to-Speech(TTS) 모델로 전달되어 오디오 청크를 생성하고 다시 사용자에게 스트리밍된다. 이 아키텍처의 강점은 각 구성 요소를 독립적으로 최적화하고 교체할 수 있다는 유연성에 있다.
05:00 - 파이프라인 아키텍처 다이어그램 - STT → LLM → TTS 흐름과 각 구성 요소의 연결 구조
STT (Speech-to-Text) - 에이전트의 귀
STT는 음성 에이전트의 귀에 해당한다. 여기서 중요한 두 가지 성능 지표는 **품질(Word Error Rate)**과 **레이턴시(Time to Complete Transcript)**다.
Word Error Rate(단어 오류율, WER)는 현재 최신 모델 기준으로 공개 벤치마크에서 약 6% 수준이다. 이는 생성된 트랜스크립트의 100개 단어 중 약 6개에 오류가 있다는 의미인데, 이것이 왜 중요한지는 명확하다. 누군가의 이름을 잘못 인식하거나, 약품명을 틀리게 받아들이면 LLM과 TTS가 그 오류를 그대로 전파하기 때문이다. STT 단계에서 발생한 오류는 하류 구성 요소들이 교정할 방법이 없다.
레이턴시 측면에서는 Time to Complete Transcript, 즉 사용자가 발화를 마친 순간부터 트랜스크립트가 완성되어 LLM으로 전달될 준비가 되는 시간이 핵심이다. Together AI에서 운영하는 일부 모델은 P90 기준으로 약 100밀리초를 달성하고 있으며, 이는 상당히 빠른 수준이다.
06:18 - STT 성능 지표 슬라이드 - P90 100ms 레이턴시 및 Word Error Rate 수치
STT의 또 다른 중요한 미해결 과제는 **턴 감지(Turn Detection)**다. 사람이 잠시 침묵한다고 해서 발화가 끝난 것이 아닐 수 있다. 에이전트가 너무 일찍 응답하기 시작해 상대방의 말을 끊는 것은 인간 대화에서도 불쾌한 경험이며, AI와의 대화에서는 더욱 치명적이다. 이 문제는 아직 완전히 해결되지 않았으며, 강연자는 이것만으로도 별도의 20분짜리 강연이 가능한 주제라고 언급한다.
아키텍처 측면에서도 흥미로운 진화가 일어나고 있다. 기존의 Whisper와 같은 모델은 30초짜리 오디오 클립으로 학습되었기 때문에 스트리밍 대화에 적합하지 않았고, 개발자들은 청킹(chunking), 사일런스 패딩, 다중 호출 및 결과 이어붙이기 등 복잡한 우회 로직을 구현해야 했다. 그러나 최근 NVIDIA 팀에서 개발한 새로운 모델은 이 문제를 아키텍처 수준에서 해결한다. 이 모델의 인코더는 30초 전체 대신 약 80밀리초에서 최대 1초 정도의 작은 오디오 청크만을 미리 살펴보며(lookahead), 이전 오디오 프레임의 활성화(activation)를 캐시해두어 새로운 프레임이 들어올 때 중복 연산을 피한다. 이는 스트리밍 음성 대화에 본질적으로 적합한 모델 아키텍처로의 전환을 의미한다.
08:06 - NVIDIA 스트리밍 네이티브 STT 모델 아키텍처 - look-ahead 시간 및 activation 캐싱 구조
LLM - 에이전트의 두뇌
LLM은 파이프라인의 두뇌다. 음성 에이전트에서 LLM의 핵심 성능 지표는 **TTFT(Time To First Token)**이며, 대략 200~300밀리초 이내를 목표로 한다. 이 숫자는 곧바로 모델 크기에 대한 실질적인 제약으로 이어진다.
강연자에 따르면, 음성 에이전트에 적합한 LLM의 크기는 통상적으로 80억~300억 파라미터(8B~30B) 범위다. 더 큰 모델을 사용하면 레이턴시 예산을 초과하고, 너무 작은 모델을 선택하면 지능과 도구 호출 품질이 저하된다. 이 두 가지는 모두 음성 에이전트가 실질적인 작업을 수행하는 데 필수적이기 때문에, 이 범위는 현재로서는 피하기 어려운 트레이드오프다.
09:04 - LLM 모델 크기 범위(8B~30B) 및 TTFT 200~300ms 기준 슬라이드
도구 호출(tool calling) 품질을 높이기 위해 일부 고객사들은 이 범위 내의 소형 LLM을 자신들의 특정 유즈케이스 데이터로 파인튜닝하는 방식을 선택하고 있다고 강연자는 언급한다. 범용 대형 모델의 범용성보다, 레이턴시 제약 안에서 특정 업무에 최적화된 소형 모델의 정확도를 선택하는 전략이다.
TTS (Text-to-Speech) - 에이전트의 목소리
TTS는 에이전트의 목소리다. 성능 지표로는 TTFA(Time To First Audio), 즉 텍스트를 받아 첫 번째 오디오 청크를 생성하기까지의 시간이 핵심이다. 이와 함께 **Real-Time Factor(RTF)**도 중요한데, 이는 일정 시간의 처리 시간 동안 얼마만큼의 오디오를 생성할 수 있는가를 나타낸다. 예를 들어 5초의 처리 시간에 10초 분량의 오디오를 생성한다면 RTF는 0.5다. RTF는 반드시 1 미만이어야 한다. 그렇지 않으면 실시간 스트리밍이 불가능하고 버퍼링이 발생한다.
10:01 - TTS Real-Time Factor(RTF) 설명 슬라이드 - 처리 시간 대비 오디오 생성량 비율
품질 측면에서 강연자는 객관적인 지표보다 직접 오디오 샘플을 청취하는 것이 가장 중요하다고 강조한다. 최종 고객이 경험할 목소리가 적절한 자연스러움과 감성을 전달하는지는 수치로 완전히 측정하기 어렵기 때문이다. 기능적 측면에서는 다양한 목소리, 고유명사와 제품명의 정확한 발음, 감정 태그를 통한 감정 표현 제어, 그리고 다국어 지원이 현재 주요 TTS 모델들이 경쟁하는 영역이다.
시스템 레벨 고려사항
개별 구성 요소를 최적화하는 것만으로는 충분하지 않다. 강연자는 파이프라인 전체를 시스템으로 바라볼 때 반드시 고려해야 할 몇 가지 중요한 문제들을 제시한다.
레이턴시 예산의 배분
파이프라인 전체에서 레이턴시와 비용의 대부분은 LLM이 차지하고, 그다음이 TTS, 그리고 STT 순이다. 그런데 강연자가 특히 강조하는 것은 네트워크 레이턴시가 엔진 레이턴시 못지않게 중요하다는 점이다. 각 모델이 서로 다른 데이터 센터에 위치할 경우, 데이터 전송에 드는 네트워크 왕복 시간이 전체 레이턴시에 상당한 비중을 차지하게 된다.
코로케이션(Co-location) - 30% 레이턴시 절감
13:06 - 코로케이션 레이턴시 비교 차트 - 네트워크 레이턴시 75ms vs 5ms의 30% 개선 효과
구체적인 예시를 들어보면, STT와 TTS 엔진 레이턴시가 100~200밀리초로 이미 잘 최적화된 시스템에서도, 각 모델이 에이전트 오케스트레이터로부터 물리적으로 멀리 있으면 75밀리초의 네트워크 레이턴시가 추가된다. 런던에서 음성 에이전트를 운영하면서 LLM은 미국에 있는 OpenAI 서버를 사용한다면, 대서양을 왕복하는 네트워크 지연이 그대로 사용자 경험에 반영된다.
이에 대한 해결 방향은 모델과 에이전트 오케스트레이터를 같은 데이터 센터, 가능하다면 같은 건물 안에 위치시키는 것이다. 이렇게 하면 네트워크 레이턴시가 75밀리초에서 5밀리초로 줄어드는데, 이미 최적화된 시스템에서도 이것만으로 전체 레이턴시의 약 30%를 감소시킬 수 있다. 실시간 시스템에서 10밀리초 단위의 차이가 중요하다는 것을 생각하면, 코로케이션은 선택이 아닌 필수에 가깝다. 이는 곧 오픈소스 모델을 자체 인프라에서 운영하는 것이 갖는 실질적인 이점이기도 하다.
오토스케일링(Auto-scaling)의 특수성
음성 에이전트 시스템의 오토스케일링은 일반적인 비동기 시스템보다 까다롭다. 스케일 업 측면에서는 요청이 밀리기 시작하면 사용자 경험이 즉각적으로 나빠지기 때문에 일반적인 시스템보다 훨씬 적극적이고 빠르게 증설해야 한다. 반면 스케일 다운은 더 복잡하다. 음성 대화는 상태를 가진(stateful) 장기 연결이기 때문에, 임의로 서버 인스턴스를 종료하면 진행 중인 통화가 끊긴다. 대화가 완전히 종료될 때까지 기다린 후 인스턴스를 제거해야 하므로, 인프라 자원의 효율적 회수가 구조적으로 어렵다.
차세대 방향 - Speech-to-Speech 모델
파이프라인 아키텍처가 현재의 지배적 방식이지만, 강연자는 더 단순하고 우아한 미래 방향을 소개한다. 바로 순수 Speech-to-Speech 모델이다. STT → LLM → TTS의 세 모델을 오케스트레이션하는 대신, 오디오를 입력받아 도구 호출까지 처리하고 오디오를 직접 출력하는 단일 모델을 사용하는 것이다.
15:07 - Speech-to-Speech 모델 아키텍처 비교 - 파이프라인 vs 단일 모델 구조
OpenAI의 Real-time API가 대표적 사례이며, NVIDIA도 최근 유사한 방향의 모델을 출시했다. 개념적 매력은 분명하다. STT 과정에서 텍스트로 변환되며 소실되는 음성의 뉘앙스, 즉 톤, 감정, 망설임과 같은 정보들이 그대로 모델에 전달되어 더 자연스러운 응답 생성이 가능해진다. 또한 Full-Duplex 통신, 즉 모델이 오디오를 여전히 수신하면서 동시에 오디오를 생성하는 것이 가능해져, 인간 대화처럼 “그렇군요”, “아, 네” 같은 백채널링(backchannel) 반응이 가능해진다. 상대방의 말 끊기(interruption)와 끼어들기(barge-in) 처리도 파이프라인 아키텍처에서 복잡한 엔지니어링이 필요한 것과 달리 모델이 자연스럽게 처리할 수 있다.
그러나 강연자는 현실적인 한계도 솔직하게 짚는다. 현재 대부분의 Speech-to-Speech 모델은 지시 이행(instruction following)과 도구 호출(tool calling)에서 아직 충분한 성능을 보여주지 못하고 있다. 실제 프로덕션 환경에서 이 모델들을 시도해본 팀들의 경험은 대체로 비슷하다. 프롬프트 엔지니어링으로 문제를 해결하려다 결국 파이프라인 아키텍처로 돌아온다. 하지만 이 모델들이 지속적으로 개선될 것이라는 점은 명확하며, 그 시점이 오면 음성 에이전트 구축 방식에 근본적인 변화가 일어날 것이다.
Q&A - 현장의 실전 질문들
강연 후 청중과의 질의응답에서 실제 프로덕션 구축 경험에서 나온 심도 있는 질문들이 이어졌다.
함수 호출 Eval 전략
도구 호출 유즈케이스에서 어떤 평가(eval)를 사용하고, 프로덕션 출시를 위한 합격선은 어디인가라는 질문에 강연자는 파이프라인 아키텍처를 기준으로 설명했다. STT와 TTS가 충분히 잘 동작한다는 전제 하에, LLM의 도구 호출 평가는 일반적인 LLM 도구 호출 평가 방법론과 유사하다. 도구 호출이 올바르게 이루어졌는가, 출력이 유효한가 등을 검증하는 방식이다. 강연자는 도구 호출 구조의 정확도는 거의 100%에 가까워야 한다고 언급하며, 최종 정확도 기준은 유즈케이스의 특성에 따라 달라진다는 점도 솔직하게 인정했다.
가드레일(Guardrail) 통합과 레이턴시 트레이드오프
실제 현장에서 LLM과 TTS 사이에 가드레일 모델을 삽입해야 하는 필요성에 대한 질문도 나왔다. 예를 들어 에이전트가 권한이 없는 80% 할인을 제시하지 않도록 검사하는 모델이다. 강연자는 이것이 매우 실제적인 문제라고 인정하면서, 기본 레퍼런스 아키텍처는 단순하지만 실제 프로덕션에서는 이처럼 여러 모델이 추가된다고 설명했다. LLM 앞에 분류기(classifier)를 두어 어떤 LLM(환불 처리 vs. 주문 조회)으로 라우팅할지 결정하거나, LLM 출력 이후 응답을 TTS로 보내기 전에 가드레일을 거치게 하는 방식이 모두 사용된다. 청중이 추가로 지적한 것처럼, 이미 TTS를 통해 생성된 음성 응답은 취소하기 어렵기 때문에 TTS 이전 단계에서 모든 검증을 완료하는 것이 중요하다. 가드레일이 추가될수록 레이턴시 예산에 대한 압박이 심해지며, 각 구성 요소에 명확한 SLA를 부여하고 독립적으로 스케일링하는 것이 유일한 해답이라고 강연자는 설명했다.
Thinker-Talker 패턴
가드레일 논의 맥락에서 강연자는 흥미로운 아키텍처 패턴을 소개했다. Thinker-Talker 패턴이다. 소형 LLM이 실시간 대화를 담당하는 “Talker” 역할을 하면서, 복잡한 처리가 필요할 때는 “잠시만요” 또는 “확인해볼게요” 같은 시간 벌기 응답을 생성하고, 동시에 더 크고 강력한 모델(Thinker)에 도구 호출을 발행한다. 대형 모델은 더 풍부한 지시사항과 도구, 가드레일을 기반으로 정교한 응답을 생성하고, 이것이 다시 TTS를 거쳐 사용자에게 전달된다. 이 패턴은 레이턴시 제약과 지능 수준 사이의 긴장을 아키텍처 수준에서 완화하는 실용적인 접근법이다.
Speech-to-Speech 모델에서의 관찰 가능성
Speech-to-Speech 모델로 전환할 경우 로깅과 평가(eval) 방식이 어떻게 달라지냐는 질문도 나왔다. 강연자는 일부 측면은 유지될 수 있다고 설명했다. 순수 Speech-to-Speech 아키텍처에서도 병렬로 트랜스크립션 모델을 함께 실행하여 입출력 오디오를 텍스트로 변환하면 어느 정도의 감사 가능성(auditability)을 확보할 수 있다. 그러나 근본적으로 STT, LLM, TTS 각각의 텍스트 레벨 평가는 의미를 잃게 되고, 전체 대화 흐름을 단위로 하는 Full-Duplex 대화 평가 방식으로 전환해야 한다.
마무리 - 엔지니어링으로서의 음성 에이전트
Rishabh Bhargava의 강연은 음성 에이전트가 더 이상 미래의 이야기가 아님을 명확히 한다. 레이턴시, 지능, 음성 품질, 신뢰성이라는 네 가지 조건을 동시에 충족해야 하는 이 AND 문제는 현재 STT → LLM → TTS로 구성된 파이프라인 아키텍처를 통해 실질적으로 해결되고 있으며, 코로케이션을 통한 네트워크 레이턴시 최소화, Thinker-Talker 패턴을 통한 지능-레이턴시 트레이드오프 완화 등 실용적인 엔지니어링 해법들이 축적되고 있다.
동시에 Speech-to-Speech 모델이라는 더 우아한 미래 아키텍처의 윤곽도 그려지고 있다. 텍스트로의 변환 없이 음성의 감정과 뉘앙스를 그대로 처리하고, Full-Duplex 통신을 통해 진정한 인간적 대화 경험을 제공하는 이 방향은 아직 지시 이행과 도구 호출 품질 면에서 프로덕션 수준에 미치지 못하지만, 지속적인 개선이 이루어지고 있다. 강연자의 메시지는 결국 하나다. 음성은 컴퓨터와 인간이 상호작용하는 방식을 바꾸는 새로운 인터페이스이며, 이를 구현하는 엔지니어링 과제는 지금 이 순간 해결해야 할 현실적인 문제로 우리 앞에 놓여 있다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | Engineering voice agents: Latency, quality, and scale |
| 채널 | AI Engineer |
| 강연자 | Rishabh Bhargava (Together AI, Voice AI Team Lead) |
| 리포트 작성 | 2026-06-01 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.