할루시네이션

최종 확인: 2026-08-09

할루시네이션(hallucination, 환각)은 AI 모델이 사실이 아닌 내용을 사실인 것처럼 그럴듯하게 만들어 내는 현상이다.

틀렸다는 것이 문제가 아니라, 틀린 티가 안 난다는 것이 문제다. 말투와 형식이 맞는 답과 똑같아서 읽는 사람이 구분할 수 없다.

왜 문제가 되나

계산기가 틀리면 바로 안다. AI가 틀리면 모른다.

실제로 이런 식으로 나타난다.

• 존재하지 않는 함수나 API를 알려 준다
• 존재하지 않는 논문·판례·책을 저자와 연도까지 붙여 인용한다
• 넣어 준 문서에 없는 내용을 문서에서 읽은 것처럼 말한다
• 그럴듯한 주소를 만들어 낸다
• 날짜와 숫자를 자신 있게 틀린다

마지막 항목이 가장 위험하다. 가격, 한도, 기한 같은 숫자는 확인하지 않고 쓰기 쉬운데, 틀리면 그대로 손해로 이어진다.

왜 알아채기 어려운가

사람이 거짓말을 할 때는 대개 티가 난다. 말이 흐려지거나, 설명이 앞뒤가 안 맞거나, 자세히 물으면 막힌다.

모델은 그렇지 않다. 맞는 답을 만드는 방식과 틀린 답을 만드는 방식이 같기 때문이다. 문장 구조도, 어조도, 확신의 정도도 구분되지 않는다.

오히려 자세히 물을수록 더 그럴듯해진다. 근거를 대라고 하면 근거를 만들고, 출처를 대라고 하면 출처를 만든다. 추궁이 검증이 되지 않는다는 점이 사람을 상대할 때와 가장 다른 부분이다.

그래서 대응 방법도 다르다. 모델에게 되묻는 대신 밖에서 확인해야 한다.

주의

확신에 찬 말투가 정확도의 근거가 아니다.

모델은 모를 때도 아는 것과 똑같은 말투로 답한다. "~인 것으로 알려져 있다", "공식 문서에 따르면" 같은 표현도 만들어 낼 수 있다.

출처를 붙였다는 것 자체가 검증이 아니다. 출처까지 지어내는 경우가 있어서, 그 출처가 실재하는지를 따로 봐야 한다.

비유 — 시험 보는 학생

이 현상을 가장 잘 설명하는 비유가 시험이다.

객관식 시험에서 모르는 문제가 나오면 어떻게 하는가. 빈칸으로 두는 것보다 찍는 편이 낫다. 틀려도 감점이 없고, 맞으면 점수를 얻는다.

AI 모델도 같은 상황에 있다. 그리고 그렇게 하도록 훈련됐다.

OpenAI 연구진이 2025년 9월 발표한 논문 〈Why Language Models Hallucinate〉는 이 비유로 시작한다 — "어려운 시험 문제를 마주한 학생처럼, 대규모 언어 모델은 불확실할 때 추측하며, 불확실함을 인정하는 대신 그럴듯하지만 틀린 문장을 만든다."

왜 생기나

논문은 원인을 두 단계로 나눈다.

① 학습 단계 — 통계적 압력

할루시네이션은 신비한 현상이 아니다. 논문은 "단순히 이진 분류의 오류에서 비롯된다"고 말한다.

모델이 학습할 때 하는 일은 결국 이 문장이 맞는 문장인가를 가려내는 것에 가깝다. 그런데 틀린 문장과 사실을 구분할 수 없는 경우가 있다. 그런 영역에서는 자연스러운 통계적 압력으로 잘못된 문장이 나오게 된다.

세상에 한 번밖에 등장하지 않는 사실 — 어떤 사람의 생일 같은 것 — 은 학습 데이터에서 규칙을 뽑을 근거가 없다. 규칙이 없으면 추측이 된다.

