EY 캐나다 보고서에 가짜 인용 가득 - 컨설팅 회사도 AI 환각에 무너지다

4대 회계법인의 보고서에서 발견된 "존재하지 않는 출처"

EY(Ernst & Young) 캐나다가 최근 발표한 사이버보안 보고서가 인터넷에서 큰 논란을 만들고 있어요. 문제는 보고서의 내용이 아니라 출처거든요. 보고서에 인용된 참고문헌과 통계 자료 중 상당수가 "실제로 존재하지 않는" 가짜였다는 사실이 GPTZero라는 AI 탐지 서비스의 조사로 드러난 거예요. EY는 딜로이트, KPMG, PwC와 함께 세계 4대 회계법인(Big 4) 중 하나로, 컨설팅 보고서의 신뢰성이 곧 회사의 자산인 곳이에요. 그런 회사가 이런 일을 겪었다는 게 충격이죠.

GPTZero의 분석에 따르면 보고서에 인용된 링크들 중 상당수가 클릭하면 404 페이지로 가거나, 존재하지 않는 보고서를 가리키거나, 실제로는 다른 내용의 페이지로 연결됐다고 해요. 통계 수치의 출처라며 적혀 있는 기관 보고서를 직접 찾아가 봐도 그런 수치가 없는 경우도 있었고요. 이건 전형적인 LLM 환각(hallucination)의 패턴입니다. ChatGPT나 Claude 같은 대형 언어모델이 "그럴듯해 보이는" 출처를 지어내는 그 현상이요.

환각은 왜 생기고, 왜 출처에서 특히 자주 터지나

LLM이 환각을 일으키는 이유를 잠깐 풀어드릴게요. 대형 언어모델은 사실 "다음에 올 단어를 확률적으로 예측하는" 기계예요. 학습 데이터에서 "보안 사고 증가율은" 다음에 "X%였다(출처: Y기관, 2023)"라는 패턴을 수없이 봐왔기 때문에, 비슷한 문맥이 나오면 통계적으로 그럴듯한 숫자와 출처를 "생성"해요. 실제로 그런 통계가 있는지 확인하는 게 아니라, 그런 형태의 문장이 나올 법한 자리니까 만들어내는 거죠.

특히 URL과 인용은 환각이 잘 일어나는 영역이에요. URL은 패턴이 규칙적이거든요. https://www.gartner.com/en/newsroom/press-releases/2023-... 같은 형태가 학습 데이터에 많으니까, 모델은 이 패턴을 흉내내서 그럴싸한 URL을 만들어요. 그런데 실제로 그 페이지가 있는지 모델은 알 수가 없죠. 학술 논문 인용에서도 같은 일이 벌어져요. 저자명, 학술지명, 권호, 페이지 번호 형식은 다 맞는데 실제 그런 논문이 없는 거예요. 미국에서는 변호사가 ChatGPT가 만들어낸 가짜 판례를 법원에 제출했다가 제재받은 사건이 여러 건 있었어요.

EY 보고서가 LLM으로 작성됐는지는 아직 EY가 공식 확인한 건 아니지만, 가짜 인용의 패턴을 보면 사람이 일부러 위조했다기보다는 AI가 생성한 텍스트를 검수 없이 그대로 실은 정황이 강해요. 사람이 위조한다면 적어도 실존하는 기관과 그럴듯한 보고서 제목을 찾아서 끼워넣지, 클릭하면 바로 404가 뜨는 URL을 만들지는 않거든요.

컨설팅 업계의 AI 도입 광풍, 그리고 그 부작용

맥락을 좀 더 넓게 보면 이번 사건은 우연이 아니에요. 4대 회계법인은 지난 2년간 생성형 AI에 막대한 투자를 해왔어요. PwC는 OpenAI와 10억 달러 규모의 파트너십을 맺었고, KPMG는 Microsoft와 손잡고 Azure OpenAI를 전사 도입했죠. EY도 EYQ라는 자체 AI 플랫폼을 만들어서 컨설턴트들이 보고서 초안을 빠르게 뽑아낼 수 있게 했고요. 컨설팅 단가가 높은 만큼, AI로 생산성을 끌어올리면 마진이 크게 좋아지거든요.

문제는 검수 프로세스가 AI의 속도를 못 따라간다는 점이에요. 예전엔 주니어 컨설턴트 여러 명이 며칠 동안 만들 자료를 이제 한 사람이 한나절에 뽑아낼 수 있는데, 시니어의 리뷰 능력은 그대로니까 결국 검수가 형식적으로 끝나는 거죠. 특히 인용과 출처는 "확인하려면 일일이 클릭해봐야 하는" 노동집약적 작업이라서, 바쁘면 가장 먼저 생략돼요.

비슷한 사건은 계속 늘고 있어요. 작년에 시카고 선타임스가 게재한 여름 추천 도서 목록에 존재하지 않는 책이 다수 포함됐던 일, 호주의 컨설팅사 딜로이트가 정부에 제출한 보고서에서 가짜 인용이 발견돼 환불해줬던 일 같은 게 대표적이에요. 이번 EY 건은 그 흐름의 연장선상에 있어요.

개발자 입장에서 배울 점

AI 도구를 코드 작성에 쓰는 우리에게도 똑같은 교훈이 있어요. Claude나 Cursor가 만들어준 코드에 존재하지 않는 라이브러리 함수가 호출되거나(이걸 "패키지 환각"이라고 부르는데, 실제로 공격자들이 이 환각된 이름으로 악성 패키지를 npm에 미리 올려두는 슬롭스쿼팅 공격까지 나왔어요), 실제로는 다른 시그니처를 가진 API를 정확한 것처럼 호출하거나 하는 경우가 흔하거든요. "AI가 만든 결과물은 반드시 실행해보고 검증한다"는 원칙은 보고서를 쓰는 컨설턴트나 코드를 짜는 개발자나 똑같이 적용돼야 해요.

실무에서 바로 적용할 수 있는 팁 몇 가지를 정리해볼게요. 첫째, AI가 인용한 출처는 무조건 한 번 클릭해서 확인하세요. 둘째, 통계 수치는 원본 데이터를 다시 한 번 찾아보세요. 셋째, 외부에 나가는 문서일수록 "AI가 작성한 부분"과 "사람이 작성한 부분"을 내부적으로 구분해서 관리하면 검수 우선순위를 정하기 쉬워요. 넷째, 사내 RAG(검색 증강 생성) 시스템을 도입할 때는 "근거 문서 링크를 반드시 같이 출력하게" 설계해서, 환각 여부를 즉시 확인할 수 있게 만드세요.

마무리

이번 EY 사건은 AI 시대의 신뢰 문제를 압축적으로 보여줘요. 도구는 강력해졌는데 그 도구를 어떻게 책임 있게 쓸지에 대한 프로세스는 아직 정비되지 않은 거죠. 여러분 회사에서는 AI가 만든 결과물을 외부에 내보내기 전에 어떤 검증 단계를 거치고 있나요? 그리고 "AI 사용 명시"를 의무화하는 게 맞는다고 생각하시나요, 아니면 결과물 품질만 보장되면 그만이라고 보시나요?