
부제: 목적·재료·형식·합격선만 적어도, 무엇을 고쳐야 할지 보여요
분명히 써 줬는데, 왜 이것만 나왔을까요
어제는 꽤 쓸 만했어요. 그래서 오늘도 같은 식으로 물었죠. “이 회의 내용 이메일로 정리해 줘.”
그런데 돌아온 건 길기만 하고 담당자도, 마감일도 없는 글이었어요. 화가 나기보다 당황스러웠어요. 제가 뭘 잘못 눌렀나 싶었거든요.
그런데 이건 실력 문제가 아니에요. 생성 결과는 원래 매번 조금씩 달라집니다. OpenAI 공식 문서도 생성이 비결정적이라서, 일관성은 문장 하나가 아니라 기법과 테스트로 만든다고 설명해요. 그러니까 “어제는 됐는데 오늘은 왜?”는 여러분 탓이 아니라 원래 그런 성질이에요.
문제는 다른 데 있었어요. 제 요청서에 빈칸이 있었던 거예요.

먼저, 오늘의 답부터
요청서에 네 칸을 적으세요. 목적 / 재료 / 형식 / 합격선. 그리고 한 번에 끝내지 말고, 세 번 안에 고치세요.
칸 이름과 개수는 ABNL이 정리한 틀이에요. 공식 문서의 표준 명칭은 아닙니다.
여기까지만 가져가도 오늘은 충분해요. 아래는 왜 그런지, 그리고 실제로 어떻게 바뀌는지예요.

세 회사가 다른 말을 하는 게 아니었어요
OpenAI, Anthropic, Google의 공식 프롬프트 문서를 나란히 놓고 봤어요. 용어는 다른데 말하는 건 같았어요.
| 공통 요소 | OpenAI | Anthropic | |
|---|---|---|---|
| 명확한 지시 | 효과적인 지시 작성 | 명확성 기법 | 명확·구체적인 지시 |
| 필요한 맥락 | 관련 맥락 제공 | XML 구조로 맥락 구분 | 맥락 제공 |
| 형식·예시 | 정답 예시, 입출력 예시 | 예시 기법 | 구체적인 예시 권장 |
| 기준·반복 | 비결정적이라 테스트 필요 | 성공 기준부터 정의 | 출발점일 뿐, 실험·개선 |
공통분모는 문서에 있고, 이걸 네 칸으로 묶은 건 ABNL이에요.

특히 눈에 띈 건 Anthropic 쪽이었어요. 프롬프트를 손보기 전에 성공 기준을 정하고, 그 기준을 실제로 시험할 방법을 갖추라고 해요. 대부분 이 순서를 반대로 해요. 일단 시키고, 나온 걸 보고, 마음에 안 들면 다시 시키죠. 그러면 뭐가 나아졌는지 판단할 기준이 없어요.
원본 전후 실습: 회의 메모를 후속 이메일로
실습 원문은 아래와 같아요. 실제 회의록이 아니라 가상으로 만든 정보예요. 회사 기밀이나 개인정보를 실습에 쓰지 마세요.
프로젝트 오로라 주간회의 출시 후보일: 9월 18일 민지: 제품 소개 문구 9월 10일까지 현우: FAQ 초안 9월 11일까지 결정: 베타 참여자에게 먼저 안내 미정: 최종 가격, 고객지원 운영시간
BEFORE — 평소 쓰던 요청
이 회의 내용을 이메일로 정리해 줘.
실제로 돌려본 결과예요.
제목: [프로젝트 오로라] 주간회의 내용 및 일정 공유
안녕하세요.
프로젝트 오로라 주간회의 내용을 아래와 같이 공유드립니다.
- 출시 후보일: 9월 18일
- 민지: 제품 소개 문구 작성 — 9월 10일까지
- 현우: FAQ 초안 작성 — 9월 11일까지
- 결정 사항: 베타 참여자에게 우선 안내
- 미정 사항: 최종 가격, 고객지원 운영시간
담당자분들께서는 일정에 맞춰 준비해 주시고, 미정 사항은 추후 확정되는 대로 공유 부탁드립니다.
감사합니다.
솔직히 말하면, 못 쓴 결과는 아니에요. 담당자도 날짜도 다 들어갔어요. 여기서 “그럼 됐네”라고 넘어가기 쉬운데, 문제는 다른 데 있어요.
- 메모를 옮겨 적은 것에 가까워요. 회의 메모의 여섯 줄이 그대로 여섯 줄 목록이 됐어요. 받는 사람이 다음에 뭘 해야 하는지는 여전히 각자 알아서 읽어야 해요.
- 결정된 것과 아직 안 정해진 게 같은 목록에 나란히 있어요. 눈으로는 구분이 안 돼요.
- 읽는 사람이 누구인지 정하지 않았어요. 그래서 문체도 길이도 이번엔 이렇게 나왔을 뿐, 다음에도 이렇게 나온다는 보장이 없어요.
- 무엇보다 이 결과가 통과인지 아닌지 판단할 기준이 없어요. 괜찮아 보인다는 느낌뿐이에요.
네 칸이 필요한 이유가 여기예요. 결과를 극적으로 바꾸려는 게 아니라, 결과를 판정 가능하게 만들려는 거예요.

