6부 · 한계와 그 이유
← 5부 추론(생성) · 목차 · 다음: 7부 원리에서 실전으로 →
지금까지 쌓은 원리—다음 토큰 예측, 파라미터에 분산 저장된 지식, 확률 분포에서의 샘플링, 유한한 컨텍스트—로부터 LLM의 한계가 왜 생기는지 자연스럽게 끌어낼 수 있습니다. 이 부의 한 줄 요약입니다.
LLM의 약점 대부분은 버그가 아니라, "그럴듯한 다음 토큰을 예측한다"는 설계에서 따라 나오는 자연스러운 결과다.
6.1 왜 환각하는가
환각(hallucination) 은 모델이 그럴듯하지만 사실과 다른 내용을 자신 있게 내놓는 현상입니다. 가짜 인용, 없는 논문, 틀린 날짜 같은 것들입니다. 왜 이런 일이 불가피하게 생길까요? 원리에서 끌어내 보면 이유가 겹겹입니다.
flowchart TB
A["다음 토큰 예측 설계<br/>'그럴듯함'을 최적화<br/>(진위 판별 장치 없음)"] --> H["환각"]
B["지식이 파라미터에 분산<br/>조회가 아니라 재구성<br/>(4부)"] --> H
C["드문(롱테일) 사실은<br/>흐릿하게 저장"] --> H
D["평가·훈련이 '모름'보다<br/>자신 있는 추측을 보상"] --> H
classDef cause fill:#d8b4f8,stroke:#8b5cf6,color:#000
classDef bad fill:#ffcdd2,stroke:#c62828,color:#000
class A,B,C,D cause
class H bad
첫째, 설계 자체. 모델은 "참인 토큰"이 아니라 "그럴듯한 토큰"을 예측하도록 만들어졌습니다(1·4부). 진위를 가리는 내부 장치가 없으니, 그럴듯하면 틀려도 내놓습니다.
둘째, 재구성 방식. 지식이 데이터베이스에 조회되는 게 아니라 파라미터에서 재구성됩니다(4부). 근거가 부족한 빈자리를 모델은 "가장 그럴듯한 것"으로 메웁니다.
셋째, 롱테일. 데이터에 드물게 등장한 사실은 흐릿하게 저장되어, 또렷이 답하지 못하고 지어내기 쉽습니다.
넷째, 동기 구조. 2025년 연구들이 강조한 새 관점입니다. 모델을 평가하는 방식이 "모르겠다"보다 자신 있는 추측을 보상하는 경향이 있어, 모델은 마치 객관식 시험에서 모르면 찍는 학생처럼 "일단 그럴듯하게 답하는" 쪽으로 학습됩니다. 즉 환각은 데이터 품질만의 문제가 아니라, 훈련·평가의 인센티브 문제이기도 합니다.
비유 — 빈칸을 그냥 비워 두지 못하는 학생
시험에서 모르는 문제를 비우면 0점, 찍으면 가끔 맞는 규칙이라면, 학생은 늘 찍습니다. 모델도 "모른다"고 말하기보다 그럴듯한 답을 채우도록 길들여집니다.
이 비유가 깨지는 곳: 학생은 자기가 찍는다는 걸 알지만, 모델은 자기 답이 추측인지 근거 있는지 구분하는 감각이 없습니다. 그래서 똑같이 자신 있게 참과 거짓을 말합니다.
흔한 오해 깨기
흔히들 "환각은 고치면 없어질 버그"라고 생각하지만, 실제로는 현재 설계에서 완전히 없애기는 어려운 구조적 성질에 가깝습니다. 검색·도구 연결(7부)이나 평가 방식 개선으로 줄일 수는 있어도, "그럴듯함을 예측한다"는 본질이 남는 한 0으로 만들기는 어렵다는 게 다수 견해입니다(다만 활발히 연구 중인 주제입니다).
6.2 왜 최신 정보를 모르거나 틀리는가
이건 4부에서 이미 뿌리를 봤습니다. 모델의 지식은 학습 데이터의 시점에 묶입니다(지식 컷오프). 그 이후의 사건—새 가격, 바뀐 직책, 최근 뉴스—은 학습에 들어 있지 않습니다.
문제는 모델이 "나는 그 시점 이후를 모른다"고 스스로 명확히 선을 긋지 못한다는 점입니다. 과거에 맞던 정보를 현재형으로 자신 있게 말하거나(예: 바뀐 직책을 옛 인물로 답함), 컷오프 이후 일을 그럴듯하게 지어낼 수 있습니다(6.1의 환각과 겹침).
이 한계를 메우는 표준 방법이 검색·도구 연결입니다. 모델 바깥에서 최신 정보를 가져와 컨텍스트에 넣어 주면, 모델은 그걸 보고 답합니다. 7부에서 다룹니다.
6.3 왜 산수와 정확한 사실에 약한가
강력한 모델이 의외로 간단한 곱셈을 틀리거나, "딸기에 r이 몇 개냐"를 못 맞히는 걸 보면 의아합니다. 이것도 원리에서 설명됩니다.
산수가 약한 이유. 모델은 계산을 수행하는 게 아니라, "이 수식 다음에 올 그럴듯한 토큰"을 예측합니다(5부). 자주 본 식("2+2=4")은 패턴으로 외워 맞히지만, 처음 보는 큰 수의 곱셈은 한 자리씩 정확히 계산하는 절차가 없어 그럴듯한 숫자를 내놓습니다. 게다가 한 토큰씩 앞으로만 가는 자기회귀라(5부), 사람처럼 종이에 받아 계산하고 검산하는 식의 되짚기가 기본 동작에 없습니다.
글자 세기가 약한 이유. 2부에서 본 토큰화 때문입니다. 모델은 "strawberry"를 글자 s-t-r-a-w-...로 보는 게 아니라 몇 개의 토큰 덩어리로 봅니다. 덩어리 안의 글자 개수는 모델 입장에서 직접 보이지 않으니, 세는 게 어렵습니다.
flowchart LR
W["'strawberry'"] --> T["토큰 덩어리로 인식<br/>예: 'straw' + 'berry'"]
T --> Q["'r이 몇 개?'<br/>덩어리 속 글자는<br/>직접 안 보임"]
Q --> WR["그럴듯한 숫자 추측<br/>(자주 틀림)"]
classDef in fill:#fff3b0,stroke:#e0a800,color:#000
classDef proc fill:#a8e6e2,stroke:#2ba89e,color:#000
classDef bad fill:#ffcdd2,stroke:#c62828,color:#000
class W in
class T,Q proc
class WR bad
흔한 오해 깨기
흔히들 "AI는 컴퓨터니까 계산은 정확하겠지"라고 생각하지만, 실제로는 LLM은 계산기가 아니라 언어 패턴 예측기입니다. 정확한 계산이 필요하면 모델에 계산 도구를 붙여 주는 게 정석입니다(7부). 도구를 쥐여 주면 약점이 상당히 메워집니다.
6.4 "중간 소실" — 긴 맥락의 어려움
5부에서 컨텍스트 창이 유한하다고 했습니다. 그런데 창 안에 정보가 들어 있어도 문제가 생길 수 있습니다. 바로 중간 소실(lost in the middle) 입니다.
연구에 따르면, 긴 입력에서 모델은 맨 앞과 맨 끝의 정보를 잘 활용하고, 중간에 있는 정보는 놓치는 경향이 있습니다. 정확도를 위치에 따라 그려 보면 양 끝이 높고 가운데가 낮은 U자 모양이 나타납니다. 답이 든 문서를 앞에서 중간으로 옮기기만 해도 정확도가 크게 떨어진다는 관찰이 보고됐습니다.
flowchart LR
S["맥락 시작<br/>주목도 높음 ★★★"] --> M["중간<br/>주목도 낮음 ★"]
M --> E["맥락 끝<br/>주목도 높음 ★★★"]
classDef good fill:#b9f6ca,stroke:#2e9e5b,color:#000
classDef bad fill:#ffcdd2,stroke:#c62828,color:#000
class S,E good
class M bad
흥미롭게도 이는 사람의 기억 편향(목록의 처음과 끝을 잘 기억하는 초두·최신 효과)과 닮았지만, 모델에선 인지가 아니라 위치 처리 방식 등 구조적 이유에서 옵니다. 또 단순히 맥락을 더 많이 넣는다고 해결되지 않습니다 — 길어질수록 잡음이 늘고, 길이 자체가 성능을 떨어뜨린다는 연구도 있습니다.
비유 — 긴 회의록의 가운데 페이지
두꺼운 회의록을 훑을 때 첫 장과 마지막 장은 눈에 들지만, 가운데 어딘가 끼인 핵심 한 줄은 놓치기 쉽습니다.
이 비유가 깨지는 곳: 사람은 마음먹고 가운데를 정독할 수 있지만, 모델의 위치 편향은 그렇게 의지로 끄기 어렵습니다. 그래서 실전에선 중요한 정보를 앞이나 끝에 배치하는 식으로 편향을 거슬러 싸우기보다 활용합니다(7부).
6.5 편향과 안전 문제의 뿌리
4부에서 봤듯, 모델은 학습 데이터를 거울처럼 비춥니다. 데이터에 든 고정관념·차별·오류·불균형이 모델에 스며들고 때로는 증폭됩니다. 이것이 편향(bias) 문제의 뿌리입니다.
핵심은, 이것이 모델의 "악의"나 "의견"이 아니라는 점입니다. 모델은 무엇이 공정하고 참인지 판별하지 못한 채, 데이터에서 본 연관을 통계적으로 재현할 뿐입니다. 사후학습(4부의 RLHF류)으로 일부 완화하지만, 완전히 없애기는 어렵고, "무엇을 편향으로 볼 것인가" 자체가 사람마다 다른 가치 판단을 포함합니다.
안전 문제(유해하거나 위험한 출력)도 비슷한 뿌리를 갖습니다. 그럴듯한 텍스트를 생성하는 능력은 유익한 글뿐 아니라 해로운 글도 그럴듯하게 만들 수 있기 때문입니다. 그래서 사후학습과 별도의 안전 장치로 이런 출력을 줄이려 하지만, 이 역시 완벽하지 않은 진행 중인 과제입니다.
흔한 오해 깨기
흔히들 "AI가 편향된 건 누군가 그렇게 프로그래밍해서"라고 생각하지만, 실제로는 대부분 명시적 프로그래밍이 아니라 데이터를 반영하는 학습 방식 자체에서 비롯됩니다. 그래서 "코드 한 줄 고치기"로 해결되지 않고, 데이터·학습·평가 전반의 문제로 다뤄집니다.
6.6 모델이 "추론"하는가 — 균형 잡힌 논의
마지막으로, 가장 뜨거운 질문입니다. 요즘 모델은 답하기 전에 단계를 밟아 "생각하는" 듯한 과정(사고 사슬, chain-of-thought)을 보여 주고, 이런 식으로 수학·코딩 문제를 더 잘 풉니다. 이걸 진짜 추론(reasoning) 이라 부를 수 있을까요?
이건 합의되지 않은, 활발한 논쟁입니다. 양쪽 입장을 공정하게 소개합니다.
| 회의적 입장 | 긍정적 입장 |
|---|---|
| 단계를 밟는 듯 보여도 결국 "그럴듯한 다음 토큰 예측"이다. | 단계적 사고가 실제로 어려운 문제의 정답률을 높인다(실용적 효과는 분명). |
| 통제된 퍼즐(하노이 탑 등)에서 복잡도가 높아지면 정확도가 붕괴하고, 정답 알고리즘을 줘도 못 따라간다 — 진짜 논리 실행이 아니라 패턴 예측이라는 증거. | 그 실험은 출력 길이 제한 등 설계 결함 탓일 수 있고, 추론 엔진 자체가 그렇게 취약하진 않다(반박 연구 존재). |
| 새롭고 분포 밖(out-of-distribution) 문제에 약하다. | 중간 난이도에선 단계적 사고가 분명한 이점을 준다. |
2025년 한 유명 연구("생각의 환상")는 통제된 퍼즐에서 모델이 일정 복잡도를 넘으면 정확도가 0으로 붕괴하고, 풀이 알고리즘을 명시적으로 줘도 같은 벽에 부딪힌다고 보고했습니다. 이를 두고 "진짜 추론이 아니다"라는 해석이 나왔지만, 곧 "그건 실험 설계의 한계(예: 출력 토큰 제한)이지 추론 능력의 한계가 아니다"라는 반박이 이어졌습니다. 양측 모두 일리가 있고, '추론하느냐'는 아직 열린 문제입니다.
균형 잡기. 한 가지는 분명합니다 — 사고 사슬은 많은 실용 과제에서 효과가 있습니다. 그것을 "진짜 사고"라 부를지는 철학적·정의적 문제이며, 이 안내서는 어느 한쪽으로 단정하지 않습니다. 다만 "단계를 보여 준다 = 사람처럼 논리를 실행한다"로 비약하지 않는 신중함을 권합니다. 보이는 단계가 실제 내부 처리를 충실히 반영한다는 보장도 없다는 점(사고 사슬의 충실성 문제)도 연구 중입니다.
흔한 오해 깨기
흔히들 "모델이 보여 주는 '생각 과정'이 그 답이 나온 진짜 이유다"라고 생각하지만, 실제로는 그 설명이 내부에서 실제로 일어난 계산과 얼마나 일치하는지는 불확실합니다. 그럴듯한 설명과 실제 근거가 다를 수 있습니다.
6부 요약
- LLM의 약점 대부분은 버그가 아니라 "그럴듯한 다음 토큰 예측"이라는 설계의 자연스러운 귀결입니다.
- 환각: 진위 판별 장치 없음 + 재구성 방식 + 롱테일 + 자신 있는 추측을 보상하는 평가. 줄일 수는 있어도 현재 설계에서 완전 제거는 어렵습니다.
- 최신 정보 약점: 지식 컷오프. 검색·도구로 메웁니다(7부).
- 산수·글자 세기 약점: 계산기가 아니라 패턴 예측기이고, 토큰화 때문에 글자 단위가 안 보입니다. 도구를 붙이면 메워집니다.
- 중간 소실: 긴 맥락에서 앞뒤는 잘 보고 가운데를 놓치는 U자 편향. 중요한 건 앞·끝에 둡니다.
- 편향·안전: 명시적 프로그래밍이 아니라 데이터를 반영하는 학습 방식에서 옵니다. 완화는 되나 완전 해결은 어렵습니다.
- "추론하는가": 합의되지 않은 활발한 논쟁. 사고 사슬은 실용적 효과가 있으나, 그것을 "진짜 사고"라 단정하지 않는 신중함이 필요합니다.
다음 부에서는 이 원리들이 실전 기법(프롬프트·맥락 제공·RAG·도구·에이전트)을 어떻게 설명하는지로 다리를 놓습니다. 한계를 알면, 그 한계를 메우는 기법이 왜 통하는지 보입니다.
← 5부 추론(생성) · 목차 · 다음: 7부 원리에서 실전으로 →
이 부에서 다룬 환각·편향·안전·자해 등과 무관하게, 만약 AI 안전이나 정신적 어려움 등 민감한 주제로 도움이 필요하다면 전문 기관이나 신뢰할 수 있는 사람과 상의하길 권합니다. 이 문단은 안내서의 기술적 설명과 별개의 일반적 안내입니다.