LLM

토큰은 왜 단어가 아닐까

2026.08.21.

LLM8편

1LLM은 왜 다음 토큰 하나만 예측할까
2Transformer는 왜 Q, K, V 셋으로 나눴을까

3토큰은 왜 단어가 아닐까읽는 중
4LLM은 왜 가장 확률 높은 토큰을 고르지 않을까
5Positional Encoding에서 RoPE까지, 어텐션에 순서를 부여하는 법

1 / 2

API 요금표는 토큰당 가격을 매기고, 컨텍스트 창은 토큰 수로 정해지고, LLM 추론 비용은 요청 수와 무관하게 토큰 단위로 붙습니다. 모두가 토큰을 세는데 정작 토큰이 무엇인지는 짚고 넘어가는 일이 드뭅니다. 단어 하나일 수도 있고 단어의 일부일 수도 있다는 정도로 얼버무리기 일쑤죠.

그 “일부”라는 말에 생각보다 많은 설계가 숨어 있습니다. 텍스트는 단어로 쪼갤 수도 있고 글자로 쪼갤 수도 있는데 현대 LLM은 전부 그 중간 어딘가를 택했습니다. 얼마나 굵게 자를지는 사람이 정하지만, 어디서 자를지는 데이터가 정합니다.

이 글에서는 왜 단어도 글자도 아닌지에서 출발해 토큰화(tokenization)의 표준 알고리즘인 BPE를 봅니다. 그다음 쪼개진 조각에 매긴 번호를 벡터로 바꾸는 임베딩과 다시 확률 분포로 되돌리는 lm_head까지, 텍스트가 모델을 드나드는 양 끝단을 짚습니다.

단어로 쪼개면 안 될까

신경망 기계 번역 초기에는 텍스트를 단어로 쪼갰습니다. 가장 자연스러운 선택이었죠. 자주 나오는 단어 3만에서 5만 개로 어휘(vocabulary)를 만들고 목록에 없는 단어는 전부 <UNK>(unknown)라는 토큰 하나로 뭉갰습니다.

그런데 단어는 닫힌 집합이 아닙니다. 새 고유명사와 신조어가 계속 생기고 한국어 같은 교착어에서는 동사 하나가 수십 가지 활용형으로 나타납니다. “먹었다”, “먹는다”, “먹으니”는 뿌리가 같은데 단어 단위 어휘에서는 전부 독립된 항목입니다. 어휘를 아무리 키워도 처음 보는 단어는 나오고 그때마다 <UNK>가 등장합니다. 모델 입장에서 <UNK>는 단어의 정체가 지워진 토큰입니다. 무엇이 있었는지는 사라지고 모르는 무언가가 있었다는 사실만 남으니까요. 생성 쪽은 더 심합니다. 어휘에 없는 단어는 모델이 출력할 방법 자체가 없습니다.

반대 극단은 글자입니다. 한글 완성자 11,172자, 영어 알파벳 26자면 끝이니 모르는 단어라는 개념 자체가 사라지죠. 대신 시퀀스가 길어집니다. 공백 포함 77자짜리 영어 문장이 실제 GPT 토크나이저로는 18토큰인데 글자 단위면 77토큰, 4배가 넘습니다. Transformer의 어텐션은 토큰 쌍마다 관계를 계산하는 연산이라 길이가 4배면 어텐션 점수 계산량은 16배가 됩니다. 게다가 글자 하나에는 의미가 거의 실리지 않습니다. “았”이라는 글자는 혼자서는 아무것도 뜻하지 않고 “좋았다”에 들어가야 과거라는 뜻이 생기니 같은 내용을 배우는 데 모델이 더 먼 문맥을 봐야 합니다.

그래서 현대 토크나이저는 중간을 택합니다. 자주 나오는 덩어리는 통째로 토큰이 되고 드문 부분은 잘게 쪼개집니다. 이 단위가 서브워드(subword)입니다.

