From project-lifecycle
변경 영향 분석 스킬. 기획, 설계, 코드 변경 시 영향받는 산출물과 범위를 체계적으로 분석한다. "영향 분석", "변경 영향", "임팩트 분석", "변경 범위", "impact analysis", "change impact", "기획 변경" 요청 시 사용.
npx claudepluginhub shaul1991/shaul-plugin --plugin project-lifecycleThis skill uses the workspace's default tool permissions.
기획, 설계, 코드 등 어떤 단계에서든 변경이 발생할 때,
Batch-converts UI design screenshots from directories into Vue 3 Composition API components, mapping elements to Vant, Element Plus, or Ant Design Vue libraries.
Share bugs, ideas, or general feedback.
기획, 설계, 코드 등 어떤 단계에서든 변경이 발생할 때, 영향받는 후속 산출물과 범위를 체계적으로 분석하여 누락 없이 업데이트할 수 있도록 한다.
담당 에이전트:
alm-manager(어플리케이션 라이프사이클 매니저)
프로젝트에서 변경은 불가피하다. 문제는 변경 자체가 아니라 변경의 파급 효과를 놓치는 것이다. 기획 하나가 바뀌면 설계, 코드, 테스트, 문서 모두 영향받을 수 있다. 영향 분석 없는 변경은 드리프트와 회귀 버그의 원인이 된다.
변경의 내용과 범위를 명확히 정의한다:
## 변경 요청서
| 항목 | 내용 |
|------|------|
| 변경 ID | CHG-YYYY-NNN |
| 변경 유형 | 기획 변경 / 설계 변경 / 기술 스택 변경 / 요구사항 추가 / 요구사항 삭제 |
| 변경 대상 | 변경되는 산출물/기능 명시 |
| 변경 사유 | 왜 변경이 필요한가 |
| 요청자 | |
| 요청일 | YYYY-MM-DD |
변경 대상이 속한 Phase에서 시작하여 후속 Phase로의 의존성을 추적한다:
Phase별 영향 전파 매트릭스:
변경 출발점 직접 영향 간접 영향 검증 필요
──────────────────────────────────────────────────────────
Phase 0 설정 → 1~8 전체 - 컨벤션 일관성
Phase 1 아이디어 → 2 기획 → 3~8 PRD, 스코프 재검토
Phase 2 기획 → 3 설계, 4 디자인 → 5 구현, 7 QA 유저스토리, KPI, 인수테스트
Phase 3 설계 → 4 디자인, 5 구현 → 6 인프라, 7 QA API, 데이터모델, 테스트
Phase 4 디자인 → 5 구현(프론트) → 7 QA 인터랙션 명세, UI 테스트
Phase 5 구현 → 6 인프라, 7 QA → 8 운영 빌드, 배포, 테스트
Phase 6 인프라 → 7 QA → 8 운영 배포 파이프라인, 모니터링
Phase 7 QA → 8 운영 - 릴리즈 기준
구체적으로 어떤 파일/산출물이 영향받는지 리스트업한다:
## 영향 분석 결과
### 직접 영향 (반드시 수정 필요)
| # | 산출물 | 경로 | 영향 내용 | 수정 범위 |
|---|--------|------|----------|----------|
| 1 | | `.claude/XX-xxx/파일.md` | | 전면 수정 / 부분 수정 |
| 2 | | | | |
### 간접 영향 (검토 필요)
| # | 산출물 | 경로 | 잠재 영향 | 검토 수준 |
|---|--------|------|----------|----------|
| 1 | | | | 확인만 / 수정 가능성 |
| 2 | | | | |
### 코드 영향
| # | 파일/모듈 | 영향 내용 | 수정 규모 |
|---|----------|----------|----------|
| 1 | | | S / M / L / XL |
| 2 | | | |
### 테스트 영향
| # | 테스트 파일 | 영향 | 조치 |
|---|-----------|------|------|
| 1 | | 수정 필요 / 추가 필요 / 삭제 | |
| 2 | | | |
변경의 전체 위험도를 평가한다:
| 평가 항목 | 점수 (1-5) | 가중치 | 설명 |
|---|---|---|---|
| 영향 범위 | 30% | 영향받는 Phase 수 | |
| 수정 규모 | 25% | 변경해야 할 산출물/코드 양 | |
| 복잡도 | 20% | 변경의 기술적 난이도 | |
| 회귀 리스크 | 15% | 기존 기능 깨질 가능성 | |
| 일정 영향 | 10% | 일정 지연 가능성 |
위험도 등급:
위험도에 따른 변경 실행 전략:
Low 위험도:
변경 실행 → 관련 산출물 업데이트 → sync-check → 완료
Medium 위험도:
영향 분석 공유 → 사용자 승인 → 변경 실행 → 산출물 업데이트 → sync-check → 테스트 재실행 → 완료
High 위험도:
영향 분석 공유 → 사용자 승인 → 실행계획 수립 (governance) → 단계적 변경 → 각 단계 재검증 → 전체 sync-check → 회귀 테스트 → 완료