2026년에 실제로 작동하는 Voice AI: FDE의 현장 해법

URL: https://www.youtube.com/watch?v=MwNvowwcZOo 날짜: 2026-08-26 채널: Latent Space (latentspacepod) 원제: ⏭️ Forward Deployed: Voice AI on what works in 2026 출연: Basil Chatha(진행), Basia Sudol(Decagon), Varun Singh(Daily), Steven Diaz(Vapi), Tyler D'Silva(Retell AI), Sudarshan Kamath(Smallest AI) 자막: YouTube 자동 생성 영어 자막(한국어 자막 요청은 429로 실패하여 영어 자막 사용)

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==2026년의 Voice AI는 멋진 단일 음성-대-음성 모델 하나로 해결되는 문제가 아니라, 정확성·가드레일·지연시간·비용·운영 신뢰성을 함께 설계하는 Forward Deployed Engineering(FDE)의 문제다.==

• 현재 기업용 음성 에이전트의 실전 표준은 음성 입력→Speech-to-Text(STT)→LLM→Text-to-Speech(TTS)로 이어지는 cascaded pipeline이다.
• Speech-to-Speech 모델은 감정과 동시성을 더 자연스럽게 다룰 가능성이 있지만, 정확성·해석 가능성·도구 호출·가드레일에서 아직 기업용 cascade를 대체하지 못한다.
• 고객지원에서 실제로 중요한 것은 데모의 순간적인 자연스러움이 아니라 잘못된 날짜·정책·상품 정보를 말하지 않고, 공급자 장애에도 통화를 멈추지 않으며, 사람의 노동비와 비교 가능한 원가로 안정적으로 일하는 것이다.

음성 에이전트는 사람이 말하는 동안 생각하고, 도구를 호출하고, 상대의 말이 끝났는지 판단하고, 필요하면 끼어들어야 한다. 그러므로 단순히 더 큰 모델을 고르는 일만으로는 충분하지 않다. 고객의 실제 통화 흐름을 관찰하는 FDE가 병목을 찾아 프롬프트·워크플로·모델·평가셋·인프라를 반복해서 조정해야 한다.

1. FDE 팟캐스트가 다루는 문제와 Voice AI 패널의 배경

1.1. Basil Chatha가 FDE를 취재하게 된 경로

1. 제품과 고객 사이를 연결해 온 경력

   1. Credit Karma 제품 매니저: Basil Chatha는 처음에 제품 매니저로 Credit Karma에서 몇 년간 일했다.
   2. 벤처 스튜디오 경험: 이후 작은 venture studio에서 일하며 초기 사업과 제품을 경험했다.
   3. Exoflop Labs 설립: 그 다음 Exoflop Labs라는 컨설팅 사업을 시작해 소매업체·보험사 등 고객을 위해 agent를 구축했다.
   4. FDE와의 자연스러운 연속성: 고객이 만들고 싶은 구체적인 사용 사례를 이해하고, 트레이드오프를 정하고, 실제 제품을 함께 만드는 일이 앞선 제품 업무의 자연스러운 확장이라고 설명했다.

2. 마케팅과 실제 작동 사이의 간극

   1. PE 고객의 혼란: 1월 무렵 몇몇 private equity firm과 일하면서, 사람들이 Twitter와 LinkedIn의 AI 소식을 따라가지만 무엇이 마케팅 BS이고 무엇이 실제인지 모르겠다고 호소하는 것을 들었다.
   2. 현장 전문가를 초대하는 방식: 그래서 멋진 회사에서 실제로 일하는 사람을 초대해 그들이 만드는 것을 깊게 파고들고, 다른 기업이 적용할 수 있는 교훈을 남기자는 취지로 fireside panel과 팟캐스트를 시작했다.
   3. 기존 에피소드: 첫 에피소드는 agentic engineering의 미래를 다뤘고 Factory, Cognition, Composio, SoundGraph 등의 회사를 초대했다. 그 밖에 voice agent, computer-use agent, enterprise agent를 주제로 구체적인 구현 세부를 다뤘다.

1.2. 패널 구성과 이번 편의 목적

1. 다섯 명의 현장 엔지니어링 리더

   1. Basia Sudol(Decagon): Head of Enterprise Solutions로 기업 고객의 음성 배포 문제를 다룬다.
   2. Varun Singh(Daily): CPTO로 Pipecat 생태계와 실시간 음성 인프라를 이끈다.
   3. Steven Diaz(Vapi): FDE Manager로 고객의 실제 음성 워크플로를 배포한다.
   4. Tyler D'Silva(Retell AI): Founding FDE로 고객 현장에 음성 시스템을 정착시킨다.
   5. Sudarshan Kamath(Smallest AI): Founder로 음성 모델과 실시간 음성 제품을 만든다.

2. 왜 Voice AI인가

   1. 뜨거운 동시에 어려운 시장: Sierra도 음성 에이전트 구축을 AI에서 가장 경쟁적인 시장 중 하나로 언급할 만큼 수요가 높다.
   2. 현실의 질문: 패널은 cascaded pipeline을 실제로 어떻게 조립하는지, 어떤 모델을 쓰는지, 지연시간과 지능 사이의 선택을 어떻게 하는지, 공급자 장애·turn-taking·다국어·프롬프트·원가를 어떻게 해결하는지 다룬다.
   3. 지원 업무가 중심: 음성 AI의 가장 큰 실전 영역은 customer support다. 수천억 달러가 투입된 거대한 콜센터 산업이지만 기존 시스템의 품질은 낮으며, 패널은 그 상태를 개선하려 한다.

