외부 에이전트를 ElevenLabs Agents의 음성 오케스트레이션과 통합하기

최첨단 에이전트 오케스트레이터는 점점 더 복잡한 작업을 처리하고 다양한 엔터프라이즈 도구 전반에서 작동할 수 있게 되고 있습니다. 이를 위해서는 애플리케이션, 대화 및 시스템 상태를 세심하게 관리해야 합니다. 음성 이외의 모달리티에서는 컨텍스트 엔지니어링,이라는 포괄적인 개념 아래 공통 패턴이 등장했습니다. 이는 상호작용이 진행됨에 따라 에이전트의 시스템 프롬프트를 중심으로 일관된 방식을 구축하는 것을 목표로 합니다. 음성을 도입하면 음성 상호작용의 구성 요소를 관리하기 위한 추가 상태 계층이 생길 뿐 아니라, 이상적으로는 다른 모달리티에서 수행한 기존 작업의 결과물을 재사용할 수도 있습니다. 

이 글에서는 ElevenLabs Agents가 외부 에이전트를 지원하는 방식과 통합을 세밀하게 제어할 수 있는 패턴을 소개합니다. 이러한 메커니즘을 통해 고객은 더 넓은 범위의 오케스트레이션에 대한 완전한 소유권을 유지하면서 ElevenLabs의 최고 수준 음성 오케스트레이션을 활용할 수 있습니다.

핵심 구성 요소

ElevenLabs Agents

가장 단순한 형태의 ElevenLabs Agent는 WebSocket 클라이언트를 통해 접근할 수 있습니다. 대화 내 서버 및 클라이언트 이벤트를 나타내는 정보는 JSON 객체로 에이전트와 주고받습니다. 에이전트는 사용자 음성을 전사하면 즉시 생성 요청을 트리거합니다. 주요 모델 제공업체 대부분을 지원하며, 고객이 자체 Custom LLM을 사용할 수도 있습니다. Custom LLM 뒤에서 생성 요청에 응답할 더 복잡한 오케스트레이터(에이전트)를 도입할 경우, OpenAI의 Chat Completions API 또는 Responses API를 지원해야 합니다. 다행히 이 API 형식 사양은 대부분의 주요 에이전트 구축 프레임워크(CrewAI, LangChain, LangGraph, HayStack, LlamaIndex, ...)에서 쉽게 지원합니다. 

통합이 완료되면 이러한 에이전트는 자신이 연결된 음성 오케스트레이터와 관계없이 언제든 내부 및 외부 상태를 읽고 업데이트할 수 있어야 하는 경우가 많습니다. 이를 효과적으로 관리하면 기존 텍스트 전용 에이전트와의 일관성을 보장할 수 있습니다. 

상태 관리

에이전트가 환경을 효율적으로 탐색하기 위해 추적해야 하는 데이터는 본질적으로 작업별 특성이 매우 강합니다. 외부 에이전트로 구동되는 ElevenLabs Agents의 경우, 몇 가지 명확히 정의된 범주에 걸쳐 상태를 유지하는 것이 유용합니다.

내부 상태는 대화의 동작을 관리합니다. 에이전트 내부 상태의 일부로 추적되는 요소의 예는 다음과 같습니다.

• 음성 활동, 끼어들기, 현재 발화자 식별을 포함한 현재 대화 흐름.
• 감지된 의도, 엔터티 또는 감정과 같이 실시간 전사 분석에서 도출된 애플리케이션별 인사이트.
• 중간 생각, 가설, 이전의 해결책 생성 시도를 포함한 추론 과정.
• 활성 목표, 운영 모드, 상호작용 중 동작을 안내하는 일시적 제약 조건 등의 구성 및 운영 파라미터.

반면 외부 상태는 주로 에이전트가 상호작용하거나 영향을 미치는 관련 시스템과 사람에 초점을 둡니다. 에이전트 외부 상태의 일부로 추적되는 요소의 예는 다음과 같습니다.

