GitHub Issue와 작은 PR로 점진적 리팩터링 계획을 세우는 프롬프트

언제 사용하나

크게 얽힌 모듈을 한 번에 바꾸기 어려울 때 GitHub Issue에 목표와 위험을 남기고, 여러 개의 작은 PR로 안전하게 진행할 때 사용합니다.

준비할 정보

• {{TARGET_AND_GOAL}}: 대상 모듈과 개선 목표
• {{CONSTRAINTS}}: 호환성, 일정, 배포, 데이터 제약
• {{TEST_SAFETY_NET}}: 기존 테스트와 추가 가능한 관측 지표
• {{OWNERS}}: review·승인·배포 담당자

복사해서 쓰는 프롬프트

아래 리팩터링을 GitHub Issue 1개와 작은 PR들로 나눠 계획해줘.

대상과 목표: {{TARGET_AND_GOAL}}
제약: {{CONSTRAINTS}}
테스트·관측 안전망: {{TEST_SAFETY_NET}}
담당자: {{OWNERS}}

1. Issue에는 배경, 비범위, 완료 조건, 위험, 추적 지표를 작성해.
2. 각 PR은 독립적으로 review·배포·rollback 가능하게 나눠.
3. PR별 변경 파일 후보, 선행 관계, 테스트, feature flag 필요 여부를 적어.
4. 기능 동작을 바꾸는 단계와 구조만 바꾸는 단계를 분리해.
5. 중단 기준과 전체 계획을 재평가할 checkpoint를 포함해.

검증 방법

각 PR의 완료 조건을 CI와 실제 환경에서 확인하고 GitHub Issue checklist에 증빙 링크를 남깁니다. 다음 PR을 시작하기 전에 이전 단계의 오류율과 rollback 가능성을 확인합니다.

주의사항

PR 개수만 잘게 나누고 서로 강하게 의존하게 만들지 않습니다. contract 삭제나 데이터 migration처럼 되돌리기 어려운 단계는 호환 기간 뒤 별도 승인으로 진행합니다.