3. World's Fair 사례와 FDE의 현실성

   1. 전화로 묻는 컨퍼런스 에이전트: 패널 중 한 팀은 World's Fair용 voice agent를 만들어 누군가 전화하면 컨퍼런스 질문에 답하도록 했다.
   2. 분석 데이터는 없었다: 제작자는 실제로 몇 명이 전화했는지 analytics를 보지 않아 모른다고 말했다. 사람들이 단순히 시험해 보려고 전화를 걸었을 가능성이 크다고 농담했다.
   3. 후원사의 실제 배포: Daily가 sponsor였으므로 컨퍼런스에 맞는 좋은 deployment use case를 만들어 본 것이라고 설명했다. 완벽한 대규모 사업이 아니어도 실제 환경에서 운영해 보는 일이 FDE의 핵심이다.

4. 연구자·제품 엔지니어·FDE의 시각 차이

   1. 연구자의 해법: 연구자는 더 큰 모델이 모든 문제를 해결하기를 기대하는 경향이 있다.
   2. FDE의 불만: 고객을 직접 상대하는 FDE는 “이 모델이 끔찍한 실수를 했고 다시는 일어나면 안 된다. 그것을 어떻게 보장할 것인가?”라고 묻는다.
   3. 제품의 책임: 모델이 아직 충분히 좋지 않거나 영원히 완벽해지지 않을 수 있다는 사실을 인정하고도 고객지원 시스템을 운영해야 한다. FDE는 모델의 가능성보다 실패의 재발을 통제하는 사람이다.

2. 2026년 Voice AI의 기본 구조: Cascade

2.1. 가장 단순한 파이프라인

1. 입력과 transport

   1. 음성 입력: 사용자의 음성은 WebRTC, 전화 통화, WebSocket 같은 transport를 통해 들어온다.
   2. 전처리: background-noise removal과 voice isolation 모델이 배경 소음을 제거하고 여러 사람이 있는 foreground에서 한 사람의 목소리를 분리한다.
   3. STT: Speech-to-Text 모델이 음성을 transcription으로 바꾼다.

2. turn detection이 필요한 이유

   1. Enter 키가 없다: 텍스트 채팅에서는 사용자가 Enter를 누르면 발화가 끝났다는 신호가 전달되지만, 음성에는 walkie-talkie나 push-to-talk 같은 명시적 종료 신호가 없다.
   2. 시각 정보의 한계: 상대의 얼굴을 볼 수 있다면 말이 끝났는지 볼 수 있지만, 전화와 일반 음성 인터페이스에서는 불가능하다.
   3. VAD와 smart turn: Voice Activity Detection(VAD)과 smart-turn 모델이 단순히 잠깐 멈춘 것인지, 문장을 끝내고 응답을 기다리는 것인지 판단한다. 문장 중간의 pause와 발화 종료 후 pause를 구분하는 일이 생각보다 어렵다.

3. 추론과 출력

   1. LLM 호출: transcription 텍스트를 LLM에 보내면 LLM은 답변을 추론하거나 필요한 tool call을 결정한다.
   2. TTS: 전체 또는 스트리밍된 텍스트를 Text-to-Speech(DDS/TTS)로 변환한다. TTS는 보통 real time보다 빠르게 생성된다.
   3. 재생: 생성된 음성을 같은 transport로 최종 사용자에게 stream하고 스피커에서 재생한다.

2.2. Outbound와 inbound의 구조적 차이

1. Outbound가 상대적으로 쉽다

   1. Debt collection 예시: 채무 추심 전화는 미납액을 알리고 지불 여부나 정해진 선택지를 묻는 좁은 workflow로 설계할 수 있다.
   2. 명확한 입력 경계: 허용할 입력과 응답하지 않아도 되는 입력을 미리 정할 수 있다.
   3. 통화를 끊을 권한: 사람이 갑자기 엉뚱한 말을 하거나 workflow 밖으로 나가면 bot이 통화를 종료할 수 있다. Outbound bot은 통화를 계속 유지해야 할 의무가 없다.
   4. 실패 양상: 반대로 outbound 전화는 상대가 bot임을 알아차리는 순간 바로 끊어 버리는 경우가 많다. 팀이 직접 outbound use case를 운영해 보면서 이 문제를 확인했다.

2. Inbound가 어렵다

   1. 호출자의 정체와 목적을 모른다: 꽃집·동네 가게처럼 할 수 있는 일이 유한한 사업은 그나마 쉽지만, 전화를 건 사람이 왜 전화했는지 bot은 사전에 알 수 없다.
   2. Amazon 규모의 분기: Amazon처럼 수십억 개의 상품과 상품별 반품·배송·정책이 있는 서비스는 물리 상품인지, 저가인지 고가인지, 전자제품인지 등에 따라 답변이 달라진다.
   3. 모든 정책을 하나의 프롬프트에 넣을 수 없다: 단일 프롬프트에 모든 정책을 넣으면 LLM이 프롬프트의 첫 4%와 마지막 4%는 기억하고 중간 내용은 잊는 듯한 문제가 생긴다. 중간에 있는 반품 정책은 쉽게 hallucination을 일으킨다.

