ElevenAgent 오케스트레이션 엔진 완전 해부

ElevenAgents는 실시간 대화를 위해 설계된 저지연 오케스트레이션 엔진으로 구동되며, 오버헤드는 100ms 미만입니다. 이 아키텍처는 ElevenLabs의 연구와 OpenAI, Google, Anthropic 등 주요 제공업체의 최신 LLM, 그리고 ElevenLabs가 호스팅하는 일부 오픈소스 모델을 결합합니다. 답변 파이프라인의 다양한 단계에서 여러 모델을 활용해, 에이전트는 반응성과 컨텍스트 인식 모두를 보장합니다. 각 모델의 강점을 유연하게 조합해 활용함으로써, 다양한 엔터프라이즈 업무와 대화 시나리오에서 신뢰할 수 있고 확장 가능한 성능을 제공하며, 지능, 속도, 비용의 균형도 최적화합니다.

이번 글에서는 이러한 모델들이 어떻게 협력해 에이전트가 복잡한 환경에서 필요한 핵심 기능을 제공하는지, 그리고 각 모델이 언제 어떤 토큰을 보는지 설명합니다. 그 중심에는 상호작용의 여러 지점에서 대화 이력을 관리하는 방식이 있습니다. 독립 에이전트와 다중 에이전트 워크플로우 모두에서 오케스트레이션 과정에서 대화 이력이 어떻게, 어디서 공유되는지 다시 살펴보며 그 역할을 명확히 합니다.

독립 에이전트

먼저 독립 에이전트와 그 핵심 구성 요소를 살펴봅니다. 최소한의 가치가 있는 에이전트는 시스템 프롬프트, 여러 개의 도구 그리고 지식 베이스에 접근할 수 있다고 볼 수 있습니다. 엄격한 단계 순서 검증이 크게 필요하지 않거나, 에이전트 내 지식 사일로를 피하는 것이 중요한 경우에는 워크플로우보다 독립 에이전트를 사용하는 것이 좋습니다. 지식 사일로란 일부 도구, 문서, 과거 컨텍스트가 특정 하위 에이전트에게만 접근 가능한 상황을 말합니다. 이는 다중 에이전트 워크플로우의 본질적인 특성이며, 유연성과 결정론 사이의 트레이드오프를 만듭니다.

ElevenLabs의 독립 에이전트에서는 다음과 같은 점을 이해하는 것이 중요합니다:

• 효과적인 생성 요청 구성
• 관련 문서 검색 및 반영
• 에이전트 응답에 참고할 도구 호출 생성 및 실행
• 평가 및 데이터 수집을 위한 결과 출력

대화 컨텍스트 구축 

고객과 ElevenLabs 에이전트 간의 대화는 양측이 번갈아 메시지를 주고받는 일련의 턴으로 구성됩니다. 이 에이전트와 사용자 메시지의 교차 목록이 대화 컨텍스트를 구축하는 출발점이 됩니다. 각 턴마다, LLM은 이전 턴보다 한 개 더 많은 교차 메시지가 포함된 생성 요청을 받습니다. 이 메시지 목록은 에이전트의 시스템 프롬프트를 나타내는 단일 시스템 메시지로 시작합니다.

ElevenLabs 오케스트레이터는 사용자가 말을 마쳤는지 예측해 LLM 지연을 줄입니다. 경우에 따라 동일한 대화 컨텍스트로 여러 번 LLM 생성 요청이 발생할 수 있습니다. 오케스트레이션이 응답 속도를 최적화하지만, 응답 품질은 지식 접근 방식에도 크게 좌우됩니다. 고객이 에이전트를 더 발전시키면, 보통 독점 문서와 공개 콘텐츠를 결합해 에이전트의 답변을 근거 있게 만듭니다. 수년간 RAG(검색 기반 생성)가 이를 위한 표준 접근법이었습니다.ElevenAgents 지식 베이스는 RAG를 기반으로 최적화된 멀티모델 아키텍처를 적용하며, 자세한 내용은 이전 포스트에서 다뤘습니다. 이를 통해 최근 사용자 입력이 후속 질문이거나, 명확한 질문이 없는 경우에도 신뢰성 있게 문서를 검색할 수 있습니다.

하지만 검색은 에이전트가 외부 시스템과 상호작용하는 한 가지 방법일 뿐입니다.

도구를 활용한 정보 검색 및 액션 수행

