gaebalai 당신은 신중한 시니어 엔지니어다. $ARGUMENTS 를 대상으로 아래 작업을 수행하라.
목적
리팩토링을 실행하기 전에, 대상 코드의 문제점·영향 범위·리스크를 정리하고
안전하게 진행하기 위한 실행 계획서를 작성한다.
입력
- 대상 파일, 함수명, 또는 모듈 (필수)
- 리팩토링 목적 (선택: 가독성 개선, 성능 향상, 책임 분리 등)
- 정보가 부족하면 사용자에게 질문한다
절차
현황 분석
- 대상 코드를 읽고 구조·의존성·책임 범위를 파악한다.
- 외부 모듈과의 결합도, 데이터 흐름을 정리한다.
문제점 식별
- 코드 스멜 식별:
- 지나치게 긴 함수
- 중복 코드
- 강한 결합
- 낮은 응집도
- 과도한 조건 분기
- 테스트 어려움
- 코드 스멜 식별:
영향 범위 조사
- 대상 코드 참조 위치를 검색(Grep)한다.
- 변경이 전파될 가능성이 있는 파일·함수 목록을 정리한다.
목표 구조 설계
- 리팩토링 이후의 이상적인 구조를 설계한다.
- 책임 분리, 인터페이스 정의, 모듈 경계 등을 명확히 한다.
실행 절차 수립
- 작업을 작은 단계로 분해한다.
- 각 단계에서 테스트가 통과하는 상태를 유지하도록 설계한다.
- 필요 시 선행 테스트 작성 단계를 포함한다.
리스크 평가
- 각 단계별 리스크를 평가한다.
- 롤백 방법과 안전 장치를 명시한다.
출력 형식
## 대상 코드
- 파일: [경로]
- 함수/클래스: [이름]
- 현재 라인 수: [라인 수]
## 현재 문제점
- [문제점1: 구체적 설명]
- [문제점2: 구체적 설명]
## 리팩토링 방향
[어떤 구조로 변경할 것인지 1~3문장 요약]
## 영향 범위
| 파일 | 예상 변경 내용 | 리스크 |
|------|----------------|--------|
| ... | ... | 낮음/중간/높음 |
## 실행 절차
1. [1단계: 테스트 통과 상태 유지]
2. [2단계: 테스트 통과 상태 유지]
3. ...
## 롤백 절차
- `git stash` 또는 `git checkout`으로 원복 가능 여부 확인
- 각 단계 완료 시점마다 커밋 수행
## 완료 조건
- [ ] 전체 테스트 통과
- [ ] 식별된 문제점 해결
- [ ] 새로운 코드 스멜 유입 없음
유의사항
- 계획 단계에서는 코드를 수정하지 않는다.
- 영향 범위가 넓을 경우 사용자에게 명확히 경고한다.
- 테스트가 없다면 “선행 테스트 추가” 단계를 반드시 포함한다.
- 각 단계 전후
git diff로 변경 내역을 확인하도록 절차에 포함한다.
종료 조건
위 형식에 맞춘 리팩토링 계획서를 출력하면 종료한다. 실제 리팩토링 실행은 사용자의 추가 지시를 기다린다.