ChatGPT나 Claude를 써 본 사람이라면 한 번쯤은 겪어봤을 것이다. 존재하지 않는 책을 그럴듯하게 추천하고, 가짜 논문 제목과 가짜 저자를 만들어내고, 작년에 끝난 회사를 아직 운영 중이라고 답하는 그 현상. 이걸 학술 용어로 환각(Hallucination) 이라고 부른다.
문제는 이게 단순한 버그가 아니라 현재 LLM 아키텍처에 내재된 구조적 특성이라는 점이다. 원리를 모르면 "AI가 똑똑하니까 알아서 잘 하겠지" 하고 그대로 쓰게 되고, 운영 중인 서비스에서 사고가 난다. 이 글에서는 환각이 왜 발생하는지, 어떤 유형이 있는지, 그리고 개발자가 실무에서 환각을 줄이려면 어떤 전략을 써야 하는지를 정리한다.
환각이란 무엇인가
가장 자주 인용되는 학술적 정의는 이렇다. 2025년 10월 arXiv에 공개된 한 종합 서베이 논문에서는 환각을 "LLM이 생성한 내용 중, 유창하고 문법적으로는 정확하지만 사실과 다르거나 외부 근거로 뒷받침되지 않는 출력" 이라고 정의한다.
핵심은 두 가지다.
- 유창함: 문장은 매끄럽고 문법적으로 자연스럽다
- 사실 불일치: 그러나 실제 사실, 인용된 출처, 또는 주어진 문맥과 어긋난다
즉 환각은 "틀렸는데 틀린 줄 모르게 잘 쓴 글" 이다. 이게 가장 위험한 이유는, 사용자가 어디가 틀렸는지 알아채기 어렵다는 데 있다. 명백한 오류는 차라리 낫다. 환각은 99%가 맞고 1%만 조용히 틀려 있다.
환각의 유형 — 무엇이 어떻게 틀리는가
연구에 따라 분류 방식은 다양하지만, 실무 관점에서 자주 마주치는 유형은 다음 4가지다.
1. 사실 환각 (Factual Hallucination)
존재하지 않는 사실을 만들어내거나, 실제 사실을 잘못 기술한다.
"아인슈타인은 1921년 노벨 물리학상을 받았으며, 그의 수상 사유는 상대성이론이었다."
수상 연도는 맞지만, 사유는 틀렸다(실제로는 광전 효과). 이런 "미묘하게 틀린 사실" 이 가장 흔하고 잡기 어렵다.
2. 컨텍스트/논리 환각 (Contextual / Logical Hallucination)
주어진 문맥과 모순되거나, 추론 과정에 논리적 오류가 들어간다. RAG로 문서를 제공했는데도 모델이 문서에 없는 내용을 끼워 넣거나, 문서 내용을 자기 멋대로 해석하는 경우가 여기 해당한다.
3. 시간적 혼동 (Temporal Disorientation)
학습 데이터의 시점과 현재 시점을 구분하지 못한다. 이미 끝난 사건을 진행 중이라고 답하거나, 폐업한 회사의 CEO를 현직으로 답하는 식이다. 학습 컷오프 이후 정보는 모델 입장에서는 존재하지 않는 시간대에 있다.
4. 출처 조작 (Reference Fabrication)
가장 악명 높은 유형이다. 존재하지 않는 논문, 책, 판례, URL을 그럴듯한 형식으로 만들어낸다. 저자 이름, 출판 연도, 저널명이 모두 그럴싸하지만 실제로 검색하면 아무것도 안 나온다. 변호사가 ChatGPT가 만든 가짜 판례를 법정에 제출했다가 징계받은 사례가 미국에서 여러 번 보도된 적이 있다.
이 외에도 코드 생성 환각(존재하지 않는 라이브러리 함수 호출), 윤리적 환각, 멀티모달 환각 등 도메인별 변종이 계속 보고되고 있다.
왜 발생하는가 — 환각의 4단계 원인
환각은 한 군데서 발생하는 게 아니라 LLM 개발 라이프사이클의 모든 단계에서 누적된다. 단계별로 정리해보자.
1단계: 데이터 — 학습 데이터의 한계
LLM은 결국 인터넷에서 긁어온 텍스트를 학습한다. 그 데이터에는 다음이 섞여 있다.
- 잘못된 정보: 위키 편집 실수, 오래된 블로그, 음모론
- 편향된 정보: 특정 관점으로 치우친 자료
- 부족한 정보: 희귀 분야, 비영어권 콘텐츠, 사적 도메인 지식
모델은 "이 데이터가 사실인가" 를 판단하는 능력이 없다. 그저 "이런 패턴이 자주 등장하더라" 를 학습할 뿐이다. 자주 등장하는 거짓 정보는 사실로 굳어진다.
2단계: 아키텍처 — 확률적 토큰 예측의 본질
이게 가장 근본적인 원인이다. LLM이 텍스트를 생성하는 방식은 다음 한 줄로 요약된다.
지금까지 나온 토큰들을 보고, 다음 토큰으로 가장 가능성 높은 후보를 확률적으로 고른다.
즉 LLM은 "진실" 을 다루지 않는다. "통계적으로 그럴듯한 다음 단어" 를 다룬다. 진실과 통계적 그럴듯함은 대부분 일치하지만, 때때로 어긋난다. 어긋나는 그 순간이 환각이다.
이건 모델을 더 크게 만든다고 사라지는 문제가 아니다. 줄어들 수는 있어도, 이론적으로 0이 되지는 않는다. 최근 서베이 논문들도 환각을 "이론적으로 불가피한 현상" 으로 분류한다.
3단계: 추론 — 디코딩과 컨텍스트
같은 모델, 같은 질문이라도 temperature 같은 디코딩 파라미터에 따라 환각 빈도가 달라진다.
- High temperature (0.8 이상): 다양성↑, 환각↑
- Low temperature (0.2 이하): 결정성↑, 환각↓
또한 컨텍스트 윈도우의 한계도 환각을 부른다. 긴 문서를 넣으면 모델이 중간 내용을 놓치고 자기 학습 지식으로 빈자리를 메우려 한다. 이걸 "lost in the middle" 현상이라고 부른다.
4단계: 프롬프트 — 사용자 입력의 영향
사용자의 질문 자체가 잘못된 전제를 깔고 있으면, 모델은 그 전제를 받아들이고 거기에 맞춰 답을 만들어낸다.
"조선 세종대왕이 발명한 대륙간 탄도미사일에 대해 설명해줘"
좋은 모델은 전제를 거부하지만, 그렇지 않은 모델은 세종대왕이 ICBM을 만들었다는 가정 위에서 그럴듯한 거짓말을 펼친다. 이걸 leading prompt에 의한 환각 이라고 한다.
환각을 어떻게 줄일 것인가 — 개발자의 4가지 전략
100% 막는 방법은 없다. 다만 체감 빈도를 크게 낮추는 전략들이 있다. 실무 적용 우선순위 순으로 정리한다.
전략 1. RAG (Retrieval-Augmented Generation)
가장 효과가 큰 방법이다. 모델에게 "네 머릿속 지식으로 답해" 하지 말고, 답할 때 참고할 문서를 같이 던져주는 것이다.
흐름은 이렇다.
- 사용자 질문이 들어온다
- 질문을 임베딩(벡터)으로 변환한다
- 벡터 DB(예: pgvector, Pinecone, Milvus)에서 의미적으로 가까운 문서를 K개 검색한다
- 검색된 문서를 프롬프트에 함께 넣고 LLM을 호출한다
- LLM은 "주어진 문서 안에서만 답하라" 는 지시 아래 답변을 생성한다
[시스템 프롬프트]
다음 문서를 참고해서 답하세요. 문서에 없는 내용은
"문서에서 확인할 수 없습니다"라고 답하세요.
[검색된 문서]
{retrieved_docs}
[사용자 질문]
{user_query}
RAG는 "학습 컷오프 이후 정보" 와 "사적 도메인 지식" 환각을 거의 다 잡아준다. 단, RAG도 만능은 아니다. 검색이 부정확하면(잘못된 문서를 찾아오면) 환각이 그대로 나오고, 모델이 검색된 문서를 무시하고 자기 지식으로 답하는 경우도 있다. 그래서 "문서에 없으면 모른다고 답하라" 같은 명시적 지시가 중요하다.
전략 2. 프롬프트 엔지니어링
모델 호출 코드를 손대지 않고도 환각을 줄일 수 있는 가장 싼 방법이다. 효과적인 패턴 몇 가지.
1) 명시적 불확실성 허용
모르는 내용에 대해서는 추측하지 말고 "확실하지 않습니다"라고
답하세요. 잘못된 정보를 자신 있게 답하는 것보다 모른다고
답하는 것이 훨씬 낫습니다.
이 한 문장만 시스템 프롬프트에 넣어도 환각이 눈에 띄게 줄어든다.
2) 출처 명시 요구
답변에 사용한 사실에 대해서는 반드시 출처(문서명·페이지·URL)를
함께 표기하세요. 출처를 댈 수 없는 정보는 답변에서 제외하세요.
출처를 요구하면 모델이 "근거가 있는 정보" 만 골라서 답하려는 경향이 강해진다. 단, 출처 자체를 환각하는 경우도 있으니 후처리에서 검증이 필요하다.
3) Chain-of-Thought + Self-Verification
답을 바로 내지 말고 추론 과정을 먼저 적게 한 다음, 그 추론을 스스로 검증 하게 한다. 두 단계로 호출이 늘어나서 비용은 올라가지만, 사실성이 중요한 도메인(법률, 의료, 금융)에서는 충분히 가치 있다.
전략 3. 검증 워크플로우 — AI 출력은 항상 초안
이건 기술이 아니라 운영 원칙이다. 사용자가 메모리에서 강조하는 것과도 정확히 같은 관점인데, AI의 출력을 그대로 신뢰하지 않고 항상 검증 단계를 둬야 한다. 특히 다음은 무조건 검증한다.
- 숫자: 통계, 가격, 날짜, 버전, 비율
- 출처: 논문 제목, 저자, URL, 책 ISBN
- 법규/기준: 법조문, 표준 번호, 인증 기준
- 최신 정보: 현직, 진행 중 사건, 최신 릴리즈 버전
검증 워크플로우는 "AI 답변 → 사람 검토 → 게시" 의 단순한 형태일 수도 있고, "AI 답변 → 다른 모델로 cross-check → 검증 통과한 부분만 저장" 같은 자동화 형태일 수도 있다. 도메인 위험도에 맞춰 설계하면 된다.
전략 4. 모델·파라미터 선택
모든 환각이 같지 않다. 작업 성격에 맞춰 모델과 파라미터를 고르면 환각을 구조적으로 줄일 수 있다.
- 사실성 중요한 작업: 큰 모델 + temperature 0.1~0.3
- 창의성 필요한 작업: 작은 모델도 OK + temperature 0.7~1.0
- 코드 생성: 코드 특화 모델 + 낮은 temperature + 컴파일/테스트로 검증
- 에이전트(도구 호출) 작업: tool-use 학습이 잘 된 모델 + 함수 시그니처 엄격 정의
실무 체크리스트
지금까지 정리한 내용을 한 페이지로 압축하면 다음과 같다.
- [ ] 숫자·출처·법규·최신 정보는 무조건 검증한다
- [ ] 사적 도메인 지식이나 최신 정보가 필요하면 RAG를 도입한다
- [ ] 시스템 프롬프트에 "모르면 모른다고 답하라" 를 명시한다
- [ ] 사실성 작업은 temperature를 낮게 둔다
- [ ] 답변 출처를 요구하되, 출처 자체도 검증한다
- [ ] 위험도 높은 도메인에서는 사람 검토 또는 cross-check 단계를 둔다
- [ ] AI 출력은 최종 결과물이 아니라 초안 으로 본다
마무리 — 환각은 없앨 대상이 아니라 관리할 대상
LLM 환각은 잡초 같은 게 아니라 날씨 같은 것이다. 막을 수 없으니, 그 위에서 제대로 일하는 법을 익혀야 한다. 모델이 더 좋아져도 환각은 0이 되지 않고, 새 도메인·새 데이터·새 모델이 나올 때마다 새로운 형태의 환각이 같이 나온다.
가장 위험한 건 환각 자체가 아니라, 환각을 인지하지 못하는 워크플로우다. AI 답변을 검증 없이 그대로 게시하거나, 그대로 코드에 박거나, 그대로 보고서에 인용하는 순간 사고가 난다. 반대로 "AI 출력은 항상 초안" 이라는 원칙만 팀이 공유하고 있으면, 환각이 있어도 시스템은 안전하게 굴러간다.
환각을 두려워하지 말고, 이해하고 다루는 쪽으로 가자. 이 글에서 정리한 4가지 원인과 4가지 대응 전략이 그 출발점이 될 것이다.
참고 자료
- Aisha Alansari, Hamzah Luqman. Large Language Models Hallucination: A Comprehensive Survey (arXiv:2510.06265, 2025.10)
- A Comprehensive Taxonomy of Hallucinations in Large Language Models (arXiv:2508.01781, 2025.08)
- LLM-based Agents Suffer from Hallucinations (arXiv:2509.18970, 2025.09)
- Lewis et al. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks