토큰과 토큰화 (Tokenization)

토큰과 토큰화 (Tokenization)

LLM은 우리가 입력한 문자열을 그대로 계산하지 않습니다. 텍스트는 먼저 토크나이저를 지나 작은 조각으로 나뉘고, 각 조각은 정수 ID로 바뀝니다. 모델이 실제로 받는 것은 이 ID 배열이며, ID는 다시 임베딩 벡터로 변환되어 신경망의 입력이 됩니다.

토큰화는 단순한 전처리처럼 보이지만 모델 사용 경험에 직접 영향을 줍니다. 같은 문장도 토크나이저에 따라 길이가 달라지고, 그 차이는 컨텍스트 사용량·비용·지연으로 이어집니다. 철자나 숫자처럼 토큰 경계와 실제 문제의 단위가 어긋나는 작업에서는 추론 난이도에도 영향을 줄 수 있습니다. 다만 모델의 실패를 토큰화 하나로만 설명해서는 안 됩니다. 토큰화는 입력 표현에 편향을 만들고 특정 작업을 어렵게 만드는 요인 중 하나입니다.

이 글에서는 문자열이 모델 입력이 되는 과정부터 BPE·WordPiece·Unigram의 차이, SentencePiece와 byte-level 토큰화, 어휘 크기와 한국어 토큰 효율까지 연결해서 살펴봅니다.

---

문자열이 모델 입력이 되기까지

사람이 보는 문자열과 모델이 계산하는 입력 사이에는 몇 단계가 있습니다.

문자열
  ↓
정규화 (선택적)
  ↓
Pre-tokenization (토크나이저에 따라 다름)
  ↓
BPE / WordPiece / Unigram 등의 분할
  ↓
토큰
  ↓
정수 ID
  ↓
임베딩 벡터
  ↓
Transformer

예를 들어 안녕하세요라는 문자열이 토큰 세 개로 분할됐다고 하겠습니다.

"안녕하세요"
    ↓
[토큰 A, 토큰 B, 토큰 C]
    ↓
[15496, 24231, 8236]   # 예시 ID

여기서 숫자 자체에 언어적 의미가 있는 것은 아닙니다. 15496은 해당 토크나이저의 vocabulary에서 특정 토큰에 배정된 번호이고, 모델에서는 임베딩 행렬의 한 행을 선택하는 인덱스로 사용됩니다.

ID 15496
   ↓
embedding[15496]
   ↓
벡터

그래서 모델 체크포인트와 토크나이저는 한 세트입니다. 같은 문자열을 다른 토크나이저로 인코딩하면 ID 체계가 달라지고, 모델이 학습한 임베딩과 맞지 않게 됩니다.

왜 글자나 단어 그대로 쓰지 않는가

글자 단위는 어휘가 작고 어떤 문자열도 잘게 표현할 수 있다는 장점이 있습니다. 대신 시퀀스가 길어집니다. 특히 일반적인 full attention Transformer에서는 시퀀스 길이가 늘수록 attention 계산량이 크게 증가합니다.

단어 단위는 반대입니다. 시퀀스는 짧아지지만 vocabulary가 커지고, 학습 때 보지 못한 단어를 처리하기 어렵습니다. 한국어처럼 조사와 어미가 붙어 표면형이 많이 생기는 언어에서는 이 문제가 더 커집니다.

서브워드는 둘 사이의 절충입니다.

자주 나오는 표현   → 크게 묶는다
드문 표현          → 더 작은 조각으로 나눈다

예를 들어 한 토크나이저에서 다음과 같이 나뉠 수 있습니다.

"the"          → the
"unhappiness"  → un + happi + ness
"asdkfjh"      → as + dk + f + jh

중요한 점은 서브워드라는 이유만으로 모든 문자를 반드시 표현할 수 있는 것은 아니라는 것입니다. 초기 alphabet에 없는 문자가 들어오면 <unk>가 생길 수 있습니다. byte-level BPE나 byte fallback처럼 바이트까지 내려가는 방식을 쓰면 이 문제를 피할 수 있습니다.

---

BPE가 토큰을 만드는 법

