P6-6.1 긴 생성의 출발점이 되는 다음 토큰 예측¶

Section ID: P6-6.1 Version: v2026.07.23

P6-5.2에서는 GPT 기반 생성 구조가 어떻게 대화형 LLM 경험으로 이어졌는지 보았습니다. 이제 질문을 더 좁힐 차례입니다.

그렇게 큰 모델은 학습할 때 정확히 무엇을 반복하는가?

LLM을 처음 접할 때 가장 많이 듣는 답은 다음입니다.

LLM은 다음 토큰을 예측하도록 학습된다.

이 문장은 맞지만, 너무 짧으면 오해를 부릅니다. 많은 독자는 이 말을 듣고 그럼 단순 자동완성 아닌가?라고 생각합니다. 여기서는 바로 그 질문을 더 정확한 수준으로 정리합니다.

생성형 LLM을 이해할 때 첫 기준은 모델이 무엇을 반복해서 맞히도록 훈련되는가입니다. 검색이나 도구 연결은 생성 결과를 보강하는 장치이고, 정렬은 응답 습관을 조정하는 단계입니다. 그보다 앞에서 붙잡아야 할 감각은 현재 문맥에서 다음 토큰 분포를 계산하는 일이 긴 생성의 출발점이라는 점입니다.

다음 토큰 예측이라는 기본 목표¶

기본 학습 목표는 다음 질문에서 시작합니다.

다음 토큰 예측은 정확히 무엇을 예측하는가?
왜 이 단순해 보이는 목표가 긴 문장, 요약, 질의응답, 코드 생성으로 이어질 수 있는가?
다음 토큰 예측만으로 무엇을 설명할 수 있고, 무엇은 설명하지 못하는가?

여기서 다루는 것은 무엇을 학습 목표로 삼는가입니다. 후보들 중 실제 생성 시 무엇을 고를지는 출력 선택 규칙의 문제이고, 응답 습관을 어떻게 조정할지는 정렬과 후속 조정의 문제입니다. 이 셋을 구분해야 다음 토큰 예측이라는 한 문장을 너무 많은 뜻으로 늘려 쓰지 않게 됩니다.

따라서 핵심은 자동완성처럼 보인다는 인상보다 현재 문맥에서 다음 토큰 분포를 반복 계산한다는 학습 목표입니다. 이 절에서는 LLM이 학습 중 무엇을 반복 예측하는지, 그리고 그 국소 예측이 왜 긴 생성과 다양한 언어 작업의 출발점이 되는지를 잡습니다. 후보 중 무엇을 실제로 고르는지는 다음 절의 sampling 문제로, 응답 습관과 안전성을 어떻게 조정하는지는 뒤의 instruction tuning과 alignment 문제로 남겨 둡니다.

목표는 LLM의 기본 학습 목표가 무엇인지 스스로 설명할 수 있을 정도로 기준을 세우는 것입니다.

문장을 한 번에 꺼내는 모델이라는 인상을 현재 문맥에서 다음 토큰 분포를 계산하고 그 선택을 누적하는 구조로 바꾸어 읽어야 합니다.

다음 토큰 목표와 긴 생성의 구분¶

다음 토큰 예측을 토큰 단위로 설명할 수 있습니다.
문장 생성이 한 번에 완성되는 것이 아니라 순차적으로 이어진다는 점을 설명할 수 있습니다.
왜 단순한 예측 목표가 복잡한 언어 행동으로 이어질 수 있는지 말할 수 있습니다.
이 기준만으로 LLM 전체를 다 설명할 수 없다는 점을 구분할 수 있습니다.

이 기준이 중요한 이유는 다음과 같습니다.

토큰, 임베딩, Transformer를 하나의 학습 목표로 다시 묶어 주고
생성형 AI의 기본 동작을 과장 없이 설명하게 하며
이후 sampling, temperature, prompting, alignment를 모두 이 기반 위에 놓을 수 있게 하기 때문입니다

다음 토큰 예측의 판단 기준¶

다음 토큰 예측을 단순 자동완성으로만 읽지 않으려면 네 가지 기준을 분리해야 합니다.

판단 기준	확인할 질문
예측 단위	문장 전체가 아니라 다음 토큰 후보 분포를 계산하는가
토큰 단위	단어가 아니라 토큰 조각 기준으로 설명하고 있는가
누적 효과	현재 문맥이 바뀌면 다음 후보 분포도 함께 바뀌는가
후속 연결	sampling, prompting, alignment 설명의 출발점으로 이어지는가