이것이 왜 중요한가. 할루시네이션을 "모델이 아직 덜 똑똑해서"로 보면 더 큰 모델을 기다리는 것이 답이 된다. 그런데 통계적 압력에서 오는 것이라면 크기를 키워도 자료가 희박한 영역에서는 그대로 남는다.

실제로 자주 겪는 것도 그런 영역이다. 잘 알려진 사실은 잘 맞히고, 자료가 적은 주제에서 갑자기 틀린다.

② 평가 단계 — 추측이 점수를 준다

더 중요한 것은 두 번째다. 논문의 핵심 주장이기도 하다.

> "언어 모델은 시험을 잘 보도록 최적화되며, > 불확실할 때 추측하는 것이 시험 성적을 높인다."

모델의 성능은 벤치마크 점수로 평가되고, 그 순위표가 개발 방향을 정한다. 그런데 대부분의 벤치마크는 "모르겠다"에 점수를 주지 않는다.

• 추측해서 맞으면 → 점수를 얻는다
• 추측해서 틀리면 → 점수가 없다 (감점도 없다)
• 모른다고 하면 → 무조건 점수가 없다

이 구조에서는 추측하는 모델이 항상 이긴다. 논문은 이를 불확실한 답변에 벌을 주는 "전염병"이라고 표현한다.

그래서 해결책은

논문의 결론이 특이하다. 모델을 고치는 것이 아니라 채점 방식을 고치라는 것이다.

> "순위표를 지배하지만 어긋나 있는 기존 벤치마크의 채점 방식을 수정해야 하며, > 할루시네이션 평가를 하나 더 만드는 것으로는 안 된다."

기술 문제가 아니라 제도 문제로 본 셈이다. 논문은 이를 "사회기술적 완화(socio-technical mitigation)"라고 부른다.

다른 견해

참고

이 설명이 정설로 확정된 것은 아니다.

위 논문에 대한 반론도 나와 있다. 할루시네이션은 최적화의 실패가 아니라 트랜스포머 구조 자체에서 오는 필연이라는 견해다.

이쪽이 맞다면 채점 방식을 고쳐도 없어지지 않는다.

2026년 8월 기준 양쪽 모두 진행 중인 논의이며, 이 위키는 어느 한쪽을 정답으로 적지 않는다.

어떤 형태로 나타나나

유형	예	알아채기
존재하지 않는 것	없는 함수·라이브러리·논문	쉬움 (찾아보면 없다)
섞인 사실	실재하는 두 가지를 잘못 결합	어려움
낡은 정보	바뀐 가격·은퇴한 모델	중간
숫자 오류	한도·비율·날짜	어려움
문서에 없는 내용	넣어 준 자료에 없는 것을 있다고	중간
과잉 일반화	일부 사례를 전체인 양	어려움

"섞인 사실"이 가장 까다롭다. 구성 요소가 전부 실재하기 때문에 검색해도 관련 자료가 나오고, 자세히 대조하기 전에는 틀린 줄 모른다.

예를 들어 실재하는 회사와 실재하는 제품을 엮되 소유 관계가 틀린 경우, 또는 실재하는 저자와 실재하는 학술지를 엮되 그런 논문은 없는 경우가 그렇다. 검색하면 회사도 나오고 저자도 나와서 확인했다는 착각이 들기 쉽다.

낡은 정보는 할루시네이션인가

엄밀히는 다른 문제다. 모델에는 지식 기준일이 있어서 그 이후의 일을 모른다. 이건 지어낸 것이 아니라 모르는 것이다.

다만 사용자가 겪는 결과는 같다 — 틀린 정보를 사실처럼 받는다. 그래서 실무에서는 함께 다루는 편이 낫다.

줄이는 방법

사용자가 할 수 있는 것

① "모르면 모른다고 해"라고 명시한다

가장 단순하면서 효과가 큰 방법이다. Anthropic 공식 문서는 "불확실함을 인정할 권한을 명시적으로 주는 것만으로도 잘못된 정보가 크게 줄어든다"고 안내한다.

앞의 시험 비유로 보면 당연하다. "모르겠다"에 감점이 없다고 알려 주는 것이기 때문이다.

② 자료를 직접 넣는다

