개발 계획 (Development Planning)
언어/플랫폼에 무관하게 적용되는 소프트웨어 개발 계획 방법론.
요구사항 인터뷰
구현 전 다음 질문으로 목표를 명확히 한다:
- What: 무엇을 구현/변경하는가?
- Why: 왜 필요한가? 해결하려는 문제는?
- How: 선호하는 접근 방식이 있는가?
- Success criteria: 언제 완료된 것으로 보는가?
추측하지 말고, 모호하면 사용자에게 확인한다.
필수 정보 수집
기술 컨텍스트
- 언어: 단일 언어 또는 하이브리드
- 프레임워크: 사용 중인 UI/백엔드 프레임워크
- 아키텍처 패턴: MVVM, Clean, MVC, 레이어드 등
- 의존성 관리: package.json, Package.swift, requirements.txt, build.gradle 등
프로젝트 제약
- 버전 요구사항: 런타임/빌드 타겟
- 라이브러리 가용성: 사용 가능한 외부 의존성
- 팀 규모: 협업 범위
기존 패턴
- 유사 기능이 어떻게 구현되어 있는가?
- 네이밍 컨벤션, 파일 구조
- 테스트 패턴
코드베이스 검색 전략
병렬 검색
Grep, SemanticSearch, Glob를 동시에 활용한다:
- SemanticSearch: "이 기능이 어떻게 작동하는가?", "유사한 구현이 어디에 있는가?"
- Grep: 정확한 타입명, 메서드명, import 관계
- Glob: 특정 패턴의 파일 목록 (예: Repository, ViewModel)
검색 대상
- 유사 기능: 참고할 기존 구현
- 네이밍 컨벤션: 클래스/함수/파일명 규칙
- 아키텍처 패턴: 레이어 구조, 의존성 방향
- 테스트 패턴: 기존 테스트 위치와 구조
결과 해석
- 검색 결과가 없으면 해당 패턴이 없을 수 있음 (추측 금지)
- 여러 파일이 나오면 의존성 그래프를 그려 영향 범위 파악
- 기존 코드 스타일을 따라 일관성 유지
아키텍처 패턴별 분석
MVVM
- 확인: Model, View, ViewModel 분리
- 신규 코드 위치: 해당 Feature의 ViewModel, View
- 수정 대상: 상태 관리, 바인딩
Clean Architecture
- 확인: Domain, Data, Presentation 레이어
- 신규 코드 위치: UseCase는 Domain, Repository 구현은 Data, UI는 Presentation
- 수정 대상: 의존성 방향 (Domain → Data)
MVC
- 확인: Model, View, Controller 분리
- 신규 코드 위치: Controller가 비대해지지 않도록 주의
- 수정 대상: Controller 내 로직 분리
레이어드
- 확인: 계층별 폴더 구조
- 신규 코드 위치: 해당 계층의 기존 패턴 따라
- 수정 대상: 상위 계층이 하위 계층에 직접 의존하지 않도록
영향도 평가 매트릭스
| 항목 |
내용 |
확인 방법 |
| 직접 변경 |
수정/추가/삭제할 파일 |
Grep으로 참조 추적 |
| 간접 영향 |
의존하는 모듈, 호출하는 코드 |
SemanticSearch, import 분석 |
| Breaking change |
API 변경, 시그니처 변경 |
사용처 전체 검색 |
| 리스크 |
예상치 못한 영향 가능 영역 |
경계 모듈, 외부 연동 |
구현 계획 템플릿
목표 (Goal)
- 명확히 정의된 달성 목표
영향 분석 (Impact)
- 직접 변경 대상
- 간접 영향 범위
- Breaking change 여부
단계 (Steps)
1. [단계명] - [의존성] - [검증 방법]
2. ...
리스크 (Risks)
- 예상 리스크와 대응 방안
검증 계획 (Verification)
- 어떻게 완료 여부를 확인하는가
원칙
- 추측 금지: 코드베이스 검색으로 확인한다.
- 병렬 탐색: Grep, SemanticSearch, Glob 등을 동시에 활용한다.
- 기존 패턴 존중: 새 패턴을 만들지 않고 기존 패턴을 따른다.
- 단계별 검증: 각 단계에 검증 수단을 포함한다.
- 선제적 리스크 식별: 구현 전에 리스크를 정리한다.
피해야 할 안티패턴
- 코드베이스 검색 없이 구현 시작
- 기존 패턴이 있는데 새 패턴 도입
- 검증 단계 생략
- 범위 과소 평가
- "이 패턴일 것이다" 추정 (실제 분석으로 확인)
- "이 라이브러리를 쓴다" 추정 (의존성 파일 확인)
검증 체크리스트
□ What/Why/How/Success criteria가 명확한가?
□ 유사 기능/패턴이 코드베이스에 있는가?
□ 기존 아키텍처/컨벤션을 따르는가?
□ 직접/간접 영향 범위를 평가했는가?
□ 각 단계에 검증 방법이 있는가?
□ 리스크와 대응 방안을 정리했는가?
□ 참조할 모든 타입이 존재하는가?
□ import/의존성 경로가 유효한가?
□ 메서드 시그니처가 일치하는가?
□ 완전성: 필요한 모든 정보가 수집되었는가?
□ 정확성: 수집된 정보가 실제 코드베이스와 일치하는가?
□ 실현 가능성: 계획이 현실적으로 실행 가능한가?
□ 일관성: 기존 코드 스타일과 일관성이 있는가?
1---2name: planning-173description: 새 기능 계획, 리팩토링, 코드베이스 구조 분석 시 사용하는 개발 계획 방법론. Use when planning new features, refactoring, or analyzing codebase structure before implementation.4---5
6# 개발 계획 (Development Planning)
7
8언어/플랫폼에 무관하게 적용되는 소프트웨어 개발 계획 방법론.
9
10## 요구사항 인터뷰
11
12구현 전 다음 질문으로 목표를 명확히 한다:
13
14- What: 무엇을 구현/변경하는가?
15- Why: 왜 필요한가? 해결하려는 문제는?
16- How: 선호하는 접근 방식이 있는가?
17- Success criteria: 언제 완료된 것으로 보는가?
18
19추측하지 말고, 모호하면 사용자에게 확인한다.
20
21## 필수 정보 수집
22
23### 기술 컨텍스트
24- 언어: 단일 언어 또는 하이브리드
25- 프레임워크: 사용 중인 UI/백엔드 프레임워크
26- 아키텍처 패턴: MVVM, Clean, MVC, 레이어드 등
27- 의존성 관리: package.json, Package.swift, requirements.txt, build.gradle 등
28
29### 프로젝트 제약
30- 버전 요구사항: 런타임/빌드 타겟
31- 라이브러리 가용성: 사용 가능한 외부 의존성
32- 팀 규모: 협업 범위
33
34### 기존 패턴
35- 유사 기능이 어떻게 구현되어 있는가?
36- 네이밍 컨벤션, 파일 구조
37- 테스트 패턴
38
39## 코드베이스 검색 전략
40
41### 병렬 검색
42Grep, SemanticSearch, Glob를 동시에 활용한다:
43
44- SemanticSearch: "이 기능이 어떻게 작동하는가?", "유사한 구현이 어디에 있는가?"
45- Grep: 정확한 타입명, 메서드명, import 관계
46- Glob: 특정 패턴의 파일 목록 (예: *Repository*, *ViewModel*)
47
48### 검색 대상
49- 유사 기능: 참고할 기존 구현
50- 네이밍 컨벤션: 클래스/함수/파일명 규칙
51- 아키텍처 패턴: 레이어 구조, 의존성 방향
52- 테스트 패턴: 기존 테스트 위치와 구조
53
54### 결과 해석
55- 검색 결과가 없으면 해당 패턴이 없을 수 있음 (추측 금지)
56- 여러 파일이 나오면 의존성 그래프를 그려 영향 범위 파악
57- 기존 코드 스타일을 따라 일관성 유지
58
59## 아키텍처 패턴별 분석
60
61### MVVM
62- 확인: Model, View, ViewModel 분리
63- 신규 코드 위치: 해당 Feature의 ViewModel, View
64- 수정 대상: 상태 관리, 바인딩
65
66### Clean Architecture
67- 확인: Domain, Data, Presentation 레이어
68- 신규 코드 위치: UseCase는 Domain, Repository 구현은 Data, UI는 Presentation
69- 수정 대상: 의존성 방향 (Domain → Data)
70
71### MVC
72- 확인: Model, View, Controller 분리
73- 신규 코드 위치: Controller가 비대해지지 않도록 주의
74- 수정 대상: Controller 내 로직 분리
75
76### 레이어드
77- 확인: 계층별 폴더 구조
78- 신규 코드 위치: 해당 계층의 기존 패턴 따라
79- 수정 대상: 상위 계층이 하위 계층에 직접 의존하지 않도록
80
81## 영향도 평가 매트릭스
82
83| 항목 | 내용 | 확인 방법 |
84|------|------|----------|
85| 직접 변경 | 수정/추가/삭제할 파일 | Grep으로 참조 추적 |
86| 간접 영향 | 의존하는 모듈, 호출하는 코드 | SemanticSearch, import 분석 |
87| Breaking change | API 변경, 시그니처 변경 | 사용처 전체 검색 |
88| 리스크 | 예상치 못한 영향 가능 영역 | 경계 모듈, 외부 연동 |
89
90## 구현 계획 템플릿
91
92```
93목표 (Goal)
94 - 명확히 정의된 달성 목표
95
96영향 분석 (Impact)
97 - 직접 변경 대상
98 - 간접 영향 범위
99 - Breaking change 여부
100
101단계 (Steps)
102 1. [단계명] - [의존성] - [검증 방법]
103 2. ...
104
105리스크 (Risks)
106 - 예상 리스크와 대응 방안
107
108검증 계획 (Verification)
109 - 어떻게 완료 여부를 확인하는가
110```
111
112## 원칙
113
1141. 추측 금지: 코드베이스 검색으로 확인한다.
1152. 병렬 탐색: Grep, SemanticSearch, Glob 등을 동시에 활용한다.
1163. 기존 패턴 존중: 새 패턴을 만들지 않고 기존 패턴을 따른다.
1174. 단계별 검증: 각 단계에 검증 수단을 포함한다.
1185. 선제적 리스크 식별: 구현 전에 리스크를 정리한다.
119
120## 피해야 할 안티패턴
121
122- 코드베이스 검색 없이 구현 시작
123- 기존 패턴이 있는데 새 패턴 도입
124- 검증 단계 생략
125- 범위 과소 평가
126- "이 패턴일 것이다" 추정 (실제 분석으로 확인)
127- "이 라이브러리를 쓴다" 추정 (의존성 파일 확인)
128
129## 검증 체크리스트
130
131```
132□ What/Why/How/Success criteria가 명확한가?
133□ 유사 기능/패턴이 코드베이스에 있는가?
134□ 기존 아키텍처/컨벤션을 따르는가?
135□ 직접/간접 영향 범위를 평가했는가?
136□ 각 단계에 검증 방법이 있는가?
137□ 리스크와 대응 방안을 정리했는가?
138□ 참조할 모든 타입이 존재하는가?
139□ import/의존성 경로가 유효한가?
140□ 메서드 시그니처가 일치하는가?
141□ 완전성: 필요한 모든 정보가 수집되었는가?
142□ 정확성: 수집된 정보가 실제 코드베이스와 일치하는가?
143□ 실현 가능성: 계획이 현실적으로 실행 가능한가?
144□ 일관성: 기존 코드 스타일과 일관성이 있는가?
145```
majiayu000