3. 대화 상태를 계속 유지해야 한다

   1. Compaction: 긴 대화를 요약·압축하는 compaction model이 필요하다. 코딩 에이전트가 context window가 차기 전에 작업을 저장하고 압축하는 것과 같은 문제다.
   2. 25%부터 긴장한다: 1 million-token context model을 써도 25% 사용 시점부터 compaction을 고민해야 한다. 70%에 이르기를 기다리면 이미 시스템이 궤도를 이탈할 수 있다.
   3. 음성 AI가 먼저 겪은 문제: 음성 AI 팀은 모델이 50,000·250,000 token 정도로 작던 시절부터 5~10턴, 10,000 token만 되어도 모델이 망가지는 현상을 다뤘다. 최근 코딩 에이전트가 겪는 compaction 문제보다 한 세대 앞서 해결해 온 셈이다.
   4. 짧은 턴과 발화량: 음성 대화의 turn은 짧지만 bot이 사람보다 더 오래 말하기 쉽다. 따라서 사람의 말이 무엇이었고 대화가 어디까지 왔는지 매 턴 정확히 추적해야 한다.

3. Cascade 대 Speech-to-Speech

3.1. 왜 단일 Voice-to-Voice 데모만으로는 부족한가

1. 데모의 매력

   1. 자연스러운 감정: Voice-to-Voice 데모는 사용자의 웃음과 말투에 반응하고, 빠르게 답하는 것처럼 들린다.
   2. 청각적 인상: 짧은 대화에서는 매우 snappy하고 사람의 tone을 이해하는 듯해 기술이 완성된 것처럼 보인다.

2. 사실성 오류의 사례

   1. 예약 날짜 질문: 모델이 어느 날 예약할지 묻고 사용자가 “다음 주”라고 답하자, 모델이 “6월 10일이 맞나요?”라고 되묻는다.
   2. 연도 정정: 사용자가 “아니, 연도는 2030년이다”라고 고치면 모델은 “맞다, 2030년이다. 2030년 6월 10일로 예약하겠다”고 동의한다.
   3. 핵심 문제: 2026년의 실제 날짜와 맞지 않는 내용을 그럴듯한 말투로 확인해 주는 것이 음성 지원 업무에서는 자연스러움보다 훨씬 치명적이다.

3. Cascade의 통제력

   1. Supervisor 단계: 입력을 supervisor model에 통과시켜 prompt injection과 social engineering을 감지할 수 있다.
   2. Intent selection: 다음 단계에서 사용자 의도를 선택하고, 고객 유형과 현재 workflow에 맞는 조건을 확인한다.
   3. Context optimization: 적용할 prompt와 정책만 골라 compact·compile하여 message-generation model에 전달한다.
   4. 사후 검증: LLM 응답이 사실에 근거하는지, 2030년이 맞는지, 현재 정책과 일치하는지 확인한 후 음성으로 내보낼 수 있다.

3.2. Cascade의 가격은 지연시간이다

1. Conveyor belt 문제

   1. STT, 감독 모델, 의도 선택, 조건 확인, LLM, 검증, TTS가 이어지므로 내부에서는 많은 일이 진행된다.
   2. 각 단계를 순차로 기다리면 사용자는 긴 침묵을 듣게 된다. 따라서 가능한 단계를 병렬화해야 한다.

2. 10ms씩 줄이는 엔지니어링

   1. Decagon 팀은 최근 약 6개월 동안 pipeline의 각 부분에서 10ms씩 지워 나가는 작업을 반복했다.
   2. 겉으로는 단순히 대화하는 것처럼 보여도, 뒤에서는 병렬화와 캐시·스트리밍·분기 최적화로 많은 단계를 수행한다.
   3. 성능 최적화의 목표는 단계 수를 숨기는 것이 아니라, 통제력을 유지하면서 사용자가 snappy하다고 느끼게 만드는 것이다.

3. Speech-to-Speech의 출발점

   1. 감정 정보 보존: STT로 바꾸는 순간 사용자가 “음”이라고 말한 감정이 슬픈지 흥분했는지 일부 손실될 수 있다. 이 문제가 speech-to-speech 연구를 자극했다.
   2. 인간 뇌의 비동기성: 사람은 상대가 말하는 동안 이미 생각을 만들고, 너무 오래 말하면 끼어들며, 뒤에서 메모하거나 도구를 호출한다. 말이 끝난 뒤에야 생각하는 cascade는 이런 비동기성을 그대로 재현하지 못한다.
   3. 자연스러운 통과 테스트: 인간의 뇌가 작동하는 방식에 가까워지려면 speech를 native하게 받아 speech를 native하게 비동기 출력하는 구조가 필요하다는 설명이다.

3.3. Hydra와 Speech-to-Speech의 미완성 지점

1. Hydra의 설계

   1. Smallest AI는 Hydra라는 speech-to-speech model을 구축하고 있다.
   2. 초기 speech-to-speech 모델이 speech를 받아 speech만 내보냈다면 Hydra는 speech와 text를 모두 입력·출력으로 다루는 multimodal 구조다.
   3. text를 병렬로 받아 tool call을 수행할 수 있으므로, 음성의 자연스러움과 기업 시스템의 통합을 함께 겨냥한다.

