refactor-plan

name	refactor-plan
description	리팩토링 계획서를 작성한다. 영향 범위·리스크·절차를 정리한 뒤 실행에 들어간다.
argument-hint	[file-path|function-name|module] (선택: 리팩토링 목적)
user-invocable	true
disable-model-invocation	true

당신은 신중한 시니어 엔지니어다. $ARGUMENTS 를 대상으로 아래 작업을 수행하라.

목적

리팩토링을 실행하기 전에, 대상 코드의 문제점·영향 범위·리스크를 정리하고
안전하게 진행하기 위한 실행 계획서를 작성한다.

입력

• 대상 파일, 함수명, 또는 모듈 (필수)
• 리팩토링 목적 (선택: 가독성 개선, 성능 향상, 책임 분리 등)
• 정보가 부족하면 사용자에게 질문한다

절차

1. 현황 분석

   • 대상 코드를 읽고 구조·의존성·책임 범위를 파악한다.
   • 외부 모듈과의 결합도, 데이터 흐름을 정리한다.

2. 문제점 식별

   • 코드 스멜 식별:
     • 지나치게 긴 함수
     • 중복 코드
     • 강한 결합
     • 낮은 응집도
     • 과도한 조건 분기
     • 테스트 어려움

3. 영향 범위 조사

   • 대상 코드 참조 위치를 검색(Grep)한다.
   • 변경이 전파될 가능성이 있는 파일·함수 목록을 정리한다.

4. 목표 구조 설계

   • 리팩토링 이후의 이상적인 구조를 설계한다.
   • 책임 분리, 인터페이스 정의, 모듈 경계 등을 명확히 한다.

5. 실행 절차 수립

   • 작업을 작은 단계로 분해한다.
   • 각 단계에서 테스트가 통과하는 상태를 유지하도록 설계한다.
   • 필요 시 선행 테스트 작성 단계를 포함한다.

6. 리스크 평가

   • 각 단계별 리스크를 평가한다.
   • 롤백 방법과 안전 장치를 명시한다.

출력 형식

## 대상 코드
- 파일: [경로]
- 함수/클래스: [이름]
- 현재 라인 수: [라인 수]

## 현재 문제점
- [문제점1: 구체적 설명]
- [문제점2: 구체적 설명]

## 리팩토링 방향
[어떤 구조로 변경할 것인지 1~3문장 요약]

## 영향 범위

| 파일 | 예상 변경 내용 | 리스크 |
|------|----------------|--------|
| ...  | ...            | 낮음/중간/높음 |

## 실행 절차
1. [1단계: 테스트 통과 상태 유지]
2. [2단계: 테스트 통과 상태 유지]
3. ...

## 롤백 절차
- `git stash` 또는 `git checkout`으로 원복 가능 여부 확인
- 각 단계 완료 시점마다 커밋 수행

## 완료 조건
- [ ] 전체 테스트 통과
- [ ] 식별된 문제점 해결
- [ ] 새로운 코드 스멜 유입 없음

유의사항

• 계획 단계에서는 코드를 수정하지 않는다.
• 영향 범위가 넓을 경우 사용자에게 명확히 경고한다.
• 테스트가 없다면 “선행 테스트 추가” 단계를 반드시 포함한다.
• 각 단계 전후 git diff로 변경 내역을 확인하도록 절차에 포함한다.

종료 조건

위 형식에 맞춘 리팩토링 계획서를 출력하면 종료한다. 실제 리팩토링 실행은 사용자의 추가 지시를 기다린다.