SWE Refactor Bench, 코딩 에이전트는 전체 저장소를 마이그레이션할 수 있을까

서론

코딩 에이전트는 단일 파일 편집이나 국소적인 버그 수정에서 빠르게 발전해 왔다. 그러나 수년간 누적된 소프트웨어의 기술 스택을 바꾸는 일은 전혀 다른 난이도를 가진다. 소스 코드뿐 아니라 의존성, 빌드 설정, 인터페이스, 테스트, 실행 환경이 저장소 전체에서 서로 연결되어 있기 때문이다. SWE Refactor Bench는 이런 장기적이고 광범위한 작업을 측정하기 위해 만들어졌다.

테스트 통과만으로는 충분하지 않다

기존 소프트웨어 엔지니어링 벤치마크는 대체로 정해진 테스트에서 원하는 동작을 보이는지를 확인한다. 이 방식에는 허점이 있다. 에이전트가 기존 구현을 그대로 두거나 요구된 기술 변경을 우회하면서도 테스트를 통과할 수 있기 때문이다. 연구진은 이 문제를 “Blindness”라고 부른다.

SWE Refactor Bench는 다음 세 단계로 이 허점을 줄인다.

• Migration Audit：요구된 마이그레이션이 실제로 수행됐는지 확인한다.
• Behavioral Tests：고정된 테스트 모음으로 마이그레이션 이후의 기능 보존 여부를 검사한다.
• Agentic Verification：6개의 독립 코딩 에이전트가 고정 테스트에서 놓칠 수 있는 행동 차이를 겨냥한 테스트를 생성한다.

벤치마크는 네 종류의 기술 부채를 다루는 20개의 전체 저장소 마이그레이션 과제로 구성된다. 대상 프로젝트로 SQLite, zlib, libsodium, GraphHopper가 제시됐으며, C에서 Rust, Maven에서 Gradle, POSIX에서 WebAssembly로의 전환 등이 포함된다.

마이그레이션 완성도와 동작 정확성은 다르다

실험은 8개 프런티어 모델과 26개 모델 노력 설정을 조합한 520회 실행으로 진행됐다. 세 단계를 모두 통과한 실행은 28회, 전체의 5.4%였다. 20개 과제 중 13개는 수용 가능한 해법을 단 한 번도 받지 못했다. 가장 높은 성적을 낸 claude-opus-5도 47.0/100점에 그쳤다.

세부 결과는 더 중요하다. Migration Audit을 통과한 340회 중 58%는 고정 검사 항목의 99%까지 도달했지만, 100%에 도달한 비율은 26%였다. 에이전트가 마이그레이션을 상당히 진행할 수는 있어도 경계 조건, 호환성, 누락된 세부 사항에서 쉽게 실패한다는 의미다. 마이그레이션을 사실상 건너뛰고 기존 동작만 유지한 일부 실행은 감사 단계에서 중단됐다. 실제로 변경을 시도한 대부분의 실행은 이후 행동 테스트에서 실패했다.

마이그레이션 종류별 차이도 컸다. 빌드 도구체인 재작성 점수는 31.4였지만 언어 마이그레이션은 5.6에 그쳤다. 언어를 바꾸려면 문법 변환을 넘어 의미, 의존성, 런타임 차이, 저장소 내부의 인터페이스까지 함께 조정해야 한다.

의미와 영향

이 벤치마크는 “코드가 실행된다”는 사실과 “마이그레이션이라는 엔지니어링 목표를 달성했다”는 사실을 분리한다. 기술 부채를 줄이고 유지보수 비용을 낮추려는 실제 프로젝트에서는 보이는 테스트를 통과하는 것만으로 충분하지 않다. 기존 부채를 남긴 채 새로운 호환성 문제를 만들 수도 있기 때문이다.

앞으로의 에이전트는 코드 생성뿐 아니라 저장소 전체 계획 수립, 의존성 추적, 변경 범위 감사, 숨은 행동 차이 탐색, 실패 이후의 반복 수정 능력을 갖춰야 한다. 이번 결과는 시스템 규모의 소프트웨어 진화가 여전히 미해결 과제임을 보여준다. 현재의 에이전트는 마이그레이션의 제한된 부분을 지원할 수 있지만, 전체 변경을 독립적으로 책임질 수준에는 아직 도달하지 못했다.

출처: Hugging Face Daily Papers