[논문 정리] Agents' Last Exam

Agents' Last Exam (ALE)
UC Berkeley 외 250+ 산업 전문가 협업 · Website / GitHub / HuggingFace Leaderboard

---

Abstract

• 최근 AI는 다양한 벤치마크에서 강한 성능을 보이지만, 이 성과가 실제 전문 직군의 경제적으로 의미 있는 배포로 이어지지 못하고 있음
• 원인은 평가 자체의 문제: 기존 벤치마크가 실제·경제적으로 가치 있는 워크플로우에 대한 지속적인 성능 측정을 하지 못함
• Agents' Last Exam (ALE): 장기 호라이즌(long-horizon), 경제적으로 가치 있는, 검증 가능한 실제 업무로 AI Agent를 평가하는 벤치마크
• 250+ 산업 전문가와 협업, O*NET/SOC 2018(미국 연방 직업 분류) 기반 비물리 산업 커버
• 13개 산업 클러스터 / 55개 서브필드 / 1,000+ Task 구조
• 가장 어려운 tier는 아직 전혀 포화되지 않음: 주요 harness·backbone 조합 전체의 평균 full pass rate가 1% 미만
• Living benchmark: Task pool이 새로운 산업·워크플로우 온보딩과 함께 지속적으로 성장
• 목표는 또 하나의 리더보드가 아니라, 벤치마크 성공과 GDP 관련 영향(impact) 사이의 격차를 좁히는 도구

---

1. Introduction

• 최근 몇 년간 AI는 바둑, 올림피아드 수학, 경쟁 프로그래밍 등 유명 벤치마크를 연달아 정복했지만, 정작 경제적 산출이라는 지표에서는 그 영향이 여전히 미미함
• 벤치마크 승리는 쌓이는데 핵심 산업에서의 측정 가능한 변화는 그만큼 따라오지 못하는 utility 문제로 파악
• 벤치마크는 단순히 능력을 기록하는 게 아니라 연구의 초점, 엔지니어링 목표, 어떤 도메인이 빠르게 개선될지를 좌우함 → ImageNet이 Computer Vision에서 했던 역할처럼, 검증 가능하고 널리 쓰이는 평가가 등장한 도메인은 진전이 가속되고 배포가 뒤따름
• 하지만 금융·법률·전기공학·제조 같은 경제 핵심 섹터에는 아직 그런 벤치마크가 부재

ImageNet 비유가 이 논문의 논지를 가장 압축적으로 보여주는 대목인 듯. "벤치마크가 없어서 발전이 없다"는 인과를 실증하기는 어렵지만, 적어도 검증 가능한 평가가 특정 도메인의 연구 관심을 흡수해온 패턴은 최근 AI 역사에서 반복적으로 관찰됨.

• 이런 벤치마크를 만들기 어려운 구조적 이유 세 가지
  1. 수집 비용: 장기 호라이즌의 진짜 워크플로우는 실제 소프트웨어·조직 맥락에서 나와야 해서 수집 자체가 비쌈
  2. 산업 커버리지: 폭넓고 진짜인 워크플로우를 확보하려면 여러 도메인 전문가에 대한 지속적 접근과 산업 지형에 대한 깊은 이해가 필요
  3. 검증 난이도: 산출물 형태가 파일·스프레드시트·미디어·리포트·설계·모델 등으로 매우 이질적이라 검증이 본질적으로 어려움 → 기존 벤치마크(GDPval, Remote Labor Index 등)는 결국 사람 평가에 의존
• 기존 벤치마크들은 사실성(realism)·폭(breadth)·검증가능성(verifiability) 중 하나를 포기하는 경향, ALE는 이 세 가지를 동시에 달성하려는 시도
• "Last Exam"이라는 이름의 이중 의미: ① 경쟁력의 최종 관문 — 이 시험을 통과하면 해당 직군에서 지속적으로 경제적 가치를 내는 업무 수행 준비가 됐다는 뜻 ② 난이도의 최전선 — 전문적 판단이 필요한 진짜 장기 워크플로우에 기반하므로 현재 시스템이 신뢰성 있게 해낼 수 있는 경계에 위치
• ALE는 1,000+ Task instance, 55 subfield, 13 industry cluster로 구성, 250+ 전문가와 협업, O*NET/SOC 2018에 근거해 직업 분류 지형을 매핑
• 대부분 Task는 GUI 상호작용(데스크톱 앱, 브라우저, 도메인 특화 소프트웨어)과 CLI 조작(셸 스크립팅, 코드 실행, 파일 조작)을 함께 요구 → 기존 벤치마크가 따로따로 테스트하던 능력의 합집합을 요구
• 현재 결과: 최강 조합(Codex + GPT-5.5, Terminal-Bench에서 82%)조차 ALE의 가장 쉬운 tier에서 50% 미만, 가장 어려운 tier에서는 10% 미만; Claude Code를 포함한 대부분의 mainstream agent는 그 tier에서 거의 0%

