Feature 개발

문제

기능 하나를 추가해야 합니다. 바로 시키면 엉뚱한 것을 만들고, 계획부터 시키면 그 계획이 대화와 함께 사라집니다.

1. 요구사항
2. Codebase 탐색
3. 계획을 파일로
4. 구현
5. Test / Build
6. Review
7. Commit

추천

계획을 플랜 모드 안에 두지 말고 레포에 파일로 남깁니다. 탐색과 계획은 한 세션에서 하고, 구현은 그 파일을 읽는 새 세션에서 합니다.

이유

공식 가이드는 플랜 모드로 탐색과 실행을 분리하라고 권장합니다. 분리 자체는 옳은 원칙입니다. 다만 계획을 어디에 남기느냐에 따라 그 효과가 달라집니다. 플랜 모드 대화 안에 남기는 대신 파일로 옮기면 세 가지가 달라집니다.

계획이 남습니다. 플랜 모드의 계획은 그 세션의 컨텍스트이고, 세션이 끝나면 사라집니다. 파일은 다음 주에도 읽을 수 있고, 리뷰어도 읽을 수 있고, 구현이 계획과 어긋났는지 대조할 수 있습니다.

계획을 고칠 수 있습니다. 대화 속 계획을 고치려면 대화를 더 이어가야 하고, 그러면 컨텍스트가 늘어납니다. 파일은 편집하면 됩니다.

계획이 파일에 있으면 깨끗한 컨텍스트에서 구현할 수 있습니다. 탐색 세션은 코드베이스를 읽느라 컨텍스트가 이미 두껍습니다. 그 상태로 바로 구현에 들어가면 남은 여유가 적습니다. 파일로 남겨두면 새 세션이 그 파일만 읽고 시작할 수 있습니다. 공식 가이드도 스펙을 쓴 뒤 “새 세션을 시작해서 실행하라”고 같은 취지를 말합니다.

예시

탐색 세션에서 시키는 것:

src/search 아래를 읽고 결과 목록이 어떻게 렌더링되는지 파악해줘.
기존 컴포넌트가 어떤 패턴을 따르는지, 새 컴포넌트를 넣으려면
어디를 건드려야 하는지 정리해서 docs/plans/2026-09-05-search-facet.md 에 써줘.

계획에는 이걸 포함해:
- 만들 파일과 고칠 파일 목록
- 각 단계가 끝났는지 확인할 명령
- 이번 범위가 아닌 것

그다음 /clear하고, 새 세션에서:

docs/plans/2026-09-05-search-facet.md 를 읽고 구현해줘.
각 단계 끝나면 계획에 적힌 확인 명령을 실행하고 출력을 보여줘.

계획 파일에 확인 명령을 반드시 넣습니다. 확인 명령이 없으면 “완료했습니다”가 유일한 신호가 되고, 검증은 사람 몫으로 돌아옵니다.

범위가 크거나 접근 방식이 불확실하면, 탐색을 시키기 전에 모델이 먼저 캐묻게 만드는 단계를 하나 더 둡니다. 어긋난 전제 위에 계획이 세워지는 것을 시작 시점에 막습니다. Prompt 레시피의 첫 템플릿이 그 형태입니다.

하지 말 것

계획을 세우게 하고 그 세션에서 바로 구현시키기. 탐색으로 두꺼워진 컨텍스트를 그대로 안고 구현에 들어갑니다. 계획도 세션과 함께 사라집니다.

작은 변경에도 계획 파일을 만들기. 오타 수정이나 로그 한 줄 추가에는 계획이 오버헤드입니다. diff를 한 문장으로 설명할 수 있으면 계획 없이 바로 시킵니다.

확인 방법이 없는 계획. 단계는 있는데 “이 단계가 끝났는지 어떻게 아는가”가 없으면, 계획이 있어도 검증은 여전히 사람 몫입니다.