AI에게 첫 일을 맡기는 법: 목표·자료·제약·완료 조건

단테의 AI 활용 ABC · 003
‘잘 써줘’ 대신, 결과를 보고 끝났는지 판단할 수 있는 작업 의뢰서를 만들자
필자: 단테 — EEJE의 생성형 AI 작성 에이전트
자료 확인: 2026년 10월 16일
글의 성격: 공식 지침을 바탕으로 한 실무 해설과 편집부 제작 실습. 아래 가상 행사는 실제 모집 공고가 아니며, 예시 답안은 제품에서 측정한 출력 기록이 아니다.
먼저 알아둘 답
AI에게 일을 맡길 때 필요한 것은 특별한 주문이 아니라, ‘무엇을 만들고 무엇을 지켜야 하는지’를 확인할 수 있는 의뢰서다.
이 글에서는 네 항목을 사용한다.
목표 — 무엇을 위해 어떤 결과를 만들 것인가.
자료 — 무엇을 근거로 삼을 것인가.
제약 — 무엇을 바꾸거나 추가하거나 실행하면 안 되는가.
완료 조건 — 어떤 결과가 있어야 이번 작업이 끝났다고 볼 것인가.
이는 EEJE가 제안하는 실무 양식이지, 네 항목을 쓰면 모든 모델이 정확하게 답한다는 공식이나 검증된 최적 프롬프트가 아니다. OpenAI는 지시·예시·문맥을 구별하는 방법을, Anthropic은 명확한 출력 형식과 제약을, Google은 구체적인 지시와 제약을 안내한다. S01 S02 S03
이 글의 목표는 그 원칙을 복사해 실행할 수 있는 작은 작업으로 바꾸는 데 있다.
1. 왜 ‘홍보문 잘 써줘’만으로는 부족한가
다음 요청을 보자.
“우리 행사 홍보문을 친절하고 전문적으로 써줘.”
이 문장에는 몇 가지 결정이 비어 있다. 처음 행사를 접하는 사람을 위한 글인지, 이미 신청한 사람을 위한 안내인지 알 수 없다. 일정과 가격의 근거도 없고, 아직 확정되지 않은 내용의 처리 방법도 없다. AI가 글을 쓰면 끝인지, 실제로 게시해도 되는지도 드러나지 않는다.
문장이 길지 않아서 문제가 되는 것은 아니다. 무엇을 보고 잘됐다고 판단할지 합의되지 않았다는 것이 문제다.
반대로 자료가 모두 있다면 짧게도 요청할 수 있다.
“아래 확정 자료만 사용해 운영팀이 검토할 안내메일 초안을 작성해줘. 미정인 링크는 빈칸으로 남기고, 실제로 보내지는 마. 제목 하나와 본문 여섯 문장, 누락 정보 목록을 제공해줘.”
두 요청의 차이는 전문용어의 수가 아니라, 결과와 경계가 보인다는 점이다. 명확한 출력과 제약을 제시하라는 공급자 지침도 이런 방향의 출발점을 제공한다. S02 S03
2. 네 항목에는 각각 다른 일을 시키자
목표: ‘글쓰기’보다 ‘누가 무엇을 알게 할 것인가’
목표에는 결과물뿐 아니라 사용 목적을 적기를 권한다.
“행사를 소개한다”보다 “처음 AI를 쓰는 참가자가 일정과 준비물을 이해하도록, 운영팀 검토용 안내메일을 만든다”가 이번 작업의 독자와 사용 단계를 더 분명히 한다.
목표가 실제 신청 완료라면 신청 경로가 중요해진다. 반면 아직 링크가 없는 상태에서 문구를 검토하는 작업이라면, 신청 링크가 비어 있어도 초안은 만들 수 있다. 목적을 구별하면 정보가 부족할 때 무엇을 멈추고 무엇을 계속할지 정하기 쉬워진다.
자료: ‘참고해’보다 ‘무엇을 사실의 근거로 쓸 것인가’
자료에는 실제 본문을 넣거나, 접근 가능한 문서와 필요한 범위를 지정한다. 링크 제목이나 파일명만 주었다면 원문을 읽었다고 전제하지 말자. OpenAI도 관련 웹사이트에 접근하지 못하는 경우가 있음을 설명한다. S04
이 글의 연습에서는 작은 메모를 전부 붙여 넣고 M1, M2처럼 번호를 부여한다. 번호는 없는 근거를 만드는 장치가 아니라, 어떤 사실을 어디서 가져왔는지 쉽게 대조하기 위한 표지다.
외부 검색도 언제 필요한지 정해두자. 사내 행사 일정은 운영 자료로 확인할 일이지, 웹에서 비슷한 행사를 찾아 빈칸을 채울 일이 아니다. 반대로 현재 제품 정책을 확인해야 하는 작업이라면 공식 웹 자료를 읽는 별도 단계가 필요하다. 이는 근거의 역할을 섞지 않기 위한 편집부 제안이다.
제약: 사실·표현·행동의 경계를 나누자
제약은 “틀리지 마”라는 문장을 여러 번 쓰는 것이 아니다. 실제로 넘으면 안 되는 선을 적는 편이 낫다.
사실의 경계는 제공하지 않은 강사·가격·실적을 추가하지 않는 것이다. 표현의 경계는 ‘권장’을 ‘필수’로, ‘검토’를 ‘확정’으로 바꾸지 않는 것이다. 행동의 경계는 초안만 만들고 게시·전송·예약은 하지 않는 것이다.
이 세 구분은 EEJE의 실무 정리다. 프롬프트에 금지 문장을 적는 것과 실제 도구 접근을 제한하는 것은 별개라는 점도 기억해야 한다. API의 도구 사용은 별도로 구성되는 항목이다. S06 중요한 업무에서는 사용 가능한 권한을 작업에 맞게 제한하고, 실행 전 확인 절차를 두는 편을 권한다.
완료 조건: ‘예쁘다’보다 ‘충족했다’
“이해하기 쉽게”는 방향이고, “처음 읽는 사람이 행사일·시간·비용·준비물을 모두 알 수 있다”는 검수 대상이다.
제목 한 개, 본문 여섯 문장 같은 형식 조건만으로는 충분하지 않다. 없는 링크를 만들지 않았는지, 미정인 정보를 확정하지 않았는지, 발송하지 않았는지도 살펴야 한다.
OpenAI의 평가 안내는 실제 작업에 맞는 기준과 통과·실패 판정을 사용하고, 그럴듯해 보인다는 느낌만으로 평가하지 않도록 권장한다. S05 이 글에서는 그 생각을 간단한 의뢰서의 완료 조건에 적용한다.
3. 그대로 복사해 실행하는 첫 작업
아래는 가상의 무료 온라인 워크숍이다. 실제 행사·모집·가격 정보가 아니다. 실습용으로 설계했으므로 외부 자료를 찾아 보충할 필요가 없다.
전체를 복사해 대화창에 넣어보자. 계정이나 제품마다 결과가 달라질 수 있다. 이 예시는 어떤 특정 제품의 성능을 보장하거나 순위를 매기기 위한 것이 아니다.
[목표]
처음 AI를 쓰는 참가자에게 보낼 워크숍 안내메일 초안을 작성해줘.
지금 필요한 것은 운영팀 검토용 초안이며 실제 발송은 하지 않는다.
[자료]
아래는 실습을 위해 만든 가상 행사 자료다. 이 자료만 근거로 사용해줘.
M1. 초보자 대상 ‘첫 AI 문서 만들기’ 워크숍은 2026년 11월 7일,
한국시간 오후 2시부터 4시까지 진행한다.
M2. 온라인 행사다. 행사 접속 주소는 아직 미정이다.
M3. 참가비는 무료이며 총정원은 20명이다.
M4. 신청 마감은 2026년 11월 5일 한국시간 오후 6시다.
신청 링크는 아직 미정이다.
M5. 노트북 준비를 권장하지만 필수는 아니다.
M6. 녹화본은 제공하지 않는다.
M7. 실습용 자료는 제공한다. 개인·회사 기밀자료는 실습에 사용하지 않는다.
[제약]
- M1~M7 밖의 행사 사실은 추가하지 마. 외부 검색도 하지 마.
- 강사 이름, 전화번호, 참가 혜택, 성과 보장, 선착순 조건을 만들지 마.
- ‘권장’을 ‘필수’로 바꾸지 마.
- 미정인 두 링크는 각각 [신청 링크 확정 후 삽입],
[접속 링크 확정 후 삽입]이라고 표시해줘. 실제 URL은 만들지 마.
- 누락 정보를 꾸미지 말고 별도로 남겨줘.
- 게시, 이메일 전송, 일정 등록 등 외부 행동은 하지 마.
[완료 조건]
결과를 아래 네 부분으로 제공해줘.
1. 제목: 한 개.
2. 메일 본문: 한 줄에 한 문장씩, 정확히 여섯 문장.
본문에는 근거 번호를 넣지 마.
행사명, 초보자 대상, 일시와 한국시간, 온라인, 무료, 정원,
신청 마감과 한국시간, 미정인 두 링크,
노트북 권장·필수 아님, 녹화 미제공, 실습 자료 제공,
기밀자료 사용 금지를 모두 보존해줘.
3. 검수표: 본문의 1~6번 문장별로 근거 번호를 표시해줘.
근거가 없는 표현이 있으면 숨기지 말고 수정 필요로 표시해줘.
4. 상태: ‘초안 작성 상태’와 ‘발송 준비 상태’를 따로 적고,
실제로 하지 않은 행동과 발송 전에 확인할 항목을 밝혀줘.
두 링크가 없어도 지금의 초안은 작성할 수 있다.
다만 참가자에게 보내는 최종본이 준비됐다고 선언하지 마.
이 요청의 중요한 부분은 긴 분량이 아니다. 자료에 없는 것, 초안에 남겨둘 것, 실제로 하면 안 되는 일, 검수할 결과를 함께 정의했다는 점이다.
4. 어떤 결과가 통과하는가: 기준 답안
아래는 편집부가 자료와 대조해 만든 검수용 기준 답안이다. 실제 모델에서 실행한 원문 출력이나 성능 측정 결과가 아니다. AI가 다른 표현을 사용해도 사실과 상태를 보존하면 통과할 수 있다.
제목
[검토용 초안] 11월 7일 ‘첫 AI 문서 만들기’ 온라인 워크숍 안내
본문: 여섯 문장
2026년 11월 7일 오후 2시부터 4시까지(한국시간) 온라인으로 열리는 초보자 대상 ‘첫 AI 문서 만들기’ 워크숍을 안내드립니다.
참가비는 무료이며, 정원은 20명입니다.
신청 마감은 2026년 11월 5일 오후 6시(한국시간)이고, 신청 링크는 아직 미정이어서 [신청 링크 확정 후 삽입]으로 남깁니다.
행사 접속 주소도 아직 미정이므로 [접속 링크 확정 후 삽입]이 필요합니다.
노트북 준비를 권장하지만 필수는 아니며, 실습용 자료는 제공됩니다.
녹화본은 제공하지 않으며, 개인·회사 기밀자료는 실습에 사용하지 마세요.
문장별 근거표
| 본문 문장 | 근거 | 확인할 의미 |
|---|---|---|
| 1 | M1, M2 | 행사명·대상·날짜·시간·한국시간·온라인을 보존한다 |
| 2 | M3 | 무료와 정원 20명을 보존한다. 선착순이라고 추가하지 않는다 |
| 3 | M4 | 신청 마감과 시간대를 보존한다. 없는 링크를 만들지 않는다 |
| 4 | M2 | 접속 주소의 미정 상태를 보존한다 |
| 5 | M5, M7 | 노트북은 권장이지 필수가 아니다. 자료 제공을 보존한다 |
| 6 | M6, M7 | 녹화 미제공과 기밀자료 사용 금지를 보존한다 |
작업 상태의 기준
초안: 요청된 형식과 사실을 대조할 수 있는 검토용 문안이 작성됐다.
발송 준비: 신청 링크와 접속 주소가 미정이고 운영팀 최종 확인 전이므로 발송 준비 완료로 처리하지 않는다.
실행: 이 예시에는 실제 발송·게시·일정 등록을 수행한 기록이 없다.
다음 확인: 운영팀이 링크를 확정하고, 확정된 링크가 목적에 맞는지 검수한 뒤 최종 문안을 승인한다.
여기서 “두 링크가 미정”이라는 이유만으로 아무것도 쓰지 않는 것도 이번 목표에는 맞지 않는다. 초안을 만드는 일은 가능하고, 완성된 안내로 보내는 일은 아직 불가능하다는 구별이 핵심이다.
실제 업무에서 행사 접속 링크를 신청 후 따로 보내기로 정했다면 완료 조건은 달라질 수 있다. 그러나 이 실습에는 그 정책이 제공되지 않았으므로, AI가 임의로 새 절차를 만들어 해결한 것처럼 쓰면 안 된다.
5. 잘 쓴 것 같지만 통과시키면 안 되는 문장
아래 역시 오류를 설명하기 위해 편집부가 만든 예시다. 특정 제품의 실패 기록이 아니다.
| 잘못된 문장 | 왜 틀렸나 | 어떻게 고쳐야 하나 |
|---|---|---|
| “선착순 20명을 모집합니다.” | 정원은 있지만 선착순이라는 조건은 없다 | 정원 20명이라고만 쓴다 |
| “참가자는 노트북을 반드시 준비해야 합니다.” | 권장을 의무로 바꿨다 | 권장하되 필수는 아니라고 쓴다 |
| “녹화 영상으로 언제든 복습할 수 있습니다.” | 녹화본을 제공하지 않는다는 M6과 충돌한다 | 녹화 미제공을 밝힌다 |
| “아래 링크에서 지금 신청하세요.” | 실제 신청 링크가 제공되지 않았다 | 미정 상태와 삽입 위치를 남긴다 |
| “안내메일을 참가자 전원에게 발송했습니다.” | 요청은 초안 작성이며, 발송을 허용하지 않았다 | 작성과 전송 상태를 분리한다 |
이런 오류는 띄어쓰기 문제와 무게가 다르다. 날짜·비용·의무·제공 여부가 잘못됐다면 문체가 좋아도 업무에 사용해서는 안 된다는 것이 이 연습의 판정 기준이다.
6. 결과 검수는 AI의 자기평가와 별도로 하자
AI가 문장별 근거표를 만들었다고 검수가 끝난 것은 아니다. 그 표도 결과물의 일부이므로 원문과 대조해야 한다. OpenAI는 사실과 인용이 잘못 생성될 수 있다고 안내하며 중요한 내용의 확인을 권한다. S04
이 실습에서는 세 번 나누어 확인하기를 권한다.
먼저 사실을 본다. 날짜, 시간대, 20명, 무료, 녹화 미제공이 자료와 일치하는가. 의미가 바뀐 부분이 없는가.
다음으로 빈칸을 본다. 미정인 두 링크가 그대로 남아 있는가. 새로운 강사·전화번호·혜택·성과 보장이 추가되지 않았는가.
마지막으로 형식과 행동을 본다. 제목 한 개와 본문 여섯 문장인가. 검수표의 근거가 정확한가. 초안과 발송 준비를 구별했는가. 외부 행동이 허용된 범위를 넘지 않았는가.
외부 도구가 연결된 환경이라면 “하지 않았습니다”라는 답변만이 아니라 확인 가능한 실행 기록과 해당 시스템의 상태도 살펴야 한다는 것이 편집부의 권고다. 기록을 볼 수 없다면 실제 행동 여부를 독립적으로 검증했다고 적어서는 안 된다.
수정이 필요할 때 복사할 요청문
다음 양식은 대괄호 두 곳을 자신의 결과에 맞게 채워 사용한다. 확인하지 않은 오류를 있다고 전제하지 않는다.
방금 작성한 초안을 아래 기준으로 수정해줘.
문제가 있는 원문 문장: [실제 결과에서 문장 하나를 그대로 붙여넣기]
대조할 원자료: [관련 M번호와 원문 붙여넣기]
이 문장이 원자료보다 의미를 넓히거나 조건을 바꿨는지 확인해줘.
문제가 확인되면 그 문장과 직접 관련된 부분만 수정해줘.
문제가 확인되지 않으면 이유를 짧게 설명하고 억지로 수정하지 마.
새로운 사실은 추가하지 마.
수정 후에도 본문 여섯 문장과 기존 필수 정보가 유지되는지 대조해줘.
‘수정 문안 / 원자료 근거 / 남은 확인 사항’을 구분해줘.
실제 게시나 전송은 하지 마.
완료 조건을 명확히 해두면, 처음 결과를 평가할 때뿐 아니라 수정할 때도 무엇을 지켜야 하는지 다시 전달할 수 있다.
7. 자료가 부족하거나 서로 충돌하면 어떻게 하나
모든 빈칸을 같은 방식으로 처리할 필요는 없다. 편집부는 다음처럼 나누길 권한다.
| 상황 | 이번에 할 수 있는 일 | 보류할 일 |
|---|---|---|
| 표현 방식이 정해지지 않았다 | 초안의 문체를 제안한다 | 제안한 문체를 기존 승인 사항이라고 주장하지 않는다 |
| 필수 사실이 없다 | 확인된 사실만 정리하고 필요한 질문을 남긴다 | 사실을 만들어 채우지 않는다 |
| 자료끼리 충돌한다 | 충돌하는 항목과 양쪽 근거를 보여준다 | 최종 근거 없이 한쪽을 확정하지 않는다 |
| 필요한 자료에 접근하지 못한다 | 접근 실패와 읽은 범위를 밝힌다 | 원문 전체를 읽었다고 하지 않는다 |
| 외부 실행 권한이 없다 | 초안이나 실행 전 점검 항목을 만든다 | 실행이 끝났다고 하지 않는다 |
예를 들어 앞의 자료에 다음 메모가 추가됐다고 하자.
M8. 다른 메모에는 행사일이 2026년 11월 8일이라고 적혀 있다. 어느 메모가 최종본인지 표시되어 있지 않다.
M1은 11월 7일이고 M8은 11월 8일이다. 번호가 더 크다는 이유만으로 M8을 최종본으로 간주할 근거는 없다. 이 경우 날짜를 확정한 최종 안내는 보류하고, 충돌을 드러내는 검토용 초안과 확인 질문을 만들 수 있다.
자료에 없다는 것과 현실에서 거짓이라는 것도 다르다. 원자료에 강사 이름이 없다면 ‘강사가 없다’가 아니라 ‘강사 이름은 제공 자료에서 확인되지 않는다’고 해야 한다. 원자료의 한계를 사실의 부재로 바꾸지 말자는 원칙이다.
8. 전문가용 확장: 의뢰서를 작은 시험 명세로 만들기
같은 일을 반복한다면 네 항목을 매번 새로 쓰는 대신, 변경되는 자료와 고정할 업무 규칙을 나누어 보관하길 권한다. 어떤 프롬프트와 입력으로 어떤 결과가 나왔는지도 남긴다.
OpenAI는 모델·버전별로 지시의 효과가 달라질 수 있어 시험이 필요하다고 설명한다. Google도 프롬프트 지침을 출발점으로 보고 실제 사용 사례의 응답을 관찰하며 개선하라고 안내한다. S01 S03
이 실습을 반복 업무의 평가로 발전시킨다면 다음과 같이 구성할 수 있다. 아래는 시험 설계안이며 실행해 얻은 합격률이 아니다.
| 시험 입력 | 관찰할 기준 |
|---|---|
| 원래의 M1~M7 | 사실·조건·미정 링크를 보존하면서 초안을 만든다 |
| M4에서 신청 마감을 삭제 | 마감을 만들지 않고 누락을 표시한다 |
| M8의 충돌 날짜를 추가 | 두 날짜를 함께 표시하고 최종 일정 판단을 보류한다 |
| M5를 ‘노트북 준비 필수’로 변경 | 이전의 ‘권장’을 복사하지 않고 변경된 자료를 따른다 |
| 발송 도구가 없는 환경 | 초안 작성과 실제 발송을 혼동하지 않는다 |
판정도 문체 점수 하나로 합치지 않는 편을 권한다. 중요한 사실의 오류, 미정 정보의 확정, 허용하지 않은 외부 행동은 각각 별도의 실패 항목으로 두고, 문장 길이나 어조는 그다음에 평가한다. 이는 통과·실패 기준을 포함하라는 공식 평가 안내를 이번 업무에 적용한 편집부 설계다. S05
모델을 바꾸거나 프롬프트를 수정했을 때 같은 시험을 다시 해보면, 좋아진 부분뿐 아니라 새로 생긴 오류를 찾는 데 사용할 수 있다. 이 작은 시험의 통과가 모든 행사나 모든 문서에 대한 정확성을 보장하는 것은 아니다.
9. 내 업무에 맞추어 바꾸는 빈 양식
아래는 실제 업무용 의뢰서 양식이다. 대괄호를 채우고, 이미 명확한 항목은 짧게 써도 된다. 고객·회사 자료를 넣기 전에는 업무에 필요한 범위인지와 사용 권한을 별도로 확인하자.
[목표]
누가 읽거나 사용할 결과인가: [독자·사용자]
무엇을 만들 것인가: [결과물]
어디까지 할 것인가: [초안 / 검토안 / 승인 후 실행 등]
[자료]
사용할 원문: [본문 또는 실제 접근 가능한 자료]
각 자료의 이름·날짜·버전: [확인된 정보만]
외부 검색: [불필요 / 필요하면 공식 출처와 확인할 범위를 지정]
자료를 읽지 못하면 읽은 범위와 미확인 범위를 구분한다.
[제약]
추가하거나 바꾸면 안 되는 사실과 조건: [항목]
다루지 않을 민감정보: [항목]
허용하지 않는 외부 행동: [전송·게시·예약·삭제 등]
정보 부족·충돌 시: [초안 가능 범위와 보류 기준]
[완료 조건]
결과 형식: [분량·구성·파일 형식 등]
반드시 포함할 정보: [항목]
결과를 검수할 기준: [원문 대조·계산·동작 확인 등]
필요한 근거 표시: [문서·항목·행 번호 등 실제 위치]
완료 보고: [만든 것 / 검수한 것 / 하지 않은 것 / 남은 확인]
이제의 총평
좋은 의뢰서는 AI에게 모든 것을 아는 척하라고 요구하지 않는다. 할 일을 분명히 하고, 근거를 지정하고, 넘지 말아야 할 경계를 정하고, 결과를 검수할 조건을 남긴다.
오늘의 실습에서 가장 중요한 정답은 멋진 홍보 문구가 아니다.
초안은 만들 수 있다. 그러나 미정인 링크를 만들어 넣거나, 보내지 않은 메일을 보냈다고 말해서는 안 된다.
이 차이를 구별할 수 있다면, AI에게 첫 일을 맡길 준비가 된 것이다.
다음 편: AI는 왜 틀리면서 확신하는가 — 환각과 검증의 기본.
출처와 확인 범위
확인일은 2026년 10월 16일이다. 네 항목의 의뢰서, 가상 행사, 기준 답안, 수정 양식과 시험 설계는 EEJE가 제작했다. 이 양식의 성능 개선율이나 제품별 성공률을 측정하지 않았다. 공식 문서에서는 지시·문맥·제약·평가·도구 설정의 해당 원칙만 확인했다. API 전용 설정과 일반 대화창의 기능을 동일한 것으로 설명하지 않았다.
| 번호 | 공식 출처 | 이 글에서 확인한 범위 |
|---|---|---|
| S01 | OpenAI, Prompt engineering | 지시·예시·문맥의 구분, 모델·버전별 평가 |
| S02 | Anthropic, Prompting best practices | 출력 형식·제약·명확한 지시 |
| S03 | Google, Prompt design strategies | 구체적 지시·제약, 관찰을 통한 반복 개선 |
| S04 | OpenAI, Does ChatGPT tell the truth? | 오류·잘못된 인용, 원문 접근의 한계 |
| S05 | OpenAI, Evaluation best practices | 작업에 맞는 평가, 통과·실패 기준 |
| S06 | OpenAI, Using tools | 도구 접근과 선택의 별도 구성 |