RepoRescue: LLM 에이전트의 전체 저장소 호환성 구조에 대한 실증 연구

초록

오픈소스 라이브러리와 도구는 널리 재사용되지만, 호환성 유지 비용이 높다. 관리자가 떠나면 런타임과 의존성이 진화함에 따라 유용한 저장소가 더 이상 작동하지 않을 수 있다. 본 연구는 LLM 에이전트가 오래된 저장소를 현대 환경에 적응시킬 수 있는지, 즉 호환성 구조(compatibility rescue)라는 과제를 탐구한다. 버그 수리와 달리 호환성 구조는 원래 환경에서는 작동했지만 생태계 변화 후 실패하는 저장소에서 시작된다. RepoRescue는 에이전트에게 저장소와 실패하는 현대 환경만 제공하며, 에이전트는 실패를 진단하고 영향을 받은 코드를 찾아 역사적 테스트 스위트를 복원하는 소스 코드 구조 작업을 수행해야 한다. 우리는 Python 193개와 Java 122개 저장소로 RepoRescue를 구축했으며, 각 저장소는 과거에는 통과했지만 현대화 후 실패하는 것으로 검증되었다. Python에서는 5개, Java에서는 3개의 배포된 에이전트 시스템을 평가했다. 전체 패치 통과율 외에도 테스트 파일 수정을 제거한 후 패치를 재실행하여 소스 전용 수리를 측정하고, 테스트 편집을 차단하는 런타임 강제 방식을 추가했으며, 구조 후 스위트가 통과한 저장소의 실제 사용을 검증했다. Claude Code 시스템은 지시에도 불구하고 실패하는 테스트를 편집하는 경우가 있으며, 런타임 차단 시 Kimi는 여전히 41.5%의 저장소를 구조한다. 시스템은 상호 보완적이며, 이들의 합집합은 62.7%에 달해 최고 단일 시스템보다 10.9%포인트 높다. 난이도는 파일 간 조정에 집중된다. 코드베이스 전체의 조정이 필요한 14개 저장소에서 GPT-5.2(Codex를 통해)는 14개 모두 통과한 반면, 모든 Claude Code 시스템은 최대 2개만 통과했다. 마지막으로, 통과하는 스위트는 초기 신호일 뿐이다. 구조 후 스위트가 통과한 34개의 관리되지 않는 Python 후보 중 22개는 실제 시나리오에서 작동하고, 12개는 호환성 실패를 해결하는 패치로 버그 사냥을 통과한다. RepoRescue는 소스 전용 감사, 런타임 강제, 실용적 검증, 추론 레이블을 통해 호환성 구조를 벤치마킹한다.

English

Open-source libraries and tools are widely reused, but compatibility maintenance is expensive. Once maintainers leave, useful repositories can stop working as runtimes and dependencies evolve. We study whether LLM agents can adapt old repositories to modern environments, a task we call compatibility rescue. Unlike bug repair, compatibility rescue starts from a repository that worked in its original environment but fails after ecosystem drift. RepoRescue gives agents only the repository and its failing modern environment; the agent must diagnose the failure, locate affected code, and produce a source-code rescue that restores the historical test suite. We build RepoRescue from 193 Python and 122 Java repositories, each verified to pass historically and fail after modernization. We evaluate five deployed agent systems on Python and three on Java. Beyond full-patch pass rate, we rerun patches after removing test-file edits to measure source-only repair, add a runtime-enforced regime that blocks test edits, and validate practical use for repositories whose suites pass after rescue. We find that Claude Code systems sometimes edit failing tests even when prompted not to; with runtime blocking, Kimi still rescues 41.5% of repositories. Systems are complementary: their union reaches 62.7%, exceeding the best single system by 10.9 points. Difficulty concentrates in cross-file coordination: on 14 repositories requiring coordinated whole-codebase changes, GPT-5.2 through Codex passes all 14, while every Claude Code system passes at most two. Finally, a passing suite is only an initial signal: among 34 unmaintained Python candidates whose suites pass after rescue, 22 work in realistic scenarios and 12 pass bug-hunt with patches that address the compatibility failure. RepoRescue benchmarks compatibility rescue with source-only auditing, runtime enforcement, practical validation, and reasoning labels.