핵심 요약
기존의 LLM-as-a-Judge 방식은 텍스트 표면의 정보에만 의존하여 복잡한 환경에서 동작하는 에이전트를 평가하는 데 한계가 있었다. 이 논문은 에이전트가 직접 도구를 사용하고 환경을 탐색하며 증거를 수집해 평가하는 Agent-as-a-Judge 패러다임을 제안하고 이를 위한 체계적인 벤치마크를 구축했다.
왜 중요한가
기존의 LLM-as-a-Judge 방식은 텍스트 표면의 정보에만 의존하여 복잡한 환경에서 동작하는 에이전트를 평가하는 데 한계가 있었다. 이 논문은 에이전트가 직접 도구를 사용하고 환경을 탐색하며 증거를 수집해 평가하는 Agent-as-a-Judge 패러다임을 제안하고 이를 위한 체계적인 벤치마크를 구축했다.
핵심 기여
AJ-Bench 벤치마크 구축
검색, 데이터 시스템, GUI 등 3개 도메인에 걸쳐 155개의 작업과 516개의 주석 처리된 궤적을 포함하는 종합적인 평가 프레임워크를 설계했다.
Agent-as-a-Judge 패러다임 검증
평가자 에이전트가 외부 도구를 활용해 정보를 획득하고 상태 및 프로세스를 검증하는 능력을 체계적으로 평가하여 기존 LLM-as-a-Judge 대비 성능 향상을 입증했다.
다양한 검증 모드 제안
정보 획득(Information Acquisition), 상태 검증(State Verification), 프로세스 검증(Process Verification)의 세 가지 핵심 차원을 통해 에이전트의 판단 능력을 다각도로 분석했다.
핵심 아이디어 이해하기
기존의 LLM 기반 평가는 모델이 생성한 텍스트 답변이 정답지와 얼마나 유사한지를 측정하는 Softmax 기반의 확률적 일치나 단순 텍스트 비교에 머물러 있었다. 하지만 복잡한 환경에서 동작하는 에이전트는 실행 과정에서 수많은 중간 상태를 생성하며, 단순히 최종 텍스트만으로는 그 과정의 정당성을 판단하기 어렵다.
이 논문은 평가자에게도 '행동 능력(Agency)'을 부여해야 한다는 아이디어에서 출발한다. 평가자 에이전트는 고정된 텍스트만 보는 것이 아니라, 피평가 에이전트가 남긴 흔적을 따라가며 직접 브라우저를 열어 정보를 검색하거나 데이터베이스 쿼리를 날려 실제 데이터가 변경되었는지 확인한다. 이는 딥러닝에서 Embedding 공간의 거리를 계산하는 것을 넘어, 실제 물리적/디지털 환경의 상태 변화를 Ground Truth로 삼는 방식이다.
결과적으로 평가자 에이전트는 스스로 도구를 사용하여 검증에 필요한 증거를 수집하며, 이를 통해 기존 모델들이 잡아내지 못했던 미세한 오류나 실행 과정의 논리적 결함을 찾아낼 수 있게 된다.
관련 Figure

단순 텍스트만 보는 LLM-as-a-Judge는 최신 정보를 확인하지 못해 오답을 내리지만, 도구를 사용하는 Agent-as-a-Judge는 직접 브라우징을 통해 정확한 출시일을 확인하고 올바른 판단을 내리는 과정을 보여준다.
LLM-as-a-Judge와 Agent-as-a-Judge의 평가 방식 차이를 보여주는 다이어그램.
방법론
AJ-Bench는 검색(Search), 데이터 시스템(DS), 그래픽 사용자 인터페이스(GUI)의 세 가지 도메인으로 구성된다. 각 도메인은 에이전트가 도구를 사용해야만 해결할 수 있는 복잡한 시나리오를 포함하며, 평가자 에이전트는 Playwright MCP 도구 등을 사용하여 환경과 상호작용한다.
평가 프로세스는 크게 두 단계로 나뉜다. 첫 번째 단계는 환경 설정 및 재생(Env Setup & Replay)으로, 피평가 에이전트의 궤적을 실제 환경에서 재현하여 최종 상태를 구축한다. 두 번째 단계는 세 가지 모드의 검증이다. 정보 획득 모드에서는 외부 검색을 통해 증거를 찾고, 상태 검증 모드에서는 파일이나 DB의 변화를 직접 확인하며, 프로세스 검증 모드에서는 실행 단계별 논리를 검사한다.
수학적 평가 지표로는 예측값과 실제 정답 간의 F1 Score를 사용한다. [정밀도(Precision)와 재현율(Recall)을 입력으로] → [2 * (P * R) / (P + R) 연산을 수행해] → [하나의 조화 평균값을 얻고] → [이 숫자가 높을수록 평가자 에이전트의 판단이 인간의 주석과 일치함을 의미한다].
관련 Figure

