LLM 기반 다중 에이전트 시스템(MAS)은 다양한 작업을 처리할 수 있으며, 이로 인해 시스템 부하와 실행 동작에 대한 불확실성이 증가한다. 전통적인 결정적 워크플로와 달리 LLM 기반 MAS는 실시간으로 결정을 내리는 동적 실행 모델을 사용하며, 이는 정적으로 정의된 제어 흐름이 아닌 LLM 출력에 의해 주도된다.

중요하게도, MAS는 가벼운 클라이언트 측 프레임워크의 집합으로만 볼 수 없다. 대신 동적인 상호작용, 획득한 행동, 및 다양한 실패 모드로 특징지어지는 복잡한 시스템이다. 이러한 특성은 예측 가능성, 관찰 가능성이 있고 성능 격리라는 전통적 가정을 도전하며, 기존의 시스템 최적화 기법이 이 맥락에서 효과적이지 않게 만든다. 따라서 MAS 실행 동작을 체계적으로 분석하는 벤치마크 스위트는 성능 최적화를 추구하는 시스템 운영자와 혁신적인 기회를 찾고자 하는 연구원 모두에게 필수적이다.

불행히도, LLM 기반 MAS의 표준화된 벤치마크는 여전히 제한적이며 종종 MAS 실행 동작에 대한 광범위한 커버리지를 제공하지 못한다. 이전 작업은 주로 서버 측 모델 성능을 평가하는 LLM 서비스와 추론 효율성에 초점을 맞추었다. 그러나 LLM 기반 MAS의 등장과 함께 최근 벤치마크는 개별 에이전트의 능력 (예: 도구 사용 및 의사소통 전략)을 평가하기 시작했지만, 이들은 주로 애플리케이션 수준 성능 (예: 작업 성공률 및 응답 품질)에 중점을 두고 있으며 시스템 수준의 MAS 실행 영향과 해당 워크로드 관리 도전을 포괄적으로 표준화된 관찰적 관점으로 제공하지 못한다. 이러한 분산은 복잡한 런타임 동작을 논리적으로 이해하고 일관되게 시스템을 비교하는 것을 어렵게 만든다.

이 간극에 부합하여 최근 조사에 따르면 약 75%의 팀이 실제 MAS를 평가할 때 벤치마크 없이 운영하고 있으며, 25%는 사용자 정의 벤치마크를 구축하지만 이로 인해 시나리오 간의 포트폴리오와 재사용성이 제한된다.

이 관찰을 바탕으로 LLM 기반 MAS에 대한 우수한 벤치마크가 가져야 할 핵심 목표를 다음과 같이 정의한다:

O1: 아키텍처의 다양성. LLM 기반 MAS의 실행 스택은 매우 유연하다. 한 가지 목적을 달성하는 다양한 구성, 에이전트 수, 역할 배치, 상호작용 토폴로지 (예: 중앙 집중형, 계층적 또는 피어-투-피어), 및 통신 프로토콜이 포함된다. 또한 설계 공간은 오케스트레이션 프레임워크, 백엔드 LLM, 예산 제약 조건, 도구 가용성, 메모리 메커니즘과 같은 선택사항을 포함하며 반영 및 종료에 대한 정책도 포함한다.

O2: 기능의 대표성. 에이전트 워크플로와 실제 배포의 급속한 확산은 MAS 아키텍처의 다양성을 증가시켰다. 최근 설계는 점점 더 복잡해진 조정 및 추론 전략을 탐구한다. 결과적으로 단일 아키텍처를 전체 MAS 디자인 공간의 대표로 고려하기 어렵다.

O3: 실행 가시성. 현재 상업용 에이전트 시스템은 종종 높은 수준의 추론 추적을 노출하지만 실행 수준 세부 사항 및 내부 시스템 상태에 대한 표준화되지 않은 제한된 가시성을 제공한다. 또한 존재하는 MAS 모듈들은 통일된 텔리미트 표준이 부족하여 “침묵” 정보 소비를 초래하며, 다양한 LLM 공급자와 프레임워크가 사용자에게 중요한 운영 데이터를 노출하지 못하게 한다.

이 간극을 해결하기 위해 MAESTRO라는 포괄적이고 오픈소스 평가 스위트를 제시한다. MAESTRO는 다양한 에이전트 아키텍처, 상호작용 패턴 및 런타임 조건에서 실행 동작을 체계적으로 분석하여 원칙적인 시스템 최적화에 대한 통찰력을 제공하는 것을 목표로 설계되었다.