다음 토큰 예측은 무엇을 뜻하나¶

LLM은 학습 중에 긴 텍스트를 보고, 현재까지 주어진 토큰 뒤에 어떤 토큰이 올 가능성이 높은지를 반복해서 맞추도록 조정됩니다.

예를 들어 다음처럼 볼 수 있습니다.

입력 맥락(context): 오늘 날씨가 매우
다음 후보 토큰: 좋다, 춥다, 맑다, ...

이때 모델은 현재까지의 토큰들을 바탕으로 바로 다음 토큰의 확률 분포를 계산합니다.

중요한 점은 모델이 처음부터 문장 전체를 통째로 꺼내는 것이 아니라는 점입니다.

현재까지의 맥락을 보고, 다음 한 조각을 예측하고, 그 조각을 다시 맥락에 붙이는 과정이 반복됩니다.

왜 토큰(token) 단위인가¶

LLM은 보통 글자를 그대로 다루지 않고 토큰(token) 단위로 다룹니다. 이 책의 앞 절에서 보았듯, 토큰은 단어 전체일 수도 있고, 단어 일부일 수도 있고, 기호 조각일 수도 있습니다.

그래서 다음 단어 예측이라고 하면 엄밀하지 않은 경우가 많습니다. 더 안전한 표현은 다음입니다.

LLM은 다음 토큰(next token)을 예측하도록 학습된다.

이 차이를 구분해야 나중에 토큰화(tokenization), 문맥 길이(context window), 비용 계산을 함께 이해할 수 있습니다.

왜 단순한 목표가 복잡한 기능으로 이어지나¶

여기서 독자가 가장 많이 멈춥니다.

다음 한 조각 맞히기만 반복하는데, 왜 요약도 하고 번역도 하고 코드도 작성할 수 있을까요?

핵심은 다음과 같습니다.

언어는 순차 구조를 갖고
문맥에 따라 다음 표현이 크게 달라지며
긴 문서와 다양한 장르를 많이 보면
다음 토큰을 잘 맞히기 위해 문법, 표현, 관계, 형식, 일부 세계 지식을 함께 반영해야 하기 때문입니다

즉, 학습 목표 자체는 국소적(local)으로 보이지만, 그 목표를 잘 수행하려면 넓은 패턴을 내부적으로 다뤄야 합니다.

이 점이 LLM을 단순 자동완성과 완전히 같은 것으로만 보기 어려운 이유입니다.

자동완성과 어디까지 같고 어디서부터 달라지나¶

자동완성 비유가 유용한 이유는 둘 다 현재 맥락 뒤에 무엇이 올지 고른다는 공통 구조를 가지기 때문입니다. 지금까지 입력된 맥락을 보고 다음 출력을 예측하고, 한 조각씩 이어 붙이며 결과를 만든다는 점에서는 자동완성과 LLM 생성이 닮아 있습니다.

하지만 여기서 멈추면 설명이 부족합니다. LLM 생성은 훨씬 긴 문맥, 다양한 문서 형식, 작업 지시, 대화 기록까지 함께 반영할 수 있고, 그 결과 요약, 질의응답, 설명, 변환, 코드 생성 같은 작업 형태로 확장됩니다. 따라서 비교의 핵심은 자동완성과 같은가 아닌가가 아니라, 같은 다음 토큰 예측 구조가 더 큰 문맥과 더 긴 출력에서 어떤 부담을 만들기 시작하는가입니다.

비교축	짧은 자동완성 비유	LLM 생성에서 더 크게 드러나는 점
입력 맥락	짧은 문장 일부	긴 문서, 대화 기록, 지시문까지 함께 반영할 수 있다
출력 길이	다음 한두 단어	여러 문장, 코드 블록, 요약 단락으로 길게 이어질 수 있다
작업 범위	이어쓰기 보조	요약, 질의응답, 설명, 변환, 코드 생성처럼 다양한 형식으로 확장된다
실패 양상	어색한 다음 단어	사실 오류, 구조 붕괴, 잘못된 중심 문장처럼 더 큰 수준의 실패로 이어질 수 있다

즉, LLM도 출발점은 자동완성과 닮았지만, 입력 범위, 출력 길이, 실패 비용이 훨씬 커지기 때문에 단순한 문장 보조보다 더 넓은 시스템처럼 읽어야 합니다. 더 안전한 정리는 다음과 같습니다.

