LLM 환각(할루시네이션): 원인과 실전 대응책
LLM을 업무에 붙일 때 가장 먼저 부딪히는 벽이 환각(hallucination)입니다. 존재하지 않는 논문을 인용하고, 없는 API를 자신 있게 호출하는 코드를 써 줍니다. 결론을 먼저 적으면, 환각은 버그가 아니라 LLM의 동작 원리에서 나오는 구조적 부산물이며, 완전히 없앨 수는 없지만 실무적으로 충분히 줄이고 관리할 수 있습니다. 이 글은 왜 생기는지부터 무엇으로 줄이는지까지를 정리합니다.
왜 생기는가: 검색기가 아니라 생성기입니다 #
LLM은 데이터베이스에서 사실을 조회하는 시스템이 아닙니다. 학습 데이터의 통계적 패턴을 압축해 저장해 두고, “지금까지의 텍스트 다음에 올 확률이 높은 토큰"을 하나씩 생성하는 시스템입니다. 이 구조에서 세 가지 귀결이 나옵니다.
- 지식은 손실 압축되어 있습니다. 자주 등장한 사실은 잘 재현되지만, 드물게 등장한 사실은 비슷한 패턴들과 섞여 저장됩니다. 흐릿하게 기억되는 부분을 물으면 모델은 가장 그럴듯한 패턴으로 빈칸을 채웁니다. 그 결과물이 환각입니다.
- 유창함과 정확성은 별개입니다. 모델은 “자연스러운 문장"을 만들도록 학습됐기 때문에, 내용이 틀려도 문체는 확신에 차 있습니다. 사람이 거짓말을 할 때 보이는 머뭇거림 같은 신호가 없어서 더 위험합니다.
- 학습 컷오프 이후는 모릅니다. 학습 데이터 수집 시점 이후의 사실을 물으면, 모델은 모른다고 하거나 옛 정보를 기준으로 그럴듯하게 답합니다. 최신 모델은 “모른다"라고 답하는 훈련이 강화됐지만, 경계는 여전히 완벽하지 않습니다.
자주 만나는 유형 #
- 사실 오류: 날짜, 수치, 인물 관계처럼 검증 가능한 사실이 틀리는 경우입니다. 특히 숫자와 고유명사의 조합에서 잦습니다.
- 출처 날조: 존재하지 않는 논문 제목, 판례 번호, URL, 책 인용을 만들어 냅니다. 형식이 완벽해서 더 속기 쉽습니다. 실제로 법원 제출 서면에 가짜 판례를 인용해 문제가 된 사례가 여러 나라에서 반복되고 있습니다.
- 코드 API 환각: 존재하지 않는 함수, 옛 버전에서 사라진 메서드, 다른 라이브러리의 시그니처를 섞어 씁니다. 코드는 실행하면 바로 드러나기 때문에 검증 루프를 붙이기는 오히려 쉬운 영역입니다.
- 문맥 왜곡: 제공한 문서에 없는 내용을 문서에 있다고 답하는 경우입니다. RAG를 붙였다고 끝이 아닌 이유이며, 검색된 근거와 답변의 정합성을 따로 봐야 합니다.
줄이는 방법: 실무에서 검증된 수단들 #
환각 대응은 하나의 은탄환이 아니라 여러 층의 조합입니다.
- 근거를 주입합니다(RAG). 모델의 기억에 의존하지 않고, 질문과 관련된 문서를 검색해 컨텍스트로 제공한 뒤 “이 근거 안에서 답하라"고 지시합니다. 사내 지식, 최신 정보, 드문 사실에 대한 환각을 줄이는 가장 효과 큰 수단입니다. 기반 기술은 임베딩과 벡터 검색에서, 실패 지점 진단은 RAG 심화 #1에서 다뤘습니다.
- 인용을 강제합니다. 답변의 각 주장에 근거 문서의 어느 부분을 참조했는지 표시하게 하면, 근거 없는 주장이 끼어들 자리가 줄어들고 사용자가 검증할 경로도 생깁니다. 구체적 구현은 RAG 심화 #5 인용으로 환각 줄이기에 정리되어 있습니다. 벤더가 API 차원에서 인용 기능을 제공하는 경우도 있습니다.
- 모른다고 답할 길을 열어 줍니다. “확실하지 않으면 모른다고 답하라”, “근거 문서에 없으면 없다고 답하라"는 명시적 지시는 단순하지만 실측 효과가 있습니다. 반대로 “반드시 답을 제시하라"는 지시는 환각을 유도합니다.
- 계산과 조회는 도구에 맡깁니다. 산술, 날짜 계산, 최신 정보 조회, DB 조회는 모델이 기억으로 답하게 두지 말고 코드 실행이나 검색, 함수 호출 도구로 처리하게 합니다. 모델의 역할을 “사실 생성"에서 “도구 결과 정리"로 바꾸는 것입니다. 도구 연동 표준은 MCP 정리에서 다뤘습니다.
- 출력을 기계적으로 검증합니다. 구조화 출력으로 스키마를 강제하고, 생성된 URL은 실제 접속으로, 코드는 컴파일과 테스트로, 인용 판례나 논문은 원본 조회로 후처리 검증합니다. 검증 가능한 형태로 출력을 설계하는 것 자체가 환각 대책입니다.
- 평가 파이프라인으로 회귀를 막습니다. 대표 질문 세트와 정답 기준을 만들어 두고, 프롬프트나 모델을 바꿀 때마다 환각률을 측정합니다. 만들기 번거롭지만, 이것이 없으면 “개선"이 실제로 개선인지 알 수 없습니다. 구성 방법은 RAG 심화 #6 평가 파이프라인에서 다뤘습니다.
없앨 수 없다는 전제로 설계합니다 #
위 수단을 전부 적용해도 환각률은 0이 되지 않습니다. 확률적 생성이라는 본질이 바뀌지 않기 때문입니다. 그래서 마지막 층은 기술이 아니라 운영 설계입니다.
- 오류 비용에 따라 사람 검토를 배치합니다. 사내 문서 초안처럼 오류 비용이 낮은 곳은 자동화하고, 법률 자문, 의료 안내, 대외 공지처럼 오류 비용이 높은 곳은 사람의 승인 없이 출력이 나가지 않게 만듭니다.
- 사용자에게 한계를 표시합니다. AI 생성 답변임을 명시하고 근거 링크를 함께 제공하면, 사용자가 최종 검증자 역할을 할 수 있습니다.
- 환각 사례를 수집합니다. 운영 중 발견된 환각을 평가 세트에 계속 추가하면, 대응이 누적적으로 좋아집니다.
정리 #
- 환각은 다음 토큰 확률 예측이라는 LLM의 동작 원리에서 나오는 구조적 현상입니다. 버그가 아니므로 패치로 사라지지 않습니다.
- 위험한 이유는 틀린 내용이 확신에 찬 문체로 나오기 때문입니다. 출처 날조와 코드 API 환각이 실무에서 특히 잦습니다.
- 대응은 층층이 쌓습니다. RAG로 근거를 주입하고, 인용을 강제하고, 모른다고 답할 길을 열고, 계산과 조회는 도구에 맡기고, 출력을 기계적으로 검증하고, 평가 파이프라인으로 회귀를 감시합니다.
- 그래도 0은 되지 않습니다. 오류 비용이 높은 경로에는 사람 검토를 설계에 포함하는 것이 최종 방어선입니다.