AI가 설득력 있게 틀릴 수 있는 이유

조금 과장해서 말하면, 언어 모델은 1 + 1 = 3이어야 하는 이유를 아주 그럴듯하게 설명할 수 있습니다. 깔끔한 논리 구조를 세우고, 중간 단계를 제시하며, 마치 교과서처럼 확신에 찬 어조로 결론을 내놓을 수도 있습니다.

이 예시에서는 위험이 상대적으로 작습니다. 우리는 정답을 알고 있기 때문에 오류를 바로 알아차릴 수 있습니다.

하지만 같은 메커니즘은 우리가 스스로 그 전제를 검증할 만큼의 전문지식을 갖고 있지 않을 때 훨씬 더 중요해집니다. 드물게 쓰이는 Framework API에 대한 잘못된 설명도 정확한 기술 설명처럼 보일 수 있고, 트랜잭션 경계에 대한 잘못된 판단도 분산 시스템 경험이 없는 사람에게는 충분히 그럴듯하게 들릴 수 있습니다. 보안 관련 질문에서는 잘못된 가정이 오직 그 종류의 시스템을 실제로 분석해 본 사람에게만 드러날 수도 있습니다.

그래서 핵심 질문은 우리가 노골적인 헛소리를 구별할 수 있느냐가 아닙니다.

정말 중요한 질문은, 사람이 스스로 1 + 1 = 3이라는 주장이 틀렸다는 사실을 모를 때 무엇이 일어나는가입니다.

일상적인 표현으로는 AI가 “거짓말을 했다”고 말하기 쉽습니다. 수사적 표현으로는 이해할 수 있지만, 기술적으로는 이 메커니즘을 잘 설명하지 못합니다. 거짓말은 보통 어떤 사람이 그 말이 틀렸다는 것을 알고 있으면서도 속일 의도로 말하는 것을 전제합니다. Large Language Model에 그런 의도를 쉽게 투영해서는 안 됩니다.

더 정확한 표현은 다음과 같습니다.

모델은 설득력 있게 틀릴 수 있습니다.

그리고 바로 그렇기 때문에 이 글의 핵심 명제가 중요합니다.

Plausibility는 Truth의 기준이 아닙니다.

가장 위험한 Hallucination은 위험해 보이지 않습니다

명백한 헛소리는 상대적으로 다루기 쉽습니다. Agent가 문법적으로 존재할 수 없는 Method를 호출하면 Compiler가 반박할 수 있습니다. 생성된 Test가 Compile조차 되지 않으면 즉시 Feedback을 받습니다. 모델이 베를린이 프랑스에 있다고 말한다면, 대부분의 사람은 추가 도구 없이도 의심할 수 있습니다.

더 어려운 것은 기존 지식에 자연스럽게 섞여 들어가는 오류입니다.

답변은 기술 용어를 정확히 쓰고, 익숙한 Pattern을 사용하고, 구조도 깔끔하며, 이유 설명까지 그럴듯할 수 있습니다. 열 개의 문장 중 아홉 개는 맞을 수도 있습니다. 단 하나, 이후 해결 경로 전체가 의존하는 열 번째 문장만 틀릴 수 있습니다.

그렇다고 덜 위험한 것은 아닙니다. 오히려 반대입니다.

가장 위험한 Hallucination은 그것이 틀렸다는 사실을 알아보는 데 도메인 지식이 필요한 Hallucination입니다.

사람은 언어적 자신감을 내용의 신뢰성으로 쉽게 해석합니다. 하지만 LLM에서는 이 둘을 같은 것으로 볼 수 없습니다. 우아한 설명은 우선 우아한 설명일 뿐입니다. 논리 구조가 있다고 해서 전제가 참이라는 뜻은 아닙니다. 전문적으로 보이는 Code Block 역시 그 안의 API가 실제로 존재한다는 증거는 아닙니다.

처음에는 이것을 개별 모델의 단순한 품질 문제로 볼 수도 있습니다. 하지만 메커니즘은 더 깊고, 언어 모델이 텍스트 생성을 학습하는 방식부터 시작됩니다.

왜 Hallucination이 생기는가?

Hallucination이라는 말은 이제 지어낸 사실부터 모든 오답, 심지어 Agent의 모든 원치 않는 결정까지 매우 넓게 가리킵니다.

기술적 논의를 위해서는 범위를 좁혀야 합니다. 모든 오류가 같은 원인에서 생기는 것은 아닙니다.

언어 모델은 Truth Registry가 아닙니다

Large Language Model 안에 다음과 같은 데이터베이스가 단순히 들어 있는 것은 아닙니다.

진술
↓
참 / 거짓

Pretraining에서 모델은 방대한 텍스트로부터 통계적 구조와 관계를 학습합니다. 단순화하면 주어진 조건에서 어떤 텍스트가 이어질 가능성이 높은지를 배우는 것입니다. Training Data의 모든 문장에 “참” 또는 “거짓”이라는 명시적 Label이 붙는 것은 아닙니다.

