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

ElevenAgents는 실시간 대화에 맞춰 설계된 저지연 오케스트레이션 엔진으로 구동되며, 추가 오버헤드는 100ms 미만입니다. 이 아키텍처는 ElevenLabs의 연구 성과와 OpenAI, Google, Anthropic 등 주요 제공업체의 최첨단 LLM, 그리고 ElevenLabs가 호스팅하는 엄선된 오픈 소스 모델을 결합합니다. 응답 파이프라인의 여러 단계에서 다수의 모델을 사용해, 에이전트는 매우 신속하면서도 맥락을 이해하는 대화를 보장합니다. 각 모델의 강점을 동적으로 함께 활용하여 지능, 속도, 비용 간 균형을 최적화하면서 다양한 엔터프라이즈 작업과 대화 시나리오에서 안정적이고 확장 가능한 성능을 제공합니다.

이 글에서는 복잡한 환경에서 에이전트가 작동하는 데 필요한 핵심 역량을 제공하기 위해 이러한 모델이 어떻게 함께 작동하는지, 더 구체적으로는 어떤 모델이 언제 어떤 토큰을 보는지 설명합니다. 그 중심에는 상호작용의 여러 시점에 걸친 대화 기록 관리가 있습니다. 독립 에이전트와 멀티 에이전트 워크플로 모두에서 오케스트레이션 내 대화 기록의 역할을 명확히 하기 위해, 대화 기록이 전반에 걸쳐 어떻게 어디에서 공유되는지 살펴보겠습니다.

독립 에이전트 

먼저 독립 에이전트와 핵심 구성 요소를 살펴보겠습니다. 최소한의 가치를 제공하는 에이전트는 시스템 프롬프트와 여러 도구에 대한 액세스, 그리고 지식 베이스를 갖춘다고 볼 수 있습니다. 사용 사례에서 엄격한 단계 순서를 검증할 필요가 적거나 에이전트 간 지식 사일로를 피하는 것이 중요하다면 워크플로보다 독립 에이전트를 선택하는 것이 좋습니다. 지식 사일로는 특정 도구, 문서 또는 과거 맥락을 일부 하위 에이전트만 이용할 수 있고 다른 에이전트는 이용할 수 없을 때 발생합니다. 이는 멀티 에이전트 워크플로에 내재하며 유연성과 결정성 간의 트레이드오프를 초래합니다. 

ElevenLabs의 독립 에이전트에서는 다음 방식을 이해하는 것이 중요합니다.

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

대화 맥락 구축 

고객과 ElevenLabs 에이전트의 대화는 양측이 메시지를 주고받아 구성된 여러 턴으로 이루어집니다. 에이전트와 사용자 메시지가 번갈아 나열된 이 목록은 대화 맥락을 구축하는 출발점입니다. 각 턴에서 기반 LLM은 이전 턴보다 메시지가 하나 더 많은, 에이전트와 사용자 메시지가 번갈아 포함된 생성 요청을 받습니다. 당연히 이 메시지 열의 앞에는 에이전트의 시스템 프롬프트를 나타내는 단일 시스템 메시지가 추가됩니다.

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

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

도구를 사용한 작업 수행 및 정보 검색

ElevenLabs 에이전트는 유연한 도구 시스템을 통해 대화 중 실제 작업을 수행하고 실시간 정보를 가져올 수 있습니다. 이러한 기능에는 중요한 설계 고려 사항이 따릅니다. 활성화된 모든 도구는 이름, 설명, 매개변수 스키마가 시스템 프롬프트 및 대화 기록과 함께 포함되므로 직렬화된 프롬프트의 크기를 늘립니다. 도구가 늘어날수록 올바른 도구 순서를 호출하기 위해 모델에 요구되는 추론 부담도 커집니다. Agent Builder에서 도구 설명은 도구의 기능과 반환하는 필드를 안내합니다. 언어 모델은 이 정보를 사용해 도구 사용의 맥락을 이해합니다. 도구가 정의되면, 해당 도구를 호출하는 구체적인 조건은 에이전트의 시스템 프롬프트에 지정합니다. 예를 들면 다음과 같습니다.

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

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

• 외부 API를 호출하는 웹훅 도구.
• 대화 websocket을 통해 이벤트로 도구 요청을 전송하는 클라이언트 도구.
• 통화 전환과 같은 기본 제공 작업을 위한 시스템 도구.
• 다음에 연결하는 MCP 도구: Model Context Protocol 서버.