LLM은 다음 토큰 예측 구조를 기반으로 하지만, 대규모 사전학습과 추가 조정을 거치며 매우 다양한 언어 작업 형태를 수행하게 된다.

아주 단순하게 그리면¶

flowchart TD
  A["문맥 토큰"]
  B["다음 토큰 분포"]
  C["토큰 하나 선택"]
  D["선택 토큰을 문맥에 추가"]
  E["바뀐 문맥으로 반복"]

  A --> B
  B --> C
  C --> D
  D --> E
  E --> B

이 도식의 핵심은 생성이 한 번에 끝나는 계산이 아니라 반복되는 순차 계산이라는 점입니다.

사례 및 예시¶

아래 도식은 이 절의 세 사례를 다음 한 토큰을 고른다보다 초반 선택이 뒤 문맥 전체를 어떻게 밀고 가는가라는 공통 질문으로 다시 묶은 것입니다.

flowchart TD
  A["같은 다음 토큰 구조"]
  B["이메일 초안<br/>첫 표현이 응답 톤을 정함"]
  C["요약 작성<br/>첫 문장이 뒤 강조를 정함"]
  D["코드 생성<br/>초반 토큰이 뒤 구조를 제한함"]

  A --> B
  A --> C
  A --> D

이 도식에서 확인해야 할 점은 과업이 달라도 생성이 모두 누적 구조라는 것입니다. 초반 토큰 하나의 선택이 뒤 문장, 뒤 요약, 뒤 코드 구조까지 연쇄적으로 영향을 줄 수 있으므로, 다음 토큰 예측은 한 조각 찍기보다 뒤 흐름을 정하는 시작 선택으로 읽는 편이 더 정확합니다.

사례 1. 이메일 문장 이어쓰기¶

입력이 안녕하세요, 문의하신 내용에 대해로 시작하는 고객 메일 초안을 생각해 볼 수 있습니다. 사람은 이런 문장을 보면 뒤 문장이 거의 정답 하나로 정해져 있다고 느끼기 쉽지만, 실제로는 설명, 사과, 안내 같은 여러 표현이 후보가 될 수 있습니다.

예를 들어 같은 문의라도 확인 결과, 불편을 드려 죄송합니다, 다음 절차를 안내드립니다처럼 서로 다른 시작이 모두 자연스러울 수 있습니다. 여기서 바뀌는 점은 정답 문장 하나를 꺼내는가를 보던 기준에서 현재 맥락에서 어떤 후보가 더 자연스러운가를 보는 기준으로 이동한다는 것입니다.

여기서 중요한 것은 다음 문장이 하나로 고정된다는 점이 아니라, 몇 가지 후보 중 어떤 표현이 현재 맥락에 더 자연스러운가입니다. 모델은 학습 중 이런 이어쓰기 패턴을 반복적으로 보며 다음 토큰 분포를 익힙니다.

첫 문장을 사과 중심으로 잡으면 뒤도 보상이나 처리 일정 안내가 따라오기 쉽고, 확인 결과 중심으로 잡으면 설명형 문장이 이어질 가능성이 커집니다. 그래서 이 사례에서 확인해야 할 결과는 같은 입력이라도 첫 표현 선택에 따라 뒤 문장의 말투와 후속 안내 흐름이 실제로 달라지는가입니다.

이 사례가 중요한 이유는 생성 결과가 머릿속 어딘가에 있는 정답 문장을 꺼내는 과정처럼 느껴질 수 있기 때문입니다. 하지만 실제로는 첫 몇 토큰이 뒤 문장의 성격을 밀어 가는 누적 구조에 더 가깝습니다. 이메일 초안에서 죄송합니다로 시작하면 뒤도 보상과 조치 안내 쪽으로 이어지기 쉽고, 확인 결과로 시작하면 설명과 사실 전달 쪽으로 이어질 가능성이 커집니다. 그래서 다음 토큰 예측을 이해할 때는 한 문장 전체를 한 번에 고른다보다 초반 선택이 뒤 흐름의 방향을 정한다로 보는 편이 더 정확합니다.

이 차이를 이어쓰기 선택 관점으로 다시 보면 다음과 같습니다.

