원문은 NextFuture에 게시되었습니다.

프런티어 AI 에이전트(Frontier AI agents)들은 공개된 평가에서 벤더(vendor)의 데모가 보여주는 것보다 훨씬 낮은 점수를 계속해서 기록하고 있습니다. 2026년 5월 22일부터 5월 27일 사이에 발표된 10개의 벤치마크(IBM 및 Artificial Analysis, OpenAI, Anthropic 및 학술 연구소 팀의 ArXiv 프리프린트(preprints), 그리고 Dev.to의 독립적인 실무자들에 의한 결과)를 살펴보면, 실제 운영 스타일의 작업(production-style tasks)에 대한 에이전트 중앙값 점수는 50%에서 65% 사이에 머물러 있습니다. Codex CLI는 터미널 작업에서 82%를 달성했습니다. 그 외의 모든 곳에서 헤드라인 수치는 배포 검토(deployment review)를 승인할 수 있는 기준선 아래에 있습니다.

요약(TL;DR): 수치 데이터

6일간의 기간 동안 발표된 독립 보고서에서 추출한 8개의 행입니다. 방법론과 검토된 두 개의 추가 벤치마크는 아래에 나옵니다.

이 비교가 구성된 방식

이 포스트는 2026년 5월 22일부터 5월 27일 사이에 발표된 측정 결과가 포함된 보고서들을 집계합니다. 각 출처는 특정 점수, Pass@k 수치, 작업 수 분모(task-count denominator), 또는 통제된 비교(controlled comparison)를 보고해야 했습니다. 데모 설명글, 제휴 보도 자료, 그리고 분모가 없는 성능 주장(capability claims)은 제외되었습니다.

• 포함 기준 (Inclusion): 오리지널 벤치마크 (original benchmark), 명명된 데이터셋 (named dataset), 수치 결과, 또는 N개의 이전 벤치마크에 대한 감사 (audit); 위 기간 내에 발표된 경우.

• 제외 기준 (Exclusion): 벤더 마케팅 페이지, 단일 일화성 스레드, 재현되지 않은 단일 작업 승리, Pass@k는 있으나 베이스라인 (baseline)이 없는 논문.

• 정규화 (Normalization): 점수는 원본 단위 그대로 유지합니다. HealthBench의 0.6272는 백분율 환산값과 함께 보고됩니다. ITBench-AA의 "프런티어 모델 (Frontier models)"는 저자들이 평가한 최상위 폐쇄형 가중치 (closed-weight) 계층을 의미합니다.

표에는 포함되지 않았으나 검토된 두 가지 추가 벤치마크는 다음과 같습니다: FastKernels (GPU 커널 생성, 현재의 벤치마크가 새로운 최적화를 발견하기보다 알려진 최적화를 복제하는 것에 보상한다고 주장함), 그리고 성공적인 목표당 에너지 (Energy per Successful Goal, 에이전트 시스템에 적합한 분모는 모델 호출 (model invocation)이 아니라 사용자 목표라고 제안함). 두 벤치마크 모두 헤드라인 수치를 어떻게 해석해야 하는지에 대한 관점을 재정립합니다.

프로덕션 작업 점수: 왜 아무것도 70%를 넘지 못하는가

실제 프로덕션 배포 시나리오에 가장 근접한 세 가지 벤치마크 — 기업 IT 운영 (ITBench-AA), 커널 사양 (OSV-Bench), 임상 추론 (HealthBench Professional) — 모두 가장 강력하게 발표된 구성에서 50%에서 63% 사이의 점수를 기록했습니다. 이러한 편차는 기초 작업들이 시사하는 것보다 좁은데, 이는 각 스위트 (suite)가 다단계 궤적 (multi-step trajectories)에서 부분 점수를 부여하는 것을 중단하기 때문입니다. 단 한 번의 도구 호출 (tool call) 실패나 환각 (hallucinated)된 중간 사양은 전체 작업을 0점으로 떨어뜨립니다.

