결론부터 말하면, 모호한 요청을 받은 직후 AI에게 보고서를 쓰게 하지 마세요. 먼저 목적·결정, 독자, 근거 자료, 제약, 완료 기준 다섯 칸을 채우고 빈칸은 상사에게 확인합니다.
이 글은 “AI로 목차를 빨리 만드는 법”과 다릅니다. 쓰기 전에 요청의 모호함을 드러내고, 확인되지 않은 가정이 보고서 안으로 들어가지 않게 만드는 절차입니다. 목차 작성은 그다음 단계입니다.
1. 요청을 다섯 칸으로 분해하세요
Google Cloud의 공식 프롬프트 설계 문서는 목표, 지시, 제약, 맥락, 출력 형식처럼 입력의 구성 요소를 명시하고 반복 시험할 것을 안내합니다. OpenAI의 현재 모델 가이드도 목표, 관련 맥락, 제약, 필요한 근거, 성공 기준, 출력 형식을 먼저 주는 방식으로 설명합니다. 아래 다섯 칸은 두 문서의 공통 요소를 보고서 요청에 맞게 줄인 것입니다.
| 항목 | 적을 내용 | 빈칸일 때 물을 질문 |
|---|---|---|
| 목적·결정 | 이 보고서를 보고 누가 무엇을 결정하는가 | “검토용인가요, 승인이나 선택이 필요한가요?” |
| 독자 | 최종 독자, 이미 아는 내용, 관심사 | “최종 독자는 누구이고 가장 궁금해할 것은 무엇인가요?” |
| 근거 자료 | 사용할 수치·문서·기간, 확인되지 않은 내용 | “반드시 넣을 수치와 기준 기간은 무엇인가요?” |
| 제약 | 마감, 분량, 파일 형식, 포함·제외 항목 | “몇 쪽이며 표나 발표 자료도 필요한가요?” |
| 완료 기준 | 승인 조건과 최종 산출물 | “이 보고서가 답해야 하는 질문 한 가지는 무엇인가요?” |
독자를 먼저 정하는 이유도 명확합니다. 미국 Digital.gov의 평이한 언어 지침은 구체적인 독자를 정하고 그들이 필요로 하는 정보에 집중하라고 안내합니다. CDC의 커뮤니케이션 지침도 주요 독자, 목적, 핵심 메시지에서 시작하고 검토자와 일찍 협업하라고 권합니다.
2. 한 문장을 실제 브리프로 바꿔보겠습니다
상사가 “이달 성과 보고서 정리해줘”라고 말했다고 가정해 보겠습니다. 아래 내용은 사용법을 보여주기 위한 가상 예시이며 실제 회사 자료가 아닙니다.
| 항목 | 가상 입력 예시 |
|---|---|
| 목적·결정 | 임원 회의에서 다음 달 예산 재배분 여부를 결정 |
| 독자 | 세부 업무를 모르는 임원 3명 |
| 근거 자료 | 목표 대비 실적, 차이 원인, 주요 위험, 다음 행동과 필요 예산 |
| 제약 | 2쪽, 표 1개, 초안 마감은 다음 날 오전 10시 |
| 완료 기준 | 유지·축소·추가 투자 중 하나를 판단할 수 있어야 함 |
실제 업무에서는 확실하지 않은 값을 추측해 채우지 마세요. 예를 들어 최종 독자나 마감이 확인되지 않았다면 [확인 필요]로 남겨야 합니다. 이 표의 역할은 완성된 답을 꾸미는 것이 아니라, 답이 없는 칸을 보이게 만드는 것입니다.
3. 이 지시문을 복사해 목차와 질문을 받으세요
다섯 칸을 채운 뒤 아래 지시문을 AI에 붙여 넣습니다. 중요한 순서는 가정 → 확인 질문 → 목차 → 필요한 근거입니다.
다음 입력만 사용해 보고서 목차를 만드세요.
[목적·결정]
[독자]
[근거 자료]
[제약]
[완료 기준]
출력 순서:
1) 확인되지 않은 가정
2) 상사에게 먼저 물을 질문 3개
3) 의사결정 중심 목차 5개
4) 각 목차에 필요한 근거
수치나 사실을 만들지 마세요. 입력에 없는 내용은 [확인 필요]로 표시하고, 한국어로만 작성하세요.
보고서 요청 브리프 TXT 내려받기
4. 목차보다 먼저 확인 메시지를 보내세요
상사에게 “무슨 말씀이세요?”라고 되묻기보다, 내가 이해한 목적과 형식을 짧게 제시한 뒤 틀린 부분을 고쳐 달라고 요청합니다. 앞의 가상 예시는 다음 메시지로 바꿀 수 있습니다.
팀장님, 임원회의에서 다음 달 예산 재배분을 결정하는 2쪽 보고서로 이해했습니다. 목표 대비 실적·차이 원인·위험·실행안과 예산 요청 순으로 잡겠습니다. 판단 기준과 반드시 넣을 수치를 확인 부탁드립니다. 초안 마감은 내일 오전 10시가 맞을까요?
회신을 받으면 브리프를 수정한 다음에만 본문 초안을 요청합니다. 상사가 답하지 않은 칸은 AI가 대신 결정하게 두지 않고 문서에 [확인 필요]로 남깁니다.
5. Ollama 단일 실행에서 확인한 것
실험 환경: 2026년 8월 28일, 이 PC의 Ollama qwen3.5:4b로 각 조건을 한 번씩 실행했습니다. 속도나 모델 품질을 비교하는 벤치마크가 아니라, 입력 구조가 결과에 어떻게 드러나는지 확인한 편집 실험입니다.
| 확인 항목 | “이달 성과 보고서 정리해줘” | 다섯 칸을 준 요청 |
|---|---|---|
| 결정 목적 | 일반적인 성과 보고서 구성에 머묾 | 예산 재배분 판단에 맞춘 항목이 나타남 |
| 근거·질문 | 자료의 빈칸과 확인 질문이 드러나지 않음 | 필요 근거, 가정, 상사 질문을 구분함 |
| 문제점 | 요청에 없는 날짜와 틀을 넣고 다른 언어 문자가 섞임 | 마감 시각을 바꾸고 영어·다른 언어 문자가 남음 |
| 편집 판단 | 업무 초안으로 사용하지 않음 | 방향 참고만 가능하며 사람 검수 후 사용 |
구조화한 입력에서도 날짜 변경과 언어 혼입이 발생했습니다. 따라서 이 실험은 “구체적으로 쓰면 언제나 맞다”는 증거가 아닙니다. 오히려 입력 구조와 별개로 사실·날짜·언어를 사람이 다시 확인해야 한다는 운영 경계를 보여줍니다.
6. 실무에서는 이 순서로 끝내세요
상사의 원문을 한 줄 그대로 남깁니다.
다섯 칸을 채우고 모르는 내용은 [확인 필요]로 표시합니다.
내가 이해한 목적·독자·형식과 질문을 상사에게 보냅니다.
확인된 브리프만 AI에 넣어 가정·질문·목차·근거를 받습니다.
수치, 날짜, 고유명사, 결론을 원자료와 대조한 뒤 본문을 씁니다.
- 보고서가 지원할 결정이 한 문장으로 적혀 있는가
- 최종 독자와 그들이 이미 아는 내용이 구분되어 있는가
- 근거 자료의 출처·기간과 확인되지 않은 값이 표시되어 있는가
- 마감·분량·형식이 상사와 합의되었는가
- AI가 만든 수치·날짜·고유명사가 남아 있지 않은가
- 목차의 각 항목이 결정에 필요한 질문에 답하는가
목차가 확정된 다음 단계
요청을 확인한 뒤 초안의 뼈대를 만드는 단계가 필요하다면 아래 두 글로 이어가세요. 오늘 글은 두 글보다 앞단인 요청 해석과 확인만 다룹니다.
작성·검수 정보
- 작성·검수: MUMULAB 편집팀
- 검수 방법: 공식 지침 4건 대조, 기존 보고서 관련 글 중복 확인, Ollama 단일 실행 2건 비교, 정량 보장 문구 제거, 브라우저 QA
- 적용 범위: 사내 일반 보고서 요청을 정리하는 예시이며 인사·법률·재무 판단을 대신하지 않음
확인한 공식 자료
- Google Cloud 프롬프트 설계 전략 — 목표·지시·제약·맥락·출력 형식과 반복 시험
- OpenAI 모델 프롬프트 가이드 — 목표·맥락·제약·근거·성공 기준·출력 형식
- Digital.gov 독자를 위한 글쓰기 — 구체적인 독자와 독자가 필요로 하는 정보
- CDC Clear Communication Index 사용법 — 주요 독자·목적·핵심 메시지와 초기 검토 협업
확인일: 2026년 8월 28일. 공식 자료의 원칙을 MUMULAB이 일반 사내 보고서용 다섯 칸으로 재구성했습니다. 로컬 실험은 동일 PC에서 조건별 한 번만 실행했으므로 모델 전체의 성능으로 일반화하지 않습니다.