Byte Pair Encoding은 원래 1994년에 제안된 데이터 압축 알고리즘입니다. 가장 자주 반복되는 바이트 쌍을 다른 기호로 치환해 데이터를 줄였습니다.

2015년 Sennrich 등이 이를 기계번역의 서브워드 분할에 적용했습니다. 압축에서의 핵심 아이디어인 “가장 자주 붙는 쌍을 반복해서 합친다”를 토큰 vocabulary 학습에 사용한 것입니다.

학습

작은 예제로 보면 동작이 단순합니다.

코퍼스
    low     5회
    lower   2회
    newest  6회
    widest  3회

처음에는 글자처럼 작은 단위에서 시작합니다.

l o w
l o w e r
n e w e s t
w i d e s t

그다음 전체 코퍼스에서 인접한 두 조각의 빈도를 셉니다.

1. 가장 자주 등장하는 인접 쌍을 찾는다
2. 그 쌍을 새 토큰으로 합친다
3. 다시 빈도를 센다
4. 목표 vocabulary 크기까지 반복한다

예를 들어 다음처럼 병합이 진행될 수 있습니다.

e + s   → es
es + t  → est
l + o   → lo
lo + w  → low
n + e   → ne
ne + w  → new

학습 결과에는 vocabulary와 병합 순서가 남습니다.

vocabulary
    "l"
    "o"
    "lo"
    "low"
    "est"
    ...

merge rules
    e s
    es t
    l o
    lo w
    ...

BPE가 형태소를 이해해서 est 같은 조각을 찾은 것은 아닙니다. 코퍼스에서 함께 자주 등장했기 때문에 합쳐졌고, 그 결과가 언어학적 단위와 우연히 잘 맞을 수 있는 것입니다.

인코딩

토크나이저 학습은 한 번 수행하지만 인코딩은 입력마다 수행합니다.

입력
 ↓
초기 단위로 분할
 ↓
학습한 merge rule 적용
 ↓
더 이상 합칠 수 없으면 종료
 ↓
vocabulary에서 ID 조회

일반적인 BPE 인코딩은 학습된 규칙에 의해 결정적으로 동작합니다. 같은 토크나이저 설정과 같은 정규화된 입력이면 같은 토큰 배열이 나옵니다.

---

BPE, WordPiece, Unigram

Transformer에서 자주 만나는 서브워드 방식은 BPE, WordPiece, Unigram입니다. 셋 모두 vocabulary 크기와 시퀀스 길이 사이의 절충을 풀지만, 학습 방식과 인코딩 방식은 다릅니다.

방식	학습 방향	학습의 핵심	인코딩의 핵심
BPE	작은 단위 → 큰 단위	가장 자주 등장하는 쌍을 병합	학습된 merge rule 적용
WordPiece	작은 단위 → 큰 단위	빈도 비율 기반 점수가 높은 조합을 선택	vocabulary에서 가능한 조각을 greedily 탐색
Unigram	큰 후보 집합 → 작은 vocabulary	제거했을 때 손실이 적은 토큰을 삭제	확률이 높은 분할 선택

WordPiece

WordPiece는 BERT 계열에서 잘 알려진 방식입니다. BPE와 마찬가지로 작은 단위에서 시작하지만 단순히 가장 많이 등장한 쌍을 고르지 않습니다.

Hugging Face 문서에서 설명하는 직관적인 점수는 다음과 같습니다.

score(A, B) = freq(AB) / (freq(A) × freq(B))

각각 흔한 두 조각이 우연히 자주 붙는 것보다, 따로는 상대적으로 덜 등장하지만 함께 있을 때 유독 자주 나타나는 조합을 더 높게 평가합니다.

BERT의 WordPiece 표현에서는 단어 중간에 등장하는 조각을 ##로 표시하는 경우가 익숙합니다.

playing → play + ##ing

여기서 주의할 점은 WordPiece가 BPE처럼 merge rule 목록을 그대로 적용해 인코딩하는 방식은 아니라는 것입니다. 학습한 vocabulary를 바탕으로 입력의 앞쪽부터 가능한 긴 조각을 찾는 방식이 일반적인 설명에 더 가깝습니다.

