Mar 30, 2026

마지막 업데이트 Apr 15, 2026

AI hallucination 줄이기 가이드: 그럴듯하지만 틀린 답을 구조적으로 줄이는 법

LLM을 실제로 써보면 가장 불안한 순간은 답이 틀렸다는 사실 자체보다, 틀린데도 너무 자연스럽고 자신 있게 말한다는 점입니다. 이 패턴을 보통 hallucination이라고 부릅니다.

이 문제는 단순히 “모델이 가끔 실수한다”에서 끝나지 않습니다. 사내 법무팀용 문서 검색 챗봇을 만들었는데, 처음에는 모델이 존재하지 않는 사내 규정 조항을 인용하면서도 완벽한 문장으로 답하는 바람에 법무팀이 그대로 사용할 뻔한 적이 있습니다. 이후 RAG + 출처 검증 + “문서에 없으면 답하지 마시오” 규칙을 결합하니 거짓 인용이 주 30건에서 2건으로 줄었습니다. 문서 검색, 고객 지원, 사내 도구, 리포트 초안, 운영 자동화처럼 사람이 바로 믿고 다음 행동으로 이어질 수 있는 흐름에서는 작은 hallucination도 비용이 커집니다.

그래서 중요한 질문은 “hallucination이 생기느냐”가 아니라 어떻게 하면 그 빈도와 영향도를 구조적으로 낮출 수 있느냐입니다.

이 글에서는 아래를 정리합니다.

hallucination이 정확히 무엇인지
왜 이런 현상이 생기는지
프롬프트, RAG, tool calling, 검증, 평가가 각각 어떤 역할을 하는지
실무에서 어떤 순서로 안전장치를 쌓아야 하는지

핵심만 먼저 말하면 이렇습니다. hallucination은 프롬프트 한 줄로 사라지는 문제가 아니라, 근거를 붙이고, 답변 범위를 좁히고, 모르면 멈추게 하고, 생성 후 다시 검증하는 시스템 설계 문제입니다.

AI hallucination이란 무엇인가

hallucination은 모델이 사실이 아니거나, 근거가 없거나, 확인되지 않은 내용을 마치 맞는 것처럼 생성하는 현상입니다.

대표적인 예시는 아래와 같습니다.

존재하지 않는 출처나 논문을 인용한다
실제 문서에 없는 기능이나 정책을 있다고 말한다
오래된 정보를 최신 정보처럼 단정한다
API 이름, 함수 시그니처, 설정 키를 그럴듯하게 지어낸다
문서에 없는 절차를 “보통 이렇게 하면 된다”며 섞어 넣는다

여기서 위험한 지점은 문장이 부자연스럽지 않다는 데 있습니다. 오히려 말투가 유창하고 구조도 그럴듯해서 사용자가 검증을 생략하기 쉬워집니다.

왜 hallucination이 생길까

이 현상을 이해하려면 먼저 LLM이 무엇을 하는 모델인지 봐야 합니다. LLM은 본질적으로 다음 토큰을 예측하는 생성 모델입니다. 자세한 배경은 LLM 다음 토큰 예측 가이드에서도 다뤘지만, 중요한 점은 모델이 참과 거짓을 직접 판정하는 기계가 아니라 그럴듯한 다음 출력을 이어 가는 기계에 가깝다는 것입니다.

hallucination은 특히 아래 조건에서 잘 커집니다.

질문이 모호해서 답변 범위가 넓다
필요한 사실이 프롬프트 안에 없다
모델 내부 지식만으로 최신 정보나 사내 정보를 맞혀야 한다
자유 서술형 출력이라 추측할 여지가 크다
답변 뒤에 검증 단계가 없다
검색이나 도구 호출이 있어도 결과 품질이 낮다

즉, hallucination은 단순히 “모델이 멍청해서” 생기는 문제가 아니라, 근거 없이 대답해야 하는 상황을 시스템이 허용했기 때문에 생기는 경우가 많습니다.

먼저 모델 문제가 아니라 시스템 문제로 봐야 한다

많은 팀이 처음에는 “더 좋은 모델로 바꾸면 해결되지 않을까?”라고 생각합니다. 물론 더 나은 모델은 도움이 됩니다. 하지만 실전에서는 모델 하나만 교체해도 hallucination이 완전히 사라지지 않습니다.

이유는 답변 품질이 아래 층위의 영향을 모두 받기 때문입니다.

사용자의 질문이 얼마나 구체적인지
시스템 프롬프트가 무엇을 금지하고 허용하는지
필요한 문서나 데이터가 검색되는지
실시간 사실이 도구 호출로 보강되는지
출력 형식이 제한되는지
생성 후 검증이 들어가는지
위험한 경우 사람 검토로 넘기는지

그래서 hallucination 대응은 모델 선택보다 애플리케이션 설계가 더 중요할 때가 많습니다.

hallucination을 줄이는 실전 순서

1. 어떤 답변이 위험한지부터 분리하기

