LLM 답변은 왜 틀릴 수 있는가

오늘의 질문

앞선 글들에서 LLM이 다음 token의 확률을 계산해 하나씩 골라 문장을 만든다는 것을 봤다. 그러다 보면 반드시 이런 경험을 하게 된다.

답변이 너무 자연스럽고 자신 있게 쓰여 있어서 믿었는데, 확인해보니 없는 내용이었다. 왜 이런 일이 생기고, 매번 어떻게 걸러내야 하나?

여기서 중요한 건 “틀렸다”는 사실 자체가 아니라 틀린 것이 안 보인다는 점이다. 답이 어설프면 의심하게 되지만, 유창하면 의심할 계기가 없다. 이 글은 왜 유창함과 정확함이 갈라지는지, 그리고 실무에서 이걸 어떤 절차로 걸러낼지를 다룬다.

먼저 답하기

한 문장으로 줄이면 이렇다.

모델은 “사실인 문장”을 만들도록 훈련된 게 아니라 “그럴듯한 다음 조각”을 이어붙이도록 훈련됐다. 유창함과 사실성은 대개 겹치지만 항상 겹치지는 않고, 어긋난 순간에도 문장은 여전히 유창하다.

이 현상에는 이름이 있다. **hallucination(환각)**이라고 부른다. LLM 기반 에이전트를 다룬 Xi 외의 서베이 논문(2023)은 이를 모델이 출처나 사실 정보와 상충하는 내용을 생성하는 현상으로 설명하며, 이것이 사실적으로 엄격함이 요구되는 작업에 LLM을 널리 사용할 수 없는 결정적 이유 중 하나라고 지적한다.

그러니 실무에서 필요한 건 “모델을 더 믿을 만하게 만드는 방법”이 아니라 틀린 문장을 잡아내는 절차를 어디에 둘 것인가에 대한 답이다. 아래에서 원인과 절차를 나눠서 본다.

주제에 맞는 핵심 설명

왜 틀리는가

원인은 하나가 아니다. 위 서베이 논문이 짚는 지점들을 정리하면, 최소한 네 갈래로 나뉜다.

첫째, 애초에 사실성을 목표로 학습된 게 아니다. 같은 논문은 언어 모델이 엄밀히 말해 입력을 이용해 다음 token을 예측하는 조건부 확률 모델로 기능한다고 서술한다. 확률이 높은 조각은 “학습 데이터에서 이런 맥락 뒤에 자주 등장했던 조각”이라는 뜻이지 “참인 조각”이라는 뜻이 아니다. 둘이 자주 일치하는 건 사람이 쓴 글이 대체로 사실을 담고 있기 때문일 뿐, 확률 계산 자체가 사실 여부를 재는 장치는 아니다.

둘째, 학습된 지식 자체가 낡거나 처음부터 틀렸을 수 있다. 이 논문은 모델이 학습 과정에서 획득한 지식이 시간이 지나 낡을 수도 있고, 애초에 잘못된 것일 수도 있다고 지적한다. 그리고 이걸 고치기 위해 다시 학습시키는 방식은 고품질 데이터와 상당한 시간, 계산 자원을 요구하며, 더 나쁘게는 파괴적 망각(catastrophic forgetting)으로 이어질 수 있다고 설명한다. 즉 “틀린 지식만 골라서 고치기”가 기술적으로 간단한 문제가 아니라는 뜻이다.

셋째, 알고 있는 것에 제대로 도달하지 못할 수 있다. 같은 논문은 도구 사용을 논하는 대목에서, LLM 기반 에이전트가 학습 데이터의 모든 조각을 기억할 능력은 없으며, 또한 맥락 프롬프트의 영향 때문에 올바른 지식으로 향하지 못하거나 아예 환각적 지식을 생성할 수도 있다고 서술한다. 여기서 눈여겨볼 부분은 “맥락 프롬프트의 영향”이다. 질문을 어떻게 쓰느냐가 답의 정확성에도 관여한다는 뜻이고, 앞선 글에서 다룬 prompt 이야기가 여기로 연결된다.

넷째, 왜 그렇게 답했는지 추적이 어렵다. 이 논문은 LLM 기반 에이전트의 의사결정 과정이 투명성이 부족해서, 의료나 금융처럼 위험이 큰 영역에서 신뢰하기 어렵게 만든다고 지적한다. 답이 틀렸을 때 어디서 어긋났는지 짚을 수 없다면, 같은 실수가 다음에도 반복되는 걸 막기 어렵다.

여기서 내 해석을 하나 덧붙인다. 위 네 가지는 성질이 다르다. 둘째와 셋째는 기술이 개선되면 줄어들 수 있는 문제다. 하지만 첫째는 구조에서 나온다. 다음 token의 확률을 계산하는 방식으로 문장을 만드는 한, “그럴듯함”을 최적화한 결과물이 나오는 것 자체는 바뀌지 않는다. 그래서 실무 대응의 무게중심을 “모델이 안 틀리게 만들기”가 아니라 “틀린 걸 잡아내기”에 두는 편이 안전하다고 본다. 이건 논문의 주장이 아니라 위 내용에서 내가 끌어낸 판단이다.

검증 절차

그러면 무엇을 어떻게 확인해야 하나. 핵심은 답변을 통째로 놓고 “맞나 틀리나”를 판단하지 않는 것이다. 한 답변 안에 성질이 전혀 다른 문장들이 섞여 있고, 각각 다르게 다뤄야 한다.

이 그림에서 가장 중요한 칸은 왼쪽이 아니라 가운데다. 답변을 문장으로 쪼갠 다음 세 갈래로 분류하고, 그중 사실 주장만 출처 대조로 넘긴다. 해석과 보류 문장은 검증 대상에서 빼고 “이건 해석”이라고 표시만 남긴다. 세 갈래를 섞어서 한꺼번에 판정하려 하면, 검증할 수 없는 문장에 시간을 쓰거나 검증해야 할 문장을 놓친다.