Unigram

Unigram은 방향이 반대입니다. 처음부터 큰 후보 vocabulary를 만든 뒤 덜 중요한 토큰을 제거합니다.

큰 후보 vocabulary
      ↓
토큰 하나를 제거했을 때 전체 손실이 얼마나 증가하는지 계산
      ↓
손실 증가가 작은 후보 제거
      ↓
목표 vocabulary 크기까지 반복

각 토큰에는 score가 있고, 한 문자열을 여러 방식으로 나눌 수 있을 때 전체 score가 좋은 분할을 선택합니다.

이 확률 모델 덕분에 학습 중에는 항상 같은 분할만 쓰지 않고 여러 후보 분할을 샘플링하는 subword regularization도 사용할 수 있습니다. 이는 모델이 특정 토큰 경계에 지나치게 의존하지 않도록 만드는 방법입니다.

---

SentencePiece는 무엇인가

SentencePiece를 BPE·WordPiece·Unigram과 같은 수준의 알고리즘으로 나열하면 구조가 헷갈립니다.

SentencePiece는 raw text에서 직접 vocabulary를 학습하고 인코딩하는 토큰화 도구/라이브러리이고, 내부 모델로 unigram, bpe, char, word 등을 선택할 수 있습니다. 공식 구현에서도 model_type으로 이 방식을 고릅니다.

SentencePiece가 해결하려 했던 중요한 문제 중 하나는 공백 기반 pre-tokenization에 대한 의존입니다. 영어에서는 공백으로 단어 후보를 나누기 쉽지만, 중국어·일본어처럼 공백이 단어 경계가 아닌 언어에서는 같은 전제를 사용하기 어렵습니다.

SentencePiece는 공백도 입력의 일부로 다루며 보통 ▁ 기호로 시각화합니다.

"Hello world"
    ↓
▁Hello ▁world

이 구조 덕분에 토큰을 이어 붙인 뒤 ▁를 공백으로 되돌리는 방식으로 정규화된 입력 문자열을 복원할 수 있습니다.

여기서 “완전히 원본 그대로 복원된다”고 단정하면 안 됩니다. 토크나이저가 앞단에서 Unicode 정규화나 공백 정리를 수행했다면 복원 대상은 원본 바이트열이 아니라 정규화 이후의 텍스트입니다.

---

바이트까지 내려가는 이유

문자 기반 vocabulary만 사용하면 학습 때 alphabet에 없던 Unicode 문자를 처리하기 어려울 수 있습니다. 이를 해결하는 대표적인 방법이 바이트를 기본 단위 또는 fallback 단위로 사용하는 것입니다.

Byte-level BPE

GPT-2가 대표적인 예입니다. UTF-8 문자열을 바이트 관점에서 다루면 가능한 값은 0~255의 256개뿐입니다.

모든 입력 문자열
    ↓ UTF-8
byte sequence
    ↓
256개 기본 값으로 항상 표현 가능

그 위에서 BPE 병합을 학습하면 흔한 바이트 패턴은 큰 토큰이 되고 드문 문자열은 더 작은 바이트 단위로 남습니다. 기본 단위가 모든 바이트를 포함하므로 <unk> 없이 임의의 문자열을 표현할 수 있습니다.

OpenAI의 tiktoken도 byte pair encoding 계열입니다.

Byte fallback은 같은 말이 아니다

모든 현대 토크나이저가 GPT-2식 byte-level BPE를 사용하는 것은 아닙니다. SentencePiece 기반 토크나이저처럼 문자/서브워드를 주로 사용하다가 모르는 문자를 만났을 때만 byte fallback으로 내려가는 설계도 있습니다.

따라서 다음은 구분하는 편이 좋습니다.

byte-level BPE
    처음부터 byte를 기본 alphabet으로 사용

byte fallback
    평소에는 일반 subword를 쓰고
    표현할 수 없는 부분만 byte로 내림

둘의 공통 목적은 희귀 문자, 이모지, 특수 기호까지 안정적으로 표현하는 것입니다.

---

어휘 크기가 바꾸는 것

