에이전트 AI - 벤치마크 - 누적되는 다중턴 코딩, EvoCode-Bench

https://arxiv.org/pdf/2605.24110v1

2026.5.22
[EvoCode-Bench: Evaluating Coding Agents in Multi-Turn Iterative Interactions]

EVOCODE-BENCH 는 코딩 AI 에이전트가 단발적인 작업 완수를 넘어, 시간에 따라 변화하는 요구사항에 맞춰 자신의 코드베이스를 지속적으로 관리할 수 있는지를 측정하기 위해 설계된 새로운 벤치마크입니다. 연구진은 13개의 주요 모델을 대상으로 5~15회차에 걸친 연속적인 상호작용을 테스트했으며, 이를 통해 에이전트가 새로운 기능을 추가하면서도 기존 기능을 파괴하지 않고 유지하는 능력을 정밀하게 평가했습니다. 실험 결과, 모델의 단일 회차 성능(SR)과 다회차 누적 성능(MT@4) 사이에는 상당한 격차가 존재했으며, 상호작용이 깊어질수록  회귀 오류와 요구사항 추적 실패로 인해 성능이 급격히 저하되는 양상이 나타났습니다. 결국 이 프로젝트는 에이전트가 복잡하고 진화하는 소프트웨어 환경에서 신뢰할 수 있는 개발 파트너가 되기 위해서는 단순한 코드 작성을 넘어 
누적된 상태 유지 및 회귀 방지 능력이 핵심적인 평가 지표가 되어야 함을 시사합니다.

 

개요 (Overview)

코딩 에이전트가 반복적인 개발 파트너로 점점 더 많이 쓰이고 있지만, 대부분의 벤치마크는 여전히 하나의 명세를 주고 하나의 최종 평가만 내리는 방식에 머물러 있다는 문제의식에서 출발한 논문입니다. 이에 저자들은 26개의 상태 유지형(stateful) 코딩 과제와 227개의 평가 라운드로 구성된 EvoCode-Bench를 제안합니다. 각 과제는 5~15 라운드 동안 에이전트의 작업공간을 유지하고, 요구사항을 관찰 가능한 행동으로 명시하며, 누적 실행 테스트를 통해 새 요구사항과 기존에 활성 상태인 요구사항을 함께 검증합니다.

13개 코딩 에이전트를 MT@4(4회 시도 기반 fail-stop 다중 라운드 점수)와 SR(참조 상태로 완성된 이전 라운드에서 시작하는 단일 라운드 점수) 두 지표로 평가한 결과, 대부분의 에이전트에서 SR이 MT@4보다 22~40점 높았습니다. 이 격차는 순위 자체를 바꾸는데, 가장 높은 SR(78.9)을 기록한 에이전트가 지속 실행 능력(MT@4 44.0)에서는 3위에 그칩니다. 최상위 에이전트조차 다중 턴 지표에서 약 50%의 성공률에 머물고, 종합 통과율은 5라운드 시점에 1라운드 성능의 절반 이하로 떨어집니다.

배경 (Background)

기존 코드 평가 연구는 크게 세 갈래로 발전해 왔습니다.

코드 생성·리페어 벤치마크: 함수 단위 생성 평가에서 시작해, 라이브러리 호출을 포함한 지시 이행 평가를 거쳐 저장소 수준 문제 해결로 발전했습니다. SWE-bench 계열은 실제 깃허브 이슈 해결을 요구하고, RepoBench는 저장소 수준 코드 완성을 평가합니다. SWE-EVO와 SlopCodeBench 등 최근 두 연구가 순차적 구조를 추가했지만, 고정되거나 단순 누적되는 명세에 의존할 뿐 대화형 사용자 상호작용이나 요구사항 수정은 다루지 않습니다.

 

자율 코딩 에이전트 평가: SWE-agent, OpenHands 등이 에이전트-컴퓨터 인터페이스를 제공하고, Terminal-Bench와 AppWorld는 실행 가능한 환경과의 상호작용을 평가합니다. 그러나 이런 설정들은 대체로 여전히 단일 과제 명세와 단일 궤적을 기준으로 성공을 정의합니다.

 

