AI 할루시네이션 방지법 – 틀린 답을 프롬프트로 막는 방법
AI는 모르는 걸 지어낸다. 프롬프트로 얼마나 막을 수 있는가, 냉정하게 분석한다
들어가며: AI가 틀렸는데 나만 몰랐다
3월 초, 산업보건지도사 시험을 앞두고 AI에게 기출문제를 풀어달라고 했습니다.
결과는 충격적이었습니다. AI는 틀린 답을 내놨습니다. 문제는 그게 아니었어요. 틀린 답에 대한 설명이 너무 완벽했습니다. 왜 이 보기가 정답인지, 관련 법령은 무엇인지, 어떤 원칙에서 도출되는지를 막힘없이, 자신 있게, 그럴듯하게 설명해냈습니다.
의심이 들어 정답을 직접 알려줬습니다.
"아니에요. 제가 분석한 바로는 ○번이 맞습니다. ×번은 이런 이유로 오답입니다."
AI가 우겼습니다. 틀린 답이 맞다고, 내가 알려준 정답이 오히려 오답이라고 설명했습니다.
마지막으로 문제지 파일과 정답지 파일을 동시에 올렸습니다. 분석해달라고 했습니다.
여전히 틀렸습니다.
이 세 단계 경험은 LLM 할루시네이션의 본질을 정확하게 드러냅니다. 이 편에서는 왜 이런 일이 벌어지는지, 그리고 프롬프트로 얼마나 막을 수 있는지를 완전히 해체합니다.
1. 할루시네이션이란 정확히 무엇인가
할루시네이션(Hallucination)은 AI가 사실이 아닌 정보를 사실인 것처럼 생성하는 현상입니다. 하지만 이 정의는 너무 단순합니다.
진짜 문제는 AI가 자신이 틀렸다는 사실을 모른다는 것입니다. 거짓말과 할루시네이션은 다릅니다. 거짓말은 진실을 알면서 숨기는 것입니다. 할루시네이션은 AI의 관점에서 완전히 사실입니다. 모델은 자신이 틀렸다고 생각하지 않습니다.
이것이 할루시네이션을 특히 위험하게 만드는 이유입니다. 틀린 정보가 틀린 것처럼 보이지 않습니다.
할루시네이션의 종류
할루시네이션은 크게 세 가지로 나뉩니다.
1. 사실 오류 (Factual Hallucination)
존재하지 않는 사람, 날짜, 사건, 논문을 만들어냅니다. "2019년 하버드대 연구에 따르면..."으로 시작하는 인용문이 순수하게 창작된 것인 경우입니다. 출처, 저자, DOI까지 완벽하게 생성합니다.
2. 추론 오류 (Reasoning Hallucination)
각 단계는 논리적으로 보이지만 결론이 잘못된 경우입니다. 산업보건지도사 시험 사례가 여기에 해당합니다. AI는 법령 조항을 인용하고, 보기를 분석하고, 논거를 제시했지만 출발점부터 틀렸습니다. 논리의 형식은 갖췄지만 내용이 틀린 것입니다.
3. 맥락 충돌 (Context Conflict Hallucination)
가장 이해하기 어려운 형태입니다. 사용자가 올바른 정보를 컨텍스트에 직접 제공했음에도 모델이 이를 무시하고 학습 데이터 기반의 잘못된 답을 고집하는 경우입니다. 정답지를 파일로 올렸는데도 틀린 이유가 여기에 있습니다.
2. 왜 할루시네이션이 생기는가: LLM의 작동 원리
할루시네이션을 막으려면 왜 생기는지를 알아야 합니다.
LLM은 "다음 토큰을 예측하는 기계"다
LLM은 텍스트를 이해하는 기계가 아닙니다. 주어진 컨텍스트에서 가장 그럴듯한 다음 단어(토큰)를 예측하는 기계입니다. 이 예측은 수백억 개의 파라미터에 인코딩된 통계적 패턴을 기반으로 합니다.
"산업보건지도사 시험에서 소음성 난청의 기준은?"이라는 질문을 받으면, 모델은 이 질문 다음에 올 가장 그럴듯한 텍스트를 생성합니다. 여기서 "그럴듯한"의 기준은 사실이 아니라 학습 데이터에서 유사한 패턴 다음에 무엇이 왔는가입니다.
만약 학습 데이터에 관련 법령이 부족하거나 오래된 기준이 더 많이 포함되어 있다면, 모델은 오래된 기준을 자신 있게 출력합니다. 틀렸다는 것을 알 방법이 없습니다.
확신의 온도: Temperature와 무관한 문제
흔한 오해가 있습니다. Temperature를 낮추면 할루시네이션이 줄어든다는 것입니다. 부분적으로는 맞지만, 핵심을 놓치고 있습니다.
Temperature는 출력의 다양성을 조절합니다. 낮추면 더 결정적이고 일관된 답을 냅니다. 그러나 만약 모델이 잘못된 사실을 높은 확률로 학습했다면, Temperature를 0으로 낮춰도 그 잘못된 사실을 더 확신 있게 출력할 뿐입니다.
왜 정답을 알려줘도 우기는가: 학습 가중치 vs 컨텍스트
여기가 가장 중요한 부분입니다.
LLM은 텍스트를 처리할 때 두 가지 정보 원천을 사용합니다.
- 파라메트릭 지식 (Parametric Knowledge): 학습 과정에서 수백억 개의 가중치에 인코딩된 정보. 모델 내부에 "기억된" 것들.
- 컨텍스트 지식 (Contextual Knowledge): 현재 대화에서 사용자가 제공한 정보. 프롬프트에 들어있는 것들.
두 정보가 충돌할 때, 모델은 항상 컨텍스트를 우선해야 할까요? 이론적으로는 그렇습니다. 하지만 실제로는 그렇지 않습니다.
특히 모델이 특정 사실에 대해 강하게 학습된 경우, 즉 학습 데이터에서 반복적으로 등장한 정보일수록 컨텍스트보다 파라메트릭 지식이 우세해질 수 있습니다. 시험 문제에서 정답을 알려줘도 AI가 우긴 것은 바로 이 충돌 때문입니다. 모델의 내부 "기억"이 사용자의 말보다 강했던 것입니다.
왜 파일 두 개를 줘도 실패했는가: 어텐션의 한계
문제지와 정답지를 동시에 올렸을 때 실패한 것은 다른 이유입니다.
두 파일을 동시에 처리하면 컨텍스트 길이가 급격히 늘어납니다. LLM의 어텐션 메커니즘은 긴 컨텍스트에서 모든 정보를 동등하게 처리하지 못합니다. 특히 두 문서 사이의 교차 참조(Cross-reference) — "이 문제의 정답은 저 정답지의 몇 번이다" — 를 정확하게 수행하는 것은 생각보다 훨씬 복잡한 작업입니다.
이것은 컨텍스트 길이가 늘어날수록 중간 정보가 손실되는 "Lost in the Middle" 현상으로도 알려져 있습니다. 2023년 Liu et al.의 연구에서 실험적으로 확인된 바 있습니다. 모델은 컨텍스트의 시작과 끝 부분은 잘 처리하지만 중간에 들어간 정보는 놓치는 경향이 있습니다.
3. 프롬프트로 할루시네이션을 줄이는 실전 기법
이제 실전입니다. 프롬프트로 할루시네이션을 완전히 막을 수는 없습니다. 그러나 유의미하게 줄이는 기법들은 존재합니다.
기법 1: 불확실성 명시 강제
가장 단순하면서 효과적인 기법입니다. 모델에게 확신이 없으면 반드시 표현하도록 지시합니다.
규칙:
- 확실한 사실만 답하라
- 확신할 수 없는 내용은 "확실하지 않습니다"라고 명시하라
- 정보를 모를 경우 "모릅니다"라고 답하라
- 추측이 포함된 경우 "추측입니다"라고 표시하라
이 프롬프트의 효과와 한계:
효과: 모델이 명시적으로 불확실성을 표현하도록 유도합니다. 특히 일반적인 지식 질문에서 "확실하지 않습니다"라는 답변이 증가합니다.
한계: 모델이 강하게 학습한 잘못된 정보에 대해서는 효과가 약합니다. 틀렸지만 확신하는 경우, 모델 입장에서는 "불확실"하지 않기 때문입니다. 앞서 시험 문제 사례에서 "모르면 모른다고 해"라고 지시해도 소용없었던 이유입니다. 모델은 그게 맞다고 생각하니까요.
기법 2: 범위 제한 (Scope Restriction)
모델이 답할 수 있는 영역을 명확히 제한합니다.
당신은 아래 [제공된 문서]의 내용만을 기반으로 답해야 합니다.
문서에 없는 내용은 "제공된 문서에 해당 내용이 없습니다"라고 답하세요.
절대로 문서 외부의 지식을 사용하지 마세요.
효과: 컨텍스트에 제공된 정보 범위 내에서 작동할 때 할루시네이션을 크게 줄입니다. RAG 시스템의 기본 프롬프트 패턴이기도 합니다.
한계: 모델이 이 규칙을 완벽하게 지키지 않습니다. 특히 문서의 내용이 모델의 학습 데이터와 충돌할 때 몰래 내부 지식을 섞어 넣기도 합니다. 이것을 완전히 차단하는 것은 프롬프트만으로는 불가능합니다.
기법 3: 자기검증 (Self-Verification) 프롬프트
모델이 답변을 생성한 후 스스로 검증하게 합니다.
1단계: 질문에 답하라
2단계: 생성한 답변을 검토하라
3단계: 각 주장에 대해 "이것이 사실인가, 확인 가능한가"를 자문하라
4단계: 불확실한 부분이 있으면 명시하고, 필요시 답변을 수정하라
효과: 단순 CoT보다 정확도를 높이는 경우가 많습니다. 모델이 자신의 출력을 비판적으로 검토하는 과정에서 명백한 오류를 잡아내기도 합니다.
한계: 역시 모델이 강하게 믿는 잘못된 정보는 자기검증에서도 통과시킵니다. "내가 방금 한 말이 맞나?"를 물어도, 모델 입장에서는 맞다고 확신하고 있기 때문입니다.
기법 4: 출처 요청 — 그러나 함정이 있다
"출처를 같이 알려줘"는 할루시네이션을 막기 위해 자주 쓰이는 방법입니다. 그러나 이것은 양날의 검입니다.
출처를 요청하면 모델은 출처를 생성합니다. 그 출처가 실제로 존재하는지 확인하지 않습니다. 논문 제목, 저자명, 학술지명, 발행 연도, DOI까지 그럴듯하게 만들어낼 수 있습니다. 이것을 인용 할루시네이션이라고 부릅니다.
나쁜 방식:
"○○에 대해 설명하고 출처를 알려줘"
→ 모델이 가짜 출처를 생성할 가능성 있음
더 나은 방식:
"○○에 대해 설명해줘. 확실한 출처가 없으면 출처를 만들어내지 말고
'출처 확인 필요'라고 표시해줘"
가장 좋은 방식은 출처가 필요한 정보라면 모델에게 묻지 말고, 직접 신뢰할 수 있는 소스를 찾는 것입니다. AI는 검색 엔진이 아닙니다.
기법 5: 역할 분리 (Separation of Roles)
모델이 답변자와 검증자 역할을 분리하게 합니다. 두 번 호출하거나, 프롬프트 안에서 두 역할을 명시합니다.
[1차 응답자 역할]
주어진 질문에 최선을 다해 답하라.
[2차 검증자 역할]
위 응답을 비판적으로 검토하라. 사실 오류, 논리 비약,
불확실한 주장이 있으면 지적하라. 수정이 필요하면 수정안을 제시하라.
동일한 모델을 사용하면 검증자도 같은 편향을 갖고 있어서 효과가 제한적입니다. 하지만 전혀 안 하는 것보다는 낫습니다. 실제 프로덕션 시스템에서는 다른 모델을 검증자로 사용하는 방식도 씁니다.
4. 프롬프트로 절대 막을 수 없는 것
솔직하게 말할 시간입니다.
강하게 학습된 오류
모델이 학습 데이터에서 수십만 번 이상 반복 학습한 잘못된 정보는 프롬프트로 교정하기 매우 어렵습니다. 특히 오래된 기준, 개정 전 법령, 과거의 상식이 새로운 정보보다 훨씬 많이 학습돼 있을 때입니다.
산업보건지도사 시험의 경우, 관련 법령과 기준은 지속적으로 개정됩니다. 모델의 학습 데이터 컷오프 이후에 개정된 내용은 모델이 알 수 없습니다. 그리고 개정 이전의 기준이 훨씬 많은 텍스트로 학습돼 있어, 최신 기준을 알려줘도 오래된 기준으로 답하는 경향이 생깁니다.
지식 컷오프 이후의 정보
모든 LLM에는 학습 데이터의 컷오프 날짜가 있습니다. 그 이후의 정보는 모델이 갖고 있지 않습니다. 없는 정보를 묻는다고 해서 "모릅니다"라고 항상 답하지 않습니다. 있는 척 만들어냅니다.
고도로 전문화된 도메인
일반적인 지식에 비해 극도로 전문화된 영역 — 특정 분야의 최신 법령, 희귀 질환의 치료 프로토콜, 특수 산업의 기준치 등 — 은 학습 데이터 자체가 부족합니다. 데이터가 부족할수록 할루시네이션 확률이 올라갑니다.
5. 그러면 어떻게 써야 하는가: 실용적 판단 기준
할루시네이션을 완전히 막을 수 없다면, AI를 어떻게 써야 할까요?
검증 가능한 작업에 쓰세요.
코드를 짜달라고 하면 실행해서 확인할 수 있습니다. 글의 구조를 잡아달라고 하면 논리적으로 검토할 수 있습니다. 번역을 도와달라고 하면 원문과 대조할 수 있습니다. 결과를 검증할 수 없는 작업에 AI 출력을 그대로 신뢰하는 것은 위험합니다.
사실 확인이 필요한 정보는 원본 소스를 확인하세요.
AI가 말한 법령 조항은 국가법령정보센터에서 확인하세요. AI가 말한 연구 결과는 직접 논문을 찾아보세요. AI는 출발점이지 종착점이 아닙니다.
AI를 전문가 대체재로 쓰지 마세요.
시험 준비, 의료 판단, 법률 해석, 재무 결정. 이런 영역에서 AI의 출력을 검증 없이 신뢰하는 것은 위험합니다. AI는 전문가를 보조하는 도구이지, 대체하는 도구가 아닙니다. 특히 틀렸을 때의 대가가 큰 영역일수록.
할루시네이션을 인정하는 모델을 선택하세요.
최신 모델들은 "제 학습 데이터에 없는 내용입니다", "확인이 필요합니다" 같은 표현을 더 적극적으로 사용하도록 개선되고 있습니다. 그러나 이것도 완전하지 않습니다. 모델 선택 시 할루시네이션 벤치마크를 참고하는 것도 방법입니다.
6. 근본적 해결책: RAG
프롬프트 기법으로 할루시네이션을 줄이는 데는 한계가 있습니다. 진짜 해결책은 모델이 없는 사실을 지어내지 않아도 되도록, 필요한 사실을 직접 주입하는 것입니다.
이것이 RAG(Retrieval-Augmented Generation) 의 핵심 아이디어입니다.
RAG는 사용자의 질문이 들어오면 먼저 신뢰할 수 있는 문서 DB에서 관련 내용을 검색하고, 그 내용을 컨텍스트에 넣은 뒤 모델에게 "이 문서를 기반으로만 답하라"고 지시합니다. 모델이 스스로 사실을 만들어낼 필요가 없어집니다.
산업보건지도사 시험 예시로 돌아가면, 이상적인 구조는 이렇습니다.
1. 사용자: "소음성 난청의 산재 인정 기준은?"
2. 시스템: 최신 산업재해보상보험법 + 고용노동부 고시 DB 검색
3. 검색된 원문 → 컨텍스트에 주입
4. 모델: "제공된 문서에 따르면..." (원문 기반으로 답변)
모델이 학습 데이터로 추측할 필요 없이, 검증된 최신 문서를 보고 답합니다. 할루시네이션의 근본 원인인 "정보 부재"를 해결하는 방식입니다.
RAG의 구체적인 구현과 프롬프트 설계는 8편에서 상세히 다룹니다.
마치며: 할루시네이션을 두려워하지 말고 이해하라
AI가 틀린 답을 확신 있게 말하는 경험은 누구나 합니다. 그 경험 이후에 두 가지 반응이 갈립니다.
하나는 "AI는 못 믿겠다"며 사용을 포기하거나 극도로 제한하는 것. 다른 하나는 "왜 이런 일이 생기는지 이해하고 그에 맞게 쓰는 것"입니다.
할루시네이션은 LLM의 구조적 특성입니다. 버그가 아니라 설계의 일부입니다. 다음 토큰을 예측하는 시스템이 "모르면 침묵하는 것"보다 "그럴듯한 것을 생성하는 것"에 최적화되어 있기 때문에 생기는 현상입니다.
이것을 이해하면 AI를 더 잘 쓸 수 있습니다. 검증 가능한 작업에 쓰고, 사실 확인이 필요한 영역은 원본을 찾고, 프롬프트로 불확실성 표현을 강제하되 그것도 완벽하지 않다는 걸 알고 씁니다.
도구를 제대로 아는 것이 도구를 제대로 쓰는 첫걸음입니다.
7편에서는 프롬프트를 코드처럼 다루는 방법을 다룹니다. 변수, 템플릿, 재사용 가능한 프롬프트 구조 설계 — 프롬프트 엔지니어링이 단순한 글쓰기에서 시스템 설계로 진화하는 지점입니다.