Vocabulary를 크게 만들면 더 많은 문자열 조각을 하나의 토큰으로 담을 수 있습니다. 평균 시퀀스 길이는 줄어들 가능성이 높지만 그 대가로 embedding과 출력층이 커집니다.

입력 embedding의 파라미터 수는 대략 다음과 같습니다.

vocabulary size × hidden size

예를 들어 vocabulary가 200,000개이고 hidden size가 4,096이면 embedding만 약 8.2억 개의 파라미터가 필요합니다. 입력 embedding과 출력 projection을 묶지 않는 모델은 출력층에도 비슷한 규모가 필요합니다.

또한 autoregressive LM은 다음 토큰을 생성할 때 vocabulary 전체에 대한 logits를 만들어야 하므로 vocabulary 확대는 출력 계산에도 비용을 추가합니다.

반대로 vocabulary가 너무 작으면 같은 문장이 더 많은 토큰으로 쪼개집니다. 그러면 컨텍스트를 더 많이 사용하고 prefill 길이와 생성 step 수에도 영향을 줍니다.

실제 공개 모델만 봐도 vocabulary 크기는 크게 다릅니다.

모델	vocab_size
GPT-2	50,257
Llama 3.1 8B	128,256
Qwen3 8B	151,936
gpt-oss 20B	201,088

이 숫자를 보고 “새 모델일수록 vocabulary가 무조건 커진다”고 일반화해서는 안 됩니다. 모델이 목표로 하는 언어 범위, 코드·수학 데이터, special token 설계, tokenizer 학습 코퍼스에 따라 결정되는 설계 선택입니다.

---

토큰 경계가 모델 동작에 미치는 영향

토큰화는 모델의 능력을 결정하는 유일한 요소가 아니지만 입력을 어떤 단위로 보여줄지 정하는 inductive bias를 만듭니다.

글자 단위 작업

strawberry의 r 개수를 세거나 문자열을 뒤집는 문제는 사람이 글자를 단위로 보면 간단합니다. 하지만 모델 입력은 글자 배열이 아니라 서브워드 ID 배열입니다.

사람이 필요한 단위
s t r a w b e r r y

모델이 받을 수 있는 단위의 예
straw + berry

이 경우 모델은 토큰 내부의 철자 구조를 직접 입력 위치로 받지 않습니다. 학습을 통해 토큰의 spelling 정보를 어느 정도 배울 수 있고 최신 모델은 이런 문제를 잘 풀기도 하지만, 문자 단위 표현을 직접 사용하는 시스템보다 불리한 입력 표현인 것은 맞습니다.

따라서 “LLM이 글자를 못 세는 이유는 토큰화 때문이다”보다는 “토큰화가 문자 단위 작업을 어렵게 만드는 한 요인이다”라고 이해하는 편이 정확합니다.

숫자와 산술

숫자는 토큰 경계가 계산 단위와 어긋날 수 있습니다.

123456

토크나이저 A → 123 | 456
토크나이저 B → 12 | 345 | 6
토크나이저 C → 1 | 2 | 3 | 4 | 5 | 6

자리올림이 필요한 산술에서는 어느 자리가 같은 위치인지 맞추는 것이 중요한데 토큰 경계가 자릿수 경계와 다르면 모델이 추가적인 표현 변환을 해야 합니다.

실제로 숫자 토큰화 방향과 단위가 산술 성능에 영향을 준다는 연구가 있으며, 그래서 숫자를 한 자리 또는 일정한 자릿수 단위로 다루는 설계가 사용되기도 합니다. 다만 산술 성능 역시 학습 데이터, 모델 규모, 학습 목표의 영향을 함께 받습니다.

공백과 대소문자

토크나이저는 정규화와 pre-tokenization 규칙에 따라 공백과 대소문자를 서로 다른 토큰으로 만들 수 있습니다.

OpenAI의 tiktoken 테스트에서도 hello world의 앞 공백을 포함한 조각이 vocabulary에 반영되는 식의 동작을 확인할 수 있습니다. 그래서 다음 두 문자열은 문자 하나 차이지만 토큰 배열은 크게 달라질 수 있습니다.

"답:"
"답: "