첫 표현 선택	사람 눈에는 모두 자연스러워 보이는 점	뒤 문장에서 실제로 달라지기 쉬운 흐름
`불편을 드려 죄송합니다`	고객 응답으로 무난해 보임	사과, 보상, 후속 처리 안내가 이어지기 쉬움
`확인 결과`	사실 전달 시작으로 무난해 보임	설명형 문장과 원인 정리가 뒤따르기 쉬움
`다음 절차를 안내드립니다`	친절한 안내처럼 보임	단계별 행동 안내와 링크/방법 설명이 이어지기 쉬움

이 표가 바로잡는 오해는 어차피 비슷한 문장이니 뒤도 거의 같을 것이라는 기대입니다. 실제로는 초반 몇 토큰의 선택이 뒤 말투와 안내 구조를 계속 끌고 갑니다.

사례 2. 요약¶

회의록을 세 줄 요약으로 바꾸는 장면을 생각해 볼 수 있습니다. 사람은 결과만 보면 요약이라는 별도 능력처럼 느끼기 쉽고, 한 번에 압축된 정답을 꺼내는 것처럼 상상하기 쉽습니다.

하지만 실제 생성 과정에서는 지금까지 만든 요약 문장 뒤에 어떤 표현이 자연스러운지를 계속 이어 붙이는 구조가 반복됩니다. 예를 들어 첫 줄에서 배포 일정이 연기되었다를 선택하면, 다음 줄은 그 이유나 후속 조치를 잇는 표현이 더 자연스러워질 수 있습니다.

여기서 바뀌는 점은 요약 정답을 한 번에 꺼낸다는 감각에서 첫 문장 선택이 뒤 요약 흐름을 계속 민다는 감각으로 기준이 이동한다는 것입니다. 물론 이때는 입력 문서 핵심이 내부적으로 반영되어 있어야 엉뚱한 다음 표현을 고르지 않습니다.

첫 줄이 잘못 시작되면 뒤 문장도 그 흐름을 따라가므로, 잘못된 중심 문장을 초기에 잡는 비용이 큽니다. 즉, 요약도 특별한 마법이 아니라 문맥을 반영한 다음 토큰 선택의 연속으로 읽을 수 있습니다. 그래서 이 사례에서 확인해야 할 결과는 첫 요약 문장을 어떻게 시작했는지에 따라 뒤 문장의 이유, 조치, 강조 순서가 실제로 함께 달라지는가입니다.

이 장면도 실무에서 자주 느끼는 오해를 바로 건드립니다. 사람은 요약 결과를 다 보고 나면 처음부터 이 요약 전체를 알고 있었겠지라고 상상하기 쉽습니다. 하지만 실제로는 첫 줄에서 무엇을 중심으로 잡았는지가 둘째 줄, 셋째 줄의 방향을 계속 밀어 갑니다. 배포 일정이 연기되었다로 시작하면 뒤에는 이유와 후속 조치가 붙기 쉽고, 법무 검토가 필요하다로 시작하면 위험과 승인 절차가 중심이 되기 쉽습니다. 즉 요약도 한 번에 완성된 정답을 꺼내는 능력이라기보다, 중심 문장을 어떻게 잡았는지가 뒤 흐름을 규정하는 누적 생성 구조로 읽는 편이 더 정확합니다.

같은 회의록도 첫 줄 선택에 따라 뒤 요약 구조가 달라집니다.

첫 요약 문장 선택	먼저 떠올리기 쉬운 인상	뒤에서 실제로 강조되기 쉬운 것
`배포 일정이 연기되었다`	핵심 결론부터 잡은 요약처럼 보임	연기 이유, 다음 조치
`법무 검토가 필요하다`	위험 중심 요약처럼 보임	승인 절차, 보류 항목
`담당자가 변경되었다`	인수인계 중심 요약처럼 보임	역할 전환, 후속 책임

이 사례에서 중요한 기준은 요약은 한 번에 압축된 결과라는 인상보다 첫 중심 문장이 뒤 문장의 강조 순서를 밀어 간다는 구조입니다. 다음 토큰 예측 관점은 바로 이 누적 효과를 설명하려고 필요합니다.

사례 3. 코드 생성¶

코드 생성에서 def calculate_total까지 쓴 장면을 떠올려 볼 수 있습니다. 사람은 이 위치를 보면 다음에 괄호, 콜론, 들여쓰기 블록 같은 구조가 이어질 가능성을 기대합니다.

