할루시네이션, 왜 생기고 어떻게 줄일까? LLM 오류를 막는 실무 가이드

고객 지원 봇이 정책에 없는 예외를 만들어내서는 안 됩니다. 보고서 작성 어시스턴트가 합계를 임의로 내놓아서도 안 됩니다. 모델로 행동을 선택하고 툴을 호출하는 소프트웨어인 에이전트는 어떤 고객 기록을 수정할지 추측해서는 안 됩니다. 실무에서 달성해야 할 목표는 근거 없는 답변이나 동작이 애플리케이션 밖으로 나가지 못하게 막는 것입니다.

2026년 10월 17일 검증 완료. 링크로 연결한 모델 개발사의 지침, API 문서, 연구 사례, 법원 기록을 기준으로 확인했습니다. 아래 사례는 출처가 있는 관찰 결과입니다. 검증 코드와 주간 체크리스트는 구현을 위한 권장안이며, 실제 운영 성과를 보고한 내용은 아닙니다.

할루시네이션이란 무엇이며, 왜 발생할까요?

LLM 할루시네이션은 대규모 언어 모델이 거짓이거나 근거가 없는 내용을 답인 것처럼 생성하는 현상입니다. LLM은 대규모 언어 모델을 뜻하며, 텍스트의 패턴을 학습해 언어를 생성하는 모델입니다. 어떤 내용이 다른 맥락에서는 사실이더라도, 제공한 문서로 뒷받침되지 않는다면 그 문서에 비추어서는 근거 없는 주장일 수 있습니다.

모델을 책상 위 자료로 보고서를 완성하는 능숙한 작성자라고 생각해 보겠습니다. 빠진 문단도 그럴듯하게 채울 수 있습니다. 그렇다고 그 문단을 회사의 공식 기록에 넣어도 된다는 뜻은 아닙니다.

그럴듯한 문장을 예측하는 것과 사실 확인은 다릅니다

2025년 9월 5일에 발표된 OpenAI의 언어 모델이 할루시네이션을 일으키는 이유에 관한 연구 글은 사전 학습에서 모든 문장에 참·거짓 표시가 붙어 있는 것은 아니며, 모델은 그런 상태에서 텍스트를 예측하는 법을 배운다고 설명합니다. 드물게 등장하고 다른 패턴에서 유추하기 어려운 사실은 특히 알아내기 어렵습니다. 이후 학습으로 행동을 개선할 수는 있어도, 유창함이 진실성을 보장하지는 않습니다.

개발 관점에서 결론은 분명합니다. 제품 정책, 계정 상태, 재고 정보는 애플리케이션이 읽을 수 있는 신뢰할 만한 공식 데이터에 있어야 합니다. 모델이 기억하는 답을 데이터베이스처럼 취급하면 피할 수 있는 오류 경로를 만들게 됩니다.

누락되거나 오래된 맥락은 정보의 빈틈을 만듭니다

고객에게 필요한 사실이 모델에 전달된 적조차 없을 수 있습니다. 업로드한 문서는 오래됐을 수 있고, 검색 결과는 다른 제품 버전의 자료일 수 있으며, 계정 조회는 실패할 수 있습니다. Anthropic도 Claude가 부정확한 답변을 내놓는 이유에서 최신 정보의 부재를 혼동의 원인으로 명시합니다.

여기서 두 가지 문제를 구분해야 합니다. 어시스턴트가 정책을 지어냈다면 생성 단계의 실패입니다. 효력이 끝난 정책을 정확히 되풀이했다면 자료 관리의 실패입니다. 어느 쪽이든 고객은 잘못된 답을 받지만, 프롬프트를 고친다고 만료된 문서나 고장 난 계정 조회가 해결되지는 않습니다.

반드시 답해야 한다는 압박이 잘못된 행동에 보상을 줍니다

OpenAI는 정확도만 평가하면 불확실성을 인정하는 것보다 추측하는 쪽에 보상이 돌아갈 수 있다고 지적합니다. 완성된 답변은 모두 성공으로, 담당자 이관은 모두 실패로 집계한다면 자체 성공 지표에서도 같은 실수를 반복할 수 있습니다.