기억에 의존하게 두지 말고 원문을 넣는다. "제공한 문서에만 근거해서 답하라"고 범위를 좁히면 더 낫다. 기억을 꺼내는 문제가 읽고 찾는 문제로 바뀌기 때문이다.

③ 원문 인용을 먼저 뽑게 한다

긴 문서를 다룰 때 특히 효과가 있다. Anthropic 문서는 2만 토큰이 넘는 문서에서 이 방식을 권한다. 원문을 그대로 옮겨 오게 하면 지어낼 여지 자체가 줄어들기 때문이다.

1. 관련 대목을 그대로 인용하게 한다
2. 인용이 없으면 "관련 인용을 찾지 못했다"고 말하게 한다
3. 그 인용에만 근거해 분석하게 한다

④ 근거를 못 대면 지우게 한다

답을 만든 뒤 주장마다 뒷받침하는 인용을 찾게 하고, 못 찾으면 그 주장을 삭제하게 한다.

⑤ 숫자와 고유명사는 직접 확인한다

가격·한도·날짜·인명·논문 제목은 반드시 원출처에서 본다. 이 위키가 가격을 공식 요금 페이지에서만 확인하는 것도 같은 이유다. 이 다섯 가지 중 앞의 넷은 모델에게 시키는 일이고, 다섯 번째만 사람이 하는 일이다. 그런데 실제로 사고를 막는 것은 대개 다섯 번째다.

개발자가 할 수 있는 것

기법	방식
사고 사슬 검증	단계별로 이유를 설명하게 해 잘못된 논리를 드러낸다
Best-of-N 검증	같은 질문을 여러 번 던져 답이 흔들리는지 본다
반복 다듬기	앞의 답을 입력으로 넣어 스스로 검증하게 한다
외부 지식 차단	일반 지식을 쓰지 말고 제공 문서만 쓰게 한다

Best-of-N이 특히 실용적이다. 여러 번 물었을 때 답이 갈린다면 모델이 확신하지 못한다는 신호다. 확실히 아는 것은 매번 같게 나온다.

바로 쓸 수 있는 문구

공식 문서의 권고를 한국어 문장으로 옮기면 이렇게 된다.

목적	덧붙일 문장
불확실성 허용	"확실하지 않으면 "확실하지 않다"고 말해 줘. 추측으로 채우지 마."
범위 제한	"내가 준 문서에 있는 내용만 써. 일반 지식은 쓰지 마."
인용 먼저	"먼저 관련 대목을 원문 그대로 인용하고, 그다음 그 인용에만 근거해서 답해 줘."
인용 없으면	"관련 인용을 못 찾으면 "관련 내용 없음"이라고 적어."
사후 검증	"답을 다 쓴 뒤, 주장마다 근거 인용을 찾아 붙여. 못 찾은 주장은 지워."
근거 구분	"문서에서 확인한 것과 네 판단을 나눠서 표시해 줘."

마지막 항목이 실무에서 유용하다. 확인된 사실과 추론이 섞인 문장이 가장 알아채기 어려운 형태이기 때문이다. 나눠서 쓰게 하면 무엇을 검증할지가 분명해진다.

이 문장들은 Cursor나 Claude Code 같은 도구의 규칙 파일에 넣어 두면 매번 적지 않아도 된다.

완전히 없앨 수 있나

없앨 수 없다. Anthropic 공식 문서도 이 점을 명시한다.

> "이 기법들이 할루시네이션을 크게 줄이기는 하지만 완전히 없애지는 못한다. > 특히 중요한 결정에서는 항상 핵심 정보를 검증해야 한다."

줄이는 것과 없애는 것은 다르다. 그래서 대응도 달라야 한다.

정리

"AI가 틀릴 수 있다"를 전제로 절차를 짠다.

• 틀리면 큰일 나는 정보는 사람이 확인하는 단계를 반드시 넣는다
• 확인 비용이 AI로 아낀 시간보다 크면 그 작업에는 AI를 안 쓰는 것도 답이다
• 검증이 쉬운 작업부터 맡긴다. 코드는 실행해 보면 되고, 요약은 원문과 대조하면 된다