위 그림의 서브워드 분할은 GPT 계열 토크나이저(o200k)의 실제 출력 그대로입니다. 자주 나오는 “오늘”과 “았다”는 하나로 뭉쳤고 나머지 “은”, “날”, “씨”, “가”, “좋”은 글자 그대로 남았습니다. 그림에서는 생략했지만 “날”과 “좋” 앞에는 공백이 붙어 있는데 공백은 이렇게 뒤따르는 토큰의 일부가 됩니다. 한국어는 글자 9개가 7토큰으로 영어만큼 줄지 않는데 한글이 덜 병합되는 탓입니다. 어느 쪽이든 이 경계는 사람이 그은 게 아닙니다. 코퍼스(말뭉치) 통계가 그었고 통계를 경계로 바꾸는 알고리즘이 BPE입니다.

압축 알고리즘을 빌려오다

1994년 Philip Gage가 발표한 Byte Pair Encoding은 원래 파일 압축 기법입니다. 데이터에서 가장 자주 나오는 인접 바이트 쌍을 새 기호 하나로 치환하고 이 과정을 반복합니다. 자주 나오는 패턴일수록 짧은 기호로 줄어드니 전체 크기가 작아지는 원리죠.

2016년 Sennrich 연구진이 이 알고리즘을 기계 번역의 희귀 단어 문제에 적용했습니다. 절차는 압축 때와 같습니다.

코퍼스를 글자 단위로 쪼갠 상태에서 시작합니다
가장 자주 인접해서 나타나는 쌍을 찾아 하나로 병합합니다
병합된 덩어리를 새 어휘 항목으로 추가하고, 2로 돌아갑니다

실제 구현에는 이 앞에 단계가 하나 더 있습니다. 텍스트를 먼저 공백과 문장부호, 숫자 경계에서 조각냅니다(사전 토큰화). 병합은 각 조각 안에서만 일어납니다. 단어 앞의 공백은 그 단어 조각에 붙습니다. 그래서 단어 경계를 넘는 병합은 생기지 않고 아래 워크스루도 단어 안에서만 쌍을 셉니다.

작은 코퍼스로 따라가 보겠습니다. low가 5번, lower가 2번, newest가 6번, widest가 3번 나옵니다.

e와 s가 붙어 나오는 횟수가 9회(newest 6 + widest 3)로 가장 많으니 es가 첫 병합입니다. s와 t도 9회로 같지만 동률이면 먼저 만난 쌍을 택합니다. 다음은 es와 t가 합쳐져 est가 되고 l과 o, lo와 w가 뒤를 잇습니다. 네 번 병합했더니 이 코퍼스에서 자주 쓰이는 덩어리인 est와 low가 어휘에 들어왔습니다. -est 같은 접미사가 통째로 토큰이 되는 게 우연이 아닌 거죠. 자주 나오니까 병합됐을 뿐인데 자주 나오는 형태소일수록 먼저 통째로 토큰이 되니 결과적으로 형태소와 비슷한 경계가 잡힙니다.

병합 규칙 학습이 끝나면 남는 것은 순서가 매겨진 규칙 목록입니다. 새 텍스트가 들어오면 글자 단위로 쪼갠 뒤 이 목록을 학습된 순서 그대로 적용합니다. 규칙과 순서가 고정이니 같은 텍스트는 언제 넣어도 같은 토큰 나열이 됩니다.

처음 보는 단어가 들어오면 이 방식의 장점이 드러납니다. lowest는 위 코퍼스에 한 번도 없었지만 low와 est가 어휘에 있으니 두 토큰으로 표현됩니다. 코퍼스에 있던 lower도 통째로는 병합되지 못했으니 low, e, r 세 토큰이 되고요. 병합을 더 이어가면 er도 묶입니다. Sennrich 연구진이 노린 효과가 이것입니다. <UNK>로 뭉개는 대신 아는 조각의 조합으로 재구성하는 것이죠. 아는 글자로 이루어진 단어라면 아무리 낯설어도 최악의 경우 글자까지 내려가면 되니 표현하지 못하는 단어가 사라집니다.

병합을 몇 번 할지가 곧 어휘 크기입니다. 어휘 크기는 설계자가 정하는 하이퍼파라미터입니다. 데이터에서 발견되는 값이 아니죠. GPT-2의 어휘 구성에 이 구조가 드러납니다.