2. 정확성과 해석 가능성의 교환

   1. 새로운 architecture는 한 parameter에서 좋아지는 대신 다른 parameter에서 퇴보하는 경우가 많다.
   2. 전문 STT 모델의 정확도가 speech-to-speech encoder보다 높을 수 있다. 자연스러움이 늘어도 정확성 기준을 유지해야 한다.
   3. Black box를 그대로 운영할 수 없으므로 어디가 부족한지 해석 가능하게 만드는 연구가 중요하다.

3. 기업 도입의 현재와 미래

   1. 지금 기업 환경에서는 여전히 speech-to-speech보다 cascaded deployment가 훨씬 많다.
   2. Speech-to-speech는 장기적으로 도달할 방향이지만, 단기에는 두 구조가 경쟁하다가 hybrid로 수렴할 가능성이 크다.

3.4. Hybrid와 specialized model의 중간 해법

1. 대화 loop와 복잡한 작업 분리

   1. 사람과 주고받는 active loop는 speech-to-speech가 계속 유지한다.
   2. 상품 조회처럼 복잡한 lookup이 필요하면 다른 LLM에 위임해 cascade 작업을 수행한다.
   3. speech-to-speech model은 복잡한 질문임을 알아차리는 순간 응답을 중단하거나 semaphore/thread를 통해 cascade에 넘길 수 있다.

2. 사람의 autopilot을 모델에 매핑

   1. 사람도 자기가 일하는 시간의 약 50%를 별다른 숙고 없이 autopilot으로 처리한다.
   2. 고객과 고용량으로 운영하기 시작하면 그 반복 업무를 완전히 이해하는 specialized model을 학습시킬 수 있다.
   3. 예를 들어 “반품 정책이 무엇인가?”라는 질문의 단순한 답은 대부분의 SKU에 동일하게 적용될 수 있다.
   4. 정책이 적용되는 상품·SKU를 알고 있으면 70% 정도의 질문은 즉시 답하고, 범위를 벗어난 질문만 복잡한 cascade와 검색으로 보낸다.

4. 모델 선택과 파이프라인 병렬화

4.1. Frontier LLM의 실전 선택

1. Thinking을 끈 빠른 모델

   1. 음성 응답의 첫 단계 모델은 깊게 생각하기보다 prompt에 빠르게 반응해야 한다.
   2. Thinking을 끄면 GPT 계열이나 Opus·Sonnet 같은 frontier model도 실시간 흐름에 맞출 수 있지만, 실제 지연시간은 여전히 점검해야 한다.

2. 패널의 경험적 선호

   1. Gemini 2.5는 매우 빠르고, 당시 새로 나온 Gemini 3.5는 더 느리지만 사용할 만하다는 평가가 있었다.
   2. Claude Haiku도 매우 좋다고 평가받았지만, 기대하는 실시간 속도보다는 여전히 느릴 수 있다.
   3. 결론은 최신·최대 모델이 아니라 해당 workflow에서 정확성과 속도를 함께 만족하는 모델을 찾아야 한다는 것이다.

4.2. 순차 pipeline을 병렬화하는 방식

1. 입력의 fork

   1. Speech-to-speech 모델에 음성을 직접 보내는 동시에 다른 branch로 STT를 실행할 수 있다.
   2. STT text가 나오면 그 결과를 여러 LLM으로 fork해 각각 판단하게 할 수 있다.

2. Waterfall과 gate

   1. 여러 모델의 결과가 내려오는 waterfall의 바닥에 gate를 둔다.
   2. 모든 모델이 같은 판단을 내리면 downstream LLM을 호출하고, 불일치하면 더 나은 모델이나 추가 검증으로 보낸다.
   3. 필요한 경우 매우 복잡한 multi-model 구조까지 만들 수 있다는 농담이 나왔다. 예전에는 20년 동안 할 일이 없었지만 이제 20년 전의 상상 같은 복잡한 시스템을 실제로 만들 수 있다는 식의 유머였다.

3. 병렬화의 한계

   1. 최종 답변 text를 알기 전에는 TTS를 완전히 생성할 수 없으므로 모든 단계를 병렬화할 수는 없다.
   2. 대신 의도 분류, 안전성 검사, 검색 준비, filler 생성처럼 결과를 기다리지 않아도 되는 작업을 먼저 실행한다.
   3. 정확성과 안정성을 위해 결국 gate와 후속 LLM이 필요한 경우가 있으므로, 병렬화는 지연시간을 줄이되 검증을 없애는 방법이 아니다.

5. 다국어·억양·음성 품질

5.1. English-first Speech-to-Speech

1. 변수를 줄이는 전략

   1. Speech-to-speech 팀은 현재 영어 지능과 품질에 집중하고 있다.
   2. 이미 asynchronous speech-to-speech 자체가 frontier 기술이라서 다른 언어라는 변수를 동시에 추가하지 않겠다는 판단이다.

2. Cascade의 지역별 수요

   1. 인도에서 큰 수요가 있고, Latin America에서도 많은 수요가 있다.
   2. 미국은 대부분 영어지만 스페인어와 다양한 accent가 함께 존재한다.
   3. 미국의 억양 처리에서 큰 기술적 장애는 없었고, 마지막으로 남은 어려운 문제는 noise cancellation에 가깝다는 평가가 나왔다.