우리의 기여는 세 가지다:

풍부하고 확장 가능한 벤치마크. MAESTRO에는 다양한 아키텍처 차이를 가진 12가지 대표적인 MAS 예제가 포함되어 있으며, 이를 통해 체계적 통찰력을 도출하는 데 기반을 마련한다 ([tab:systematic-findings] 참조). 또한 MAESTRO는 확장성을 위해 설계되었으며, 커뮤니티가 기존의 MAS 구현을 우리의 평가 프레임워크에 최소한의 노력으로 통합하고 재사용할 수 있도록 한다.

프레임워크 무관한 시스템 통합. MAESTRO는 널리 사용되는 오픈 소스 에이전트 프레임워크와 예제들 위에 구축되어 실제 관찰된 일반적인 아키텍처 패턴을 포착하기 위해 설계되었다.

통일된 실행 수준 텔리미트 표준. MAESTRO는 다양한 모듈에서 포괄적인 실행 데이터를 캡처하기 위한 통일된 텔리미트 인터페이스를 정의하고 구현한다. 이 아키텍처는 다양한 MAS 구성 요소가 따르는 공통 프로토콜을 설정하여 시스템 수명 주기 내내 일관되고 투명한 모니터링을 보장한다.

MAESTRO는 https://github.com/sands-lab/maestro 에서 이용 가능하다.

배경

LLM 기반 MAS의 구조

LLM 기반 다중 에이전트 시스템은 개별 에이전트가 처리할 수 없는 큰 작업을 완료하기 위해 동반 운영되는 LLM 에이전트들의 집합이다. 일반적인 MAS에서 여러 전문 에이전트들은 계획, 조정 및 실행을 통해 큰 작업을 수행하며 각각의 개인 에이전트는 특정 하위 작업에 중점을 둔다.

구성 요소. LLM 에이전트는 생성적 기본 모델과 외부 도구, 메모리, 추론 및 계획 능력을 결합하여 다단계 작업을 자동으로 수행하는 엔티티이다. 각 에이전트는 고도로 동적인 환경에서 적응성과 전략적인 의사결정이 필수적인 상황에서 독립적으로 작동하도록 설계된다. 각 에이전트는 다음 네 가지 핵심 부분으로 구성된다:

오케스트레이션 및 배포. 실무자는 LangGraph, CrewAI, AutoGen, LlamaIndex, Agno 등의 에이전트 프로그래밍 프레임워크에서 작성한 워크플로를 통해 MAS를 오케스트레이션한다. 이러한 세 번째 당사자 프레임워크는 설문조사에 따르면 인기가 있지만, 실무자를 대상으로 한 자세한 인터뷰 결과 85%의 경우 실무자가 애플리케이션을 직접 구축하는 것을 선호한다고 나타났다. 이러한 워크플로는 개발자가 시스템에서 허용하는 독립성 수준에 따라 정적 또는 동적으로 구성될 수 있다. 현재 MAS는 단일 모노리식 애플리케이션으로 배포되지만, 점점 분산형 애플리케이션으로 개발 및 배포되고 있다.

워크플로 구조. MAS 워크플로는 하위 작업의 트리 구조를 갖는 계층적 구조를 따르며 각각의 하위 작업은 순차적 및 병렬 흐름을 혼합한다. 워크플로에는 개별 에이전트에 대한 재귀 호출도 포함될 수 있다.

실패 유형. MAS 애플리케이션은 세 가지 주요 실패 유형을 보여준다 — 시스템 설계 문제, 에이전트 간 불일치, 작업 검증. 시스템 설계 문제에는 구성 문제, API 및 시스템 문제, 자원 관리 부족 등이 포함된다. 에이전트 간 불일치 문제는 실행 중에 에이전트 간 상호작용 및 조정에서 중요한 정보 흐름의 붕괴로 발생하며 이를 포함하여 계획 및 조정 오류, 잘못된 출력 생성, 개별 LLM 환각, 잘못된 정보 처리가 있다. 작업 검증 실패는 확인 전략이 문제를 식별하는 데 부족하기 때문에 발생한다.

