Prompt

문제

프롬프트를 매번 처음부터 새로 씁니다. 검증 기준, 계획 저장 위치, 위임 방식을 그때그때 즉흥적으로 정합니다.

예시

1. 먼저 캐묻게 시키기

큰 작업은 바로 시작시키지 않습니다. 설계가 갈리는 지점을 모델이 먼저 물어보게 만듭니다.

<하려는 것을 한두 문장으로>

바로 시작하지 마세요. 먼저 저를 인터뷰해 주세요.
기술 구현, 엣지 케이스, 트레이드오프, 제가 놓쳤을 만한 것을 물으세요.
뻔한 질문은 빼고, 답에 따라 설계가 실제로 달라지는 것만 물으세요.
한 번에 하나씩 물어보세요.

다 물어본 뒤에 docs/plans/<날짜>-<주제>.md 에 사양을 쓰세요.

언제: 여러 파일을 건드리거나, 접근 방식이 불확실하거나, 익숙하지 않은 코드를 고칠 때 씁니다. diff를 한 문장으로 설명할 수 있으면 건너뜁니다.

바꿀 것: 마지막 줄의 사양 파일 경로입니다. 인터뷰가 끝나면 /clear하고 새 세션에서 그 파일을 읽혀 구현합니다. 이렇게 나누는 이유는 Feature 개발에서 다룹니다.

왜 되는가: 모델은 의도를 추론할 수는 있지만 읽어낼 수는 없습니다. 답을 지어내는 대신 묻게 만들면, 어긋난 전제 위에 코드가 쌓이는 것을 시작 시점에 막습니다. 질문 몇 개가 나중에 되돌리는 비용보다 쌉니다.

2. 검증 명령을 프롬프트 안에 넣기

<작업 지시>

완료 기준: <검증 가능한 결과>. "동작하게"로 쓰지 않는다.
범위: 포함 — <포함할 것>. 제외 — <제외할 것>.
구현 전에 만들 파일과 고칠 파일 목록을 먼저 보여줘.
각 단계가 끝나면 <검증 명령>을 실행하고 출력을 보여줘.

언제: 계획 파일 없이 바로 구현시키면서도 완료 판정을 사람의 눈에 맡기지 않을 때 씁니다. 바꿀 것: <검증 명령>에는 이 작업에 맞는 lint·test·build 명령을 넣습니다. <포함>과 <제외>는 한 단락으로 짧게 씁니다.

3. 계획을 파일로 쓰게 시키기

탐색 세션에서 씁니다.

<코드베이스 영역>을 읽고 <파악할 것>을 정리해서
docs/plans/<날짜>-<주제>.md 에 써줘.

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

/clear한 뒤 구현 세션에서 씁니다.

docs/plans/<날짜>-<주제>.md 를 읽고 구현해줘.
각 단계 끝나면 계획에 적힌 확인 명령을 실행하고 출력을 보여줘.

언제: 기능 하나가 여러 파일에 걸치고, 탐색으로 두꺼워진 컨텍스트를 구현까지 끌고 가고 싶지 않을 때 씁니다. 플랜 모드 대신 파일을 쓰는 이유는 Feature 개발에서 다룹니다. 바꿀 것: 코드베이스 영역, 파악할 것, 날짜·주제, 확인 명령입니다.

4. 서브에이전트로 조사 위임하기

<조사할 범위>를 조사해줘. 파일을 읽거나 grep해도 되는데,
덤프하지 말고 결론만 정리해서 알려줘.

확인할 것:
- <질문 1>
- <질문 2>

원본 인용이 필요하면 파일 경로와 줄 번호만 남겨줘.

언제: 로그나 파일 덤프 같은 조사 결과물이 커서 부모 컨텍스트에 올리고 싶지 않을 때 씁니다. 위임하고 끝내지 않습니다. 결과가 부족하면 같은 서브에이전트에 후속 지시를 보냅니다. 바꿀 것: 조사할 범위, 확인할 것 목록입니다.

이유

각 틀에는 구조적인 이유가 있습니다.

검증 명령을 프롬프트에 박아 두면 완료 판정을 명령의 종료 코드나 출력이 맡습니다. “동작하게 해줘”만 쓰면 무엇이 되면 끝인지가 모델과 사람 사이에서 암묵적으로만 합의됩니다. 그 합의는 어긋나기 쉽습니다.

계획을 파일로 쓰게 하면 탐색 중 두꺼워진 컨텍스트를 구현 세션까지 끌고 가지 않아도 됩니다. 탐색과 구현을 /clear로 분리하고 그 사이를 파일 하나로 이으면, 구현 세션은 계획을 읽는 것만으로 시작할 수 있습니다.

서브에이전트에 조사를 위임하면 로그나 파일 덤프처럼 노이즈가 큰 중간 산출물이 부모 컨텍스트에 올라오지 않습니다. 결론과 근거 경로만 받으면 되는 작업일수록 이 이득이 큽니다.

하지 말 것

“동작하게 해줘”만 쓰기. 완료 판정 기준이 없으면 검증 루프가 사람에게 돌아옵니다.

긴 조사 결과를 메시지로 받으려 하기. 보고가 길면 도중에 잘리기 쉽습니다. 처음부터 파일로 쓰게 시킵니다.

라이브러리 채택을 Yes/No로 묻기. 활성도·라이선스 비교는 비교적 정확하게 답합니다. 무료/유료 경계나 버전 프레이밍에서는 낙관적으로 틀리기 쉽습니다. “우리 카탈로그 M종 중 N종은 무료 범위로 조달, 나머지는 자체” 형태로 답하게 하는 편이 낫습니다.