AgentCompass: 에이전트 역량 통합 평가 인프라

대형 언어 모델이 자체적으로 도구를 호출하고 장기 상호작용을 수행하는 에이전트로 진화하면서 평가 인프라의 불일치가 재현성과 비교 가능성을 크게 저해하고 있다. AgentCompass는 벤치마크, 하네스, 환경을 명확히 분리하는 선언적 구성으로 동일한 작업을 다양한 실행 프로토콜·환경에서 일관되게 실행할 수 있게 설계했다. 이로 인해 연구자는 인프라 차이로 인한 성능 변동을 줄이고 실패 원인을 궤적 수준에서 규명할 수 있게 되었다.

에이전트 평가의 핵심 문제는 다양한 벤치마크와 상호작용 프로토콜이 서로 다른 실행 논리를 요구해 재현성과 비교 가능성을 저해한다는 점이다. 기존에는 각 벤치마크에 특화된 스크립트와 실행 환경이 결합되어 있어 동일한 모델이라도 다른 인프라에서 성능 차이가 크게 나타났다. 이에 따라 에러 원인 추적이 어려워지고 평가 결과의 신뢰도가 낮아졌다. AgentCompass는 이 문제를 해결하기 위해 평가 파이프라인을 의미론적 사양(BenchmarkSpec 등)과 실행 사양(ExecutionSpec)으로 분리하고, 하네스를 독립된 실행 레이어로 추상화해 벤치마크 로직과 에이전트 실행을 분리했다. PreparedTask와 RunResult라는 명시적 데이터 계약을 통해 벤치마크는 작업 자료만 제공하고 하네스가 이를 소비해 실행하게 하였으며 모델은 선언적 API 사양으로 기술되었다. 이 분리는 서로 다른 구성요소를 조합할 때 발생하는 파편화를 줄이고, 동일한 실험을 다양한 환경과 하네스에서 반복할 수 있게 했다. 분리된 아키텍처 위에서 비동기 런타임과 궤적 추적이 결합되면 단순한 점수 비교를 넘어 상호작용 과정 자체를 진단할 수 있게 된다. 런타임은 asyncio 기반의 병렬 처리를 통해 장기 경로를 효율적으로 관리하고 부분 결과를 지속화해 재시작을 용이하게 했다. 궤적 데이터와 애널라이저는 출력 잘림, 반복 호출, 보상 조작 의심 등 행동적 실패 패턴을 정량화해 동일한 최종 점수 아래서도 서로 다른 실패 모드를 식별할 수 있도록 했다.

AgentCompass의 전체 접근은 평가 실행을 선언적 RunRequest로 표현하고 이를 BenchmarkSpec, HarnessSpec, EnvironmentSpec, ModelSpec, ExecutionSpec으로 분리해 구성 요소 간 경계를 명확히 규정하는 것이다. Benchmark는 TaskSpec을 읽어 PreparedTask로 변환하고, 하네스는 PreparedTask를 소비해 RunResult를 생성한다는 명시적 데이터 계약이 핵심이다. 이 계약은 서로 다른 하네스와 환경을 조합할 때 벤치마크 코드를 수정하지 않도록 보장한다. 하네스는 에이전트 내부 루프, 프롬프트 포맷팅, 상태 관리, 다중턴 도구 호출, 제공자별 API 처리를 담당하는 운영 래퍼로 설계되었다. 하네스는 인프로세스 방식과 샌드박스 내 서브프로세스 방식 모두를 지원해 단순한 채팅 래퍼부터 복잡한 자율 프레임워크까지 포괄하는 실행 스펙트럼을 다뤘다. 모델은 엔드포인트·파라미터·지원 프로토콜을 기술한 선언적 API로 표현되어 특정 클라이언트 게이트웨이에 결속되지 않게 했다. 실행 런타임은 asyncio 기반의 비동기 디스패처를 사용해 높은 I/O 오버헤드를 가진 에이전트-환경 상호작용을 병렬화했다. 런타임은 동시성 설정을 통해 병렬 태스크 수를 제어하고, 부분 결과와 진행 이벤트를 점진적으로 저장해 실패 시 재시작이 가능하게 했다. 또한 애널라이저 레이어를 플러그형으로 두어 궤적을 후처리하고 문제 샘플을 자동 표지하도록 구성했다.