고객이 확정 배송일을 요구한다면 배송사의 공식 예상 정보가 필요합니다. 배송사가 아직 예상일을 제공하지 않았다면, 어떤 정보가 없는지 구체적으로 설명하는 것이 유용한 결과입니다. 테스트와 운영 대시보드에서도 이런 결과를 긍정적으로 평가해야 합니다.

LLM 할루시네이션 사례: 잡아내야 할 네 가지 오류

애플리케이션이 무엇을 검증해야 하는지에 따라 오류를 분류합니다. 범주가 서로 겹치기도 하지만, 소규모 팀도 어느 지점에 검증을 추가할지 구체적으로 판단할 수 있습니다.

지어낸 사실: 학위논문 제목 사례는 OpenAI의 연구 설명에 나옵니다. 익숙한 이름이라고 해서 모르는 논문 제목까지 알 수 있는 것은 아닙니다. 업무에서는 비슷한 제품에 있는 기능이라는 이유로 해당 제품에도 그 기능이 있다고 지어내는 오류에 해당합니다.

틀린 수치: 같은 글의 생일 사례는 정밀해 보이는 날짜 자체가 근거는 아니라는 점을 보여줍니다. 애플리케이션에서는 근거 없는 수치와 계산 오류를 구분해야 합니다. 수량은 기록에서 가져오고, 합계는 일반 코드로 계산한 다음, 모델에는 전달받은 결과를 설명하게 합니다.

가짜 인용: 2024년 3월 20일 United States v. Cohen 사건 결정문은 당시 Google의 생성형 어시스턴트였던 Google Bard에서 얻은, 존재하지 않는 세 건의 판례를 다룹니다. 그중 하나가 United States v. Figueroa-Florez였습니다. 사건명과 인용 형식이 그럴듯하다고 실제 법적 근거가 되는 것은 아니었습니다.

잘못된 툴 인자: Berkeley Function Calling Leaderboard 작성자들은 요청된 이율 5%를 annual_interest_rate: 5로 전달한 호출을 올바른 소수 표기인 0.05와 함께 보여줍니다. 둘 다 숫자이므로 타입 검사만으로는 구분할 수 없습니다. 이는 인자의 의미가 잘못된 오류입니다. 모든 잘못된 툴 호출이 사실을 지어낸 경우는 아니지만, 실행 전 검토에서는 함께 다뤄야 합니다.

AI 할루시네이션, 고객에게 전달되기 전에 줄이려면

생성 전후에 근거 제공과 검증 절차를 두고, 둘 중 하나라도 부족할 때 시스템이 어떻게 동작할지 정합니다. 개발자는 검증을, 운영자는 기준 정보와 담당자 이관 경로를 책임집니다.

최신의 관련 자료를 바탕으로 답하게 합니다

검색 증강 생성, 즉 RAG는 외부 자료를 검색해 관련 구절을 모델에 제공합니다. 작성자에게 참고할 자료를 주는 방식입니다. Anthropic의 Contextual Retrieval 설명은 검색된 구절의 주변 맥락을 유지해야 하는 이유를 보여줍니다. 일부만 떼어낸 구절에는 어느 회사, 어느 기간, 어떤 대상을 설명하는지 빠질 수 있습니다.

고객 지원 기능이라면 공식 정책 문서 모음을 정하고 제품, 지역, 시행일, 접근 권한에 관한 메타데이터를 붙입니다. 생성 전에 이 필드로 자료를 필터링합니다. 취소 규정은 예외 조항과 함께 검색해야 합니다. 적용 조건에서 분리된 문단은 고객에게 잘못된 약속을 하는 근거로 쓰일 수 있습니다.

실시간 계정 정보는 애플리케이션의 데이터베이스나 서비스에서 읽어야 합니다. 특정 고객의 주문이 발송됐는지를 문서 검색으로 대신 확인하기는 어렵습니다. 조회에 실패하면 일반 지식으로 조용히 대체하지 말고, 정보를 확인할 수 없는 상태를 반환합니다.

처음에는 단순한 검색 흐름으로 시작합니다. 여러 출처를 대상으로 추가 검색이 필요한 질문에는 모델이 후속 검색 단계를 선택할 수 있는 에이전틱 RAG를 사용합니다. 추가 검색에도 중단 규칙과 동일한 출처 검증이 필요합니다.