OpenAI가 2025년에 공개한 분석은 Hallucination 문제의 일부를 바로 이 관점에서 설명합니다. 예측 가능한 언어 구조는 많은 사례로부터 잘 학습할 수 있지만, 드물거나 대체로 임의적인 사실은 구체적 형태를 안정적으로 복원할 만큼 충분한 Pattern을 제공하지 않을 수 있습니다. 또한 오답의 비용이 Abstention보다 낮은 일반적인 Evaluation 방식은 불확실성을 드러내기보다 추측하도록 유도할 수 있습니다.

그렇다고 LLM이 사실을 무작위로 추측하기만 한다는 뜻은 아닙니다. 현대 모델에는 방대한 유용한 지식이 있습니다. 핵심은 특정 지점에 신뢰할 만한 정보가 없더라도 그럴듯한 텍스트를 생성하는 능력이 자동으로 사라지지 않는다는 점입니다.

지식의 공백이 Output에서 지식의 공백처럼 보일 필요는 없습니다.

모델은 한 주제에 관해 매우 많은 것을 알면서도 구체적인 과제에 결정적인 바로 그 정보만 충분히 표현하지 못할 수 있습니다.

없거나 오래된 정보

지식이 빠르게 오래될 때 이 문제는 특히 잘 드러납니다.

Framework에는 새 API가 생기고, Library의 동작은 바뀌며, 표준은 발전합니다. Cloud Service는 제품을 교체합니다. 기업 내부 시스템은 공개 Training Data에 아예 등장하지 않습니다.

예를 들어 모델은 Angular Component, Dependency Injection, RxJS, Change Detection과 오랜 Coding Pattern을 알면서도 방금 출시된 API에 관한 지식은 불완전할 수 있습니다.

그러면 흥미로운 상황이 생깁니다. Angular처럼 보이는 답변을 만들 Context와 새 API의 이름 및 기본 개념은 갖고 있지만, 각 요소를 기술적으로 올바르게 조합할 세부사항은 부족합니다.

결과는 문법적으로 설득력 있고 개념적으로 그럴듯하지만 실제로는 동작하지 않을 수 있습니다.

드문 Library, Proprietary API, 특수한 전문지식, 아주 새로운 표준에서도 마찬가지입니다.

많이 안다는 사실이 결정적인 지점에서 너무 적게 아는 일을 막아 주지는 않습니다.

잘못됐거나 불완전한 Context

모든 오답이 모델의 지식 공백에서 생기는 것은 아닙니다.

Agent가 매우 강력한 모델을 사용하면서도 나쁜 Evidence를 토대로 작업할 수 있습니다.

Repository Search가 오래된 구현을 찾거나, 낡은 문서가 폐기된 개념을 설명할 수 있습니다. Requirements가 누락되거나 두 Agent File이 모순될 수 있습니다. Tool Error를 잘못 해석하거나 Memory에 현재 Version에는 더 이상 유효하지 않은 결정이 남아 있을 수도 있습니다.

이런 상황을 모두 Hallucination이라고 부르는 것은 정확하지 않습니다.

필요한 정보가 Context 안에 있어도 잘못 가중되거나 결합되거나 덜 중요한 Evidence보다 후순위로 밀릴 수 있습니다.

이는 오히려 기존 Evidence에 대한 오해에 가깝습니다.

이 구분은 실무적으로 중요합니다. 지식이 없을 때는 최신 문서나 Search가 도움이 될 수 있습니다. Evidence가 나쁠 때는 Context를 더 준다고 자동으로 해결되지 않습니다. 오래된 문서를 더 많이 넣어도 잘못된 결론이 옳아지지는 않습니다.

잘못된 추론

세 번째 형태도 있습니다.

모델이 관련 사실을 올바르게 알고도 잘못된 결론을 내릴 수 있습니다.

두 지점의 Transaction을 각각 정확히 인식하면서도 Atomicity에 관한 결론은 틀릴 수 있습니다. 두 API를 올바르게 설명했지만 사용 중인 Lifecycle에서는 그 조합이 유효하지 않을 수 있습니다. Security Mechanism을 정확히 설명하고도 잘못된 Trust Boundary에 적용할 수 있습니다.

실무에서는 적어도 다음 네 가지를 구분해 두는 것이 도움이 됩니다.

• 없거나 오래된 지식,
• 실제로 지어냈거나 근거 없는 정보,
• 기존 Evidence에 대한 오해,
• Reasoning 또는 추론 과정의 오류.

실제 상황에서는 이 범주들이 겹칠 수 있지만 Verification에서는 무엇을 다루는지에 따라 대응이 달라집니다.

지식의 공백과 언어적 불확실성은 같은 것이 아닙니다

사람도 완벽하게 Calibration되어 있지는 않습니다. 자신의 지식을 과대평가하고 잘못 기억하며, 실제 Evidence보다 더 확신에 차서 답할 수 있습니다.

언어 모델에는 한 가지 어려움이 더 있습니다. 답변의 어조만으로는 그 바탕이 되는 Evidence의 강도를 신뢰성 있게 추론할 수 없습니다.

모델이 자동으로 다음과 같은 완벽한 내부 상태 표시기를 갖는 것은 아닙니다.

확실히 안다
일부만 안다
모른다

모델이 자신의 답변이 맞을 가능성에 관한 정보를 가질 수 있음을 보여 주는 연구는 분명히 있습니다. Anthropic은 이미 2022년에 모델이 자기 진술의 정확성 확률을 평가할 수 있는지 조사했습니다. 적절한 Task와 Format에서는 쓸 만한 Calibration이 나타났지만, 새로운 Task로 Generalization할 때의 문제도 드러났습니다.