OSV-Bench가 가장 명확한 지표를 보여줍니다. 이 벤치마크는 Hyperkernel OS에서 파생된 245개의 사양 생성 (specification-generation) 태스크를 포함하고 있으며, 가장 강력한 LLM은 55.10%의 Pass@1에 도달했습니다. 이것이 절대적인 한계치입니다. 실제 OS 배포를 위해서는 95% 이상의 Pass@1을 달성하거나 모든 출력물에 대해 인간의 검토 (human review)가 필요합니다. 이는 BODHI 논문이 도메인 지식 계층 (domain-knowledge layer)을 추가함으로써 사실상 인정하고 있는 부분이기도 합니다.

HealthBench Professional 또한 동일한 양상을 보입니다. 7개 노드의 특화된 라우팅 파이프라인인 MDIA는 전체 n=525 샘플에 대해 OpenAI의 GPT 채점 방식 하에서 0.6272에 도달했습니다. 프롬프트 (prompt)보다 아키텍처 (architecture)가 더 중요하지만, 아키텍처를 적용하더라도 한계치는 3분의 2 미만에 머물러 있습니다.

코딩 에이전트: 기준치를 통과하는 유일한 카테고리

코딩 에이전트 (Coding agents)는 예외적인 사례입니다. Codex CLI의 Goal 모드는 무인 다시간 태스크 제품군인 Terminal-Bench 2.0에서 82.7%를 기록했습니다. CLEVER에서 Claude Code의 에이전트 증명 프레임워크 (agentic proving framework)는 동형 검사 (isomorphism checks) 하에서 98.8%의 유효한 사양과 81.3%의 승인율을 기록했는데, 이는 말뭉치 (corpus) 내에서 가장 높은 절대 수치입니다. 같은 주에 진행된 독립 테스트에서는 13개의 LLM에 동일한 실제 코드베이스 (excalidraw)를 제공하고 각각 사양 트리 (specification tree)를 요청했는데, 그중 6개가 노트북에서 실행되었습니다. 이는 로컬 모델 (local-model) 측면의 격차가 좁혀지고 있음을 시사합니다.

왜 코딩은 다른 모든 에이전트 카테고리보다 뛰어난 성능을 보일까요? 보고서 전반에서 세 가지 이유가 나타납니다. 첫째, 코드는 컴파일러 (compiler)가 있어 보상 신호 (reward signal)가 의료나 기업 IT에서 사용되는 인간 채점 점수보다 더 날카롭습니다. 둘째, 태스크 영역이 성숙해 있습니다. Terminal-Bench는 버전 2.0에 도달했고, CLEVER는 Lean 4 툴링 (tooling)을 기반으로 구축되어 벤더들이 튜닝할 수 있는 사이클을 충분히 가졌습니다. 셋째, 사용자가 기술적이기 때문에 궤도가 회복되는 동안 부분적인 성공만으로도 여전히 가치를 제공할 수 있습니다. 코딩 카테고리 내부를 살펴보면, 이번 달에 발표한 8가지 터미널 CLI 생태계 종합 보고서는 무인 모드 (unattended-mode)의 승리가 감독형 페어 프로그래밍 (supervised pair-programming) 처리량으로 깔끔하게 전환되지는 않는다는 점을 보여줍니다.

헤드라인 수치가 거짓말을 할 때

