KPMG도 당한 AI 할루시네이션, 결제·정산팀이 배울 것

KPMG가 보고서를 내렸다 — 숫자가 아니라 신뢰가 무너졌다

2026년 6월, 세계 4대 회계법인 중 하나인 KPMG는 스스로 발행한 AI 활용 현황 보고서를 돌연 회수했다. 이유는 단순하고 아이러니했다. 보고서 안에 AI가 만들어낸 그럴듯한 거짓 데이터, 즉 할루시네이션이 포함되어 있었다. AI가 AI에 대해 거짓말을 한 것이다.

"또 AI가 틀렸네"로 넘길 수 없는 이유가 있다. KPMG는 컨설팅·감사·세무 영역에서 수십 년간 팩트 검증 역량을 쌓아온 조직이다. 연간 매출 약 400억 달러 규모의 그 조직이 AI 생성 콘텐츠를 검증 없이 배포했다가 회수했다는 것은, 규모나 브랜드와 무관하게 AI 출력을 그대로 신뢰하는 것이 얼마나 위험한가를 보여주는 사례다. 우리처럼 결제·정산·자동화를 직접 운영하는 작은 팀에게 이 사건은 경보음이다. 우리가 쓰는 AI 도구들이 출력하는 숫자, 요약, 보고서 초안 — 그 어느 것도 KPMG가 받은 것보다 본질적으로 더 신뢰할 수 없다.

AI가 AI를 틀리게 설명한다 — 왜 결제 현장과 직결되나

이번 사건에서 특히 주목할 지점은 '주제'다. KPMG가 작성한 것은 AI '활용 현황'에 관한 보고서였다. AI 도구가 AI 도구에 관해 쓴 글이 틀렸다는 것은, 모델이 자신의 작동 방식이나 업계 통계에 대해 특히 확신에 찬 오류를 낼 수 있음을 시사한다. 스스로 잘 안다고 여기는 영역에서 더 당당하게 틀리는 것이다.

결제·정산 맥락으로 치환해 보자. 우리 팀은 AI를 다음 맥락에서 쓴다: 이상 거래 탐지 결과 요약, 월간 정산 리포트 초안 작성, 파트너사 정산 기준 해석 보조, 카드사 수수료 구조 분석. 이 중 어느 하나라도 AI가 그럴듯하게 틀린 숫자를 집어넣으면 어떤 일이 생길까. 정산 리포트에서 수수료율이 2.3%에서 2.1%로 잘못 표기되어 파트너사로 전달됐다고 가정하자. 파트너사가 이 수치를 내부 ERP에 반영하고 다음 달 정산 이의를 제기한다. 이의 처리, 수동 검증, 재정산에 드는 시간은 최소 수 시간 — 작은 팀에게 이것은 하루치 여력이다. 숫자 하나가 만드는 파급 효과다.

0.1% 오류율이 만드는 현실적 파국

구체적인 수치로 생각해 보자. 월 100만 건 규모의 트랜잭션을 처리하는 결제 시스템에서 AI 요약 도구가 0.1%의 오류율로 금액을 잘못 집계한다면, 이는 1,000건의 오분류다. 건당 평균 거래 금액이 5만 원이라고 해도 잠재적 오차는 5,000만 원 규모가 된다. 이것이 감사에서 발견되면 설명 부담은 고스란히 팀에게 돌아온다.

KPMG 사례에서 우리가 배워야 할 트레이드오프는 이것이다. 속도 vs. 신뢰성. AI를 쓰면 보고서 초안 작성 시간이 90% 줄어들 수 있다. 하지만 검증 없이 배포했을 때 회수 비용 — 신뢰 손실, 재작업 시간, 파트너사·감사인과의 해명 커뮤니케이션 — 이 그 절감분을 순식간에 초과한다. KPMG가 실증했다. 더 까다로운 문제는 할루시네이션이 '틀린 티가 나는 방식'으로 오지 않는다는 것이다. KPMG 보고서의 오류가 즉각 눈에 띄었다면 배포 전에 잡혔을 것이다. 모델은 그럴듯한 형식, 그럴듯한 출처 언급, 그럴듯한 수치 범위 안에서 틀린다. 결제 현장에서 이것은 치명적이다 — 수치가 '그럴듯한 범위 안에 있어서' 검토자가 그냥 넘기는 상황이 발생한다.

HEDVION이라면 — 우리 팀의 대응 시나리오

우리 팀은 AI를 쓰지 않는 것이 답이 아님을 안다. 작은 팀이 높은 처리량을 소화하려면 자동화는 필수다. 문제는 'AI를 쓸 것인가'가 아니라 'AI 출력을 어느 단계에서, 어떤 방식으로 검증할 것인가'다.

