음성 에이전트는 듣는 것이 아니라 읽고 있습니다

생각하는 동안에는 마치 귀가 멀고 눈이 먼 것과 비슷합니다. 주변에서 무슨 일이 일어나는지 아무것도 인지하지 못하죠. -

@miramurati

대부분의 음성 에이전트가 여전히 텍스트 변환 기록(transcript)에만 의존해 판단을 내린다는 사실이 놀랍습니다.

모든 통화는 에이전트의 "사고 레이어(thinking layer)"에 도달하기 전에 오디오에서 텍스트로 변환됩니다. 이 변환 과정에서는 정보가 손실됩니다. 오직 단어만 살아남죠. 망설임, "음" 하는 소리, 문장 끝에서 떨어지는 억양, 배경 소음, 다른 사람에게 말을 걸기 위해 고개를 돌리는 순간까지 전부 사라집니다.

그래서 에이전트는 추측할 수밖에 없습니다. 상대방이 생각을 다 말하기도 전에 끼어들고, 말이 끝난 뒤에도 너무 오래 기다리며, 정중한 문장 뒤에 숨겨진 분노를 놓칩니다.

저는 이것이 오늘날 음성 AI 의 가장 큰 격차라고 생각합니다.

이 글은 현재 상황에 대한 제 관점을 담았으며, 다음 질문들을 다룹니다.

• 에이전트가 통화를 직접 듣지 못해도 제대로 판단할 수 있을까요?
• 왜 LLM 들의 연결망(web of LLMs)은 이 격차를 메우지 못했을까요?
• 왜 speech-to-speech 모델을 사용하지 않을까요?
• 실제로 '듣는' 사고 레이어는 어떤 모습일까요?

현재 시장은 어디쯤 와 있을까?

https://x.com/jordan_dearsley/status/2085602471918064064

수년간 사람들은 음성이 소프트웨어와 소통하는 보편적인 방식이 될 것이라고 예측했습니다. 2026 년, 그 예측이 현실이 되기 시작했습니다. @ElevenLabs, @DeepgramAI 같은 기업들과 800 개 이상의 음성 AI 제품 덕분에, AI 는 매년 수십억 건의 비즈니스 통화를 처리하고 있습니다.

하지만 모든 기술 물결의 초기 단계가 그렇듯, 도입 속도가 품질 향상을 앞질렀습니다. 실제 운영 환경의 에이전트에 매우 만족하는 기업은 약 5 곳 중 1 곳에 불과합니다. 따라서 대부분의 에이전트는 저렴하고 안정적인 영역, 즉 대본을 따르는 아웃바운드 콜이나 예측 가능한 단순 인바운드 요청에만 머물러 있습니다.

거의 모든 음성 에이전트는 STT(speech-to-text), LLM, TTS(text-to-speech) 순서로 이어지는 캐스케이드(cascaded) 구조입니다. 엔지니어들은 각 작업에 최적의 모델을 선택하고, 모든 중간 단계를 확인하며, 에이전트가 말하고 행동하는 방식을 세밀하게 통제할 수 있기 때문에 이 설계를 선호합니다.

STT 와 TTS 는 지연 시간과 비용 면에서 크게 발전했지만, 여전히 취약한 부분은 사고 레이어입니다.

텍스트 변환 기록이 버리는 것들

사고 레이어의 역할은 간단합니다. 대화가 현재 어떤 상태인지 파악하고, 올바른 다음 상태로 넘어가기 위한 행동(말하기, 실행하기, 전달하기, 계속 듣기)을 선택하는 것입니다.

여러분의 코드는 항상 통화가 워크플로우의 어느 단계에 있는지 알고 있습니다. 하지만 반대편에 있는 사람에게 무슨 일이 일어나고 있는지는 모릅니다. 바로 그 부분을 사고 레이어가 매 턴마다 읽어내야 합니다.

• 사용자가 말을 마친 것인가, 아니면 잠시 멈춘 것인가?
• 어떤 언어로 말하고 있는가?
• 호기심을 가진 것인가, 나쁜 서비스에 화가 난 것인가?
• 배경 소리가 TV 인가, 아이들이 노는 소리인가?
• 나에게 말하는 것인가, 옆에 있는 사람에게 말하는 것인가?
• 무엇을 원하는가: 환불, 새 계정 생성, 상태 확인?

"네, 말씀하세요."라는 동일한 텍스트 변환 기록을 가진 두 개의 오디오 클립. 하나는 에이전트에게 한 말이고, 다른 하나는 방 안에 있는 다른 사람에게 한 말입니다. 오디오만이 둘을 구분할 수 있습니다.