**grounding(근거 연결)**이라는 말도 여기서 나온다. 어떤 주장을 확인 가능한 외부 자료에 붙여두는 것을 뜻한다. 위 서베이 논문은 이 방향의 대응책으로 두 가지를 소개한다. 하나는 환각의 정도를 측정하는 지표를 만들어 개발자가 LLM 출력의 신뢰성을 평가할 기준으로 삼는 접근이고, 다른 하나는 모델이 외부 도구를 사용하게 해서 잘못된 지식을 피하도록 하는 접근이다. 특히 검색 기반 도구에 대해서는 외부 데이터베이스, 지식 그래프, 웹 페이지의 도움으로 접근 가능한 지식의 범위와 품질을 개선한다고 설명한다. 다만 이 논문은 곧바로 단서를 붙인다. 두 방법 모두 환각의 영향을 완화할 수 있지만, 더 효과적인 접근에 대한 추가 탐구가 여전히 필요하다는 것이다. 즉 “도구를 붙였으니 이제 안심”이라고 말할 단계는 아니다.

작은 연습: 한 답변을 세 갈래로 나눠보기

아래는 가상의 답변 하나를 문장 단위로 쪼개서 분류한 예시다. 실제 모델 출력을 그대로 가져온 게 아니라, 분류 감각을 보여주기 위해 만든 예시라는 점을 밝혀둔다.

가상의 답변: “이 라이브러리는 2019년에 처음 공개되었고, 비동기 처리를 지원합니다. 그래서 대규모 트래픽 환경에 적합합니다. 최근 버전에서는 성능이 크게 개선되었습니다.”

이 표에서 짚을 부분은 네 문장이 한 문장씩 다른 처리를 요구한다는 점이다. 그리고 셋째 문장처럼 앞의 사실 주장 두 개에 “그래서”로 이어붙여진 해석이 가장 위험하다. 앞이 사실이니 뒤도 사실처럼 읽히지만, 실제로는 검증 대상이 아니다.

실무에서 쓸 수 있는 확인 순서로 정리하면 이렇다.

1. 답변을 문장 단위로 끊는다. 한 문장에 주장이 두 개 들어 있으면 더 쪼갠다.
2. 각 문장을 사실 주장 / 해석 / 확인 필요로 분류한다. 이 단계가 가장 중요하고 가장 자주 생략된다.
3. 사실 주장만 출처와 대조한다. 이때 모델에게 “출처를 알려달라”고 되묻는 것으로 대체하지 않는다. 출처 자체도 그럴듯하게 만들어질 수 있는 문장이므로, 원문을 직접 열어 확인해야 근거 연결이 성립한다.
4. 날짜·수치·고유명사를 특히 의심한다. 이런 항목은 그럴듯한 형태를 갖추기 쉬운 반면 틀렸을 때 티가 나지 않는다.
5. 확인 못 한 것은 확인 못 했다고 표시해 남긴다. 지우지 말고 표시해두는 게 낫다. 나중에 누가 인용할 때 판단 근거가 된다.

자주 묻는 질문

모델에게 “확실해?“라고 다시 물어보면 검증이 되나요? 안 된다. 되묻는 것도 결국 다음 token 예측이므로, “네, 확실합니다”라는 답변 역시 그럴듯하게 생성될 수 있다. 앞서 인용한 서베이 논문이 지적하듯 의사결정 과정 자체가 투명하지 않아서, 모델이 제시하는 확신의 정도가 실제 정확성과 얼마나 대응하는지 보장할 수 없다. 검증은 모델 밖의 출처를 열어보는 방식으로만 성립한다.

출처를 함께 달아달라고 요청하면 되지 않나요? 출처를 요청하는 건 도움이 되지만 그것만으로 검증이 끝나지는 않는다. 출처 표기 자체도 생성된 문장이므로, 제목·저자·연도의 조합이 그럴듯하게 만들어질 수 있다. 실무 원칙은 하나다. 출처를 받았으면 그 출처를 직접 열어서, 인용된 내용이 실제로 그 문서에 있는지 확인한다. 링크가 열리는지 확인하는 것과 내용이 일치하는지 확인하는 것은 다른 일이다.

검색 기능이 붙은 도구를 쓰면 이 문제가 해결되나요? 줄어들지만 사라지지 않는다. 위 서베이 논문은 외부 도구 사용이 접근 가능한 지식의 범위와 품질을 개선한다고 설명하면서도, 이런 방법들이 환각의 영향을 완화할 수 있다고 표현하고 더 효과적인 접근에 대한 추가 연구가 필요하다고 명시한다. 실무적으로는 검색 결과를 요약하는 단계에서 여전히 왜곡이 생길 수 있으므로, 검색 기반 답변도 원문 대조 절차를 건너뛰면 안 된다.

어디까지 검증해야 하나요? 전부 다 확인하면 직접 쓰는 게 빠를 것 같은데요. 현실적인 기준은 틀렸을 때의 피해 크기로 정하는 것이다. 초안 작성, 아이디어 정리, 코드 스켈레톤처럼 다음 단계에서 자연히 걸러지는 작업은 가볍게 넘어갈 수 있다. 반면 외부에 공개되는 문서, 수치가 들어간 보고, 규정·계약 관련 판단처럼 틀린 문장이 그대로 굴러가는 작업은 위 절차를 생략하면 안 된다. 판단 기준을 “이 문장이 틀린 채로 다음 단계로 넘어가면 누가 언제 알아채는가”로 잡으면, 어디에 시간을 쓸지가 대체로 분명해진다.