GPT-2 어휘 50,257 = 기본 바이트 256 + 병합 규칙 50,000 + 특수 토큰 1 (<|endoftext|>)

글자에서 시작하면 문제가 글자 자체로 옮겨갑니다. 유니코드 문자 전부를 기본 어휘에 넣자니 그것만 16만 자에 가까워 목표 어휘보다 크고 코퍼스에 나온 문자만 넣자니 처음 보는 문자에서 다시 <UNK>가 필요합니다. 그래서 GPT-2는 시작점을 글자에서 UTF-8 바이트로 내렸습니다. 어휘 구성의 첫 항 “기본 바이트 256개”가 그 결과입니다. 어떤 텍스트든 256종 바이트의 나열이니 표현하지 못하는 입력이 원천적으로 사라지고, 이 방식을 byte-level BPE라 부릅니다. 한글 한 글자는 UTF-8로 3바이트라서 병합되기 전이라면 글자 하나가 3토큰인 셈입니다.

SentencePiece와 Unigram

서브워드를 만드는 알고리즘이 BPE만 있는 것은 아닙니다. Llama 초기 모델이 쓴 SentencePiece는 공백까지 일반 문자로 취급해 언어를 가리지 않고 처리하는 구현인데, Llama는 그중 BPE 모드를 바이트가 아닌 문자에서 시작해 모르는 문자만 바이트로 떨어뜨리는 설정으로 썼습니다. 같은 도구가 지원하는 Unigram 방식은 반대 방향이죠. 병합으로 어휘를 키워가는 대신 큰 후보 어휘에서 덜 유용한 조각을 덜어내고, 분할할 때도 규칙 순서를 따르지 않고 확률이 가장 높은 분할을 고릅니다. 방향은 달라도 결과물은 닮았습니다. 자주 나오는 덩어리가 토큰이 된다는 원리가 같으니까요.

특수 토큰은 이 병합 과정과 무관하게 어휘에 직접 박아 넣는 항목입니다. 생성 종료를 알리는 <EOS>, 챗 템플릿의 역할 구분자, 도구 호출을 감싸는 <|tool_call|> 같은 토큰들이죠. 모델 카드에 “시스템 역할을 토크나이저 수준에서 지원한다”고 적혀 있다면 이런 토큰이 어휘의 정식 항목으로 자리를 확보하고 있다는 뜻입니다. 그 자리는 챗 템플릿이 들어가는 학습 단계에서 학습됩니다. 거꾸로 말하면, 배포된 모델에 특수 토큰을 나중에 끼워 넣으려면 어휘에 항목을 추가하고 모델도 그에 맞춰 추가 학습시켜야 합니다.

정리하면 토크나이저는 모델이 아닙니다. 모델 학습이 시작되기 전에 별도의 코퍼스 통계로 병합 규칙을 확정해 두고 그 뒤로는 규칙을 기계적으로 적용하는 전처리기입니다. 모델은 텍스트를 본 적이 없습니다. 토크나이저가 넘겨준 번호의 나열만 봅니다.

색인 번호에서 벡터로

“오늘은 날씨가 좋았다”를 토크나이저에 넣으면 이렇게 나옵니다.

"오늘은 날씨가 좋았다"
→ [149830, 4740, 61781, 68282, 4081, 32077, 69458]
   (오늘 · 은 · ␣날 · 씨 · 가 · ␣좋 · 았다)    ␣ = 앞에 붙은 공백

이 번호는 어휘 목록의 색인일 뿐입니다. 149830번과 149831번은 이웃한 숫자지만 의미상 아무 관계가 없습니다. 그런데 신경망은 실수 벡터를 받아 실수 벡터를 내는 함수라서 색인을 벡터로 바꿔주는 단계가 필요합니다.

