# 좋은 지시의 네 가지 요소
> **이 장에서 배우는 것**
> [「AI가 처음이라면」의 요령](/guide/ai-how-to-ask)을 체계로 정리합니다. 네 가지 요소가
> 무엇이고, 각각이 빠졌을 때 정확히 어떤 방식으로 어긋나는지.
## 왜 체계가 필요한가
「AI가 처음이라면」에서 "구체적으로 쓰라", "상황을 알려주라"는 요령을 봤습니다. 개인이 쓸
때는 그걸로 충분합니다.
그런데 **에이전트에게 맡기거나 여러 사람이 같은 작업을 반복할 때**는 요령으로
부족합니다. [에이전트는 틀린 방향으로도 열심히 가고](/guide/ai-agent-basics),
사람마다 지시가 달라지면 결과도 달라집니다.
그래서 **빠진 게 없는지 확인할 수 있는 목록**이 필요합니다.
## 네 가지 요소
| 요소 | 답하는 질문 | 빠지면 |
|---|---|---|
| **목표** | 무엇을 만드나 | 엉뚱한 것을 만듦 |
| **범위** | 어디까지 손대나 | 건드리면 안 될 곳을 건드림 |
| **완료 조건** | 됐다는 걸 어떻게 아나 | 끝났는지 판단이 갈림 |
| **맥락** | 이미 무엇이 있나 | 있는 걸 다시 만듦 |
## 하나씩 보기
### 1. 목표 — 무엇을 만드나
가장 당연해 보이는데 가장 자주 애매합니다.
```
✗ "로그인을 개선해줘"
→ '개선'이 무엇인지가 안 정해짐. 속도? 보안? 화면?
✓ "로그인 실패 시 아무 메시지도 안 나오는 문제를 고쳐줘"
→ 무엇이 문제이고 무엇이 해결인지 명확
```
**요령**: 목표를 "무엇을 하고 싶다"가 아니라 **"지금 무엇이 문제다"**로 적으면
대개 명확해집니다.
### 2. 범위 — 어디까지 손대나
이게 빠지면 **좋은 의도로 사고가 납니다.** 개선하라고 했으니 관련 있어 보이는
것까지 손댑니다.
```
✓ "인증 로직 자체는 바꾸지 말고 화면 메시지만 수정할 것"
```
범위는 **하지 말 것**으로 적는 게 효과적입니다. 할 것을 다 적기는 어렵지만
하면 안 되는 것은 몇 개 안 됩니다.
### 3. 완료 조건 — 됐다는 걸 어떻게 아나
가장 자주 빠지고, 빠졌을 때 가장 나중에 티가 납니다.
```
✗ "잘 되게 해줘"
✓ "완료 기준: 비밀번호 틀림 / 없는 계정 / 잠긴 계정
세 경우 각각의 테스트가 통과할 것"
```
**완료 조건이 없으면 "됐다"의 판정을 사람이 매번 해야 합니다.** 그러면 자동화의
이득이 그만큼 깎입니다.
> 이 요소는 조직 차원으로 올라가면 그대로
> [평가(Evals)](/guide/ai-evaluation)가 됩니다. 개인은 눈으로 보고 판정하지만
> 조직은 기준이 있어야 합니다.
### 4. 맥락 — 이미 무엇이 있나
없으면 **바퀴를 다시 발명합니다.**
```
✓ "쿠폰 모델은 이미 Coupon 클래스에 있고, 할인 계산은
PriceCalculator 를 씁니다. 새로 만들지 말고 이걸 쓰세요."
```
맥락에는 **하지 않아도 되는 이유**도 포함됩니다. "이건 이미 해봤는데 안 됐다"를
알려주면 그 방향을 지웁니다.
## 네 요소를 다 넣으면
```
[목표]
로그인 실패 시 아무 메시지도 안 나오는 문제를 고쳐주세요.
[범위]
- 인증 로직은 바꾸지 말 것
- 화면에 표시되는 메시지만 수정
[완료 조건]
- 비밀번호 틀림 / 없는 계정 / 잠긴 계정을 구분해 표시
- 단, 어느 쪽이 틀렸는지는 노출하지 말 것 (계정 존재 여부 유출 방지)
- 세 경우 각각의 테스트가 통과할 것
[맥락]
- 메시지 문구는 messages/ko.json 에서 관리합니다
- 예전에 계정 존재 여부를 노출해서 보안 지적을 받은 적이 있습니다
```
길어 보이지만 **쓰는 데 2분**이고, 애매하게 줘서 세 번 다시 시키는 것보다
빠릅니다.
## 요소별 점검표
지시를 보내기 전에 확인하세요.
```
□ 목표 무엇이 문제이고 무엇이 해결인지 적었나
□ 범위 건드리면 안 되는 것을 적었나
□ 완료 조건 됐다는 걸 판정할 방법이 있나
□ 맥락 이미 있는 것, 이미 실패한 것을 알려줬나
```
**네 칸이 다 찼는데도 결과가 나쁘면** 그때는 다른 문제입니다 — 모델의 한계이거나
[컨텍스트가 밀려난 것](/guide/ai-context-overflow)일 수 있습니다.
## 자주 하는 오해
### "매번 이렇게 길게 쓰라는 건가?"
아닙니다. **반복되는 작업**과 **에이전트에 맡기는 작업**에 씁니다. 일회성 질문은
「AI가 처음이라면」의 요령으로 충분합니다.
반복 작업이라면 이 형식을 **템플릿으로 저장**해두고 재사용하는 게 실무적입니다.
[서브 에이전트](/guide/cn-agents-intro)의 지시문이 정확히 그 용도입니다.
### "완료 조건을 어떻게 미리 정하나?"
정할 수 없으면 **그 작업은 아직 맡길 준비가 안 된 것**입니다. 사람이 해도 "됐다"를
판정 못 하는 일을 AI에게 맡기면 판정은 영원히 사람 몫으로 남습니다.
---
## 확인
**1. 범위를 "하지 말 것"으로 적는 게 효과적인 이유는?**
답
**할 것을 다 적기는 어렵지만 하면 안 되는 것은 몇 개 안 되기 때문**입니다.
범위가 없으면 좋은 의도로 관련 있어 보이는 것까지 손대서 사고가 납니다.
**2. 완료 조건이 빠지면 자동화의 이득이 왜 깎입니까?**
답
**"됐다"의 판정을 사람이 매번 해야 하기 때문**입니다. 만드는 건 자동인데 판정이
수동이면 그만큼 사람 시간이 남습니다.
**3. 네 요소를 다 채웠는데 결과가 나쁘면 무엇을 의심합니까?**
답
모델의 한계이거나 **컨텍스트가 밀려난 것**입니다. 지시 자체의 문제는 아니므로,
새 대화로 옮기거나 작업을 더 쪼개는 쪽을 봐야 합니다.
---
이제 직접 고쳐 써보는 실습입니다 → [지시 고쳐쓰기](/guide/ai-rewriting-prompts)