ChatGPT나 Claude와 같은 LLM을 사용하기 시작하면, "존재하지 않는 논문을 인용했다", "API 사양이 실제와 다르다"와 같은 경험을 하게 될 때가 있다.

이를 할루시네이션 (hallucination) —— 그럴듯하지만 사실과 다른 출력 —— 이라고 부른다.

이 기사는 할루시네이션이 왜 발생하는지, 실무에서 어떻게 줄일 수 있는지를 초보자용으로 정리한다.

할루시네이션이란, LLM이 생성한 텍스트가 문법적으로나 논리적으로 자연스럽게 읽히지만, 사실과 일치하지 않는 상태를 가리킨다.

전형적인 예는 다음과 같다.

• 존재하지 않는 논문·서적·URL을 인용한다
• 가공의 API 메서드나 파라미터 이름을 제시한다
• 인물의 경력이나 기업의 연혁을 잘못 설명한다
• 코드가 컴파일·실행되지 않는데 "작동합니다"라고 단언한다

중요한 점은, 모델이 거짓말을 하고 있다는 자각이 없다는 점이다. 출력은 항상 "다음에 올 법한 토큰"을 선택하고 있을 뿐이며, 진위 판정 단계는 포함되어 있지 않다.

OpenAI의 문서에서도 모델은 사실의 정확성을 보장할 수 없음을 명시하고 있다.

원문: "Models can hallucinate and return plausible but incorrect answers"

일본어 번역: 「모델은 할루시네이션을 일으켜, 그럴듯하지만 잘못된 답변을 반환할 수 있다」(출처: OpenAI API documentation)

할루시네이션의 원인은 크게 4가지로 정리할 수 있다.

LLM의 추론 (inference)은 입력 텍스트를 바탕으로 다음에 올 토큰의 확률 분포를 계산하여 하나씩 선택해 나가는 처리다.

"이 문장의 뒤로 자연스러운가"는 평가하지만, "이 문장이 사실인가"는 평가하지 않는다.

입력: "2020년 노벨 물리학상을 수상한 것은"
모델의 내부: P(다음 토큰)를 계산 → 그럴듯한 고유명사를 생성
문제: 학습 데이터에 없거나, 오래되었거나, 잘못된 정보라도 문맥에 맞으면 출력됨

사전 학습 데이터에는 정확한 정보도 잘못된 정보도 포함되어 있다.

또한, 학습 컷오프 (cut-off) 날짜 이후의 사건이나 마이너한 고유명사는 모델이 충분히 학습하지 못했을 가능성이 있다.

"모릅니다"라고 답하는 것보다, 그럴듯한 추측을 반환하는 쪽이 학습상 보상받는 패턴이 되어 있다.

토큰을 하나씩 생성하기 때문에, 전반부의 오류가 후반부의 생성 조건이 된다.

장문·다단계 추론일수록 오류가 연쇄될 가능성이 높다.

실무에서 특히 주의가 필요한 타입은 다음과 같다.

문제가 되는 것은, 사실 확인이 요구되는 상황에서 창의적으로 보완될 때이다.

완전히 없앨 수는 없지만, 실무에서 효과가 확인된 대책 5가지를 정리한다.

모델에게 "근거를 제시하라", "불확실하다면 모른다고 답하라"고 명시한다.

다음 질문에 답해 주세요.
【규칙】
- 확신이 서지 않는 경우에는 "모름"이라고 답할 것
...

Anthropic의 문서에서도 모델에게 불확실성을 인식시키는 프롬프트 (prompt) 설계를 권장하고 있다.

사내 문서나 공식 문서를 검색한 뒤에 모델에게 전달하는 수법이다.

모델이 "알고 있는 것"뿐만 아니라 "전달받은 근거"에 기반하여 답변하게 된다.

[사용자의 질문]
↓
[벡터 검색] → 관련 문서의 청크 (chunk)를 취득
...

RAG에서도 100% 방지할 수 있는 것은 아니지만 (검색 결과에 없는 정보를 추측하는 경우가 있음), 근거가 있는 답변으로 유도하기 쉽다.

모델에게 「계산기」, 「Web 검색」, 「데이터베이스 질의」 등의 도구(Tool)를 사용하게 하여, 외부 시스템으로부터 사실을 취득한 후 답변하게 한다.