이것이 결과를 반드시 바꾼다는 뜻은 아닙니다. 다만 프롬프트 변경을 평가할 때는 사람이 보기에 사소한 whitespace 변경도 실제 모델 입력에서는 다른 토큰열이라는 점을 알아둘 필요가 있습니다.

충분히 학습되지 않은 토큰

Vocabulary에 들어 있다는 것과 모델이 그 토큰을 충분히 학습했다는 것은 다른 문제입니다. 토크나이저를 만들 때는 등장했지만 이후 모델 학습 데이터의 필터링·중복 제거 과정에서 거의 사라진 토큰은 embedding이 충분히 업데이트되지 않을 수 있습니다. 이런 항목은 흔히 under-trained token 또는 glitch token이라고 부릅니다.

2024년 EMNLP에 발표된 Fishing for Magikarp은 tokenizer와 모델 학습 데이터의 불일치가 이런 토큰을 만들 수 있음을 체계적으로 분석했습니다. 즉 이상 토큰은 단순한 옛 GPT 계열의 해프닝이라기보다 tokenizer vocabulary와 실제 pretraining 분포가 어긋날 때 생길 수 있는 일반적인 문제입니다.

보안에서도 token boundary를 의식할 필요가 있습니다. Unicode variation selector, zero-width 문자, homoglyph처럼 사람이 거의 구분하지 못하는 문자가 tokenizer에는 전혀 다른 입력으로 들어갈 수 있습니다. 그렇다고 무조건 NFKC 같은 정규화를 강제하면 의미 있는 차이까지 없앨 수 있으므로, 입력 정책에 맞는 Unicode normalization과 control-character 처리 규칙을 정하고 실제 tokenizer 결과까지 포함해 테스트하는 편이 안전합니다.

---

한국어 토큰 효율

한국어가 영어보다 항상 특정 배수만큼 토큰을 더 쓴다고 말할 수는 없습니다. 모델마다 tokenizer vocabulary와 학습 데이터가 다르고, 같은 언어에서도 문체·코드 혼합·고유명사에 따라 차이가 큽니다.

다만 한국어 토큰 효율에 영향을 주는 요인은 설명할 수 있습니다.

UTF-8 바이트 길이

ASCII 영어 문자는 보통 UTF-8에서 1바이트지만 한글 음절은 일반적으로 3바이트입니다.

A     → 1 byte
한    → 3 bytes
😀    → 4 bytes

byte-level tokenizer에서 충분히 병합되지 않은 문자열은 이 차이가 토큰 수 증가로 이어질 수 있습니다. 하지만 한글 한 글자가 3바이트라고 해서 항상 3토큰이라는 뜻은 아닙니다. 학습 과정에서 자주 등장한 한국어 byte sequence는 하나의 큰 토큰으로 병합될 수 있습니다.

코퍼스와 vocabulary

BPE 계열에서는 자주 등장하는 패턴일수록 병합 기회를 많이 얻습니다. 특정 언어가 tokenizer 학습 코퍼스에서 충분히 등장하면 그 언어의 흔한 문자열이 큰 토큰으로 만들어질 가능성이 높습니다.

한국어는 조사와 어미가 결합되는 교착어라 표면형이 다양하다는 특징도 있습니다.

가다
갑니다
갔습니다
갔었는데
가시겠어요

이런 차이는 빈도를 여러 표면형으로 분산시킬 수 있지만, 실제 효율은 tokenizer가 어떤 corpus와 normalization을 사용해 학습됐는지가 더 직접적인 변수입니다.

비용과 컨텍스트

API와 모델 서버는 대체로 token 단위로 context length와 usage를 계산합니다. 같은 의미를 전달하는 한국어 문장이 영어보다 더 많은 토큰을 사용한다면 다음이 함께 영향을 받습니다.

• 컨텍스트에 넣을 수 있는 실제 문서량
• 입력 처리량과 prefill 시간
• token 단위 과금
• 생성해야 하는 출력 token 수

하지만 이를 “한국어는 영어의 두 배” 같은 고정 상수로 계산하면 위험합니다. 실제로 사용할 모델의 tokenizer로 측정해야 합니다.

---

토큰 수는 직접 측정한다

