보고서 하나가 매우 전문적으로 보인다. 제목은 완전하고, 문단은 매끄럽고, 인용은 가지런히 정리되어 있으며, 대형 기관 사례까지 들어 있다. 그러면 이제 말투를 다듬고, 도표를 보충하고, 상사에게 확인을 보내면 된다고 생각하기 쉽다.
하지만 인용 자체가 틀렸다면, 멋진 문장은 오히려 오류를 더 쉽게 믿게 만든다.
2026년 6월, KPMG는 앞서 공개했던 AI 도입 보고서 《Redefining excellence in the age of agentic AI》를 내렸다. 여러 매체는 GPTZero의 조사를 인용해 보고서 안의 많은 인용과 사례가 출처와 정확히 맞지 않는다고 전했다. TechCrunch도 UBS, 영국 NHS, 스위스 연방철도, Transport for London 등이 보고서에 나온 자사 AI 사용 현황 설명이 부정확하거나 오해를 부를 수 있다고 밝혔다고 보도했다. KPMG는 보고서를 삭제하고 조사에 착수했으며, 책임 있는 AI 사용에는 사람의 감독, 내용 검증, 독립 출처 확인이 필요하다고 강조했다.
이 사건은 단지 “컨설팅 회사도 실수할 수 있다”는 이야기가 아니다. 일반 업무 담당자에게 더 실용적인 교훈은 이것이다. AI가 도와 쓴 내용이 보고서, 발표 자료, 백서, 제안서, 외부 공개 글이 된다면 검토의 핵심은 문장이 자연스러운지가 아니라 인용, 사례, 책임을 원자료까지 되짚을 수 있는지여야 한다.
이 글은 “AI가 보고서를 쓴 뒤 진짜 봐야 할 것은 문장이 아니라 인용이 버틸 수 있는지 여부다”를 독자가 바로 쓸 수 있는 하나의 판단 문제로 좁힌다. KPMG가 AI 환각이 의심되는 AI 도입 보고서를 내린 뒤, 정말 배워야 할 점은 이것이다. 고객, 상사, 외부 독자가 인용할 수 있는 모든 AI 보고서는 먼저 인용, 사례, 책임의 세 단계 검사를 거쳐야 한다. 아래 표와 체크리스트는 팀이 진행하기 전에 무엇을 확인하는 데 쓰면 된다.
AI 보고서에서 가장 위험한 오류는 본문에 숨어 있지 않을 수 있다
많은 사람은 AI가 만든 문서를 확인할 때 먼저 세 가지를 본다. 오탈자가 있는지, 논리가 자연스러운지, 회사 말투처럼 들리는지 여부다. 모두 중요하지만, 신뢰 손실을 가장 크게 일으키는 지점은 아니다.
진짜 문제는 “근거가 있어 보이는” 오류이다. 예를 들면 다음과 같다.
- 인용된 글이나 연구는 실제로 존재하지만 제목, 저자, 연도, 결론이 왜곡될 정도로 바뀌어 있다.
- 사례 속 회사는 실제로 존재하지만, 보고서가 말한 일을 한 적은 없다.
- 숫자는 그럴듯해 보이지만 원본 표, 조사 방법, 발표일을 찾을 수 없다.
- 각주는 많지만, 그 각주가 앞 문장을 뒷받침하는지 누가 열어 확인한 적은 없다.
GPTZero는 이런 현상을 일종의 “느낌으로 하는 인용”에 가까운 문제라고 설명했다. 겉으로는 인용처럼 보이지만 실제로는 진짜 출처, 가짜 제목, 잘못된 저자, 과도한 추론이 뒤섞여 있을 수 있다는 뜻이다. 독자에게는 아예 인용이 없는 경우보다 더 발견하기 어렵다. 문서 표면상으로는 이미 검증을 마친 것처럼 보이기 때문이다.
따라서 AI가 보고서 작성 흐름에 들어온 뒤에는 “그럴듯하게 썼는가”만 물어서는 안 된다. 더 먼저 물어야 할 질문은 이것이다. “이 문서에서 사람들이 인용이나 사례를 보고 믿게 될 문장은 무엇인가?”
먼저 보고서를 세 가지 검증 가능한 재료로 나누기
보고서 전체를 처음부터 끝까지 읽으면 매끄러운 문장에 쉽게 끌려간다. 더 안전한 방법은 검증해야 할 재료를 먼저 분리하는 것이다.
| 재료 유형 | 확인할 것 | 흔한 위험 |
|---|---|---|
| 인용 출처 | 글, 연구, 보고서, 법규, 공식 문서가 실제로 존재하는지, 바로 앞 문장을 뒷받침하는지 | 출처는 존재하지만 결론을 AI가 너무 멀리 바꾸었거나, 인용 형식은 진짜 같지만 세부 정보가 틀림 |
| 실명 사례 | 회사, 정부기관, 고객, 제품이 문서에 묘사된 일을 실제로 했는지 | 파일럿을 정식 도입처럼 쓰거나, 단일 기능을 전체 프로세스처럼 표현함 |
| 숫자와 시간 | 비율, 금액, 사용자 수, 발표일, 버전명을 원자료까지 추적할 수 있는지 | 오래된 숫자를 최신 상태처럼 쓰거나, 서로 다른 시장의 자료를 섞어 씀 |
이 표의 목적은 모두를 연구자로 만들려는 것이 아니라, 보고서를 보내기 전에 한 번 멈추게 하는 것이다. 어떤 문단이 예산, 구매, 계약, 고객 신뢰, 공개 평판에 영향을 준다면 AI가 만든 “그럴듯함”만 믿어서는 안 된다.
간단한 방법은 담당자가 모든 인용, 회사명, 숫자를 하나의 검증 표에 복사하게 하는 것이다. 각 행에는 최소한 네 칸이 있어야 한다. 원문 문장, 출처 링크, 출처 안의 대응 문장, 검증 상태이다. 대응 문장이 없다면 그 문장은 정식 문서에 남기지 말아야 한다.
세 단계로 판단하기: 문구 수정, 재작성, 공개 불가
모든 오류의 심각도가 같지는 않는다. 위험을 단계별로 나누어야 사소한 수정에 시간을 쓰느라 실제로 문제가 될 문단을 놓치지 않는다.
| 단계 | 예시 | 다음 조치 |
|---|---|---|
| 수정 가능 | 인용 형식이 불완전함, 날짜 형식이 틀림, 출처 링크를 보충해야 함 | 수정한 뒤 다시 열어 확인한다. 전체를 되돌릴 필요는 없다 |
| 반드시 다시 작성 | 사례 설명의 원출처를 찾을 수 없거나, 출처가 주장 일부만 뒷받침함 | 작성자나 AI 생성 흐름으로 돌려보내 출처가 뒷받침할 수 있는 버전으로 다시 쓴다 |
| 공개 불가 | 실명 기관이 부인함, 숫자가 사업 판단에 영향을 줌, 의료/법률/재무/보안 결론을 증명할 수 없음 | 공개를 중단하고 책임자가 삭제, 재작성, 관련자 통보, 정정 기록 보관 여부를 결정한다 |
여기서 “책임자”는 명목상 문서 소유자가 아니다. 문서를 외부에 낼지, 고객에게 알릴지, 수정 비용을 부담할지 결정할 수 있는 사람이다. AI는 자료 정리를 도울 수 있지만 잘못된 인용이 만든 신뢰 손실을 회사 대신 책임질 수는 없다.
팀에서 보고서의 최종 정리를 맡고 있다면 프로세스에 한 문장을 넣을 수 있다. AI가 도와 만든 외부 공개 문서는 출처의 대응 문장이 없는 인용과 사례를 정식본에 넣지 않는다. 이 문장은 “AI 환각을 조심해야 한다”보다 훨씬 실행하기 쉽다.
어떤 상황에서는 AI가 곧장 최종본까지 쓰게 하면 안 된다
어떤 문서는 AI가 먼저 초안을 정리하고 사람이 빠르게 다듬어도 된다. 내부 회의 요약, 설문 문항 초안, 인터뷰 핵심 정리 같은 문서이다. 원자료가 남아 있고, 독자가 그것이 초안임을 알고 있다면 위험은 비교적 통제 가능하다.
하지만 아래 상황에서는 AI가 초안에서 최종본까지 그대로 흘러가게 해서는 안 된다.
- 외부 공개 백서, 연구 보고서, 컨설팅 제안서, 보도자료.
- 고객, 협력사, 정부기관, 경쟁사 이름을 나열하는 문서.
- 구매, 투자, 예산, 감원, 컴플라이언스 의사결정을 뒷받침하는 발표 자료.
- 언론, 고객, 상사, 법무팀이 다시 인용할 수 있는 숫자와 결론.
이런 문서에는 AI를 첫 정리 단계에 활용할 수 있다. 다만 중간에 반드시 “출처 확인”과 “책임 확인”이라는 두 관문이 있어야 한다. 출처 확인은 각 핵심 문장이 원자료로 돌아갈 수 있는지 보는 것이고, 책임 확인은 누가 그 문장을 외부에 말해도 된다고 결정할 권한이 있는지 확인하는 것이다.
시간이 부족하다면 검증하지 않은 멋진 사례를 많이 남기기보다 보고서 범위를 줄이는 편이 낫다. 사례가 없는 정직한 보고서는 대개 틀린 사례로 가득한 완성형 보고서보다 안전하다.
다음 AI 보고서를 전달하기 전에 검증 페이지를 하나 추가하기
가장 실용적인 변화는 모든 사람에게 “더 조심하라”고 요구하는 것이 아니라 문서 전달 패키지에 검증 페이지 한 장을 추가하는 것이다. 이 페이지는 복잡할 필요가 없다. 핵심 주장마다 다섯 가지 신호만 남기면 된다.
- 핵심 문장: 인용되거나, 재전달되거나, 의사결정에 쓰일 문장.
- 원출처: 공식 문서, 연구, 뉴스, 계약서, 내부 자료, 인터뷰 기록.
- 대응 증거: 출처 안에서 이 문장을 실제로 뒷받침하는 문단, 페이지 번호, 스크린샷 위치.
- 검증자: 출처를 실제로 열어 확인한 사람.
- 공개 판단: 유지, 재작성, 삭제, 다시 작성, 공개 중단.
이 검증 페이지는 AI 보고서 검토를 “보기 좋고 자연스러운가”에서 “근거가 버틸 수 있는가”로 바꾼다. 책임도 더 분명해진다. AI는 작성자, 검토자, 발행자가 아니다. 자료 정리를 돕는 도구일 뿐이다. 마지막에 내용을 밖으로 내보내는 것은 여전히 팀이다.
KPMG의 이번 사건은 AI 환각이 채팅창 안에서만 나타나는 것이 아니라 보고서, 각주, 사례로 포장되어 실제 비즈니스 의사결정 안으로 들어갈 수 있음을 보여 준다. 다음에 AI가 도와 만든 멋진 문서를 보게 된다면 효율적이라고 칭찬하기 전에 먼저 더 중요한 질문을 던져야 한다. 이 인용과 사례는 정말 확인할 수 있는가?
AI 정리 카드
이 판단표를 오늘의 다음 행동으로 옮기기 이 프롬프트는 AI가 먼저 배경을 묻고 나서 판단하게 한다. 글 요약이 아니라 내 업무 흐름 점검에 쓰는 용도다.
이 BMC 미니 레슨을 내 상황에 적용하고 싶다: AI가 보고서를 쓴 뒤 진짜 봐야 할 것은 문장이 아니라 인용이 버틸 수 있는지 여부다
이 글이 다루는 구체적인 문제: KPMG가 AI 환각이 의심되는 AI 도입 보고서를 내린 뒤, 정말 배워야 할 점은 이것이다. 고객, 상사, 외부 독자가 인용할 수 있는 모든 AI 보고서는 먼저 인용, 사례, 책임의 세 단계 검사를 거쳐야 한다.
글 URL: https://boosterminiclass.com/ko/posts/ai-report-citation-failure-review-checklist/
글을 요약만 하지 말아 달라. 먼저 다음 3가지를 확인하는 질문을 해 달라.
1. 내가 지금 다루는 실제 워크플로 또는 의사결정은 무엇인가.
2. 이 흐름에 어떤 데이터, 권한, 계정, 비용, 외부 실행이 관련되는가.
3. 오늘 필요한 결과가 중단/진행 판단, 시험 도입 체크리스트, 인수인계 템플릿, 위험 등급 중 무엇인가.
그다음 이 글의 프레임워크로 내 상황을 점검해 달라: 1. 이 AI 보조 보고서를 누가 인용하고 어떤 의사결정에 사용할지 먼저 나열한다; 2. 모든 인용, 사례, 숫자, 고객명을 분리해 항목별로 검증한다; 3. 세 단계 표로 어떤 오류는 문구 수정이면 되는지, 어떤 오류는 다시 작성해야 하는지, 어떤 오류는 외부 공개가 불가능한지 판단한다; 4. 다음 보고서를 위해 출처 스크린샷, 사람의 재검토, 책임자 승인 칸을 만든다.
다음 형식으로 출력해 달라:
- 지금 바로 진행, 제한적으로 시험, 일단 중단 중 무엇인지 한 문장 판단;
- 프레임워크를 내 상황에 적용한 표: 준비됨 / 근거 부족 / 사람 확인 필요;
- 오늘 할 수 있는 가장 작은 한 단계;
- 담당자, 로그, 되돌리기, 사람 검토가 필요한 지점.
답변은 초안으로 보고, 실행 전 데이터·권한·책임 범위를 사람이 확인한다.
참고 자료
- TechCrunch: KPMG pulls report on AI usage due to apparent hallucinations — https://techcrunch.com/2026/06/13/kpmg-pulls-report-on-ai-usage-due-to-apparent-hallucinations/
- GPTZero: Chasing the Hallucinations: KPMG’s AI-Powered Attempt at “Redefining Excellence” — https://gptzero.me/news/investigations-kpmg/
- The Register: KPMG’s AI report becomes an accidental demo of AI hallucinations — https://www.theregister.com/ai-and-ml/2026/06/12/kpmgs-ai-report-turns-into-a-demo-of-ai-hallucinations/5255029
- Finance Monthly: KPMG Pulls AI Report After UBS, NHS and Transport for London Case Studies Found to Contain Hallucinations — https://www.finance-monthly.com/kpmg-ai-report-hallucinations-ubs-nhs-transport-for-london/