위의 굵은 글씨 항목들은 무엇을 말했는지뿐만 아니라 어떻게 말했는지를 알려줍니다. 텍스트 변환 기록은 단어를 남기고 억양, 속도, 멈춤, 공간감은 버립니다.

첫 번째 질문을 예로 들어보겠습니다. 우리는 침묵이 찾아오기 전에 상대가 말을 마무리하려 한다는 것을 압니다. 억양이 내려가고, 속도가 느려지며, 목소리가 잦아듭니다. 오디오를 듣는 모델은 정확히 이런 신호를 활용하도록 학습합니다(Ekstedt & Skantze, 2022). 하지만 텍스트 변환 기록만 읽는 모델은 그럴 수 없습니다. 운율(prosody) 정보는 애초에 기록되지 않기 때문입니다(Rajaa, 2026).

다섯 번째 질문도 마찬가지입니다. Apple 의 테스트에 따르면, 발화가 어시스턴트를 향한 것인지 확인할 때 텍스트 변환 기록에 오디오를 추가하면 텍스트만 사용했을 때보다 오류가 최대 39% 감소했습니다.

최고의 판단은 오디오와 텍스트를 함께 사용할 때 나옵니다. 안타깝게도 오늘날의 에이전트는 텍스트만 받습니다.

텍스트 변환 기록만 사용 시: 74.8% 의 턴에서过早하게 끼어듦. 오디오 사용 시: 7.8%. Uniphore, arXiv 2609.11066.

LLM 연결망이 벽에 부딪히는 이유

엔지니어들은 "사고 레이어"를 구축하기 위해 탐욕스러운(greedy) 해결책을 택했습니다. 즉각적인 수익을 극대화하는 가장 쉬운 길로 달려갔죠. 당시 최고의 프런티어 LLM 을 고용해 무엇을 해야 하는지 적힌 거대한 매뉴얼 하나를 넘기는 방식이었습니다. 2023~24 년 전체가 이런 식이었습니다.

여기에는 몇 가지 문제가 있습니다.

• 첫째, 팀들은 LLM 이 예측 불가능하고 느리며, 길고 빽빽한 프롬프트에서는 지시 사항을 놓친다는 사실을 깨달았습니다.
• 둘째, 단일 LLM 호출로는 발화의 의미를 이해하기에 부족합니다.

그래서 다음 논리적 단계는 더 빠르고 저렴한 LLM 들의 연결망이었습니다. 각기 다른 작업을 담당하는 LLM 들과 그 위에 오케스트레이터를 두는 구조였죠. 데모는 훌륭했습니다. 구매자들은 감탄했고 매출이 발생하기 시작했습니다.

이것이 오늘날의 프런티어 스택입니다.

하지만 실제 운영 환경에서 이 아키텍처는 두 가지 균열을 드러냈습니다.

• 모든 구성 요소가 여전히 동일한 텍스트 변환 기록을 읽습니다. LLM 을 더 많이 추가한다고 해서 이미 버려진 멈춤이나 어조를 되살릴 수는 없습니다.
• 구성 요소들이 서로를 기다립니다. 각 호출마다 지연이 발생합니다. 턴을 인식하고, 무엇을 할지 결정하며, 작업을 수행하는 데 응답 시간의 최대 80% 가 소요됩니다.

캐스케이드 방식의 음성 에이전트: 발신자의 오디오는 STT 로 가고, 여러 번의 LLM 호출을 거친 뒤 TTS 로 갑니다. 억양, 멈춤, 어조, 배경 소리, 대화 상대 정보는 STT 단계에서 모두 버려집니다.

업계는 사고 레이어를 '작업' 단위로 쪼갰습니다. 하지만 '입력' 단위로 쪼갰어야 했습니다. 오디오 신호가 필요한 판단은 오디오 네이티브 모델로 보내고, LLM 은 텍스트 작업만 하도록 했어야 합니다.

왜 텍스트 변환 과정을 아예 생략하지 않을까?

올해 speech-to-speech(STS) 모델이 본격적으로 가능성을 보여주기 시작했습니다. 매력은 분명합니다. STT, LLM, TTS 를 하나의 모델로 압축함으로써 지연 시간이 줄어들고, 대화 이해도가 높아지며, 엔지니어링 부담이 줄어듭니다.

가장 큰 단점은 통제력과 검증된 데이터의 부재입니다. STS 모델이 무슨 말을 할지 정확히 짚어낼 수 없고, 오디오로 사고하는 모델에게는 툴 호출(tool call)이나 코드 실행이 자연스럽게 다가오지 않습니다.