비결정성의 원인. MAS 애플리케이션은 동적이고 다양한 특성을 갖기 때문에 여러 이유로 비결정성을 보여준다. 첫째, LLM들은 본질적으로 확률적이며 동일한 입력에 대해 다른 출력을 생성한다. 둘째, 외부 도구 실행은 사전 계획이나 프로그래밍되지 않으며 도구는 비결정적인 결과를 발생시킬 수 있다. 셋째, 워크플로는 실시간에서 변경되며 동적 워크플로의 비결정성은 에이전트의 가용성으로 더욱 악화될 수 있다. 넷째, 내장된 신뢰성을 유지하는 메커니즘은 MAS 실행의 성능과 구조에 영향을 미치며, 예를 들어 품질 중심 재시도는 실행 그래프를 변경한다.

신뢰성의 첫 번째 시민권. 전형적인 MAS 애플리케이션은 설계 및 구현에서 신뢰성을 첫 번째 시민권으로 다룬다. 이를 여러 가지 방법으로 수행한다. 첫째, 대부분의 MAS 애플리케이션은 인간-인-더-루프 평가에 의존하며 거의 절반의 애플리케이션이 5단계 이하로 실행한 후 인적 개입을 원하는 것으로 나타났다. 또한, 개발자는 LLM-as-a-judge를 사용하여 품질 검사를 자동화한다. MAS 애플리케이션은 또한 품질 검사가 실패할 경우 품질을 개선하기 위해 재시도를 자동화한다. 둘째, 실무자는 1분 이상의 응답 시간을 허용하는 66%의 최근 설문조사 응답자가 실시간 반응성보다 품질을 우선시한다. 셋째, 실무자는 배포된 에이전트의 독립성을 제약하기 위해 정적 워크플로를 동적 워크플로보다 선호한다.

기존 벤치마크의 한계

LLM의 효율성 및 효과를 측정하는 중요한 측면 중 하나는 실제 작업을 수행할 때 LLM의 성능을 평가하고 벤치마킹하는 것이다. 최근 LLM 에이전트와 MAS 애플리케이션의 급속한 증가로 인해 기계 학습 연구 커뮤니티에서 에이전트 시스템의 성능을 측정하기 위한 벤치마킹에 대한 관심이 크게 증가했다.

에이전트 벤치마크. 전형적인 에이전트 벤치마크는 개별 LLMs의 능력을 평가한다. 이러한 벤치마크는 다중 에이전트 환경으로 확장되었다. 연구자들은 도구 호출, 작업 계획, 의사소통 전략, 순차적 흐름, 개인정보 보호, 협업 효율성과 같은 아키텍처의 특정 속성을 평가하기 위해 특수화된 벤치마크를 개발하였다. 이러한 특수화된 벤치마크는 MAS 애플리케이션의 한 가지 특정 속성이나 차원만 집중적으로 살펴보며, 전체적인 에러 및 성능을 효과적으로 이해하는데 필요한 통합적 관점을 제공하지 못한다.

사용자 정의 벤치마크. MAS 설계 공간의 다양성과 표준화 부족으로 인해 개발자는 종종 특정 애플리케이션에 맞는 사용자 정의 벤치마크를 작성한다. 예를 들어, AutoGen의 저자는 AutoGen 프레임워크에서 개발된 작업을 위한 사용자 정의 벤치마크인 Autogenbench를 만들었다. 최근 설문조사에 따르면 25%의 팀은 MAS 애플리케이션용으로 사용자 정의 벤치마크를 작성하고 있으며, 나머지 75%의 팀은 공식 벤치마크 없이 에이전트를 평가하며 대신 A/B 테스트와 직접적인 전문가/사용자 피드백을 사용한다. 이러한 벤치마크는 특정 애플리케이션에 적합하지만, MAS 설계 공간의 다양성을 포착하거나 광범위한 환경에서 통찰력을 제공하는 데에는 부족하다.

관찰 도구와 벤치마크. 관찰성 도구 및 Opik, TRAIL, TAMAS와 같은 관찰성 기반 벤치마크는 MAS 실행의 스팬과 추적을 포착하여 개발자가 문제를 진단하고 MAS 실행을 이해하기 위해 추적 분석에 사용한다. 표준 지표를 넘어서, 이러한 도구는 에이전트 호출 빈도, 외부 API 사용률 등을 제공하지만, 전체적인 관찰성은 제한적이다.