그 일을 맡는 것이 임베딩 테이블(embedding table)입니다. 어휘 크기 $|V|$ 곱하기 $d_{\text{model}}$ 크기의 행렬 $E$ 를 두고 색인 번호, 즉 토큰 ID가 들어오면 그 번호의 행을 꺼냅니다. 연산이라 부르기 민망할 만큼 단순한 조회(lookup)죠. ID를 one-hot 벡터로 만들어 행렬을 곱해도 결과는 같지만 실제 구현은 그냥 행을 꺼냅니다.

여기서 $d_{\text{model}}$ 은 모델 전체가 쓰는 벡터의 폭입니다. 임베딩 테이블에서 꺼낸 벡터는 모델 본체인 Transformer 블록 수십 개를 차례로 지나면서 블록마다 갱신되는데 이렇게 블록 사이를 오가는 위치별 벡터를 hidden state라 부릅니다. 임베딩 벡터도 hidden state도 전부 이 차원이고 모델 카드의 hidden size가 이 값입니다. 행렬 $E$ 의 값은 처음에 무작위이고 다음 토큰을 맞히는 학습이 채웁니다. 비슷한 맥락에 나타나는 토큰들이 비슷한 벡터로 모이는 것은 그 학습의 부산물이고요.

모델의 반대쪽 끝에는 같은 모양의 행렬이 하나 더 있습니다. hidden state를 어휘 전체의 점수로 되돌리는 행렬로, 흔히 lm_head 또는 unembedding이라 부릅니다. 여기 들어가는 hidden state는 마지막 Transformer 블록의 출력을 최종 정규화한 값입니다.

P(w_{t+1} \mid w_{1:t}) = \mathrm{softmax}(W_U \, h_t), \qquad W_U \in \mathbb{R}^{|V| \times d_{\text{model}}}

$w_{1:t}$ 는 첫 토큰부터 $t$ 번째까지의 입력 전체이고, $h_t$ 는 마지막 위치의 hidden state, $W_U$ 가 lm_head입니다. 이 곱셈의 결과는 어휘 항목마다 하나씩, 총 $|V|$ 개의 점수(logit)입니다. softmax는 이 점수들을 합이 1인 양수 비율, 즉 확률 분포로 바꾸는 함수입니다. LLM은 매 스텝 어휘 전체에 대한 확률 분포를 내놓고 거기서 다음 토큰을 고릅니다. 그 분포가 이 곱셈 한 번으로 나옵니다.

$W_U$ 와 $E$ 는 모양이 같아서(둘 다 $|V| \times d_{\text{model}}$ ) 아예 한 행렬을 같이 쓰기도 합니다(weight tying). 그러면 토큰 $w$ 의 점수는 그 토큰의 입력 임베딩과 $h_t$ 의 내적이 됩니다. GPT-2가 그랬고 지금은 모델마다 갈립니다. 임베딩 비중이 큰 소형 모델에서는 묶는 쪽이 남는 장사라 Gemma 계열은 지금도 묶습니다. Llama는 8B 이상 주력 모델에서 따로 두지만 소형인 Llama 3.2 1B와 3B는 묶었습니다.

그림 가운데 점선은 실제 서빙에서도 경계입니다. 토큰화와 디토큰화는 CPU 작업이라 서빙 엔진들은 이 단계를 GPU 실행 루프와 별도 프로세스로 분리합니다. 긴 프롬프트를 쪼개는 동안 GPU에 일감을 주는 루프가 멈춰 있으면 그 시간만큼 GPU가 놀기 때문입니다.

RAG의 임베딩과는 다른 물건입니다

검색이나 RAG에서 말하는 임베딩은 별도의 임베딩 모델이 문장이나 문서 전체를 벡터 하나로 요약한 결과입니다. 이 글의 임베딩은 LLM 내부에서 토큰 하나마다 행 하나를 꺼내는 테이블이고요. 하나는 모델이 문장을 읽고 내놓은 출력 벡터이고 다른 하나는 토큰마다 고정된 학습 파라미터입니다. 같은 단어를 쓰지만 만드는 주체도, 단위도, 용도도 다릅니다.

토큰화의 대가