따라서 “모델은 자신의 불확실성을 절대 평가하지 못한다”는 주장도, 언어로 표현된 확신이 자동으로 잘 Calibration되어 있다는 가정만큼이나 틀립니다.

최근 연구는 “아마도”, “확실하지 않습니다” 같은 표현이나 자신감 있는 답변이 실제 모델 내부의 불확실성과 일치하는지를 명시적으로 조사합니다. 2025년 EMNLP 논문 MetaFaith는 조사 대상 모델과 방법에서 별도 조치 없이는 이러한 언어적 Calibration이 여전히 상당히 신뢰하기 어렵다는 점을 보여 줍니다.

LLM에서는 지식의 공백과 언어적 불확실성이 같은 것이 아닙니다.

바로 그렇기 때문에 Evidence가 부족할 때 구체적인 주장을 하지 않는 Abstention이 별도의 Optimization Goal이 되고 있습니다.

OpenAI의 SimpleQA가 흥미로운 예입니다. Web Access 없이 gpt-5-thinking-mini는 Accuracy 22%, Hallucination Rate 26%를 기록했습니다. o4-mini의 Accuracy는 24%로 비슷했지만 Hallucination Rate는 75%였습니다. 결정적인 차이는 더 새로운 모델이 구체적인 답을 훨씬 자주 보류했다는 점입니다. Abstention은 52% 대 1%였습니다. 이 수치는 어느 모델에나 적용되는 일반적인 Hallucination Rate가 아닙니다. SimpleQA는 짧은 사실 질문을 의도적으로 어렵게 만든 Benchmark입니다. 하지만 더 많이 답하기와 더 좋은 답을 하기가 같은 목표가 아님을 잘 보여 줍니다.

2023년과 지금은 같은 세계가 아닙니다

초기 ChatGPT 시절부터 LLM을 집중적으로 사용해 온 사람은 서로 반대되는 두 가지 오류를 범하기 쉽습니다.

하나는 2023년의 경험을 오늘날 모델에도 그대로 적용하는 것이고, 다른 하나는 엄청난 발전을 문제가 완전히 해결됐다는 뜻으로 받아들이는 것입니다.

둘 다 실제 발전을 제대로 반영하지 못합니다.

초기의 Factuality Benchmark는 Hallucination이 왜 그렇게 빠르게 핵심 이슈가 됐는지를 보여 줍니다. 2023년 발표된 HaluEval에서 연구진은 특정 Test Category의 사용자 질문에 대한 ChatGPT 답변 중 약 19.5%가 검증할 수 없는 정보를 생성했다고 보고했습니다. 이는 2023년 ChatGPT의 일반적인 Hallucination Rate가 아니라, 해당 Benchmark 방법론의 결과입니다.

같은 해 FActScore는 전혀 다른 문제를 조사했습니다. 긴 인물 전기를 Atomic Fact로 나눈 뒤 신뢰할 만한 출처가 각 사실을 얼마나 뒷받침하는지 평가했습니다. 사람에 의한 Evaluation에서 ChatGPT의 FActScore는 58%였습니다. 이 역시 이 Task만 설명하며 HaluEval의 19.5%와 합산하거나 직접 비교해서는 안 됩니다.

그보다 앞선 TruthfulQA에서 가장 성능이 좋았던 모델은 Truthful Answer 58%를 기록한 반면 사람은 94%였습니다. 다만 이 Benchmark는 2021년에 공개됐고, 오래된 모델 세대와 흔한 오해가 오답을 유도하는 질문을 다뤘습니다. 현대 시스템의 비교값이라기보다 역사적 맥락입니다.

반면 최근 측정은 다른 품질 수준을 보여 줍니다.

GPT-5 System Card는 LongFact와 FActScore의 Open-ended Factual Question을 Browsing 유무에 따라 평가했습니다. Browsing을 사용한 gpt-5-thinking의 Claim-level Hallucination Rate는 LongFact Concepts 0.7%, LongFact Objects 0.8%, FActScore 1.0%였습니다. 같은 평가에서 OpenAI o3는 각각 4.5%, 5.1%, 5.7%였습니다. Browsing 없이 평가한 gpt-5-thinking의 FActScore 수치는 3.7%로 올라갔습니다. 이는 OpenAI의 구체적인 Evaluation 및 Grading Pipeline에만 해당하지만, 더 나은 모델이 오류를 크게 줄이고 Search 같은 외부 Evidence가 Factuality를 추가로 개선할 수 있음을 보여 줍니다.

발전은 이어졌습니다. 8월 GPT-5.6 Update에서 OpenAI는 Factuality 중심 Production Prompt, 사용자가 신고한 과거 오류, 의료·법률·금융의 High-Stakes Prompt라는 의도적으로 어려운 세 Set에서 GPT-5.5 Instant보다 개선됐다고 보고했습니다. GPT-5.6 Sol의 사실 오류율은 세 Set 전체에서 약 60% 낮았습니다. OpenAI는 이것이 어렵고 Hallucination이 발생하기 쉬운 사례를 선별한 결과이며 일반적인 ChatGPT Traffic의 평균 오류율이 아님을 명시합니다.

