환각은 왜 생기고 어떻게 줄이는가: 원인과 실무 대응

존재하지 않는 논문을 그럴듯한 저자와 연도까지 붙여 인용하고, 없는 API 함수를 자연스럽게 쓴 코드를 내놓고, 틀린 법조문을 조항 번호까지 달아 제시합니다. 이런 현상을 환각(hallucination) 이라고 부릅니다.

환각이 위험한 이유는 틀렸다는 것 자체보다 틀린 방식에 있습니다. 모델은 모를 때 머뭇거리지 않습니다. 아는 것을 말할 때와 지어낼 때의 문장이 똑같이 유창하고 자신감 있습니다. 검증할 방법이 없는 사용자는 구분할 수단이 없습니다.

이 글에서는 환각이 왜 구조적으로 발생하는지, 어떤 상황에서 특히 잘 나타나는지, 그리고 실무에서 위험을 낮추는 방법을 정리합니다. 결론부터 말하면 완전히 없앨 수는 없고, 시스템 설계로 관리해야 하는 문제입니다.

생성 과정에 사실 검증이 없습니다

LLM의 동작 원리에서 설명했듯 모델은 매 단계에서 "다음에 올 법한 토큰"을 고릅니다. 이 과정 어디에도 "방금 쓴 내용이 사실인가"를 확인하는 단계가 없습니다.

논문을 인용하는 상황을 생각해 보겠습니다. "관련 연구로는" 다음에 올 법한 토큰은 저자 이름입니다. 그다음은 연도, 그다음은 논문 제목입니다. 각 단계에서 모델은 학습 데이터에서 본 패턴에 맞는 그럴듯한 토큰을 이어 갑니다. 그 조합이 실제로 존재하는 논문인지는 검사되지 않습니다. 형식이 맞으면 통과입니다.

즉 환각은 모델이 고장 난 상태가 아니라 정상 동작의 결과입니다. "그럴듯한 다음 토큰 생성"이라는 목적 함수에 충실한 출력이며, 사실성은 애초에 그 목적에 포함되어 있지 않습니다.

여기에 또 하나가 겹칩니다. 정렬 단계에서 모델은 도움이 되는 답변을 하도록 조정됩니다(사전학습·파인튜닝·정렬 참고). "모르겠다"는 답변보다 뭔가를 제시하는 답변이 선호되는 경향이 학습되면, 모델은 불확실할 때도 답을 만들어 내는 쪽으로 기울 수 있습니다.

환각의 세 가지 유형

대응 방법이 다르므로 구분해 두면 유용합니다.

사실 조작 — 존재하지 않는 것을 만들어 냅니다. 가짜 논문, 없는 함수, 허구의 사건. 가장 흔하고 눈에 띄는 유형입니다.

사실 왜곡 — 실재하는 것을 잘못 설명합니다. 실제 인물에게 하지 않은 발언을 붙이거나, 실제 API의 파라미터 이름을 틀리게 씁니다. 부분적으로 맞기 때문에 발견하기 더 어렵습니다.

문맥 이탈 — 주어진 자료에 없는 내용을 답변에 섞습니다. 검색 증강 구조에서 자주 나타납니다. 제공된 문서에 근거가 없는데도 모델이 자기 파라미터의 지식으로 빈칸을 채우는 경우입니다.

환각이 잘 나타나는 조건

모든 질문에서 같은 비율로 발생하지는 않습니다. 다음 조건에서 확률이 뚜렷이 올라갑니다.

학습 데이터에 드문 주제 — 특정 지역의 소규모 기업, 비주류 도구의 세부 옵션, 최근에야 논의되기 시작한 개념처럼 자료가 적은 영역에서 취약합니다.

정확한 식별자를 요구할 때 — 날짜, 숫자, 인용문, URL, 버전 번호, 조항 번호. 형식은 정해져 있는데 내용은 외워야 하는 것들입니다. 형식만 맞춰 채우기 쉬운 구조입니다.

지식 컷오프 이후의 일 — 모델이 알 수 없는 시점의 사건에 대해서도 답을 만들어 냅니다. 모른다는 사실 자체를 모르기 때문입니다.

질문이 거짓 전제를 포함할 때 — "2019년에 발표된 그 연구에서는"처럼 전제가 틀린 질문을 받으면, 전제를 의심하기보다 그에 맞춰 답을 구성하는 경향이 있습니다.

긴 대화의 뒷부분 — 입력이 길어지면 앞쪽 내용이 희석되고, 모델이 자기가 앞서 만든 내용을 사실처럼 참조하며 오류가 누적될 수 있습니다.

근거를 함께 주는 것이 가장 효과적입니다

환각을 줄이는 방법 중 효과가 가장 분명한 것은 모델이 외우고 있는 지식에 의존하지 않게 만드는 것입니다. 답에 필요한 자료를 찾아서 함께 넣어 주면, 모델은 기억을 더듬는 대신 주어진 텍스트를 읽고 정리하면 됩니다.

이 구조가 검색 증강 생성(RAG) 이며, 설계 방법은 RAG 파이프라인에서 다룹니다. 핵심만 짚으면 다음과 같습니다.

• 질문과 관련된 문서를 먼저 검색해 프롬프트에 넣습니다.
• "제공된 자료에 근거해서만 답하라" 고 명시합니다.
• "자료에 없으면 없다고 답하라" 는 지시를 함께 넣습니다.
• 답변에 출처를 표시하게 해 사용자가 검증할 수 있게 합니다.

RAG도 만능은 아닙니다. 검색이 엉뚱한 문서를 가져오면 그 문서를 근거로 잘못된 답이 나옵니다. 근거가 있어 보이기 때문에 오히려 더 신뢰받는 역효과도 있습니다. 검색 품질이 곧 답변 품질입니다.