Terminal-Bench 2.0에서 기록된 82.7%라는 수치는 이번 분기 어디에서나 인용될 것입니다. 이 수치는 실제 데이터이지만, 읽히는 것보다 범위가 더 좁습니다. Codex CLI의 Goal 모드는 일반적인 개발자 일과(developer-day workload)가 아니라, 수 시간 동안 지속되는 터미널 작업에 맞춰 조정된 무인 실행 구성 (unattended-runtime configuration)입니다. 동일한 에이전트라도 감독형 페어 프로그래밍 (supervised pair-programming) 모드에서는 무인 자율성 (unattended autonomy)을 포기하는 대신 더 긴밀한 감독과 다른 점수 프로필 (score profile)을 갖게 됩니다. 설상가상으로, 같은 주에 발표된 ArXiv 논문인 「생산 환경 LLM 추론 벤치마크에서의 체계적 측정 편향 식별 및 완화 (Identifying and Mitigating Systemic Measurement Bias in Production LLM Inference Benchmarks)」는 단일 프로세스 및 asyncio 기반 벤치마킹 유틸리티가 클라이언트 측 대기열 병목 현상 (client-side queuing bottlenecks)을 유발하여, 부하 상황에서 보고된 처리량 (throughput)과 지연 시간 (latency) 수치를 부풀린다는 점을 입증합니다. Positional Failures 감사 (audit)는 추론 (reasoning)에 대해서도 유사한 논거를 제시합니다. 11개의 롱 컨텍스트 (long-context) 벤치마크 중 작업 위치 (task position), 채우기 콘텐츠 (filler content), 컨텍스트 길이 (context length)를 공동으로 제어하는 벤치마크는 0개였으며, 이는 인용된 롱 컨텍스트 점수가 모델의 실제 도달 범위 (reach)를 일상적으로 과장하고 있음을 의미합니다.

빌더 프로필별 판결

• 사이드 프로젝트를 출시하는 1인 개발자 (Solo dev shipping side projects): 코딩 에이전트를 선택하세요. 무인 터미널 작업에는 Codex CLI (Terminal-Bench 2.0에서 82.7%)를, 검증 가능성 (verifiability)이 중요하다면 Claude Code (CLEVER에서 98.8%)를 추천합니다. 코딩 이외의 분야에서는 헤드라인 수치를 신뢰하지 마세요. 작업을 본격적으로 시작하기 전에 직접 20개의 태스크로 스팟 체크 (spot check)를 수행하십시오.

• 예산 압박이 있는 5~20인 규모의 팀: 에이전트 운영 (agentic-ops) 관련 주장은 본인의 작업 분포에 대한 Pass@k를 확인하기 전까지는 마케팅으로 간주하십시오. 기업용 IT 분야에서 ITBench-AA가 보여준 50% 미만의 상한선이 벤더의 데모가 아닌 현실적인 사전 확률 (prior)입니다. 계정 기반 계약을 체결하기 전에 5월 엔지니어링 블로그에서 분류된 9가지 프로덕션 실패 모드 (nine production failure modes catalogued from May engineering blogs)를 함께 검토하십시오.

• 비용에 민감한 배치 워크로드 (batch workload): '성공적인 목표당 에너지 (Energy per Successful Goal)' 논문은 호출 수준의 가격 책정 (invocation-level pricing)이 에이전트 비용을 잘못 나타낸다고 주장합니다. 하나의 목표를 달성하기 위해 6번의 재시도 (retries)가 발생했다면, 이는 사용자 입장에서는 하나의 결과물이지만 비용 청구 측면에서는 6번의 완료 (completions)가 됩니다. 워크로드의 가격을 목표 달성 수치 (goal denominator) 기준으로 산정하십시오.

• 지연 시간 (latency)에 민감한 사용자 대상 앱: 롱 컨텍스트 추론 (Long-context reasoning)은 현재 평가 방식에서 가장 취약한 연결 고리입니다. 벤치마크가 태스크의 위치를 제어할 수 있게 될 때까지, 모델이 검증 컨텍스트 창 (validation context window)을 벗어난 임의의 깊이에서 중요한 정보를 놓친다고 가정하십시오.

검토된 출처 (Sources reviewed)

검토된 출처 (Sources reviewed)

