보고서 작성 업무가 정말 많은 컨설팅 회사 특성상 AI를 정말 많이 쓰게 됩니다. 신기한건 요즘 고객사들도 많이 쓰시더군요, 가끔 Client와 만나게 되면, 어떤 AI 쓰시냐, 나는 이걸 많이 쓴다 등등 ice breaking 목적이지만 AI가 정말 실생활, 실 업무에 스며들었다는 것을 느끼게 됩니다.
그런데 말입니다. AI로 보고서를 쓰는 여러분들은 정말 딸깍 한번으로 보고서를 잘 쓰시나요?, 보고서 주제 수립과 리서치 때문에 몇시간씩 GPT와 씨름을 하고 계시진 않으신가요?, 우리가 쓰는 AI는 왜 내 맘을 잘 몰라주고 엉뚱한 얘기를하거나, Fact에도 없는 얘기를 하면서 사람을 힘들게 할까요?

오늘은 AI로 보고서 업무를 잘 Support할 수 있는 제 개인적인 노하우를 공유드리려 합니다.
목차
Pain point: 보고서 방향성만 짜는데도 적게는 30분, 많게는 3시간...
근인: AI는 사용자의 질문에 답하고 동조하는 서포터일뿐, 나 자체를 대신해주지 않습니다.
솔루션: AI 보고서 작성 프롬프트 (역할 / 체계적 Input / 구체적인 아웃풋 이미지 / 작성 원칙)
결론: 막연한 질문으로 시작하기 보다, 질문 자체를 설계해서 접근해봅시다
Pain point: 보고서 방향성만 짜는데도 적게는 30분, 많게는 3시간...
보고서 업무를 받게 되면 처음 방향성을 잡든, 조사를 하든, PPT로 만들든 이런 저런 AI 툴을 쓰게 됩니다. 아무래도 보고서라는 것 자체가 회사, 보고 배경, 목적에 따라 Customization이 요구되는 일이다 보니, 획일적인 AI 자동생성기 보다는, 대부분 대화형 AI (Chat GPT, 제미나이, Perplexity, Manus 등)을 많이들 쓰실 것 같아요
그런데, 이런 경험 없으신가요? 방향성 뽑아달라고해서 뽑아주면 마음에 들지않고, 그래서 이것 저것 추가요구를 하다보면 1~3시간이 훌쩍 지나가게 됩니다. 또 방향성이 마음에 들었을때 "내용 조사해서 디벨롭해줘"라고 말하게 되면 말도 안되는 헛소리를 Fact인것마냥 지어내면서 말해주기도 하고, 우여곡절 끝에 내용을 구성해서 다시한번 들여다 보면, 있어보이는 컨텐츠는 많지만 일반론적인 것들이고, Edge point가 없는, 소위 말하는 Kick이 없는 보고서가 나오기 마련이죠
그래서 AI를 활용해서 보고서를 작성할때 사용자를 가장 힘들게 하는 pain point는 아래 3가지인 것 같습니다
- 방향성 설정: 보고서 방향성 잡는데만 1시간~3시간 (이런 저런 대화 나누고, 추가 요청사항 말하다 보면...)
- 조사: 사실도 아닌 것을 Fact처럼 말해서 근거 확인하는데 상당한 시간 소요
- Edge point 디벨롭: 내용 구성은 됬으나 Edge point, Kick이 없는 일반론적 컨텐츠
결과적으로 시간을 줄이기 위해, 편리하게 작성하기 위해 AI로 보고서를 쓰는건데, 아이러니하게도 시간이 더 드는 것 같기도 하고, 괜시리 AI한테 화나고, 피로감만 높아지는 상황이 의외로 많이 발생하게 됩니다.
근인: AI는 사용자의 질문에 답하고 동조하는 서포터일뿐, 나 자체를 대신해주지 않습니다.
위에 말씀드린 Pain point와 같이 보고서를 쓸 때 AI가 똥멍청이가 되는 이유는 무엇일까요?, 왜 우리는 AI로 보고서를 쓰는데 시간이 더 오래 걸리고, 피곤할 수 밖에 없을까요?, 근인은 AI는 (1) 사용자의 질문에 답만하는 수동적인 기계이고, (2) 꼼꼼하게 체크하면서 지시하지 않으면 설렁설렁하는 게으름뱅이이며, (3) 사용자의 요구수준과 맥락을 모른채 일을 하는 신입사원과 같은 존재이기 때문입니다.
AI 특징 (1): 사용자에 질문에 답만하는 수동적인 기계
일례로 방향성 설정하는데만 3시간이 걸리는 이유는, AI가 답한 내용을 조금씩 파고들어가다 보면 더 새로운 idea나 컨텐츠가 나오게 되고, 그래서 이걸 다시 질문하고 구체화하고, 그러다 보면 몇시간이 훌쩍 지나가버리는 경험이 많으실 겁니다.
그 이유는 AI는 보고서의 구조와 질문을 먼저 생각하기 보다, 사용자의 질문에 답을 먼저 하는 것 중심으로 설계되어 있기 때문입니다. 즉, 보고서라는 것이 방향성이 똑바로 설계되려면 보고서의 배경, 목적, 이에 따른 핵심 질문, 핵심 질문에 답을하기 위한 목차와 스토리라인이 순차적으로 구성되어야 하는데, 이러한 보고서에 대한 체계적인 설계 없이, 보고서 어떻게 써야하느냐라는 질문만 맹목적으로 하게 되면 AI는 맹목적인 질문에 답하는 기계로 둔갑할 수 밖에 없다는 것이죠.
AI 특징 (2): 꼼꼼하게 지시하지 않으면 설렁설렁 일하는 게으름뱅이
그렇다면 두번째 Pain point인, "사실도 아닌 것을 Fact처럼 말하는" 이슈는 왜 발생하는 것일까요?, 제 가설이긴 합니다만, 두가지 이유가 있을 것 같습니다. 첫번째는 AI는 사용자가 마음속으로만 생각하는 조사 등 업무의 Quality 요구 수준에 대해 구체적으로 알지 못합니다. 그래서 때로는 사실과 가설을 혼동해서 말하기도 하고, 조사를 아주 조금만 한 상태에서 추론하여 일을하기도 하죠.
두번째 이유는 AI 서비스 회사들의 토큰아끼기 전략 때문아닐까 싶어요. AI가 꼼꼼하게 일을 안할 수도 있지만, 여러차례 Fact 확인하는 경향이 포착되면 AI가 학습을 하거나 하면 되는데, 개별 사용자들의 맥락을 다 이해한 상황에서 이러한 맥락이 축적되고, 그래서 일을 시키면 시킬수록 똑똑한 AI가 되기 위해서는 막대한 토큰이 사용될 수 있고, 그러다 보면 AI 서비스 회사 입장에서는 그대로 비용증가(Data 처리비용 증가 등)로 이어지게 되기 때문에, 어느 정도의 멍청함을 용인하는 것이 아닐까 싶습니다.
AI 특징 (3): 사용자의 요구수준과 맥락을 모른채 일을 하는 신입사원과 같은 존재
세번째 Pain point인, Contents에 대한 Edge가 없다는 것도 사실 두번째 내용과 유사한 이유이긴 하지만, 결과적으로 사용자가 원하는 Quality 요구 수준에 대해 AI는 명확히 알고 있지 못하고, 그러다 보니 여러 추가 질의, 요구사항을 통해 Quality를 교정하는 Discussion 과정이 필수적이고, 그러다 보니 AI와 논의를 통해 보고서를 작성할때 막대한 시간이 들어가는 것 같습니다.
제 아무리 똑똑한 AI라 할지라도, 사용자마다 원하는 수준과 Quality 요구치가 다르다보니 여기에 적응하는 것이 필요하게 되고, 특히 사용자의 맥락을 모두 학습하지않는 오늘날의 AI 서비스 특성상 이러한 시행착오가 반드시 들어갈 수 밖에 없는 것이죠(이와 동시에 보고서를 쓰기 위한 AI훈련에 드는 시간도 반드시 증가할 수 밖에 없는 구조인 것 같습니다).
솔루션: AI 보고서 작성 프롬프트 (역할 / 체계적 Input / 구체적인 아웃풋 이미지 / 작성 원칙)
결과적으로 AI가 똥멍청이가 되는 근인을 살펴보면, 사용자의 Quality 요구치, 기대수준, 맥락 등을 이해하지 못하기 때문에 시행착오가 많고, 그래서 AI 보고서 작성에 시간이 많이든다고 정리될 수 있을 것 같습니다.
그렇다면 어떻게 이러한 Gap을 축소 시킬 수 있을까요?, 어떻게 AI가 내 상황과 맥락을 충분히 인지한 상태에서 일할 수 있게할까요?, 저는 아래와 같이 처음 보고서를 기획할 때 프롬프트 템플릿을 만들어 질문하고 있습니다. (이렇게 한다면 훨씬 내 입맛에 맞는 보고서 기획과 논의가 이루어질 수 있습니다)