검증 가능성이 곧 활용 범위다. 결과가 맞는지 금방 확인되는 작업일수록 AI를 맡기기 쉽고, 확인이 어려운 작업일수록 위험하다.

작업별 위험도

모든 작업의 위험이 같지 않다. 두 가지를 곱해서 판단하면 된다.

• 틀렸을 때 얼마나 큰일인가
• 틀렸는지 확인하기가 얼마나 쉬운가

작업	확인 난이도	틀렸을 때	판단
코드 작성	쉬움 (실행해 보면 된다)	오류로 드러남	맡겨도 된다
글 다듬기	쉬움 (읽으면 안다)	문체 문제	맡겨도 된다
아이디어 내기	—	고르면 그만	맡겨도 된다
문서 요약	중간 (원문 대조)	잘못된 이해	대조 필요
자료 조사	어려움	잘못된 결론	출처 확인 필수
가격·한도 확인	쉬움 (공식 페이지)	금전 손해	직접 확인
법률·의료·세무	어려움	심각	전문가 확인

"확인 난이도"가 핵심이다. 확인이 쉬우면 틀려도 금방 잡히므로 위험이 실질적으로 낮아진다. 코드가 대표적이다.

반대로 자료 조사는 틀린 것을 찾아내려면 결국 직접 조사해야 하므로, AI로 아낀 시간이 확인 시간으로 되돌아간다.

검증 순서

전부 확인할 수는 없으니 순서를 정한다.

1. 숫자 — 가격·한도·비율·날짜. 틀리기 쉽고 손해가 크다
2. 고유명사 — 사람·회사·제품·논문 이름. 실재하는지부터
3. 출처 — 링크가 살아 있는지, 그 내용이 정말 있는지
4. 인과 관계 — "A 때문에 B"라는 서술. 사실 두 개가 맞아도 연결이 틀릴 수 있다
5. 일반화 — "대부분", "항상" 같은 표현의 범위

3번을 건너뛰는 경우가 많다. 출처가 붙어 있으면 확인했다는 느낌이 들어서인데, 출처의 존재와 내용의 일치는 별개다.

참고

"틀린 티가 나는 곳"부터 본다.

지나치게 구체적인 숫자, 딱 떨어지는 비율, 처음 듣는 이름은 확인이 필요하다는 신호로 보는 편이 낫다.

반대로 모델이 얼버무리는 대목은 오히려 안전한 경우가 많다. 확신에 찬 문장일수록 먼저 의심하는 것이 실전에서 효율이 좋다.

모델은 자기가 모른다는 걸 아나

부분적으로 안다.

앞의 시험 비유가 여기서도 쓰인다. 학생이 "이건 확실하고 저건 찍었다"를 아는 것처럼, 모델도 어느 쪽이 더 불확실한지에 대한 감은 갖고 있다.

문제는 그걸 표현할 이유가 없다는 것이다. 불확실함을 밝히면 평가에서 손해를 보므로, 훈련 과정에서 그냥 답하는 쪽이 강화된다.

그래서 "모르면 모른다고 해"라는 한 줄이 효과가 있다. 없던 능력을 만들어 내는 것이 아니라, 막혀 있던 표현을 열어 주는 것에 가깝다.

Best-of-N 검증이 통하는 이유도 같다. 확실히 아는 것은 여러 번 물어도 같게 나오고, 추측한 것은 물을 때마다 흔들린다.

RAG와 검색 접지

모델의 기억 대신 실제 문서를 근거로 삼게 하는 방식이 널리 쓰인다.

방식	하는 일
RAG	질문에 맞는 문서를 찾아와 함께 넣어 준다
검색 접지	웹 검색 결과에 근거해 답하게 한다
문서 직접 첨부	사용자가 원문을 넣는다

셋 다 효과가 크다. 지식 기준일 문제도 함께 해결된다.

주의

근거를 붙여도 남는 문제가 있다.