• ITBench-AA: Frontier Models Score Below 50% on the First Benchmark for Agentic Enterprise IT Tasks — IBM + Artificial Analysis가 Hugging Face에 기고하며, 에이전트 기반(agentic) IT 작업에서 50% 미만의 상한선을 제시했습니다.
• BODHI: Precise OS Kernel Specification Inference — ArXiv가 기고하며, OSV-Bench의 245개 작업에 대한 Pass@1 상한선으로 55.10%를 제시했습니다.
• MDIA: A Multi-Agent Diagnostic Intelligence Pipeline on HealthBench Professional — ArXiv가 기고하며, n=525에서 0.6272 점수를 제시했습니다.
• Agentic Coding in 2026: Claude Code vs Codex CLI vs Gemini CLI vs Cursor Agent — Owen Fox가 Dev.to에 기고하며, Terminal-Bench 2.0에서 Codex CLI의 82.7%를 제시했습니다.
• Agentic Proving for Program Verification — ArXiv가 기고하며, CLEVER에서 Claude Code의 98.8% / 81.3%를 제시했습니다.
• Positional Failures in Long-Context LLMs: A Blind Spot in Reasoning Benchmarks — ArXiv가 기고하며, 장문맥(long-context) 평가에 대한 11개 벤치마크 감사를 제시했습니다.
• I Gave 13 LLMs the Same Codebase and Asked for a Specification. Six Ran on My Laptop. — Dev.to에서 13개 LLM에 동일한 코드베이스를 제공하고 사양을 요청하는 다중 모델 비교를 제시했습니다.
• One Policy, Infinite NPCs: Persona-Traceable Shared RL Policies — ArXiv가 기고하며, 300개 페르소나 라이프 시뮬레이션 벤치마크에서 기대치 대비 17배 이상, 22배 빠른 수치를 제시했습니다.

• Identifying and Mitigating Systemic Measurement Bias in Production LLM Inference Benchmarks — ArXiv, 5월 26일 기고, asyncio 벤치마킹 유틸리티에 대한 측정 편향 (measurement-bias) 논거를 제시했습니다.

• Energy per Successful Goal: Goal-Level Energy Accounting for Agentic AI Systems — ArXiv, 5월 25일 기고, 목표 수준의 비용 분모 (goal-level cost denominator)를 제시했습니다.

FAQ

여기서 이 벤치마크들을 직접 수행한 사람이 있나요?

아니요. 이 포스트는 2026년 5월 22일부터 5월 27일 사이에 발표된 10개의 보고서를 집계한 것입니다. TL;DR 표의 각 행은 원본 출처를 인용합니다. 이 종합(synthesis) 자체가 기여이며, 이 포스트의 어떠한 주장도 비공개 벤치마크나 재실행 결과에서 나온 것이 아닙니다.

하나의 결정적인 벤치마크를 실행하는 대신 왜 집계하나요?

단일 벤치마크는 거짓을 말합니다. 같은 주에 발표된 Positional Failures 감사와 Production LLM Measurement Bias 논문은 이를 명시적으로 입증합니다. 벤치마크 유틸리티, 위치 제어 (position controls), 작업 프레이밍 (task framing)은 각각 순위를 뒤집을 수 있을 만큼 큰 오류를 유발합니다. 10개의 독립적인 보고서를 집계하면 중앙값의 동작과 편차를 드러낼 수 있으며, 이는 단 한 번의 영웅적인 실행보다 의사 결정에 더 유용합니다.

이 수치들은 얼마나 최신인가요?

10개의 소스 모두 2026년 5월 22일에서 5월 27일 사이에 발표되었습니다. 인용된 도구 버전은 Terminal-Bench 2.0, Lean 4 (CLEVER), OSV-Bench (Hyperkernel), HealthBench Professional입니다. 코딩 에이전트 (coding-agent) 선두주자들은 90일 이내에 3~8%포인트 변동할 것으로 예상됩니다. 에이전틱-옵스 (agentic-ops)의 상한선은 데이터셋과 채점 작업이 더 까다롭기 때문에 더 느리게 움직일 것입니다.

이번 발췌본에서 누락된 것은 무엇인가요?

달러 단위의 작업당 비용 (Cost-per-task) 수치입니다. 2026년 5월 코퍼스(corpus)는 작업 횟수 분모와 에너지 분모를 보고하지만, 성공한 목표당 깨끗한 달러 수치를 제시하는 경우는 드뭅니다. 이 간극을 집계하는 것이 이 시리즈의 다음 포스트입니다.

이 기사는 원래 NextFuture에 게시되었습니다. 더 많은 풀스택 (Fullstack) 및 AI 엔지니어링 (AI engineering) 콘텐츠를 보시려면 저희를 팔로우하세요.