• 현재 목표, 가용성 또는 권한 등 에이전트가 상호작용하는 다른 사용자나 시스템의 상태.
• 에이전트의 행동 능력에 영향을 줄 수 있는 API, 데이터베이스 또는 통합과 같은 도구 및 지식 베이스.
• 에이전트의 다음 단계를 좌우하는 외부 행위자 또는 시스템과 관련된 진행 중인 작업과 종속성.

에이전트와 사용자 간 관계의 전체 수명 주기에서 이 정보를 안정적으로 유지하는 일반적인 패턴을 살펴보겠습니다.

솔루션 구성 요소

개요 

이 섹션에서는 복잡한 외부 에이전트를 성공적으로 통합하는 데 필요한 아키텍처 구성 요소와 구현 세부 사항을 다룹니다. 이 접근 방식의 핵심은 세션을 나타내는 임의이지만 고유한 식별자를 모든 서비스에서 프록시할 수 있는 기능입니다. Custom LLM을 사용하는 ElevenLabs Agents에서는 호출 시작 시 extra body 객체 내 LLM 파라미터로 필요한 식별자를 대화 오버라이드의 일부로 전달하기만 하면 됩니다. 이렇게 하면 식별자가 사용자로부터 ElevenLabs Agent를 거쳐 외부 에이전트까지 전달됩니다. 

Custom LLM 뒤에 있는 상태 유지 프록시에 주목하세요. 일반적으로 존재하지 않는 이 서비스는 개별 생성 요청을 외부 에이전트와의 연결을 나타내는 임의의 식별자에 매핑할 수 있게 합니다. 이 서비스의 구현 소유권은 외부 에이전트 개발자에게 있습니다. 가장 단순한 형태에서 프록시는 ElevenLabs 대화 또는 통화 SID(전화 통신용)에 매핑되는 고유 식별자로 표현된 연결을 관리합니다. 더 고급 버전에서는 여러 상호작용에 걸친 복잡한 고객 관계에 대화를 매핑하는 과정에 계층 구조를 도입할 수 있습니다.

이러한 고급 구성에서 프록시는 단일 다운스트림 세션에 연결된 단일 요청을 넘어서는 추가 식별자를 유지합니다. 각 식별자가 하나의 대화나 통화 SID만 나타내는 대신, 프록시는 하나의 식별자를 여러 관련 상호작용에 연결할 수 있습니다. 이를 통해 시스템은 채널을 넘나드는 고객 여정을 추적하고, 과거 컨텍스트를 재사용하며, 여러 상호작용을 동시에 조정할 수 있습니다. 예를 들어 하나의 매핑은 여러 웹 채팅 세션, 후속 음성 통화, 내부 지원 workflow를 동일한 논리적 고객 식별자 아래로 묶을 수 있습니다. 그러면 프록시는 Custom LLM 뒤에서 통합된 상태를 유지하면서 간단한 규칙을 기반으로 요청을 올바른 식별자로 라우팅할 수 있습니다. 이를 통해 외부 에이전트가 관리하는 더욱 유연하고 지속적인 다단계 상호작용이 가능해집니다.

메시지 전달

생성 요청을 상위 수준 엔터티에 성공적으로 매핑하는 것 외에도, 상태 유지 프록시는 API 요청을 통해 애플리케이션 프런트엔드나 별도의 라우터 서비스 같은 외부 소스와 양방향 메시지를 주고받을 수 있습니다. 이것이 필요한 애플리케이션에서 ElevenLabs Agents는 메시지가 다른 서비스로 전달되고 있다는 사실을 알 필요가 없습니다.  

예를 들어 외부 에이전트가 진행 중인 음성 활동을 파악하면 사용자가 말하고 있는지, 얼마나 오래 말했는지, 사전에 조치를 취해야 하는지를 판단하는 데 유용한 경우가 많습니다. 이러한 인사이트는 ElevenLabs Agents가 제공하는 처리된 음성 활동 감지(VAD) 점수를 클라이언트 이벤트로 전달하면 대화 WebSocket을 통해 직접 도출하고 활용할 수 있습니다. ElevenLabs에서 점수를 수신하면 클라이언트 애플리케이션은 애플리케이션 요구사항에 따라 VAD 클라이언트 이벤트를 상태 유지 프록시로 전달할 수 있으며, 이때 메시지에 임의의 세션 식별자를 포함해야 합니다. 상태 유지 프록시는 세션의 기존 연결을 최적으로 식별하는 요청 매핑 로직을 구현해야 합니다. 