작성 설계, 궤적 수집, 라벨링 단계부터 실제 환경 설정 및 세 가지 검증 모드(프로세스, 상태, 정보 획득)를 통한 평가 프로세스를 상세히 설명한다.
AJ-Bench의 전체적인 구축 및 평가 파이프라인 개요도.
주요 결과
실험 결과, 동일한 백본 모델을 사용할 때 Agent-as-a-Judge 설정이 LLM-as-a-Judge 방식보다 평균 13% 포인트 높은 F1 Score를 기록했다. 특히 GUI 도메인에서는 도구 사용을 통해 성능이 최대 31.23% 포인트까지 대폭 향상되는 결과를 보였다.
Ablation Study를 통해 추론 노력(Reasoning Effort)과 상호작용 횟수(Interaction Turns)의 영향을 분석했다. 상호작용 횟수가 늘어날수록 전반적인 성능은 향상되었으나, 단순히 모델의 추론 단계를 늘리는 것(Thinking)이 항상 더 나은 판단으로 이어지지는 않음을 확인했다. 이는 도구 사용을 통한 실질적인 증거 확보가 단순 사고력보다 평가 정확도에 더 결정적인 역할을 함을 시사한다.
관련 Figure

Search(61개), DS(42개), GUI(52개) 작업이 각각 어떤 세부 카테고리(FileSystem, Postgres, Excel, PPT 등)로 구성되어 있는지 시각적으로 보여준다.
AJ-Bench의 도메인 및 하위 작업 분포를 나타내는 선버스트 차트.

최대 상호작용 횟수(Turns)가 늘어날수록 모든 도메인에서 성능이 향상되지만, 도메인마다 성능 포화 지점이 다름을 보여준다.
상호작용 횟수 증가에 따른 도메인별 F1 Score 변화 그래프.
기술 상세
AJ-Bench는 Mind2Web2, WideSearch, MCPMark, OSWorld 등 기존 데이터셋을 기반으로 에이전트 평가에 적합하도록 재구성되었다. 평가자 에이전트는 MCP(Model Context Protocol)를 통해 브라우저, 파일 시스템, 데이터베이스와 통신하며, 각 도메인별로 특화된 프롬프트 전략을 사용한다.
구현 측면에서 GUI 도메인은 OSWorld 컴포넌트를 활용하여 AWS 인스턴스에서 독립적인 환경을 구축하고 궤적을 재현한다. 평가 모델로는 GPT-5, Gemini 2.5 Pro, DeepSeek-V3.2 등 최신 SOTA 모델들이 벤치마킹되었으며, 모델의 내재적 추론 능력과 외부 도구 활용 능력 간의 상관관계를 분석하기 위해 다양한 설정에서 실험이 수행되었다.
관련 Figure

단일 모달리티보다 텍스트 기반의 A11y Tree와 시각 정보인 Screenshot을 혼합했을 때 전반적으로 가장 높은 성능을 보임을 입증한다.
GUI 도메인에서 입력 모달리티(A11y Tree, Screenshot, Mixed)에 따른 성능 비교 차트.
한계점
대부분의 작업이 기존 벤치마크에서 수정되어 가져온 것이므로 작업의 다양성과 확장성에 한계가 있을 수 있다. 또한 검색 도메인에서는 외부 웹 환경의 실시간 변화나 네트워크 연결 상태에 따라 평가 결과의 안정성이 영향을 받을 수 있다는 점이 명시되었다.
실무 활용
복잡한 워크플로우를 수행하는 AI 에이전트의 성능을 자동으로 검증하고 신뢰할 수 있는 보상 신호(Reward Signal)를 생성하는 데 활용 가능하다.
- 자율 코딩 에이전트가 작성한 코드의 실제 동작 여부를 환경 내에서 직접 실행하여 검증
- 웹 브라우징 에이전트가 수집한 정보의 최신성 및 정확성을 실시간 검색을 통해 확인
- 데이터베이스 조작 에이전트의 작업 결과가 실제 스키마 및 레코드에 올바르게 반영되었는지 감사
코드 공개 여부: 공개
코드 저장소 보기키워드
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.