프롬프트로 줄일 수 있는 부분

구조를 바꾸기 어려운 상황에서도 프롬프트로 개선할 여지가 있습니다.

모른다고 말할 여지를 명시적으로 줍니다. "확실하지 않으면 '확인이 필요합니다'라고 답하세요"처럼 적어 두면, 무리하게 답을 만드는 경향이 줄어듭니다. 모델에게 빠져나갈 길을 만들어 주는 셈입니다.

확실한 것과 불확실한 것을 구분하게 합니다. "확신하는 내용과 추측인 내용을 나눠서 표시하세요"라고 요구하면 검토 지점이 드러납니다.

추측하지 말라고 못 박습니다. 특히 수치, 날짜, 인용, 식별자에 대해서는 "모르면 비워 두고 [확인 필요]로 표시하라"고 지시하는 편이 낫습니다.

작업을 쪼갭니다. 한 번에 조사·분석·작성을 모두 시키면 중간의 오류가 그대로 결과에 실립니다. 단계를 나누고 사이에 검증을 넣으면 오류가 전파되기 전에 걸러집니다.

이 방법들은 발생 확률을 낮출 뿐 보장하지는 않습니다. 실제 값을 넣어 봐야 효과를 알 수 있습니다.

검증을 시스템에 넣습니다

프로덕션에서는 프롬프트에만 기대지 말고 확인 가능한 것은 기계적으로 확인해야 합니다.

핵심 원칙은 모델을 "확인 가능한 출력"을 내도록 설계하는 것입니다. 자유 서술형 답변은 검증이 어렵지만, 구조화된 출력과 출처 표기를 요구하면 자동 검사가 가능해집니다.

위험도에 따라 사람의 검토 단계를 두는 것도 필요합니다. 의료·법률·금융처럼 오류 비용이 큰 영역에서는 모델 출력을 최종 결과가 아니라 초안으로 다루는 것이 원칙입니다.

사용자에게 알리는 것도 설계입니다

서비스를 만든다면 환각 가능성을 사용자에게 전달하는 것 자체가 설계 요소입니다.

• 출처 링크를 눈에 띄게 배치해 확인을 유도합니다.
• 근거가 약한 답변에는 표시를 남깁니다.
• 중요한 결정에는 원문 확인을 권하는 안내를 넣습니다.
• 사용자가 오류를 신고할 수 있는 경로를 둡니다.

"AI가 생성한 내용이므로 부정확할 수 있습니다" 같은 문구를 구석에 두는 것만으로는 부족합니다. 사용자가 실제로 검증할 수 있는 수단을 함께 제공해야 의미가 있습니다.

쓰기 전에 던질 세 가지 질문

모든 출력을 똑같이 의심할 수는 없습니다. 검증에 드는 시간도 비용이기 때문입니다. 출력을 쓰기 전에 다음 세 가지를 물어보면 어디에 검증을 집중할지 정할 수 있습니다.

틀리면 무엇을 잃는가. 회의 아이디어 목록이 조금 틀리는 것과 계약서 조항 해석이 틀리는 것은 무게가 다릅니다. 오류 비용이 클수록 원자료 확인을 생략하면 안 됩니다.

확인할 수단이 있는가. 코드는 실행해 보면 되고, 인용은 원문을 찾아보면 됩니다. 반면 확인 수단이 없는 주장(출처 없는 통계, 비공개 정보에 대한 설명)은 쓰지 않는 편이 안전합니다.

근거가 입력에 있었는가. 문서를 주고 요약하게 한 결과와, 아무 자료 없이 물어본 결과는 신뢰도가 다릅니다. 전자는 원문과 대조할 수 있지만, 후자는 모델의 기억에 기댄 답입니다.

흔한 오해

"더 큰 모델을 쓰면 해결된다." 일반적으로 개선되지만 사라지지는 않습니다. 원인이 규모가 아니라 생성 방식에 있기 때문입니다. 큰 모델은 더 그럴듯하게 틀릴 수도 있습니다.

"temperature를 0으로 하면 없어진다." 무작위성과 사실성은 별개입니다. 샘플링에서 설명했듯 temperature를 낮추면 일관된 오답이 나올 뿐입니다.

"환각은 버그다." 목적 함수의 결과입니다. 사실성을 요구한 적이 없는 시스템에 사실성을 기대하는 쪽이 어긋나 있습니다. 필요한 것은 수정이 아니라 사실성을 보장하는 바깥 장치입니다.

정리

• 환각은 생성 과정에 사실 검증 단계가 없기 때문에 발생하는 구조적 현상입니다.
• 유형은 사실 조작, 사실 왜곡, 문맥 이탈로 나뉘며 각각 대응이 다릅니다.
• 드문 주제, 정확한 식별자, 지식 컷오프 이후, 거짓 전제, 긴 대화에서 확률이 높아집니다.
• 가장 효과적인 대응은 근거 자료를 함께 제공하는 검색 증강이며, 검색 품질이 답변 품질을 결정합니다.
• 프롬프트로 "모른다고 말할 여지"를 주면 발생률이 낮아지지만 보장되지는 않습니다.
• 코드 실행, 스키마 검증, 링크 확인처럼 기계적으로 확인 가능한 출력을 설계하는 것이 핵심입니다.

참고 자료

• Survey of Hallucination in Natural Language Generation — 환각 현상의 분류와 원인 정리
• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — RAG 원 논문
• TruthfulQA — 모델이 흔한 오해를 재생산하는 경향에 관한 연구