Anthropic의 Claude Opus 4.8 System Card는 Web Search나 다른 Tool을 쓸 수 없는 네 가지 Closed-book Factuality Benchmark를 다룹니다. Opus 4.8은 비교한 여섯 모델 가운데 네 Benchmark 모두에서 Incorrect Rate가 가장 낮았습니다. 발전의 상당 부분은 정답 증가뿐 아니라 불확실할 때 더 자주 Abstain한 데서 왔습니다. 다만 Net Score(Correct 빼기 Incorrect)에서는 Opus 4.7과의 차이가 통계적으로 유의하지 않았습니다. Anthropic 역시 외부 Tool 없는 Factual Hallucination은 해결된 문제가 아니라고 강조합니다.

이 Benchmark들은 서로 다른 것을 측정하므로 절대값을 직접 비교할 수 없습니다. 이를 하나의 전 세계적 “AI Hallucination Rate” 곡선으로 합치는 것은 방법론적으로 잘못입니다.

하지만 방향은 공통적입니다.

현대 모델은 초기 Chat Model보다 Factuality가 크게 향상됐습니다. 그러나 개선은 해결과 같지 않습니다.

초기 LLM 사용 시기의 Angular 경험

나는 이 변화를 실무에서 매우 직접적으로 경험했습니다.

당시 모델도 Component, Service, Dependency Injection, RxJS, 전통적인 Change Detection Pattern에서는 매우 유용한 코드를 만들 만큼 Angular를 잘 알았습니다.

그러다 Signals가 등장했습니다.

Angular 16은 2023년에 새 반응성 모델인 Signals를 Developer Preview로 처음 도입했습니다. API와 그 주변의 Pattern은 실제로 아주 새로웠습니다.

당시 나의 개인적 인상으로는 모델이 최신 Angular 상태에서 내가 실무로 다루던 수준보다 때때로 상당히 뒤처져 있었습니다. 이는 과학적 측정이 아니며, 당시 모든 모델이 정확히 몇 년씩 “뒤처져 있었다”는 주장도 아닙니다.

흥미로운 점은 그 동작이었습니다. 모델은 Angular에 대해 많은 것을 알고 있었지만, 결정적인 바로 그 지점에서는 충분히 알지 못했습니다.

나는 Signals 기반의 현대적인 구현을 요청했습니다. 모델은 이 용어를 알고 있었고, 내가 원하는 방향을 이해했으며, 그것을 기존 Angular 패턴과 결합했습니다. 결과는 Angular 코드처럼 보였고, 심지어 Signals 코드처럼도 보였습니다. 그런데 실제로는 일부 API가 그런 형태로 존재하지 않았고, 개념이 뒤섞여 있었으며, RxJS 시대의 패턴이 새 API에 맞지 않는 방식으로 옮겨져 있어서 기술적으로 작동할 수 없는 경우가 있었습니다.

다른 부분이 대부분 맞았기 때문에, 이 오류를 발견하려면 Angular를 충분히 잘 알아야 했습니다.

오늘날의 경험은 완전히 다릅니다. 현재 모델은 훨씬 최신의 Framework 상태를 알고 있습니다. Agent는 Repository Code와 최신 문서를 검색하고 API를 확인한 뒤 구현을 TypeScript, Angular Compiler, Test로 검증할 수 있습니다.

근본 메커니즘이 사라진 것은 아닙니다. 그러나 잘못된 가정을 피하거나 제때 발견할 가능성은 크게 높아졌습니다.

지금은 다른 품질 등급에 있습니다

현대의 Coding Agent는 단순히 “큰 Prompt를 받은 언어 모델”이 아닙니다.

시스템에 따라 Repository Search, Documentation, Web Search, Compiler, Type System, Test Runner, Linter, Eval과 전문 Tool을 작업 과정에 포함해 없거나 불확실한 지식을 외부 Evidence와 대조할 수 있습니다.

이것은 실제 오류 상황을 크게 바꿉니다.

모델이 최신 API Signature를 확실히 기억하지 못한다고 해 봅시다. 순수한 Chat은 Parametric Knowledge만으로 답해야 할 수 있습니다. 반면 Agent는 package.json에서 설치된 Version을 읽고 Type Definition과 최신 문서를 검색하며, 구현한 뒤 Compiler에 확인할 수 있습니다.

원래는:

API가 이렇게 동작한다고 생각한다

이상적으로는 다음 검증 과정으로 바뀝니다.

가설
↓
문서
↓
Repository
↓
구현
↓
Compiler
↓
Test
↓
Feedback

따라서 현대 Coding Agent를 초기 Chat Model의 Hallucination 문제만으로 평가하면 오해를 낳습니다.

Tool은 시스템을 바꿉니다.

LongFact와 함께 제안된 SAFE 방법은 긴 답변을 개별 사실로 나누고 Search Query를 통해 외부 Evidence와 대조합니다. 이는 새 Benchmark뿐 아니라 Generation과 Verification을 기술적으로 분리할 수 있다는 Pattern도 보여 줍니다.

다만 한 가지 중요한 제한은 남습니다.