토큰 수를 정확히 알고 싶다면 글자 수를 토큰 수로 환산하지 말고 실제 tokenizer를 사용합니다.

OpenAI 계열 tokenizer는 tiktoken으로 확인할 수 있습니다.

import tiktoken

enc = tiktoken.encoding_for_model("gpt-5")
text = "토큰 수는 모델의 토크나이저로 직접 측정합니다."

ids = enc.encode(text)
print(ids)
print(len(ids))

Hugging Face 모델은 해당 모델과 함께 배포된 tokenizer를 읽는 것이 안전합니다.

from transformers import AutoTokenizer

tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen3-8B")
text = "토큰 수는 모델의 토크나이저로 직접 측정합니다."

ids = tokenizer.encode(text, add_special_tokens=False)
print(ids)
print(len(ids))

채팅 모델에서는 raw 문자열만 세면 실제 요청 길이와 다를 수 있습니다. system/user role, chat template, BOS/EOS와 같은 special token이 추가되기 때문입니다.

Hugging Face 모델이라면 실제 chat template까지 적용해 보는 편이 좋습니다.

messages = [
    {"role": "system", "content": "한국어로 답하세요."},
    {"role": "user", "content": "토큰화가 뭐야?"},
]

ids = tokenizer.apply_chat_template(
    messages,
    tokenize=True,
    add_generation_prompt=True,
)

print(len(ids))

API를 호출했다면 응답의 usage 정보가 실제 요청에 사용된 token accounting을 확인하는 가장 중요한 기준입니다. 다만 제공자에 따라 cached token, reasoning token, image/audio token처럼 세부 항목과 과금 방식이 다를 수 있으므로 total_tokens 하나만 보고 비용을 역산하지 않는 편이 좋습니다.

---

토크나이저는 모델과 함께 관리한다

이미 학습된 모델에서 tokenizer만 임의로 교체하면 안 됩니다.

기존 tokenizer
"hello" → 15339

새 tokenizer
"hello" → 812

모델의 embedding 15339번 행은 기존 tokenizer의 15339번 토큰에 맞춰 학습돼 있습니다. ID 의미를 바꾸면 입력과 embedding의 대응 관계가 무너집니다.

따라서 배포와 파인튜닝에서는 다음을 하나의 버전 단위로 관리하는 것이 안전합니다.

model checkpoint
+ tokenizer vocabulary
+ merge/model 파일
+ tokenizer config
+ special token 정의
+ chat template

새 토큰을 추가하는 것은 가능합니다. 이 경우 vocabulary를 확장하고 모델의 embedding/output layer 크기도 맞춘 뒤, 새로 생긴 embedding이 의미를 배우도록 추가 학습이 필요합니다.

num_added = tokenizer.add_tokens(["<NEW_TOKEN>"])
model.resize_token_embeddings(len(tokenizer))

이 코드만 실행하면 행은 생기지만 새 토큰의 의미까지 학습되는 것은 아닙니다. 실제 데이터로 학습해야 합니다.

---

토큰화의 흐름

토큰화 기술의 흐름을 간단히 놓으면 다음과 같습니다.

시기	변화	의미
1994	Byte Pair Encoding	데이터 압축 알고리즘으로 등장
2015	BPE를 NMT 서브워드에 적용	rare word와 vocabulary 문제를 서브워드로 해결
2012	WordPiece 공개	음성 검색 연구에서 제안되고 이후 BERT 계열이 채택
2018	Unigram / Subword Regularization	확률적 분할과 regularization
2018	SentencePiece	raw text에서 언어 독립적으로 tokenizer 학습
2019	GPT-2 byte-level BPE	256 byte 기반으로 임의 문자열 표현
이후	tokenizer 다양화	다국어, 코드, 숫자, 특수 토큰을 고려한 설계 확대

출발은 압축이었지만 LLM에서는 어떤 문자열을 어떤 계산 단위로 보여줄 것인가라는 표현 설계 문제가 됐습니다.

---

정리

토큰은 단어의 동의어가 아닙니다. 토크나이저가 vocabulary와 학습 규칙에 따라 만든 모델 입력 단위입니다.

