멀티 에이전트 구조 기반 AI 리팩토링 시스템 구축하기

·4분 읽기
#AI#Refactoring#Multi-Agent

1. 문제 정의

회사 프로젝트에서 애플리케이션 전체 코드베이스를 대상으로 리팩토링을 진행해야 하는 상황이 있었다.

기존 방식은 단순했다.

개발자가 전체 코드를 직접 확인하고, 리팩토링이 필요한 부분을 판단한 뒤 수작업으로 개선한다.

하지만 코드 규모가 커질수록 다음과 같은 문제가 드러났다.

  • 전 영역을 직접 검토하는 데 드는 시간
  • 리팩토링 필요 여부 판단의 주관성
  • 중복 코드 및 구조 위반 요소의 누락
  • 투입 시간 대비 낮아지는 개선 효과

특히 가장 비효율적이었던 것은 "리팩토링이 필요한지 판단하는 시간" 이었다.

이 판단 과정을 자동화할 수 없을지 고민하다가, AI 기반 멀티 에이전트 구조를 설계하게 되었다.

2. 설계 목표

단순한 코드 수정 자동화가 목표가 아니었다. 다음 다섯 가지를 모두 충족하는 시스템을 만들고자 했다.

  • 코드베이스 전 영역에 대한 자동 분석
  • 리팩토링 필요 요소 도출
  • 개선 설계 수립
  • 안전한 코드 변경
  • Human-in-the-loop 기반 검토 구조

이를 위해 역할별로 분리된 멀티 에이전트 구조를 설계했다.

3. 전체 구조

Orchestrator
├─ Analysis Agent (Claude Sonnet)
├─ Design Agent (Claude Sonnet)
└─ Execution Agent (Claude Opus)

역할 정의

구성 요소역할
Orchestrator전체 흐름 제어 및 단계별 검토 요청
Analysis Agent코드 분석 및 리팩토링 대상 도출
Design Agent분석 결과 기반 리팩토링 전략 설계
Execution Agent설계 기반 실제 코드 변경 수행

4. 분석 기준

Analysis Agent는 다음 기준으로 코드베이스 전 영역을 스캔한다.

  • 중복 코드 탐지
  • FSD 레이어 규칙 위반 여부
  • UI-로직 분리 필요성 (Custom Hook 추출 가능성)
  • 타입 안정성 문제
  • 복수 역할을 수행하는 컴포넌트 탐지
  • 과도한 복잡도를 가진 컴포넌트 식별

단순히 문제를 감지하는 데 그치지 않고, 왜 리팩토링이 필요한지 근거와 함께 리스트업하도록 설계했다.

5. 설계 단계

Design Agent는 분석 결과를 바탕으로 구체적인 개선 방향을 정의한다.

  • 파일 분리 전략
  • Custom Hook 추출 구조
  • FSD 레이어 재배치 방향
  • 타입 구조 개선 전략
  • 컴포넌트 책임 재정의

이 단계에서는 코드를 직접 변경하지 않는다. 오직 설계만 수행한다.

6. 실행 단계

Execution Agent(Opus)는 설계 내용을 기반으로 실제 코드 변경을 수행한다.

코드를 변경하기 전, 반드시 다음 정보를 먼저 출력한다.

  • 변경 대상 파일 목록
  • 변경 요약
  • diff 형태의 코드 제안

그리고 Orchestrator는 개발자에게 확인을 요청한다.

다음 작업을 진행하시겠습니까?

  • 승인 → 변경 실행
  • 수정 요청 → 설계에 반영 후 재검토
  • 중단 → 작업 종료

완전 자동화가 아닌, 단계별 승인 구조를 채택했다.

7. Human-in-the-loop 설계

AI를 전적으로 신뢰하지 않았다.

각 단계가 종료될 때마다 콘솔에 분석 결과 요약, 설계 전략, 코드 변경 diff를 출력하고, 개발자가 진행 여부를 직접 결정하도록 했다.

이 구조를 통해 다음과 같은 리스크를 줄일 수 있었다.

  • 과도한 추상화
  • 기존 설계 의도 파괴
  • 불필요한 구조 변경

8. 모델 분리 전략 및 토큰 최적화

각 에이전트에 서로 다른 모델을 배치했다.

  • 분석 / 설계 → Claude Sonnet
  • 실행 → Claude Opus

역할 특성에 따른 분리

  • 분석·설계 단계는 구조적 사고와 맥락 이해가 중요하다.
  • 실행 단계는 코드 정확성과 일관성이 중요하다.

토큰 비용 최적화

코드베이스 전 영역을 다루기 때문에 토큰 사용량이 매우 크다.

  • 분석 단계는 광범위한 입력을 처리하므로 Sonnet으로 비용 효율을 유지했다.
  • 설계 단계는 요약된 분석 결과를 기반으로 하므로 Sonnet을 유지했다.
  • 실행 단계는 제한된 파일 단위로 작업하므로 Opus를 사용했다.

역할별 모델 분리는 비용과 정확성 사이의 균형을 맞추기 위한 전략이었다.

9. 도입 결과

멀티 에이전트 기반 리팩토링 시스템을 도입한 이후, 다음과 같은 변화가 있었다.

  • 리팩토링 필요 요소 자동 탐지
  • 중복 코드 제거
  • UI-로직 분리 구조 개선
  • 타입 안정성 강화
  • 리팩토링 소요 시간 단축
  • 동일 시간 대비 처리량 증가

가장 큰 변화는 "리팩토링이 필요한지 판단하는 시간"이 크게 줄었다는 점이다.

기존에는 코드베이스 전 영역을 사람이 직접 검토해야 했다. 이제는 Analysis Agent가 1차 후보를 도출하고, 개발자는 검토와 의사결정에 집중할 수 있게 되었다.

10. 회고

  • AI는 리팩토링을 대체하지 않는다. 판단을 보조한다.
  • 핵심은 에이전트 자체가 아니라 오케스트레이션 설계에 있다.
  • Human-in-the-loop 구조는 선택이 아닌 필수다.
  • 멀티 에이전트 구조는 과하지 않았다. 오히려 안정성을 높였다.

11. 향후 확장 방향

리팩토링 결과를 바탕으로 자동으로 PR을 생성하는 구조를 확장할 계획이다. 또한 이 시스템을 사내 누구나 활용할 수 있도록 CLI 형태로 개선하고, 테스트 코드를 자동 생성하는 에이전트를 추가하는 것도 시도해볼 것이다.

댓글