모든 출력이 같은 위험도를 갖지는 않습니다. 잡담형 요약과 정책 안내, 가격 계산, 계약 문구 추천, 장애 원인 진단은 실패 비용이 다릅니다.

먼저 아래처럼 분류해 두면 대응 강도를 정하기 쉬워집니다.

틀려도 큰 피해가 없는 저위험 답변
출처와 최신성이 중요한 중위험 답변
잘못되면 비용이나 책임 문제가 생기는 고위험 답변

고위험 답변일수록 “바로 답하기”보다 “근거가 있을 때만 답하기” 쪽으로 설계를 바꿔야 합니다.

2. 답을 만들기 전에 근거를 먼저 붙이기

hallucination을 줄이는 가장 강력한 방법 중 하나는 모델이 혼자 기억에 의존하지 않게 만드는 것입니다.

문서 기반 질의라면 RAG가 대표적입니다. 관련 문서를 먼저 가져오고, 그 문서를 바탕으로만 답하도록 하면 모델이 빈 공간을 상상으로 메울 가능성이 줄어듭니다. 이 흐름은 RAG 가이드와 임베딩 가이드를 같이 보면 더 잘 연결됩니다.

실시간 사실이 중요하다면 tool calling이 더 적합할 수 있습니다. 예를 들면:

현재 재고 확인
최신 가격 조회
오늘 날짜 기준 상태 확인
내부 데이터베이스에서 계정 정보 조회

이런 항목은 모델 기억에 맡기기보다 도구로 직접 조회하는 편이 훨씬 안전합니다. 관련 배경은 Tool Calling 가이드에서 이어서 볼 수 있습니다.

핵심은 간단합니다. 모델이 맞혀야 하는 문제를 줄이고, 확인 가능한 사실을 먼저 공급하라는 것입니다.

3. 자유 서술을 줄이고 출력 공간을 좁히기

자유롭게 길게 쓰게 둘수록 모델은 빈칸을 채우려는 유혹을 더 많이 받습니다. 반대로 답변 형식을 제한하면 추측의 폭을 줄일 수 있습니다.

효과적인 제약 방식은 아래와 같습니다.

JSON 스키마로 필드를 고정한다
허용된 선택지 안에서만 답하게 한다
“근거 문서에 없는 내용은 제외” 규칙을 둔다
각 주장 옆에 출처를 붙이게 한다
확실하지 않은 항목은 unknown으로 반환하게 한다

structured output은 hallucination을 완전히 없애지는 못해도, 틀린 답을 찾기 쉬운 형태로 바꿔 준다는 점에서 매우 중요합니다.

4. 모를 때는 멈추게 해야 한다

많은 시스템이 실수하는 부분이 여기입니다. 사용자는 답을 원하지만, 제품은 “항상 답해야 한다”는 압박을 모델에 주면 안 됩니다.

프롬프트와 정책에 아래 원칙을 명시하는 것이 좋습니다.

근거가 없으면 추측하지 말 것
문서에 없는 내용은 “확인 불가”라고 말할 것
출처가 부족하면 추가 정보가 필요하다고 말할 것
도구 호출 실패 시 답을 꾸며내지 말 것

즉, 좋은 시스템은 “정답률”만 높이는 것이 아니라 부정확할 때 억지로 말하지 않는 능력도 같이 키워야 합니다.

5. 생성 후 검증 레이어를 반드시 넣기

고객에게 바로 보여 주는 중요한 답변이라면 첫 번째 생성 결과를 그대로 신뢰하면 안 됩니다. 생성 뒤에 최소한의 검증 단계를 넣어야 합니다.

실무에서 자주 쓰는 검증은 아래와 같습니다.

JSON 스키마 검증
필수 필드 누락 검사
숫자 범위나 날짜 형식 검사
인용된 문서가 실제로 존재하는지 확인
답변 문장과 출처 문장 사이의 정합성 확인
비즈니스 규칙 기반 재검사
고위험 케이스의 human review

검증은 모델 위에 덧붙는 “불신 레이어”라고 보면 이해하기 쉽습니다. 이 레이어가 없으면 hallucination 하나가 그대로 사용자 경험이 됩니다.

6. RAG도 만능이 아니라는 점을 기억하기

많은 사람이 “RAG를 넣으면 hallucination은 끝”이라고 생각하지만 실제로는 그렇지 않습니다. 검색이 잘못되면 잘못된 근거를 붙이고도 틀린 답을 낼 수 있습니다.

RAG 품질을 좌우하는 요소는 꽤 많습니다.

문서 자체가 최신인지
chunk가 너무 잘게 혹은 너무 크게 쪼개지지 않았는지
메타데이터 필터링이 정확한지
검색 점수만 믿지 않고 reranking이 필요한지
모델에게 “제공된 문서 안에서만 답하라”는 규칙이 있는지

즉, RAG는 hallucination을 줄이는 강력한 도구이지만, retrieval 품질이 낮으면 오히려 근거가 있는 척하는 답변을 만들 수도 있습니다.

7. 평가 셋으로 실제 실패율을 재야 한다