ElevenLabs 에이전트는 유연한 도구 시스템을 통해 대화 중 실제 행동을 하거나 실시간 정보를 검색할 수 있습니다. 이 기능은 중요한 설계 요소를 동반합니다: 활성화된 도구가 많아질수록, 도구 이름, 설명, 파라미터 스키마가 시스템 프롬프트와 대화 이력과 함께 직렬화되어 프롬프트 크기가 커집니다. 도구가 많아질수록 올바른 도구 순서를 호출해야 하는 모델의 추론 부담도 커집니다. Agent Builder에서는 도구 설명이 도구의 기능과 반환 필드를 안내합니다. 이 정보로 언어 모델이 도구 사용 맥락을 이해합니다. 도구 호출 조건은 에이전트의 시스템 프롬프트에 정의합니다. 예시:

• lookup_order 도구 설명:lookup_order: “주문 ID로 고객의 주문 상세 정보를 조회합니다. 주문 상태, 구매 품목, 배송지, 운송장 번호를 반환합니다.”
• 시스템 프롬프트 예시:“고객 신원을 확인한 후 lookup_order 도구를 호출해 주문 상세 정보를 조회하세요.”

이렇게 역할을 분리하면 도구 정의를 여러 에이전트에서 재사용할 수 있고, 각 에이전트의 시스템 프롬프트로 도구 호출 시점을 세밀하게 제어할 수 있습니다. 고객이 효과적으로 시스템 프롬프트를 설계할 수 있도록 프롬프트 가이드에서 더 자세한 안내를 제공합니다. 이 프레임워크 내에서 정의할 수 있는 도구 유형은 주로 다음과 같습니다:

• 외부 API를 호출하는 웹훅 도구
• 대화 웹소켓을 통해 이벤트로 도구 요청을 전송하는 클라이언트 도구
• 콜 이관 등 내장 동작을 위한 시스템 도구
• Model Context Protocol 서버와 연결하는 MCP 도구

에이전트가 도구 사용을 결정하면, 대화에서 필요한 정보를 추출해 실행 요청을 보냅니다. 도구가 결과를 반환하면, 그 결과가 대화에 추가되어 모델이 다음 응답에서 자연스럽게 참고할 수 있습니다. 필요하다면 도구의 출력값을 동적 변수로 에이전트의 저장 정보에 업데이트할 수도 있습니다. 이 저장 정보는 도구 응답에서 미리 정의된 매핑을 통해 추출한 간단한 키-값 쌍으로 관리됩니다. 설정된 변수는 시스템 프롬프트, 이후 도구 파라미터, 워크플로우 조건 등에 다시 활용됩니다. 이런 피드백 루프를 통해 에이전트는 상호작용에 따라 진화하는 작업 메모리를 갖게 됩니다.

이처럼 도구가 에이전트 추론에 통합되는 방식 외에도, 실행 타이밍 역시 설정할 수 있습니다. 도구는 세 가지 실행 모드 중 하나로 동작하며, 각 모드는 대화 목적에 따라 적합합니다. 즉시 실행 모드(Immediate Mode)에서는 LLM이 요청하자마자 도구가 실행됩니다. 주문 상태 확인 등 빠른 응답이 필요한 경우 기본값입니다. 사전 안내 발화(pre-tool speech)와 결합하면, 에이전트가 “확인해드릴게요”와 같은 짧은 안내를 먼저 생성해 사용자에게 전달하고, 도구는 동시에 실행되어 대기 시간을 최소화합니다. 도구가 느릴 경우, 플랫폼이 자동으로 안내 메시지 길이를 늘려 예상 대기 시간에 맞춥니다. 반면, 사후 안내 발화(Post-Tool Speech Mode)는 에이전트가 말을 마친 뒤 도구를 실행합니다. 콜 이관, 세션 종료, 결제 등 실제 결과를 동반하는 행동에 필수적입니다. 사용자는 “이제 결제팀으로 연결해드릴게요”와 같은 안내를 듣고, 행동이 실행되기 전에 중단할 기회를 가집니다. 비동기 모드(Async Mode)는 대화를 멈추지 않고 도구를 백그라운드에서 실행합니다. 이메일 발송, 외부 워크플로우 트리거, 데이터 로깅 등 결과를 응답에 참고할 필요가 없는 작업에 적합합니다.

실행과 오케스트레이션이 준비되면, 다음 단계는 성능 측정 방법을 이해하는 것입니다.

성능 측정

