SWE-rebench V2: 대규모 다국어 소프트웨어 엔지니어링 작업 수집을 위한 언어 독립적 파이프라인

기존 AI 코딩 에이전트 평가 및 학습 데이터는 주로 Python에 편중되어 있었으나, 이 논문은 20개 이상의 프로그래밍 언어를 아우르는 대규모 실행 환경을 자동 구축하는 방법을 제시한다. 이를 통해 특정 언어에 국한되지 않는 범용적인 소프트웨어 엔지니어링 에이전트 개발과 강화학습(RL)을 위한 안정적인 보상 신호 확보가 가능해진다.

기존 SWE-bench와 같은 벤치마크는 실제 GitHub 이슈를 해결하는 능력을 평가하지만, 대규모 강화학습(RL) 학습에 활용하기에는 데이터의 양이 부족하고 특정 언어(Python)에 치우쳐 있다. 특히 각 저장소마다 다른 복잡한 의존성 설치와 테스트 실행 환경을 수동으로 구축하는 것은 확장이 불가능한 병목 현상이었다.

이 논문은 '인터랙티브 셋업 에이전트'라는 개념을 도입한다. 이는 단순히 고정된 스크립트를 실행하는 것이 아니라, LLM이 터미널 피드백을 실시간으로 확인하며 설치 오류를 수정하고 테스트 명령어를 찾아내는 방식이다. 마치 개발자가 처음 보는 프로젝트를 클론하고 환경을 맞추는 과정을 자동화한 것과 유사한 원리로 동작한다.

또한, 수집된 데이터의 품질을 보장하기 위해 여러 LLM 판정단(Ensemble of LLM Judges)을 활용해 문제 설명이 충분한지, 테스트가 정답 코드와 일치하는지를 검증한다. 이를 통해 RL 학습 시 잘못된 보상(Reward Noise)이 발생하는 것을 방지하고, 20개 이상의 언어에 대해 일관된 품질의 학습 데이터를 확보할 수 있게 되었다.

전체 파이프라인은 데이터 수집, 셋업 합성, 실행 기반 검증, 이슈 명확성 필터링, 메타데이터 보강의 5단계로 구성된다. GitHub Archive에서 후보 PR을 추출한 뒤, 각 저장소의 특성에 맞는 Docker 이미지를 생성하여 격리된 실행 환경을 보장한다.

셋업 합성은 Qwen3-Coder-480B 기반의 에이전트가 수행한다. 에이전트는 [현재 디렉토리의 파일 목록과 이전 실행의 오류 로그를 입력으로] → [LLM이 해결책을 추론하여 새로운 쉘 명령어를 생성하는 연산을 수행해] → [수정된 install_config.json을 출력하고] → [이는 재현 가능한 빌드 환경을 구축하는 설정값이 된다.] 이 과정을 최대 10회 반복하며 테스트가 성공적으로 실행되는 구성을 찾아낸다.

품질 필터링 단계에서는 gpt-oss-120b, GLM-4.7, DeepSeek-V3.2로 구성된 앙상블 판정단이 이슈 텍스트를 평가한다. 세 모델 모두가 구현에 충분한 정보가 있다고 판단한 경우에만 최종 데이터셋에 포함시킨다. 또한, PR 설명을 기반으로 문제 정의를 생성하는 'PR-based Task Expansion'을 통해 데이터 규모를 12만 개 이상으로 확장했다.

인터랙티브 셋업 에이전트의 성능 분석 결과, Qwen3-Coder-480B 모델을 사용했을 때 pass@10 기준 62.7%의 설치 성공률을 기록하여 비대화형 방식(15.7%)보다 압도적으로 우수한 성능을 보였다. 이는 복잡한 다국어 환경 구축에서 피드백 루프의 중요성을 입증한다.

최종 구축된 데이터셋은 Python(21.6%), Go(20.6%), JS/TS, Rust 등 20개 언어를 포함하며, 2014년부터 2025년까지의 광범위한 기간을 커버한다. 작업의 난이도는 수정 파일 수와 라인 수 기준으로 중간 수준이 메디안(Median)이지만, 90분위수에서는 9개 파일/181개 라인을 수정해야 하는 고난도 작업도 포함되어 있다.

주요 모델들의 성능 평가 결과, Claude Opus-4.5가 전체 평균 pass@1 기준 25.0%로 가장 높은 성능을 보였으며, GLM-4.7(21.0%), MiniMax-M2.1(19.0%)이 뒤를 이었다. 언어별로는 Python에서 가장 높은 성능(36.11%)을 보였으나, Scala와 같은 언어에서는 모든 모델이 낮은 성능을 기록하여 언어별 난이도 차이가 뚜렷함을 확인했다.

SWE-rebench V2는 언어 독립성을 달성하기 위해 '단일 실행 계약(Single Executable Contract)' 구조를 채택했다. 각 작업은 Docker 컨테이너 내에서 표준화된 인터페이스를 통해 설치 및 테스트가 수행되며, 이는 이질적인 빌드 시스템(Maven, Cargo, npm 등)을 추상화한다.

진단 메타데이터(Diagnostic Metadata)는 연구자가 학습 데이터를 전략적으로 선택할 수 있게 돕는다. 예를 들어, 'B1: Test Suite Coupling' 태그는 수정과 무관한 테스트 실패 가능성을 나타내며, 이를 필터링하여 'Clean'한 데이터셋으로 초기 SFT(Supervised Fine-Tuning)를 수행하거나, 나중에 노이즈가 섞인 데이터를 추가하여 에이전트의 강건성(Robustness)을 높이는 커리큘럼 학습이 가능하다.

셋업 합성 시 에이전트는 install_config.json이라는 정형화된 출력을 생성하도록 강제된다. 여기에는 성공한 설치 명령어 목록과 전체 테스트 실행 명령어가 포함된다. 또한, 로그 파서 생성기를 통해 원시 텍스트 로그를 PASSED, FAILED, SKIPPED 상태의 구조화된 맵으로 변환하여 보상 신호의 정확도를 높였다.

현재 환경 설계는 단일 Docker 컨테이너로 패키징 가능한 프로젝트에 국한되어 있어, 여러 서비스나 외부 데이터베이스가 필요한 복잡한 시스템은 커버하지 못한다. 또한, 진단 메타데이터를 활용한 실제 에이전트 학습 효과에 대한 대규모 실험은 이번 연구 범위에서 제외되었다.