EvoCode-Bench는 코딩 에이전트를 지속적인 작업 환경에서 227회의 순차 라운드에 걸쳐 검증한다. 단일 턴 점수는 실제 신뢰성을 부풀리기 쉬우며, 진짜 병목은 기능 부재가 아닌 리그레션(regression)에 있다.
대부분의 코딩 벤치마크는 구조가 똑같다. 에이전트에게 단일 작업을 주고, 작업을 수행하게 한 뒤, 결과를 확인한다. 에이전트가 수십 번의 툴 호출을 거칠 수 있지만, 사용자 입력은 하나, 최종 평가도 하나다.
하지만 실제로 에이전트를 쓰는 방식은 다르다. 무언가를 만들다 보면 새로운 아이디어가 생기고, 요구사항이 바뀌고, 리팩터링도 하게 된다. EvoCode-Bench는 바로 그 사이클을 검증하기 위해 설계됐다.
EvoCode-Bench는 26개 태스크, 227회의 순차 라운드(태스크당 5~15회)로 구성된 멀티턴 코딩 벤치마크다. ML/MLOps, 빌드 시스템, 데이터 엔지니어링, 클라우드/보안, 과학 컴퓨팅 등 다섯 가지 영역에 걸쳐 에이전트를 평가한다. 이 벤치마크를 주목할 만한 이유는 세 가지다.
Single-Turn Eval (SWE-bench):
[Prompt] → [Agent works] → [Pass/Fail] → Container discarded
Multi-Turn Eval (EvoCode-Bench):
[Prompt 1] → [Agent works] → [Test 1] →
[Prompt 2] → [Agent works] → [Test 1+2] →
[Prompt 3] → [Agent works] → [Test 1+2+3] → ...어떤 태스크(d1_w5)는 에이전트에게 Go 언어로 작성된 CLI 빌드 오케스트레이터 buildctl을 8라운드에 걸쳐 만들도록 요구한다. 처음 몇 라운드가 어떻게 진행되는지 살펴보자.
1라운드:
buildctl라는 CLI 툴을 만들어라. 의존성 해결, 병렬 실행, 콘텐츠 주소 기반 아티팩트 캐싱을 갖춘 멀티 타깃 빌드 파이프라인을 오케스트레이션해야 한다." 전체 명세에는 TOML 설정 파싱, 위상 정렬, 캐시 키 계산(커맨드 + 환경변수 + 입력 파일 해시의 SHA-256), CLI 커맨드 4종(build, graph, clean, status), JSON 리포트 형식, 사이클·누락 의존성·타임아웃에 대한 에러 처리가 포함된다.round-1/tests/test.sh(테스트 케이스 24개)를 마운트해 CLI에 실행한다. 향후 채점 기준을 에이전트가 미리 읽지 못하도록 검증 후 테스트 스크립트는 삭제된다.2라운드:
imports 필드 신규 추가(전이적 임포트 지원, 사이클 감지, 이름 충돌 에러 포함), 그리고 커맨드·입력·출력에서 ${VAR_NAME} 확장을 지원하는 [variables] 섹션이 포함된다.5라운드:
skipped가 아닌 별도 상태인 cancelled을 부여하라. 기존 동작을 복원하려면 --keep-going 플래그를 추가하라."단일 턴 점수는 실제 신뢰성을 크게 부풀린다. 연구진은 두 가지 모드를 비교했다. 하나는 매 라운드를 사람이 완성한 깨끗한 코드베이스에서 시작하는 방식(SR), 다른 하나는 에이전트가 여러 라운드에 걸쳐 자신의 작업 환경을 직접 유지하는 방식(MT@4)이다. 에이전트는 깨끗한 코드에 지시를 따르는 것은 잘한다. 하지만 자신이 이전에 작성한 코드 위에서 이어 작업할 때는 성능이 눈에 띄게 떨어진다. 하위 모델에서는 그 격차가 약 4배(MT 8.4% → SR 33.1%)에 달하고, 최상위 모델도 여전히 1.4~1.8배 차이가 난다. 멀티턴 실패의 57% 이상이, 깨끗한 상태에서는 모델이 쉽게 통과하는 라운드에서 발생한다.
압박이 가해지면 순위가 달라진다. Claude Opus 4.6은 단일 라운드 점수가 가장 높았지만(78.9%), 멀티턴에서는 Opus 4.7(54.0%)과 GPT-5.5(52.4%)에 밀려 3위(44.0%)로 내려앉는다. 전체 모델 기준으로 통과율은 1라운드 46.7%에서 5라운드 21.3%, 10라운드 7.7%로 떨어진다. 턴이 쌓일수록 누적 결정이 늘어나고, 실패도 늘어난다.
모델 등급에 따라 실패 양상이 다르다. 하위 에이전트는 초반부터 실패하는데, 요청한 것을 아예 구현하지 못하는 경우가 대부분이다(실패의 87~90%). 중위 에이전트는 초반 라운드는 잘 버티지만, 명세가 바뀌면 기존 동작을 완전히 제거하지 않은 채 새 로직을 덧붙이는 경향이 있다(실패의 28.6%, 5라운드에서 정점). 최상위 에이전트는 더 멀리 가지만 결국 이미 작동하던 것을 망가뜨린다. 리그레션이 2라운드 기준 실패의 35%를 차지한다.
리그레션이 진짜 병목이다. 에이전트가 실패하는 이유는 대부분 기능을 구현하지 못해서가 아니다. 이미 잘 작동하던 것을 망가뜨리기 때문이다. 명세가 바뀌면 에이전트는 새 요구사항을 처리하기 위해 코드를 수정하는데, 그 수정이 공통 코드 경로를 건드려 이전 동작을 의도치 않게 깨뜨린다. 기존 기능이 여전히 정상인지 재검증하는 과정이 빠지는 것이다.
구조화가 도움이 된다. 요구사항을 지속적인 문서(프로젝트 플랜이나 명세 파일 등)로 관리한 에이전트는 성공률이 두 배 이상 높았다.
데이터셋이 작다. 태스크 26개, 라운드 227회. 난이도가 높은 태스크 몇 개가 집계 점수를 왜곡할 수 있다.
전부 아니면 전무 방식의 채점. 테스트 케이스의 98%가 통과해도 리그레션 하나면 해당 라운드 전체가 0점이 된다. 논문은 케이스 단위 점수도 함께 제시하는데, 이진 실패로 채점된 라운드에서도 에이전트가 어서션 정확도 80% 이상을 달성하는 경우가 많다는 것을 보여준다.
복구 루프가 없다. fail-stop 채점(MT@4) 방식에서는 한 라운드가 실패하면 전체 시도가 종료되고, 남은 라운드는 자동으로 0점 처리된다. 에이전트가 망가진 상태에서 회복할 수 있는지는 검증하지 않는다.
상호작용이 정적이다. '사용자'는 고정된 스크립트다. 명확화 질문도, "제가 말한 게 그게 아닌데요"도, 모호성도 없다.
인프라 민감도. 논문 결과 자체도 컨테이너 스로틀링이나 kubelet 오류 같은 인프라 문제가 점수를 오염시킬 수 있음을 인정한다.
EvoCode-Bench는 에이전트가 시간이 지나도 코드베이스를 지속적으로 유지할 수 있는지를 검증한다. 테스트 스위트는 1라운드의 bash 약 900줄에서 5라운드에는 거의 4,000줄로 불어난다. 최고 수준의 모델조차 5라운드가 되면 절반 이상의 성능을 잃는다. 지배적인 실패 원인은 "기능을 만들지 못한다"가 아니라, 이미 작동하던 것을 망가뜨리는 리그레션이다. 명세가 이전 결정을 뒤집으면 최상위 모델도 고전한다. 가장 명확한 신호는 이것이다. 지속적인 요구사항 문서를 관리한 에이전트는 성공률이 두 배 이상 올랐다. 원시 성능보다 구조가 중요하다.
