AI의 “자신만만함”은 올바름의 보증이 아니다 — 할루시네이션(그럴듯한 거짓말)을 근거 제시와 출력 검증으로 “포착하는” 기술

AI에게 무언가를 물어보면, 굉장히 유창하고 자신만만하게 답변이 돌아오곤 하죠.

존재하지 않는 함수를 「이걸로 작동합니다」라고 해서 붙여넣었더니 작동하지 않았다. 출처로 제시된 URL을 열었더니 404였다. 실재하지 않는 논문 제목을 저자 이름과 함께 당당하게 알려주었다. …이런 경험, 한 번쯤 있지 않으신가요?

저는 이것을 몇 번 겪으면서 어느 순간 깨달았습니다. AI의 “자신감”은 올바름의 증명이 되지 않는다. 그저 「그럴듯함」이 높을 뿐이며, 유창함과 정확성은 완전히 별개의 축이라는 것을 말이죠.

이 「그럴듯하지만 사실이 아닌 출력」을 할루시네이션 (hallucination=환각) 이라고 부릅니다. 일본어로 하면 「그럴듯한 거짓말」입니다. AI가 악의를 가지고 거짓말을 하는 것이 아니라, 구조상 어쩔 수 없이 발생한다는 것이 포인트입니다.

그리고 또 하나 중요한 용어를 미리 짚고 넘어가겠습니다. 그라운딩 (grounding) = 「답변을 제대로 된 근거(출처)에 연결하는 것」. 오늘 기사는 간단히 말하면 「AI의 답변을 근거에 묶어두고, 검증을 통해 포착하는」 이야기입니다.

이 기사에서는,

• 왜 AI는 “당당하게” 틀리는가 (최근 연구를 통해 상당히 명쾌하게 설명되고 있습니다)
• 할루시네이션은 「없애는」 것이 아니라 「줄이고·포착하는」 것이라는 관점
• 내일부터 업무에서 바로 사용할 수 있는 3층 방어 (프롬프트 예시 3개 + 코드 예시 2개 포함) - 인간이 어디를 설계하고, 어디를 판단하며, 어디를 AI에게 맡길 것인가

를 최대한 쉽게 풀어서 쓰겠습니다. AI에 아직 익숙하지 않은 분이라도 「아하, 우선 이걸 하면 되겠구나」라고 이해할 수 있는 상태를 목표로 합니다.

먼저, 이 부분이 가장 흥미로운 지점입니다.

「AI가 틀리는 건 아직 똑똑하지 않아서니까, 더 똑똑해지면 사라지는 거 아냐?」라고 생각하기 쉽습니다. 하지만 최근 연구를 읽어보면 아무래도 그것만이 전부가 아닙니다.

2025년 9월에 OpenAI 연구진 등이 발표한 논문 「Why Language Models Hallucinate」 (arXiv:2509.04664)가 매우 납득이 가는 설명을 하고 있습니다. 요점을 아주 쉽게 풀이하면 다음과 같습니다.

현재의 AI는 「모릅니다」라고 말하는 것보다 「짐작해서 대답하는」 편이 “성적이 더 좋아지도록” 훈련되어 있습니다.

무슨 뜻일까요? AI의 똑똑함을 측정하는 테스트 (벤치마크)의 대부분은 정답이면 1점, 오답이면 0점, 그리고 「모릅니다」도 0점으로 채점하기 때문입니다.

여기서 학생 시절의 시험을 떠올려 보세요. 빈칸으로 제출하면 확실히 0점입니다. 하지만 무언가 적어 놓으면 「운 좋게 맞출 수도」 있습니다. 그렇다면… 일단 채워 넣게 되죠.

AI도 완전히 똑같은 구조에 놓여 있습니다. 「모른다」고 솔직하게 말해도 0점이라면, 자신만만하게 찍는 것이 기대 점수가 더 높아집니다. 그래서 모르는 내용이라도 그럴듯하게 채워 넣는 것입니다. 이것이 할루시네이션의 커다란 정체 중 하나라는 뜻입니다.

이 지점에서 마음이 좀 편해지실 겁니다. 할루시네이션은 AI가 고장 났다거나, 게으름을 피우고 있다는 식의 이야기가 아닙니다. 학습과 평가 설계의 자연스러운 “귀결”인 것입니다.

그렇다면 비난해 봤자 소용없습니다. 비난하는 대신, 우리가 「검증할 수 있는 메커니즘」을 설계하면 됩니다. 이것이 오늘 가장 전달하고 싶은 태도입니다.

