AI 에이전트에 음성 추가: 프레임워크에 구애받지 않는 통합 패턴

Source: Dev.to

소개

최근에 AI 에이전트를 구축해 왔다면 흥미로운 점을 눈치채셨을 겁니다: 모두가 PydanticAI, LangChain, LlamaIndex에 대해 이야기하고 있지만, 전체 아키텍처를 단일 음성 제공자에 묶지 않고 음성 기능을 추가하는 방법에 대해서는 거의 언급되지 않습니다. 잠시 생각해 보면 이것은 큰 문제입니다.

저희 Sayna는 바로 이 문제와 마주하고 있었으며, 어떤 프레임워크나 제공자를 선택하느냐보다 추상화 패턴이 왜 더 중요한지에 대한 생각을 공유하고 싶었습니다.

음성 통합의 실제 문제

예시 상황 설명:

텍스트 입력과 출력을 갖는 AI 에이전트가 있습니다—전혀 문제 없습니다. 타입 안전성을 좋아해서 PydanticAI를 사용하거나, 팀이 이미 익숙해서 LangChain을 쓰거나, 기존 프레임워크가 사용 사례에 맞지 않아 직접 커스텀으로 만든 경우일 수도 있습니다. 모두 잘 동작합니다.

BUT 누군가가 “여기에 음성을 추가할 수 있을까?”라고 묻기 시작하면, 완전히 다른 문제 세계에 직면하게 됩니다.

음성 통합을 시작하는 순간, 단순히 TTS와 STT만 추가하는 것이 아니라

• 지연 시간 요구사항,
• 스트리밍 복잡성,
• 공급자‑별 API,
• 그리고 인프라스트럭처에 관한 새로운 계층

을 동시에 도입하게 되는 것입니다.

제가 대화하는 대부분의 개발자는 같은 실수를 합니다: TTS 공급자를 하나 골라요 (예: ElevenLabs는 음질이 좋으니), STT 공급자를 하나 골라요 (예: Whisper는 OpenAI에서 제공하니), 이를 에이전트에 바로 연결하고 끝났다고 생각합니다. 6개월 뒤에야 ElevenLabs의 가격 정책이 규모에 맞지 않거나 Whisper의 지연 시간이 실시간 대화에 너무 높다는 것을 깨닫고, 코드베이스의 상당 부분을 다시 작성해야 하는 상황에 처합니다.

이는 과거 클라우드 공급자와 겪었던 벤더‑락‑인 문제와 정확히 동일한데, 이번에는 AI 서비스 분야에서 더 빠르게 나타나고 있습니다.

프레임워크 비종속성이 중요한 이유

놀라실 수도 있는 사실이 하나 있습니다: PydanticAI, LangChain, 그리고 LlamaIndex는 모두 음성을 처리하는 방식이 서로 다르지만, 음성 계층에서의 추상화 문제를 실제로 해결하지는 못합니다.

• 이들은 LLM 호출을 아름답게 추상화하지만, 음성 처리에 관해서는 대부분 스스로 해결해야 합니다.
• LangChain은 구성 요소들을 체인으로 연결할 수 있게 해 줍니다: 직접 STT 함수와 TTS 함수를 제공하고 이를 순차적인 체인으로 결합합니다. 이는 유연하지만, 추상화 부담을 사용자에게 떠맡깁니다—프로바이더를 바꿀 때마다 체인 로직을 수정해야 합니다.
• PydanticAI는 아직 네이티브 음성 지원이 없습니다(관련 오픈 이슈가 존재). 따라서 개발자들이 직접 커스텀 솔루션을 구축하고 있으며, 마찬가지로 추상화 책임이 사용자에게 있습니다.

핵심은 이 프레임워크들이 나쁘다는 것이 아니라, 그들이 하는 일에 있어서는 훌륭하다는 점입니다. 핵심은 음성이 별개의 계층이며, 이를 에이전트 툴킷의 또 다른 도구로만 취급하면 더 큰 그림을 놓치게 된다는 것입니다.

실제로 필요한 추상화 패턴

AI 에이전트의 음성 통합을 생각할 때, 저는 세 가지 뚜렷한 계층을 봅니다:

1. 에이전트 로직

   • 여기에는 PydanticAI, LangChain, 혹은 여러분이 만든 커스텀 솔루션이 위치합니다.
   • 사고, 툴 호출, 메모리, 그리고 모든 지능적인 부분을 담당합니다.
   • 오디오 포맷, 음성 합성, 혹은 전사 모델에 대해 알 필요가 없습니다.