Tool이 Truth를 보장하지는 않습니다. Agent가 잘못된 문서를 고를 수 있고 Search Result가 오래됐을 수 있습니다. Test가 잘못된 속성을 검사할 수도 있습니다. Compiler는 Type Correctness를 확인할 뿐 Domain Correctness까지 증명하지 않으며, Green Build는 Security Boundary가 올바른지 말해 주지 않습니다.

메커니즘은 사라지지 않았지만, 오류 가능성과 수정 기회는 크게 달라졌습니다.

왜 도메인 지식이 여전히 중요한가

여기서 종종 이상한 질문이 등장합니다.

모델이 점점 더 많은 코드를 생성할 수 있다면, 왜 여전히 수십 년 경험을 가진 사람이 필요할까요?

이 질문은 소프트웨어 개발을 코드 생산으로 축소합니다.

경험 많은 개발자는 단지 같은 Method를 더 빨리 입력하는 사람이 아닙니다. 특히 Coding Agent와 함께 일할수록 다른 능력이 더 중요하게 드러납니다. 그럴듯해 보이는 해결책이 실제로 문제와 시스템에 맞는지 판단하는 능력입니다.

경험 많은 엔지니어는 그 API가 정확히 그 Framework Version에는 존재하지 않는다는 점을 알아챌 수 있습니다. 어떤 Security Fix가 잘못된 Trust Boundary를 보호하고 있다는 사실을 볼 수 있습니다. 각각은 맞는 두 Database Operation이 함께는 Atomic Operation이 아니라는 점을 알 수 있습니다. 모든 로컬 Code가 그럴듯해 보여도 Race Condition이 남아 있다는 것을 볼 수 있습니다. 새로운 Dependency가 Architecture Boundary를 위반하거나, 로컬하게 우아한 해결책이 장기적으로 전체 시스템에 맞지 않는다는 것을 알아챌 수도 있습니다.

이것은 타이핑 속도의 문제가 아닙니다.

시스템과 도메인에 대한 Mental Model이 필요합니다.

어떤 도메인에 대해 내가 아는 것이 적을수록, “설득력 있는 Hallucination”과 “설득력 있는 정답”을 구분하기는 더 어려워집니다.

그렇다고 사람이 모든 답을 직접 생성할 수 있어야 한다는 뜻은 아닙니다. Library의 모든 세부사항을 외울 필요도 없습니다. 하지만 어떤 주장이 중요하고, 어떤 가정을 반드시 검증해야 하며, 어떤 Tool이 충분히 신뢰할 만한 Evidence를 줄 수 있는지는 이해해야 합니다.

전문성이 가치 있는 이유는 사람이 더 빨리 생성하기 때문이 아니라, 더 나은 판단을 가능하게 하기 때문입니다.

이것은 Junior Developer에 대한 반대가 아닙니다

이 모든 내용을 “오직 Senior Developer만 Coding Agent와 일해야 한다”는 주장으로 읽어서는 안 됩니다.

경험은 사람을 어려운 문제에서 떼어 놓는다고 생기지 않습니다.

Coding Agent는 오히려 훌륭한 학습 도구가 될 수 있습니다. 낯선 Code를 설명하고, 대안을 보여 주고, Test를 만들고, 추가 질문에 답하고, 서로 다른 Design의 결과를 함께 논의할 수 있습니다.

문제는 Generation이 자신의 사고 과정을 완전히 대체할 때 시작됩니다.

Test가 Green이고 Code가 전문적으로 보인다는 이유만으로 결과를 그대로 받아들이면, 왜 그 해결책이 작동하는지 배우는 양이 줄어듭니다. 이런 이해가 계속 쌓이지 않으면, 나중에 그럴듯하지만 잘못된 해결책을 알아보는 데 필요한 판단력 자체가 부족할 수 있습니다.

따라서 이것은 Junior Developer에 대한 반대가 아니라 Mentoring, Review, 의식적인 학습에 대한 주장입니다. 경험은 하루아침에 생기지 않으며, 여전히 성장할 공간이 필요합니다.

Chat에서 Agent로: 오류가 실행 가능한 것이 됩니다

여기까지는 Hallucination을 대체로 전통적인 Chat 문제로 볼 수도 있습니다.

잘못된 답변이 텍스트로 나타나고, 사람이 읽고 검증하거나 버립니다.

Coding Agent는 이 상황을 바꿉니다.

이 시리즈의 5번 글은 Agent의 해결 경로를 Decision, Action, Observation, 그리고 변화하는 Context의 연속으로 설명했습니다. 바로 이 구조 때문에 잘못된 가정은 새로운 성격을 갖게 됩니다.

잘못된 가정
↓
그럴듯한 결정
↓
코드 변경
↓
Repository 상태
↓
미래의 Context

예를 들어 Agent가 어떤 Architecture Rule을 잘못 해석했다고 해 봅시다.

그 결과 두 Module 사이에 새로운 Dependency를 만듭니다. Code는 Compile됩니다. Test도 여전히 Green입니다. 심지어 현재 Ticket까지 해결할 수도 있습니다.

그 순간 잘못된 가정은 더 이상 텍스트가 아닙니다.

Repository를 바꿔 버렸습니다.