에이전트와의 통화가 끝난 후, 고객은 통화의 일부 정보를 추출해 추가 분석이나 저장, 또는 통화 성공 여부 판단에 활용할 수 있습니다. 이때 필요한 것이 바로 데이터 수집과 평가 기준입니다. 데이터 수집을 통해 통화 기록에서 구조화된 정보를 추출해 후속 분석 및 집계에 활용할 수 있습니다. 고객은 이 결과를 엔터프라이즈 데이터 레이크하우스에 내보내 리포팅이나 워크플로우 고도화에 사용합니다. 예를 들어, 영업 개발 에이전트는 대화에서 잠재 고객 정보를 자동 추출해 CRM 시스템의 리드로 생성하거나 업데이트할 수 있습니다. 반면, 평가 기준은 통화가 성공적으로 완료됐는지 판단합니다. 모든 기준이 충족되면 통화는 성공으로, 그렇지 않으면 실패로 표시됩니다. 이를 통해 대화가 항상 정의된 품질 및 무결성 기준을 충족하도록 하며, 빠른 피드백도 제공합니다. 통화가 종료되고 사후 웹훅이 트리거되면, 에이전트는 최종 기록(도구 실행 및 메타데이터 포함)을 LLM에 전달해 모든 데이터 수집 항목과 평가 기준을 함께 처리합니다. 모델은 이 통합 프롬프트로 각 평가 기준 충족 여부를 판단하고, 지정된 데이터 포인트를 추출해 후속 분석에 제공합니다. LLM이 이러한 설정을 입력 프롬프트의 일부로 직접 해석하므로, 명확하고 일관되게 작성하는 것이 중요합니다. 평가 기준 및 데이터 수집 설명 작성 시 다음과 같은 모범 사례를 권장합니다.

평가 기준

1. 기준별로 명확한 목표 한 가지: 한 문장 또는 짧은 항목이 여러 목표를 한 기준에 담는 것보다 좋습니다.
2. 관찰 가능하고 기록 기반: 성공/실패 여부가 기록(무엇을 말했는지, 에이전트가 무엇을 했는지, 사용자가 무엇을 요청했는지)만으로 판단 가능하도록 목표를 작성하세요. LLM이 알 수 없는 외부 맥락이 필요한 목표는 피하세요.
3. 명확한 성공/실패/불명 outcomes: LLM은 이미 목표가 충족되면 성공, 충족되지 않으면 실패, 기록만으로 판단 불가하면 불명으로 표시해야 한다는 맥락을 갖고 있습니다. 따라서 “충족”과 “미충족”이 명확히 구분되도록 목표를 작성해야 하며, 모호하면 모델이 불명 또는 잘못 분류할 수 있습니다.
4. 간결하게 작성: 여러 평가 기준이 한 번에 전달될 수 있으므로, 기준이 길면 노이즈가 늘고 환각 현상도 유발할 수 있습니다.
5. 언어도 중요: LLM이 평가 기준 충족 여부에 대한 근거를 제시할 때, 기준 설명과 동일한 언어로 답변하므로 이 점을 고려해야 합니다.

데이터 수집

1. 추출 대상을 정확히 설명: 설명이 LLM에 가장 중요한 신호입니다. 필드의 의미, 언제 값을 설정해야 하는지, 불명확할 때는 어떻게 처리하는지(예: “고객이 원하는 날짜를 말하지 않으면 null로 남겨두세요”)를 명확히 작성하세요.
2. 예상 타입과 일치: LLM이 제공하는 값은 항상 데이터 수집 항목에 지정된 타입(예: boolean, string, integer 등)과 일치합니다. 설명도 이에 맞춰 작성하세요. 예를 들어, integer 타입에는 “요청한 품목 수 추출”, boolean에는 “고객이 제안에 동의했는지 예/아니오”와 같이 작성할 수 있습니다.
3. 가능하면 enum 사용: string 타입에서 값이 고정된 경우, 스키마에 enum을 사용하세요. 모델의 출력을 제한해 잘못된 값을 줄일 수 있습니다.
4. 항목별로 추출 목표 한 가지: 여러 가지 사실을 한 항목 설명에 담지 말고, 각각 별도 항목으로 분리해 각 통화마다 명확한 추출 목표가 있도록 하세요.
5. 설명은 짧게: 설명은 몇 문장으로 충분합니다. 긴 단락은 필요 없습니다. 기록은 이미 사용자 메시지에 있으므로, 스키마와 짧은 설명만으로 충분합니다.

현재 이 평가 및 추출 단계에 사용되는 LLM은 빠른 처리를 위해 저지연 모델로 고정되어 있습니다. 곧 더 유연한 옵션도 제공할 예정입니다.

다음으로, 구조화된 오케스트레이션, 결정론, 여러 대화 역할별 특화가 필요한 경우 사용할 수 있는 워크플로우에 대해 살펴봅니다.

워크플로우