단기적으로 STS 는 아직 현실과 거리가 멀다고 봅니다. 발전 속도가 빨라지더라도 FAQ 답변 같은 단순한 유즈케이스에 먼저 적합할 것입니다. 빌더들은 부분적으로는 관성 때문에, 그리고 대부분은 통제력과 유연성이 필요하기 때문에 캐스케이드 방식을 유지할 것입니다.

그렇기에 저는 캐스케이드 스택을 더 쉽게 통제할 수 있게 만들고, 비용과 지연 시간 측면에서 배포 가능하게 만드는 모델을 구축하고 있습니다.

듣는 레이어

에이전트를 통제하고 불필요한 복잡성을 제거할 방법이 있다고 믿습니다. 바로 결정 모델(decision models) 입니다.

GPT-Live를 자세히 들여다보면 핵심에 결정 엔진이 있다는 것을 알 수 있습니다. 초당 여러 번, 말할지, 계속 들을지, 멈출지, 끼어들지, 툴을 호출할지 결정합니다. 캐스케이드 구조에도 이와 동일한 엔진이 필요하며, 이는 여러분이 보고 통제할 수 있는 컴포넌트여야 합니다.

결정 모델은 현재 상태와 제한된 옵션 집합(말하기 또는 대기, 에스컬레이션 또는 계속, 어떤 의도인지)을 입력받아 확률과 함께 하나의 선택지를 반환합니다. LLM 보다 훨씬 빠르고 저렴하죠. @typesafeai는 이 방식이 텍스트에서 얼마나 잘 작동하는지 보여주며 사람들을 놀라게 했습니다.

제가 제안하는 바는 다음과 같습니다.

• 결정 모델이 통화를 듣고 제한된 범위의 결정을 내립니다.
• 여러분의 소프트웨어가 워크플로우 상태, 권한, 도구를 관리합니다.
• LLM은 가장 잘하는 일을 합니다. 무엇을 할지 결정이 내려진 후 답변을 작성하는 것이죠.

결정 모델은 오디오, 지금까지의 대화 내용, 옵션 집합을 입력받아 각 옵션의 확률을 반환합니다: refund_status 0.91, cancel_order 0.06, escalate 0.03 (예시).

이 구조가 작동하게 만드는 것은 신뢰도 점수(confidence score)입니다. LLM 에게 자신이 얼마나 확신하는지 물어보면 틀렸을 때도 보통 "매우" 확신한다고 답합니다(Xiong et al., 2024). 반면 분류기의 점수는 말 그대로의 의미를 갖도록 조정할 수 있습니다. 분류기가 확신한다고 말할 때 실제로도 그런 경우가 많습니다(Guo et al., 2017).

디자인 파트너들과 진행한 초기 실험에 따르면, 에이전트 내부에서 LLM 이 수행하는 작업의 30~40% 가 라우팅, 분류(triage), 제한된 옵션 중 선택과 같은 정확히 이런 종류의 업무였습니다.

하지만 현재의 결정 모델은 텍스트나 이미지로 작동합니다. TypeSafe AI 의 보고에 따르면 Jev 를 포함한 모든 모델이 텍스트 외에 다른 모달리티가 추가되면 결정의 질이 떨어지며, Jev 에는 문서화된 오디오 지원이 없습니다.

텍스트 결정 모델에 오디오를 억지로 덧붙일 수는 없습니다. 듣는 모델을 구축하려면 세 가지가 필요합니다.

• 매 순간 올바른 결정으로 레이블링된 실제 대화 오디오
• 오디오와 텍스트를 함께 사용해 결정을 내리는 모델
• 다양한 억양, 소음, 열악한 전화 회선 환경에서도 일관되게 유지되는 신뢰도 점수

음성에 적합한 결정 모델은 곧 '듣는' 모델, 즉 오디오 네이티브 결정 레이어입니다.

결정 레이어가 들을 수 있게 되면 무엇이 달라지는가

오디오 네이티브 결정 모델이 있으면 다음 유즈케이스들이 가능해집니다.

1. 디버깅 가능한 에이전트. 많은 팀이 이제 에이전트를 상태 그래프로 설계합니다. 인사하기, 신원 확인하기, 환불 처리하기, 에스컬레이션하기 등입니다. 매 턴은 두 가지 결정으로 귀결됩니다. 대화가 실제로 어떤 상태에 있는지, 그리고 다음에 어떤 상태로 이동해야 하는지입니다. 둘 중 하나라도 잘못되면 통화 전체가 엇나갑니다.