다음 Task에서 같은 Agent나 다른 Agent는 그 Dependency를 봅니다. 처음에는 그것이 단지 기존 Code일 뿐입니다. 즉, 이 시스템이 원래 이렇게 구성되어 있다는 Local Evidence처럼 보입니다.

바로 이 지점에서 한 번의 편차가 더 장기적인 무언가로 바뀔 수 있습니다.

모든 잘못된 가정이 여기까지 가는 것은 아닙니다. Compiler, Type System, Test, Review, Architecture Rule, 혹은 주의 깊은 개발자가 즉시 멈출 수 있습니다.

하지만 멈추지 않으면, 이번 Action이 다음 Decision의 Context를 바꿉니다.

Broken Windows와 로컬 증거

Repository Code는 Coding Agent에게 특별한 의미를 가집니다.

Agent는 처음부터 모든 Code의 역사를 알지 못합니다.

어떤 Class가 4년 전 일정 압박 속에서 작성됐다는 사실을 자동으로 알지 못합니다. 이상한 접근 방식이 과거 Migration을 두 단계로 진행해야 했기 때문에 생겼다는 사실도 보이지 않습니다. Review에서 누군가 “이걸 Pattern으로 복사하지 마세요”라고 명시적으로 썼다는 사실도 반드시 알고 있는 것은 아닙니다.

처음에는 그저 Code를 봅니다.

그래서 일회성 Workaround가 Local Evidence가 될 수 있습니다.

일회성 Workaround
↓
Commit됨
↓
기존 Repository Code
↓
나중에 Pattern으로 해석됨
↓
다시 재생산됨
↓
점점 확립된 Pattern처럼 보임

이 현상은 AI 없이도 당연히 존재합니다. 개발자는 수십 년 동안 기존 Code를 복사해 왔습니다. Legacy System이 잘못된 방향으로 놀랄 만큼 일관되게 성장하는 이유도, 한 번의 로컬 Decision이 계속 Template로 쓰이기 때문인 경우가 많습니다.

Agent가 바꾸는 것은 주로 이 메커니즘의 속도와 규모입니다.

AI가 나쁜 아키텍처를 처음 가능하게 만드는 것은 아닙니다. 하지만 나쁜 아키텍처를 훨씬 더 빠르게 “일관되게” 만들 수는 있습니다.

좋은 소식은 같은 강화 효과가 반대 방향으로도 작동한다는 점입니다.

Codebase가 명확한 Boundary를 가지고, 일관된 Pattern을 사용하고, 좋은 Example을 유지하며, Architecture Rule을 기계적으로 검사한다면 Agent도 그 Local Evidence를 보게 됩니다.

그러면 다음처럼 작동합니다.

좋은 Pattern
↓
기존 Repository Code
↓
Local Evidence
↓
재현
↓
더 높은 일관성

따라서 Coding Agent는 본질적으로 나쁜 아키텍처를 증폭하는 것이 아닙니다. Repository, 문서, Test, Rule이 Local Evidence로 제공하는 신호를 먼저 증폭합니다.

그래서 점점 더 중요한 아키텍처 질문은 이것입니다.

우리는 Agent에게 어떤 신호를 주고 있는가?

Hallucination, 오해, Drift는 같은 것이 아닙니다

이 시점에서는 서로 관련은 있지만 다른 세 가지 개념을 구분하는 것이 좋습니다.

이 글에서 말하는 Hallucination은 잘못되었거나 근거가 부족한 진술 또는 가정입니다. 예를 들어 모델이 실제로 존재하지 않는 API가 있다고 주장하는 경우입니다.

**오해(Misinterpretation)**는 정보가 존재하지만 잘못 가중되거나 잘못 결합되는 경우입니다. 문서는 존재하지만 Agent가 Version 18의 Rule을 Version 21에 적용하거나, Legacy Workaround를 현재의 Architecture Rule로 받아들이는 식입니다.

Drift는 여러 단계를 거치며 해결 경로나 결과 아키텍처가 원래 의도한 방향에서 점점 멀어지는 과정을 뜻합니다.

Hallucination은 Drift를 일으킬 수 있습니다.

하지만 반드시 그렇지는 않습니다.

Hallucination
↓
Compiler Error
↓
수정

이 경우에는 의미 있는 Drift가 없습니다.

반대로 전형적인 Hallucination 없이도 Drift는 생길 수 있습니다.

로컬 Decision 하나는 그 자체로 정당할 수 있습니다. 그런데 나중에 여러 번 복제되며 Codebase 구조를 바꿉니다. 다른 변경이 계속 그것을 따릅니다. 누구도 틀린 사실을 지어낸 적은 없지만 Exception이 Convention이 됩니다.

그래서 Drift는 단일 모델 오류라기보다 Feedback Mechanism에 가깝습니다.

작은 편차가 어떻게 Drift가 될 수 있는가

단순화하면 다음과 같은 흐름이 가능합니다.

편차
↓
수용됨
↓
Codebase의 일부가 됨
↓
미래의 Context가 됨
↓
다시 재생산됨
↓
새로운 로컬 관례

핵심은 Feedback입니다.

Agent는 Context를 바탕으로 Output만 만드는 것이 아닙니다. Action을 통해 이후 Context가 다시 읽어 올 바로 그 환경을 바꿉니다.

Agent Decision
      ↓
Repository State
      ↓