토큰화는 공짜가 아닙니다. 병합 규칙은 코퍼스 통계에서 나오는데 토크나이저 학습 코퍼스는 영어가 압도적으로 많습니다. 그러니 영어는 긴 단어도 토큰 하나로 묶이고 다른 언어는 잘게 쪼개집니다. 언어 간 불균형이 가장 체감되는 비용이죠. 같은 뜻의 두 문장을 GPT-4의 토크나이저(cl100k, 어휘 약 10만)로 세어 보면 이렇습니다.

EN "The weather was nice today, so I took a slow walk in the park this afternoon."
   공백 포함 77자 → 18토큰
KO "오늘은 날씨가 좋아서 오후에 공원을 천천히 산책했습니다."
   공백 포함 31자 → 39토큰

영어는 18토큰, 한국어는 39토큰입니다. 글자 수는 한국어가 절반도 안 되는데 토큰 수는 두 배를 넘습니다. 토큰이 곧 과금 단위이자 컨텍스트 창의 단위이니 같은 내용을 다뤄도 한국어 사용자는 더 비싸게, 더 좁게 쓰는 셈입니다.

구조를 뜯어보면 한글은 출발선부터 다릅니다. 31자에 39토큰이면 글자 단위보다도 깁니다. 바이트에서 출발한 한글이 글자 수준까지도 다 병합되지 못한 결과입니다. byte-level 토크나이저에서 알파벳은 1바이트, 한글은 글자마다 3바이트에서 시작합니다. 거기서 얼마나 큰 덩어리로 병합되느냐는 코퍼스 등장 빈도가 정하는데 병합 규칙의 자리는 코퍼스에 많은 영어 패턴부터 채워집니다. 덜 병합된 언어는 글자보다 잘게, 바이트 조각 단위까지 쪼개진 채 남는 구조입니다.

숫자는 자릿수와 무관하게 쪼개집니다. GPT-4 계열 토크나이저는 숫자를 왼쪽부터 최대 세 자리씩 끊는 규칙을 사전 토큰화에 둡니다. 그래서 “12345”는 “123”과 “45”가 되고 “1000000”은 “100”, “000”, “0”이 됩니다. 왼쪽 기준이라 같은 자릿값이 매번 다른 덩어리에 들어갑니다. 받아올림 같은 자릿수 연산을 배우기에 애초부터 불리한 표현이죠.

철자 질문에서는 같은 기제가 더 노골적으로 드러납니다. GPT-4 계열 토크나이저에서 ” strawberry”는 앞에서 본 “날”처럼 공백이 붙은 채 통째로 토큰 하나죠. strawberry에 r이 몇 개냐는 질문에 모델이 헤매는 출발점이 여기입니다. 모델이 받는 것은 그 토큰의 임베딩 벡터 하나이고 그 안에 r이 세 번 들어 있다는 정보는 어디에도 적혀 있지 않습니다. 모델은 이 토큰 안의 글자를 본 적이 없고요. 철자를 답하려면 철자가 풀어 쓰인 다른 문맥에서 그 관계를 간접적으로 배워 뒀어야 하고, 거기에 셈까지 얹어야 하니 틀리기 쉽습니다.

한번 정한 토크나이저는 되돌리기 어렵습니다. 병합 규칙과 어휘는 모델 학습 전에 확정되고 임베딩 테이블의 행 번호가 곧 어휘 항목입니다. 토큰 몇 개를 더하는 정도는 행을 늘려 추가 학습하면 됩니다. 하지만 토크나이저를 통째로 바꾸면 기존 임베딩과 lm_head가 전부 무효가 되어 거의 처음부터 다시 학습해야 합니다. 어휘가 다른 두 모델은 같은 텍스트를 서로 다른 ID 나열로 봅니다. speculative decoding에서 두 모델의 어휘가 같아야 하는 것도 같은 이유입니다. draft 모델이 후보 토큰을 먼저 뽑으면 본체가 그것을 검증하는 방식이니까요.

어휘는 왜 커지고 있나

