요구사항 변경은 실패가 아니라 프로젝트의 일부입니다. 문제는 문서 없이 '조금만 더'가 반복되는 것입니다. Change Request(CR) 발생 시 AI로 영향 분석·재견적·고객 메일 초안을 만드는 절차입니다.
CR 5단계 프로세스
| 단계 | 산출물 | AI 활용 |
|---|---|---|
| 1 접수 | CR 티켓 | 요청 정규화 |
| 2 영향 | WBS diff | 일정·공수 추정 |
| 3 견적 | 추가 견적서 | 견적 도구 |
| 4 합의 | 서면 승인 | 메일 초안 |
| 5 반영 | Scope v1.x | 명세 diff |
CR 티켓 필수 필드
- 요청자·날짜
- 변경 전/후 설명
- 영향 범위 (FE/BE/디자인/QA)
- 추가 일정·비용
- 승인 여부·서명
Scope에 'CR 없이는 작업하지 않음'을 명시해 두면 협상이 쉬워집니다.
AI 프롬프트 예시
다음 변경 요청의 영향 받는 화면·API·테스트 케이스를 표로 정리하고 추가 공수를 시간 단위로 추정해줘: [CR 내용]
팁: CR 승인 전 코드 작업을 시작하면, 분쟁 시 무상 작업으로 간주됩니다. 승인 메일 1통이 수백만 원을 지킵니다.
CR 우선순위 매트릭스
| 영향 큼 | 영향 작음 | |
|---|---|---|
| 긴급 | 즉시 견적·승인 | 다음 스프린트 |
| 비긴급 | 일정 재협상 | 백로그 |
AI 영향 분석 결과를 이 표에 붙이면, PM·클라이언트가 같은 프레임으로 우선순위를 맞출 수 있습니다.
템플릿 저장
승인된 CR 10건을 모아 '자주 나오는 변경' FAQ를 만들면, 다음 프로젝트 RFP In/Out에 미리 반영해 CR 자체를 줄일 수 있습니다.
고객용 CR 메일 톤
"추가 비용을 청구합니다" 대신 "Scope v1.0 대비 변경 diff · 추가 3일 · ○○원 — 승인 주시면 v1.1 반영" 구조를 쓰면 거절률이 낮아집니다. AI가 초안을 쓰고 PM이 숫자만 검증하세요.
CR backlog 주간 review에서 AI로 '유사 CR cluster'를 묶으면, product 쪽에 recurring request로 올릴 product improvement candidate를 찾을 수 있습니다. CR은 비용이면서 동시에 roadmap input입니다.
CR approved 후 AI로 updated timeline Gantt text를 생성하고, client calendar invite description에 붙이면 miscommunication on new dates가 줄어듭니다.
CR template Notion duplicate link를 contract appendix에 넣어 client self-serve request도 same process를 타게 하세요.