[Paper] 멀티 에이전트 협업 이름 바꾸기 리팩터링

Source: arXiv - 2601.00482v1

개요

조정된 이름 바꾸기 리팩터링—단일 이름 변경이 많은 관련 식별자에 파급되어야 하는 경우—는 개발자에게 흔하지만 오류가 발생하기 쉬운 작업입니다. 이 논문은 개발자와 협력하여 전체 과정을 자동화하는 최초의 멀티‑에이전트 프레임워크를 제시합니다. 초기 이름 변경을 프로젝트 전체에 걸친 안전한 변환으로 전환하면서도 인간이 제어권을 유지하도록 합니다.

주요 기여

• 멀티‑에이전트 아키텍처 (Scope Inference, Planned Execution, Replication) 로 LLM 추론을 IDE‑네이티브 리팩터링 API와 조정합니다.
• Declared Scope 언어: 이름 변경 의도 범위를 간결한 자연어로 표현한 것으로, 개발자의 첫 번째 편집에서 자동으로 생성됩니다.
• 실증 연구: 100개의 오픈‑소스 프로젝트에서 609 K 커밋에 걸친 협조적 이름 변경을 분석하여 패턴과 문제점을 밝혀냈습니다.
• 사용자 평가 (205명 개발자)에서 수동 작업이 73 % 감소하고 오탐 제안이 5배 감소했음을 보여줍니다.
• 오픈‑소스 프로토타입: VS Code와 IntelliJ에 통합되었으며 Apache‑2.0 라이선스로 공개되었습니다.

방법론

1. 형성 마이닝 – 저자들은 이름 변경 커밋을 분석하여 이름 변경이 추가 변경을 유발하는 빈도를 정량화하고, 중요한 컨텍스트(예: 클래스 이름, API 심볼)를 식별했습니다.
2. 에이전트 설계
   • 범위 추론 에이전트는 개발자의 초기 이름 변경(‘단서’)을 읽고, LLM을 사용하여 “fetchData라는 모든 public 메서드와 data 패키지의 모든 오버로드를 이름 변경한다”와 같은 선언된 범위를 생성합니다.
   • 계획 실행 에이전트는 이 범위를 구체적인 계획으로 변환하고, IDE의 리팩터링 엔진에 질의하며, 적용하기 전에 각 변경을 범위와 대조하여 검증합니다.
   • 복제 에이전트는 계획에 기반해 프로젝트 전체 검색을 수행하고, 결과를 실행 에이전트에 전달하여 엣지 케이스를 처리합니다.
3. 구현 – 에이전트들은 가벼운 JSON‑RPC 프로토콜을 통해 통신하며, 이를 통해 LLM은 상태를 유지하지 않고 IDE가 무거운 작업을 처리하도록 합니다.
4. 평가 – 두 단계로 진행됩니다: (a) 실제 이름 변경 시나리오 1 200개에 대한 벤치마크로, 휴리스틱 이름 변경 도구와 일반 LLM 제안을 비교합니다; (b) 사용자 연구에서는 참가자들이 에이전트를 사용한 경우와 사용하지 않은 경우에 협조적인 이름 변경을 수행하도록 하여 시간, 오류율, 주관적 작업 부하를 측정합니다.

결과 및 발견

• Declared Scope는 복잡한 교차 모듈 심볼까지도 의도된 이름 변경 범위의 96 %를 포착했습니다.
• 실제 편집을 IDE의 신뢰할 수 있는 리팩터링 API에 위임함으로써, 순수 LLM 출력에서 흔히 발생하는 “환각” 오류를 방지했습니다.
• 참가자들은 에이전트가 반복적인 작업을 처리하는 동안에도 자신이 “운전석에” 남아 있다고 느꼈다고 보고했습니다.

실용적인 시사점

• IDE 플러그인 – 이 아키텍처는 리팩터링 API를 제공하는 최신 IDE용 플러그인으로 패키징될 수 있어, 팀에게 대규모 이름 변경을 위한 즉시 사용 가능한 도우미를 제공합니다.
• CI/CD 통합 – 에이전트는 pre‑commit 훅에서 실행되어 전체 이름 변경 계획을 제안함으로써 API 폐기와 관련된 코드 리뷰 마찰을 줄입니다.
• 엔터프라이즈 코드베이스 – 수천 개의 상호 의존 모듈을 가진 모노레포에서 조정된 이름 변경은 종종 병목이 되는데, 이 접근법은 소요 시간을 며칠에서 몇 분으로 단축할 수 있습니다.
• 개발자 온보딩 – 새로운 팀원은 에이전트를 활용해 이름 변경이 미치는 파급 효과를 파악함으로써 레거시 코드 학습 곡선을 낮출 수 있습니다.
• 확장성 – 동일한 멀티‑에이전트 패턴을 다른 조정된 리팩터링(예: 인터페이스 추출, 클래스 이동)에도 재활용할 수 있으며, 단일 개발자 의도가 널리 전파됩니다.

제한 사항 및 향후 작업

• 범위 생성은 LLM 품질에 의존 – 문서가 부족하거나 매우 동적인 코드(예: JavaScript)를 사용하는 언어에서는 Scope Inference Agent가 가끔 경계 사례를 놓쳤습니다.
• IDE 의존성 – 현재 프로토타입은 안정적인 리팩터링 API를 제공하는 IDE에서만 작동하며, 헤드리스 환경은 추가 어댑터가 필요합니다.
• 검색 확장성 – 매우 큰 코드베이스(>10 M LOC)의 경우 Replication Agent의 프로젝트 전체 검색이 성능 병목이 되며, 점진적 인덱싱이 계획된 개선 사항입니다.
• 사용자 신뢰 – 오탐이 낮았지만 개발자는 여전히 생성된 계획을 검토해야 하며, 향후 작업에서는 더 풍부한 시각화와 “예시 기반 되돌리기” 메커니즘을 탐구할 예정입니다.

저자들은 여러 전문 에이전트가 협업하는 보다 넓은 생태계를 구상합니다—명명, 타입 마이그레이션, 아키텍처 재구성을 담당하며—AI 기반 리팩터링을 개발자 워크플로우의 일상적인 부분으로 만들고자 합니다.

저자

• Abhiram Bellur
• Mohammed Raihan Ullah
• Fraol Batole
• Mohit Kansara
• Masaharu Morimoto
• Kai Ishikawa
• Haifeng Chen
• Yaroslav Zharov
• Timofey Bryksin
• Tien N. Nguyen
• Hridesh Rajan
• Danny Dig

논문 정보

• arXiv ID: 2601.00482v1
• Categories: cs.SE, cs.AI
• Published: 2026년 1월 1일
• PDF: PDF 다운로드