BPE는 자주 붙는 조각을 반복해서 병합하고, WordPiece는 병합의 정보성을 반영하는 점수를 사용하며, Unigram은 큰 후보 vocabulary에서 덜 중요한 토큰을 제거합니다. SentencePiece는 이들과 나란히 놓이는 하나의 병합 알고리즘이라기보다 raw text에서 BPE나 Unigram 등을 사용할 수 있게 만든 tokenizer 구현입니다.

byte-level BPE와 byte fallback은 희귀 Unicode 문자를 안정적으로 표현하는 중요한 방법이지만 모든 모델이 같은 방식을 쓰는 것은 아닙니다.

그리고 토큰화는 비용 문제에 그치지 않습니다. 문자 단위 작업이나 숫자 처리처럼 문제의 자연스러운 단위와 token boundary가 다를 때 모델에 추가 부담을 줄 수 있습니다. 반대로 모델의 모든 철자·산술 실패를 토큰화 하나로 설명해서도 안 됩니다.

실무에서 가장 중요한 원칙은 단순합니다. 토큰 수는 추정하지 말고 실제 사용할 tokenizer로 측정하고, 모델과 tokenizer는 하나의 artifact로 관리합니다.

---

용어 정리

용어	뜻
토큰 (token)	토크나이저가 모델 입력 단위로 만든 문자열 또는 byte 조각
토큰화 (tokenization)	문자열을 token sequence와 token ID로 변환하는 과정
토크나이저	정규화·분할·ID 변환 등을 수행하는 전처리 구성요소
vocabulary	토큰과 정수 ID의 대응 관계
subword	단어보다 작은 조각을 포함하는 토큰화 단위
OOV	tokenizer vocabulary로 표현할 수 없는 입력 단위
BPE	자주 등장하는 인접 쌍을 반복적으로 병합하는 방식
WordPiece	빈도 비율 기반 점수로 유용한 조합을 학습하는 서브워드 방식
Unigram	큰 후보 vocabulary에서 확률 모델에 덜 필요한 토큰을 제거하는 방식
SentencePiece	raw text에서 BPE·Unigram 등을 학습·적용할 수 있는 tokenizer 구현
byte-level BPE	256개 byte 값을 기본 alphabet으로 삼는 BPE
byte fallback	일반 vocabulary로 표현할 수 없는 부분만 byte 단위로 내리는 방식
pre-tokenization	BPE 등의 본 알고리즘 전에 입력 경계를 만드는 단계
normalization	Unicode·대소문자·공백 등을 tokenizer 규칙에 따라 정규화하는 단계
special token	BOS, EOS, role marker처럼 일반 텍스트 외의 특별한 역할을 가진 토큰
token efficiency	같은 정보를 표현하는 데 필요한 token 수의 효율

참고자료

• Sennrich et al., Neural Machine Translation of Rare Words with Subword Units — BPE를 NMT 서브워드에 적용한 논문
• Kudo, Subword Regularization: Improving Neural Network Translation Models with Multiple Subword Candidates — Unigram LM과 subword regularization
• SentencePiece: A simple and language independent subword tokenizer and detokenizer
• Google SentencePiece 공식 구현
• Hugging Face, Tokenization algorithms — BPE, WordPiece, Unigram, SentencePiece 설명
• Hugging Face, Normalization and pre-tokenization — tokenizer pipeline과 encoding 차이
• OpenAI, tiktoken — byte pair encoding 기반 tokenizer 구현
• OpenAI, Language Models are Unsupervised Multitask Learners — GPT-2 byte-level BPE
• Singh & Strouse, Tokenization counts: the impact of tokenization on arithmetic in frontier LLMs — 숫자 tokenization과 산술 성능
• Land & Bartolo, Fishing for Magikarp: Automatically Detecting Under-trained Tokens in Large Language Models — under-trained/glitch token 분석
• Gao et al., Imperceptible Jailbreaking against Large Language Models — 보이지 않는 Unicode variation selector가 tokenization과 안전성에 미치는 영향
• Qwen3-8B config — vocab_size=151936
• OpenAI gpt-oss-20b config — vocab_size=201088