기술 요약: REFINE – 증거 기반 코드 리팩토링을 위한 멀티 에이전트 LLM 접근 방식

문제 정의

대규모 언어 모델(LLM)은 코드 생성 및 변환에서 강력한 능력을 보여주지만, 소프트웨어 리팩토링에 적용할 때는 상당한 어려움에 직면합니다. 효과적인 리팩토링을 위해서는 코드 품질 문제(코드 스멜)를 줄이기 위해 코드를 수정할 뿐만 아니라, 변경 사항이 새로운 결함을 도입하거나 외부 동작을 변경하거나 또는 중요한 구조적 요소(예: 공개 API, 어설션)를 제거하지 않도록 보장해야 합니다.

현재의 LLM 지원 리팩토링 방식은 엄격한 검증이 부족하여, 환각된 제안, 일관성 없는 변환, 또는 동작 관련 코드 구조의 제거와 같은 위험을 초래하는 경우가 많습니다. 따라서 다음과 같은 체계적인 접근 방식이 필요합니다:

1. 정적 분석으로부터 얻은 증거를 통해 LLM을 가이드함.
2. 계획, 생성 및 검증을 위해 멀티 에이전트 워크플로우를 오케스트레이션함.
3. 무엇이 변경되었는지, 어떤 위험이 남아 있는지, 그리고 출력이 단순히 자동으로 수용되는 솔루션이 아닌 실행 가능한 리팩토링 후보인지에 대한 추적 가능한 증거를 제공함.

방법론: REFINE 워크플로우

저자들은 Java 파일 수준의 리팩토링을 위해 설계된 도구 불가지론적(tool-agnostic)이고 증거 인식적인 멀티 에이전트 프레임워크인 REFINE(Refactoring with Evidence-aware Flow for Integrated ageNtic Execution)을 소개합니다. 이 시스템은 Next.js 인터페이스, 정적 분석(PMD 7.x)을 위한 Java Spring Boot 백엔드, 그리고 오케스트레이션을 위한 Python 에이전트 서비스(LangGraph v1.1 사용)를 사용하여 연구 프로토타입으로 구현되었습니다.

워크플로우는 세 가지 주요 단계를 통해 작동합니다:

1. 작업 특성화 (Task Characterization)

• 입력: 오픈 소스 프로젝트의 단일 Java 파일.
• 증거 수집: 정적 분석(PMD)이 파일 수준의 코드 스멜과 규칙 수준의 증거를 식별합니다.
• 맥락화: 시스템은 공개 API 시그니처, 워크스페이스 컨텍스트를 추출하고, 탐지된 코드 스멜의 우선순위를 정하여 경계가 설정된 리팩토링 작업을 형성합니다.

2. 리팩토링 오케스트레이션 (Refactoring Orchestration)

워크플로우는 프로세스를 관리하기 위해 11개의 별도 역할(에이전트)을 조정합니다:

• 계획 에이전트 (Planning Agent): 결정론적 규칙 기반 가이드와 선택적인 LLM 정교화를 결합하여 스멜 중심의 리팩토링 계획을 수립합니다.
• 리팩토링 에이전트 (Refactoring Agent): 계획, 원본 소스 및 제약 조건(예: 공개 API 보존)을 바탕으로 후보 변환을 생성하기 위해 LLM을 호출합니다.
• 검증 에이전트 (Verification Agent): 생성된 후보가 유지되기 전, 구성된 증거 체크리스트에 따라 후보를 분석합니다.

3. 검증 추적 및 분석 (Verification Trace & Analysis)

REFINE은 LLM 출력을 최종 결과로 취급하지 않습니다. 대신, 변환된 파일을 재분석하여 다음을 계산합니다:

• 스멜 감소: 절대적($\Delta_{smell} = B - A$) 및 상대적 코드 스멜 탐지 개선도.
• 정적 보존 프록시 (Static Preservation Proxies): 공개 API 보존, 예외 처리, 프레임워크 계약, 조건부 로직, 그리고 중요한 assert/fail 호출에 대한 체크.
• 실패 진단: 특정 거절 사유(예: 공개 메서드 제거)를 기록합니다.
• 추적 가능성: 모든 결정이 증거와 연결되도록 원본 소스, 생성된 후보, 에이전트 단계, 메트릭 및 검증 결과를 영속화합니다.

실험 설계

• 데이터셋: 코드 스멜 수와 코드 라인 수(LOC)에 따른 층화 무작위 추출을 통해 선정된 15개 오픈 소스 시스템(예: JHotDraw, Apache Ant, Guava, JabRef)의 450개 Java 파일.
• LLM 구성: 세 가지 프런티어 모델이 평가되었습니다: OpenAI GPT-5.5, Google Gemini 3.1 Pro Preview, Anthropic Claude Opus 4.8.
• 규모: 이는 총 1,350개의 모델 패스 출력을 생성했습니다.
• 베이스라인: 단순 프롬프팅과 멀티 에이전트 워크플로우를 비교하기 위해 150개 파일 서브셋에 대해 매칭된 직접 프롬프팅 베이스라인을 수행했습니다.
• 메트릭: 코드 스멜 감소, 품질 지표(순환 복잡도, 유지보수성 지수 등), 구조적 변경, 그리고 보존 위험.