워크플로우는 복잡한 대화 흐름을 시각적으로 설계할 수 있는 인터페이스를 제공합니다. 최종적으로 오케스트레이터가 여러 하위 에이전트, 도구, 이관을 독립 에이전트 식별자 아래에서 관리하는 논리 객체를 생성합니다. 워크플로우는 독립 에이전트에서 이미 설명한 요소 외에 추가로 다음과 같은 구성 요소를 고려해야 합니다:

• 시스템 프롬프트와 하위 에이전트 대화 목표의 상호작용
• 그래프 내 다양한 전환 지점 이동 방식

특화된 대화 목표

워크플로우는 독립 에이전트의 기능을 재사용해 상호작용 내내 일관된 행동을 보장합니다. 여기에는 기본 시스템 프롬프트, 핵심 도구, 항상 접근 가능한 글로벌 지식 베이스 등 공유 요소가 포함됩니다. 전체 시스템 프롬프트는 보통 글로벌 대화 컨텍스트, 기대 톤, 안전 기준, 브랜드 또는 제품별 지침을 정의합니다.

이런 공유 기반 위에, 워크플로우는 방향성 그래프 내에서 동작하는 특화 하위 에이전트를 도입합니다. 각 하위 에이전트는 좁은 범위의 목표를 부여받고, 역할에 맞는 추가 프롬프트, 도구, 지식 소스를 기본 설정에 더합니다. 전체 대화 구성을 새로 정의하는 대신, 하위 에이전트는 프롬프트 조합과 선택적 컨텍스트 확장으로 의도를 기본 에이전트에 덧붙입니다. 대화 이력은 하위 에이전트 전환 시에도 유지되어 연속성을 보장하지만, 각 하위 에이전트는 의도적으로 제한된 시스템 뷰로 동작합니다. 지식 베이스와 도구는 선택적으로 노출되어, 역할 간 정보 누수를 막는 명확한 사일로를 만듭니다. 이를 강화하기 위해, 오케스트레이터 객체는 전환마다 독립 에이전트처럼 새로 구축됩니다. 이로써 활성 하위 에이전트의 프롬프트 상태, 설정, 사용 가능한 기능이 완전히 결정적으로 유지됩니다. 이런 설계로 워크플로우는 글로벌 일관성을 유지하면서도, 각 단계별 특화와 명확한 역할 분리, 컨텍스트·지식·행동 적용의 정밀 제어가 가능합니다.

이런 제어를 가능하게 하는 핵심 메커니즘 중 하나가 하위 에이전트 간 전환 방식입니다.

LLM 조건으로 워크플로우 전환 제어

워크플로우는 하위 에이전트의 방향성 그래프를 따라 진행되며, 노드 간 전환은 명시적 조건으로 제어됩니다. 이 조건은 언제 제어권이 다른 하위 에이전트로 넘어갈지 결정하며, 사용자 입력, 도구 결과, 동적 변수에 따라 워크플로우가 반응할 수 있게 합니다. 그래프 조건은 결정론적이거나 LLM 평가 기반일 수 있습니다. 무조건 전환, 동적 변수 표현식, 도구 결과 조건 등 결정론적 조건은 제어 흐름에 강한 보장을 제공해 엄격한 워크플로우 진행에 적합합니다. 반면, LLM 기반 조건은 사용자 의도 감지, 특정 정보 제공 여부 등 자연어 기준의 의미적 평가를 가능하게 합니다.

중요하게도, LLM 조건은 활성 에이전트의 시스템 프롬프트 외부에서 평가되며, 에이전트의 생성 행동에는 영향을 주지 않습니다. 대신 오케스트레이터가 현재 대화 상태를 기준으로 병렬 평가합니다. 이 분리는 전환 로직이 에이전트 프롬프트를 오염시키거나 응답 생성에 영향을 주지 않으면서도, 워크플로우가 LLM 추론을 활용해 유연하게 그래프를 이동할 수 있게 합니다. 결정론적 조건과 LLM 평가 조건을 조합해, 워크플로우는 정확성이 중요한 부분에는 결정론적 전환을, 의미 해석이 필요한 부분에는 LLM 기반 전환을 적용해 예측성과 적응성을 모두 달성할 수 있습니다.

대화가 새로운 단계로 진행되면, 시스템은 해당 단계에 맞게 맞춤화된 에이전트 버전을 활성화합니다. 각 단계는 자신에게 필요한 지식과 도구만 접근하며, 집중된 지침으로 동작합니다. 예를 들어, 환불 처리 단계에서는 환불 정책만 참고하고, 온보딩이나 분류와 관련된 맥락은 상속받지 않습니다. 단계 이동은 명시적 전환 조건으로 제어되며, 책임 전환 시점과 라우팅 결정이 자연스럽게 대화 흐름에서 이뤄집니다. 연속성을 위해, 사용자 경험은 전환 과정에서도 매끄럽게 유지되며, 각 단계는 관련 대화 컨텍스트만 상속받고 전환 메커니즘은 노출되지 않습니다. 또한, 비생산적인 라우팅 순환을 방지하는 안전장치도 마련되어 워크플로우가 안정적이고 목표 지향적으로 유지됩니다.