우리가 현재 운영하거나 검토 중인 구조는 세 레이어다. 레이어 1 — 구조화된 출력 강제. 자유 형식 텍스트 대신 JSON 스키마로 출력을 고정한다. 정산 요약이라면 {"merchant_id": ..., "total_txn": ..., "settlement_amount": ..., "fee_rate": ...} 형태로만 받고 스키마 바깥 값은 즉시 오류 처리한다. 모델이 수치를 자유롭게 만들어낼 여지를 구조적으로 줄이는 것이다. 레이어 2 — 크로스 체크 자동화. AI가 집계한 정산 금액을 원천 트랜잭션 DB에서 직접 SQL 집계한 값과 자동으로 비교한다. 차이가 설정된 임계값(예: 0.05%)을 초과하면 사람이 검토하기 전까지 파트너사 발송이 자동 보류된다. AI 요약이 틀려도 DB 값이 최종 보루가 된다. 레이어 3 — '출처 있는 주장만 허용' 프롬프트 설계. 보고서나 분석 문서를 AI로 초안 작성할 때 반드시 내부 데이터를 컨텍스트로 첨부하고 "첨부 데이터에 없는 수치는 절대 사용하지 마라"는 지시를 명시한다. 외부 통계를 AI가 '기억'에서 꺼내는 것을 막는 것이다.

이 세 레이어가 모두 작동하더라도 100% 안전을 보장하지는 않는다. 하지만 KPMG처럼 AI 출력을 검증 없이 그대로 배포하는 것과는 완전히 다른 위험 수준이다.

AI 개발서가 말하는 것과 현실의 간극

최근 나온 AI 엔지니어링 관련 서적들과 실무 가이드 — 이른바 'AI 개발 책'류 — 가 공통적으로 강조하는 것이 있다. AI는 확신도(confidence)와 정확도(accuracy)가 비례하지 않는다. 모델은 틀릴 때도 맞을 때와 거의 같은 수준의 확신으로 답한다. 이것이 전통적인 소프트웨어 버그와 근본적으로 다른 점이다.

전통적인 버그는 크래시나 명백한 이상값을 낸다. AI 할루시네이션은 '그럴듯하게 통과'된다. KPMG의 경우처럼 보고서 형식이 완벽하고 문장이 유려하고 수치가 그럴듯한 범위에 있으면 초안 검토자가 실제로 팩트 체크를 생략할 확률이 높아진다. 이를 'automation bias'라 부른다 — 자동화된 시스템의 출력을 맹목적으로 신뢰하는 인간의 경향이다. 책에서는 이론으로 배우지만, KPMG는 2026년에 그 이론을 실물 사고로 증명했다. 결제·정산 도메인에서 automation bias는 특히 위험하다. 우리가 다루는 수치들은 계약, 세금, 규제 보고에 직결된다. "AI가 그렇게 요약했으니까"는 감사인 앞에서 변명이 되지 않는다.

지금 당장 써먹는 실행 시사점

KPMG 사태를 교훈 삼아, 소규모 결제·정산 팀이 오늘부터 바로 적용할 수 있는 구체적 행동 항목이다.

① AI 출력 배포 전 체크리스트를 문서화한다. 지금 당장 노션이나 컨플루언스에 한 페이지짜리 문서를 만들어라. "외부 전송 전 AI 생성 콘텐츠에 포함된 수치는 원천 데이터와 대조 완료했는가?" 이 질문 하나만 있어도 KPMG 수준의 실수는 막을 수 있다.

② 정산 관련 문서에 AI 출처 태그를 의무화한다. 내부 문서라도 "이 초안은 AI로 작성됨, 수치 검증 필요" 태그를 달아라. 팀원이 AI 출력을 그대로 전달하는 관행을 방지하는 가장 저비용 방법이다.

③ 외부 통계가 필요한 보고서는 AI에 맡기지 않는다. 내부 데이터 집계·요약은 AI가 잘한다. 그러나 "업계 평균 수수료율", "국내 결제 시장 규모" 같은 외부 통계는 모델이 훈련 데이터에서 꺼내는데 — 이게 정확히 KPMG가 당한 방식이다. 외부 통계가 필요하면 직접 1차 출처를 확인해라.

④ 크로스 체크 자동화를 최소 1개 파이프라인에 먼저 적용한다. 가장 중요한 월간 정산 파이프라인 하나를 골라, AI 집계값과 DB 직접 쿼리값을 자동 비교하는 스크립트를 이번 주 안에 작성한다. 완벽한 시스템보다 작동하는 단 하나의 검증 레이어가 낫다.

⑤ 팀 내 'AI 오류 발견 사례' 공유 채널을 만든다. KPMG처럼 크게 당하기 전에, 팀원이 AI 출력에서 이상값을 발견했을 때 바로 공유할 채널을 지금 열어라. 이 데이터가 쌓이면 어떤 작업에 AI를 쓰면 안 되는지 실제 패턴이 보인다.

KPMG가 보고서를 내린 것은 망신이지만, 그들은 인지하고 빠르게 회수했다. 더 나쁜 시나리오는 틀린 보고서가 조용히 유통되어 다운스트림 의사결정에 쓰이는 것이다. 우리 팀에서 그 다운스트림 의사결정이 결제 파트너와의 계약이거나 정산 분쟁이라면, 회수 버튼이 없을 수 있다.

원문: AI News & Artificial Intelligence | TechCrunch