주요 결과

1. 코드 스멜 감소 (RQ1)

REFINE은 세 가지 LLM 구성 모두에서 탐지된 코드 스멜의 상당한 감소를 달ей했습니다:

• 총 감소량: GPT-5.5(68.26%), Gemini 3.1(72.79%), Opus 4.8(68.49%).
• 주요 스멜: 가장 유의미한 개선은 주요 코드 스멜에서 나타났습니다 (86.51%에서 91.60% 감소).
• 품질 지표: 광범위한 품질 메트릭의 개선은 균일하지 않았습니다. Gemini 3.1은 순환 복잡도와 LCOM에서 상당한 감소를 보였으나, 다른 메트릭(유지보수성, 테스트 가능성, Halstead 노력)은 모델에 따라 혼재되거나 부정적인 변화를 보이기도 했습니다.

2. 보존 및 위험 (RQ2)

• 높은 통과율: 대부분의 정적 보존 지표(공개 메서드 시그니처, 예외 처리, 프레임워크 계약)는 높은 통과율(81.8% ~ 94.2%)을 기록했습니다.
• 핵심 위험:
  • Assert/Fail 호출: 모든 모델에서 핵심적인 assert/fail 호출을 보존한 출력은 57.1%에 불과하여 체계적인 위험을 나타냈습니다.
  • 공개 메서드 제거: 이는 가장 구체적인 진단 실패 사례였습니다. Gemini 3.1이 71건으로 가장 많은 공개 메서드 제거를 보였고, GPT-5.5(41건), Opus 4.8(34건)이 그 뒤를 이었습니다.

3. 리팩토링 동작 (RQ3)

모델마다 서로 다른 편집 프로필을 통해 스멜 감소를 달성했습니다:

• GPT-5.5: 가장 압축적인 편집을 생성했습니다.
• Gemini 3.1: 가장 많은 라인과 메서드를 제거하는 "삭제 중심(deletion-heavy)" 프로필을 보였습니다.
• Opus 4.8: 가장 많은 메서드 추출을 수행하는 "추출 중심(extraction-heavy)" 프로필을 보였습니다.
• 상관관계: 더 큰 편집 볼륨은 더 높은 절대적 스멜 감소와 상관관계가 있었으나, 반드시 더 높은 상대적 감소와 일치하지는 않았습니다.

4. 직접 프롬프팅과의 비교

매칭된 150개 파일 서브셋에서 REFINE은 직접 프롬프팅보다 다음 항목에서 우수한 성능을 보였습니다:

• 스멜 감소: 중앙값 총 감소량이 REFINE(100.0%)이 직접 프롬프팅(20.8%)보다 높았습니다.
• 편집 흔적 (Edit Footprint): 더 작은 중앙값 변경량(14 LOC vs 65 LOC)을 보였습니다.
• API 안전성: 더 적은 공개 메서드 제거 사례(46건 vs 112건)를 기록했습니다.
• 트레이드오프: 직접 프롬프팅이 핵심적인 assert/fail 구문을 더 자주 보존했습니다 (100% vs 58%).

의의 및 주장

본 논문은 REFINE을 행동 보존형 리팩토링 도체의 대체제가 아니라, 추적 가능하고 증거를 인식하는 리팩토링 후보 생성 및 평가 메커니즘으로 규정합니다.

• 증거 인식: 주요 기여는 생성된 코드를 변화를 유발한 특정 정적 증거(스멜) 및 통과하거나 실패한 검증 체크와 연결하는 것입니다.
• 제어된 생성: 멀티 에이전트 워크플로우는 직접 프롬프팅보다 더 제어된 후보 생성을 제공하여, 더 작은 편집과 우발적인 API 제거를 유도하지만, 모든 행동적 위험을 제거하지는 못합니다.
• 한계: 저자들은 생성된 출력이 생산 환경에 즉시 적용 가능한 것이 아닌 **후보(candidate)**임을 명시적으로 밝힙니다. 정적 보존 체크는 프록시(대리 지표)이며 행동적 동등성을 입증하는 것은 아닙니다.
• 실무적 시사점: 생성된 후보는 특히 의존성이 풍부하거나 시스템 수준의 환경에서 채택되기 전에 컴파일, 테스트, 의존성 분석 및 인간의 검토를 거쳐야 합니다.

결론적으로, 본 연구는 증거 인식 멀리 에이전트 워크플로우가 타겟팅된 파일 수준의 코드 스멜 완화에는 유망하지만, 직접 프롬프팅이나 멀티 에이전트 방식 모두 현재로서는 복잡한 소프트웨어 생태계에서 자율적으로 작동할 만큼 충분한 전체 행동 보존 증거를 제공하지 못한다고 밝히고 있습니다.