여기서 중요한 주의사항을 미리 말씀드립니다.

인터넷에서 「할루시네이션 대책」을 검색하면 「이것으로 완전히 없앨 수 있다」와 같은 헤드라인이 나옵니다. 하지만 솔직히 말씀드리겠습니다. 현시점에서 할루시네이션을 완전히 제로로 만드는 마법은 없습니다.

연구 세계에서도 2025~2026년 서베이 논문 (arXiv:2510.06265 등)들이 입을 모아 말하는 것은 「단일 기법으로는 빈틈이 남는다. 여러 기법을 층(layer)으로 겹치는 것이 가장 낫다」는 것입니다.

따라서 이 기사의 목표는 「거짓말을 제로로 만드는 것」이 아니라 다음과 같습니다.

• 줄이기… 애초에 거짓말이 나오기 어려운 전달 방식·질문 방식을 사용한다
• 포착하기… 발생한 거짓말을 인간의 눈에 닿기 전에 감지하여 멈춘다

건강검진에 비유하면 이해하기 쉬울지도 모릅니다. 병을 100% 예방할 수는 없지만, 생활 습관으로 줄이고, 검사를 통해 빨리 잡아냅니다. AI의 출력도 마찬가지로, 「줄이는 설계」와 「포착하는 검증」을 세트로 갖추는 것이 현실적인 승리 전략입니다.

그렇다면 구체적으로 어디에서 멈춰야 할까요? 저는 3가지 층으로 생각하면 정리하기 쉽다고 보고 있습니다.

층	한마디로 하면	여기서 할 일
① 입력층 (근거를 전달)	「상상해서 답하게 하지 않는다」	답의 재료가 되는 올바른 자료를 함께 전달 (Grounding / RAG)
...	...	...

순서대로 가보겠습니다.

가장 효과적이면서도 놓치기 쉬운 것이 바로 여기입니다.

AI는 아무런 자료를 전달하지 않으면 '기억(학습한 지식)'에서 답합니다. 이 기억은 모호하고 오래된 경우가 많습니다. 따라서 답의 재료가 되는 1차 정보(사내 문서, API 사양, 해당 코드 등)를 함께 전달해 주는 것. 이것만으로도 상상으로 빈틈을 채울 여지가 급격히 줄어듭니다.

이 '관련 자료를 검색하여 그것을 재료로 답하게 하는' 메커니즘을 멋지게 부르면 **RAG (Retrieval-Augmented Generation = 검색 증강 생성)**라고 합니다. 어렵게 들리지만, 첫걸음은 매우 단순합니다. **"해당할 법한 문서를 프롬프트에 붙여서 함께 전달하는 것"**만으로도 훌륭한 Grounding (그라운딩)입니다.

아까의 연구를 떠올려 보세요. AI는 "모릅니다"가 0점이라고 판단하면 어떻게든 답을 맞추려 합니다. 그렇다면 이쪽 프롬프트에서 "모른다고 말해도 괜찮아"라는 퇴로를 명시적으로 만들어 주면 됩니다.

이것이 효과적입니다. 프롬프트 예시 3가지를 남겨두겠습니다. 그대로 복사해서 조정하여 사용하세요.

프롬프트 예시 1: 기권(棄権)을 허용하고 인용을 강제하기 (기본형)

당신은 사실 확인에 엄격한 어시스턴트입니다.
이하의 <자료>에 적혀 있는 내용'만'을 근거로 질문에 답해 주세요.
# 규칙
...

포인트는 "자료에 없는 것은 '판단할 수 없습니다'라고 말해도 된다"라고 퇴로를 만들어 준 것과, "문장마다 출처를 붙이게 한 것"입니다. 출처를 붙일 수 없다 = 근거가 없다, 이므로 거짓말이 섞이기 어려워집니다.

프롬프트 예시 2: 자신의 답을 스스로 점검하게 하기 (자기 검증 / Chain-of-Verification)

AI에게 한 번 답을 하게 한 뒤, 다시 한번 "지금의 답, 근거가 있어?"라고 되돌아보게 하는 방법입니다. 의외로 스스로 알아차립니다.

당신이 직전에 작성한 답변을 한 문장씩 점검해 주세요.
# 절차
1. 답변을 한 문장씩 분해한다.
...

프롬프트 예시 3: 확신도 라벨로 "이 부분 수상함"을 시각화하기

전부를 의심하는 것은 힘들기 때문에, AI에게 "이 부분은 자신 있음/없음"을 신고하게 하여 인간이 확인해야 할 곳을 좁히는 전략입니다.