에이전트가 도구를 사용하기로 결정하면 대화에서 필요한 세부 정보를 가져와 실행 요청을 보냅니다. 도구가 결과를 반환하면 해당 결과가 대화에 추가되어 모델이 다음 응답에서 자연스럽게 참조할 수 있습니다. 필요하다면 도구의 출력은 에이전트에 저장된 정보를 동적 변수로 업데이트할 수도 있습니다. 이 저장 정보는 미리 정의된 매핑을 사용해 도구 응답에서 추출된 단순한 키-값 쌍으로 유지됩니다. 설정된 변수는 시스템 프롬프트, 향후 도구 매개변수, 워크플로 조건을 통해 다시 에이전트에 반영될 수 있습니다. 이 피드백 루프는 상호작용에 따라 발전하는 일종의 작업 메모리를 에이전트에 제공합니다.

여기까지는 도구가 에이전트의 추론에 통합되는 방식을 설명했지만, 실행 시점도 구성할 수 있습니다. 도구는 각기 다른 대화 요구에 맞는 세 가지 실행 모드 중 하나로 실행할 수 있습니다. 즉시 모드에서는 LLM이 도구를 요청하는 즉시 실행됩니다. 주문 상태 확인처럼 사용자가 거의 즉각적인 응답을 기대하는 빠른 조회의 기본 모드입니다. 도구 실행 전 발화와 함께 사용하면 에이전트는 먼저 “확인해 보겠습니다”와 같은 짧은 응답을 생성해 사용자에게 전달하고, 동시에 도구를 병렬 실행하여 공백 시간을 최소화합니다. 더 느린 도구의 경우 플랫폼은 예상 대기 시간에 맞춰 이러한 안내 메시지를 자동으로 늘립니다. 반면 도구 실행 후 발화 모드는 에이전트가 말을 마칠 때까지 실행을 지연합니다. 통화 전환, 세션 종료, 결제 제출처럼 현실 세계에 영향을 미치는 작업에 필수적입니다. 사용자는 “지금 청구 부서로 연결해 드리겠습니다”와 같은 전체 맥락을 듣고, 작업이 수행되기 전에 중단할 기회를 가집니다. 비동기 모드는 대화를 멈추지 않고 도구를 전적으로 백그라운드에서 실행합니다. 이메일 전송, 외부 워크플로 트리거, 데이터 기록처럼 에이전트가 응답에서 결과를 참조할 필요가 없는 fire-and-forget 작업에 가장 적합합니다.

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

성능 측정

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

평가 기준

1. 기준당 하나의 명확한 목표: 한 기준에 여러 목표를 넣는 것보다 문장 하나 또는 짧은 글머리 기호 하나가 더 좋습니다. 
2. 관찰 가능하고 통화 기록에 기반해야 함: 통화 기록(말한 내용, 에이전트가 수행한 작업, 사용자가 요청한 사항)만으로 성공/실패를 판단할 수 있도록 목표를 작성하세요. LLM에 없는 외부 맥락이 필요한 목표는 피하세요.
3. 성공/실패/알 수 없음 결과를 명시: 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 모델이 포함됩니다. ZRM에서 다른 LLM을 사용하려는 고객은 해당 제공업체와 자체 계약을 체결하고, 그 계약이 적용되는 API 키를 사용하여 커스텀 LLM으로 구성할 수 있습니다. 이는 표준 신뢰 경계 밖으로 데이터 처리를 확장하므로, 활성화하기 전에 ElevenLabs Safety 팀이 사용 사례를 수동으로 검토하고 승인해야 합니다. ZRM은 ElevenLabs와 하위 처리자가 통화 데이터를 보관하지 않도록 보장하지만, 고객은 에이전트가 사용하는 외부 도구 또는 웹훅이 해당 보존 및 규제 요건을 준수하도록 할 책임이 있습니다.

앞으로의 전망

이 글에서는 ElevenLabs Agents가 신뢰할 수 있는 실시간 경험을 대규모로 제공하기 위해 대화 맥락, 도구, 평가, 구조화된 워크플로를 관리하는 방식을 살펴보았습니다. 고객이 더욱 복잡한 환경에 에이전트를 배포함에 따라, ElevenLabs는 구성 가능한 평가 모델과 더 풍부한 전환 제어부터 단계별 프롬프트 구성 및 토큰 사용량에 대한 심층 가시성까지 오케스트레이션 엔진의 유연성을 계속 확장하고 있습니다.

ElevenLabs의 Forward Deployed Engineering 팀은 이러한 기능이 실제 배포 환경과 발맞춰 발전하도록 고객과 긴밀히 협력하고 있습니다. 차세대 Agents는 실시간 대화를 가능하게 하는 저지연 성능을 저해하지 않으면서도 더욱 뛰어난 투명성, 결정성, 적응성을 제공할 것입니다.