• 엉뚱한 문서를 찾아올 수 있다 — 검색 자체가 틀리면 근거도 틀린다
• 문서를 잘못 요약할 수 있다 — 원문에 있는 내용을 반대로 읽기도 한다
• 문서에 없는 내용을 덧붙일 수 있다 — 빈틈을 기억으로 메운다
• 출처 표시가 실제 근거와 어긋날 수 있다 — 링크는 맞는데 내용이 그 링크에 없다

"출처가 달려 있으니 확인됐다"고 넘기면 안 되는 이유가 여기에 있다. Gemini의 검색 접지처럼 검색 엔진을 직접 가진 도구도 마찬가지다.

흔한 오해

"더 좋은 모델을 쓰면 없어진다"

줄지만 없어지지는 않는다. 논문은 "최신 시스템에서도 지속된다"고 명시한다.

"검색 기능을 붙이면 해결된다"

크게 도움이 되지만 완전하지 않다. 검색 결과를 잘못 요약하거나, 결과에 없는 내용을 덧붙이는 일이 여전히 일어난다.

"출처를 달았으면 믿어도 된다"

출처도 지어낼 수 있다. 실재하는 출처인지, 그 출처에 정말 그 내용이 있는지가 별개다.

"AI가 거짓말을 하는 것이다"

의도의 문제가 아니다. 속이려는 것이 아니라 맞는 답과 그럴듯한 답을 구분하지 못하는 것에 가깝다. "거짓말"이라는 표현은 원인을 잘못 짚게 만든다.

"길게 물어보면 정확해진다"

관계없다. 오히려 자료를 필요 이상으로 넣으면 컨텍스트 부패로 정확도가 떨어질 수 있다.

"한국어라서 더 심하다"

확인된 근거가 없다. 자료가 적은 주제일수록 심해지는 경향은 있지만, 언어 자체로 단정할 만한 공식 자료를 이 위키는 확인하지 못했다.

어디서 자주 겪나

상황	왜
최신 정보를 물을 때	지식 기준일 이후는 모른다
자료가 적은 주제	학습할 근거가 부족하다
구체적인 숫자를 물을 때	가격·한도는 자주 바뀐다
출처를 요구할 때	형식은 맞추되 내용이 없을 수 있다
긴 대화 뒤	앞 내용이 밀려나 컨텍스트 윈도우 밖으로 나갔다
코드 라이브러리	없는 함수나 옵션을 만들어 낸다

코딩에서는 그나마 낫다. 없는 함수를 쓰면 실행이 안 되므로 바로 드러난다. Cursor나 Claude Code 같은 도구가 실제로 유용한 이유 중 하나가 검증이 자동으로 이루어지는 영역이라는 점이다.

다만 코딩에도 사각지대가 있다. 실행은 되는데 의도와 다르게 도는 코드, 드물게만 발생하는 조건, 성능이나 보안에 관련된 판단은 실행만으로 걸러지지 않는다. "돌아간다"와 "맞다"는 다른 말이다.

반대로 글쓰기·조사·요약은 틀려도 실행 오류가 나지 않는다. 사람이 대조하지 않으면 그대로 넘어간다. 읽기에 자연스럽다는 것이 정확도의 근거가 되지 않는다는 점을 가장 자주 잊게 되는 영역이기도 하다.

자주 묻는 것

왜 모른다고 말하지 않나?

그렇게 훈련되지 않았기 때문이다. 대부분의 평가가 "모르겠다"에 점수를 주지 않아, 추측하는 쪽이 성적이 좋게 나온다.

프롬프트로 완전히 막을 수 있나?

줄일 수 있을 뿐이다. "모르면 모른다고 해", "제공 문서만 써"가 가장 효과가 크지만 완전하지 않다.

같은 질문에 매번 다른 답이 나온다

모델이 확신하지 못한다는 신호로 보면 된다. Best-of-N 검증이 이 성질을 이용한 방법이다.

AI가 준 논문 인용을 그대로 써도 되나?

안 된다. 저자·연도·제목까지 그럴듯하게 만들어 내는 대표적인 유형이다. 실제로 검색해서 존재를 확인해야 한다.

