기술 요약: SWE-Bench ProMax

문제 정의

AI 코딩 에이전트가 발전함에 따라 기존의 소프트웨어 엔지니어링 벤치마크가 빠르게 포화 상태에 도달하고 있으며, 이는 상승하는 점수가 실제 능력의 개선을 반영하는 것인지 아니면 단순히 현재 벤치마크 설계의 한계를 반영하는 것인지에 대한 우려를 낳고 있습니다. SWE-bench Verified에 대한 최근 감사 결과, 해결되지 않은 인스턴스의 거의 60%가 결함이 있는 테스트 스위트(정답 코드를 거부하는 지나치게 좁은 범위이거나, 명시되지 않은 요구사항을 체크하는 지나치게 넓은 범위)를 포함하고 있었으며, 프런티어 모델들이 학습 데이터로부터 골드 패치(gold patch)를 재현할 수 있다는 사실이 밝혀졌습니다. 또한, 현재의 벤치마크는 주로 고립된 버그 수정이나 기능 구현에 초점을 맞추고 있으며, 대개 단일 파일 수정만을 포함합니다. 이는 전문적인 개발 과정에서 필수적인 장기적 과제인 **코드 리팩토링(code refactoring)**의 복잡성, 즉 여러 파일에 걸쳐 조율된 행동 보존적 변경 사항을 요구하는 능력을 포착하지 못합니다. 기존의 리팩토링 벤치마크는 규모가 제한적이거나, 단일 프로그래밍 언어에 국한되어 있거나, 테스트 품질에 대한 엄격한 인간 검증이 부족합니다.

방법론

저자들은 다음과 같은 엄격한 3단계 구축 파이프라인을 통해 이러한 격차를 해소하기 위해 설계된 전문가 큐레이션 기반 다국어 벤치마크인 SWE-Bench ProMax를 소개합니다.

1. 데이터 수집: 저자들은 특정 기준(별 개수 500개 이상, 승인된 오픈 소스 라이선스, 주요 언어가 Python, Java, TypeScript, Go, C, C++, 또는 Rust인 경우)을 충족하는 후보 저장소를 GitHub에서 식별했습니다. 이들은 "버그 수정"을 제외하고 "리팩토링(refactor)"이라는 키-워드를 포함하며 테스트 파일과 비테스트 파일을 모두 수정한 2025년 1월 이후의 커밋을 추출했습니다. 이를 통해 초기 후보군 29,782개를 확보했습니다.
2. 환경 구축: 각 후보에 대해, 모든 종속성이 설치된 리팩토링 전 상태의 저장소를 포함하는 격리된 Docker 환경을 구축했습니다. 골드 패치(소스 및 테스트 변경 사항)를 적용하고 테스트 스위트를 실행했습니다. 환경 빌드에 실패하거나 골드 패치가 모든 테스트를 통과하지 못하는 인스턴스는 폐기되었습니다.
3. 필터링 및 문제 재작성: 이 단계에서는 품질 보장을 위해 LLM의 도움을 받는 인간 전문가가 참여했습니다.
   • 커밋 분석: 전문가들이 범위와 의도를 이해하기 위해 디프(diff)를 분석했습니다.
   • 품질 필터링: 복잡성이 불충분한 작업(예: 단일 파일 변경, 사소한 라인 수)을 제거했습니다. 결정적으로, 지나치게 좁은 테스트(특정 구현 세부 사항 강제)와 지나치게 넓은 테스트(작업 범위를 벗어난 동작 체크)를 제거하기 위해 테스트 스위트를 수동으로 검토했습니다.
   • 문제 정의 재작성: 원래의 커밋 메시지는 정밀하고 모호하지 않은 사양을 제공하도록 처음부터 다시 작성되었습니다. 각 설명은 골드 패치를 위한 필요충분조건인지 검증되었습니다.
   • 인간 검증: 최종 검토를 통해 이슈 설명, 테스트 스위트, 그리고 골드 패치 간의 일치 여부를 확인했습니다.

최종 벤치마크는 7개의 프로그래밍 언어에 걸친 70개의 서로 다른 저장소에서 추출된 170개의 인스턴스로 구성됩니다.

핵심 기여