진단할 때 핵심은 올바른 근거가 모델에 도달했는지입니다. 답변과 함께 출처 ID와 버전을 저장하면 운영자가 검색 누락과 근거 없는 내용 추가를 구분할 수 있습니다.

‘모른다’를 애플리케이션의 응답 상태로 만듭니다

Anthropic의 할루시네이션을 줄이는 방법은 불확실성을 허용하고, 원문 인용에 근거해 작업하며, 출처를 제시하고, 뒷받침되지 않는 주장을 제거하라고 권장합니다. 이 지침을 애플리케이션의 응답 규약으로 구체화합니다.

모델에 answered, needs_clarification, insufficient_evidence처럼 명시적인 결과 상태를 제공합니다. 답이 없는데도 필수 필드를 채우려고 답을 만들어내게 해서는 안 됩니다. 인터페이스는 각 상태를 유용한 다음 단계로 연결해야 합니다. 필요한 사항만 묻는 후속 질문, 누락된 기록에 대한 설명, 검색한 맥락을 첨부한 담당자 이관이 될 수 있습니다.

예를 들어 이렇게 지시할 수 있습니다. “제공된 정책과 계정 기록만 사용합니다. 기록만으로 답을 확정할 수 없다면 어떤 정보가 없는지 밝힙니다. 유사 사례를 근거로 적용 대상 여부를 추론하지 않습니다.” 쉬운 질문만이 아니라 근거가 빠진 상황에서도 이 지시가 작동하는지 테스트합니다.

알 수 없다는 결과는 안전상 응답 거절, 툴 시간 초과, 권한 없는 요청과 다릅니다. 담당자가 해당 문제를 해결할 수 있도록 로그에서도 이 상태들을 구분합니다.

인용은 코드로 검증할 수 있게 만듭니다

인용은 애플리케이션이 이미 알고 있는 근거를 가리켜야 합니다. 검색 단계에서 출처 ID를 부여하고, 서버에서 이 ID를 승인된 URL로 연결합니다. 모델이 기억에 의존해 참고문헌이나 링크 주소를 만들어내게 하지 않습니다.

다음 세 가지를 별도로 확인합니다.

• 존재 여부: 인용한 출처 ID가 이번 요청을 위해 제공한, 접근이 허용된 자료에 속하는지 확인합니다.
• 인용문 일치: 인용한 문구가 답변에 사용한 바로 그 버전의 원문에 있는지 확인합니다.
• 주장의 근거: 해당 구절이 이 고객의 상황에서 그 주장을 뒷받침하는지 확인합니다.

앞의 두 가지는 코드로 비교적 간단히 확인할 수 있습니다. 세 번째는 도메인 규칙, 신뢰할 수 있는 구조화된 필드, 또는 주장과 근거의 관계를 별도로 검토하는 절차가 필요합니다. 문서에서 ‘적용 대상’이라는 표현을 찾았다고 특정 고객이 적용 대상이라는 사실까지 입증되는 것은 아닙니다.

Anthropic의 인용 기능 문서는 근거 위치를 찾는 데 도움이 되는 문서 연결 인용을 설명합니다. 출처를 가리키는 정보는 답변을 감사하는 데 유용하지만, 그 출처가 최신인지, 공식적으로 신뢰할 수 있는지, 올바르게 해석됐는지까지 판단해 주지는 않습니다.

구조화된 출력을 사용한 뒤, 값까지 검증합니다

구조화된 출력은 허용되는 필드와 값의 타입을 정의한 스키마에 맞게 응답을 제한합니다. 덕분에 애플리케이션의 검증 코드를 작성하기가 쉬워집니다. OpenAI의 Structured Outputs 가이드는 출력에 여전히 오류가 있을 수 있으며, 응답 규약에 적절한 대체 경로가 없으면 맞지 않는 입력이 할루시네이션을 유발할 수 있다고 명시적으로 경고합니다.

툴 호출은 실행 전에 수행할 작업, 필수 인자, 단위, 허용 값, 기록의 존재 여부, 호출자의 권한을 검증합니다. 테넌트와 인증된 사용자는 애플리케이션 코드에서 확인합니다. 필요한 경우 모델이 접근이 허용된 기록 중에서 선택하게 할 수는 있지만, 모델이 제시한 고객 ID를 접근 권한의 증거로 취급해서는 안 됩니다.

