STEP 2 - LLM의 한계, Hallucination과 Knowledge Cutoff

LLM은 왜 한계가 있는가 - Hallucination과 Knowledge Cutoff

요즘 사내 업무에도 ChatGPT 같은 LLM을 붙여보려는 시도가 많습니다. 그런데 막상 실제 서비스에 적용하려고 하면 두 가지 문제에 바로 부딪힙니다. 그럴듯하지만 틀린 답을 하거나, 최신 정보를 아예 모르는 경우입니다. RAG를 이해하기 전에, 먼저 왜 이런 한계가 생기는지부터 정리해봅니다.

1. LLM은 어떻게 답을 만드는가

LLM(Large Language Model)은 질문에 대한 정답을 "검색"해서 가져오는 구조가 아닙니다. 학습된 데이터를 바탕으로 다음에 올 단어를 확률적으로 예측해서 문장을 이어나가는 방식으로 동작합니다.
입력: "대한민국의 수도는"
모델 내부: "서울"이 올 확률 92%, "부산"이 올 확률 3%, ...
출력: "대한민국의 수도는 서울입니다."

이 구조가 핵심입니다. 모델은 "사실을 검증"하는 게 아니라 "가장 그럴듯한 다음 단어"를 고를 뿐입니다. 학습 데이터에 충분히 반복된 내용이면 이 방식이 실제 사실과 잘 맞아떨어지지만, 그렇지 않은 경우 문제가 생깁니다.

2. Hallucination이란

Hallucination(환각)은 모델이 존재하지 않는 정보를 마치 사실인 것처럼 자신 있게 생성하는 현상입니다. 확률적으로 그럴듯한 문장을 만들어내는 것뿐이라, 실제로 존재하지 않는 함수명, 논문, 법 조항도 자연스럽게 만들어냅니다.
질문: "Spring Data JPA의 findByIdWithLock() 메서드 사용법 알려줘"
답변: "findByIdWithLock()은 비관적 락을 적용하여 조회하는 메서드로,
@Lock 어노테이션과 함께 사용하면..."
→ 실제로는 존재하지 않는 메서드지만, 문법적으로도 맥락상으로도
실제 있을 법하게 답변을 생성합니다.

원인은 명확합니다. 모델 내부에는 "이 정보가 사실인지 검증하는 단계"가 없습니다. 학습 데이터 분포상 그럴듯하면 그대로 출력됩니다. 질문이 구체적이고 지엽적인 주제일수록, 학습 데이터에 관련 내용이 적을수록 Hallucination 발생 확률은 올라갑니다.

3. Knowledge Cutoff란

LLM은 특정 시점까지 수집된 데이터로 학습됩니다. 그 이후에 벌어진 일, 새로 나온 라이브러리 버전, 최근 정책 변경 같은 정보는 모델이 원천적으로 알 수 없습니다. 이걸 Knowledge Cutoff(지식 컷오프)라고 부릅니다.

상황	결과
학습 시점 이전 정보 질문	정확하게 답변 가능
학습 시점 이후 정보 질문	모른다고 답하거나, Hallucination 발생
특정 회사 내부 문서	애초에 학습 데이터에 없어서 답변 불가

특히 마지막 케이스가 실무에서 가장 크게 부딪히는 지점입니다. 사내 위키, 내부 API 문서, 최신 정책처럼 애초에 공개된 적 없는 데이터는 아무리 큰 모델을 써도 알 수가 없습니다.

4. Fine-tuning으로는 왜 부족한가

"그럼 우리 회사 데이터로 다시 학습시키면 되지 않나"라는 생각이 자연스럽게 듭니다. Fine-tuning(파인튜닝)이 바로 그 방법인데, 실무에 적용하기엔 몇 가지 현실적인 벽이 있습니다.

• 학습 비용과 시간이 크고, 데이터가 바뀔 때마다 재학습이 필요합니다.
• 문서가 하루 단위로 갱신되는 서비스에는 사실상 적용이 어렵습니다.
• 잘못 학습되면 기존 성능이 떨어지는 Catastrophic Forgetting 위험도 있습니다.

즉, "모델 자체에 지식을 주입하는 방식"은 최신성을 유지하기가 구조적으로 어렵습니다.

5. 정리

• LLM은 사실 검증 없이 확률적으로 가장 그럴듯한 답을 생성하기 때문에 Hallucination이 발생합니다.
• 학습 시점 이후의 정보나 비공개 데이터는 Knowledge Cutoff로 인해 모델이 원천적으로 알 수 없습니다.
• Fine-tuning은 이 문제를 부분적으로 완화할 수는 있지만, 비용과 최신성 유지 측면에서 실무 적용에 한계가 있습니다.

결국 필요한 건 모델 자체를 바꾸는 게 아니라, 질문에 답하기 전에 관련된 최신 문서를 찾아서 모델에게 함께 넘겨주는 방식입니다. 다음 글에서는 이 아이디어를 구현한 RAG(Retrieval-Augmented Generation)의 개념과 전체 아키텍처를 정리해보겠습니다.