LLM 할루시네이션이 사내 AX 의 진짜 함정인 이유, 5가지 방어 패턴

지난 주에 베비투스랩이 직접 마주친 사례입니다. 블로그 글 평가용으로 외부 오픈소스 두 개의 GitHub 정보를 WebFetch 로 가져왔습니다. 결과를 보니 stars 376,000, 출시 2026년 1월, 라이선스 MIT 라고 명확하게 적혀 있었습니다.

그대로 글에 인용했으면 거짓 글이 됐습니다. 검증 차원에서 GitHub REST API 로 ground truth 를 다시 잡아보니 stars 는 맞았지만 라이선스는 NOASSERTION, 출시 일자도 미세하게 달랐습니다. WebFetch 의 작은 모델이 그럴듯한 디테일을 환각으로 채워 넣은 케이스였습니다.

Karpathy 의 표현을 빌리면 LLM 은 본질적으로 "dream machine" 입니다. 100% 꿈을 꾸는 도구가 가끔 진실을 말하는 것이지, 진실을 말하는 도구가 가끔 꿈을 꾸는 게 아닙니다. 사내 AX 도입의 가장 큰 함정이 정확히 여기 있습니다.

할루시네이션이 사내 AX 에 위험한 이유

ChatGPT 데모에서는 할루시네이션이 가끔 보입니다. "5% 정도 틀리네" 정도의 인상입니다. 그러나 사내 시스템 운영에서는 5% 가 곧 매출 손실·고객 이탈·규제 위반입니다.

베비투스랩이 운영 중에 자주 보는 영역은 다음 3 가지입니다.

첫째 재무 데이터 자동 분석입니다. AI 가 매출 보고서를 자동 생성할 때 숫자를 그럴듯하게 만들어냅니다. "전년 대비 17.3% 증가" 같은 정확해 보이는 수치가 실제 데이터와 다를 수 있습니다. 임원이 그대로 의사결정에 쓰면 큰 비용으로 돌아옵니다.

둘째 법규·정책 검토입니다. 사내 컴플라이언스 검토에 AI 를 쓸 때 존재하지 않는 법령 조항을 인용합니다. 법무팀이 검토 없이 그대로 답변 보내면 클라이언트에게 잘못된 정보가 갑니다.

셋째 CS 자동 답변입니다. 회사 매뉴얼에 없는 정책을 AI 가 만들어내고 그게 답변으로 나갑니다. 고객이 "AI 가 그렇게 답했는데요" 하면 회사는 정책으로 인정해야 하나 거부해야 하나 진퇴양난에 빠집니다.

세 영역 다 공통점이 있습니다. 결과물이 그럴듯하게 보여서 검토 없이 넘어가기 쉽다는 점입니다.

베비투스랩이 쓰는 5 가지 방어 패턴

1. Ground truth 검증 게이트

LLM 출력을 그대로 신뢰하지 않고 원본 데이터와 자동 비교합니다. 위의 GitHub 환각 사례에서 베비투스랩이 한 게 정확히 이 패턴입니다. WebFetch 결과를 한 번 받고 REST API 로 한 번 더 받아 두 결과의 핵심 필드 (stars·라이선스·출시일) 를 비교합니다. 차이가 있으면 ground truth 를 채택합니다.

사내 시스템에서는 ERP·CRM 의 원본 DB 를 한 번 더 조회해 LLM 출력의 수치가 일치하는지 자동 검증하는 layer 가 필요합니다.

2. RAG + 출처 인용 강제

AI 가 답변할 때 "어디서 가져온 정보인지" 명시하게 강제합니다. RAG (검색 증강 생성) 가 회사 매뉴얼에서 직접 인용한 부분은 안전하지만 AI 가 자체 학습 지식으로 답한 부분은 환각 위험이 있습니다.

베비투스랩이 사내 시스템 AI 도입 패턴 ⑤ (CS 티켓 자동 분류·1차 답변) 에서 RAG 구축에 6 주가 든다고 적은 이유도 같습니다. 출처 추적 가능한 답변 architecture 가 RAG 의 핵심입니다.