AFTER — 네 칸을 채운 요청
아래 가상 회의 메모를 베타 출시 실무팀에 보낼 후속 이메일로 써 주세요.
[목적]
읽는 사람은 회의에 참석한 실무팀이에요.
담당자와 마감일을 다시 확인하게 하는 게 목적이에요.
[재료]
<메모> 안의 내용만 쓰세요.
메모에 없는 내용은 추측하지 말고 "메모에 없음"이라고 적어주세요.
[형식]
제목 1개와 본문을 써 주세요.
본문은 인사말 / 결정 사항 / 담당 업무 / 미정 사항 / 마무리 순서로,
500자 안팎의 해요체로 써 주세요.
[합격선]
민지와 현우의 업무와 날짜를 모두 포함하세요.
최종 가격과 고객지원 운영시간은 "미정"으로 표시하세요.
새로운 날짜·담당자·가격을 만들지 마세요.
이 세 가지가 안 지켜지면 실패로 볼게요.
<메모>
(여기에 위 회의 메모를 붙여 넣어요)
</메모>
같은 메모를, 이 요청서로 다시 돌린 결과예요.
제목: [프로젝트 오로라] 주간회의 결정 사항 및 담당 일정 확인
안녕하세요, 실무팀 여러분.
프로젝트 오로라 주간회의 후속 내용을 공유해요. 출시 후보일은 9월 18일이며, 베타 참여자에게 먼저 안내하기로 결정했어요.
담당 업무와 마감일을 다시 확인 부탁드려요. 민지는 제품 소개 문구를 9월 10일까지 준비하고, 현우는 FAQ 초안을 9월 11일까지 준비해요. 일정이나 업무 내용에 차이가 있다면 알려주세요.
미정 사항은 최종 가격과 고객지원 운영시간이에요. 두 항목의 담당자와 확정일은 메모에 없음으로 확인돼요.
각자 담당 업무와 마감일을 확인해 주시고, 수정할 내용이 있으면 회신 부탁드려요. 감사합니다.
바뀐 지점을 짚어볼게요.
<메모>태그로 지시와 재료를 물리적으로 갈랐어요. OpenAI 문서가 Markdown 헤더나 XML 태그로 지시와 맥락의 경계를 나누라고 안내하는 부분이에요.- 형식에 길이·구조·문체를 다 적었어요. 이게 없으면 매번 달라져요.
- 마지막 칸이 핵심이에요. “이게 안 되면 실패”라고 미리 적어두면, 나온 결과를 눈대중이 아니라 항목으로 채점할 수 있어요.