5.2. 일본·아랍어 사례가 보여 주는 교체 가능성

1. 일본 배포에서 드러난 한계

   1. 일본 고객에게 OpenAI 4.1이나 Deepgram transcriber를 붙이는 것은 잘 작동했다.
   2. 그러나 영어·스페인어·포르투갈어 중심 시장에서 state-of-the-art라고 생각했던 voice 모델은 일본어에서 전혀 잘 작동하지 않았다.
   3. 특정 언어에서 한 component가 실패하면 전체를 다시 만드는 대신 cascade의 해당 component만 교체할 수 있어야 한다.

2. Customer-provided TTS

   1. Vapi는 고객이 custom Text-to-Speech server를 가져오도록 허용한다.
   2. 각 시장에는 특정 언어와 문화에 특화된 startup 또는 lab이 있고, 그들의 음성 모델이 브랜드명·주소·고유 발음을 더 잘 처리할 수 있다.
   3. 모든 시장과 사용 사례의 발음을 한 플랫폼이 직접 최적화하는 것은 현실적으로 불가능하므로 modular cascade가 유리하다.

3. Arabic의 난점

   1. 아랍어는 브랜드명과 주소를 정확히 발음하는 일이 특히 어렵다.
   2. 단순히 언어를 지원한다고 선언하는 것과 실제 고객의 고유명사를 자연스럽고 정확하게 읽는 것은 다른 문제다.

6. Sesame의 데모와 하드웨어 전략

6.1. 사라진 것처럼 보이는 Voice-to-Voice 회사

1. 강렬한 초기 데모

   1. Sesame는 매우 인상적인 voice-to-voice 데모를 공개했지만 이후 제품 소식이 거의 들리지 않았다.
   2. 패널은 업계에서 이 회사가 무엇을 하고 있는지 질문받았다.

2. 하드웨어 집중

   1. 들은 바에 따르면 Sesame는 음성을 어떤 하드웨어에 넣는 작업을 하고 있다.
   2. 안경인지 다른 기기인지는 확실하지 않지만, 채용된 사람들이 hardware와 voice 배경에 집중하고 있다는 설명이 나왔다.
   3. CEO가 이미 많은 돈을 벌었고 그냥 재미로 실험하고 싶어 한다는 전언도 소개됐다. 그래서 원하는 방향으로 무엇이든 할 수 있다는 농담이 이어졌다.

7. 거대한 System Prompt인가, Workflow인가

7.1. Inbound의 graph·node 방식

1. 예측 가능한 흐름

   1. Inbound에서 전용 전화번호와 비교적 예측 가능한 목적지가 있다면 대화가 어느 workflow로 갈지 더 잘 알 수 있다.
   2. 이 경우 node나 graph builder를 사용해 질문·인증·조회·완료 단계를 명시적으로 연결하는 방식이 적합하다.

2. 필요한 정보만 당겨오기

   1. 알고 있는 시점에 특정 knowledge가 필요하므로 웹사이트와 문서 전체를 매번 prompt에 넣을 필요가 없다.
   2. 현재 node에서 필요한 컨텍스트만 추출하면 지연시간과 hallucination 가능성을 함께 줄일 수 있다.

7.2. Outbound의 중앙 두뇌와 검색

1. 예측 불가능한 호출자

   1. Outbound의 caller는 화를 낼 수도 있고, 짜증을 낼 수도 있고, 전혀 예상하지 못한 방식으로 반응할 수 있다.
   2. 그러므로 고정된 전용 flow만으로는 부족하고 다양한 prompt component를 조합할 수 있는 중앙 brain이 필요하다.

2. Knowledge base와 cosine similarity

   1. Outbound에서는 어떤 지식이 필요할지 사전에 정하기 어렵기 때문에 웹사이트·문서 등 더 많은 자료를 검색 대상으로 활용한다.
   2. Cosine similarity 같은 retrieval 기준으로 관련 context를 찾아야 하며, 검색 결과가 충분히 정확하다는 전제에서 답변한다.

7.3. 모델이 좋아질수록 바뀌는 Prompt 전략

1. 조건부 Prompt의 초기 해법

   1. 약 7개월 전에는 frontier LLM이 긴 절차의 4A1 같은 중간 단계를 반복해서 건너뛰었다.
   2. 그래서 execution engine이 prompt와 guideline을 전부 넣기 전에 현재 상황에 관련 있는지 판정하고, 관련 항목만 system prompt에 포함하는 방법을 썼다.

2. 모델 개선에 따른 회귀

   1. 모델이 좋아지면서 무엇이 관련 있는지 판단하는 전처리 단계가 오히려 모델 자체에 모든 정보를 주는 것보다 신뢰성이 낮아지는 경우가 생겼다.
   2. 최근에는 다시 모든 자료를 모델에 주고 모델이 알아서 선택하게 하는 방향으로 조금씩 돌아가고 있다.
   3. 어느 방식이 절대적으로 옳은 것이 아니라 고객별 사용 사례와 모델 버전에 따라 달라진다.

3. 검증은 끝나지 않는다

   1. 비결정적(nondeterministic) 시스템에서 진짜 답은 먼저 만들고, 반복해서 테스트하고, LLM-as-a-judge로 작동 여부를 평가하는 것이다.
   2. 신뢰성이 부족하면 preprocessing과 context optimization을 추가하고 다시 테스트한다.
   3. “테스트하고 알아내고, 다시 테스트하고 다시 알아내는” 과정이 운영의 기본이며 한 번의 프롬프트 설계로 끝나지 않는다.