안전 및 보안

더 높은 수준의 안전 및 보안 통제가 필요한 경우, 고객은 오케스트레이터의 추가 기능을 활용할 수 있습니다.

가드레일

ElevenLabs Agents는 실시간으로 사용자 및 에이전트 메시지를 평가하는 설정 가능한 중재 및 정렬 시스템을 통해 안전 가드레일을 구현합니다. 유입 콘텐츠는 성적 내용, 폭력, 괴롭힘, 증오, 자해 등 여러 위험 카테고리로 분류되며, 각 카테고리는 독립적으로 임계값을 설정할 수 있습니다. 가드레일이 작동하면 대화는 즉시 종료되고, 클라이언트에 명확한 실패 사유가 안내됩니다. 이를 통해 프롬프트 기반 완화에만 의존하지 않고, 위험한 상호작용을 조기에 일관되게 차단할 수 있습니다. 가드레일은 에이전트 프롬프트 로직 외부에서 동작해, 모델 행동이나 사용자 입력으로 우회할 수 없는 신뢰성 있는 집행 계층을 제공합니다. 이 방식으로 고객은 도메인에 맞게 안전 민감도를 조정하면서도, 런타임에서 결정론적 집행을 유지할 수 있습니다.

규정 준수 데이터 관리

화자가 에이전트와 민감한 정보를 공유하는 경우, 예를 들어 HIPAA 준수가 필요한 의료 데이터 등, 엄격한 저장 및 처리 요건이 적용될 수 있습니다. 이런 사용 사례를 지원하기 위해, 에이전트 또는 워크스페이스 단위로 Zero Retention Mode(ZRM)를 제공합니다. 활성화 시 모든 통화 데이터는 메모리에서만 처리되고, 영구 저장소에는 기록되지 않습니다. 통화 및 처리가 끝나면 ElevenLabs는 어떤 정보도 보관하지 않습니다. 따라서 기록, 오디오, 분석 결과는 Agents 대시보드에서 확인할 수 없으며, 이 정책은 고객 시스템과 내부 로그 모두에 적용됩니다. 데이터는 저장되지 않지만, 통화 중에는 처리되며, 설정된 사후 웹훅으로 결과가 전달되어 고객이 필요시 자체 시스템에 기록이나 분석 결과를 저장할 수 있습니다.

ZRM이 활성화되면, 서브프로세서 역시 데이터를 보관하지 않도록, 고객 데이터 학습 또는 보관을 금지하는 계약을 맺은 LLM 제공업체(현재 Google Gemini, Anthropic Claude)로 사용 가능한 LLM이 제한됩니다. ZRM 하에서 다른 LLM을 사용하려면, 고객이 해당 제공업체와 별도 계약을 체결하고, 그 계약에 포함된 API 키로 커스텀 LLM을 설정해야 합니다. 이 경우 데이터 처리가 ElevenLabs의 표준 신뢰 경계를 넘어가므로, Safety팀의 사전 검토 및 승인이 필요합니다. ZRM은 ElevenLabs와 서브프로세서가 통화 데이터를 보관하지 않도록 보장하지만, 고객은 에이전트가 사용하는 외부 도구나 웹훅이 관련 보관 및 규제 요건을 준수하는지 직접 책임져야 합니다.

앞으로의 방향

이번 글에서는 ElevenLabs Agents가 대화 컨텍스트, 도구, 평가, 구조화된 워크플로우를 어떻게 관리해 신뢰할 수 있는 실시간 경험을 대규모로 제공하는지 살펴봤습니다. 고객이 점점 더 복잡한 환경에 에이전트를 배포함에 따라, ElevenLabs는 오케스트레이션 엔진의 유연성을 지속적으로 확장하고 있습니다. 평가 모델 설정, 전환 제어 강화, 프롬프트 구성 및 토큰 사용에 대한 심층 관찰 등 다양한 기능이 추가되고 있습니다.

저희 Forward Deployed Engineering 팀은 실제 환경에서의 배포와 함께 이러한 기능이 발전할 수 있도록 고객과 긴밀히 협력하고 있습니다. 차세대 Agents는 실시간 대화의 저지연 성능을 유지하면서도, 더욱 투명하고 결정적이며 유연한 경험을 제공할 예정입니다.