테마
10. 보고서 작성 워크플로
AI는 보고서를 대신 책임지는 작성자가 아니라, 목차를 빠르게 세우고 초안을 압축 생산하는 보조 엔진에 가깝다.
1. 보고서는 크게 세 가지로 나눌 수 있다
원문은 보고서를 다음 세 종류로 구분한다.
| 종류 | 목적 | 자주 필요한 질문 |
|---|---|---|
| 기획보고서 | 아이디어를 승인받기 위해 작성 | 왜 이 일을 해야 하는가? |
| 계획보고서 | 승인된 일을 실제로 실행하기 위해 작성 | 어떻게 추진할 것인가? |
| 결과보고서 | 끝난 일의 성과와 교훈을 정리 | 무엇이 나왔고 무엇을 배웠는가? |
같은 "보고서 작성"이라도 종류가 다르면 프롬프트도 달라져야 한다.
- 기획보고서: 필요성, 설득력, 차별성
- 계획보고서: 일정, 인력, 예산, 실행 순서
- 결과보고서: 결과, 근거, 해석, 한계
2. AI가 잘하는 일과 사람이 맡아야 하는 일
AI는 아래 영역에서 강하다.
- 초안 생성
- 목차 구조화
- 문단 확장
- 표현 다듬기
- 빠진 항목 찾기
반대로 사람은 아래를 책임져야 한다.
- 사실 데이터 제공
- 수치와 근거 검증
- 조직 맥락 반영
- 최종 의사결정
즉, AI를 쓸 때 가장 좋은 태도는 "다 써줘"가 아니라 **"내가 가진 사실을 넣고 구조화 속도를 올리자"**에 가깝다.
3. 시작 전에 먼저 정해야 할 것
보고서 초안 품질은 처음 질문 한 번에서 많이 갈린다.
최소한 아래 다섯 가지는 먼저 정해두는 편이 좋다.
- 보고서 종류
- 독자
- 목적
- 이미 확정된 사실
- 아직 가정인 부분
예를 들어 같은 사업 문서라도 독자가 달라지면 표현이 바뀐다.
- 상사에게 보고: 의사결정 포인트 중심
- 투자자에게 제안: 시장성과 수익성 중심
- 실무팀에게 공유: 일정과 역할 분담 중심
4. 추천하는 기본 작성 순서
한 번에 완성본을 요구하기보다, 작은 단위로 쪼개는 편이 훨씬 안정적이다.
원문에서도 이 흐름이 반복된다.
- 먼저 목차를 세운다
- 필요한 데이터를 조금씩 넣는다
- 섹션 단위로 확장한다
- 사람이 읽고 수정 방향을 추가한다
- 다시 보완한다
5. 익숙하지 않은 분야에서도 시작할 수 있는 이유
원문은 "내가 잘 모르는 분야라도 기획보고서의 뼈대를 만들 수 있는가?"를 실험한다.
핵심은 AI가 그 분야의 진실을 전부 안다는 뜻이 아니라, 보고서의 일반적인 구조를 많이 학습했기 때문에 초안 틀을 빠르게 세울 수 있다는 점이다.
다만 전제가 있다.
- 최소한의 사실 데이터는 사람이 넣어야 한다
- 모르는 수치는 가정이라고 표시해야 한다
- 한 번에 여러 시나리오를 섞지 않는 편이 좋다
예를 들어 지역 개발 기획서를 쓴다면 처음부터 전부 물어보기보다 아래처럼 시작하는 편이 낫다.
text
이 문서는 기획보고서다.
독자는 지방자치단체 의사결정자다.
목적은 신규 주거지 개발 필요성을 설명하는 것이다.
확정 사실:
- 대상 지역 인구 추세
- 평균 주택 가격
- 현재 교통 여건
가정:
- 공급 규모
- 예상 분양률
이 조건에 맞는 목차를 설계해줘.
불확실한 수치는 [가정]으로 표시해줘.이렇게 하면 모델이 "그럴듯한 소설"을 쓰기보다, 사실과 가정을 구분한 초안을 만들 가능성이 높아진다.
6. 목차를 세운 뒤에는 한 섹션씩 팽창시켜라
보고서를 한 번에 10페이지, 20페이지씩 뽑으려고 하면 보통 품질이 떨어진다.
대신 목차를 확정한 뒤, 필요한 섹션만 하나씩 확장하는 편이 좋다.
이 방식의 장점은 분명하다.
- 틀린 부분을 빨리 발견할 수 있다
- 사람이 데이터와 그림을 끼워 넣기 쉽다
- 보고서 번호 체계와 구성 정리가 편하다
원문에서도 실제 문서 작업은 이렇게 흘러간다.
초안을 붙여 넣고, 필요 없는 문장을 덜고, 숫자와 그림은 사람이 보충하는 방식이다.
7. 계획보고서는 비판 루프를 붙이면 훨씬 강해진다
계획보고서나 사업계획서는 "그럴듯한 말"만으로는 부족하다.
실행 순서, 자금, 팀 구성, 일정 같은 부분에서 쉽게 허점이 드러난다.
이때는 앞 장에서 본 Generator/Discriminator 구조가 잘 맞는다.
실무적으로는 아래 질문이 특히 유용하다.
- 이 계획은 왜 승인받기 어려운가?
- 수치 근거가 가장 약한 부분은 어디인가?
- 일정과 인력 배치에서 비현실적인 부분은 무엇인가?
- 심사자가 가장 먼저 반박할 지점은 어디인가?
즉, 보고서 작성 단계에서 AI를 두 번 쓰는 것이다.
- 한 번은 작성자처럼
- 한 번은 심사자처럼
8. 바로 써볼 수 있는 프롬프트 틀
8.1 목차 설계 프롬프트
text
다음 문서의 종류는 [기획보고서 / 계획보고서 / 결과보고서]다.
독자는 [상사 / 투자자 / 협업부서 / 심사자]다.
목적은 [승인 / 실행 / 결과 공유]다.
확정 사실:
- ...
가정:
- ...
이 조건에 맞는 목차를 3단계 깊이까지 설계해줘.
부족한 정보가 있으면 [추가 데이터 필요]로 표시해줘.8.2 섹션 확장 프롬프트
text
다음 목차 중 `3.2 시장 분석`만 작성해줘.
확정 사실만 우선 사용하고, 부족한 수치나 판단은 [가정] 또는 [추가 데이터 필요]로 표시해줘.
출력은 다음 형식으로 해줘.
- 소제목
- 핵심 문단
- 넣으면 좋은 도표 또는 그림 제안 3개8.3 비판 검토 프롬프트
text
당신은 이 문서를 심사하는 검토자다.
아래 초안을 읽고 `문제점 / 왜 문제인지 / 보완 데이터` 형식으로 정리해줘.
사소한 문장 교정보다 승인 판단에 영향을 주는 약점을 우선해줘.9. 자주 하는 실수
9.1 처음부터 완성본을 요구한다
이 경우 목차도 흐려지고, 근거 없는 문장이 많이 섞인다.
9.2 사실과 가정을 구분하지 않는다
보고서에서는 "있는 데이터"와 "예상치"가 섞이면 신뢰도가 떨어진다.
9.3 모델이 만든 수치를 그대로 가져간다
숫자는 특히 검증이 중요하다.
출처가 없는 수치는 반드시 사람이 다시 확인해야 한다.
9.4 비판 루프를 너무 오래 돌린다
어느 순간부터는 핵심 개선보다 사소한 표현 수정만 반복된다.
그 시점에는 사람이 최종 편집으로 넘어가는 편이 낫다.
10. 이번 배치에서 기억할 문장
- 보고서 종류가 달라지면 좋은 프롬프트도 달라진다
- AI는 구조화와 초안 생산에 강하고, 사실 검증과 책임은 사람이 맡아야 한다
- 목차를 먼저 만들고 섹션을 하나씩 확장하는 방식이 가장 안정적이다
- 계획보고서처럼 검토가 중요한 문서는 Generator/Discriminator 루프가 특히 효과적이다
논문 같은 고난도 결과보고서 워크플로는 다음 배치에서 별도로 다루는 편이 더 이해하기 쉽다.