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