동시에 코드는 자유 서술보다 훨씬 엄격해서, 현재 문맥과 맞지 않는 토큰이 하나만 들어와도 바로 문법 오류나 흐름 오류로 무너지기 쉽습니다. 예를 들어 함수 이름은 총액 계산인데 다음 줄에서 할인 변수를 빼먹거나, 닫아야 할 괄호를 놓치면 뒤 전체가 무너질 수 있습니다.

조건문 들여쓰기가 한 번 틀어지면 반환문 위치까지 연쇄적으로 어긋난다는 점도 같은 구조를 보여 줍니다. 여기서 바뀌는 점은 코드 블록을 한 번에 완성한다는 감각에서 초반 토큰 선택이 뒤 구조 전체를 계속 끌고 간다는 감각으로 기준이 이동한다는 것입니다.

LLM은 이런 코드 토큰 패턴도 자연어와 마찬가지로 현재 맥락 뒤에 무엇이 가장 그럴듯한가를 반복 선택하는 구조 안에서 다룹니다. 그래서 이 사례에서 확인해야 할 결과는 초반 토큰 하나의 선택이 뒤 코드의 변수명, 들여쓰기, 반환 구조까지 연쇄적으로 흔드는가입니다.

세 사례를 다음 토큰 선택 관점으로 다시 묶으면 다음과 같습니다.

상황	현재 맥락이 먼저 정하는 것	다음 단계에서 바로 달라지는 후보
이메일 이어쓰기	사과형, 설명형, 안내형 같은 톤	뒤 문장의 말투와 안내 흐름
요약	첫 요약 문장의 중심 정보	이유, 조치, 강조 순서
코드 생성	함수 구조와 현재 블록 문맥	괄호, 들여쓰기, 반환 패턴

다음 토큰 예측이 드러나는 장면¶

sampling이나 temperature 세부를 아직 몰라도, 지금 보는 현상이 학습 목표인 다음 토큰 예측과 어떻게 연결되는지는 짧게 가를 수 있습니다. 같은 앞문장 뒤에 사과형, 설명형, 안내형 후보가 모두 자연스럽다면 정답 문장 하나가 저장되어 있는가보다 현재 맥락에서 다음 후보 분포가 여러 갈래로 열려 있는가를 먼저 물어야 합니다. 요약 첫 줄을 잘못 잡자 뒤 문장도 같은 방향으로 밀린다면 요약 전체를 통째로 꺼냈는가보다 첫 선택이 뒤 생성 경로를 계속 바꾸는 순차 구조인가를 봐야 합니다. 코드에서 괄호 하나가 어긋난 뒤 전체 블록이 무너진다면 사소한 토큰 하나쯤 뒤에서 복구되겠지보다 현재 토큰 선택이 뒤 문맥 조건을 연쇄적으로 바꾸는가를 물어야 합니다.

이 구분에서 중요한 것은 자동완성과 완전히 같은가를 따지는 일이 아니라, 긴 생성도 결국 현재 문맥 뒤에 무엇이 올지를 반복해서 맞히는 구조 위에 놓여 있다는 점을 실제 사례에 대입해 보는 일입니다.

여기서 자주 섞이는 것도 다음과 같습니다.

학습 목표인 다음 토큰 예측과 실제 서비스 응답 전체를 같은 층위로 묶기 쉽습니다.
요약, 설명, 코드 생성을 서로 다른 마법처럼 보지만 모두 같은 순차 예측 구조 위에 있다는 점을 놓치기 쉽습니다.
다음 토큰 하나의 선택이 뒤 구조 전체를 얼마나 강하게 미는지 과소평가하기 쉽습니다.

따라서 LLM은 다음 토큰을 예측하도록 학습된다는 문장은 암기용 정의가 아니라 실제 생성 장면을 읽는 기준이 되어야 합니다.

이 구분의 목적은 원인을 한 번에 확정하는 데 있지 않습니다. 다음 토큰 예측을 한 문장 정의로만 외우지 않고, 지금 보고 있는 현상이 후보 분포, 누적 생성, 연쇄 오류 중 어디에서 먼저 드러나는지 짧게 가르는 데 있습니다.

연습 및 예제¶

이 예제의 목표는 실제 LLM 전체를 구현하는 것이 아니라, 학습 데이터에서 다음 토큰 후보가 어떻게 만들어지고, 선택된 토큰이 다시 다음 단계의 입력이 되는가를 눈으로 확인하는 것입니다. 고정된 점수 사전을 손으로 넣는 대신, 작은 문장 묶음에서 직접 이전 세 토큰 -> 다음 토큰 빈도를 세고 그 결과로 여러 프롬프트를 이어서 생성해 보겠습니다.