---

2. Benchmark Design and Dataset Construction

2.1. 설계 원칙 — 어떤 Task를 원하는가

• Representativeness(대표성): 실제 전문가가 실제로 쓰는 소프트웨어와 일치해야 함. 예: 2D 도면을 3D 모델로 바꾸는 건축 작업이면 AutoCAD가 아니라 SolidWorks/Rhino를 써야 자연스러움
• Complexity(복잡성): 몇 번의 UI 조작이 아니라 전문가가 상당한 시간을 들이는 end-to-end 산출물이어야 함(workflow vs. action의 구분). "DaVinci에서 색 필터 적용" 같은 단일 로컬 편집은 부적합, "달리는 치타를 다른 경주 영상에 합성"처럼 트래킹·로토스코핑·컴포지팅·컬러 매칭이 묶인 작업이 적합
• Verifiability(검증가능성): 결정론적 채점이나 명확한 rubric이 가능한 관측 가능 산출물이어야 함. "몬스터 나오는 RPG 게임 설계" 같은 건 객관적으로 확인할 목표가 없어 부적합, "게임 mota.exe를 RPGMaker XP로 재현"은 지도 구조·캐릭터 속성·이벤트 상태를 참조본과 자동 비교할 수 있어 적합

2.2. Benchmark Scope and Taxonomy

• 산업을 임의로 고르거나 경제 규모순으로 고르지 않고, SOC 2018 + O*NET에 taxonomy를 정박(anchor)
• 소프트웨어 매개 워크플로우가 비슷한 직업들을 클러스터링, 핵심 업무가 디지털이 아닌 섹터는 제외 → 13개 도메인, 55개 서브도메인
• 기존 16개 주요 벤치마크의 공개 카테고리를 LLM-assisted classifier로 같은 55-subdomain taxonomy에 매핑한 결과, 그 union조차 55개 중 13개 서브도메인을 전혀 커버하지 못함

2.3. Task Construction Pipeline

• Task는 일반 크라우드워커가 아니라 반드시 도메인 전문가의 실제 루틴에서 나와야 하고, 엄격한 심사를 통과해야 함

• 5단계 게이트
  1. Expert sourcing: 산업 자문위원회를 통해 도메인 전문가 모집
  2. Task submission: 전용 웹 포털에서 전문가가 실제 며칠~몇 주 걸렸던 과거 프로젝트를 업로드, AI-assisted 도구로 설명·입력파일·대상 소프트웨어·기대 산출물·평가 스펙 5요소를 다듬음
  3. First-pass review: 학회 스타일 심사(major/minor revision, borderline accept, accept, strong accept)
  4. Task implementation: 승인된 스펙을 실행 가능한 자산·소프트웨어 컨테이너·평가 로직으로 변환, 엔지니어 dry-run 포함
  5. Final QC: 전문가 위원회의 동료 검토 — 참조 산출물의 정확성, 평가 기준의 적절한 보정(너무 좁지도 헐겁지도 않게), 문맥의 충분성을 확인

이 5단계 게이트 구조 자체가 "벤치마크의 신뢰도는 결국 심사 프로세스의 신뢰도"라는 걸 보여주는 부분. 데이터셋 논문인데 사실상 저널 리뷰 프로세스를 그대로 이식한 느낌이라 흥미로움.

• 공개/비공개 전략: 오염(contamination) 문제 때문에 전체 1,490개 Task instance 중 150개(~10%)만 공개, 나머지는 비공개 풀에 보관, 롤링 방식으로 주기적으로 교체

---

3. Evaluation Pipeline

3.1. Pipeline Architecture

• Task 하나는 서로 독립적으로 교체 가능한 세 요소로 구성
  • Task Specification (main.py): description·input assets·target software·reference assets·evaluation criteria를 담고, load()(선언) → start()(VM을 결정론적 초기 상태로 세팅) → evaluate()(0~1 점수 반환) 세 생명주기 함수를 노출
  • Agent: harness + foundation model, task description과 metadata만 받아 스크린샷·셸 출력·마우스/키보드·파일 편집·API 호출로 구성된 action loop를 종료할 때까지 반복
  • Environment: 원격 VM, input/(읽기전용) · software/(사전 설치 앱) · output/(Agent가 쓸 수 있는 유일한 대상) · reference/(Agent에게 숨겨진 정답) 4-디렉토리 구조