숫자와 철자 문제만 보면 토큰을 더 잘게, 그러니까 어휘를 줄이는 쪽이 답처럼 보입니다. 실제 흐름은 반대였죠. 어휘 크기의 기준은 오랫동안 5만이었습니다. GPT-2와 GPT-3가 쓴 50,257이 사실상의 표준이라 언어 모델 계산에서 어휘를 5만으로 놓고 어림하는 관행도 여기서 나왔습니다. Llama 1이 32K로 잠깐 내려간 뒤로는 계속 커지기만 했고요.

GPT-2   (2019)   50K
Llama 1 (2023)   32K
Llama 3 (2024)  128K
GPT-4o  (2024)  200K
Qwen3.5 (2026)  250K
Gemma 4 (2026)  262K

어휘를 키우는 이유는 방금 본 언어 간 불균형에 있습니다. 어휘가 크면 더 긴 덩어리까지 토큰 하나로 묶이고 특히 영어 밖 언어가 덜 잘게 쪼개집니다. 위에서 39토큰이던 한국어 문장이 GPT-4o의 토크나이저 o200k(어휘 20만)에서는 18토큰입니다. 영어 문장은 두 토크나이저에서 똑같이 18토큰이니 한국어만 영어 수준까지 내려온 셈이고요. 어휘를 두 배로 키우고 다국어 비중을 높였더니 이 문장의 토큰 수가 절반이 됐습니다. 같은 컨텍스트 창에 두 배의 내용이 들어가고 토큰당 과금이라면 요금도 절반입니다.

토큰 수는 줄지만 모델은 커집니다. 임베딩 테이블과 lm_head는 각각 $|V| \times d_{\text{model}}$ 크기라 어휘에 정비례해 커집니다. 묶는 모델이면 이런 행렬이 하나, 따로 두면 둘입니다. 어휘 26만에 $d_{\text{model}}$ 이 4096이면 행렬 하나가 10억 파라미터를 넘습니다. 수천억 파라미터 모델에서는 오차 수준이지만 수십억짜리 소형 모델에서는 전체의 상당 부분이 임베딩이죠. Gemma가 모델 크기를 말할 때 임베딩을 뺀 유효 파라미터를 따로 세는 이유입니다. 파라미터만의 문제도 아니어서 토큰을 하나 생성할 때마다 lm_head 곱셈이 $|V|$ 개의 logit을 만들어야 하니 어휘가 두 배면 이 곱셈의 비용도 두 배가 됩니다. 스텝 전체에서 차지하는 몫은 일부지만 어휘에 정비례해 따라옵니다.

참고로 Gemma 4의 262K는 정확히 $2^{18}$ , 즉 262,144입니다. 행렬 크기를 하드웨어가 다루기 좋은 2의 거듭제곱이나 128의 배수로 맞추는 관행이 어휘 크기에도 적용된 결과입니다.

앞서 본 언어 불균형, 숫자, 철자 문제가 전부 토큰 경계에서 오니 경계 자체를 없애자는 연구도 있습니다. Meta의 BLT(Byte Latent Transformer)는 바이트를 직접 받되 예측하기 어려운 지점을 기준으로 바이트를 동적 패치로 묶어 시퀀스 길이 문제를 피합니다. 다만 2026년 현재 이 방향은 연구 단계입니다. 8B 규모까지 스케일링이 확인됐을 뿐 공개된 프론티어 모델 중 채택 사례는 없고 지금 배포된 모델은 사실상 전부 서브워드 토크나이저 위에서 돌아갑니다.

마치며

토큰은 모델이 텍스트를 읽는 해상도이고 그 해상도는 언어마다 고르지 않습니다. 토큰의 굵기는 설계자가 고른 어휘 크기에서 나오고, 경계의 위치는 코퍼스 통계가 정했습니다. 한번 정해지면 모델과 함께 굳습니다. 요금표의 생김새부터 철자 질문의 오답까지, LLM을 쓰며 마주치는 특성 상당수가 모델에 들어가기도 전인 이 전처리 단계에서 정해집니다.

모델의 출력이 어휘 전체에 대한 확률 분포라는 것까지 왔습니다. 그 분포에서 토큰 하나를 어떻게 고를까요? 다음 글에서는 greedy, beam search, top-p, temperature 같은 생성 전략이 각각 어떤 확률적 의미인지 다룹니다.