점수부터 틀렸다
How Benchmarks Mis-Score Computer-Use Agents (7월 30일)는 실패로 판정된 공개 실행 기록 150개를 사람이 다시 검토했다.
- 실패 판정의 15.3%가 오판
- 10.7% — 평가기 오판
- 4.7% — 과제 자체의 결함
발표되는 에이전트 성능 점수가 실제 능력을 정확히 반영하지 않을 수 있다는 걸 수치로 보여준다. 단일 성공률보다 계획·검증·피드백·실행 실패를 분리해 평가해야 한다는 주장이다.
반대쪽 — 실제 업무는 훨씬 어렵다
StartupBench (8월 18일, ByteDance Seed)는 연구자가 임의로 만든 과제 대신 실제로 돈을 받고 사용되는 AI 스타트업 제품들의 업무 흐름을 조사해 벤치마크를 만들었다.
가장 강한 모델도 전체 작업을 **완전히 끝낸 비율은 약 30%**였다. 주요 실패 원인은 복잡한 지시 준수와 분야별 전문성이었다.
기존 벤치마크의 "70~90% 성공"과 실제 end-to-end 업무 "약 30% 완수" 사이의 간격.
이번 달 논문 중 에이전트 AI의 현재 수준과 거품을 판단하는 데 가장 직접적인 자료다.
비용까지 봐야 한다
EcoAgent-Bench (8월 6일 공개, arXiv 번호는 확인하지 못했다)의 문제의식은 다르다.
에이전트에게 예산을 주고 싼 검색으로 충분한지, 더 강한 모델을 부를지, 비싼 도구를 쓸지, 사람에게 넘길지를 판단하게 하는 304개 과제다. 현재 에이전트의 **예산 고려 엄격 성공률은 3.9~24.0%**에 불과했다.
실제 기업에서 중요한 건 "에이전트가 일을 할 수 있는가"가 아니라 **"5달러에 끝낼 일에 50달러를 쓰지는 않는가"**이기 때문이다.
능력과 배포 준비도는 다르다
Stop Shipping AI Agents on Faith: Capability Is Not Production Readiness (7월 30일)는
출시 준비도를 성능뿐 아니라 운영 환경, 규정 준수, 감시·감사·통제 체계까지 포함해 평가하는
ProofAgent Index를 제안했다. 벤치마크 점수와 데모만 보고 배포하는 관행을 비판한다.
모델이 아니라 조합을 평가한다
An End-to-End Agent Auditing Engine (8월 7일)은 최종 정답뿐 아니라 실행 효율, 도구 사용, 계획, 오류 복구 과정까지 표준 실행 기록으로 남겨 평가한다.
결과가 중요하다. 같은 모델이라도 어떤 하네스와 결합하느냐에 따라 성능이 크게 달라졌고, 모든 작업에서 항상 우월한 조합은 없었다.
평가 단위가 모델에서 모델 + 에이전트 구조 + 도구 + 실행 환경으로 이동하고 있다는 뜻이다.
결과가 아니라 과정을 본다
Beyond Final Scores (8월 13일)는 7개 최신 모델을 36개 장기 연구·개발 작업에서 평가하되 문제 설정 → 실행 → 피드백 제어를 따로 분석했다.
현재 에이전트는 새로운 방법을 만들어내는 연구자라기보다 기존 기법을 조합·최적화하는 엔지니어에 가까웠다. 실행 간 성능 변동도 컸고, 이전 경험이 도움이 되기도 했지만 오히려 잘못된 방향으로 이끌기도 했다.
CRATE (8월 21일)는 컴퓨터·모바일 에이전트를 평가할 때 긴 실행 영상을 통째로 심판에게 넣지 않고, 각 행동 전후에 화면에서 무엇이 바뀌었는지를 단계별로 추출해 합친다. AndroidWorld에서 F1 0.833으로 기존 방식보다 20% 높았다.
목표는 달성했지만 중간에 엉뚱한 파일을 지웠거나 개인정보를 노출했을 수 있다. 그래서 평가가 결과 평가에서 행동 결과(consequence) 평가로 옮겨가고 있다.
어려운 조건에서 보는 벤치마크들
- FM-Bench (8월 19일) — 축구 구단 20시즌 운영. 약 340~400번의 의사결정, 26개 도구. LLM 심판 대신 결정론적 시뮬레이터가 채점한다. 모델 크기·가격·토큰 사용량이 성적을 잘 예측하지 못했고, 수백 번 실패하고도 시장 가격 구조를 학습하지 못했다
- MobilePA-Bench (8월 24일) — 212개 모바일 도구를 쓰는 계획 에이전트. 도구 순서 제약, 권한 제한, 예상치 못한 오류가 들어오면 성능이 크게 떨어졌다
- UserToolBench (8월 10일) — 취향을 기억하는가가 아니라 행동 결정에 반영하는가. 정보가 부족하면 질문하는지까지 본다
- AI4AI-Bench (8월 20일) — AI를 훈련시키는 알고리즘 자체를 개선하라. 6개 시스템 평균 0.166, 최고도 0.250. 재귀적 자기개선은 "가능성은 보이지만 아직 멀다"에 가깝다
- SWE-bench Science (8월 21일) — 일반 GitHub 코드가 아니라 실제 과학 연구 코드베이스
- From Simple QA to Deep Research (8월 3일) — 단순 질문을 발전시켜 31개 주제 500개 딥리서치 과제를 자동 생성하고, 최종 답뿐 아니라 조사 과정도 평가한다
그래서 무엇을 다르게 할 것인가
1. 벤치마크 점수를 도구 선택 근거로 쓰지 않는다
그 점수가 어떤 하네스에서 나왔는지 모르면 내 환경에서 재현되지 않는다. 결국 내 업무로 직접 시켜 보는 것이 유일하게 믿을 만한 평가다.
2. 우리 회사 과제로 작은 평가 세트를 만든다
실제로 자주 하는 업무 5~10개를 고정해두고 도구가 바뀔 때마다 같은 걸 시켜 본다. 논문들이 하는 일의 축소판이고, 이게 없으면 매번 인상으로 판단하게 된다.
3. 성공/실패만 세지 않는다
몇 번 만에 됐나, 토큰을 얼마나 썼나, 중간에 무엇을 건드렸나. 같은 성공이라도 비용이 10배 차이 날 수 있다.
4. 데모와 배포는 다르다고 전제한다
시연에서 잘된다고 운영에 넣을 수 있는 게 아니다. 권한·감사·복구 체계가 갖춰졌는지가 별개 문제다.