hallucination 대응은 느낌으로 판단하면 안 됩니다. “이번 모델이 좀 더 똑똑해 보인다” 같은 인상만으로는 운영 품질을 관리할 수 없습니다.

대신 대표 질문 셋을 만들어서 주기적으로 측정하는 것이 좋습니다.

자주 들어오는 실제 사용자 질문
모델이 헷갈리기 쉬운 경계 사례
문서에 답이 없는 질문
최신성이 필요한 질문
출처 누락이 자주 발생하는 질문

그리고 아래 항목을 추적하면 좋습니다.

근거 없는 주장 비율
잘못된 출처 비율
문서 바깥 내용을 섞어 넣는 비율
답을 거절해야 했는데 억지로 답한 비율
검증 단계에서 차단된 비율

평가 설계는 LLM 평가 가이드와도 바로 연결됩니다. 결국 개선은 측정 가능한 실패 유형을 줄이는 과정이어야 합니다.

프롬프트만 잘 쓰면 충분할까

프롬프트는 중요합니다. 하지만 프롬프트만으로 해결되는 경우는 생각보다 제한적입니다.

프롬프트가 잘하는 일:

답변 범위 명확화
추측 금지 규칙 전달
원하는 형식 지정
모를 때의 행동 정의

프롬프트가 못하는 일:

없는 데이터를 만들어 내지 않기
최신 정보를 자동으로 가져오기
잘못된 검색 결과를 고치기
허위 출처를 스스로 완벽하게 걸러내기

그래서 실전에서는 프롬프트를 시작점으로 두되, 검색, 도구 호출, 검증, 평가를 같이 묶어야 합니다.

온도를 낮추면 hallucination이 사라질까

temperature를 낮추면 출력의 랜덤성이 줄어들 수는 있습니다. 하지만 근거가 없는 상태에서 더 차분하게 틀릴 뿐, 자동으로 사실 검증이 생기지는 않습니다.

즉, 낮은 temperature는 보조 수단일 수는 있어도 본질적인 해결책은 아닙니다.

더 큰 모델이면 괜찮을까

더 큰 모델은 보통 문맥 이해나 추론 안정성에서 이점이 있습니다. 하지만 큰 모델도 여전히 존재하지 않는 정보를 지어낼 수 있고, 특히 최신 정보나 내부 데이터처럼 학습 시점 밖의 사실에는 취약합니다.

그래서 모델 업그레이드는 유효한 카드지만, grounding 없이 모델만 교체하는 접근은 한계가 분명합니다.

고위험 영역에서는 답변보다 차단이 더 중요하다

의료, 법률, 금융, 보안, 계정 권한, 결제, 운영 자동화처럼 잘못된 답의 비용이 큰 영역에서는 “웬만하면 답해 주기”보다 “근거가 없으면 차단하기”가 더 중요합니다.

이런 흐름에서는 보통 아래 원칙이 필요합니다.

반드시 출처가 있는 경우에만 답변
최신 상태는 도구 조회 없이는 답변 금지
정책성 문구는 사람 승인 전 최종 노출 금지
위험 신호가 있으면 human-in-the-loop로 전환

좋은 사용자 경험은 항상 많이 답하는 것이 아니라, 틀릴 수 있을 때 정직하게 멈추는 것까지 포함합니다.

자주 생기는 오해

1. hallucination은 모델 품질 문제일 뿐이다

실제로는 시스템 설계 문제인 경우가 많습니다. 같은 모델도 프롬프트, retrieval, 검증 구조에 따라 실패율이 크게 달라집니다.

2. 출처만 붙이면 안전하다

가짜 출처를 붙이거나, 실제 출처를 인용해도 해석이 틀릴 수 있습니다. 출처 존재 확인과 내용 정합성 검증이 같이 필요합니다.

3. 거절이 많아지면 제품이 나빠진다

무조건 그렇지는 않습니다. 틀린 답을 당당하게 내보내는 것보다, 확인 불가를 명확히 말하는 편이 장기적으로 신뢰를 더 만듭니다.

FAQ

Q. hallucination을 완전히 없앨 수 있나요?

대부분의 실제 시스템에서는 어렵습니다. 대신 빈도와 영향도를 낮추는 것이 현실적인 목표입니다.

Q. RAG와 fine-tuning 중 무엇이 먼저인가요?

지식 부족이나 최신성 문제가 핵심이라면 보통 RAG와 검증 구조를 먼저 다듬는 편이 낫습니다. 자세한 비교는 Fine-tuning vs RAG 가이드에서 이어집니다.

Q. 작은 프로젝트도 여기까지 해야 하나요?

모든 프로젝트가 풀세트 안전장치를 넣을 필요는 없습니다. 다만 사용자가 사실로 받아들일 수 있는 답변을 생성한다면, 최소한 추측 금지 규칙과 기본 검증은 초반부터 넣는 편이 좋습니다.

먼저 읽어볼 가이드

검색 유입이 많은 핵심 글부터 이어서 보세요.