[LLM 동작원리 1편] LLM은 어떻게 대답하는가: 다음 토큰 예측의 이해

Claude한테 코드 리뷰를 시키면 가끔 존재하지 않는 메서드를 자신있게 추천합니다. "이 라이브러리의 optimizeQuery() 메서드를 사용하세요"라고 하길래 찾아봤더니 그런 메서드는 없었습니다. 분명히 확신에 찬 말투였는데 말이죠.

처음엔 그냥 AI가 틀린 거라고 넘겼습니다. 그런데 이런 일이 반복되면서 궁금해졌습니다. 왜 모르면 모른다고 하지 않고, 그럴듯한 거짓말을 할까? 이걸 이해하려면 LLM이 대답을 만들어내는 방식을 알아야 합니다.

저는 AI를 만드는 사람이 아니라 쓰는 사람입니다. 수학 공식이나 모델 구현 방법은 다루지 않습니다. 대신 "LLM이 왜 이렇게 동작하는지"를 이해해서 더 잘 활용하는 데 초점을 맞추려고 합니다.

1. 토큰 - LLM이 글을 읽는 단위

우리는 글을 글자 단위로 읽지만, LLM은 토큰이라는 단위로 읽습니다. 토큰은 단어보다 작을 수도 있고, 단어 그 자체일 수도 있습니다.

예를 들어 영어 "programming"은 대략 1~2개 토큰으로 처리됩니다. 그런데 한글 "프로그래밍"은 3~4개 토큰이 필요합니다. 한글이 영어보다 토큰을 더 많이 소모한다는 거죠.

이게 왜 중요하냐면, LLM에는 컨텍스트 윈도우라는 게 있습니다. 한 번에 처리할 수 있는 토큰 수의 상한선인데, 같은 내용이라도 한글로 작성하면 영어보다 컨텍스트를 더 많이 차지합니다. Claude Code를 쓰다 보면 대화가 길어질수록 성능이 떨어지는 느낌을 받는데, 이게 바로 컨텍스트 윈도우가 채워지기 때문입니다.

실무에서 체감되는 부분을 하나 더 이야기하면, CLAUDE.md나 프롬프트를 작성할 때 불필요하게 긴 설명을 넣으면 그만큼 실제 작업에 쓸 수 있는 공간이 줄어듭니다. 토큰이라는 개념을 알면 "왜 프롬프트를 간결하게 써야 하는지"가 납득이 됩니다.

 

2. 다음 토큰 예측 - LLM의 본질

LLM의 동작 원리를 한 문장으로 요약하면 이렇습니다. 앞에 나온 텍스트를 보고, 다음에 올 가능성이 가장 높은 토큰을 하나 고르는 것. 이걸 반복해서 문장을 만들어갑니다.

"서울의 수도는"이라는 입력을 받으면, 학습 데이터에서 이 패턴 뒤에 가장 자주 나온 토큰을 예측합니다. 당연히 높은 확률로 나오는 건 의미 없는 결과겠죠. 잘못된 예시지만 원리를 설명하기 위해 들었습니다. "한국의 수도는"이라고 하면 "서울"이 높은 확률로 나오겠죠.

중요한 건, LLM은 "서울이 한국의 수도다"라는 사실을 이해하고 대답하는 게 아니라는 겁니다. "한국의 수도는" 다음에 "서울"이 올 확률이 가장 높다는 통계적 패턴을 따르는 겁니다.

이 차이가 왜 중요하냐면, LLM이 "이해"하는 게 아니라 "예측"하는 거라는 걸 알면 많은 현상이 설명됩니다.

 

3. 할루시네이션 - 자신있는 거짓말의 원리

글 맨 처음에 이야기했던 존재하지 않는 메서드 추천, 이게 바로 할루시네이션입니다. LLM 입장에서 보면 이건 버그가 아니라 정상 동작입니다.

LLM은 "이 맥락 다음에 올 그럴듯한 토큰"을 생성할 뿐입니다. optimizeQuery()라는 메서드가 실제로 존재하는지 확인할 방법이 없습니다. 그냥 "이 라이브러리에 대한 설명 맥락에서, 다음에 올 법한 메서드 이름"을 생성한 겁니다.