제가 공유드린 프롬프트의 구성요소를 보면 크게 4가지라고 보시면 되겠습니다 (역할 - Input - Output image - 작성원칙)
- 역할: "당신은 전략컨설턴트다"라고 지정하는 것처럼 AI에게 Role을 부여하게 되면, AI는 어떤 맥락에서 보고서의 논리를 구성하고, 어떤 Stance와 Attitude로 일할지 스스로 정의합니다. 이걸 정의해주는 것과 안해주는 것의 차이가 꽤 큰 것 같아요
- Input: Input의 경우, AI에게 내가 생각하는 상황과 맥락을 인지시키기 위해 꽤나 디테일하게 작성해주고 있습니다. 신사업진출검토보고서라면 보고 배경은 무엇이고, 검토하는 사업은 무엇이며, 보고의 목적은 무엇인지, 보고 대상의 핵심 고려사항은 무엇인지 적어주는 편입니다.
- Output image: 세번째 output image의 경우, 저 같은 경우 보고서의 방향성부터 잡기 때문에 사실 Key question, 의사결정 논리에 맞춘 목차 등을 구체적으로 제시하며 일을 시키곤 합니다. (필요에 따라 One page summary, Storyline과 가설을 모두 요구하기도 합니다)
- 작성원칙: 마지막 작성원칙의 경우, 아까 말씀드린 "사실도 아닌 것을 Fact처럼 말하는 할루시네이션" 등을 방지하기 위한 목적으로 프롬프트에 포함시키며, 필요에 따라 결론을 제시한다거나, Edge point를 추려봐라라는 등의 작업 원칙을 추가하기도 합니다.
이렇게 체계적으로 프롬프트(명령어)를 셋팅해서 접근하게 되면 AI와 사용자간 맥락, 기대치 등의 Gap을 최소화시킬 수도 있고, 템플릿 형태로 만들었기 때문에 마치 체크리스트처럼 빼먹지 않고 구조적이고 체계적인 AI 보고서 작성이 이루어질 수 있습니다 ^ ^;;
결론: 막연한 질문으로 시작하기 보다, 질문 자체를 설계해서 접근해봅시다
제 경험상 AI로 보고서 작성하는데 시간이 오히려 많이 드는 이유는, 막연하게 "xxx 보고서 써줘"라고 질문했기 때문인 것 같습니다. 효과적으로 AI를 활용하기 위해서는 사용자와 AI간의 인지적 Gap (보고 배경, 목적, 요구사항, Quality 수준, Output image 등)을 최소화시키는 것이 중요하고, 이를 위해 구조적인 Template을 만든다거나, 메모장에 이를 복붙해서 물어볼때마다 붙여넣기로 활용하는 것도 고려해볼 수 있을 것 같아요 (실제 저는 그렇게 쓰고 있습니다)
결론적으로 AI 보고서 작성을 잘 하시는 분들은 보고서의 질문 자체를 잘 설계하시는 분들인것 같고, 여러 시행착오를 통해 자기만의 프롬프트(명령어) 템플릿까지 만들 정도로 고민하신 분들이 아닐까 싶네요 ^ ^;;
함께 읽으면 좋은 글들
2026.02.27 - [보고서 잘 쓰는 법] - 무료 보고서 예시?, 보고서 템플릿?, 그것보다는 방향성부터 설계하세요...
무료 보고서 예시?, 보고서 템플릿?, 그것보다는 방향성부터 설계하세요...
사람들은 보고서 업무를 받게 되면 의례 하는 것들이 있습니다. 무료 보고서 예시를 찾거나 템플릿부터 찾아보는거죠, 생각해보면 당연하기도 합니다. 보고서라는 업무 자체가 익숙치 않기도
kickstarter.tistory.com
2025.07.06 - [보고서 잘 쓰는 법] - 한장 요약 보고서(Executive summary)를 잘 쓰는 가장 쉬운 방법
한장 요약 보고서(Executive summary)를 잘 쓰는 가장 쉬운 방법
"누가 너가 한 일을 정리하래?, 함축적으로 컨텐츠를 정리해야지, 대표님은 이 한장만 볼텐데 이렇게 써서 잘 이해 되시겠어?, 핵심 내용도 안들어갔네?" 혹시 여러분들께서는 막상 보고서를 작
kickstarter.tistory.com
2025.05.30 - [보고서 잘 쓰는 법] - 보고서 스토리 짜는 방법: 결국 치밀한 Message tree 설계
보고서 스토리 짜는 방법: 결국 치밀한 Message tree 설계
일전에 대전에서 공공기관 ISP 컨설팅에 참여한적이 있습니다. 고객사 Champion은 책임운영기관으로서 통신사 IoT 본부장님께서 데이터센터 원장을 맡으셨고, 덕분에 공무원 출신의 고객사 대비 훨
kickstarter.tistory.com
2025.03.13 - [보고서 잘 쓰는 법] - 보고서 퀄리티가 걱정된다면 '3분 요약 설명'으로 점검해보자
보고서 퀄리티가 걱정된다면 '3분 요약 설명'으로 점검해보자
전략컨설팅 보고서를 작성하다보면, 몇날 몇일 꼬박 시간을 투자해서 임원분 또는대표님께 보고할 보고서를 정리하다 보면, 결국 내가 쓰는 보고서에 스스로가 매몰되어 쉽게 이해되지 않는 내
kickstarter.tistory.com
'보고서 잘 쓰는 법' 카테고리의 다른 글
| 한번에 통과되는 보고서 작성법: 이 한가지만이라도 알아두세요! (1) | 2026.03.05 |
|---|---|
| AI 보고서 자동화?, AI로 '보고서 방향성부터 설계'합니다 (0) | 2026.03.05 |
| 무료 보고서 예시?, 보고서 템플릿?, 그것보다는 방향성부터 설계하세요... (0) | 2026.02.27 |
| 보고서 쓸 때 멍 때린적 있는 사람만 보세요! (0) | 2026.02.20 |
| 한장 요약 보고서(Executive summary)를 잘 쓰는 가장 쉬운 방법 (3) | 2025.07.06 |