Context
      ↓
Agent Decision

이것은 신비로운 “AI Drift”가 아닙니다. Decision과, 그 Decision에 의해 다시 형성되는 Environment 사이의 Feedback Loop입니다.

그래서 초기 편차가 특히 중요합니다. Dependency 하나가 추가됐을 때는 별문제 없어 보일 수 있습니다. 하지만 이후 열 번의 변경이 그것을 선례로 삼으면 새로운 구조가 될 수 있습니다.

5번 글은 결과의 Variance가 우선 서로 다른 Plausible한 해결 경로를 뜻한다는 점을 보여 줬습니다. 그것만으로는 아직 Drift가 아닙니다. 하지만 Agent가 Plausible한 잘못된 가정 위에서 계속 작업하고 거기서 다음 결정을 이끌어 내면, 편차는 더 긴 Action Chain을 거치며 서로 강화될 수 있습니다. 이 연쇄가 길어지고 자율적일수록 명확한 Boundary, 검증 가능한 중간 결과, 그리고 Feedback이 더 중요해집니다.

안전이 중요한 질문에는 Plausibility 이상이 필요합니다

일반적인 UI Refactoring에서 잘못된 가정은 성가십니다.

하지만 Safety-Critical한 Decision에서 “그럴듯해 보인다”는 것은 근본적으로 충분하지 않습니다.

구체적인 Security Question에 대한 지식이 부족한 Agent도 반드시 무작정 답할 필요는 없습니다. 잘 설계된 Agent System은 추가 문서를 불러오고, 내부 Policy를 검색하고, Tool을 사용하고, 구체적인 Fact를 검증하고, 추가 질문을 하거나, Evidence가 부족할 때 행동을 거부하고 사람에게 Escalate할 수 있습니다.

다만 결정적인 표현은 잘 설계된 Agent System은 그렇게 할 수 있다는 것입니다.

이것들은 전체 System, Tooling, Training Objective, Guardrail의 속성입니다. 강력한 LLM 하나를 썼다고 자동으로 따라오는 성질은 아닙니다.

Abstention조차 간단하지 않습니다. 시스템은 정보를 찾는 것뿐 아니라, 현재 Evidence가 신뢰할 만한 답변에 충분하지 않은 순간을 인식해야 합니다.

그래서 High-Stakes Domain에서는 특히 다음 원칙이 중요합니다.

Safety-Critical Decision에서 언어적 Plausibility는 결코 유일한 품질 증거가 되어서는 안 됩니다.

Evidence, 기술적 Check, 그리고 필요하다면 자격 있는 인간의 판단이 필요합니다.

Generation과 Verification은 서로 다른 작업입니다

Coding Agent는 추가 Generation의 비용을 크게 낮춥니다. 구현 변형을 하나 더 만들고, Test를 하나 더 추가하고, 가설을 하나 더 세우는 일은 오늘날 수작업보다 훨씬 적은 비용으로 가능한 경우가 많습니다.

그 결과 업무의 초점이 일부 이동합니다.

질문은 더 이상 오직 이것만이 아닙니다.

어떻게 해결책을 생성할 것인가?

점점 더 중요한 질문은 다음과 같습니다.

이 해결책이 받아들일 만하다는 것을 어떻게 알 수 있는가?

Compiler는 한 종류의 속성을 검증합니다. Type System은 다른 종류를 검증합니다. Test는 실제로 Specification되고 구현된 것만 검사합니다. Architecture Test는 Dependency Rule을 강제할 수 있습니다. Security Scanner는 알려진 특정 문제 유형을 찾을 수 있습니다. Review는 추가적인 도메인 지식을 가져옵니다.

이 도구들 가운데 어느 하나도 혼자서 Truth Machine은 아닙니다.

하지만 함께 사용하면, 그럴듯하면서 동시에 틀린 해결책의 공간을 상당히 줄일 수 있습니다.

Generation의 비용은 낮아질 수 있지만 Verification의 중요성은 오히려 커질 수 있습니다.

이 관계는 시리즈 후반에서 더 자세히 다룰 것입니다. 여기서는 한 가지 관찰이면 충분합니다. 시스템이 매우 빠르게 많은 Plausible Solution을 만들 수 있다면, 그중 무엇이 맞는지 구분하는 능력은 덜 중요해지는 것이 아닙니다.

더 중요해집니다.

Plausibility만으로는 충분하지 않습니다

Hallucination은 초기 LLM System의 가장 눈에 띄는 약점 중 하나였습니다. 하지만 2023년 이후의 발전을 따라온 사람이라면, 그 실무적 의미가 얼마나 크게 달라졌는지도 인정해야 합니다.

모델의 Factuality는 더 좋아졌습니다. Abstention은 더 명시적으로 학습됩니다. Context 활용은 개선됐습니다. Search와 Retrieval이 최신 정보를 제공합니다. Coding Agent는 Compiler, Type System, Test를 외부 Feedback Channel로 사용할 수 있습니다. 현재 System Card들은 각각의 이전 세대와 비교해 추가적인 Factuality 향상을 계속 보여 줍니다.

