환각은 거짓말이 아니다
LLM을 처음 써 본 사람이 가장 당황하는 순간은 대개 비슷하다. 답변은 매끄럽다. 문장도 자연스럽다. 심지어 말투에는 자신감이 넘친다. 그런데 확인해 보면 핵심 사실이 틀려 있다. 존재하지 않는 논문을 인용하거나, 실제와 다른 제품 기능을 설명하거나, 문서에 없는 내용을 요약문에 슬쩍 끼워 넣는다.
이 현상을 보통 '환각', 영어로는 hallucination이라고 부른다. 다만 이 단어 때문에 오해가 생기기 쉽다. LLM이 사람처럼 의도를 가지고 거짓말을 하는 것은 아니다. 더 정확히 말하면, 환각은 모델의 출력이 입력 맥락, 외부 사실, 또는 제시된 출처와 충분히 맞지 않는 현상이다. 여러 연구에서도 LLM 환각을 '유창하고 문법적으로는 자연스럽지만 사실적으로 틀리거나 외부 근거로 뒷받침되지 않는 생성'으로 설명한다.1
예를 들어 사용자가 어떤 회사의 환불 정책 문서를 넣고 '핵심만 요약해 줘'라고 요청했다고 하자. 문서에는 '구매 후 7일 이내 환불 가능'이라고 적혀 있는데, 모델이 '구매 후 30일 이내 환불 가능'이라고 답했다면 이는 환각이다. 이 경우 모델은 외부 세계의 일반 지식을 틀린 것이 아니라, 사용자가 제공한 문서와 모순되는 내용을 만든 것이다.
반대로 사용자가 '2026년 현재 어떤 라이브러리의 최신 버전은 무엇인가?'라고 물었는데, 모델이 학습 시점 이후의 정보를 모른 채 그럴듯한 버전 번호를 만들어 냈다면 이것도 환각이다. 이번에는 입력 문서와의 모순이라기보다 외부 사실과의 불일치에 가깝다.
환각을 이해할 때 중요한 점은 '틀렸다'라는 결과만 보는 것이 아니라 '무엇에 근거해야 했는가'를 함께 봐야 한다는 것이다. 모델이 창작 소설을 쓰면서 가상의 도시 이름을 만든 것은 환각이 아니다. 사용자가 사실 확인이 필요한 보고서를 요청했는데, 존재하지 않는 도시 통계를 만든다면 환각이다. 같은 문장이라도 작업의 목적과 기대되는 근거에 따라 문제가 될 수도 있고, 아닐 수도 있다.
다음 토큰 예측은 사실 검증이 아니다
이 책의 앞부분에서 계속 확인한 것처럼 LLM의 기본 학습 목표는 다음 토큰 예측이다. 앞에 놓인 문맥을 보고 다음에 올 법한 토큰에 확률을 매기고, 그중 하나를 선택한다. 이 방식은 놀라울 정도로 강력하다. 문법, 문체, 개념 사이의 관계, 질문과 답변의 형식, 코드의 구조까지 많은 패턴을 배울 수 있다.
하지만 다음 토큰 예측은 '참인지 거짓인지 판정하는 과정'과 같지 않다. 모델은 문장을 생성할 때 매 순간 '이 문장이 실제 세계와 일치하는가?'를 별도의 데이터베이스에 조회하지 않는다. 학습 과정에서 엄청난 양의 텍스트 패턴을 압축해 두었다가, 현재 문맥에서 자연스러운 이어쓰기를 수행한다.
바로 이 지점에서 유창함과 사실성이 갈라진다. 어떤 문장이 자연스럽다고 해서 반드시 참인 것은 아니다. '이 논문은 2024년 네이처에 게재되었다'라는 문장은 그럴듯한 학술 문장이다. 그러나 실제로 그 논문이 존재하는지, 저널이 맞는지, 연도가 맞는지는 별개의 문제다. LLM은 유창한 표현을 만드는 데 매우 능숙하지만, 그 능력만으로는 사실 검증기가 되지 않는다.
OpenAI도 언어 모델의 환각이 단순히 운 나쁜 오류가 아니라, 현재의 평가 방식과 학습 인센티브가 '모르겠다'보다 '그럴듯하게 추측하기'를 유리하게 만들 수 있다는 점을 지적한다.2 사람도 시험에서 모르는 문제를 만났을 때 빈칸으로 두는 것보다 찍는 편이 점수에 유리하다면, 찍는 행동을 더 자주 하게 된다. 모델도 비슷하다. '모르면 모른다고 말하라'는 행동이 충분히 보상되지 않으면, 빈칸을 남기기보다 문장을 이어 가는 쪽으로 기울 수 있다.
물론 최신 LLM은 단순한 자동완성기보다 훨씬 정교하다. 지도 미세조정, Instruction Tuning, RLHF, DPO 같은 정렬 과정을 거치며 사용자 지시를 따르고 안전하게 답하려는 행동을 배운다. 그러나 그 과정이 모델을 완전한 진실 판정기로 바꾸지는 않는다. 정렬은 답변 습관을 개선하지만, 모든 사실을 실시간으로 검증해 주지는 않는다.
환각을 키우는 세 가지 층
환각의 원인은 하나가 아니다. '모델이 멍청해서'라고 말하면 너무 단순하고, '프롬프트를 잘못 써서'라고 말해도 절반만 맞다. 실제로는 데이터, 학습, 추론이라는 여러 층이 함께 작용한다.
첫 번째는 데이터의 문제다. LLM은 방대한 텍스트에서 배운다. 그 안에는 정확한 백과사전식 설명도 있지만, 오래된 정보, 틀린 정보, 광고성 문장, 편향된 주장, 서로 모순되는 자료도 섞여 있다. 어떤 회사의 정책은 작년에 바뀌었고, 어떤 라이브러리의 API는 새 버전에서 사라졌고, 어떤 통계는 조사 기관마다 기준이 다를 수 있다. 모델은 이 모든 흔적을 확률적 패턴으로 압축한다. 그래서 지식이 빈약한 주제, 최신 정보, 매우 좁은 전문 영역에서는 빈틈을 그럴듯한 말로 메우기 쉽다.
두 번째는 학습 목표의 문제다. 사전학습은 기본적으로 '그럴듯한 다음 토큰'에 보상을 준다. 이후의 미세조정은 '사용자에게 도움이 되는 답변'을 선호하게 만든다. 그런데 '도움이 됨'이 항상 '근거가 있음'과 같지는 않다. 사용자가 단호한 답변을 기대하는 것처럼 보이면 모델은 조심스럽게 되묻기보다 답을 만들어 내려 할 수 있다. 특히 프롬프트가 모호하거나 정보가 부족할 때 이런 경향이 커진다.
세 번째는 추론 과정의 문제다. 여기서 추론은 학습이 끝난 모델이 실제로 답변을 생성하는 순간을 뜻한다. 온도 temperature를 높이면 더 다양한 토큰을 시도하므로 창의성은 올라가지만 사실 중심 작업에서는 엉뚱한 방향으로 흐를 가능성도 커진다. 컨텍스트가 너무 길면 중요한 근거가 중간에 묻히거나, 검색된 문서가 많아도 관련성이 낮은 조각이 섞이면 모델이 잘못된 단서를 붙잡을 수 있다. RAG를 붙였는데도 검색기가 엉뚱한 문서를 가져오면, 모델은 그 엉뚱한 근거를 바탕으로 또렷한 답변을 만들 수 있다.
정리하면 환각은 모델 하나만의 문제가 아니다. 데이터에 무엇이 들어갔는지, 어떤 목표로 학습되었는지, 어떤 프롬프트와 문맥이 주어졌는지, 검색이나 도구 호출이 어떻게 연결되었는지가 모두 영향을 준다. 그래서 환각 완화도 한 가지 마법 주문으로 끝나지 않는다.
작은 오류가 답변 전체를 무너뜨리는 방식
LLM의 생성은 한 번에 완성된 문장을 꺼내는 방식이 아니다. 한 토큰씩 이어 붙인다. 이 특성 때문에 초반의 작은 선택이 뒤쪽 전체에 영향을 줄 수 있다.
예를 들어 모델이 어떤 사람의 이력을 설명한다고 하자. 첫 문장에서 '그는 2018년에 A 대학에서 박사학위를 받았다'고 잘못 생성했다. 다음 문장부터 모델은 이미 만들어진 이 문장을 문맥으로 삼는다. 그러면 '박사학위 논문은 무엇이었는가', '이후 어느 연구소에 들어갔는가' 같은 내용도 앞의 잘못된 가정에 맞춰 자연스럽게 이어질 수 있다. 처음에는 작은 오류였지만, 생성이 계속될수록 하나의 가짜 서사가 만들어진다.
이 현상은 긴 답변에서 더 자주 눈에 띈다. 짧은 답변에서는 틀릴 기회가 적다. 하지만 긴 보고서, 여러 단계의 추론, 복잡한 요약, 법률·의학·금융처럼 세부 조건이 많은 답변에서는 사실 불일치가 끼어들 틈이 많아진다. 특히 다음과 같은 작업은 환각에 취약하다.
출처, 논문, 판례, URL처럼 실제 존재 여부를 확인해야 하는 고유명사 생성
날짜, 수치, 가격, 버전 번호처럼 작은 차이가 큰 오류가 되는 정보 생성
긴 문서 요약, 다중 문서 비교, 여러 조건을 동시에 만족해야 하는 의사결정 보조
'문서에 없는 내용은 말하지 말라'는 제약이 필요한 문서 기반 질의응답
여기서 흥미로운 점은, 모델이 항상 터무니없는 답을 하는 것이 아니라는 사실이다. 환각은 대개 '너무 그럴듯한 형태'로 나타난다. 실제 논문 제목처럼 보이는 가짜 논문, 실제 법률 문장처럼 보이는 가짜 조항, 실제 API 문서처럼 보이는 가짜 함수가 위험한 이유가 여기에 있다. 틀렸지만 어색하지 않기 때문에 사용자가 그냥 지나치기 쉽다.
환각 탐지는 정답 맞히기보다 근거 찾기에 가깝다
환각을 탐지한다는 것은 단순히 '답이 맞았는가?'를 보는 일이 아니다. 더 중요한 질문은 '이 답변을 뒷받침하는 근거가 있는가?'이다. 특히 LLM 서비스를 만들 때는 모델의 최종 문장만 볼 것이 아니라, 그 답변이 어떤 입력, 어떤 검색 결과, 어떤 도구 호출에서 나왔는지를 함께 추적해야 한다.
가장 직접적인 방법은 출처 대조다. 답변 속의 사실 주장마다 근거 문서가 있는지 확인한다. RAG 시스템이라면 검색된 문서 조각과 최종 답변을 나란히 놓고, 각 문장이 문서에 의해 뒷받침되는지 확인할 수 있다. 답변이 문서의 표현을 그대로 베껴야 한다는 뜻은 아니다. 다만 답변의 핵심 주장이 문서에서 합리적으로 도출되어야 한다.
또 다른 방법은 자기 일관성 검사다. 같은 질문에 대해 모델을 여러 번 실행해 보고 답변이 얼마나 일관되는지 비교한다. SelfCheckGPT는 이런 아이디어를 활용한다. 모델이 어떤 사실을 비교적 안정적으로 알고 있다면 여러 번 생성해도 비슷한 내용을 말할 가능성이 높고, 반대로 환각성 내용은 샘플마다 서로 다른 주장으로 흩어질 가능성이 있다는 것이다.3 물론 여러 답변이 모두 같은 틀린 믿음을 공유할 수도 있으므로, 자기 일관성은 진실의 증명이 아니라 위험 신호를 찾는 도구로 이해해야 한다.
불확실성을 측정하는 연구도 있다. 단순히 토큰 확률만 보는 것이 아니라, 여러 생성 결과가 의미 단위에서 얼마나 갈라지는지를 보는 방식이다. Semantic Entropy 연구는 답변들을 의미가 같은 그룹으로 묶고, 의미 수준의 불확실성이 클수록 허구적 생성 가능성이 커질 수 있음을 보였다.4 쉽게 말해 모델이 같은 질문에 대해 '파리', '리옹', '마르세유'를 오락가락한다면 단어 선택의 다양성이 아니라 의미 자체의 불안정성이 드러난 것이다.
벤치마크도 활용된다. HaluEval처럼 질문답변, 지식 기반 대화, 요약 등에서 환각 여부를 평가하도록 만든 데이터셋은 모델이나 프롬프트, RAG 파이프라인을 비교할 때 도움이 된다.5 다만 앞 장에서 보았듯 벤치마크 점수는 출발점일 뿐이다. 실제 제품에서는 우리 사용자가 묻는 질문, 우리 문서의 구조, 우리 도메인의 위험도를 반영한 자체 평가 세트가 반드시 필요하다.
운영 환경에서는 로그 분석이 특히 중요하다. 어떤 질문에서 환각이 자주 생기는지, 검색 결과가 없을 때 모델이 어떻게 행동하는지, 특정 문서 유형에서 요약 오류가 많은지, 사용자가 어떤 답변을 다시 질문하거나 신고하는지 기록해야 한다. 환각은 추상적인 철학 문제가 아니라 반복해서 관찰하고 줄여야 하는 제품 품질 문제다.
완화는 여러 안전장치를 겹치는 일이다
환각을 완전히 없애는 단일 기법은 없다. 대신 작업의 성격에 맞춰 여러 장치를 겹쳐야 한다. 창작 글쓰기에서는 다양성이 중요하므로 환각이라는 말 자체가 덜 중요할 수 있다. 그러나 고객지원, 사내 지식 검색, 의료 정보 안내, 금융 리포트 요약처럼 사실성이 핵심인 작업에서는 모델이 자유롭게 말하도록 두면 안 된다.
가장 대표적인 완화 방법은 RAG다. 모델이 내부 기억만으로 답하지 않고, 외부 문서를 먼저 검색한 뒤 그 근거를 바탕으로 답하게 하는 방식이다. RAG는 LLM에게 오픈북 시험지를 주는 것과 비슷하다. 다만 오픈북이라고 해서 항상 정답을 쓰는 것은 아니다. 잘못된 책을 펼치거나, 맞는 문장을 잘못 읽거나, 책에 없는 내용을 자기 지식으로 보태면 여전히 틀릴 수 있다. 그래서 RAG의 핵심은 단순히 '검색을 붙였다'가 아니라 '검색 품질과 답변의 근거성을 함께 관리한다'에 있다.
도구 호출도 중요하다. 계산은 계산기에게 맡기고, 최신 가격은 데이터베이스에 묻고, 재고 상태는 내부 API에서 가져오고, 일정은 캘린더 시스템에서 확인하게 해야 한다. 모델이 '아마 그럴 것이다'라고 말하는 대신, 외부 시스템에서 확인한 결과를 바탕으로 답하게 만드는 것이다. 다음 부에서 다룰 Function Calling과 Tool Use는 바로 이 문제와 연결된다.
구조화 출력도 환각 완화에 도움이 된다. 자유 문장으로 길게 답하게 하면 모델은 불필요한 설명을 덧붙이기 쉽다. 반면 JSON Schema처럼 정해진 형식에 맞춰 answer, sources, confidence, missing_information 같은 필드를 요구하면, 적어도 출력의 형태를 통제하고 검증하기 쉬워진다. 형식이 맞는다고 내용이 참이 되는 것은 아니지만, 서비스 파이프라인에서는 형식 통제가 매우 큰 차이를 만든다.
프롬프트 설계도 기본 안전장치다. '모르면 모른다고 답하라'는 문장 하나로 모든 문제가 해결되지는 않는다. 그러나 충분한 근거가 없을 때 답변을 거절하거나 추가 정보를 요청하도록 명시하면 무리한 추측을 줄일 수 있다. 특히 문서 기반 QA에서는 다음과 같은 규칙이 효과적이다.
제공된 문서에 있는 내용만 사용한다.
답변마다 근거 문서나 문장 위치를 함께 제시한다.
문서에서 찾을 수 없는 내용은 '제공된 문서에서 확인할 수 없음'이라고 말한다.
수치, 날짜, 고유명사는 답변 전 별도 검증 단계를 거친다.
마지막으로 사람 검토가 필요하다. 어떤 분야에서는 자동화의 끝에 사람이 있어야 한다. 법률 자문, 의료 판단, 금융 투자 결정, 안전 관련 조치, 개인정보 처리처럼 오류 비용이 큰 영역에서는 LLM 응답을 최종 판단으로 사용해서는 안 된다. 모델은 초안을 만들고, 근거를 모으고, 검토할 항목을 정리하는 데 도움을 줄 수 있다. 그러나 책임 있는 결정은 검증 절차와 권한을 가진 사람이 내려야 한다.
믿을지 말지가 아니라 어떻게 검증할지의 문제
LLM을 대하는 태도는 두 극단으로 흔들리기 쉽다. 한쪽은 'AI가 말했으니 맞겠지'라고 믿는다. 다른 한쪽은 '환각이 있으니 못 쓴다'고 포기한다. 둘 다 실전에서는 별로 도움이 되지 않는다.
더 좋은 질문은 이것이다. '이 기능에서 틀리면 어떤 문제가 생기는가?'
블로그 제목을 추천하는 기능이라면 약간의 부정확함은 큰 문제가 아닐 수 있다. 고객에게 환불 가능 여부를 알려 주는 챗봇이라면 다르다. 의약품 복용 정보를 안내하거나 계약서 조항을 요약하는 기능이라면 훨씬 더 엄격해야 한다. 환각 대응은 모델 선택 문제가 아니라 제품 설계 문제다.
실무에서는 먼저 위험도를 나누어야 한다. 낮은 위험의 창작 작업은 사용자가 직접 판단하게 둘 수 있다. 중간 위험의 정보 제공 작업은 출처, RAG, 로그 기반 평가를 붙인다. 높은 위험의 의사결정 작업은 도구 검증, 규칙 기반 차단, 전문가 검토, 책임 소재를 함께 설계한다.
또한 불확실성을 사용자에게 보여 주어야 한다. 모델이 모든 답변을 같은 어조로 말하면 사용자는 무엇이 확실하고 무엇이 추정인지 구분하기 어렵다. '문서에서 확인됨', '외부 검색 필요', '계산 결과', '추정', '확인 불가' 같은 상태를 UI와 응답 형식에 반영하면 사용자는 답변을 더 올바르게 해석할 수 있다.
결국 환각을 이해한다는 것은 LLM을 덜 신비롭게 보는 일이다. 모델은 마법의 지식 창고가 아니다. 뛰어난 언어 생성 엔진이며, 적절한 문맥과 도구를 주면 매우 유용한 작업자가 된다. 하지만 검증 없이 모든 것을 맡기면, 유창함이 오히려 위험해질 수 있다.
이제 우리는 중요한 전환점에 도착했다. 지금까지는 LLM이 어떻게 학습되고 왜 틀릴 수 있는지 살펴보았다. 다음부터는 이 모델을 실제 서비스에 붙이는 방법으로 넘어간다. API로 호출하고, 프롬프트를 설계하고, 구조화 출력을 받고, 도구를 연결하고, RAG로 외부 문서를 참조하게 만들 것이다. 환각을 피하는 가장 현실적인 방법은 모델을 믿거나 불신하는 것이 아니라, 검증 가능한 시스템 안에서 일하게 만드는 것이다.
참고
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.