이 패턴은 JSON 블록으로 표현할 수 있는 모든 클라이언트 이벤트를 수용하도록 확장할 수 있습니다. 하지만 에이전트 자체에서 발생하는 이벤트를 노출하는 것도 유용합니다. 대표적인 예로 외부 시스템에서의 작업을 나타내는 도구 호출 또는 지식 베이스 쿼리의 수명 주기가 있습니다. 이러한 메커니즘은 오늘날 엔터프라이즈가 구축하는 에이전트의 근간입니다.

Custom LLM을 통해 외부 에이전트를 통합할 때 ElevenLabs의 도구 호출 및 검색 증강 생성(RAG) 기능은 외부 에이전트 자체 구현을 위해 우회되는 경우가 많습니다. 따라서 이러한 구성 요소의 소유권은 전적으로 외부 에이전트 제공업체에 있습니다. 애플리케이션은 도구 활동을 파악할 수 있어 에이전트의 진행 상황을 표시하고 그에 맞춰 최종 사용자 경험을 업데이트할 수 있으므로 여전히 이점을 얻습니다.

이러한 가시성을 제공하기 위해 외부 에이전트는 도구가 호출될 때마다 요청과 응답 모두에 대해 메시지를 보냅니다. 이 메시지는 상태 유지 프록시를 통해 클라이언트 애플리케이션으로 전달되고, 클라이언트 애플리케이션은 전용 메시지 큐로 이를 처리합니다. 이는 ElevenLabs Agents의 클라이언트 이벤트에서 사용하는 메커니즘을 그대로 따르며, 애플리케이션이 에이전트가 외부 시스템에서 읽거나 수정하는 시점을 추적할 수 있도록 합니다.

따라서 이러한 핵심 구성 요소를 사용하고 프록시와 클라이언트 애플리케이션 간 양방향 메시지 전달을 활성화하면, 고객은 LLM 오케스트레이션의 모든 부분에 대한 소유권을 유지하면서 ElevenLabs Agents에 외부 에이전트를 통합해 제공되는 음성 오케스트레이션만 엄격히 사용할 수 있습니다. 

상태와의 연결

복잡한 외부 에이전트를 효과적으로 지원하려면, 특히 상태 관리 측면에서 프록시와 에이전트 간 책임을 명확히 분리해야 합니다. 이 모델에서 프록시는 애플리케이션의 필요에 따라 그룹화된 관련 상호작용 테이블을 유지하고, 상태를 유지하지 않는 로직으로 자신과 에이전트 간 메시지를 라우팅합니다. 반대로 외부 에이전트는 전체 상태에 기여하는 모든 실질적인 내부 및 외부 정보를 처리하고 저장해야 합니다.

이러한 분리를 완화하면 기존 솔루션의 재작업을 더 줄일 수 있지만, 일반적으로 엄격한 경계를 유지하는 편이 에이전트의 작업 범위가 커질수록 더욱 견고하고 확장 가능한 결과로 이어집니다.

향후 전망

조직이 음성 및 비음성 지원 에이전트 도입에 더욱 성숙해짐에 따라, 이러한 에이전트에 필요한 정보의 패턴도 구체화되어 이 글에서 설명한 서비스의 개발과 소유권을 단순화할 수 있을 것으로 기대합니다. 그동안 이미 나타난 요구사항을 충족하는 제품을 계속 구축하고 있습니다. ElevenLabs의 Forward Deployed Engineering 팀은 이러한 새로운 요구를 구체적인 제품 역량으로 전환하고, 실제 배포 환경과 보조를 맞춰 솔루션이 발전하도록 고객과 긴밀히 협력하고 있습니다.

이미 기존 에이전트와 작업하고 있으며 LLM 오케스트레이션의 소유권을 유지한 채 ElevenLabs Agents로 음성을 활성화하려 한다면, 이 접근 방식을 사용해 보고 의견을 들려주세요!