다중 턴 상호작용 평가: MT-Bench, MT-Eval 등이 대화형 상호작용을 연구해왔고, 최근 연구는 정보가 여러 턴에 걸쳐 분산될 때 성능이 급격히 저하될 수 있음을 보였습니다.

 

이런 연구들이 코드 평가를 더 현실적으로 만들었지만, 여전히 단위는 하나의 과제 명세와 하나의 최종 평가입니다. 지속적 코딩은 다른 요구를 추가하는데, 이후 턴이 에이전트 자신이 만든 산출물 위에 구축되면서 모든 활성 요구사항을 유지해야 한다는 점입니다.

방법론 (Methods)

과제 구조: EvoCode-Bench의 과제는 하나의 지속적인 도커 컨테이너 안에서 N개의 라운드가 실행되는 구조입니다. 각 라운드에서 에이전트는 지시문을 받아 작업공간을 수정하고, 검증기가 해당 라운드까지의 모든 활성 요구사항을 테스트하며, 통과해야만 다음 지시가 주어집니다.

Fail-stop 채점: 한 시도가 특정 라운드에서 처음 실패하면 이후 모든 라운드는 0점 처리됩니다. 이는 무효화된 작업공간에서 복구하는 능력과, 유효하게 진화하는 상태를 유지하는 능력이라는 서로 다른 두 역량을 뒤섞지 않기 위한 설계입니다.

2축 분류 체계: 첫 번째 축인 상호작용 스타일은 요구사항이 어디에 담기는지를 나타냅니다. 탐색적(Explorative) 과제는 상세한 초기 요청 후 짧은 후속 지시로 이어지고, 계약적(Contractual) 과제는 매 라운드마다 상세한 행동 명세(이전 행동에 대한 수정 포함)를 제공하며, 문서 기반(Document-driven) 과제는 지속적인 의미를 명세서나 AGENTS.md 같은 프로젝트 아티팩트에 담습니다. 두 번째 축인 엔지니어링 활동은 구축(Construction), 명세 진화(Spec Evolution), 리뷰 기반 개선(Review), 마이그레이션(Migration)으로 구분됩니다.

데이터 수집 파이프라인: 과제 설계 프로토콜, 과제 구성 및 내부 검토, 오라클 검증(참조 해법이 모든 라운드에서 통과하는지 확인), 교차 검증의 4단계로 구성됩니다.

평가 프로토콜: 모든 평가는 Harbor 프레임워크와 Terminus-2 에이전트 하니스를 사용하며, 다중 라운드 평가에서는 동일한 컨테이너와 에이전트 세션이 라운드 간에 유지됩니다. 핵심 지표는 MT@4(4회 독립 시도 중 최선), SR(참조 델타로 이전 라운드를 완성한 뒤 단일 시도), Comp(마지막 라운드까지 완료한 과제 비율)입니다.

실험 (Experiments)

13개 에이전트를 동일한 프로토콜 하에서 평가했으며, 각 에이전트-과제 쌍은 전용 도커 컨테이너에서 실행되고 정확성은 오직 과제 검증기 실행으로만 측정됩니다.

주요 결과 요약:

에이전트	MT@4	SR	Comp
Opus-4.7	54.0	76.7	42.3%
GPT-5.5	52.4	74.4	38.5%
Opus-4.6	44.0	78.9	34.6%
GLM-5.1	36.2	63.9	15.4%

Opus-4.7과 GPT-5.5만이 전체 다중 라운드 점수의 절반을 넘고, 그 아래 에이전트들은 모두 36.2점 이하에 머뭅니다.

 

몇 가지 핵심 발견입니다.