RAG를 쓰면 없어지나?

줄어든다. 모델의 기억 대신 실제 문서에 근거하게 만드는 방식이기 때문이다. 다만 문서를 잘못 고르거나 잘못 요약하는 문제는 남는다.

오픈 웨이트 모델이 더 심한가?

공개 방식과는 관계가 없다. 다만 작은 모델일수록 더 자주 나타나는 경향이 있다. 오픈 웨이트 참고.

사고 기능을 켜면 줄어드나?

도움이 되는 경우가 많다. 답하기 전에 단계를 밟으면 논리의 허점이 드러나기 쉽기 때문이다. 다만 사고 과정 자체가 틀릴 수도 있어 근본적인 해결은 아니다.

AI에게 "이거 맞아?"라고 되물으면 되나?

부분적으로 통한다. 스스로 검토하다 오류를 잡는 경우가 있다. 다만 틀린 답을 그대로 옹호하거나, 반대로 맞는 답을 괜히 뒤집기도 한다. 되묻기는 검증이 아니라 참고로 보는 편이 맞다.

왜 사과하고 나서 또 틀리나?

지적을 받으면 사과하는 것이 자연스러운 대답이라 그렇게 답하는 것이지, 무엇이 틀렸는지 알아낸 것이 아니다. 사과가 정정의 근거는 아니다.

할루시네이션이 없는 AI는 언제 나오나?

알 수 없다. 원인 진단부터 아직 논의 중이다. 평가 방식의 문제라면 채점을 고쳐 크게 줄일 수 있고, 구조의 문제라면 지금 방식으로는 남는다.

이 위키가 대응하는 방식

AI로 만든 정보를 그대로 싣는 위키는 이 문제에 그대로 노출된다. 그래서 이 위키는 몇 가지를 규칙으로 정해 두었다.

규칙	이유
가격은 공식 요금 페이지에서만 확인	블로그에 잘못 퍼진 숫자가 많다
라이선스는 원문 파일로 확인	2차 자료가 실제로 틀린 사례를 확인했다
벤치마크에는 출처와 측정 시점 병기	조건에 따라 값이 달라진다
매개변수 수는 공식 발표만	추정치가 사실처럼 유통된다
확인 안 된 것은 비워 둔다	채우는 것보다 비우는 편이 낫다
모든 문서에 확인 날짜 표시	언제 기준인지 없으면 검증이 불가능하다

"확인 안 된 것은 비워 둔다"가 가장 자주 걸린다. 표에 빈칸이 있으면 불완전해 보이지만, 그럴듯한 값을 채워 넣는 것이 이 문서가 설명한 바로 그 문제다.

여담

여담

"할루시네이션"이라는 말 자체가 논쟁거리다. 환각은 원래 사람이 없는 것을 지각하는 현상을 가리키는 말인데, 모델은 지각하지 않는다. 그래서 이 비유가 문제를 잘못 설명한다는 지적이 있다.

"작화(confabulation)"나 그냥 "오류"라고 부르자는 제안도 있었지만, 이미 널리 퍼져 대체되지 않았다.

더 흥미로운 것은 원인 진단이 바뀌어 온 과정이다. 처음에는 "모델이 부족해서"라고 보는 시각이 강했다. 그런데 OpenAI 연구진의 논문은 "평가 방식이 추측에 상을 주기 때문"이라고 뒤집었다. 모델이 아니라 우리가 모델을 재는 자를 문제 삼은 것이다.

이 진단이 맞다면 결론이 묘해진다. 더 정직한 모델은 순위표에서 불리하다. "모르겠다"를 자주 말하는 모델은 점수가 낮게 나오고, 점수가 낮으면 덜 선택된다. 정직함에 값을 매길 방법이 없는 것이 지금 이 분야가 안고 있는 구조적 문제인 셈이다.

관련 문서

• 컨텍스트 윈도우
• RAG
• 대규모 언어 모델
• Claude
• ChatGPT
• Gemini
• 오픈 웨이트