툴 호출이 성공했더라도 고객에게 실제 상태를 정확히 알려야 합니다. 툴이 대기 상태나 오류를 반환했다면 취소가 완료됐다고 말해서는 안 됩니다. 최종 메시지는 반환된 상태를 기준으로 작성합니다. 이 사이트의 AI 에이전트 가드레일 가이드는 이와 관련된 동작 범위의 제한을 다룹니다.

할루시네이션 탐지: 직접 실행하는 검증 코드

범위가 좁은 사실 필드라면 모델이 제안한 값을 승인된 기록과 대조한 뒤, 애플리케이션에서 답변을 직접 구성합니다. 자유 형식의 문장이 일관돼 보이는지 확인하는 것보다 해당 필드의 정확성을 더 확실하게 보장할 수 있습니다.

다음 Python 예제는 실제 업무 정책이 아니라 설명을 위한 고객 지원 정책 테스트 데이터를 사용합니다. verify_answer.py로 저장하고 python3 verify_answer.py를 실행합니다. 표준 라이브러리만 사용하며 API는 호출하지 않습니다.

# Records must be filtered for the caller's access and policy scope
# before reaching this function. These are illustrative fixtures.
records = {
    "support-policy": {
        "text": "The support channel for this workspace is email.",
        "current": True,
        "fields": {"support_channel": "email"},
    }
}


def validate(result, sources):
    keys = {"status", "field", "value", "source_id", "quote"}
    if not isinstance(result, dict) or set(result) != keys:
        return False
    if result["field"] != "support_channel":
        return False
    if result["status"] == "unknown":
        return all(result[k] is None
                   for k in ("value", "source_id", "quote"))
    if result["status"] != "answered":
        return False
    if not all(isinstance(result[k], str)
               for k in ("value", "source_id", "quote")):
        return False
    source = sources.get(result["source_id"])
    if source is None or source["current"] is not True:
        return False
    quote = result["quote"].strip()
    return (
        bool(quote)
        and quote in source["text"]
        and result["value"]
        == source["fields"].get(result["field"])
    )


proposal = {
    "status": "answered",
    "field": "support_channel",
    "value": "chat",
    "source_id": "support-policy",
    "quote": "The support channel for this workspace is email.",
}

if not validate(proposal, records):
    print("Hold: evidence or value check failed.")
elif proposal["status"] == "unknown":
    print("I cannot confirm the support channel from these records.")
else:
    print(f"Your support channel is {proposal['value']}.")

제안된 값이 chat이면 인용문이 실제 원문과 일치하더라도 검증에 실패합니다. 값이 email이면 이 제한된 검증을 통과합니다. 답을 확정하는 것은 인용문 일치만이 아니라 신뢰할 수 있는 필드입니다.

한계를 분명히 알아야 합니다. 이 검증 코드는 자유 형식 설명의 진실성, 정책 담당자가 올바른 사실을 입력했는지, 앞단의 접근 권한 필터가 정상 동작했는지까지 확인하지 못합니다. unknown 분기는 답변 보류가 필요했는지를 판단하는 것이 아니라 허용된 응답 형식인지만 검증합니다. 이런 문제는 별도의 검증과 평가에서 다뤄야 합니다. 영향이 큰 고정된 사실은 신뢰할 수 있는 데이터로 템플릿을 채우는 방식만으로 생성 자체를 없앨 수도 있습니다.

정확한 답변과 적절한 중단을 함께 평가합니다

평가, 즉 eval은 애플리케이션이 기대한 대로 동작하는지 반복해서 확인하는 테스트입니다. 고객에게 발생할 수 있는 실패를 중심으로 구성하고, 모델, 프롬프트, 검색 인덱스, 툴 스키마, 정책이 바뀔 때 실행합니다.

근거를 갖춘 정답, 근거 없는 답변, 적절한 답변 보류, 불필요한 답변 보류, 유효하지 않은 동작 제안을 각각 기록합니다. 하나의 평균으로 합치면 근거가 개선된 것인지, 단순히 더 많은 질문에 답하지 않게 된 것인지 알기 어렵습니다.