아래 코드는 짧은 학습 문장 여러 개, 생성 시작 프롬프트 여러 개, 최대 생성 길이를 사용합니다. 결과에서는 문맥별 다음 토큰 후보 분포, 각 단계에서 선택된 토큰, 첫 분기에서 어떤 후보 경쟁이 있었는지, 누적 생성된 최종 시퀀스를 함께 봅니다. 동률 후보가 있을 때는 실행 과정을 단순하게 보이기 위해 먼저 관찰된 후보를 고릅니다. 이 선택 규칙은 실제 LLM의 디코딩 전략을 흉내 내기 위한 것이 아니라, 후보 분포가 생기고 하나를 고르면 다음 문맥이 바뀐다는 흐름을 보기 위한 장치입니다.

확인할 핵심은 다음 토큰 분포가 학습 문장들에서 반복된 연결 패턴이 누적된 결과로 만들어진다는 점입니다.

먼저 입력으로 쓰는 작은 학습 문장 묶음을 보겠습니다. 이 입력은 실제 LLM 학습 데이터가 아니라, 앞 문맥이 같아도 다음 후보가 여러 갈래로 열릴 수 있다는 감각을 보여 주기 위한 축소 말뭉치입니다. 각 묶음은 같은 앞부분을 공유하는 두 문장으로 구성되어, 첫 분기에서 후보가 둘로 갈라지도록 설계되어 있습니다.

입력 묶음	학습 문장	첫 분기에서 만들어지는 후보
회의 결과	`회의 결과 배포 일정은 다음 주로 연기되었습니다` `회의 결과 우선 수정 항목을 먼저 처리합니다`	`배포`, `우선`
고객 문의 확인 결과	`고객 문의 확인 결과 환불 절차를 안내드립니다` `고객 문의 확인 결과 배송 일정을 다시 안내드립니다`	`환불`, `배송`
배포 오류 확인 결과	`배포 오류 확인 결과 설정 파일 경로가 잘못되었습니다` `배포 오류 확인 결과 로그 수집 범위를 먼저 확인합니다`	`설정`, `로그`

코드는 이 문장들을 공백 기준 토큰으로 나누고, 이전 세 토큰 -> 다음 토큰 빈도를 셉니다. 실제 LLM은 이렇게 정확한 세 토큰 표를 찾아 쓰는 구조가 아니지만, 이 축소 예제는 현재 문맥에서 후보 분포가 생기고, 선택된 토큰이 다음 문맥에 다시 붙는다는 순차 생성 감각을 확인하는 데 목적이 있습니다.

# 작은 학습 문장 묶음에서 이전 세 토큰별 다음 토큰 빈도를 세고, 그 분포로 프롬프트를 이어 생성하는 예제입니다.
from collections import Counter, defaultdict

training_sentences = [
    "회의 결과 배포 일정은 다음 주로 연기되었습니다",
    "회의 결과 우선 수정 항목을 먼저 처리합니다",
    "고객 문의 확인 결과 환불 절차를 안내드립니다",
    "고객 문의 확인 결과 배송 일정을 다시 안내드립니다",
    "배포 오류 확인 결과 설정 파일 경로가 잘못되었습니다",
    "배포 오류 확인 결과 로그 수집 범위를 먼저 확인합니다",
]

def tokenize(sentence):
    return sentence.split()

def build_ngram_counts(sentences):
    ngram_counts = defaultdict(Counter)
    for sentence in sentences:
        tokens = ["<BOS1>", "<BOS2>", "<BOS3>"] + tokenize(sentence) + ["<EOS>"]
        for i in range(len(tokens) - 3):
            context = (tokens[i], tokens[i + 1], tokens[i + 2])
            next_token = tokens[i + 3]
            ngram_counts[context][next_token] += 1
    return ngram_counts

def next_token_distribution(ngram_counts, context_tokens):
    context = tuple(context_tokens[-3:])
    counter = ngram_counts.get(context, Counter())
    total = sum(counter.values())
    if total == 0:
        return {}
    return {
        token: round(count / total, 2)
        for token, count in counter.most_common()
    }

