오픈 소스 라이브러리와 도구들은 널리 재사용되지만, 호환성 유지(compatibility maintenance)에는 많은 비용이 듭니다. 유지 관리자가 떠나면, 런타임(runtime)과 의존성(dependencies)이 진화함에 따라 유용한 저장소(repositories)들이 작동을 멈출 수 있습니다. 우리는 LLM 에이전트가 오래된 저장소를 현대적인 환경에 적응시킬 수 있는지 연구하며, 이 작업을 호환성 복구(compatibility rescue)라고 부릅니다. 버그 수정(bug repair)과 달리, 호환성 복구는 원래 환경에서는 작동했지만 생태계 표류(ecosystem drift) 이후 실패하는 저장소에서 시작됩니다. RepoRescue는 에이전트에게 저장소와 실패하는 현대적 환경만을 제공합니다. 에이전트는 실패를 진단하고, 영향을 받는 코드를 찾아내며, 과거의 테스트 스위트(test suite)를 복구하는 소스 코드 복구(source-code rescue)를 생성해야 합니다. 우리는 각각 과거에는 통과했으나 현대화 이후 실패하는 것이 검증된 193개의 Python 및 122개의 Java 저장소를 사용하여 RepoRescue를 구축했습니다. 우리는 Python에서 5개의 배포된 에이전트 시스템을, Java에서 3개의 시스템을 평가합니다. 전체 패치 통과율(full-patch pass rate) 외에도, 우리는 소스 전용 수정(source-only repair)을 측정하기 위해 테스트 파일 수정을 제거한 후 패치를 재실행하고, 테스트 수정을 차단하는 런타임 강제(runtime-enforced) 체제를 추가하며, 복구 후 테스트 스위트가 통과하는 저장소들에 대한 실질적인 사용성을 검증합니다. 연구 결과, Claude Code 시스템은 수정하지 말라는 프롬프트가 주어졌음에도 때때로 실패하는 테스트를 수정하는 것으로 나타났습니다. 런타임 차단 시, Kimi는 여전히 41.5%의 저장소를 복구합니다. 시스템들은 상호 보완적입니다: 이들의 결합(union)은 62.7%에 도달하여, 단일 최상위 시스템보다 10.9포인트 높았습니다. 난이도는 파일 간 조정(cross-file coordination)에 집중됩니다: 코드베이스 전체의 조정된 변경이 필요한 14개의 저장소에서, GPT-5.2부터 Codex까지는 14개 모두를 통과한 반면, 모든 Claude Code 시스템은 최대 2개만 통과했습니다. 마지막으로, 통과하는 테스트 스위트는 초기 신호일 뿐입니다: 복구 후 테스트 스위트가 통과하는 34개의 관리되지 않는 Python 후보군 중, 22개는 현실적인 시나리오에서 작동하며 12개는 호환성 실패를 해결하는 패치로 버그 헌트(bug-hunt)를 통과합니다. RepoRescue는 소스 전용 감사(source-only auditing), 런타임 강제, 실질적 검증 및 추론 라벨(reasoning labels)을 통해 호환성 복구를 벤치마킹합니다.