8. Latency, Filler, 안정성, 비용

8.1. 좋은 지연시간의 정의가 계속 바뀐다

1. 고객 기대치의 상승

   1. Voice agent latency benchmark에서 좋은 수치의 기준은 계속 좋아지고 있다.
   2. 고객이 한 번 빠른 모델을 경험하면 다음 배포에는 더 낮은 지연시간을 요구한다.

2. Filler는 반드시 나쁜 것이 아니다

   1. 사람이 생각할 때 “음”, “잠시만” 같은 말을 하는 것은 정상적인 대화다.
   2. Contextual filler가 전혀 없으면 bot이 오히려 딱딱하고 비인간적으로 들릴 수 있다.
   3. 큰 prompt를 처리하거나 고객 API tool call을 기다리는 동안 “잠시만요, 확인해 볼게요”라고 말하면 5초의 침묵보다 자연스럽다.

3. Filler의 품질이 새 병목이다

   1. Filler를 무조건 삽입하는 것이 아니라 실제로 지연이 생길 때만 사용해야 한다.
   2. 삽입한다면 문맥과 말투가 자연스럽고 반복되지 않아야 한다.
   3. 실행 엔진의 목표는 filler가 아예 필요 없는 상황을 늘리면서, 필요한 순간에는 매우 좋은 filler를 생성하는 것이다.

8.2. 성능·안정성·신뢰성의 영구적인 트레이드오프

1. 가장 어려운 배포 문제

   1. 패널은 voice deployment에서 performance와 stability·reliability의 균형이 가장 어려운 문제라고 평가했다.
   2. 더 큰 prompt와 더 복잡한 추론은 edge case 대응력을 높일 수 있지만 응답을 늦춘다.

2. 전문화한 Sub-agent

   1. Vapi의 collections 사례에서는 10~15단계 workflow 전체를 매번 하나의 prompt에 넣지 않는다.
   2. 신용카드 정보를 수집해야 하는 특정 순간에만 specialized agent로 전환한다.
   3. 목표를 달성하면 긴 context가 있는 보다 자유로운 대화 agent로 돌아간다.

3. 작은 모델의 선행 분류

   1. 하나의 큰 모델이 모든 결정을 순서대로 내리게 하는 대신, 작은 language model을 pipeline 앞에 stream해 intent classifier로 사용할 수 있다.
   2. 작은 모델이 빠르게 의도를 분류하는 동안 음성 agent는 자연스러운 filler를 내보내고, 뒤에서 더 지능적인 작업을 시작한다.
   3. 이 waterfall·background-process 방식은 지연을 숨기면서도 복잡한 답변의 품질을 유지하려는 연구 방향이다.

4. Token 비용까지 함께 계산해야 한다

   1. 많은 outbound call은 시작 후 10초 안에 끊긴다.
   2. 거대한 prompt를 매번 LLM에 보내면 상대가 답하기도 전에 끊은 통화에 대해서도 모든 input token 비용을 지불한다.
   3. Prompt를 쪼개는 방법은 latency뿐 아니라 이런 낭비를 줄여 unit economics를 개선한다.

9. 장애 대응, 평가, FDE 운영

9.1. 모델 공급자 장애를 전제로 한 Waterfall

1. 단일 모델 의존의 위험

   1. 어떤 LLM provider의 infrastructure가 안정적이지 않을 수 있다.
   2. “Opus가 내려가면 어떻게 하는가?”라는 질문처럼, 주 모델이 멈추면 voice agent 전체가 중단될 수 있다.

2. Fallback model cascade

   1. 여러 모델을 waterfall로 배치해 첫 모델이 실패하거나 지연되면 다음 모델이 응답을 이어받게 한다.
   2. 음성 통화에서는 침묵이 곧 실패로 느껴지므로, fallback과 filler를 함께 설계해야 한다.
   3. Self-hosted model을 두면 사용량에 따라 scale up·scale down을 직접 제어할 수 있다.

9.2. Turn-based 공개 Benchmark

1. 공개 평가 도구

   1. Pipecat 쪽은 turn-based STT benchmark, LLM benchmark, TTS benchmark를 공개한다.
   2. 각 benchmark의 turn과 tooling이 open source이므로 새 모델이 나올 때 동일한 대화를 다시 실행할 수 있다.

2. 자체 인프라 비교

   1. 로컬에서 benchmark를 실행하거나 그래프의 출력과 자기 인프라의 출력을 비교할 수 있다.
   2. LLM만 평가하고 싶으면 STT와 TTS를 제외하고 LLM inference loop만 돌려 고객 workflow에 맞는 모델을 점검할 수 있다.
   3. 모델 이름이나 단일 데모보다 실제 turn 집합에서의 결과가 중요한 이유다.

9.3. 고객 대화 자체를 Eval로 바꾸는 FDE

1. 배포 전 테스트

   1. 고객과 대화하면서 어떤 conversation type과 workflow가 생길지 파악하면 아직 live가 아니어도 직접 평가 항목으로 바꿀 수 있다.
   2. 고객이 “이런 통화가 일어날 것”이라고 말한 내용을 eval suite에 넣고 smoke test를 실행한다.