비유하자면 이렇습니다. 시험에서 모르는 문제가 나왔을 때, 빈칸으로 두는 게 아니라 그럴듯하게 적어내는 학생과 비슷합니다. 본인은 모른다는 자각이 없이, 패턴에 맞는 답을 만들어내는 거죠.

이걸 알면 활용 방식이 달라집니다.

• AI가 추천하는 라이브러리, 메서드, 설정값은 반드시 검증해야 합니다.
• "확실해?"라고 물어봐도 소용없습니다. LLM은 자기가 모른다는 걸 모릅니다.
• 대신 코드를 직접 실행하게 하거나, 검색 도구를 연결하면 할루시네이션을 줄일 수 있습니다.

이전에 쓴 하네스 엔지니어링 글에서 "에이전트가 코드 작성 후 '됐네'라고 판단하는 걸 막고, 실제로 테스트를 돌려보게 강제했다"는 LangChain 사례를 소개한 적이 있는데, 이게 바로 할루시네이션에 대한 대응입니다. LLM이 "그럴듯하게 생성"하는 존재라는 걸 전제하고, 검증 단계를 하네스에 넣은 거죠.

 

4. Temperature - 창의성과 정확성 사이의 조절기

같은 질문을 해도 매번 다른 답이 나온 경험 있으시죠? 이건 Temperature라는 설정 때문입니다.

다음 토큰을 고를 때, 가장 확률이 높은 토큰만 무조건 선택하면 매번 똑같은 답이 나옵니다. 여기에 약간의 무작위성을 넣어서 다양한 답이 나오게 하는 게 Temperature입니다.

• Temperature가 낮으면(0에 가까우면): 가장 확률 높은 토큰을 선택 → 일관되고 예측 가능한 답
• Temperature가 높으면(1에 가까우면): 확률이 낮은 토큰도 선택될 수 있음 → 다양하고 창의적인 답

Top-p라는 것도 비슷한 역할을 합니다. "상위 몇 %의 토큰 후보 중에서 고를 것인가"를 정하는 건데, Temperature와 함께 출력의 다양성을 조절합니다.

실무에서 이걸 어떻게 쓰냐면, 코드 생성처럼 정확성이 중요한 작업에는 Temperature를 낮게, 브레인스토밍이나 글쓰기처럼 다양한 아이디어가 필요한 작업에는 높게 설정합니다. Claude Code에서 직접 Temperature를 조절할 일은 많지 않지만, API를 직접 호출하거나 다른 도구를 쓸 때 이 개념을 알면 결과물 품질을 조절할 수 있습니다.

 

5. 그래서 이걸 알면 뭐가 달라지나

지금까지 설명한 걸 정리하면 이렇습니다.

개념	핵심	활용 시 시사점
토큰	LLM이 텍스트를 읽는 단위	프롬프트를 간결하게, 한글은 토큰 소모가 큼
다음 토큰 예측	이해가 아니라 확률 기반 예측	AI 출력을 맹신하지 않고 검증하는 습관
할루시네이션	모르는 걸 그럴듯하게 생성	사실 확인 필수, 도구 연결로 보완
Temperature	출력의 무작위성 조절	작업 목적에 따라 창의성/정확성 조절

결국 LLM은 엄청나게 정교한 "다음 단어 예측기"입니다. 이걸 인정하면 AI를 더 잘 쓸 수 있습니다. "왜 틀렸지?"가 아니라 "어떻게 하면 맞는 방향으로 예측하게 할까?"로 사고가 바뀌거든요.

프롬프트를 잘 쓰는 것도, 컨텍스트를 관리하는 것도, 하네스를 설계하는 것도 결국 이 원리에서 출발합니다. LLM이 올바른 토큰을 예측할 수 있도록 환경을 만들어주는 거니까요.

다음 편에서는 컨텍스트 윈도우와 어텐션 메커니즘을 다뤄보려고합니다. "AI가 긴 대화에서 앞부분을 까먹는 이유"와 "중요한 정보를 어디에 배치해야 하는지"에 대한 이야기를 작성하려고 해요.

---

참고 자료

• What Is ChatGPT Doing… and Why Does It Work? - Stephen Wolfram
• Intro to Large Language Models - Andrej Karpathy (YouTube)
• Prompt Engineering Guide - Anthropic Docs
• Building Effective Agents - Anthropic