1. 고품질, 전문가 큐레이션 벤치마크: 자동화된 벤치마크와 달리, SWE-Bench ProMax는 다단계 전문가 큐레이션을 거칩니다. 이슈 설명은 정밀한 사양으로 재작성되었으며, 이전 벤치마크의 문제를 일으켰던 결함들을 제거하기 위해 테스트 스위트가 수동으로 검증되었습니다.
2. 전례 없는 규모와 복잡성: 이 벤치마크는 대규모 리팩토링을 목표로 하며, 인스턴스당 평균 11.4개의 수정된 파일과 261.6 라인의 코드를 포함합니다. 이는 기존 벤치마크(예: SWE-bench Verified 인스턴스의 86%는 단일 파일만 수정함)를 크게 상회하는 수준입니다.
3. 다국어 커버리지: 데이터셋은 7개의 다양한 언어(Python, Java, TypeScript, Go, C, C++, Rust)를 아우르며, 이를 통해 언어별 패러다임(예: Rust의 소유권 모델, C의 수동 메모리 관리)이 에이전트 성능에 미치는 영향을 분석할 수 있습니다.
4. 엄격한 평가 프로토콜: 벤치마크는 에이전트의 수정 사항이 중간 단계나 특정 명령에 의존하지 않고 테스트 스위트의 모든 테스트를 통과해야만 인스턴스가 해결된 것으로 간주하는 결과 중심 평가를 사용합니다.

결과 및 분석

저자들은 두 가지 에이전트 스캐폴드(mini-swe-agent 및 OpenHands) 하에서 6개의 프런티어 모델(독점 모델 3개, 오픈 웨이트 모델 3개)을 평가했습니다.

• 포화되지 않은 도전 과제: 가장 성능이 좋은 모델인 GPT-5.2는 SWE-Bench ProMax에서 41.2%의 해결률을 달ato 달성했습니다. 이는 SWE-bench Verified에서 보여준 75% 이상의 해결률보다 현저히 낮은 수치로, 대규모 다중 파일 리팩토링이 여전히 중요한 미해결 과제로 남아 있음을 확인시켜 줍니다.
• 오픈 웨로 모델의 비용 효율성: 오픈 웨이트 모델은 훨씬 적은 비용으로 독점 모델과 경쟁할 수 있는 능력을 보여주었습니다. 예를 들어, GLM-5는 인스턴스당 $0.24의 비용으로 36.5%의 해결률을 달성한 반면, Claude Sonnet 4.6은 $4.77의 비용으로 38.8%를 기록했습니다.
• 언어별 편차: 모든 언어에서 압도적인 성능을 보이는 단일 모델은 없었습니다. 성능은 언어별로 크게 달랐으며(예: Claude Sonnet 4.6은 Rust와 TypeScript에서 뛰어난 성과를 보였고, GPT-5.2는 Python과 C에서 가장 좋은 성능을 보임), 이는 모델의 강점이 특정 언어의 학습 데이터 및 아키텍처와 연결되어 있음을 시사합니다.
• 실패 모드 분석: 궤적 분석 결과 두 가지 주요 실패 패턴이 드러났습니다.
  1. 불완전한 리팩토링: 에이전트들이 골드 패치에 필요한 파일보다 일관되게 적은 수의 파일을 수정했습니다. 이들은 핵심 파일들은 자주 식별했으나, 주변 호출 지점(call sites), 문서, 설정 파일까지 변경 사항을 전파하는 데 실패하여 다운스트림 의존성 불일치로 인한 테스트 실패를 초래했습니다.
  2. 비생산적인 탐색: 실패한 시도는 성공한 시도보다 훨씬 더 많은 상호작용 횟수를 소비했으며, 종종 수정 범위를 확장하지 못한 채 반복적인 편집-되돌리기(edit-revert) 순환에 빠졌습니다.

의의

본 논문은 SWE-Bench ProMax가 현실적이고 대규모인 소프트웨어 엔지니어링 작업에 대해 AI 코딩 에이전트를 평가할 수 있는 유의미하고 포화되지 않은 벤치마크를 제공한다고 주장합니다. 이전 벤치마크의 품질 결함(결함 있는 테스트, 모호한 설명)을 해결하고 복잡성을 실제 생산 수준의 리팩토링에 맞춰 확장함으로써, 여러 파일에 걸쳐 일관된 계획을 유지하는 에이전트의 능력을 더욱 엄격하게 테스트합니다. 결과에 따르면 프런티어 모델들이 발전하고 있음에도 불구하고, 지속적인 교차 파일 조정(cross-file coordination) 능력은 여전히 근본적인 병목 구간으로 남아 있습니다. 또한, 본 벤치마크는 오픈 웨이트 모델이 프런티어 모델의 성능에 근접하면서도 훨씬 낮은 비용으로 수행될 수 있음을 강조하며, 높은 API 비용이 반드시 복잡한 리팩토링 시나리오에서 비례적인 결과 향상을 보장한다는 가설에 의문을 제기합니다.