2. 클라우드와 협업하는 엔지니어

   1. 팀은 이미 클라우드에서 평가와 실행 환경을 운영하고 있다.
   2. FDE는 고객 미팅 내용을 가져와 “이 대화 정보로 smoke test를 만들어 달라”고 요청할 수 있다.
   3. 이런 테스트는 고객이 실제 사용 의사를 밝히기 전에도 위험한 edge case를 발견하게 해 준다.

3. LLM-as-a-judge의 역할

   1. 성공 여부를 사람이 매번 듣는 대신 LLM judge가 답변의 사실성·절차 준수·신뢰성을 판정한다.
   2. 단, judge도 결정적이지 않으므로 한 번의 평가가 아니라 반복 실행과 고객별 기준이 필요하다.

10. 비용·지연·신뢰성을 함께 잡는 모델 운영

10.1. Small language model과 자체 모델

1. 고객이 조합하는 구조

   1. Smallest AI는 모델만 제공하는 것이 아니라 여러 모델을 platform에서 orchestration한다.
   2. 많은 고객은 Smallest 모델을 자사 small language model과 조합한다.

2. Realtime Voice용 Fine-tuning

   1. 고객은 작은 모델을 fine-tune해 실시간 음성의 intent·지식·대화 memory에 맞춘다.
   2. GPT-4o·GPT-4.1 같은 인기 realtime model과 비교해 knowledge base와 memory를 더 잘 맞출 수 있다.

3. 운영 이점

   1. 작은 모델은 비용이 낮다.
   2. 추론 지연시간도 훨씬 낮다.
   3. 특정 workflow에 맞게 조정하면 더 안정적일 수 있다.

10.2. API 변동성 대 Self-hosting

1. 공용 API의 latency spike

   1. OpenAI API는 특정 시점에 latency가 급등할 수 있고, 고객은 그 지연을 직접 통제할 수 없다.
   2. 음성 통화에서 이런 변동은 같은 평균 latency라도 사용자가 체감하는 품질을 크게 떨어뜨린다.

2. Self-hosted의 제어권

   1. 자체 호스팅하면 요구량에 따라 capacity를 scale up·scale down할 수 있다.
   2. 모델 크기와 하드웨어를 workflow에 맞추고, provider의 순간적인 spike에 덜 의존할 수 있다.
   3. 따라서 최첨단 모델의 지능만이 아니라 비용·SLA·예측 가능한 지연시간이 기업 음성 시스템의 모델 선택 기준이 된다.

주요 발언 모음

“음성 에이전트의 현재 state-of-the-art는 cascaded pipeline이다. Speech-to-Text, LLM, Text-to-Speech의 세 단계로 간다.”

“연구자는 더 큰 모델이 모든 문제를 해결하길 바라지만, FDE는 ‘이 끔찍한 실수가 다시는 일어나지 않는다는 것을 어떻게 보장할 것인가?’라고 묻는다.”

“사람의 뇌는 듣는 동안 생각한다. 너무 오래 말하면 끼어들고, 뒤에서 메모하거나 도구를 호출한다. 그래서 결국 비동기적으로 작동해야 한다.”

“모델을 믿고 모든 것을 한 번에 주든, 상황별로 잘라 주든 정답은 고객별로 다르다. 실제 답은 만들고, 많이 테스트하고, 다시 테스트하는 것이다.”

“성능과 안정성·신뢰성 사이의 트레이드오프는 음성 배포에서 가장 어려운 문제다.”

“사람이 생각하면서 몇 마디 filler를 넣는 것은 정상이다. 문제는 filler가 필요할 때 얼마나 자연스러운가다.”

“전화가 10초 만에 끊길 수 있는데 거대한 prompt의 모든 token 비용을 지불할 필요는 없다.”

핵심 데이터 & 수치

• 영상 길이: 36분 31초다.
• 패널 규모: Basil Chatha가 Decagon·Daily·Vapi·Retell AI·Smallest AI의 다섯 현장 리더와 대화했다.
• Cascade의 기본 단계: STT→LLM→TTS의 3단계다.
• 최적화 기간: Decagon은 약 6개월 동안 pipeline 각 단계에서 10ms씩 줄이는 작업을 반복했다.
• Context 경고선: 1M-token context라도 약 25%부터 compaction을 고민해야 하며 70%까지 기다리면 늦을 수 있다.
• 초기 음성 AI context: 예전에는 50,000·250,000 token급 context에서 5~10턴 또는 10,000 token만 되어도 모델이 이탈했다.
• 사람의 autopilot: 반복 업무의 약 50%는 전문화한 모델이 autopilot처럼 처리할 수 있다는 비유가 나왔다.
• 반품 정책 적용 범위: 단순한 정책 답변이 약 70%의 관련 SKU에 적용되는 경우를 예로 들었다.
• Outbound 이탈: 많은 호출자가 bot임을 알아차리거나 통화 시작 후 약 10초 안에 전화를 끊는다.
• 전문화 workflow: collections의 신용카드 수집처럼 10~15단계 절차를 별도 specialized agent에 위임할 수 있다.
• 외부 API 병목: 고객 API tool call이 결과를 반환하는 데 5초가 걸릴 수 있어 filler가 필요해진다.
• 모델 운영: Small language model fine-tuning은 GPT-4o·GPT-4.1 같은 대형 realtime model보다 비용·지연시간을 낮추고 특정 knowledge base와 memory에 맞출 수 있다.