각 단계에 결정 모델을 두면 모든 전환이 작고 설명 가능한 단위가 됩니다. 무엇을 들었고, 어떤 옵션이 있었으며, 무엇을 선택했고, 얼마나 확신했는지 알 수 있죠. 통화에 문제가 생기면 거대한 프롬프트를 디버깅할 필요가 없습니다. 미끄러진 톱니바퀴 하나를 찾아 그 부분만 고치면 됩니다.

1. 발신자가 말을 마치기 전에 준비되는 답변. 사람들은 문장을 끝내기 전에 자신이 원하는 것을 드러냅니다. "지난주에 주문한 건 때문에 전화했는데..."라는 말은 이미 주문 조회 요청입니다. 텍스트 우선 에이전트는 사용자가 말을 멈추길 기다리고, 최종 텍스트 변환 기록을 기다리고, 어떤 툴을 호출할지 결정한 뒤에야 비로소 호출합니다. 모든 단계가 침묵을 늘립니다.

"지난주에 주문한 건 때문에 전화했어요"라고 말하는 발신자의 타임라인. 텍스트 우선 에이전트는 끝까지 기다린 뒤 변환, 결정, get_order 호출을 수행합니다. 듣는 라우터는 문장 중간에 get_order 를 실행하고 발신자가 말을 멈추자마자 답변하여 시간을 절약합니다.

듣는 결정 모델은 통화를 선점하는 라우터 역할을 합니다. 문장 중간에 의도를 인식하고 사용자가 아직 말하는 동안 조회를 실행하므로, 사용자가 말을 멈추는 순간 주문 정보가 준비되어 있습니다.

Meta 와 CMU 의 연구진은 그 효과를 입증했습니다. 사용자의 발화와 병렬로 툴 쿼리를 예측하면 툴 지연 시간이 20% 단축되고 답변 정확도도 향상되었습니다.

1. 즉각적으로 느껴지는 개인 에이전트. 개인 에이전트는 하루 종일 주방, 자동차, 붐비는 거리에서 음성 메모를 통해 명령을 듣습니다. 그들이 듣는 것의 대부분은 단 한 번의 빠른 판단만 필요로 합니다. 이것이 할 일인지, 리마인더인지, 스쳐 지나가는 생각인지, 아니면 애초에 나에게 한 말이 아닌지?

모든 발화를 프런티어 LLM 으로 보내는 것은 느리고 비쌉니다. 듣는 소형 모델은 그 판단을 훨씬 짧은 시간에 내리고, 진짜 작업이 있을 때만 LLM 을 깨웁니다. 첫 번째 결정이 대형 모델을 기다리지 않기 때문에 에이전트는 즉각적으로 느껴집니다.

https://x.com/signulll/status/2077444321243013306

음성 AI 의 미래

음성은 보편적인 인터페이스가 될 것으로 기대되었습니다. 하지만 오늘날에는 대화가 예측 가능할 때만 작동합니다.

그러나 대본 없는 대화가 무한한 것은 아닙니다. 매 턴마다 합리적인 행동은 몇 가지로 한정됩니다. 말하기, 기다리기, 묻기, 실행하기, 전달하기. 아무도 대본으로 짤 수 없는 것은 그 순서뿐입니다. 대화를 통제하기 위해 대본을 짤 필요는 없습니다. 실제로 들은 내용을 바탕으로 매번 올바른 결정을 내리면 됩니다.

이것이 제가 베팅하는 변화입니다. 먼저 결정하고, 그다음 프롬프트를 넣는 것. 듣는 모델이 판단을 내리고, 여러분의 소프트웨어가 상태를 유지하며, LLM 이 문장을 작성합니다. 모든 결정은 투명하고, 빠르며, 측정 가능합니다. 이것이 실현되면 음성은 단순한 통화 채널을 넘어 사람들이 소프트웨어와 대화하는 방식이 될 것입니다.

저는 @tazolabs에서 그 결정 레이어를 구축하고 있으며, 앞으로 며칠 내에 저희 모델에 대해 더 자세히 공유하겠습니다.

음성 에이전트를 구축하고 계신다면, 여러분의 에이전트가 현재 어떤 결정에서 어려움을 겪고 있는지 듣고 싶습니다. 그리고 이 비전에 공감하신다면 Tazo Labs 에서 함께 만들어갑시다.

여러분의 음성 에이전트가 가장 자주 틀리는 결정은 무엇인가요?