왜 중요한가
기존 코드 벤치마크가 75% 이상의 해결률에 도달한 상황에서 SWE-Bench ProMax는 평균 11.4개 파일과 261.6줄을 함께 바꾸는 실제 리팩터링 과제를 평가 대상으로 삼는다. 170개 과제에서 최고 모델 GPT-5.2도 41.2%에 그쳐, 여러 파일의 의존 관계를 유지하는 능력이 아직 충분히 측정되지 않았음을 드러낸다.
핵심 기여
전문가 검수를 거친 대규모 리팩터링 세트
29,782개 후보에서 실제 커밋 기반 과제를 수집하고 세 단계 검수로 170개 인스턴스를 남겼다. 전문가가 문제 설명을 처음부터 다시 작성하고 테스트의 과도하게 좁거나 넓은 조건을 제거했다. 그 결과 설명, 테스트, 정답 패치가 같은 리팩터링 요구를 가리키는 평가 세트를 구성했다.
7개 언어를 포괄하는 다국어 평가
Python, Java, TypeScript, Go, C, C++, Rust의 70개 저장소에서 과제를 구성했다. 동적 타입, 정적 타입, 수동 메모리 관리, ownership 기반 메모리 모델 등 서로 다른 언어 특성이 포함됐다. 모델별 언어 강점과 코드 변환 일반화 차이를 비교할 수 있는 구조다.
포화되지 않은 에이전트 평가 난도
정답 패치는 평균 11.4개 소스 파일과 261.6줄을 수정하며, 가장 큰 사례는 182개 소스 파일을 변경한다. OpenHands 환경에서 최고 성능은 GPT-5.2의 41.2% 해결률이었다. 기존 SWE-bench Verified의 75% 이상과 대비돼 장기·다중 파일 작업의 잔여 난도를 측정한다.
실패 원인과 비용 효율성 측정
에이전트의 수정 파일 수와 상호작용 라운드를 정답 패치와 비교해 실패 양상을 추적했다. 실패한 시도는 필요한 파일보다 적은 파일을 고치면서 더 많은 라운드를 소비했다. OpenHands에서 GLM-5는 $0.24로 36.5%를 기록해 $3.60의 GPT-5.2와 비용 대비 성능을 비교할 근거를 제공했다.
핵심 아이디어 이해하기
일반적인 코드 생성 평가는 함수 하나의 입력과 출력이 맞는지 확인하지만, 리팩터링은 외부 동작을 바꾸지 않으면서 저장소 전체의 구조를 바꾸는 작업이다. 한 파일의 이름이나 인터페이스를 변경하면 다른 파일의 호출부, 설정, 문서, 테스트 픽스처도 함께 영향을 받는다. 따라서 에이전트는 코드를 생성하는 능력뿐 아니라 변경 범위와 의존 관계를 끝까지 유지해야 한다.
SWE-Bench ProMax는 에이전트에 리팩터링 전 저장소가 담긴 Docker 환경과 자연어 문제 설명을 입력으로 준다. 에이전트가 파일을 검색하고 수정한 뒤 전체 테스트 스위트를 실행하며, 모든 테스트를 통과한 최종 저장소만 해결된 인스턴스로 집계한다. 특정 편집 명령의 순서가 아니라 최종 코드 상태와 행동 보존 여부를 측정하는 방식이다.
기존 벤치마크의 테스트가 지나치게 좁으면 구현 방식만 강제해 올바른 해법을 탈락시키고, 지나치게 넓으면 문제 설명에 없는 요구를 검사한다. 이 데이터셋은 전문가가 정답 패치와 테스트를 함께 읽고 문제 설명을 다시 작성한 뒤, 필요한 변경과 허용되지 않는 변경의 경계를 맞춘다. 입력인 문제 설명에서 시작해 에이전트의 저장소 수정과 테스트 실행을 거쳐 출력인 해결률로 이어지는 구조다.
실험에서는 에이전트가 핵심 파일을 찾더라도 주변 호출부까지 변경을 확장하지 못하는 경우가 반복됐다. 필요한 파일 수가 커질수록 에이전트의 수정 범위가 정답 패치보다 빠르게 작아졌고, 실패 시도는 편집과 되돌리기를 반복하며 더 많은 라운드를 사용했다. 이 결과는 대규모 리팩터링의 핵심 난제가 단순한 코드 생성보다 장기적인 파일 간 계획 유지에 있음을 뜻한다.
방법론
데이터 수집은 GitHub API에서 별 500개 이상, 승인된 오픈소스 라이선스, 대상 언어 비중 80% 이상인 저장소를 고르는 방식으로 시작한다. 2025년 1월 이후 커밋 중 메시지에 “refactor”가 있고 “bug fix”가 없으며 테스트 파일과 비테스트 파일을 모두 수정한 커밋을 추출한다. 이 절차로 Python, Java, TypeScript, Go, C, C++, Rust에 걸친 초기 후보 29,782개를 모았다.
각 후보는 리팩터링 직전 커밋을 기준으로 복제한 뒤 의존성이 설치된 격리 Docker 환경에 넣는다. 원 개발자의 소스 및 테스트 변경인 gold patch를 적용하고 전체 테스트 스위트를 실행해 환경 구성 실패나 패치 자체가 테스트를 통과하지 못하는 사례를 버린다. 이 단계의 출력은 실행 가능한 validated instance다.
마지막 단계에서 전문가는 LLM의 보조를 받아 커밋 diff와 영향을 받는 구성 요소를 파악하고, 단일 파일 작업이나 수정량이 지나치게 적은 단순 패턴을 제거한다. 테스트는 구현 세부사항만 강제하는 과도하게 좁은 검사와 설명에 없는 동작을 요구하는 과도하게 넓은 검사를 수동으로 걸러낸다. 이후 커밋 메시지를 구성 요소, 예상 변환, 보존해야 할 동작을 포함한 독립적인 문제 설명으로 다시 작성한다.
최종 검수에서는 문제 설명이 gold patch에 필요한 조건을 빠짐없이 담고 불필요한 해법을 허용하지 않는지 확인한다. 테스트는 리팩터링이 올바르게 적용될 때 통과하고, 적용되지 않았을 때 실패하도록 설명 및 패치와 정렬한다. 모델 평가는 mini-swe-agent와 OpenHands 두 스캐폴드에서 300단계와 인스턴스당 $10 제한을 동일하게 적용하고, 170개 전체 과제의 Pass@1 해결률과 비용을 기록했다.
관련 Figure
첫 단계는 GitHub API로 별 500개 이상, 승인 라이선스, 대상 언어 비중 80% 이상인 저장소에서 2025년 1월 이후 refactor 커밋을 수집한다. 두 번째 단계에서 Docker 환경을 만들고 gold patch와 전체 테스트를 실행한 뒤, 세 번째 단계에서 전문가와 LLM 보조를 활용해 과제 난도와 테스트 품질을 검수하고 문제 설명을 다시 작성한다.
SWE-Bench ProMax의 수집·환경 구축·필터링 및 문제 재작성 과정을 세 단계로 나타낸 파이프라인이다.
주요 결과
OpenHands에서 GPT-5.2가 41.2%로 가장 높은 전체 해결률을 기록했지만, SWE-bench Verified에서 보고된 75% 이상보다 낮았다. Claude Sonnet 4.6은 38.8%, GLM-5와 Qwen3.5는 각각 36.5%, Kimi-K2.5는 32.9%였다. 같은 모델을 mini-swe-agent에서 OpenHands로 바꾸면 Gemini-3-Pro를 제외한 모든 모델의 성능이 크게 올랐고, GPT-5.2는 21.8%에서 41.2%로 상승했다.
비용과 해결률은 비례하지 않았다. OpenHands에서 Claude Sonnet 4.6은 인스턴스당 $4.77과 평균 117.9단계를 사용해 38.8%를 기록한 반면, GLM-5는 $0.24로 36.5%를 달성했다. Qwen3.5는 평균 141.2단계로 가장 많은 단계를 사용했지만 36.5%에 머물렀고, 반복적인 편집·되돌리기가 수정 범위를 넓히지 못하는 비생산적 탐색으로 이어졌다.
언어별 최고 모델도 달랐다. GPT-5.2는 Python 48.3%와 C 75.0%에서 가장 높았고, Claude Sonnet 4.6은 TypeScript 53.6%와 Rust 63.6%에서 앞섰으며, GLM-5는 Java 34.6%, Kimi-K2.5는 Go 43.5%, Qwen3.5는 C++ 54.5%를 기록했다. TypeScript에서는 Gemini-3-Pro가 0.0%, Rust에서는 Kimi-K2.5가 18.2%였지만 다른 모델은 같은 언어에서 더 높은 점수를 내 언어별 학습 데이터와 모델 특성의 차이를 확인하게 했다.
행동 추적에서는 실패한 에이전트가 gold patch보다 적은 파일을 수정하는 패턴이 나타났다. 작은 변경에서는 정답 패치와 비슷한 파일 수를 고쳤지만, 대규모 변경에서는 주변 호출부, 문서, 설정, 테스트 픽스처까지 전파하지 못해 격차가 커졌다. 성공 시도는 적은 상호작용 라운드 안에 필요한 파일을 집중적으로 수정한 반면, 실패 시도는 파일을 반복해서 읽고 테스트 실패와 되돌리기를 거치며 더 많은 라운드를 소비했다.
기술 상세
각 인스턴스는 리팩터링 직전 커밋의 저장소가 담긴 Docker 환경, 정확한 자연어 issue description, 테스트 스위트, 원 개발자의 gold patch로 구성된다. 에이전트는 환경과 문제 설명만 받고 저장소를 자율적으로 수정하며, 모든 테스트를 통과해야 resolved로 집계된다. 평가가 특정 명령열이나 gold patch와의 문자열 일치가 아니라 실행 후 저장소 상태를 기준으로 한다는 점이 핵심이다.
gold patch의 소스 변경은 평균 11.4개 파일, 261.6줄, 8,179.5토큰이며 최대 182개 파일까지 확장된다. 테스트 패치는 평균 4.5개 파일과 185.5줄을 추가해 인스턴스당 전체 변경 파일 수가 평균 15.9개가 된다. 문제 설명은 평균 685.3토큰이고, 가장 큰 전체 사례는 NASA F’Prime 프레임워크의 244개 파일을 가로질러 단일 헤더에서 통합 진입점으로 이동한다.
언어 구성은 Python 29개, TypeScript 28개, Java 26개, Go 23개, C++ 22개, Rust 22개, C 20개 인스턴스다. 이 분포는 동적 타입인 Python, garbage collection을 사용하는 정적 타입 언어인 Java와 Go, 점진적 타입 언어인 TypeScript, 수동 메모리 관리 언어인 C와 C++, ownership 기반 메모리 모델을 가진 Rust를 포함한다. 따라서 동일한 리팩터링 전략이 타입 시스템, 메모리 모델, 빌드 생태계에 따라 어떻게 달라지는지 비교할 수 있다.
실험은 mini-swe-agent의 파일 조회·편집·검색·bash 실행 루프와 OpenHands의 sandboxed command execution 및 구조화된 파일 편집 도구를 비교했다. 모든 모델에 최대 300단계와 인스턴스당 $10 비용 제한을 적용하고, 여섯 모델의 170개 인스턴스 결과를 전체 및 언어별 해결률로 계산했다. OpenHands에서 GPT-5.2는 평균 115.1단계와 $3.60으로 41.2%를 기록했고, GLM-5는 평균 114.2단계와 $0.24로 36.5%를 기록했다.
관련 Figure
차트는 Python 29개, TypeScript 28개, Java 26개, Go 23개, C++ 22개, Rust 22개, C 20개 인스턴스를 보여준다. 일곱 언어가 포함돼 있어 모델의 리팩터링 성능을 언어별로 비교할 수 있으며, 특정 언어에만 편중된 평가를 피하는 구성이다.
SWE-Bench ProMax 170개 인스턴스의 프로그래밍 언어별 분포를 나타낸 원형 차트다.
한계점
논문은 SWE-Bench ProMax의 과제가 29,782개 후보에서 170개로 선별됐다는 점과 실제 GitHub 저장소 및 커밋에서 유래했다는 점을 명시한다. 또한 성능 실험은 여섯 모델과 두 에이전트 스캐폴드에 한정돼 있다.
실무 활용
SWE-Bench ProMax는 코드 수정 에이전트가 단일 파일 버그 수정이 아니라 여러 파일의 구조 변경을 끝까지 수행하는지 측정하는 평가 세트다. 사전 구성된 Docker 환경과 전체 테스트 실행을 사용하므로 모델, 에이전트 스캐폴드, 도구 조합의 실제 저장소 작업 성능을 같은 조건에서 비교할 수 있다.
- 코딩 에이전트의 저장소 수준 리팩터링 능력을 비교할 때 활용할 수 있다. 7개 언어와 평균 11.4개 소스 파일 수정 과제를 사용해 단일 파일 테스트에서 드러나지 않는 파일 간 조정 능력을 측정한다. 전체 테스트 통과를 해결 조건으로 삼아 최종 코드 상태를 수치화한다.
- 에이전트 스캐폴드와 도구 구성을 평가할 때 사용할 수 있다. 동일한 모델을 mini-swe-agent와 OpenHands에서 실행해 파일 검색, 편집, 명령 실행 런타임의 차이를 비교한다. OpenHands에서 GPT-5.2가 21.8%에서 41.2%로 오른 결과처럼 스캐폴드 변경의 효과를 해결률과 비용으로 함께 확인한다.
- 모델 운영 비용과 작업 성과의 균형을 검토할 때 사용할 수 있다. 모델별 인스턴스당 API 비용, 평균 단계 수, 언어별 해결률을 함께 기록한다. GLM-5의 $0.24와 36.5%를 Claude Sonnet 4.6의 $4.77과 38.8%와 비교해 비용 효율적인 선택지를 판단할 수 있다.
코드 공개 여부: 미확인
키워드
용어 해설
- 해결률(Resolve Rate)
- — 에이전트가 수정한 저장소가 테스트 스위트의 모든 검사를 통과한 인스턴스의 비율이다. SWE-Bench ProMax에서는 Pass@1로 계산하며, 부분적으로 동작하거나 일부 테스트만 통과한 결과는 해결로 인정하지 않는다. 벤치마크의 실제 과제 해결 능력을 측정하는 핵심 지표다.
- 코드 리팩터링(Code Refactoring)
- — 외부 동작은 유지하면서 기존 코드의 구조를 재구성하는 소프트웨어 개발 활동이다. 여러 파일의 호출부와 설정, 테스트 픽스처를 함께 수정해야 하므로 단일 함수 수정과 달리 전체 저장소의 의존 관계를 추적해야 한다. 기술 부채를 관리하고 코드베이스를 지속적으로 변경하는 데 활용된다.
- 파일 간 조정(Cross-file Coordination)
- — 하나의 구조적 변경에 영향을 받는 여러 파일을 찾아 일관된 방식으로 수정하는 능력이다. 핵심 구현 파일뿐 아니라 주변 호출부, 문서, 설정, 테스트 픽스처까지 변경 범위에 포함하고 의존 관계가 깨지지 않았는지 검증한다. 대규모 코드 변환 에이전트의 주요 병목으로 관찰됐다.
- 에이전트 스캐폴드(Agent Scaffold)
- — 언어 모델에 파일 조회, 편집, 검색, 명령 실행 같은 도구와 반복 실행 절차를 제공하는 실행 프레임워크다. 이 논문에서는 mini-swe-agent와 OpenHands가 동일한 단계 및 비용 제한 아래 모델을 구동했다. 스캐폴드가 제공하는 런타임과 편집 도구의 범위가 대규모 리팩터링 성능에 영향을 줬다.
- 데이터 오염(Data Contamination)
- — 평가 대상 코드나 정답 패치가 모델의 학습 데이터에 이미 포함돼 벤치마크 점수가 실제 일반화 능력보다 높아지는 현상이다. 공개 저장소에서 수집한 기존 벤치마크에서는 정답 패치를 그대로 재현할 가능성이 문제로 제기됐다. 따라서 새로운 평가 세트는 과제 난도와 테스트 품질뿐 아니라 학습 데이터와의 중복 가능성도 고려해야 한다.
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