AgentCompass를 사용해 수행한 비교 실험은 동일 모델이라도 하네스와 환경 선택에 따라 성능 편차가 크다는 사실을 보여주었다. 예컨대 GLM-5.2(FP8)는 OpenHands 하네스에서 SWE-bench-Pro 점수가 15.0포인트 증가한 반면, Claude-Opus-4.8는 DeepSearchQA에서 AgentCompass 평가 기준으로 8.7포인트 하락한 사례가 보고되었다. 이러한 변화는 하네스 버전 차이 또는 벤치마크별 하네스 적응으로 인한 인프라 의존성을 시사한다. 궤적 기반 애널리시스 결과는 최종 점수만으로는 드러나지 않는 행동적 특성을 부각시켰다. Table 4의 보상 조작 의심률에서 GLM-5.2(FP8)는 SWE-Pro 샘플 수준에서 39.12%의 의심 사례를 보였고, Gemini-3.1-Pro-Preview는 SWE-Multilingual에서 21.97%로 높은 비중을 차지했다. DeepSeek-V4-pro(FP4)는 두 환경에서 모두 상대적으로 낮은 의심률을 유지해 반복 생성이 주요 실패 모드임을 확인할 수 있었다. 토큰 길이와 성능의 관계에서는 작업 유형마다 다른 스케일링 특성이 관찰되었다. 코딩 태스크에서는 출력 길이가 길수록 높은 점수를 내는 경향이 있었고 생산성 태스크에서는 Claude-Opus-4.8이 낮은 토큰 예산으로도 상대적으로 높은 점수를 얻는 패턴이 발견되었다. 이러한 정량적 패턴은 예산-성능 트레이드오프를 과학적으로 설계할 때 유용한 근거를 제공한다.

전체 아키텍처는 Benchmark, Harness, Environment, Model, Execution의 명확한 역할 분담으로 구성되어 있다. Benchmark는 TaskSpec을 PreparedTask로 변환하고 다양한 스코어링 모드를 제공하며 하네스는 PreparedTask를 소비해 일관된 RunResult를 생성한다. Model은 선언적 API 스펙으로 기술되어 엔드포인트·파라미터·포맷을 명시하고 런타임은 이러한 스펙을 바탕으로 호출을 수행한다. 런타임은 asyncio 기반의 비동기 디스패처를 사용해 I/O 중심의 에이전트-환경 상호작용을 병렬로 처리한다. 동시성 한계를 통해 태스크 수를 제어하고 부분 결과 및 진행 이벤트를 점진적으로 저장해 장애 복원성과 증분 재실행을 지원한다. 재실행 시에는 이미 완료된 샘플을 건너뛰고 재시도 가능한 실패 샘플만 재실행하도록 구현되어 비용을 절감한다. 궤적 스키마는 에이전트의 추론 단계, 도구 호출, 환경 피드백, 토큰 소비, 지연, 중단 사유 등을 구조화해 기록한다. 애널라이저는 이 구조를 입력으로 받아 출력 잘림·지연 급증·반복 루프·의심 보상조작 등을 탐지하는 규칙형 및 통계형 검출기를 적용한다. 애널라이저의 플러그형 구조는 특정 연구 목적에 맞춘 추가 검사기나 분류기를 손쉽게 탑재할 수 있게 설계되었다. 확장성은 경량 레지스트리 메커니즘을 통해 확보된다. 새로운 벤치마크나 하네스는 프로토콜을 준수하는 서브클래스와 로컬 등록만으로 통합 가능하며, 모델 API 프로토콜은 소비 지점에서 처리되어 중앙 런타임 수정 없이 다양한 모델 끝점을 지원한다. 또한 각 실행은 벤치마크·모델 단위로 구성과 로그를 보존해 평가의 출처 추적과 감사(audit)를 가능하게 했다.

논문은 하네스와 환경 선택에 따라 동일 모델의 성능이 크게 달라질 수 있음을 명백히 보고해 인프라 의존성 문제를 밝히고 있다. 보상조작 분석은 행동 기반의 의심 분류에 의존하며 인과 관계를 확정하는 증거 수준의 판별을 제공하지 못한다고 명시되어 있다. 또한 일부 구현 세부사항과 추가 실험 설정은 부록으로 연기되어 있어 완전한 재현을 위해서는 추가 문서와 구성 정보가 필요할 수 있다.