3.2. Agent Architecture: Generalist CUA (GCUA)

• Agent의 능력을 5개 기능 계층으로 분해: Brain(LLM 추론·계획) · Eyes(스크린샷 기반 GUI 인지) · Body(오케스트레이션) · Hands(구조화된 Tool 호출) · Feet(행동이 실제로 작동하는 런타임)
• 기존 CLI-agent(SWE-agent 등)는 Brain/Body/Hands/Feet은 갖췄지만 Eyes가 없고, GUI-agent는 Brain/Eyes는 있지만 Body/Hands/Feet이 얕음 → ALE가 요구하는 건 5개 층 모두를 갖춘 Generalist CUA-agent (GCUA)
• 대표적 harness(Claude Code, Codex, OpenClaw)는 main agent loop + 모듈형 system prompt builder + 통합 tool system + sub-agent dispatch + context compaction manager 구조로 수렴 중
• GUI 확장은 두 방식: GUI-as-Tool(메인 루프에 GUI 조작을 일반 Tool처럼 노출) / GUI-as-SubAgent(GUI 상호작용을 별도의 vision-language sub-agent에 위임, 네이티브 비전 입력이 없는 모델용). 본 논문의 주 평가는 GUI-as-Tool 사용

Brain/Eyes/Body/Hands/Feet 분해가 은근 깔끔한 프레임. 지금 나온 대부분의 harness가 "CLI는 완비, GUI는 부실" 아니면 그 반대라는 걸 한 장의 표로 정리한 셈이라, 왜 GCUA라는 새 범주가 필요한지 설득력이 생김.

3.3. Evaluation Modes

• 산출물이 CAM toolpath·재무 워크북·3D mesh·게임 월드 상태·렌더링된 스크린샷·자유 텍스트 리포트 등으로 극도로 이질적
• 비교 형태(comparison form): exact/hashed value, tolerance 있는 구조화된 수치/표, geometric surface·point-cloud distance, 시각적 외관(vision-LLM judge), 고정 입력 궤적 하의 behavioral world state, free-text rubric
• 결합 방식(composition): gate-and-score(이진 전제조건 통과 후 연속 점수 부여, 부분 진행에 관계없이 게이트 실패시 0점) 또는 이진 체크리스트/파일별 점수 평균
• ALE는 결정론적 대안이 있는 한 LLM-as-judge를 의도적으로 피함: "결과가 맞아 보이는지 물어보는" 방식만 있는 Task는 QC에서 반려되어 검증 가능한 산출물을 노출하도록 재설계됨. LLM judge가 불가피한 소수(비디오 클립, 게임 스크린샷 등)는 범용 판단 대신 근거에 근거한 narrow yes/no probe로 채점

---

4. Experiment

4.1. Main Results (요약)

• 모든 시스템을 GUI-as-Tool 모드의 GCUA 구성으로 통일해 평가, 표준화된 CUA MCP bridge로 14개 desktop-action tool 제공
• Run당 5시간 캡, 전체 타임아웃 비율 3.8%
• Near-Term(67개) / Full-Spectrum(55개, 55개 서브도메인 각각 최소 1개 포함) / Last-Exam(38개, 대부분 0% pass) 3단계 난이도로 구성

주요 결과(발췌)

구성	Overall Pass Rate
Codex (GPT-5.5)	24.0% — 최고
ALE-Claw (GPT-5.5)	23.0%
OpenClaw / GPT-5.5 (모델 스윕 최고)	21.1%
Grok CLI (Grok 4.3)	6.6% — mainstream 중 최저

• 모든 구성에서 Last-Exam tier는 대부분 0%대, 최강 조합도 10%대 초반에 그침
• ALE-CLI(Linux 전용 105개 서브셋)는 Terminal-Bench와 규모는 비슷하지만 훨씬 어려움: Terminal-Bench에서 82%를 찍는 Codex+GPT-5.5도 ALE-CLI에서는 23.3%
• ALE-Claw: 논문 저자들이 자체 구현한 단순화된 GCUA reference (OpenClaw 기반, 장기 메모리·개인화 등 제품 기능 제외) — 동일 모델 기준 default OpenClaw와 비슷한 성능