그런데 여기서 재미있는 걸 봤어요
똑같은 이 요청서를 서로 다른 AI 두 곳에 한 번씩 보내봤어요. 결과가 이렇게 갈렸어요.
| 첫 번째 실행 | 두 번째 실행 | |
|---|---|---|
| 모양 | 문단 위주의 줄글 편지 | 굵은 소제목 + 불릿 목록 |
| 미정 항목 표기 | 한 문단에 묶어서 서술 | 항목별로 한 줄씩 분리 |
| 마무리 | 회신 요청 | 회신 요청 + 다음 회의 전 재공유 약속 |
합격선 세 가지는 둘 다 통과했어요. 민지·현우의 업무와 날짜가 다 들어갔고, 가격과 운영시간은 미정으로 표시됐고, 메모에 없는 정보를 지어내지도 않았어요.
대신 모양은 꽤 달랐어요. 여기서 알 수 있는 게 두 가지예요. 합격선을 적어두면 중요한 건 흔들리지 않고, 대신 적어두지 않은 것은 여전히 실행마다 달라진다는 거예요. 그래서 3턴이 필요해요.
실행 조건 안내: 위 결과는 2026년 8월 18일에 서로 다른 두 AI 모델에 각각 한 번씩만 요청해 받은 것이에요. 특정 모델의 성능을 비교한 자료가 아니고, 같은 요청을 다시 보내면 또 다른 결과가 나올 수 있어요.
3턴 루프: 전체를 다시 쓰지 말고, 틀린 칸만 말하세요
- 턴 1 — 보낸다.네 칸을 채운 요청서를 그대로 보냅니다.
- 턴 2 — 채점한다.합격선에 적어둔 항목으로 결과를 하나씩 대조합니다.
- 턴 3 — 틀린 칸만 고친다.어긋난 항목만 지목해 다시 보냅니다.
채점은 이렇게 해요.
| 판정 항목 | 통과 조건 |
|---|---|
| 목적 적합성 | 실무팀이 다음에 뭘 할지 분명한가 |
| 재료 충실성 | 메모 밖 사실을 만들어내지 않았는가 |
| 필수 정보 | 담당자 2명과 날짜 2개가 다 있는가 |
| 미정 구분 | 가격·운영시간이 “미정”으로 표시됐는가 |
| 형식 | 제목과 지정한 본문 순서를 지켰는가 |
한 항목이 걸렸다면, 프롬프트 전체를 새로 쓰지 마세요. 이렇게만 보내면 돼요.
결과에서 현우의 마감일이 빠졌어요. 다른 부분은 그대로 두고, 담당 업무에 “현우 — FAQ 초안 — 9월 11일”을 추가해 주세요. 메모에 없는 정보는 넣지 마세요.
실패 진단표: 내 결과가 왜 이 모양인지 역추적하기
나온 결과의 증상만 봐도 어느 칸이 비었는지 알 수 있어요.
| 결과의 증상 | 비어 있던 칸 | 다음 턴에 추가할 문장 | 프롬프트 밖 가능성 |
|---|---|---|---|
| 길이가 매번 다르다 | 형식 | “각 줄 45자 이내로.” | 생성의 비결정성 |
| 그럴듯한데 사실이 틀렸다 | 재료 + 합격선 | “아래 자료 안의 내용만. 없으면 ‘자료에 없음’.” | 자료 부족, 모델 한계 |
| 너무 일반론이다 | 목적 | “읽는 사람은 ○○이고, ○○를 결정하려고 해요.” | 모델 지식·검색 범위 |
| 잘 나왔는지 모르겠다 | 합격선 | “이 두 조건을 못 지키면 실패로 볼게요.” | — |
| 모양은 맞는데 톤이 이상하다 | 형식 | 원하는 결과 예시를 하나 붙인다 | — |
| 느리거나 비싸다 | — | (프롬프트로 해결 안 됨) | 모델 선택·서비스 조건 |
마지막 줄은 일부러 넣었어요. Anthropic 문서는 모든 실패가 프롬프트만으로 해결되지는 않는다고 분명히 적어요. 지연시간이나 비용 문제는 문장을 아무리 다듬어도 안 줄어요. 그건 모델을 바꿀 문제예요.
요청서에 넣지 말아야 할 것
- 회사 기밀, 고객 정보, 주민번호·연락처 같은 개인정보
- 계정 아이디와 비밀번호
- 계약서나 내부 문서 원문 전체
- 서로 모순되는 지시 (“짧게, 그리고 아주 자세히”)
- 우리 팀만 아는 축약어
- 재료 없는 “알아서 잘 해줘”
화면을 녹화하거나 캡처해 공유할 때는 브라우저 탭, 알림, 계정명도 같이 찍힌다는 걸 잊지 마세요.
누가 쓰고, 누가 건너뛸까요
쓰세요
- 같은 종류의 작업을 주 1회 이상 반복하는 사람
- 결과를 검수하는 시간이 요청하는 시간보다 더 드는 사람
- 팀에서 요청 양식을 공유하고 싶은 사람
건너뛰세요
- 한 번 쓰고 버릴 단발성 질문
- 이미 평가 데이터와 자동 테스트를 굴리는 팀
- 속도나 비용이 진짜 병목인 경우 — 그건 프롬프트가 아니라 모델 선택 문제일 수 있어요
정리하면
좋은 프롬프트는 긴 프롬프트가 아니에요. 빈칸이 적은 프롬프트예요.
첫 답은 완성품이 아니라 채점 대상인 초안이고, 다음 요청에서는 틀린 항목만 지목하면 돼요.
그리고 하나 더. AI가 내놓은 결과는 확인 대상이에요. 사실관계, 법률, 의료, 금융, 가격, 정책, 최신 정보는 반드시 별도로 확인하세요. 네 칸을 다 채워도 이건 변하지 않아요.
네 칸이 손에 익으면 그다음엔 역할 지정이나 단계별 사고 유도 같은 기법으로 넘어갈 수 있어요. 세 회사 문서가 다 그 순서로 안내하고 있어요.
복사해서 쓰는 빈 틀
[목적]
누가 읽고, 무엇에 쓸 결과인지.
[재료]
쓸 자료의 범위. 자료 밖 추측을 허용할지 여부.
[형식]
길이 / 구조 / 문체 / 출력 모양.
[합격선]
반드시 포함할 것:
빼야 할 것:
이게 안 되면 실패:
네 칸으로 요청하면 AI로 PPT 만들기에서 다룬 슬라이드 초안도 훨씬 덜 흔들려요. 한 번 적용해 보세요.
그리고 프롬프트를 잘 써도 저작권이나 개인정보 판단은 별개예요. 그 기준은 AI로 만든 자료, 저작권·탐지 앞에서에 정리해 뒀어요.
출처
- OpenAI, Prompt engineering
- Anthropic, Prompt engineering overview
- Google, Prompting strategies