Saram Consulting환각(hallucination)을 잡아내기 위해 팩트 체크용 LLM을 배포합니다. 이 모델은 아주 자신만만하게 세 개의 주장을 거짓(false)으로 판정합니다. 그런데 그중 두 개는 실제로 사실이었습니다. 그렇다면 진짜 오류는 어떻게 되었을까요? 모델은 이를 아예 놓쳐버렸습니다.
익숙한 상황입니까? 여러분은 방금 AI 엔지니어링에서 가장 값비싼 함정에 빠진 것입니다. 바로 현실 세계와의 연결 고리 없이, 하나의 확률 엔진으로 또 다른 확률 엔진을 검증하려 한 것입니다.
핵심적인 역설 (The core paradox)
LLM B가 자신의 파라메트릭 메모리(parametric memory, 매개변수 메모리)에만 의존하여 LLM A를 ’팩트 체크’할 때, 모델은 정확히 동일한 토큰 예측 프로세스를 실행하고 있는 것에 불과합니다. 정보를 실제로 찾아보고 있는 것이 아닙니다. 단지 검증처럼 들리는 텍스트를 생성하고 있을 뿐입니다. 두 모델 모두 겹치는 웹 말뭉치(web corpora)를 기반으로 학습되었고, 유사한 편향을 공유하며, 완전히 동일한 목표—그럴듯하게 들리는 결과물 생성—를 위해 최적화되어 있습니다.
이러한 방식이 특히 위험한 이유는 세 가지 실패 모드 때문입니다.
상호 연관된 오류 (Correlated errors). 학습 데이터의 오류로 인해 모델 A가 날짜를 틀렸다면, 모델 B 역시 동일한 잘못된 날짜를 학습했을 가능성이 높습니다. 유사한 데이터로 훈련된 모델들 간의 합의(consensus)는 독립적인 교차 확인이 아닙니다. 그것은 상호 연관된 노이즈(correlated noise)에 불과합니다.
영합성 / 아첨 현상 (Sycophancy). LLM은 도움이 되는(helpful) 방향으로 미세 조정(fine-tuning)되며, 이는 종종 확신에 찬 어조의 입력에 무조건 동조하는 경향으로 이어집니다. 원본 텍스트가 권위 있게 서술되어 있다면, ’팩트 체커’는 그 확신에 맞추기 위해 정당화 근거를 환각해 냅니다. 반대로 “환각을 찾아내라”고 프롬프트를 주면, 사용자를 만족시키기 위해 거짓 양성(false positive, 오탐)을 지어냅니다. 어느 쪽이든 진실을 얻는 것이 아니라 단순한 ’순응(compliance)’을 얻고 있을 뿐입니다.
동일한 작업, 동일한 실패 (Same task, same failure). 기억에서 사실을 생성하는 것과 기억에서 사실을 검증하는 것은 근본적으로 동일한 연산입니다. 새로운 정보는 전혀 주입되지 않았습니다. 단지 결함이 있는 동일한 프로세스를 두 번 실행하고, 그 결과를 ’검증’이라고 이름 붙였을 뿐입니다.
그 결과는 치명적입니다. 모델 A의 단순 환각도 문제지만, 모델 B가 이를 ’확인’해 주는 순간 거짓 주장에 대해 ’독립적인 검증’이 이루어진 것처럼 둔갑합니다. 이는 불확실성을 거짓된 확신(false confidence)으로 바꾸어 놓기 때문에, 검증을 아예 거치지 않는 것보다 훨씬 위험합니다.
해결책: 검증기를 현실 세계에 접지(Grounding)하라
해결책은 프롬프트 엔지니어링이 아닌 아키텍처에 있습니다. 팩트 체크 LLM의 역할을 **진실을 기억해 내는 것(recalling truth)**에서 검색된 근거(retrieved evidence)와 주장을 대조하는 것으로 전환해야 합니다.
이렇게 생각해 보십시오. 모델 A는 변론서를 작성하는 변호사입니다. 팩트 체커는 기억에 의존해 의견을 내는 또 다른 변호사가 되어서는 안 됩니다. 팩트 체커는 도서관으로 달려가 구체적인 법률 서적을 꺼내고, 정확한 문단을 찾아 읽은 다음, 이를 책상 위에 올려놓는 법률 보조원(paralegal)이어야 합니다.
팩트 체커가 검증 가능하고 인용할 수 있는 출처를 여러분의 책상 위에 올려놓지 못한다면, 두 모델 모두 환각을 일으키고 있다는 사실 외에는 아무것도 알아낸 것이 없습니다.
다섯 가지 아키텍처 개선안
1. 원자적 주장 단위 분해 (Atomic claim decomposition)
LLM은 여러 문장으로 구성된 문단을 하나의 덩어리로 신뢰성 있게 평가할 수 없습니다. 예를 들어 “아폴로 11호는 1969년 7월 20일에 착륙했으며, 버즈 라이트이어를 포함한 세 명의 우주비행사를 태우고 있었다”라는 문단에는 세 개의 서로 다른 사실적 주장이 포함되어 있습니다. 검증기는 혼란에 빠져 잘못된 세부 사항 하나 때문에 전체를 거부하거나, 반대로 전체를 그냥 수용해 버립니다.
검증을 수행하기 전에 모든 출력물을 독립적으로 검증 가능한 원자적 주장(atomic claims) 단위로 분해하십시오.
Original: "The EMA published their AI framework in January 2026,
covering all 27 member states with binding requirements."
Atomic claims:
1. The EMA published an AI framework.
2. The publication date was January 2026.
3. The framework covers all 27 EU member states.
4. The framework contains binding requirements.각 주장은 개별적으로 독립적인 검증을 거칩니다. 이는 FActScore 및 SAFE 벤치마크의 기반이 되는 핵심 기법이며, 검증 파이프라인에서 얻을 수 있는 단일 개선 사항 중 가장 영향력이 큽니다.
2. 모든 검증을 검색된 근거에 고정 (Anchor every check to retrieved evidence)
절대로 “이 주장이 사실인가요?“라고 묻지 마십시오.
항상 다음과 같이 물어야 합니다. “출처 문서 X가 이 주장을 명시적으로 지지(support)하는가, 반박(contradict)하는가, 아니면 언급하지 않는가?”
이는 작업의 본질을 환각 위험이 높은 지식 검색(knowledge retrieval)에서 환각 위험이 매우 낮은 독해(reading comprehension) 및 자연어 추론(NLI, Natural Language Inference)으로 전환합니다. 검증기는 더 이상 사실을 창작하지 않으며, 제공된 텍스트와 주장을 단순히 비교 대조할 뿐입니다.
신뢰도 순으로 정리한 세 가지 접지(grounding) 패턴은 다음과 같습니다.
| 패턴 | 작동 방식 | 신뢰도 |
|---|---|---|
| RAG 파이프라인 | 관련 문서를 검색하여 주장과 함께 검증기에 전달 | 높음 (High) |
| 웹 검색 | 검색 기능이 활성화된 모델이 출처를 가져온 후 이를 기반으로 추론 | 높음 (High) |
| 직접 API/DB 조회 | 권위 있는 데이터베이스를 프로그래밍 방식으로 직접 쿼리 | 매우 높음 (Very high) |
여기서 핵심적인 제약 조건은 검증기가 검색된 출처 내에서만 선택할 수 있어야 한다는 점입니다. 검증기는 새로운 인용구를 지어낼 수 없습니다. 이러한 ’제약된 귀속(constrained attribution)’은 검증기가 뒷받침 근거 자체를 환각해 내는 것을 원천 차단합니다.
3. 모호한 느낌(Vibes)이 아닌 정확한 원문 인용 강제
단순한 판정 결과(bare verdict)를 그대로 수용해서는 안 됩니다. 검증기가 “지지됨(SUPPORTED)” 또는 “반박됨(CONTRADICTED)“이라고 판단했다면, 이를 입증하는 출처 텍스트의 정확한 원문 인용구(verbatim quote)를 반드시 제시하도록 요구해야 합니다.
직접 인용구를 추출할 수 없다면, 검증기는 해당 주장을 “거짓”이나 “아마도 틀림”이 아닌 근거 없음(UNSUPPORTED), 즉 “제공된 근거로부터는 이를 검증할 수 없음”으로 라벨링해야 합니다.
이 요건을 통해 검증 프로세스는 반증 가능(falsifiable)해집니다. 인용구가 출처에 실제로 존재하는지 확인할 수 있고, 그 인용구가 검증기가 주장하는 바를 실제로 뒷받침하는지 대조할 수 있습니다. 이 요구사항이 없다면 검증기는 아무런 책임성 없이 그럴듯한 문단을 또 하나 지어내고 있을 뿐입니다.
4. 참/거짓 이진 분류 대신 구조화된 분류 체계 사용
참/거짓(True/False)이라는 이진 분류는 잘못된 프레임워크입니다. 검증기에는 최소한 세 가지 범주가 필요합니다.
| 범주 | 의미 | 조치 사항 |
|---|---|---|
| VERIFIED (검증됨) | 출처의 직접 인용구가 이 주장을 뒷받침함 | 승인 (Accept) |
| CONTRADICTED (반박됨) | 출처 텍스트가 명시적으로 정반대 사실을 진술함 | 거절 (Reject) |
| UNSUPPORTED (근거 없음) | 출처에서 이를 전혀 언급하지 않음 | 사람의 수동 검토 대상으로 분류 |
여기서 UNSUPPORTED(근거 없음) 범주는 매우 중요합니다. “근거를 찾지 못했다”는 것은 “이것이 거짓이다”와 같지 않습니다. 마찬가지로 “근거가 이를 반박하지 않는다”는 것이 “근거가 이를 증명한다”는 뜻도 아닙니다. 이러한 퇴로(escape hatch)가 없으면 검증기는 잘못된 정밀성(false precision)을 강요받게 되며, 바로 그 잘못된 정밀성 속에서 환각이 자라납니다.
5. 결정론적 코드로 출력 제어 (Gate the output with deterministic code)
LLM이 가장 취약한 영역(수학, 날짜, 논리, 정확한 인용, 논문 인용 검증 등)에는 LLM의 판단을 사용하지 마십시오. 결정론적 코드(deterministic code)를 사용하십시오.
| 주장 유형 | 검증 방식 |
|---|---|
| 수학 / 통계 | Python 코드 인터프리터 |
| 논문 인용 | DOI 조회, URL 유효성 검증 |
| 코드 정확성 | 컴파일러 / 테스트 스위트 |
| 규제 / 규정 텍스트 | 규제 말뭉치 직접 쿼리 |
| 날짜 / 수치 | API 또는 데이터베이스 직접 조회 |
검증기의 구조화된 출력을 코드로 전달하십시오. 특정 주장이 CONTRADICTED 또는 UNSUPPORTED로 플래그 지정되면, 또 다른 LLM에게 판정 결과를 어떻게 처리할지 맡기지 말고 프로그래밍 방식으로 응답을 즉시 거절하십시오.
검증 아키텍처 (The verification architecture)
생성에서 최종 판정에 이르는 전체 파이프라인은 다음과 같습니다.
CANDIDATE OUTPUT
│
▼
┌──────────────────┐
│ Claim Extraction │
│ (atomic facts) │
└────────┬─────────┘
│
atomic claims
│
▼
┌──────────────────────┐
│ Evidence Orchestrator │
└──────────┬───────────┘
│
┌───────────────┼───────────────┐
▼ ▼ ▼
Vector RAG Web Search API / DB
│ │ │
└───────────────┼───────────────┘
│
┌────────────────┐
│ Evidence Bundle │
└───────┬────────┘
│
┌────────────┼────────────┐
▼ ▼ ▼
Checker A Checker B Checker C
(model 1) (model 2) (model 3)
│ │ │
└────────────┼────────────┘
│
▼
┌─────────────┐
│ Adjudicator │
└──────┬──────┘
│
▼
┌─────────────────────┐
│ Deterministic Gates │
└──────────┬──────────┘
│
▼
VERDICT 핵심 설계 원칙은 검색(retrieval)과 추론(reasoning)의 분리입니다. 단 하나의 LLM에 검색, 해석, 검증, 인용, 최종 판정의 책임을 모두 부여하지 마십시오. 각 단계는 서로 다른 관심사이며 각기 다른 실패 모드를 가지고 있습니다.
다중 모델 삼각검증: 효과가 있는 것과 없는 것 (Multi-model triangulation)
서로 다른 제공업체의 여러 모델에 동일한 주장을 전달해 교차 검증하는 것은 단일 모델보다 낫습니다. 하지만 여기에는 매우 중대한 주의사항이 따릅니다.
효과가 있는 것: 모델 간의 불일치(disagreement)를 신호로 활용하는 것입니다. 검증기 A가 실제 출처와 인용구를 제시하며 VERIFIED라고 판정하고, 검증기 B가 출처 없이 기억에만 의존하여 FALSE라고 판정한다면 언제나 A의 승리입니다. 접지된 검증기(grounded checker)와 비접지 검증기(ungrounded checker) 간의 불일치는 엔지니어가 정확히 어느 부분에 집중해야 하는지 알려줍니다.
효과가 없는 것: 비접지 모델 간의 일치를 입증으로 취급하는 것입니다. 유사한 웹 데이터로 학습된 세 개의 모델이 특정 사실에 모두 동의한다 해도, 이는 빈약한 근거에 불과합니다. 동일한 학습 데이터 오류를 공유하고 있을 수 있기 때문입니다. 모델들 간의 합의는 현실과의 일치와 결코 같지 않습니다.
실무 적용 원칙: 서로 다른 연구소의 모델(상이한 학습 데이터, 다른 아키텍처)을 사용하십시오. 최대의 결정론성을 확보하기 위해 온도를 0(temperature=0)으로 설정하십시오. 그리고 적대적 프레임워크(adversarial framing)를 적용하십시오. 검증기에게 주장을 확인하라고 지시하지 말고, 주장을 **반박(disprove)**해 보라고 지시하십시오. 반박을 시도했으나 실패한 모델이, 긍정적인 확증을 찾아 나선 끝에 성공했다고 보고하는 모델보다 훨씬 신뢰할 수 있습니다.
검증 신뢰도 사다리 (The verification confidence ladder)
모든 검증이 동일한 수준의 신뢰를 담보하지는 않습니다. 신뢰 수준을 다음과 같이 정밀하게 보정(calibrate)하십시오.
| 레벨 | 검증 방식 | 신뢰도 수준 |
|---|---|---|
| 0 | 기억에 의존한 단일 LLM의 주장 | 신뢰할 수 없음 (Unreliable) |
| 1 | 기억에 의존한 두 번째 LLM의 동의 | 신뢰할 수 없음 (Unreliable) |
| 2 | 기억에 의존한 복수 LLM 간의 합의 | 취약함 (Weak) |
| 3 | LLM + 검색된 근거 (Retrieved evidence) | 중간 (Moderate) |
| 4 | LLM + 인용구가 포함된 권위 있는 출처 | 강력함 (Strong) |
| 5 | 권위 있는 근거 + 코드 기반 검증 | 매우 강력함 (Very strong) |
| 6 | 사람의 검토 + 근거 + 감사 추적(Audit trail) | 결정적임 (Definitive) |
규제 환경(regulated environments)에서는 위험도에 따라 요구 수준을 매핑하십시오.
- 저위험 정보성 주장 (Low-risk informational claim) → 레벨 3~4
- 중위험 권고사항 (Medium-risk recommendation) → 레벨 4~5 + 사람의 표본 검토(human spot-check)
- 고위험 중대 의사결정 (High-stakes decision: GxP, 안전성, 규제 준수) → 레벨 5~6 필수 적용
검증기들이 서로 충돌할 때 (When the checkers disagree)
이 상황은 가장 정확하게 대처해야 하는 시나리오입니다. 대부분의 사람들이 다섯 번째 LLM을 불러와 동점 결정을 내리게 하는 최악의 실수를 저지르는 지점이기 때문입니다.
절대 그렇게 하지 마십시오. 모델 간에 충돌이 발생하면 다음 원칙을 따릅니다.
- 한쪽은 실제 출처를 가지고 있고 다른 쪽은 없다면 — 출처를 제시한 쪽이 무조건 승리합니다.
- 양쪽 모두 출처를 가지고 있으나 의견이 엇갈린다면 — 사람이 직접 출처를 열어보아야 합니다. 대개 한쪽이 문맥을 잘못 읽었거나 오래된 블로그 글을 인용했을 가능성이 높습니다.
- 양쪽 모두 출처를 찾지 못한다면 — 이는 환각이 아니라 ‘검증 불가능(unverifiable)’ 상태입니다. 그에 맞게 표기하고 중요한 의사결정에는 절대 사용하지 마십시오.
근거의 부재가 곧 환각의 증거는 아닙니다. 거짓 ‘환각!’ 오탐의 대다수는 원본 내용이 틀려서가 아니라 검증기의 검색 성능이 부실했기 때문에 발생합니다.
검증기가 스스로 환각을 일으키고 있다는 위험 신호 (Red flags)
검증 출력물에서 다음과 같은 패턴이 나타나는지 주의 깊게 감시하십시오.
- 모호한 수정 (Vague corrections): 구체적인 전문가의 이름이나 출처를 인용하지 않은 채 “일부 전문가들은 이에 동의하지 않는다”라고 모호하게 언급함
- 날조된 인용 (Invented citations): 404 오류가 발생하는 URL, 존재하지 않는 논문 제목, 일치하지 않는 출판사
- 미세한 왜곡 (Micro-shifts): “2022년 3월 14일”을 “2022년 초”로 바꾸는 등 그럴듯하게 들리지만 정확성을 훼손하는 변형
- 과도한 확신에 찬 부정 (Overconfident negation): 실제 진실이 무엇인지 설명하지 못한 채 “이것은 거짓이다”라고만 단언함
- 완벽한 일치 (Perfect agreement): 길고 복잡한 텍스트에 대해 100% 동의하는 것은 검증기가 엄밀해서가 아니라 영합적(sycophantic)이기 때문임
결론 및 핵심 요약 (The bottom line)
스택에 LLM을 더 많이 추가한다고 해서 환각을 없앨 수는 없습니다. 메아리가 다른 메아리를 바로잡을 수 없듯이, 하나의 LLM이 다른 LLM을 검증하여 진실을 만들어낼 수는 없습니다.
실제로 효과가 있는 아키텍처는 이러한 폐쇄 루프를 깨뜨립니다.
생성(Generate) → 분해(Decompose) → 근거 검색(Retrieve evidence) → 비교 대조(Compare) → 프로그래밍 방식 제어(Gate programmatically) → 플래그 항목에 대한 사람의 검토(Human review for flagged items)
사고 모델의 전환이 필요합니다. “어떻게 하면 LLM이 다른 LLM을 팩트 체크하게 만들까?“라는 생각을 멈추십시오. 대신 “어떻게 하면 LLM을 언제든 교체 가능한 추론 컴포넌트로 활용하는 근거 기반 검증 시스템을 구축할 것인가?“를 고민해야 합니다.
시스템 아키텍처에서 LLM은 근거와 제어 시스템의 ’아래’에 위치해야지, 그 위에 군림해서는 안 됩니다. LLM을 현실을 정의하는 용도가 아니라, 현실에 대해 추론하는 도구로 사용하십시오. 이 단 하나의 원칙을 일관되게 적용하는 것만이 환각 증폭기(hallucination amplifier)와 환각 탐지기(hallucination detector)를 가르는 결정적인 차이입니다.
연구 노트: [[LLM-as-Judge-Fact-Checking-Architecture-2026]]