def generate_tokens(ngram_counts, prompt, max_steps=5):
    generated = ["<BOS1>", "<BOS2>", "<BOS3>"] + tokenize(prompt)
    trace = []

    for _ in range(max_steps):
        context = generated[-3:]
        distribution = next_token_distribution(ngram_counts, context)
        if not distribution:
            trace.append(
                {
                    "context": tuple(context),
                    "distribution": {},
                    "selected": "<STOP:no-known-next-token>",
                }
            )
            break

        selected = max(distribution, key=distribution.get)
        trace.append(
            {
                "context": tuple(context),
                "distribution": distribution,
                "selected": selected,
            }
        )
        if selected == "<EOS>":
            break
        generated.append(selected)

    visible_tokens = [token for token in generated if not token.startswith("<BOS")]
    return visible_tokens, trace

ngram_counts = build_ngram_counts(training_sentences)
prompts = ["회의 결과", "고객 문의 확인 결과", "배포 오류 확인 결과"]

for prompt in prompts:
    generated, trace = generate_tokens(ngram_counts, prompt, max_steps=5)
    print("=" * 80)
    print("prompt =", prompt)
    if trace:
        first_distribution = trace[0]["distribution"]
        print("first_branch_candidates =", first_distribution)
    for step_index, step in enumerate(trace, start=1):
        print(f"[step {step_index}] context =", step["context"])
        print("distribution =", step["distribution"])
        print("selected =", step["selected"])
    print("generated =", generated)

이 예제는 로컬 .venv의 Python으로 실행해 본문 출력과 일치함을 확인했습니다.

실행 결과 예시는 다음처럼 읽을 수 있습니다.

================================================================================
prompt = 회의 결과
first_branch_candidates = {'배포': 0.5, '우선': 0.5}
[step 1] context = ('<BOS3>', '회의', '결과')
distribution = {'배포': 0.5, '우선': 0.5}
selected = 배포
[step 2] context = ('회의', '결과', '배포')
distribution = {'일정은': 1.0}
selected = 일정은
[step 3] context = ('결과', '배포', '일정은')
distribution = {'다음': 1.0}
selected = 다음
[step 4] context = ('배포', '일정은', '다음')
distribution = {'주로': 1.0}
selected = 주로
[step 5] context = ('일정은', '다음', '주로')
distribution = {'연기되었습니다': 1.0}
selected = 연기되었습니다
generated = ['회의', '결과', '배포', '일정은', '다음', '주로', '연기되었습니다']
================================================================================
prompt = 고객 문의 확인 결과
first_branch_candidates = {'환불': 0.5, '배송': 0.5}
[step 1] context = ('문의', '확인', '결과')
distribution = {'환불': 0.5, '배송': 0.5}
selected = 환불
[step 2] context = ('확인', '결과', '환불')
distribution = {'절차를': 1.0}
selected = 절차를
[step 3] context = ('결과', '환불', '절차를')
distribution = {'안내드립니다': 1.0}
selected = 안내드립니다
[step 4] context = ('환불', '절차를', '안내드립니다')
distribution = {'<EOS>': 1.0}
selected = <EOS>
generated = ['고객', '문의', '확인', '결과', '환불', '절차를', '안내드립니다']
================================================================================
prompt = 배포 오류 확인 결과
first_branch_candidates = {'설정': 0.5, '로그': 0.5}
[step 1] context = ('오류', '확인', '결과')
distribution = {'설정': 0.5, '로그': 0.5}
selected = 설정
[step 2] context = ('확인', '결과', '설정')
distribution = {'파일': 1.0}
selected = 파일
[step 3] context = ('결과', '설정', '파일')
distribution = {'경로가': 1.0}
selected = 경로가
[step 4] context = ('설정', '파일', '경로가')
distribution = {'잘못되었습니다': 1.0}
selected = 잘못되었습니다
[step 5] context = ('파일', '경로가', '잘못되었습니다')
distribution = {'<EOS>': 1.0}
selected = <EOS>
generated = ['배포', '오류', '확인', '결과', '설정', '파일', '경로가', '잘못되었습니다']

긴 실행 결과를 먼저 압축하면 다음과 같습니다.

프롬프트	첫 후보 분포	선택된 첫 토큰	뒤 생성 경로
`회의 결과`	`배포`: 0.5, `우선`: 0.5	`배포`	`일정은 -> 다음 -> 주로 -> 연기되었습니다`
`고객 문의 확인 결과`	`환불`: 0.5, `배송`: 0.5	`환불`	`절차를 -> 안내드립니다`
`배포 오류 확인 결과`	`설정`: 0.5, `로그`: 0.5	`설정`	`파일 -> 경로가 -> 잘못되었습니다`

