코딩 에이전트 벤치마크의 두 가지 딜레마
현재 코딩 에이전트 평가는 두 극단 사이에 끼어 있다. SWE-bench 같은 공개 벤치마크는 문제와 정답이 웹에 공개되어 있어, 모델이 이슈 스레드를 암기했는지 진짜로 코드를 이해했는지 구분할 수 없다. 반면 CursorBench 같은 벤더 내부 벤치마크는 실제 사용 분포를 반영하지만, 외부에서 감사할 수 없다.
Tencent WorkBuddy Bench 팀은 이 두 딜레마를 동시에 해결한다: 실제 작업 분포를 반영하되, 프롬프트 오염을 구조적으로 차단하고, 전체를 공개하는 벤치마크를 만든 것이다.
4개 영역, 하나의 작업 형식
WorkBuddy Bench의 핵심 통찰은 “코딩 에이전트는 더 이상 코드만 편집하지 않는다”는 것이다. 같은 에이전트가 웹 프론트엔드를 만들고, 오피스 문서를 처리하고, 보안 취약점을 분석해야 한다. 이 네 가지 작업 유형이 하나의 공통된 형식을 공유한다: 에이전트가 워크스페이스에 진입하고, 자연어 요청을 받고, 산출물을 남기고, 에이전트가 볼 수 없는 검증기로 채점된다.
Code (80 태스크)
저장소 수준의 소프트웨어 엔지니어링을 평가한다. 실제 오픈소스 커밋과 PR에서 역공학했으며, 개발자·알고리즘 엔지니어·PM·QA·운영 5가지 요청자 페르소나로 역할극 요청을 작성했다. 버그 수정뿐 아니라 기능 구현, 리팩토링, 성능 개선, 저장소 이해 등 다양한 태스크 유형을 포함한다.
Web (70 태스크)
실행 가능한 프론트엔드 산출물을 요구한다. “잘 쓴 답변”이 아니라 선언된 경로에 runnable artifact가 있어야 한다. 페이지 구현, 데이터 시각화, 상호작용, 시각 디자인, 코드 테스트, 문서 변환까지 7개 카테고리를 아우르며, 생성(From Scratch)이 절반, 수정·확장·리뷰·테스트가 나머지 절반을 차지한다.
Office (50 태스크)
혼합 포맷 파일(스프레드시트, 문서, PDF, JSON, Markdown)이 있는 로컬 워크스페이스에서 자연어 작업 요청을 수행한다. 에이전트는 파일 간 정보를 일관되게 유지하고, 관련 상태를 업데이트하고, 검토 가능한 증거를 남겨야 한다. 최종 워크스페이스 상태를 평가하기 때문에, “그럴듯한 요약만 쓰고 실제 워크북은 업데이트하지 않는” 실패를 잡아낸다.
Security (60 태스크)
취약점 발견·안전 재현, 멀웨어 분석, 보안 운영, 에이전트 보안 평가까지 보안팀의 전 스펙트럼을 다룬다. LLM 판정자를 전혀 사용하지 않고 모든 태스크가 결정론적 스코어링 프로그램으로 채점된다. 5겹 안티 치트 인프라(금지 리터럴 스캔, 파일명 변경 테스트, 오버레이/변조 테스트, 인코딩 의존성 테스트, 저가치 미끼 필드)로 하드코딩과 무차별 대입을 차단한다.
오염 저항 설계
WorkBuddy Bench의 오염 저항은 “비밀”이 아니라 “구조”에 기반한다:
- 역공학된 프롬프트: 각 태스크는 실제 커밋·PR·CVE에서 역공학하여 “동료가 물어보는 듯한” 구어체 요청으로 재작성된다. 원본 이슈를 웹 검색해도 프롬프트를 복구할 수 없다.
- 의도적 불완전 명세: 대상 파일, 정확한 스키마, 엣지케이스 처리를 생략한다. 에이전트가 워크스페이스에서 맥락을 스스로 복구해야 한다.
- 공개 + 버전 관리: 데이터셋 전체(태스크 디렉토리, 환경 이미지, 평가 코드, 테스트, 참조 솔루션)를 공개하되, 주기적 버전 갱신으로 노출을 관리한다.
이중 하네스 평가: 같은 모델도 하네스가 바뀌면 순위가 바뀐다
WorkBuddy Bench의 가장 흥미로운 설계 결정은 CodeBuddy Code와 Claude Code 두 하네스에서 모든 모델을 동시 측정한다는 것이다. 결과는 하네스가 중립 측정 도구가 아님을 보여준다:
| 모델 | Code (cbc) | Code (cc) | Web (cbc) | Web (cc) | Office (cbc) | Office (cc) | Security (cbc) | Security (cc) |
|---|---|---|---|---|---|---|---|---|
| Claude Opus 4.8 | 74.4 | 77.9‡ | 68.1 | 69.9 | 82.4 | 80.5 | 52.6 | 56.0 |
| GPT-5.5 | 72.9 | 76.6 | 63.0 | 66.7 | 80.4 | 86.0 | 51.0 | 67.0 |
| GLM-5.2 | 71.5 | 77.1 | 60.0 | 53.3 | 76.0 | 75.0 | 76.3 | 80.9 |
| HY-3 | 62.9 | 66.3 | 67.7 | 66.4 | 75.2 | 73.2 | 49.7 | 56.0 |
| DeepSeek-V4-Flash | 57.0 | 65.1 | 41.6 | 44.6 | 68.2 | 70.4 | 49.7 | 56.0 |
| MiniMax-M3 | 49.0 | 55.0 | 44.6 | 42.0 | 64.8 | 64.0 | 61.0 | 54.0 |
| Hunyuan | 35.0 | 37.0 | 36.0 | 39.0 | 51.0 | 51.0 | 42.0 | 47.0 |
3회 독립 실행 평균, think 모드. ‡는 수정된 명령으로 실행. 강조는 각 열 최고치.
핵심 발견:
- 단일 모델이 모든 보드를 장악하지 못한다: Claude Opus 4.8이 5개 보드에서 1위, GLM-5.2가 Security 2개 보드에서 1위, GPT-5.5가 Office(cc)에서 1위.
- 하네스 감도가 영역마다 다르다: Code는 가장 균일하게 이동하고, Security는 평균 절대 이동이 8.6점으로 가장 크다. GPT-5.5는 Security에서 cbc 6위 → cc 2위로 순위가 급등한다.
- 오픈웨이트 모델의 약진: GLM-5.2가 Security 양쪽 보드에서 1위한 것은 이 스위트에서 오픈웨이트와 클로즈드 프론티어 모델의 격차가 보드에 따라 다르다는 증거다.
평가 방법론의 차별점
각 영역은 서로 다른 채점 도구를 사용하며, 영역 간 점수를 비교하지 않는다 (전체 평균을 내지 않는다):
- Code: 히든 테스트 (pytest, boolean assertion, JSON 리포트 스코어)
- Web: 룰 체크 + LLM/VLM 판정 + 에이전트 판정 (실행 중인 산출물을 직접 조작)
- Office: 결정론적 룰 체크 + 증거 기반 LLM 판정 (태스크별 가중치로 조합)
- Security: 결정론적 스코어링 (LLM 판정 없음, 5겹 안티 치트)
이 설계는 “채점 방법이 다르면 점수의 의미도 다르다”는 정직한 전제에서 출발한다.
Code 부문 상세 구성
Code 하위셋은 단순한 버그 수정이 아니다. 5가지 요청자 역할, 6개 사용 도메인, 기능 구현·리팩토링·성능 최적화·저장소 이해 등 다양한 태스크 타입을 포함한다. “데이터 & 알고리즘” 태스크가 “코딩” 태스크보다 평균 약 9점 높은 것(74% vs 65%)은, 비즈니스/데이터 의미를 파악하는 것보다 기존 저장소의 계약을 정확히 수정하는 것이 더 어렵다는 분석을 뒷받침한다.
시사점
- 하네스가 모델 능력의 일부다: 같은 모델이라도 하네스가 바뀌면 성능이 달라진다. 벤치마크는 하네스를 명시해야 하며, 단일 하네스 결과를 모델 능력의 전부로 해석하면 안 된다.
- 오염 저항은 구조로: 비밀에 의존하지 않고 태스크 구성 자체로 오염을 차단하는 접근은, 공개 벤치마크의 지속 가능성을 위한 중요한 방향이다.
- 다영역 평가가 필수다: 코드만 잘하는 에이전트, 웹만 잘하는 에이전트, 보안만 잘하는 에이전트가 각각 다르다. “코딩 에이전트”의 능력을 단일 점수로 요약하는 것은 오해를 낳는다.
- 오픈웨이트의 약진: GLM-5.2가 Security에서 클로즈드 모델들을 제친 것은, 특정 도메인에서 오픈 모델이 이미 경쟁력이 있음을 보여준다.
더 실습해보고 싶은 분들께
에이전트 하네스, 도구 사용 루프, 다영역 평가 파이프라인 등 이 글의 주제를 직접 실험해보고 싶다면 다음 두 자료를 추천한다:
- 『이게 되네? 오픈클로 미친 활용법 50제』 — 에이전트 하네스와 자동화 루프를 실제로 구성하고 활용하는 50가지 사례
- 「모두를 위한 루프 엔지니어링」 — 에이전트 루프 설계와 컨텍스트 엔지니어링의 실전 강의
참고문헌: Tencent WorkBuddy Bench Team, “Tencent WorkBuddy Bench: A Multi-Domain Coding-Agent Benchmark with Contamination-Resistant Task Construction”, arXiv:2607.20911, 2026.