이 발전에 감탄하면서도 핵심 문제를 축소할 필요는 없습니다. 모델은 많은 것을 알고도 결정적인 사실 하나를 놓칠 수 있습니다. 답변은 아주 잘 쓰였지만 약한 Evidence 위에 놓일 수 있습니다. 로컬하게 그럴듯한 Agent Decision이 Repository를 바꾸고, 다음 Decision의 Evidence가 되며, 개별적으로 받아들여진 편차를 장기적인 Drift로 바꿀 수 있습니다.

Plausibility는 Truth의 기준이 아닙니다.

5번 글은 Agent의 해결 경로가 Deterministic하지 않다는 점을 보여 줬습니다.

6번 글은 여기에 다음을 추가합니다.

Plausible한 해결 경로도 잘못된 가정 위에 놓일 수 있습니다.

해답은 Agent의 모든 Decision을 미리 지정하는 것이 아닙니다. 그렇게 한다면 Agent를 쓸 이유가 없습니다.

대신 우리는 어떤 해결책이 애초에 받아들일 수 있는지, 어떤 속성은 절대 양보할 수 없는지, 그리고 어떤 Signal이 잘못된 경로를 초기에 드러내는지를 더 명확히 정의해야 합니다.

다음 글은 바로 그 지점에서 시작합니다.

첫 번째 Boundary는 Requirements입니다.

---

출처와 해설

OpenAI – Why Language Models Hallucinate, 2025. Hallucination의 통계적 원인과 Abstention보다 추측을 유도할 수 있는 Evaluation Mechanism의 영향을 분석합니다. 지식의 공백이 Output에서 자동으로 불확실성으로 나타나지 않는 이유를 설명하는 데 특히 중요합니다. Why Language Models Hallucinate – OpenAI

Li et al. – HaluEval, EMNLP 2023. Hallucinated Content의 생성과 탐지를 조사합니다. 본문의 약 19.5%는 Benchmark 내 특정 ChatGPT 답변 분석에 해당하며 제품 전반의 일반적인 Hallucination Rate가 아닙니다. HaluEval – ACL Anthology

Min et al. – FActScore, EMNLP 2023. 긴 답변을 Atomic Fact로 분해하고 신뢰할 수 있는 지식 출처가 뒷받침하는 비율을 측정합니다. ChatGPT의 58%는 생성된 인물 전기에 대한 사람의 Evaluation에서 나온 수치입니다. FActScore – ACL Anthology

Lin, Hilton, Evans – TruthfulQA. 널리 퍼진 인간의 오해가 오답을 유도할 수 있는 질문을 의도적으로 다룹니다. 역사적 결과는 초기 Truthfulness 문제의 맥락으로는 유용하지만 현대 모델과 직접 비교하는 지표는 아닙니다. TruthfulQA – OpenAI

Wei et al. – Long-form factuality in large language models / LongFact & SAFE, 2024. LongFact는 Open-ended Long-form Answer의 Factuality를 측정하고, SAFE는 답변을 사실 단위로 나눈 뒤 Search의 도움으로 검증합니다. Generation과 외부 Verification의 분리에 특히 관련됩니다. Long-form factuality – Google DeepMind

OpenAI – GPT-5 System Card, 2025. 본문의 LongFact, FActScore, SimpleQA 수치는 이 System Card의 특정 Evaluation에서 가져왔습니다. Browsing 유무가 다른 Setting과 자체 Grading 방식을 사용하므로 일반적인 Hallucination Rate로 해석해서는 안 됩니다. GPT-5 System Card

OpenAI – GPT-5.6 August Update, 2026. Factuality 중심 Production Prompt, 사용자가 신고한 과거 오류, High-Stakes Question 등 의도적으로 어려운 Prompt Set의 Evaluation입니다. 이 값은 평균적인 Production Error Rate가 아닙니다. GPT-5.6 August Update

Anthropic – Claude Opus 4.8 System Card, 2026. 네 가지 Closed-book Benchmark에서 Correct, Incorrect, Abstention 행동을 평가합니다. Opus 4.8은 비교한 여섯 모델 가운데 네 Benchmark 모두에서 가장 낮은 Incorrect Rate를 보였고, 상당 부분은 불확실할 때 더 자주 Abstain한 데서 나옵니다. Net Score는 Opus 4.7과 통계적으로 유의한 차이가 없습니다. Claude Opus 4.8 System Card, 6.3.3.1절

Kadavath et al. – Language Models (Mostly) Know What They Know, 2022. 언어 모델의 Self-evaluation과 Calibration을 조사합니다. 모델이 자기 답변의 정확성 확률에 관한 정보를 가질 수 있지만 그 능력은 Task Format에 좌우되고 완벽히 Generalize되지 않음을 보여 줍니다. Anthropic Research – Language Models (Mostly) Know What They Know

Liu et al. – MetaFaith, EMNLP 2025. 자연어로 표현한 불확실성이 실제 모델 불확실성을 신뢰성 있게 반영하는지 조사하고, 대상 모델에서 여전히 상당한 Calibration 문제를 기록합니다. MetaFaith – ACL Anthology

Feng et al. – Don’t Hallucinate, Abstain, ACL 2024. 지식 공백과, 모델이 지식이 없을 때 답을 지어내는 대신 보류하도록 만드는 방법을 명시적으로 다룹니다. Don’t Hallucinate, Abstain – ACL Anthology