정확한 값, 출처 포함 여부, 필수 필드, 권한, 툴 결과는 일반 코드로 검사합니다. 구절이 다른 표현으로 바꾼 주장을 뒷받침하는지처럼 언어 판단이 필요한 문제에는 평가 모델을 사용하되, 사람이 검토한 예제로 판단 기준을 조정합니다. LLM을 평가자로 사용하는 방식도 오류를 낼 수 있는 또 다른 모델을 쓰는 것이며, 독립적인 사실 출처가 되는 것은 아닙니다.

Promptfoo는 평가 툴입니다. 모델 기반 평가 항목에는 기준 답변에 비춘 사실성, 제공된 맥락에 대한 충실성 등이 포함됩니다. 이 구분은 유용합니다. 답변이 오래된 문서와 일치해도 오늘의 상황에서는 틀릴 수 있기 때문입니다. 무엇을 통과로 볼지 정의한 다음, Promptfoo 가이드를 참고해 테스트 실행 환경을 구축합니다.

각 테스트의 실행 기록에는 요청, 검색한 근거, 제안된 인자, 실제 툴 실행 결과, 최종 답변을 함께 보관합니다. 사례가 실패하면 이 기록을 통해 어디를 고쳐야 하는지 알 수 있습니다. 문장이 평가 모델에서 높은 점수를 받더라도, 인용 누락과 잘못된 인자는 명시적으로 실패 처리합니다.

무엇이 과장돼 있을까요?

RAG가 모든 답변을 사실로 만들어 주지는 않습니다. 유용한 구절을 검색해 놓고도 잘못 읽을 수 있고, 오래된 구절을 완벽하게 인용할 수도 있습니다. 검색과 생성을 따로 테스트하고, 자료 모음을 책임질 담당자를 지정합니다.

더 큰 컨텍스트 윈도우가 자료 선별을 대신하지는 않습니다. Anthropic의 컨텍스트 엔지니어링 지침은 컨텍스트가 커질수록 재현율과 정밀도가 떨어질 수 있다고 경고합니다. 관련 규정과 예외, 필요한 계정 근거를 포함해야 합니다. 모든 문서를 프롬프트에 넣는다고 자료의 최신성이 관리되지는 않습니다.

다른 모델이 ‘맞아 보인다’고 해도 그 자체로 검증은 아닙니다. 검토자에게 실제 근거와 분명한 판단 기준을 제공해야 합니다. 독립적인 근거 없이 서로 동의하면 똑같이 근거 없는 가정이 그대로 남을 수 있습니다.

유효한 JSON이라고 내용까지 정확한 것은 아닙니다. 스키마는 출처 ID와 숫자 인자를 요구할 수 있습니다. 하지만 해당 출처가 존재하는지, 숫자가 올바른 의미인지 확인하는 책임은 여전히 애플리케이션에 있습니다.

실제로 중요한 한계는 자료로 답할 수 없는 질문, 검증 절차로 확인할 수 없는 필드, 안전하게 되돌릴 수 없는 동작입니다. 특정 워크플로를 운영에 투입해도 되는지 알려주는 보편적인 할루시네이션 비율은 없습니다.

소규모 팀이 이번 주에 적용할 체크리스트

고객에게 사실에 근거한 약속을 하거나 업무 기록을 변경하는 기능이라면 지금 조치해야 합니다. 담당자가 이미 출처와 대조해 검토하는 초안만 만드는 기능이라면, 복잡한 자동화 구조를 추가하기 전에 평가 세트를 만들고 검토 절차부터 개선합니다. 정해진 로직으로 공식 필드를 조회해 반환하는 기능에는 모델이 전혀 필요하지 않을 수도 있습니다.

다음은 시작을 위한 제안입니다. 일주일 작업만으로 실제 운영의 신뢰성이 확보된다는 근거는 아닙니다.

월요일에 가장 먼저 할 일은 최근의 오답 하나를 골라 전체 실행 기록을 보존하는 것입니다. 근거가 없었는지, 오래됐는지, 잘못 해석됐는지, 아니면 무시됐는지 확인합니다. 그 실패를 잡아내는 데 필요한 최소한의 검증을 추가하고, 해당 장애를 계속 실행할 회귀 테스트 사례로 남깁니다.

LLM 할루시네이션에 관한 자주 묻는 질문

신뢰할 수 있는 AI 워크플로를 구축하는 실무 가이드를 받으려면 뉴스레터를 구독하세요.