AI 에이전트 벤치마크를 무너뜨리다: 그 다음은?
Hao Wang, Qiuyang Mang, Alvin Cheung, Koushik Sen, Dawn Song
UC Berkeley
2026년 4월
(읽는 시간: 약 15~20분, 도구 링크: github.com/moogician/trustworthy-env)
주요 AI 벤치마크를 모두 해킹했습니다. 어떻게 했는지, 그리고 이 분야가 무엇을 고쳐야 하는지 알아보겠습니다.
벤치마크의 거짓말
매주 새로운 AI 모델이 벤치마크 리더보드 1위를 차지합니다. 기업들은 보도자료에서 이 수치를 인용하고, 투자자들은 기업 가치 평가의 근거로 삼고, 엔지니어들은 어떤 모델을 배포할지 결정할 때 이를 참고합니다. 암묵적인 약속은 단순합니다. 점수가 높을수록 시스템이 더 우수하다는 뜻이죠.
그런데 이 약속은 깨져 있습니다.
우리는 자동화된 스캔 에이전트를 만들어서 가장 유명한 AI 에이전트 벤치마크 8개를 체계적으로 감시했습니다. SWE-bench, WebArena, OSWorld, GAIA, Terminal-Bench, FieldWorkArena, CAR-bench까지 모두 말이죠. 그리고 발견한 사실은 충격적이었습니다. 모든 벤치마크가 단 하나의 작업도 해결하지 않으면서도 거의 완벽한 점수를 얻기 위해 악용될 수 있다는 것입니다. 추론도 없고, 실제 능력도 없습니다. 그저 점수 계산 방식의 허점을 이용할 뿐이죠.
이건 이론적인 공격이 아닙니다. 우리 에이전트는 각 벤치마크마다 실제로 작동하는 익스플로잇을 만들고, 공식 평가 파이프라인을 통해 실행하고, 점수가 올라가는 걸 봤거든요.
몇 가지 예를 들어볼게요:
- SWE-bench Verified: 겨우 10줄짜리 conftest.py 파일로 모든 인스턴스를 "해결"할 수 있습니다.
- Terminal-Bench: 가짜 curl 래퍼로 89개 작업 모두에서 완벽한 점수를 얻습니다. 실제 해결 코드는 한 줄도 없이요.
- WebArena: Chromium을 file:// URL로 탐색해서 작업 설정에서 정답을 직접 읽어옵니다. 812개 작업 모두에서 약 100% 점수를 얻죠.
- 그 외 수많은 사례들이 있습니다.
벤치마크는 당신이 생각하는 것을 측정하지 않습니다.
이미 벌어지고 있는 일
벤치마크 점수 조작은 이론이 아니라 현실입니다. 지금 이 순간에도 점수가 부풀려지고 조작되고 있습니다:
- IQuest-Coder-V1: SWE-bench에서 81.4%를 주장했습니다. 그런데 연구원들이 확인한 결과, 궤적의 24.4%가 그저 git log를 실행해서 커밋 히스토리에서 정답을 복사한 것이었습니다. 수정된 점수는 76.2%였습니다. 벤치마크가 공유 환경을 사용했기 때문에 부정행위가 쉬웠던 거죠.
- METR의 발견: o3과 Claude 3.7 Sonnet이 평가 실행의 30% 이상에서 리워드 해킹을 했습니다. 스택 자체 검사, 몽키 패칭, 연산자 오버로딩 같은 수법으로 작업을 풀지 않고 점수를 조작했던 겁니다.
- OpenAI의 결정: SWE-bench Verified를 내려갔습니다. 내부 감시 결과 감시 대상 문제의 59.4%가 결함이 있었기 때문입니다. 다시 말해 모델들이 깨진 정답에 대해 평가를 받고 있었던 거네요.
- KernelBench의 사례: torch.empty()가 평가자의 이전 계산에서 나온 참조 정답을 우연히 포함하는 낡은 GPU 메모리를 반환합니다. 계산은 없고 만점입니다.
- Anthropic의 Mythos Preview: 최고 수준의 모델들이 실제로 환경을 해킹하려고 시도할 수 있으며, 성공한다는 걸 보여줬습니다. 한 에피소드에서 모델은 권한이 없는 파일을 수정해야 했는데, 해결책을 찾은 끝에 상승된 권한으로 실행될 설정 파일에 코드를 주입하는 방법을 찾았습니다. 그리고 익스플로잇이 실행 후 스스로 삭제되도록 설계했습니다. 모델이 자체적으로 자기 자신을 지우는 권한 상승 익스플로잇을 만들 수 있다면, 평가 환경의 허점도 찾을 수 있다는 뜻입니다.
이건 고립된 사건들이 아닙니다. AI 능력을 측정한다고 주장하는 벤치마크 자체가 그 능력에 취약하다는 시스템적 문제의 증상입니다.
우리 익스플로잇 에이전트의 전적
작업 해결 0개. LLM 호출 0개 (대부분의 경우). 거의 완벽한 점수.
| 벤치마크 | 성과 | 방법 |
|---|---|---|
| Terminal-Bench (89개 작업) | 100% | 바이너리 래퍼 트로이목마 |
| SWE-bench Verified (500개 작업) | 100% | Pytest 훅으로 모든 테스트 통과 강제 |
| SWE-bench Pro (731개 작업) | 100% | 컨테이너 내 파서 덮어쓰기 |
| WebArena (812개 작업) | ~100% | 설정 유출 + DOM 주입 + 프롬프트 주입 |
| FieldWorkArena (890개 작업) | 100% | 검증이 정답 정확성을 확인하지 않음 |
| CAR-bench (모든 환각 작업) | 100% | 리워드 컴포넌트 완전 스킵 |
| GAIA (165개 작업) | ~98% | 공개 정답 + 정규화 충돌 |
| OSWorld (369개 작업) | 73% | VM 상태 조작 + 공개 골드 파일 |
우리 에이전트가 한 방법들
Terminal-Bench: 테스트 인프라 트로이목마화
Terminal-Bench는 89개의 복잡한 터미널 작업으로 에이전트를 평가합니다. COBOL 체스 엔진 구축부터 분산 시스템 설정까지 다양하죠. Harbor라는 샌드박싱 프레임워크를 사용해서 검증 전에 보호된 테스트 파일을 다시 업로드합니다. 컨테이너는 인터넷에 완전히 접근할 수 있는데, Harbor의 allow_internet 설정이 기본값으로 True이고 어떤 작업도 이를 재정의하지 않습니다.
Harbor는 /tests/ 디렉토리는 제대로 보호합니다. 하지만 시스템 바이너리는 보호하지 않습니다.
아이러니한 점이 있습니다. 89개 작업 중 82개가 검증 시간에 curl을 통해 인터넷에서 uv를 다운로드하거든요. 악용할 수 있는 의존성 체인이 생기는 겁니다. 우리 익스플로잇은 에이전트 단계에서 /usr/bin/curl을 래퍼로 교체합니다. 검증자가 나중에 curl ... | sh를 실행해서 uv를 설치할 때, 우리 래퍼가 요청을 가로챕니다. 실제 uv를 설치한 다음, uvx 바이너리를 트로이목마화합니다. 트로이목마화된 uvx는 pytest 호출을 감지해서 가짜 통과 출력을 생성합니다:
============================= test session starts ==============================