plan

name	plan
description	구현 전 설계 및 계획 수립 — 요구사항 분석, 설계 대안 비교, 구현 계획을 사용자와 정렬한다
user-invocable	true

Plan

구현을 시작하기 전에 요구사항을 분석하고, 설계 대안을 비교하고, 구현 계획을 수립한다. 사용자와 계획을 정렬한 후 구현을 진행한다.

1. 요구사항 분석

• 사용자의 요청을 읽고 핵심 목표와 제약을 정리한다.
• 인자가 전달되면 (/plan <task-description>) 해당 내용을 작업 설명으로 사용한다.
• 프로젝트의 architecture 문서, rules가 있으면 읽어서 현재 맥락을 파악한다.
• 관련된 기존 코드를 탐색하여 현재 구조와 패턴을 이해한다.

정리할 항목

• 목표: 이 작업이 달성해야 하는 것
• 제약: 건드리면 안 되는 것, 유지해야 하는 것
• 영향 범위: 변경이 미치는 파일/모듈 범위
• 불확실한 점: 추가 확인이 필요한 사항

2. 설계 대안 비교

변경이 단순하지 않을 때 (3개 이상의 파일 수정 또는 설계 판단이 필요한 경우), 실행 가능한 접근 방식을 2-3개 도출하고 비교한다.

각 대안에 대해:

• 핵심 아이디어 (1-2문장)
• 장점
• 단점 / 리스크
• 영향받는 파일/모듈

변경이 단순하면 이 단계를 건너뛰고 바로 구현 계획으로 넘어간다.

3. 구현 계획

선택한 접근 방식을 구체적인 작업 단위로 분해한다.

계획에 포함할 항목

• 작업 순서 (의존성 고려)
• 각 단계에서 변경할 파일/모듈
• 각 단계의 검증 방법 (테스트, 빌드)
• 예상되는 커밋 단위
• 새로 도입할 라이브러리가 있으면 후보를 조사하고, 선정 근거와 함께 문서에 확정한다 (dependencies.md "Library Selection" 참조)

계획 수립 시 원칙

• 의존되는 쪽을 먼저 구현한다.
• 각 단계가 끝나면 빌드와 테스트가 통과하는 상태여야 한다.

4. 사용자 확인

계획을 사용자에게 다음 형식으로 보고하고 구현 전 정렬한다.

목표 및 제약

(정리된 목표와 제약)

접근 방식

(선택한 방식과 이유. 대안이 있었으면 비교 요약)

구현 계획

(번호가 매겨진 단계별 목록)

불확실한 점

(추가 확인이 필요한 사항. 없으면 없음)

사용자가 계획을 승인하면 구현을 시작한다. 수정 요청이 있으면 계획을 조정한 후 재확인한다.