출력을 JSON 스키마(Schema)로 제한하고, 프로그램 측에서 검증한다.

{
"answer": "답변 텍스트",
"confidence": "high | medium | low",
...
}

confidence: low 이거나 needs_verification: true인 경우에는 인간의 리뷰(Human Review)로 넘기는 식의 **게이트 설계(Gate Design)**가 유효하다.

최종적인 안전장치는 인간의 확인이다. 특히 다음의 출력은 리뷰가 필수적이다.

• 고객에게 그대로 보내는 문장
• 법무·의료·금융과 관련된 내용
• 외부로 공개하는 기술 문서
• 자동화 파이프라인의 최종 출력

temperature는 출력의 무작위성(Randomness)을 제어하는 파라미터(Parameter)다.

사실 확인이 필요한 태스크에서는 temperature를 낮게 (0~0.3 정도) 설정하는 것이 일반적이다.

단, 낮춘다고 해서 할루시네이션이 사라지는 것은 아니다. 어디까지나 「변동성을 줄이는」 효과에 그친다.

• 사실 확인이 필요한 유스케이스(Use Case)인지 사전에 분류하고, 할루시네이션 리스크를 평가한다
• 프롬프트(Prompt)에 「모른다고 답할 것」, 「근거를 제시할 것」이라는 규칙을 포함한다
• 사내·공식 문서가 있는 경우 RAG를 통해 근거를 전달한다
• 수치·날짜·고유명사는 도구 호출 또는 외부 API로 검증한다
• 출력에 confidence나 sources 필드를 포함하여, 신뢰도가 낮은 경우 인간의 리뷰로 넘긴다
• 사실 기반 태스크에서는 temperature를 0~0.3으로 설정한다
• 실전 투입 전에 대표 사례 10건 이상으로 할루시네이션율을 측정한다
• 사용자용 UI에 「AI의 답변은 오류를 포함할 수 있습니다」라는 주의 문구를 표시한다

패턴 1: LLM의 출력을 그대로 고객에게 보낸다

→ 대책: 인간의 리뷰 또는 자동 검증 파이프라인을 거친다. 특히 고유명사·수치는 외부 소스와 대조한다.

패턴 2: RAG를 도입했는데도 할루시네이션이 줄어들지 않는다

→ 대책: 검색 정밀도(청크 크기·임베딩 모델)를 재검토한다. 프롬프트에 「컨텍스트에 없는 정보는 답하지 말 것」이라고 명시한다.

패턴 3: 「최신 정보를 알려줘」라고 했을 때 컷오프(Cutoff) 이후의 내용을 믿는다

→ 대책: Web 검색 도구를 통합하거나, 학습 컷오프 날짜를 사용자에게 명시한다.

패턴 4: 코드를 생성하게 하고 그대로 실운영 환경에 배포한다

→ 대책: 반드시 테스트 실행·lint·타입 체크를 거친다. 존재하지 않는 import나 API는 실행 시점에 검출된다.

패턴 5: 할루시네이션 대책을 「프롬프트 한 줄 추가」로 끝내려 한다

→ 대책: RAG·도구·검증·인간 리뷰의 다층 방어(Defense in Depth)를 설계한다. 단일 대책에 의존하지 않는다.

• 할루시네이션은 LLM의 「다음 토큰 예측」이라는 설계에 기인하는 구조적인 성질이며, 완전히 없앨 수는 없다.

• 발생하기 쉬운 분야는 고유명사·수치·인용·코드·최신 정보 등, 사실 확인이 필요한 태스크이다.

• 줄이기 위해서는 근거 제시 프롬프트 설계, RAG, 도구 호출, 구조화된 출력 + 검증, 인간 리뷰를 조합해야 한다.

• 실무에서는 「LLM의 출력을 믿지 않는다」는 전제로 파이프라인을 설계한다.

• Prompt engineering (OpenAI Docs)

• Reduce hallucinations (OpenAI Help Center)

• Prompt design (Anthropic Docs)

• Retrieval Augmented Generation (Meta AI, 2020)

• Survey of Hallucination in Natural Language Generation (Ji et al., 2023)