3. 사람 마지막 결재 (도메인 게이트)

수치·법규·정책 같은 high-stakes 도메인은 AI 가 결정하지 않습니다. 추천만 하고 사람이 마지막 결재합니다. 베비투스랩이 사내 시스템 AI 도입 5 가지 패턴의 공통 원칙으로 정리한 그대로입니다.

문제는 어디가 high-stakes 인지 분류입니다. CS 1 차 답변은 low-stakes 라 자동 발송 가능하지만 의료·법무·재무는 high-stakes 라 무조건 사람 검토 필수입니다. 이 분류 자체가 사내 AX 도입의 핵심 의사결정입니다.

4. 도메인 검증기 (rule-based)

LLM 위에 rule-based 검증 layer 를 둡니다. 의료 용어 사전·법령 DB·사내 코드 표준 같은 ground truth 와 LLM 출력을 자동 매칭합니다. 매칭 안 되면 LLM 답변을 reject 하거나 사람 검토로 raise 합니다.

이번 블로그 스킬에 박은 grep 게이트 (em-dash·콜론 4 가지 패턴 0 건이어야 통과) 가 정확히 같은 layer 입니다. LLM 이 만든 글을 검증기가 reject 합니다.

5. 측정 가능한 9 의 개수

이전 글에서 정리한 Karpathy 의 "5 의 9" 관점이 그대로 적용됩니다. 사내 AX 의 각 자동화가 몇 개 9 (90% / 99% / 99.9% / 99.99%) 의 정확도인지 측정합니다. 측정 안 하면 도구의 "데모는 멋있어 보임" 만 보고 자율 운영을 풀게 됩니다.

매주 또는 매월 정확도 측정 리포트가 자동으로 나오는 quality gate 가 필요합니다. 9 의 개수가 한 자릿수 떨어지면 자동 운영을 멈추고 사람 검토로 전환합니다.

솔직히 말씀드리면

베비투스랩도 글 쓰는 과정에서 LLM 환각으로 1 차 결과를 그대로 인용할 뻔한 적이 있습니다. 운 좋게 검증 게이트가 잡았지만 그게 없었으면 거짓 글이 발행됐을 겁니다.

사내 시스템에서는 운이 아니라 architecture 가 잡아줘야 합니다. ChatGPT 가 "이렇게 답하면 멋있다" 는 데모에서 그치는 도구라면 사내 AX 는 100% 운영입니다. 운영에서는 운이 아니라 검증 가능한 시스템이 필요합니다.

베비투스랩의 결론

LLM 할루시네이션은 버그가 아니라 LLM 의 본질입니다. Karpathy 의 "dream machine" 표현이 그래서 정확합니다. 사내 AX 도입은 그 본질을 인정한 위에서 5 가지 방어 패턴 (ground truth 검증·RAG 출처·사람 결재·도메인 검증기·9 의 개수 측정) 을 깔아야 운영 단계에서 무너지지 않습니다.

베비투스랩이 매일 쓰는 5 가지 하네스 (CLAUDE.md·permissions·quality gate·sub-agent isolation·worktree) 가 정확히 이 5 가지 방어 패턴과 매핑됩니다. 도구 (ChatGPT·Claude·DeepSeek) 는 갈아끼울 수 있지만 할루시네이션 방어 architecture 는 5 년을 갑니다.

이게 베비투스랩이 4 가지 약속 중 Foundation 을 첫 약속으로 두는 이유입니다. 데모는 누가 만들어도 멋있지만 환각 없는 운영은 시니어 PE 가 architecture 차원에서 잡아야만 가능합니다.

---

우리 회사가 어떤 영역에서 할루시네이션 위험이 있는지 함께 점검하고 싶으면 3 분 AX 진단 으로 회사 단계부터 확인하시거나 30 분 무료 상담 에서 검증 architecture 를 함께 정리합니다.