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

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

이 글에서는 ElevenLabs Agents가 외부 에이전트를 어떻게 지원하는지, 그리고 세밀한 통합 제어를 가능하게 하는 패턴에 대해 설명합니다. 이러한 메커니즘을 통해 고객은 ElevenLabs의 최고 수준 음성 오케스트레이션을 활용하면서도 전체 오케스트레이션에 대한 완전한 소유권을 유지할 수 있습니다.

핵심 구성요소

ElevenLabs Agents

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

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

상태 관리

정의상, 에이전트가 환경을 효율적으로 탐색하기 위해 추적해야 하는 데이터는 매우 작업별로 다릅니다. 외부 에이전트가 적용된 ElevenLabs Agents의 경우, 몇 가지 잘 정의된 범주에 따라 상태를 유지하는 것이 유용합니다.

내부 상태는 대화의 흐름을 관리합니다. 내부 상태로 추적되는 요소의 예시는 다음과 같습니다:

• 음성 활동, 끼어들기, 활성 화자 식별 등 현재 대화 흐름
• 실시간 전사 분석을 통해 파악된 애플리케이션별 인사이트(의도, 엔터티, 감정 등)
• 중간 사고, 가설, 이전 시도 등 추론 과정
• 활성 목표, 동작 모드, 상호작용 중 행동을 안내하는 임시 제약 등 구성 및 운영 파라미터

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

• 상호작용하는 다른 사용자 또는 시스템의 현재 목표, 사용 가능 여부, 권한 등 상태
• API, 데이터베이스, 통합 등 에이전트의 행동에 영향을 줄 수 있는 도구 및 지식 베이스
• 외부 주체 또는 시스템과 관련된 진행 중인 작업 및 의존성(에이전트의 다음 단계에 영향)

이 정보를 에이전트와 사용자의 관계 전반에 걸쳐 안정적으로 유지하는 일반적인 패턴을 소개합니다.

솔루션 구성요소

개요

이 섹션에서는 복잡한 외부 에이전트를 성공적으로 통합하는 데 필요한 아키텍처 구성요소와 구현 세부사항을 다룹니다. 이 접근법의 핵심은 모든 서비스에서 세션을 대표하는 임의의 고유 식별자를 프록시할 수 있다는 점입니다. 커스텀 LLM을 사용하는 ElevenLabs Agents의 경우, 필요한 식별자를 extra body 객체 내 LLM 파라미터로 전달하면 됩니다. 이 값은 대화 설정 우선 적용의 일부로 통화 시작 시 전달됩니다. 이렇게 하면 식별자가 사용자에서 ElevenLabs Agent를 거쳐 외부 에이전트까지 전달됩니다.

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

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

메시지 전달

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

예를 들어, 외부 에이전트가 진행 중인 음성 활동을 파악할 수 있으면 사용자가 말하고 있는지, 얼마나 말하는지, 사전에 어떤 조치를 취해야 할지 결정하는 데 도움이 됩니다. 이러한 인사이트는 ElevenLabs Agents가 제공하는 음성 활동 감지(VAD) 점수를 클라이언트 이벤트로 대화 웹소켓을 통해 받아 처리함으로써 바로 얻을 수 있습니다. ElevenLabs로부터 점수를 받으면, 클라이언트 애플리케이션은 애플리케이션 요구에 따라 VAD 클라이언트 이벤트를 상태 기반 프록시에 전달하고, 메시지에 임의의 세션 식별자를 포함해야 합니다. 상태 기반 프록시는 세션에 대한 기존 연결을 최적으로 식별하는 요청 매핑 로직을 구현해야 합니다.

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

외부 에이전트를 커스텀 LLM을 통해 통합할 때, ElevenLabs의 툴 호출 및 RAG(검색 기반 생성) 기능은 외부 에이전트의 자체 구현을 우선시하여 종종 우회됩니다. 따라서 이 구성요소의 소유권은 전적으로 외부 에이전트 제공자에게 있습니다. 애플리케이션은 여전히 툴 활동을 파악할 수 있어야 하며, 이를 통해 에이전트의 진행 상황을 보여주고 최종 사용자 경험을 적절히 업데이트할 수 있습니다.

이 가시성을 제공하기 위해, 외부 에이전트는 툴이 호출될 때마다 요청과 응답 모두에 대해 메시지를 발행합니다. 이 메시지는 상태 기반 프록시가 클라이언트 애플리케이션으로 전달하며, 전용 메시지 큐를 통해 처리됩니다. 이는 ElevenLabs Agents의 클라이언트 이벤트 메커니즘과 동일하며, 애플리케이션이 에이전트가 외부 시스템을 읽거나 수정할 때를 추적할 수 있게 해줍니다.

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

상태와의 연계

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

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

앞으로의 전망

조직이 음성 및 비음성 에이전트 도입을 고도화함에 따라, 이러한 에이전트에 필요한 정보 패턴이 점차 명확해질 것으로 기대합니다. 이를 통해 본문에서 설명한 서비스의 개발과 소유가 더 쉬워질 것입니다. 그동안 ElevenLabs는 이미 등장한 요구사항을 충족하기 위해 계속해서 기능을 개발하고 있습니다. ElevenLabs의 Forward Deployed Engineering 팀은 고객과 긴밀히 협력하여 새롭게 등장하는 요구를 구체적인 제품 기능으로 전환하고, 실제 현장 배포와 함께 솔루션이 발전하도록 하고 있습니다.

이미 기존 에이전트를 사용 중이고 ElevenLabs Agents로 음성 기능을 추가하면서 LLM 오케스트레이션의 소유권을 유지하고 싶다면, 이 방식을 직접 시도해보고 의견을 들려주세요!