2. 음성 추상화 레이어

   • 에이전트와 실제 음성 제공자 사이에 위치합니다.
   • 스트리밍 오디오, WebSocket 연결 관리, 음성 활동 감지 등을 처리하며, 가장 중요한 것은 제공자별 API를 통합 인터페이스 뒤에 추상화하는 것입니다.

3. 음성 제공자

   • 실제 TTS 및 STT 서비스: OpenAI, ElevenLabs, Deepgram, Cartesia, AssemblyAI, Google, Amazon Polly… 등등.
   • 각각은 강점, 가격 모델, 지연 특성, API 특이점이 다릅니다.

핵심 인사이트: 에이전트 로직은 오직 음성 추상화 레이어와만 통신해야 하며, 제공자와 직접 통신해서는 안 됩니다. 이렇게 하면 ElevenLabs에서 Cartesia로 전환하는 것이 코드 재작성 대신 설정 변경만으로 가능해집니다.

실제 고려 사항

• 지연 누적은 실제 문제입니다.
  STT → LLM → TTS 체인을 연결하면, 밀리초마다 누적됩니다. 응답 시간이 약 500 ms를 초과하면 사용자가 눈치챕니다. 이는 LLM이 끝난 뒤만이 아니라 각 단계마다 TTS 합성이 필요함을 의미합니다. 음성 레이어는 에이전트가 전체 응답을 생성하기 전에 TTS 합성을 시작해야 합니다—제공자를 직접 통합할 경우 이는 간단하지 않은 구현입니다.

• 제공자 특성이 크게 다릅니다.

  • 일부 TTS 제공자는 더 자연스럽게 들리지만 지연 시간이 더 깁니다.
  • 일부 STT 제공자는 억양을 더 잘 처리하지만 기술 용어에는 어려움을 겪습니다.
  • 일부는 고품질 오디오에서는 훌륭하지만 전화 회선(8 kHz PSTN 오디오는 웹 오디오와 매우 다름)에서는 성능이 떨어집니다.
    코드를 변경하지 않고 제공자를 교체할 수 있는 것은 단순히 편리한 것이 아니라, 프로덕션 시스템에 필수적입니다.

• 음성 활동 감지는 겉보기보다 어렵습니다.
  사용자가 언제 말을 시작하고 끝냈는지 파악하고, 중단을 부드럽게 처리하며, 배경 소음을 필터링하는 것은 해결된 문제이지만 올바른 도구를 사용할 때만 가능합니다. 이를 에이전트 로직과 동시에 처음부터 구축하는 것은 번아웃을 초래하는 레시피입니다.

멀티‑프로바이더 장점

처음부터 음성 통합을 멀티‑프로바이더 지원으로 설계하면 처음에는 명확하지 않을 수 있는 여러 이점을 얻을 수 있습니다:

• 비용 최적화가 가능해집니다.
  각 프로바이더마다 가격 모델이 다릅니다: 문자당 요금, 분당 요금, 대량 할인 등. 프로바이더를 쉽게 전환할 수 있으면, 대화 유형에 따라 가장 비용 효율적인 서비스로 라우팅할 수 있습니다.

• 신뢰성이 향상됩니다.
  프로바이더는 장애가 발생할 수 있습니다. 음성 레이어가 여러 프로바이더를 지원한다면 폴백 로직을 구현할 수 있습니다. 예를 들어 ElevenLabs가 다운될 경우, 사용자 경험을 깨뜨리지 않고 자동으로 Cartesia 또는 다른 TTS 서비스로 폴백할 수 있습니다.

• 미래 기능에 대한 유연성.
  새로운 기능(예: 감정 인식 TTS, 저지연 스트리밍 STT)은 기존 스택의 큰 부분을 다시 작성하지 않고 새로운 프로바이더를 연결함으로써 도입할 수 있습니다.

• 규제 및 지역 컴플라이언스.
  일부 관할 구역은 데이터가 특정 지리적 경계 내에 머물러야 한다고 요구합니다. 멀티‑프로바이더 추상화를 사용하면 해당 지역에 대해 컴플라이언스가 가능한 프로바이더로 오디오를 라우팅할 수 있어 핵심 에이전트 코드를 수정할 필요가 없습니다.

요점

음성을 AI 아키텍처에서 별도의 1급 레이어로 취급하십시오. 에이전트 로직을 보호하는 음성 추상화 레이어를 구축하십시오.