# Planning

> 새 기능 계획, 리팩토링, 코드베이스 구조 분석 시 사용하는 개발 계획 방법론. Use when planning new features, refactoring, or analyzing codebase structure before implementation.

- Skill: `majiayu000/planning-17` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds add majiayu000/planning-17`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/planning-17/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: majiayu000 (https://skillmd.com/u/majiayu000)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/majiayu000/planning-17

---


# 개발 계획 (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)
  - 어떻게 완료 여부를 확인하는가
```

## 원칙

1. 추측 금지: 코드베이스 검색으로 확인한다.
2. 병렬 탐색: Grep, SemanticSearch, Glob 등을 동시에 활용한다.
3. 기존 패턴 존중: 새 패턴을 만들지 않고 기존 패턴을 따른다.
4. 단계별 검증: 각 단계에 검증 수단을 포함한다.
5. 선제적 리스크 식별: 구현 전에 리스크를 정리한다.

## 피해야 할 안티패턴

- 코드베이스 검색 없이 구현 시작
- 기존 패턴이 있는데 새 패턴 도입
- 검증 단계 생략
- 범위 과소 평가
- "이 패턴일 것이다" 추정 (실제 분석으로 확인)
- "이 라이브러리를 쓴다" 추정 (의존성 파일 확인)

## 검증 체크리스트

```
□ What/Why/How/Success criteria가 명확한가?
□ 유사 기능/패턴이 코드베이스에 있는가?
□ 기존 아키텍처/컨벤션을 따르는가?
□ 직접/간접 영향 범위를 평가했는가?
□ 각 단계에 검증 방법이 있는가?
□ 리스크와 대응 방안을 정리했는가?
□ 참조할 모든 타입이 존재하는가?
□ import/의존성 경로가 유효한가?
□ 메서드 시그니처가 일치하는가?
□ 완전성: 필요한 모든 정보가 수집되었는가?
□ 정확성: 수집된 정보가 실제 코드베이스와 일치하는가?
□ 실현 가능성: 계획이 현실적으로 실행 가능한가?
□ 일관성: 기존 코드 스타일과 일관성이 있는가?
```