SWE-Bench ProMax: Benchmarking Agents on Large-Scale Multilingual Code Refactoring 요약 설명

요약
Benchmark motivation and design goals
3 SWE-Bench ProMax
- 3.1 Task formulation
- 3.2 Dataset construction and curation
4 Experiments
- 4.1 Experimental setup
5 Results and analysis
부록
짧은 생각

이번 글에서는 SWE-Bench ProMax: Benchmarking Agents on Large-Scale Multilingual Code Refactoring 논문의 핵심 포인트만 간단히 정리한다.

2026년 8월 10일(Arxiv), COLM 2026
Shi, Yuling, Xu, Jinghan, Fu, Kelin, Zeng, Wenhao, He, Shilin, Zhang, Lei, Liu, Yue, Zhao, Zelin, Zhuo, Terry Yue, Cao, Jialun, et al.
Shanghai Jiao Tong University, Peking University, The Hong Kong University of Science and Technology, Douyin Group, University of Chinese Academy of Sciences, National University of Singapore, Monash University
논문 링크
Project Page

요약

SWE-Bench ProMax는 대규모 다국어 코드 리팩터링에서 AI coding agent를 평가하기 위한 전문가 큐레이션 benchmark다. 실제 GitHub commit에서 추출한 170개 instance는 Python, Java, TypeScript, Go, C, C++, Rust의 7개 언어와 70개 repository를 포괄하며, 외부 동작을 보존하면서 여러 파일의 구조를 함께 변경하도록 요구한다.
저자들은 기존 SWE-bench 계열이 포화되는 한편, 해결하지 못한 SWE-bench Verified instance의 약 60%에서 overly narrow test 또는 overly broad test가 보고됐고 공개 repository 기반 gold patch의 데이터 오염 가능성도 있다고 지적한다. 이에 문제 설명을 처음부터 다시 작성하고 test suite를 수동 검토해 명세, gold patch, 평가 조건을 정렬하는 방식을 제안한다.
두 agent scaffold에서 여섯 frontier model을 평가한 Table 3의 최고 overall resolve rate는 OpenHands의 GPT-5.2가 기록한 41.2%다. 저자들은 이 결과를 benchmark가 아직 포화되지 않았다는 근거로 제시하며, 실패한 agent가 gold patch보다 적은 파일을 수정하고 더 많은 interaction round를 쓰는 경향을 cross-file coordination의 병목으로 해석한다.

Benchmark motivation and design goals

이 benchmark는 단일 함수 생성이나 소규모 bug fix 대신, 변경을 여러 파일에 전파하고 행동 불변성을 보존해야 하는 repository-level 리팩터링을 평가 대상으로 삼는다. Figure 1에서 SWE-Bench ProMax는 10개 초과 파일을 수정하는 instance가 30%, 200 LOC 초과 변경 instance가 32%인 반면, SWE-bench Verified에서는 단일 파일 수정 instance가 86%, 20 LOC 이하 변경 instance가 93%다.

기존 리팩터링 benchmark도 한계가 있다. RefactorBench는 9개 Python repository의 수작업 task 100개로 평균 수정 파일 수가 4.3개이며, SWE-Refactor는 Java 18개 repository의 1,099개 instance를 제공하지만 test 품질을 인간이 검증하지 않았다. 저자들은 다국어 범위, 대규모 변경, 실행 기반 검증, 전문가 검토를 함께 충족하는 평가가 필요하다고 주장한다.

기존 benchmark와 SWE-Bench ProMax의 평가 특성 비교

3 SWE-Bench ProMax

SWE-Bench ProMax의 instance는 리팩터링 직전 commit의 repository와 의존성을 담은 Docker environment, 정밀한 자연어 issue description, 정답을 검증하는 test suite, 원 개발자의 gold patch로 구성된다. gold patch는 agent에 제공되지 않으며, agent가 environment와 문제 설명만으로 repository를 수정한 뒤 suite의 모든 test를 통과해야 resolved로 판정된다. 따라서 명령 실행 순서나 중간 추론이 아니라 최종 repository 상태를 평가한다.

데이터셋은 70개 repository에서 수집한 170개 instance로 구성된다. Table 2에서 source gold patch는 평균 11.4개 파일, 261.6 LOC, 8,179.5 tokens를 수정하고, test patch는 평균 4.5개 파일과 185.5 LOC를 더해 전체 수정 파일 수는 평균 15.9개다. 언어별 instance 수는 Python 29개, TypeScript 28개, Java 26개, Go 23개, C++와 Rust 각 22개, C 20개다.

3.1 Task formulation

Task formulation은 source와 test 변경을 포함한 실제 commit을 바탕으로 한다. pre-refactoring 상태의 repository와 설치된 의존성을 제공하므로 agent는 명세를 해석하고 영향받는 파일과 의존 관계를 스스로 찾아 수정해야 하며, 모든 test를 통과하는 결과를 만들어야 한다.

3.2 Dataset construction and curation