결론 및 시사점

1. 2026년의 정답은 단일 모델이 아니다: 기업용 Voice AI는 Cascade, Speech-to-Speech, 작은 분류 모델, specialized agent, 검색, 검증, fallback을 조합하는 시스템 설계 문제다.
2. 정확성이 자연스러움보다 우선이다: 음성 감정과 즉각성은 중요하지만 2026년을 2030년으로 잘못 확인하는 것 같은 사실 오류는 고객지원에서 허용할 수 없다.
3. Hybrid를 준비해야 한다: 자연스러운 active conversation은 Speech-to-Speech로 처리하고, 조회·결제·반품·정책처럼 복잡한 순간은 cascade와 tool call로 넘기는 구조가 중기 해법이다.
4. Context를 무작정 키우지 마라: 모든 정책을 거대한 system prompt에 넣는 방식은 중간 내용 망각·지연시간·token 비용을 키운다. 고객별로 필요한 context를 고르고, specialized agent와 compaction을 활용해야 한다.
5. Latency를 침묵의 문제가 아니라 대화 설계로 다뤄라: 병렬화·streaming·작은 classifier·자연스러운 contextual filler로 5초 API 지연을 관리할 수 있다.
6. 비용은 끊긴 통화까지 포함해 계산하라: 10초 만에 끊기는 outbound call에 긴 prompt 비용을 쓰지 않도록 prompt를 분리하고, 모델 규모와 호출 순서를 조정해야 한다.
7. 모델 공급자 장애를 정상 상태로 가정하라: Opus나 OpenAI API가 느려지거나 내려갈 수 있으므로 여러 모델의 waterfall과 self-hosted fallback을 준비해야 한다.
8. 다국어는 component 교체성으로 풀어라: 일본어·아랍어처럼 브랜드와 주소 발음이 중요한 시장은 한 플랫폼이 모든 언어를 직접 최적화하기보다 고객 custom TTS와 modular cascade를 허용하는 편이 현실적이다.
9. Eval은 고객 대화에서 시작하라: 아직 live가 아닌 고객의 예상 대화를 eval suite와 smoke test로 바꾸고, 공개 turn benchmark와 LLM-as-a-judge로 반복 검증해야 한다.
10. FDE가 경쟁력의 중심이다: 연구팀이 모델을 개선하는 동안 FDE는 고객의 실패 사례를 발견하고, 워크플로와 모델을 조정하고, 실제 SLA와 원가를 만족하는 제품으로 만든다. Voice AI의 승자는 가장 멋진 데모를 가진 팀이 아니라 현장에서 실패를 통제하는 팀이다.

핵심 요약 (20줄)

Voice AI의 기업 배포는 단일 모델 선택이 아니라 FDE가 통제하는 시스템 설계 문제다.

고객지원 시장은 거대하지만 기존 콜센터의 품질은 낮아 음성 에이전트의 실전 수요가 크다.

현재 가장 신뢰할 수 있는 기본 구조는 STT·LLM·TTS를 잇는 cascaded pipeline이다.

WebRTC·전화·WebSocket transport와 noise removal·voice isolation이 음성 입력을 전처리한다.

VAD와 smart-turn 모델은 문장 중간의 pause와 발화 종료를 구분해야 한다.

Inbound는 호출자의 목적과 상품 정책을 몰라 outbound보다 훨씬 복잡하다.

Amazon처럼 상품과 정책이 많은 서비스는 모든 규칙을 하나의 거대한 prompt에 넣을 수 없다.

LLM은 긴 context의 중간 내용을 잊을 수 있어 compaction과 대화 상태 추적이 필요하다.

Speech-to-Speech는 감정과 비동기성을 보존하지만 아직 기업용 정확성과 해석 가능성이 부족하다.

Cascade는 supervisor·intent·context·truth check를 배치해 prompt injection과 사실 오류를 통제한다.

실전의 중기 해법은 자연스러운 대화와 복잡한 조회를 Speech-to-Speech와 cascade로 나누는 hybrid다.

Gemini 2.5와 Haiku처럼 빠른 모델은 음성 응답의 intelligence·latency 균형을 위한 후보가 된다.

Pipeline은 STT·분류·여러 LLM을 fork하고 gate와 waterfall로 결과를 합쳐야 한다.

일본어와 아랍어의 브랜드·주소 발음은 고객 custom TTS와 component 교체성을 요구한다.

세밀한 workflow는 specialized agent로 분리하면 긴 prompt와 불필요한 추론을 줄일 수 있다.

Contextual filler는 5초 API 지연을 숨기지만 자연스러운 품질과 사용 시점이 중요하다.

거대한 prompt는 latency뿐 아니라 통화가 10초 만에 끊겨도 발생하는 token 비용을 키운다.

공개 turn-based STT·LLM·TTS benchmark는 새 모델과 자체 인프라를 공정하게 비교하게 한다.

고객의 예상 대화를 eval suite와 smoke test로 바꾸면 배포 전에 edge case를 발견할 수 있다.

작은 fine-tuned model과 self-hosting은 비용·지연시간·API 변동성·workflow 적합성을 개선한다.