기술 요약: SWE-Refactor

문제 정의

대규모 언어 모델(LLM)은 코드 생성 측면에서 상당한 능력을 입증해 왔으나, **코드 리팩터링(code refactoring)**은 별개의 과제를 제시합니다. 리팩터링은 프로그램의 동작을 변경하지 않으면서 구조를 개선하는 정밀하고 의미론적으로 보존된 편집을 요구합니다. 이 작업은 저장소 수준의 추론, 복잡한 의존성에 대한 이해, 그리고 반복적인 검증을 필요로 하며, 이는 현재의 모델들이 달성하기 어렵고 종종 그 범위를 벗어나는 능력입니다.

기존의 리팩터링 벤치마크는 네 가지 결정적인 결함을 가지고 있습니다:

1. 제한된 시나리오 커버리지: 이들은 실제 개발에서 흔히 발생하는 복합 리팩터링(여러 번의 조정된 변환)보다는 원자적 리팩터링 유형(단일 변환)에 주로 집중되어 있습니다.
2. 자동 구축의 부재: 많은 벤치마크가 수동 큐레이션이나 LLM이 생성한 정답(ground truth)에 의존하며, 이는 편향과 확장성 문제를 야기합니다.
3. 불충분한 저장소 수준의 컨텍스트: 기존 데이터셋은 현실적인 평가에 필요한 구조적 정보(예: 클래스 계층 구조, 호출자/피호출자 관계)가 부족한 경우가 많습니다.
4. 노이즈 데이터: 많은 벤치마크가 리팩터링이 버그 수정이나 기능 추가와 혼합된 "불순한(impure)" 커밋을 포함하고 있어, 모델의 리팩터링 능력을 분리하여 평가하기 어렵게 만듭니다.

또한, 최근의 많은 벤치마크가 Python에만 독점적으로 집중되어 있는 반면, Java는 엔터프라이즈 시스템에서 지배적인 언어라는 점에서 이 분야는 프로그래밍 언어의 다양성 부족 문제를 겪고 있습니다.

방법론: SWE-Refactor

이러한 격차를 해소하기 위해 저자들은 실제 Java 프로젝트로부터 구축된 저장소 수준의 벤치마크인 SWE-Refactor를 소개합니다. 이 벤치마크는 완전히 자동화된 4단계 파이프라인을 통해 구축되었습니다:

1. 정적 분석을 통한 마이닝: 저자들은 AST 기반 도구인 RefactoringMiner를 활용하여 18개의 널리 사용되는 Java 프로젝트에서 리팩터링을 포함하는 커밋을 추출합니다.
2. 순수 리팩터링 큐레이션: PurityChecker(RefactoringMiner의 확장판)를 사용하여 불순한 변경 사항(예: 버그 수정)을 필터링하고 "순수한" 리팩터링만을 남깁니다. 저자들은 탐지기의 신뢰성을 확인하기 위해 무작위로 추출된 200개의 인스턴스를 수동으로 검증했습니다.
3. 다층적 정보 보강: 저장소 수준의 추론을 지원하기 위해, 파이프라인은 Eclipse JDT를 사용하여 프로젝트 구조, 전체 클래스 본문, 메서드 호출자/피호술자, 빌드 구성 등을 포함한 포괄적인 컨텍스트를 추출합니다.
4. 검증: 파이프라인은 적절한 JDK 버전으로 프로젝트를 컴파일하고 전체 테스트 스위트(JaCoCo 사용)를 실행하여 리팩터링이 동작을 보존하는지 확인함으로써 기능적 정확성을 보장합니다.

데이터셋 구성:

• 규모: 1,099개의 개발자 작성, 동작 보존 리팩터링.
• 출처: 18개의 다양한 Java 프로젝트.
• 유형: 922개의 원자적 인스턴스와 177개의 복합 인스턴스 포함.
• 리팩터링 유형: 3가지 원자적 유형(Extract Method, Move Method, Inline Method)과 3가지 복합 유형(Extract and Move, Move and Inline, Move and Rename)을 다룹니다.

평가 지표:
본 벤치마크는 두 가지 차원에서 LLM 성능을 평가합니다:

1. 기능적 정확성: 컴파일 성공 여부, 테스트 통과율, 그리고 AST 기반 리팩터링 검증(의도한 변환이 의도하지 않은 부작용 없이 발생했는지 확인하기 위해 RefactoringMiner 사용)을 통해 측정됩니다.
2. 인간 유사성: 개발자가 작성한 정답과의 유사성을 평가하기 위해 CodeBLEU를 사용하여 측정됩니다.

