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