답변의 각 항목에 확신도 라벨을 붙여 주세요.
- [확신도:고] … 자료에 명확한 근거가 있음
- [확신도:중] … 자료로부터 추론했으나, 해석의 여지가 있음
...

여기서 중요한 것은, 이것들은 어디까지나 "줄이는" 궁리라는 점입니다. 프롬프트만 믿고 안심해서는 안 됩니다. AI는 지시를 무시하고 그럴듯한 출처를 "지어낼" 수도 있습니다. 그래서 다음의 ③이 필요합니다.

이 부분이 엔지니어의 실력을 보여줄 대목입니다. "AI가 출처를 붙였다"는 것과 "그 출처가 정말로 주장을 뒷받침하고 있는가"는 별개의 문제입니다. 그러므로 돌아온 답을 코드로 대조합니다.

"답이 제대로 출처에 적혀 있는 내용인가?"를 확인하는 것을 전문 용어로 함의 (entailment) 체크 또는 groundedness (근거에 대한 충실도) 검증이라고 합니다. 어려워 보이지만, 생각하는 방식은 "그 문장, 정말로 출처에 적혀 있어?"를 기계로 확인하는 것뿐입니다.

여기서부터 코드 예시입니다. 범용적인 더미(dummy)로 작성하므로, 본인의 환경에 맞춰 조정해 주세요 (동작은 모델이나 버전에 따라 달라지므로 반드시 직접 검증하십시오).

먼저 가장 견고한 방식부터. AI에게 "주장"과 "그 근거가 된 원문 인용"을 세트로 JSON 출력하게 하고, 그 인용이 정말로 자료 안에 존재하는지를 프로그램으로 대조합니다. 인용이 자료에서 발견되지 않으면 그 주장은 차단(불채택)합니다.

이것은 외부 API도 판정 모델도 필요 없는, 가장 저렴하고 확실한 첫걸음입니다.

import json
import unicodedata
def normalize(text: str) -> str:
...

포인트는, "AI가 무엇이라고 말했는가"가 아니라 "자료에 무엇이 적혀 있는가"를 진실의 기준 (source of truth)으로 삼고 있다는 점입니다. AI의 자기 신고를 믿지 않고, 원문과의 일치 여부만을 믿습니다. 이것만으로도 지어낸 출처의 상당 부분을 기계적으로 걸러낼 수 있습니다.

물론, 이것은 「말바꾸기 (Paraphrasing)」에는 취약합니다 (원문과 표현이 다르면 일치하지 않음). 그 부분을 강화하고 싶을 때 사용하는 다음 코드가 그것입니다.

인용이 말바꾸기 되었더라도, 「주장이 자료로부터 도출될 수 있는가?」를 다른 AI (판정역)에게 함의 체크 (Entailment Check) 시키는 방법입니다. AI의 출력을 또 다른 AI가 채점하게 하므로 LLM-as-a-judge (심판으로서의 LLM) 라고 부릅니다.