주요 기여

1. SWE-Refactor 벤치마크: 18개 Java 프로젝트에서 추출한 1,099개의 순수 리팩터링을 담은 고품질의 새로운 데이터셋으로, 원자적 및 복합 변환을 모두 다룹니다. 이는 Java에 대해 포괄적인 저장소 수준의 컨텍스트와 자동 검증을 제공하는 최초의 벤치마크입니다.
2. 자동 구축 파이프라인: 실제 리팩터링을 추출하고, 순수성을 필터링하며, 구조적 데이터를 보강하고, 수동 주석이나 LLM 생성 정답 없이 정확성을 검증하는 재현 가능한 4단계 파이프라인을 제공합니다.
3. 포괄적 평가: 다양한 리팩터링 유형과 프롬프팅 전략(Simple Prompting, RAG, Multi-Agent 워크플로우)에 걸쳐 9개의 널리 사용되는 LLM(GPT-4o-mini, DeepSeek-V3 및 다양한 CodeLLaMa/Qwen 변체 포함)을 광범위하게 평가했습니다.

실험 결과

저자들은 1,099개의 인스턴스에 대해 9개의 LLM을 평가했습니다. 주요 결과는 다음과 같습니다:

• 전반적인 성능: 범용 모델이 오픈 소스 코드 특화 모델보다 우수한 성능을 보였습니다. DeepSeek-V3가 가장 높은 성공률(41.58%)을 기록했으며, GPT-4o-mini(39.85%)가 그 뒤를 이었습니다. CodeLLaMa-7B와 같은 오픈 소스 모델은 단 1.10%의 성공률을 보였습니다.
• 원자적 vs 복합: 모델들은 복합 리팩터링(파일 간, 다단계 변환)보다 원자적 리팩터링(로컬 편집)에서 훨씬 더 나은 성능을 보였습니다.
  • DeepSeek-V3는 Extract Method(301회 성공)에서 뛰어난 성과를 보였습니다.
  • GPT-4o-mini는 Move Method와 같은 파일 간 작업에서 더 넓은 일반화 능력을 보여주었습니다(92회 성공).
  • 오픈 소스 모델들은 복합 유형에서 거의 전무한 수준의 성과를 보였습니다.
• 고급 기술의 영향:
  • Multi-Agent 워크플로우: Developer Agent와 Reviewer Agent(GPT-4o-mini 사용)를 사용하는 워크플로우는 가장 높은 전체 성공 횟수(579개 인스턴스)를 달립하였으며, 특히 복잡한 복합 리팩터링에서 단순 프롬프팅 및 RAG를 크게 능가했습니다.
  • Agentic Scaffolding (OpenAI Codex): 강력한 에이전트인 GPT-5.1-Codex조차도 복합 인스턴스에서는 39.4%의 성공률을 기록한 반면, 원자적 인스턴스에서는 82.6%를 기록하여, 다단계의 엄격한 제약이 있는 변환의 지속적인 어려움을 보여주었습니다.

의의 및 주장

본 논문은 SWE-Refactor를 소프트웨어 엔지니어링 벤치마크의 필수적인 진화로 규정합니다. 그 의의는 다음과 같습니다:

• 현실성: 실제 프로젝트의 개발자 작성 커밋을 사용함으로써, 합성 또는 LLM 생성 벤치마크와 관련된 편향과 환각을 피합니다.
• 복잡성: 원자적 리팩터링과 복합 리팩터링 사이의 간극을 명시적으로 겨냥하여, 저장소 수준의 추론 능력을 엄격하게 테스트합니다.
• 언어 다양성: 견고한 Java 벤치마크를 제공함으로써 현재의 Python 중심적 편향을 해결하며, 대규모 엔터프라이즈 시스템에서 사용되는 언어를 반영합니다.
• 신뢰성: 자동화된 파이프라인은 정답이 동작을 보존하고 구조적으로 올바름을 보장하여, 향후 연구를 위한 신뢰할 수 있는 표준을 제공합니다.

저자들은 LLM이 코드 생성에서는 유망함을 보이지만, 복잡한 복합 리팩터링 작업에는 여전히 상당한 어려움을 겪고 있다고 결론지으며, 이는 현재의 에이전트 프레임워크가 인간의 감독 없이 다단계 소프트웨어 유지보수를 수행하기에는 아직 신뢰할 수 없음을 시사합니다.