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

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

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

핵심 구성 요소

ElevenLabs Agents

가장 단순한 형태에서 ElevenLabs Agent는 Websocket 클라이언트를 통해 액세스할 수 있습니다. 대화의 서버 및 클라이언트 이벤트를 나타내는 정보는 JSON 객체 형태로 에이전트와 주고받습니다. 에이전트가 사용자 음성을 전사하면 즉시 생성 요청을 트리거합니다. 주요 모델 제공업체를 대부분 지원하며, 고객이 자체 Custom LLM을 사용할 수도 있습니다. Custom LLM 뒤에서 생성 요청에 응답할 더 복잡한 오케스트레이터(에이전트)를 도입할 때는 OpenAI의 Chat Completions 또는 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만 나타내는 대신, 프록시는 하나의 식별자를 여러 관련 상호작용과 연결할 수 있습니다. 이를 통해 시스템은 채널을 넘나드는 고객 여정을 추적하고, 과거 컨텍스트를 재사용하며, 여러 상호작용을 한 번에 조율할 수 있습니다. 예를 들어 하나의 매핑은 여러 웹 채팅 세션, 후속 음성 통화, 내부 지원 워크플로를 동일한 논리적 고객 식별자 아래 그룹화할 수 있습니다. 그러면 프록시는 Custom LLM 뒤에서 통합 상태를 보존하면서 간단한 규칙에 따라 요청을 올바른 식별자로 라우팅할 수 있습니다. 이를 통해 외부 에이전트가 관리하는 더욱 유연하고 지속적인 다단계 상호작용을 구현할 수 있습니다.

메시지 전달

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

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

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

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

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

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

상태와 연결하기

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

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

향후 전망

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

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