# 의사 코드: client는 임의의 LLM SDK (사내의 것이어도 OK)
def is_grounded(statement: str, source_text: str, client) -> dict:
judge_prompt = f"""
...

여기서 걱정이 많은 제 모습이 나타납니다. 판정역 AI도 틀립니다. judge를 과신하여 완전 자동화로 만들면, 「AI의 거짓말을 다른 AI가 "OK"라고 보증함」과 같은 사고도 일어날 수 있습니다.

그래서 설계의 철칙은 이렇습니다. supported 이외에는 인간 리뷰 (Human Review)로 넘긴다. judge는 「전부를 사람이 보는 것은 불가능하므로, 수상한 것만 사람에게 올리는 "분류 담당자"」로 사용합니다. 최종 책임은 인간이 집니다. 이 부분은 반드시 붙잡고 있어야 할 지점입니다.

「그래서, 내 업무 어디에서 사용하는 건데?」라는 이야기를 표로 정리해 두겠습니다. AI를 사용하는 개발 플로우의 각 단계에서, "무비판적으로 믿기 쉬운 포인트"는 대략 정해져 있습니다.

개발 플로우	AI가 저지르기 쉬운 할루시네이션 (Hallucination)	삽입해야 할 검증
조사・기술 선정	실재하지 않는 라이브러리 이름・오래된 API・날조된 URL	공식 문서를 자료로 전달하기／URL은 실제로 열어서 확인
...

공통점은, 「자연어의 설득력」이 아니라 「기계로 대조할 수 있는 사실」을 기준으로 삼는 것입니다. 코드라면 타입(Type)・테스트(Test)・린트(Lint)라는 최강의 심판이 이미 존재합니다. 문장이라면 출처와의 대조입니다. "확인 가능한 형태"로 구체화할수록, 할루시네이션은 포착하기 쉬워집니다.

여기까지를 역할별로 정리해 두겠습니다. 이것이 이 기사의 뼈대입니다.

AI에게 맡기기: 대량의 초안 작성, 요약, 후보 도출, 1차 리뷰, 인용이 포함된 드래프트 생성. 속도가 필요한 부분.

인간이 설계하기: 「어떤 자료를 근거로 할 것인가」 「무엇을 검증할 것인가」 「어디를 자동으로 걸러내고 어디를 사람에게 올릴 것인가」라는 메커니즘 (Gate) 설계.

인간이 판단하기: 검증에서 "수상함"으로 올라온 것, 확신도가 낮은 것, 그리고 고위험 영역 (금융・의료・법률・보안・공개 정보)의 최종 OK.

바꿔 말하면, 엔지니어의 업무는 「AI에게 정답을 내게 하는 것」에서, **「AI의 출력을 저렴하고 확실하게 검증할 수 있는 흐름을 설계하는 것」**으로 옮겨가고 있다는 느낌이 듭니다. 똑똑한 모델을 기다리는 것이 아니라, 지금 있는 모델을 "신뢰할 수 있는 부품"으로組み込む (조합하는) 설계 능력. 이 부분이 앞으로 엄청난 가치가 될 것이라고 생각합니다.

처음에 썼듯이, 할루시네이션은 AI가 고장 나서가 아니라, 학습과 평가 설계의 자연스러운 귀결이었습니다.

그러니 AI를 비난해도, AI에 휘둘린 자신을 비난해도 별 의미가 없습니다. 비난의 축이 아니라, 배려의 축으로 생각하고 싶습니다.

제가 자주 스스로에게 던지는 질문은, 「이것, 내일의 내가 "고마워요(아자스)"라고 말해줄까?" 라는 한마디입니다.

• 오늘, 출처를 강제하는 프롬프트에 한 줄을 추가해 둔다 → 내일의 내가 날조된 URL을 자료에 붙여넣지 않아도 된다. 고마워요.
• 오늘, 인용 대조 게이트(Gate)를 20줄만 작성해 둔다 → 다음 주의 내가 거짓말이 섞인 답변을 고객에게 내놓지 않아도 된다. 고마워요.
• 오늘, "고위험은 인간 리뷰"라고 결정해 둔다 → 반년 뒤의 내가 조용한 사고를 방지하고 있다. 고마워요.

거창한 것이 아니어도 됩니다. 완벽한 대책 (거짓말 제로)을 목표로 하지 않아도 됩니다. 오늘 작은 검증을 하나 심어두는 것. 그것만으로도 내일의 나는 "무리하지 않게 해줘서 고마워요"라고 말해줄 것입니다.

AI의 "자신만만함"은 올바름의 보증이 아닙니다. 하지만 우리가 검증을 설계해 둔다면, AI의 속도를 당당하게 사용할 수 있게 됩니다. 무서워서 사용할 수 없지만 멈출 수도 없는... 그런 공중에 붕 뜬 상태에서 한 걸음 벗어날 수 있습니다.

우선, 평소 사용하는 프롬프트 마지막에 이 한 문장을 추가하는 것부터 시작해 보는 건 어떨까요?

"자료에 근거가 없는 내용은 추측으로 채우지 말고 '판단할 수 없습니다'라고 답해 주세요."

여기서부터 시작하면 충분합니다. 내일의 내가 분명 "고마워요"라고 말해줄 것입니다.

• OpenAI / Kalai, Nachum, Vempala, Zhang 「Why Language Models Hallucinate」(arXiv:2509.04664, 2025) — 평가가 "찍기"를 "모릅니다"보다 더 높은 보상을 주는 문제
• LLM 할루시네이션 (Hallucination) 완화에 관한 서베이 (arXiv:2510.06265, 2025–2026) — Prompt / Retrieval / Reasoning / Model-centric의 4가지 분류와 하이브리드 방식의 유효성
• 실무에서의 인용 검증 (Citation Verification) · 근거성 (Groundedness) 채점 · LLM-as-a-judge 패턴 해설 (각종 기술 블로그, 2025–2026)

※ 본 기사의 코드는 메커니즘을 설명하기 위한 범용 샘플입니다. 동작은 모델, 버전, 설정에 따라 달라집니다. 실제 서비스 적용 전에는 반드시 사용자의 환경에서 검증하십시오.