4.2. Analysis

• 도메인별 성능: Claude Fable 5·GPT-5.5 모두 계산수학/농업·환경 도메인이 가장 높고(~55–85%), 교육 도메인이 가장 낮음(25% 미만) — 코드 인접 도메인이 학습 중 더 많이 노출됐을 가능성을 반영
• Tool 사용: 공개 Task의 34%가 그래픽 소프트웨어를 주 Tool로 지정하지만, 실제 GUI Tool 사용 비중은 낮음 — Agent들이 GUI 대신 Bash/CLI 대체 수단을 즉흥적으로 쓰는 경향
• 실패 유형 분류(Claude Code + Opus 4.7): Understanding(31%) + Approach(47%)가 실패의 약 3/4을 차지 → 병목이 실행 능력이 아니라 도메인 지식임을 시사. 나머지는 Execution(22%)

실패의 대부분이 "몰라서 틀렸다"는 쪽이라는 게 핵심. Execution 오류(포맷, 버그)는 22%뿐이라, 툴을 더 정교하게 만드는 것보다 도메인 지식을 채워 넣는 쪽이 더 큰 레버리지일 수 있다는 뜻으로 읽힘.

• Model vs. Harness 효과: 동일 harness(OpenClaw)에서 backbone 모델을 바꾸면 pass rate가 16.8%p까지 벌어지는 반면, 동일 backbone에서 harness만 바꾸면 4.9~7.2%p 차이 → 모델의 추론·도메인 지식이 harness 엔지니어링보다 약 3배 더 큰 영향
• 비용/시간 효율성: 높은 비용·시간·토큰 소비가 반드시 더 나은 성능으로 이어지지 않음(예: ALE-Claw+GPT-5.5가 가장 저렴하면서 최고 점수)

---

5. Related Work

• 지식·시험형 벤치마크(MMLU, GPQA, HLE): 주제는 넓지만 "무엇을 아는지"만 측정, "무엇을 할 수 있는지"는 측정하지 않음
• Agentic 벤치마크(SWE-bench, OSWorld, WebArena, GAIA): 멀티스텝 상호작용·Tool 사용을 더하지만 소프트웨어 중심의 소수 도메인만 커버, 큐레이터가 만든 Task에 의존
• 경제 지향 프로젝트형 벤치마크(GDPval, Remote Labor Index): 경제적으로 근거 있는 프로젝트 스케일 평가를 지향하지만 각각 55개 중 16개, 14개 산업만 커버하고 비싼 사람 채점에 의존
• ALE의 위치: 55개 SOC/O*NET 산업을 모두 커버하는 첫 벤치마크, 모든 Task가 300+ 실무자가 실제로 완료한 프로젝트에서 나오며, 사람 평가 대신 결정론적·rubric 기반 자동 검증으로 대체

---

6. Conclusion

• ALE: 960개 전문가 저작 Task workflow(1,490개 Task instance), 55개 디지털 산업, SOC/O*NET taxonomy에 근거, 개방형 LLM judging이 아닌 결정론적 체크와 구조화된 rubric으로 채점
• 현재 Frontier Agent는 극히 일부만 통과 — 벤치마크 성공과 GDP 관련 영향 사이의 격차를 좁히는 도구로 공개
• 포화(saturation)는 곧 Agent가 전문 업무가 실제로 요구하는 장기적·Tool 집약적 작업을 지속할 수 있게 됐다는 신호가 될 것

---

부록에는 55개 서브도메인별 산업 지형 리뷰, Task 카드 예시(사출성형 CAE, 오케스트라 채보, 크로마키 합성, 스켈레탈 애니메이션, 흉부 X-ray 판독 등), 평가 모드 전체 taxonomy, harness 내부 구조, timeout·per-task 히트맵 등 방대한 세부 분석이 이어짐 — 본문 핵심 논지에는 영향이 크지 않아 이 요약에서는 생략.

전체적으로 이 논문의 무게중심은 "얼마나 어려운 벤치마크인가"보다 "얼마나 신뢰할 수 있는 평가 파이프라인을 만들었는가"에 더 실려 있는 느낌. 5단계 게이트, gate-and-score, LLM-judge 최소화 같은 장치들이 전부 같은 목표(검증 가능성 확보)를 향해 있고, 결과 자체(1% 미만 pass rate)는 그 인프라가 잘 작동한다는 걸 보여주는 부산물에 가까움.