구축은 자동 수집, 환경 구성, 전문가 중심 필터링 및 문제 재작성의 세 단계로 진행된다. 500 stars 이상, 승인된 오픈소스 license, 목표 언어 비중 80% 이상을 만족하는 repository에서 2025년 1월 이후 제출됐고 commit message에 “refactor”를 포함하되 “bug fix”는 포함하지 않으며 test와 non-test 파일을 모두 수정한 commit을 수집한다.

각 후보의 pre-refactoring repository로 Docker environment를 만들고, source 및 test 변경을 포함한 gold patch를 적용해 전체 test suite를 실행한다. environment를 만들 수 없거나 gold patch가 test를 통과하지 못하는 후보는 폐기한다. 이후 전문가는 LLM의 diff 요약과 영향 범위 분석 보조를 받아 단일 파일, 작은 변경, 단순 패턴 task를 제외하고, 구현 세부를 강제하는 overly narrow test와 명세 밖 요구를 검사하는 overly broad test를 제거한다.

전문가는 변경할 component, 요구되는 변환, 보존할 행동 불변성을 명시하는 self-contained 문제 설명을 새로 작성한다. 이어 설명이 gold patch의 필요조건과 충분조건인지, test가 올바른 리팩터링일 때에만 통과하는지를 human verification으로 확인한다. 초기 후보 29,782개 가운데 최종 benchmark에 남은 것은 170개다.

scaffold와 모델별 SWE-Bench ProMax resolve rate, step, 비용

4 Experiments

평가는 mini-swe-agent와 OpenHands 두 scaffold에서 수행한다. mini-swe-agent는 파일 열람, 편집, 검색, bash 실행을 observe-think-act loop로 제공하고, OpenHands는 sandboxed command execution과 구조화된 파일 편집 도구를 포함하는 더 풍부한 runtime을 제공한다.

agent 수정 파일 수와 성공 여부별 interaction round 누적분포

평가 모델은 proprietary Gemini-3-Pro, Claude Sonnet 4.6, GPT-5.2와 open-weight GLM-5, Kimi-K2.5, Qwen3.5다. 이들은 benchmark를 생성하거나 정답을 검증하는 모델이 아니라, 주어진 environment와 issue description을 바탕으로 repository 수정을 수행하는 평가 대상 agent의 기반 모델이다.

4.1 Experimental setup

모든 model과 scaffold에는 instance당 최대 300 step, 최대 $10의 동일한 한도를 적용했다. 수동으로 기능을 검증한 pre-built Docker container에서 전체 170개 instance를 실행하므로, 평가 중 별도의 environment 설정은 필요하지 않다.

주 지표는 Pass@1 resolve rate로, 모든 test를 통과한 instance 비율을 overall과 언어별로 보고한다. Table 3은 model-scaffold 조합별 평균 agent step과 instance당 평균 API 비용도 함께 제시한다. 비용과 step 비교는 동일 benchmark 및 해당 scaffold 조건에서만 해석해야 한다.

5 Results and analysis

실험 결과는 대규모 다중 파일 리팩터링이 현재 agent에게 어렵고 scaffold 선택이 결과에 영향을 준다는 점을 보여 준다. Table 3에서 mini-swe-agent에서 OpenHands로 옮기면 Gemini-3-Pro를 제외한 모든 평가 모델의 overall resolve rate가 증가했으며, GPT-5.2는 21.8%에서 41.2%로 19.4%p 상승했다. 저자들은 richer runtime tooling이 대규모 리팩터링에 특히 유익할 가능성을 제시하지만, 이 비교만으로 특정 도구 하나의 효과를 분리해 단정하지는 않는다.

5.1 Main results

Table 3의 모든 model-scaffold 조합을 overall resolve rate로 대조하면 최고값은 OpenHands의 GPT-5.2가 기록한 41.2%다. 같은 OpenHands 조건에서 Claude Sonnet 4.6은 38.8%, GLM-5와 Qwen3.5는 각각 36.5%, Kimi-K2.5는 32.9%를 기록했다. 저자들은 최고 성능도 41.2%에 그친다는 점을 benchmark가 아직 포화되지 않았다는 근거로 제시한다.

OpenHands의 언어별 최고 resolve rate는 하나의 모델에 집중되지 않았다. Python과 C는 GPT-5.2가 각각 48.3%, 75.0%, Java는 GLM-5가 34.6%, TypeScript와 Rust는 Claude Sonnet 4.6이 53.6%, 63.6%, Go는 Kimi-K2.5가 43.5%, C++는 Qwen3.5가 54.5%를 기록했다. 저자들은 이러한 분산을 모델 구조와 언어별 학습 데이터 구성의 차이에서 비롯될 수 있는 상보적 강점으로 해석한다.

TypeScript와 Rust에서는 모델별 편차가 컸다. OpenHands에서 Claude Sonnet 4.6은 TypeScript 53.6%, Rust 63.6%였고 GPT-5.2의 Rust 점수는 54.5%인 반면, Gemini-3-Pro의 TypeScript 점수는 0.0%, Kimi-K2.5의 Rust 점수는 18.2%다. 저자들은 이 편차가 언어의 본질적 난도보다 언어별 학습 데이터 차이를 반영할 수 있다고 가설을 제시하며, 원인은 실험으로 확정하지 않았다.