• 티어 간 격차 확대: 상·중·하위 티어로 나누면 MT@4 기준 최상위 대 최하위 비율은 5.9배(50.1 대 8.4)인 반면, SR 기준으로는 2.3배(76.7 대 33.1)에 불과합니다. 지속 실행 평가가 단일 라운드 평가보다 에이전트를 훨씬 뚜렷하게 구분합니다.
  
  
• 라운드 진행에 따른 급격한 저하: 라운드별 MT@4 통과율은 1라운드의 46.7%에서 3라운드 26.9%, 5라운드 21.3%, 10라운드 7.7%로 떨어집니다. 반면 SR은 3~8라운드 구간에서 52~57%로 비교적 안정적으로 유지되어, MT@4의 하락이 주로 누적된 작업공간 상태 때문임을 시사합니다.
  
  
• 시도 간 일관성 저하: 네 번의 시도가 모두 통과하는 비율(신뢰도)은 1라운드의 67%에서 5라운드의 20%로 떨어져, 다중 턴 환경이 능력 자체보다 일관성을 더 급격히 저하시킴을 보여줍니다.
  
  
• 티어별로 다른 실패 양상: 모든 티어에서 요구사항 누락이 지배적(87~90%)이지만, 중위 티어는 낡은 요구사항이 코드에 남아있는 문제(28.6%)가, 상위 티어는 후반 라운드에서 이전에 통과하던 테스트가 새 편집으로 깨지는 회귀(18.2%)가 두드러집니다.
  
  
• 문서 기반 과제의 높은 성과: 문서 기반 과제는 평균 MT@4 50.1로, 탐색적(20.9) 및 계약적(20.7) 과제 평균의 약 2.4배에 달합니다.

 

결론 (Conclusion)

EvoCode-Bench는 누적 테스트, 상태 유지형 작업공간, 라운드별 진단을 갖춘 지속적 다중 턴 코딩 벤치마크입니다. 결과는 단일 라운드 평가와 다중 턴 평가가 서로 다른 조건을 측정한다는 것을 보여줍니다. 전자는 참조 상태로 완성된 코드베이스를 확장하는 능력을 보상하는 반면, 후자는 자신의 코드베이스를 스스로 구축하고 유지하는 능력을 보상합니다. 대부분 에이전트에서 SR이 MT@4보다 22~40점 높으며, 가장 높은 단일 라운드 점수를 받은 에이전트가 지속 실행에서는 3위에 그칩니다. 50점을 넘는 MT@4를 기록한 에이전트는 단 두 개뿐입니다.

---

[보완 내용]: 5개 섹션 외에 참고할 만한 내용

요청하신 5개 항목 외에, 원문 기준으로 실무에 유용한 내용을 추가로 정리했습니다.

[보완 내용 1] 논의(Discussion) 섹션의 시사점 — 에이전트 시스템 설계자에게는 라운드 간 회귀 검사와 활성 요구사항의 저장소 기반 요약, 낡은 동작을 탐지하는 작업공간 감사가 필요하다는 점을, 모델 개발자에게는 하위 티어는 기본적인 요구사항 충족 능력을, 중위 티어는 명세 추적과 충돌 해결을, 상위 티어는 점진적 편집 중 회귀 통제 능력을 각각 강화할 필요가 있다는 점을 제안합니다.

[보완 내용 2] 평가 비용 — 전체 평가에는 3,657건의 기록된 다중 라운드 실행 기록에 걸쳐 약 244억 개의 토큰이 소요되어, 지속적 다중 턴 평가가 상당히 비용이 크다는 점을 보여줍니다.

[보완 내용 3] 한계점(Appendix A) — 벤치마크 규모(26개 과제)는 주로 수작업 지시문 작성, 누적 테스트 구성, 교차 검증, 다중 에이전트 평가의 비용에 의해 제약됩니다. 또한 fail-stop 모델은 복구 능력이 있는 에이전트를 과소평가할 수 있습니다.

[보완 내용 4] 구체적 과제 예시(Appendix C) — deterministic-data-pipeline-go라는 15라운드 계약형 구축 과제가 대표 사례로 제시되는데, Go로 작성된 결정론적 CLI 도구를 단계별로 확장하면서 체크섬 방식 변경(SHA-256→BLAKE2b→다시 변경), 해시 알고리즘 교체 등 여러 차례의 '충돌형' 요구사항 변경을 포함합니다. 이는 왜 누적 검증이 필요한지를 잘 보여주는 사례입니다.