이 요약 표에서 먼저 볼 것은 첫 후보가 하나로 고정되어 있지 않다는 점입니다. 같은 방식으로 만든 작은 말뭉치라도 현재 프롬프트가 달라지면 첫 후보 분포가 달라지고, 첫 토큰을 하나 고르면 그 토큰이 다시 다음 단계 문맥에 붙어 뒤 생성 경로를 바꿉니다.

이 예제에서 확인해야 할 결과는 학습 데이터에서 문맥별 다음 후보 분포가 만들어지고, 현재 문맥이 바뀌면 후보 분포도 달라지며, 선택된 토큰이 다시 더 긴 맥락이 되어 다음 선택 조건으로 이어진다는 점입니다. 특히 first_branch_candidates를 보면, 세 프롬프트가 모두 처음 한 번의 후보 경쟁부터 이미 다르게 시작한다는 점을 바로 읽을 수 있습니다.

학습 문장에서 문맥별 다음 후보가 집계된다
현재 문맥에 따라 다음 후보 분포가 달라진다
하나를 고르면 그 토큰이 다시 다음 단계 문맥에 붙는다
초반 선택이 뒤 생성 흐름 전체를 밀고 간다

순차 생성에서 누적되는 후보 분포¶

이 예제는 생성 결과를 한 번에 꺼내는 상자로 보기보다, 현재까지 만든 맥락이 다음 선택 조건으로 계속 되돌아오는 순환 구조로 읽어야 한다는 점을 보여 줍니다. 회의 결과 뒤에서는 배포, 우선 같은 후보가 생기고, 고객 문의 확인 결과 뒤에서는 환불, 배송이, 배포 오류 확인 결과 뒤에서는 설정, 로그가 후보로 달라집니다. 그리고 한 번 환불을 고르면 그다음에는 절차를, 안내드립니다처럼 그 흐름에 맞는 토큰이 다시 이어지고, 설정을 고르면 파일, 경로가, 잘못되었습니다처럼 전혀 다른 경로가 이어집니다. 그래서 뒤에서 sampling, prompting, alignment를 볼 때도 모두 다음 토큰 선택이 누적되며 응답 전체가 만들어진다는 관점을 유지하는 것이 중요합니다.

이 예제를 판단 기준으로 다시 줄이면 다음 세 질문이 먼저 떠올라야 합니다.

장면	먼저 답해야 하는 질문
왜 같은 앞문장인데 후보가 하나로 고정되지 않는가	현재 문맥이 여러 다음 토큰 후보 분포를 만들고 있는가
왜 첫 줄 선택이 뒤 요약과 뒤 코드 구조까지 흔드는가	선택된 토큰이 다시 다음 단계 문맥으로 들어가는 순차 구조인가
왜 요약, 설명, 코드 생성이 하나의 학습 목표에서 출발할 수 있는가	서로 다른 작업도 `지금 뒤에 무엇이 자연스러운가`를 맞히는 능력 위에 놓여 있는가

체크리스트¶

다음 토큰 예측을 긴 답변 전체가 아니라 다음 한 조각 분포의 반복이라는 말로 설명할 수 있는가?
자동완성과 LLM을 같게 만드는 점과 다르게 만드는 점을 함께 말할 수 있는가?
이어지는 생성 선택 설명을 무엇을 학습했는가가 아니라 후보 중 무엇을 고르는가의 문제로 읽을 준비가 되었는가?

출처와 참고 자료¶

Yoshua Bengio et al., A Neural Probabilistic Language Model, JMLR, 2003, 확인 날짜: 2026-07-19. https://jmlr.csail.mit.edu/papers/v3/bengio03a
Tomas Mikolov et al., Recurrent Neural Network Based Language Model, Interspeech, 2010, 확인 날짜: 2026-07-19. https://www.isca-archive.org/interspeech_2010/mikolov10_interspeech.html
Alec Radford et al., Improving Language Understanding by Generative Pre-Training, OpenAI, 2018, 확인 날짜: 2026-07-19. https://cdn.openai.com/research-covers/language-unsupervised/language_understanding_paper.pdf
Tom B. Brown et al., Language Models are Few-Shot Learners, arXiv, 2020, 확인 날짜: 2026-07-19. https://arxiv.org/abs/2005.14165