5.2 Agent behavior analysis

Figure 5의 왼쪽 패널은 Claude Sonnet 4.6과 Kimi-K2.5가 수정한 파일 수의 누적분포를 gold patch와 비교한다. 두 agent는 약 5개 이하의 작은 변경에서는 gold patch 분포를 비교적 따른다. 그러나 gold patch가 약 20개 파일에서 누적 90%에 도달하는 반면 두 agent는 약 10개 파일에서 90%에 도달해, 큰 patch에서 필요한 범위보다 적게 수정하는 경향을 보인다.

저자들은 이 패턴을 core file을 전혀 찾지 못하는 문제라기보다, peripheral call site, 문서, configuration, test fixture까지 변환을 전파하지 못하는 incomplete refactoring으로 해석한다. 오른쪽 패널에서는 성공 instance의 interaction round 누적분포가 더 일찍 상승하고 실패 instance의 분포가 오른쪽으로 이동한다. 저자들은 반복적인 읽기, 편집, test 실패, 되돌리기가 수정 범위를 넓히지 못한 채 round를 소비하는 unproductive exploration일 수 있다고 설명한다.

5.3 Cost and efficiency analysis

OpenHands 조건에서 비용은 resolve rate에 비례하지 않았다. Claude Sonnet 4.6은 instance당 평균 $4.77와 117.9 step으로 이 조건의 가장 높은 비용을 기록했지만 resolve rate는 38.8%였고, GPT-5.2는 $3.60에서 41.2%였다. GLM-5는 $0.24에서 36.5%를 기록했으며, 이는 이 평가 조건에서 open-weight 모델이 낮은 API 비용으로 proprietary 모델에 가까운 결과를 낼 수 있음을 보여 준다.

Qwen3.5는 mini-swe-agent와 OpenHands에서 각각 평균 155.4, 141.2 step으로 Table 3의 모든 model-scaffold 조합 중 가장 많은 step을 사용했다. 그러나 overall resolve rate 최고값을 기록하지 못했고, mini-swe-agent에서는 20.6%로 해당 scaffold의 최저 resolve rate였다. 저자들은 수동 trajectory 점검을 근거로 효과적인 cross-file coordination 없는 과도한 탐색이 역효과를 낼 수 있다고 해석한다.

모든 repository는 공개 GitHub repository이며 승인된 오픈소스 license를 사용하고, dataset에는 코드, commit metadata, test case만 포함돼 개인 정보나 민감한 데이터를 수집하지 않았다고 저자들은 밝힌다. 큐레이션 단계에서 LLM은 human annotator의 지시에 따른 문제 설명 작성과 test 검토 보조 도구로 쓰였고, Appendix B의 task category와 reasoning skill 다중 라벨 분류에는 Claude Sonnet 4.6이 쓰였다. 이 분류 결과는 benchmark instance 구성이나 모델 평가 결과에는 영향을 주지 않는다.

부록

부록 A Additional dataset details는 7개 언어의 70개 repository와 license를 제시하고, A.1에서 언어별 repository 수, instance 수, 평균 수정 파일 수, LOC, 평균 non-test 파일 수를 정리한다. TypeScript의 28개 instance가 2개 repository에서 나왔고 그중 Angular가 25개를 차지하는 repository 집중도도 설명한다.
부록 B Task category analysis는 Claude Sonnet 4.6이 170개 instance를 10개 task category와 요구 reasoning skill로 다중 라벨 분류한 분석을 제시한다. Refactoring Cleanup은 113개, 66.5%이고 API Interface Change는 111개, 65.3%이며, 모든 instance가 최소 두 category를 포함하고 46.5%는 세 개 이상을 포함한다. cross-file reasoning과 API semantics는 각각 169개, 99.4%와 168개, 98.8%로 분류됐다.
부록 C Representative instances는 C++, Java, C, Rust, Go, Python, TypeScript에서 언어별 대표 instance 하나씩을 제시한다. 각 항목은 repository, 수정 파일 수와 LOC, commit URL, 축약 파일 트리, 재작성된 문제 설명의 일부로 구성되며, C++의 nasa/fprime 244개 파일, Java의 plantuml/plantuml 94개 파일 등 대규모 변경 사례를 포함한다.

짧은 생각

문제 설명을 gold patch의 필요조건과 충분조건으로 검토하고, test의 협소성과 광범위성을 함께 제거하려는 설계는 benchmark 점수의 해석 가능성을 높이려는 직접적인 대응이다. 다만 이 품질 보증은 전문가 검토 절차에 의존하므로, 독립 검토자 사이의 판정 일치도와 gold patch와 다른 동등한 구현의 통과율을 측정하면 benchmark 평가 품질을 더 명확히 판단할 수 있다.

Gorio Tech Blog