프롬프팅 최고수 가 되는 길 — 9개 슬롯, 그리고 상위 0.1% 와 1% 의 차이
좋은 프롬프트 는 이렇게 생겼다 — 역할, 상황, 목적, 독자, 요구사항, 제한, 출력 형식, 답변 기준. 아홉 개 슬롯 을 채우는 빈칸 템플릿.
![프롬프트 템플릿 — 너는 [역할], 현재 상황은 [배경], 목적은 [원하는 결과], 대상 독자는 [누가], 요구사항 1·2·3, 제한사항, 출력 형식, 좋은 답변 기준](/assets/images/prompt-template-9-slots.jpg)
그런데 이 템플릿 을 아는 것 과 10점 만점 에 10점 으로 채우는 것 은 전혀 다른 일 이다. 앞선 두 글(행동강령 을 .md 로 · 하네스 4프레임) 이 에이전트 하네스 를 다뤘다면, 이 글 은 그 축소판 인 한 번의 프롬프트 를 최고수 처럼 쓰는 법 이다. 그리고 마지막 에, 상위 0.1% 와 1% 가 여기서 어디서 갈리는지 를 비교 한다.
1. 아홉 슬롯 — 6점 채움 vs 10점 채움
같은 슬롯 도 채우는 수준 이 다르다. 초보 는 비우지 않는 데 만족 하고, 고수 는 모델 의 실패 를 미리 막게 채운다.
| 슬롯 | 6점 (그냥 채움) | 10점 (고수의 채움) |
|---|---|---|
| 역할 | “너는 개발자다” | “너는 결제 정합성 을 10년 다룬 백엔드 시니어 다” — 관점 과 편향 까지 고정 |
| 상황 | “코드 리뷰 중” | “MSA 3개, 배포 직후 5XX 급증, 롤백 30분 내 결정 필요” — 제약 이 드러남 |
| 목적 | “개선 해줘” | “p95 를 500→200ms 로. 성공/실패 를 숫자 로 판정 가능하게” |
| 독자 | (비움) | “비개발 PM 이 읽는다” vs “온콜 엔지니어 가 읽는다” — 같은 답, 다른 프레이밍 |
| 요구사항 | “잘 정리 해줘” | “① 원인 가설 3개 ② 각 검증법 ③ 즉시 조치” — 셀 수 있게 |
| 제한사항 | (비움) | “추측 금지, 3문단 이내, 코드 없이, 반드시 롤백안 포함” — 실패 경로 차단 |
| 출력 형식 | “표로” | “① 요약 1줄 ② 원인표 ③ 조치 체크리스트” — 생성 을 구조 로 구속 |
| 답변 기준 | (비움) | “숫자 근거 있나 · 반증 가능한가 · 지금 실행 가능한가” — 모델 이 자가 채점 |
| 빈칸 삭제 | [역할] 남겨둠 |
모든 [ ] 를 실제 값 으로 — 남은 빈칸 = 모델 의 추측 = 품질 하락 |
가장 저평가 된 슬롯 은 세 개 다 — 독자 · 제한사항 · 답변 기준. 초보 는 이 셋 을 비우고, 고수 는 여기 서 점수 를 딴다.
- 독자 를 정하면 같은 내용 도 깊이 와 어휘 가 달라진다.
- 제한사항 은 앞 글 의 금지(Iron Law) 다 — 모델 이 갈 나쁜 길 을 미리 막는다.
- 답변 기준 은 프롬프트 안에 채점표 를 심는 것. 모델 이 스스로 검수 하게 만든다.
2. “빈칸 삭제” 가 왜 별도 규율 인가
템플릿 에서 가장 쉽게 빠지는 함정 은 [ ] 를 남겨두는 것 이다. 너는 [역할]이다 를 그대로 보내면, 모델 은 역할 을 추측 한다. 그리고 추측 은 언제나 평균 으로 회귀 한다 — 가장 무난하고, 가장 밋밋한 답.
빈칸 을 남기는 만큼 결정 권 을 모델 에게 넘긴 것 이다. 최고수 는 넘길 것 과 잡을 것 을 의식적 으로 나눈다.
물론 일부러 비우는 경우 도 있다 — 창의 영역, 문장 표현 처럼 모델 에게 맡기는 게 나은 곳. 하지만 그건 “안 채운” 게 아니라 “열어둔” 것 이다. 둘 의 차이 는 의도 다. 최고수 의 프롬프트 엔 실수로 남은 빈칸 이 없다.
3. 상위 1% vs 상위 0.1% — 어디서 갈리나
여기 서부터 가 본론 이다. 상위 1% 는 위 아홉 슬롯 을 잘 채운다. 상위 0.1% 는 슬롯 을 채우는 사람 이 아니라, 슬롯 자체 를 설계 하는 사람 이다.
| 관점 | 상위 1% (능숙한 사용자) | 상위 0.1% (설계자) |
|---|---|---|
| 무엇 을 쓰나 | 좋은 프롬프트 를 쓴다 | 재사용 가능한 하네스 를 쓴다 (버전 관리·테스트) |
| 모델관 | “지시 하면 따른다” | “실패 하는 방향 이 있다” — 실패 를 먼저 상상 |
| 제한사항 | 하지 말 것 을 나열 | 모델 이 합리화 할 구멍 을 미리 막음 (rationalization 대응) |
| 답변 기준 | 가끔 넣음 | 항상 넣음 — 프롬프트 를 평가 설계 로 봄 |
| 구체성 | 전부 최대한 자세히 | 잠글 곳 은 과하게, 열 곳 은 비움 — 선택적 구속 |
| 형식 vs 흐름 | 다 프롬프트 로 | 규칙·형식 은 프롬프트, 순서·상태·재시도 는 코드 로 뺌 |
| 반복 | 매번 새로 씀 | 실패 시나리오 로 템플릿 을 진화 (RED→GREEN→REFACTOR) |
| 예시 | 규칙 을 여러 개 | 탁월한 예시 하나 가 규칙 열 개 를 이김 |
핵심 차이 를 한 줄 로 요약 하면:
상위 1% 는 모델 에게 “무엇 을 하라” 고 말한다. 상위 0.1% 는 모델 이 “어디서 틀릴지” 를 먼저 설계 한다.
1% 는 과업 을 본다 — 원하는 결과 를 정확히 묘사 하면 좋은 답 이 온다고 믿는다. 맞는 말 이다, 대개는. 0.1% 는 실패 모드 를 본다 — 이 모델 이 이 과업 에서 어디서 밋밋 해지고, 어디서 추측 하고, 어디서 형식 을 흘릴지 를 안다. 그래서 그 지점 마다 슬롯 을 하나 씩 세운다. 제한사항 은 밋밋 함 을 막으려고, 답변 기준 은 자가 검증 을 시키려고, 출력 형식 은 흐름 을 잡으려고.
또 하나 — 0.1% 는 프롬프트 에 넣지 말아야 할 것 을 안다. 순서·상태·재시도 같은 결정적 흐름 은 산문 으로 적으면 반드시 샌다. 그건 코드/툴 로 뺀다. 최고수 의 프롬프트 가 오히려 짧은 이유 다 — 잠글 것 만 잠그고, 나머지 는 다른 층 에 맡기니까.
4. 그래서 10점 으로 가는 길
정리 하면, 프롬프팅 의 10점 은 더 길게 쓰는 것 이 아니다.
- 아홉 슬롯 을 다 의식 한다 — 특히 저평가 된 독자·제한·답변기준.
- 빈칸 을 남기지 않는다 — 열어둘 곳 은 의도적 으로, 나머지 는 값 으로.
- 실패 를 먼저 상상 한다 — 이 모델 이 어디서 틀릴지 를 슬롯 으로 막는다.
- 잠글 것 과 맡길 것 을 나눈다 — 규칙·형식 은 프롬프트, 흐름·상태 는 코드.
- 한 번 쓰고 버리지 않는다 — 잘 된 프롬프트 는 템플릿 으로 남겨 진화 시킨다.
프롬프팅 의 최고수 는 결국 프롬프트 를 잘 쓰는 사람 이 아니라, 모델 을 잘 아는 사람 이다. 아홉 슬롯 은 그 앎 을 담는 그릇 일 뿐 이다. 그릇 을 외우는 데서 1% 가 되고, 무엇 을 담을지 를 아는 데서 0.1% 가 된다.
좋은 질문 을 하는 사람 이 좋은 답 을 하는 기계 를 이긴다 — 그리고 최고수 는, 그 기계 가 어디서 나쁜 답 을 할지 까지 안다.