Skip to content

토큰은 어떻게 문장을 AI가 처리할 수 있는 단위로 바꾸는가

핵심 요약

토큰(token)은 LLM이 새로 만든 개념이 아니다. 컴파일러의 어휘 분석(lexical analysis), 정보검색, 자연어처리(NLP), 통계적 언어 모델, 신경망 번역, 현대 생성형 LLM으로 이어지는 여러 계산 문맥에서 오래전부터 쓰여 온 용어다. 현대 LLM에서 토큰은 tokenizer가 텍스트를 모델 입력으로 바꾸기 위해 사용하는 이산적 처리 단위로 이해하는 편이 가장 정확하다.

토큰은 단어와 동일하지 않다. 어떤 토큰은 한 글자에 가까울 수 있고, 어떤 토큰은 한 단어 전체에 가까울 수 있으며, 공백·구두점·부분 단어·바이트 조각까지 포함할 수 있다. OpenAI Help Center의 설명처럼 토큰은 모델이 처리하는 텍스트의 구성 단위이며, 언어와 문맥에 따라 길이가 달라진다. 따라서 토큰을 “의미의 최소 단위”로 이해하면 오해가 생긴다. 토큰은 의미론적 단위라기보다 계산 단위다.

현대 생성형 decoder-only LLM의 기본 학습·생성 구조를 단순화해 말하면, 주어진 문맥에서 다음 토큰의 확률분포를 예측하는 과정이 중심에 있다. 이 한정이 중요하다. BERT 계열 masked language model, encoder-only 모델, encoder-decoder 번역 모델은 학습 목표와 사용 방식이 다르다. 이 글에서 말하는 “다음 토큰 예측”은 주로 GPT류 생성형 LLM을 설명하는 범위에서 이해해야 한다.

토큰이 중요한 이유는 LLM의 주요 제약이 토큰 수와 연결되기 때문이다. 컨텍스트 길이, 입력·출력 비용, 출력 제한, 지연 시간, 메모리 사용량은 모두 토큰 수의 영향을 받는다. 다만 실제 속도와 메모리는 토큰 수만으로 결정되지 않는다. 모델 크기, attention 구현, KV cache, batching, 하드웨어, 양자화, 서빙 구조도 함께 작용한다. 그러므로 “모든 것이 토큰으로만 결정된다”보다 “많은 핵심 제약이 토큰 수와 연결된다”는 표현이 더 정확하다.

문제의식

사람은 문장을 단어와 의미의 흐름으로 읽는다. 반면 컴퓨터 시스템은 입력을 먼저 기호열, 문자 코드, 바이트, 숫자 배열로 다룬다. LLM도 한글 문장이나 영어 문장을 인간처럼 직접 읽는 것이 아니라, tokenizer가 정한 규칙에 따라 텍스트를 여러 조각으로 나누고, 각 조각을 정수 ID로 바꾼 뒤, 그 ID를 embedding vector로 변환해 계산한다.

이 중간 단위가 토큰이다. 토큰을 이해하면 LLM의 여러 현상이 설명된다. 같은 글자 수라도 언어에 따라 토큰 수가 달라지는 이유, 공백과 구두점이 모델 입력에서 무시되지 않는 이유, 긴 프롬프트가 비용과 지연 시간을 증가시키는 이유, 한국어·일본어·중국어 같은 비영어권 텍스트가 영어와 다른 token-to-character ratio를 보일 수 있는 이유가 여기에 있다.

초안의 핵심 방향은 타당하다. 토큰은 LLM 이전부터 쓰인 개념이고, 현대 LLM은 텍스트를 토큰 ID의 sequence로 바꾸어 계산한다. 보완해야 할 지점은 표현의 범위다. “토큰은 컴파일러에서 먼저 등장했고 NLP가 그대로 가져왔다”라고 단정하면 역사적 흐름이 단순화된다. 컴파일러의 lexical analysis와 자연어처리의 tokenization은 모두 연속된 문자열을 처리 가능한 단위로 나눈다는 공통 문제를 다루었고, 그 과정에서 token이라는 용어가 여러 계산 분야에서 널리 사용되었다고 정리하는 편이 안전하다.

또 하나의 보완점은 “LLM은 다음 토큰 예측을 한다”는 문장의 적용 범위다. 이 설명은 GPT류 autoregressive decoder-only 모델을 설명할 때 특히 적절하다. 모든 언어 모델이나 모든 Transformer 기반 모델을 같은 방식으로 묶으면 BERT류 masked language model, encoder-only 표현 모델, encoder-decoder 번역 모델의 차이가 흐려진다. 따라서 이 글은 주로 텍스트 기반 생성형 LLM의 tokenization을 중심으로 설명한다.

개념의 정의

토큰은 tokenizer가 입력 문자열을 시스템이 처리할 수 있도록 나눈 이산적 단위다. 여기서 “이산적”이라는 말은 연속된 문자열이 유한한 목록의 항목으로 바뀐다는 뜻이다. 신경망은 자연어 문장을 직접 계산하지 않는다. 먼저 문자열을 토큰으로 나누고, 각 토큰을 vocabulary 안의 ID에 대응시킨 다음, 그 ID를 embedding으로 바꿔 계산한다.

정의는 다음처럼 압축할 수 있다.

토큰은 tokenizer가 텍스트를 모델·알고리즘이 처리할 수 있도록 나눈 이산적 계산 단위다.

이 정의에는 세 가지 구분이 들어 있다.

첫째, 토큰은 단어와 일치하지 않을 수 있다. 영어 문장에서는 단어 하나가 토큰 하나처럼 보이는 경우가 있지만, 실제 tokenizer는 공백을 포함한 문자열, 구두점, 부분 단어, byte-level 조각을 토큰으로 삼을 수 있다.

둘째, 토큰은 형태소와도 다르다. 형태소(morpheme)는 언어학에서 의미나 문법 기능을 가진 최소 단위로 분석된다. 예를 들어 unhappiness는 un-, happy, -ness로 분석될 수 있다. 하지만 tokenizer는 인간 언어학자가 만든 형태소 분석기처럼 움직이지 않는다. 데이터에서 자주 함께 등장하는 문자 조합, 공백 패턴, byte sequence, vocabulary 크기 같은 계산 조건에 따라 경계를 만든다.

셋째, 토큰은 모델별로 달라진다. 같은 문장도 GPT 계열 tokenizer, WordPiece 기반 tokenizer, SentencePiece 기반 tokenizer, byte-level BPE tokenizer에서 다르게 나뉠 수 있다. 그러므로 “이 문장은 몇 토큰인가”라는 질문은 tokenizer와 모델을 함께 지정해야 답할 수 있다.

배경과 맥락

프로그래밍 언어 처리에서 token은 어휘 분석의 기본 단위다. Pearson의 『Compilers: Principles, Techniques, and Tools』 2판 목차도 lexical analysis, specification of tokens, recognition of tokens를 별도 주제로 다룬다. 컴파일러는 소스 코드를 문자 단위로만 처리하지 않고, 키워드, 식별자, 연산자, 숫자 리터럴, 구분자 같은 단위로 나눈다.

예를 들어 다음 코드를 보자.

int x = 10;

어휘 분석기는 대략 다음과 같은 단위를 식별한다.

int | x | = | 10 | ;

여기서 int는 키워드, x는 식별자, =는 대입 연산자, 10은 숫자 리터럴, ;는 구분자다. 이 단계가 있어야 parser는 이후 문법 구조를 만들 수 있다.

자연어처리에서도 비슷한 문제가 있다. 다음 문장은 사람에게 단어들이 모인 문장으로 보인다.

The cat sat on the mat.

프로그램은 먼저 경계를 찾아야 한다.

The | cat | sat | on | the | mat | .

영어는 공백이 단어 경계를 어느 정도 알려주기 때문에 단순해 보인다. 하지만 don't, New York, U.S.A., state-of-the-art, 이메일 주소, URL, 이모지, 숫자와 단위처럼 처리하기 어려운 사례가 많다. 한국어는 조사와 어미가 어절에 붙고, 일본어와 중국어는 공백으로 단어 경계를 나누기 어렵다. Jurafsky와 Martin의 『Speech and Language Processing』 3판 초안도 “Words and Tokens” 장에서 tokenization과 전처리를 NLP의 출발점으로 다룬다.

따라서 tokenization은 단순한 문자열 분리가 아니다. 그것은 언어의 표면 형태와 계산 시스템의 입력 요구를 맞추는 변환 과정이다.

초기 NLP와 단어 토큰

초기 자연어처리에서는 단어와 패턴이 중요한 처리 단위였다. Joseph Weizenbaum의 1966년 ELIZA 논문은 입력 문장을 keyword와 decomposition rule, reassembly rule에 따라 처리하는 초기 대화 시스템을 설명했다. ELIZA는 현대 LLM처럼 텍스트를 subword ID sequence로 바꾸는 시스템은 아니었지만, 입력 문장을 특정 단어와 패턴 중심으로 처리했다는 점에서 초기 언어처리의 계산적 관점을 보여준다.

전통적 NLP와 정보검색에서는 단어 토큰이 매우 유용했다. 문서를 단어 단위로 나누면 단어 빈도, 문서 빈도, 주변 단어, 품사, n-gram, 문서 간 유사도 같은 것을 계산할 수 있다. 예를 들어 다음 문장은 단어 단위로 쉽게 나뉜다.

The | cat | sat | on | the | mat | .

이 방식은 문서 분류, 검색, 품사 태깅, 통계적 언어 모델에서 효과적으로 사용되었다. 단어를 세고, 단어의 순서를 보고, 특정 단어가 어떤 문맥에서 자주 등장하는지 계산할 수 있기 때문이다.

하지만 단어는 생각보다 안정적인 단위가 아니다. 영어만 보아도 run, runs, running, ran은 같은 어휘적 뿌리를 공유하지만 표면형은 다르다. New York은 두 단어처럼 보이지만 하나의 고유명사로 처리해야 할 때가 많다. don't는 do와 not의 축약형이다. 하이픈, 아포스트로피, 대문자, 숫자, 단위, URL, 코드가 섞이면 경계 판단은 더 복잡해진다.

한국어에서는 문제가 더 커진다. 먹다, 먹었다, 먹었습니다, 먹겠습니까, 먹어버렸습니다는 어근, 시제, 높임, 양태, 종결어미가 결합하면서 여러 표면형을 만든다. 공백 기준으로 나눈 어절과 문법적 형태소가 일치하지 않으므로, 단어 전체를 vocabulary 항목으로 삼으면 어휘 수가 빠르게 증가한다.

단어 토큰의 한계

단어를 토큰으로 삼는 방식에는 세 가지 핵심 한계가 있다.

첫째, 희귀 단어와 미등록어 문제가 발생한다. 학습 데이터에 없던 단어가 등장하면 모델이나 시스템은 그 단어를 처리하기 어렵다. 전통적 NLP에서는 이를 OOV(out-of-vocabulary) 문제라고 불렀다. 고유명사, 의학 용어, 법률 용어, 신조어, 오타, 외국어 표기, 복합어는 OOV가 되기 쉽다.

둘째, 형태 변화가 많은 언어에서 vocabulary가 커진다. 영어도 파생어와 굴절형이 있지만, 한국어·터키어·핀란드어처럼 교착적 성격이 강한 언어에서는 어근 뒤에 여러 문법 요소가 결합하며 매우 많은 표면형이 생긴다. 단어 전체를 하나의 토큰으로 삼으면 비슷한 형태들이 별개의 항목으로 분산된다.

셋째, 단어 경계가 언어마다 다르다. 영어는 공백 기반 tokenization이 어느 정도 작동하지만, 중국어와 일본어에서는 공백이 단어 경계를 표시하지 않는다. 한국어는 공백이 있지만, 책을 같은 어절은 책과 조사 을의 결합이다. 공백을 기준으로만 나누면 문법 구조를 충분히 반영하지 못한다.

이 한계 때문에 NLP는 단어와 문자 사이의 중간 단위를 찾기 시작했다. 그 결과 부분 단어(subword) tokenization이 중요해졌다.

부분 단어 토큰과 BPE

부분 단어 토큰은 단어 전체를 하나의 토큰으로 삼지 않고, 더 작은 문자열 조각으로 표현하는 방식이다. 문자 단위 tokenization은 모든 단어를 표현할 수 있지만 sequence가 길어진다. 단어 단위 tokenization은 sequence가 짧지만 희귀 단어와 OOV에 약하다. subword tokenization은 이 둘 사이에서 표현력과 효율을 절충한다.

예를 들어 internationalization이라는 단어는 tokenizer에 따라 다음처럼 나뉠 수 있다.

international | ization

또는 다음처럼 더 잘게 나뉠 수 있다.

inter | national | ization

이 분해는 반드시 언어학적 형태소 분석과 일치하지 않는다. 실제 subword tokenizer는 학습 말뭉치에서 자주 등장하는 문자열 조합을 중심으로 vocabulary를 만든다. 자주 등장하는 단어는 긴 토큰으로 남을 수 있고, 드문 단어는 여러 조각으로 분해된다. 이 덕분에 처음 보는 단어도 이미 알고 있는 작은 단위들의 조합으로 표현할 수 있다.

BPE(Byte Pair Encoding)는 subword tokenization을 설명할 때 빠지지 않는 방법이다. BPE는 원래 Philip Gage가 1994년에 제안한 데이터 압축 알고리즘이다. 핵심 아이디어는 가장 자주 등장하는 인접 기호 쌍을 반복적으로 병합하는 것이다. 이후 Sennrich, Haddow, Birch의 2016년 ACL 논문 「Neural Machine Translation of Rare Words with Subword Units」는 신경망 기계번역에서 희귀 단어 문제를 완화하기 위해 BPE 기반 subword unit을 활용했다. 이 연구는 BPE가 NLP와 신경망 번역에서 중요한 tokenization 방법으로 자리 잡는 데 큰 영향을 주었다.

BPE의 장점은 간단하다. 자주 등장하는 문자열은 하나의 토큰으로 묶어 sequence를 줄이고, 드문 문자열은 작은 조각으로 분해해 표현 가능성을 유지한다. 예를 들어 매우 긴 의학 용어나 신조어가 등장해도 모델은 그것을 완전히 모르는 단어 하나로 처리하기보다, 이미 학습된 부분 문자열들의 조합으로 다룰 수 있다.

WordPiece와 SentencePiece

BPE와 함께 자주 언급되는 방식이 WordPiece다. WordPiece는 Google의 신경망 기계번역 시스템과 BERT 계열 모델에서 널리 알려졌다. Yonghui Wu 등은 2016년 「Google's Neural Machine Translation System: Bridging the Gap between Human and Machine Translation」에서 NMT 시스템이 rare words 처리에 어려움을 겪는다고 설명하고, common sub-word units, 곧 wordpieces를 활용한다고 밝혔다. 이 맥락에서 WordPiece는 단어 단위와 문자 단위의 절충으로 희귀어 문제를 줄이기 위한 방법으로 이해할 수 있다.

BPE와 WordPiece는 모두 subword vocabulary를 만든다는 점에서 비슷하지만, 병합 기준과 학습 절차는 다르다. BPE는 빈번한 인접 쌍을 반복적으로 병합하는 방식으로 설명되는 경우가 많고, WordPiece는 likelihood나 language-modeling 관점의 기준과 연결되어 설명되는 경우가 많다. 입문 수준에서는 두 방식 모두 “희귀 단어를 작은 단위로 분해하면서도 자주 등장하는 문자열은 큰 단위로 유지하려는 subword tokenization 계열”로 묶어 이해하면 충분하다.

SentencePiece는 Kudo와 Richardson의 2018년 EMNLP System Demonstrations 논문에서 제안된 언어 독립적 subword tokenizer이자 detokenizer다. 이 논문은 기존 subword segmentation 도구들이 pre-tokenized word sequence를 가정하는 경우가 많았던 반면, SentencePiece는 raw sentence에서 직접 subword model을 학습할 수 있다고 설명한다. 이 점은 공백 기반 단어 경계가 분명하지 않은 언어를 처리할 때 특히 중요하다.

SentencePiece의 의의는 “단어를 먼저 나눈 뒤 subword를 만든다”는 절차에 덜 의존한다는 데 있다. 영어처럼 공백이 단어 경계를 알려주는 언어에서는 pre-tokenization이 상대적으로 자연스럽지만, 일본어·중국어처럼 공백이 없는 언어 또는 한국어처럼 어절과 형태소가 어긋나는 언어에서는 원문에서 직접 subword model을 학습하는 접근이 장점을 가진다.

Transformer와 LLM에서 토큰이 작동하는 방식

Transformer는 2017년 Vaswani 등 「Attention Is All You Need」에서 제안된 구조다. 이 논문은 recurrence와 convolution에 의존하지 않고 attention mechanism에 기반한 architecture를 제시했다. Transformer가 tokenization을 발명한 것은 아니다. Transformer의 핵심은 sequence 안의 위치들이 self-attention을 통해 서로의 관계를 계산한다는 데 있다. 다만 Transformer 기반 언어 모델이 텍스트를 처리하려면 텍스트를 먼저 token sequence로 바꾸어야 한다.

현대 텍스트 기반 LLM의 입력 과정은 대략 다음과 같다.

원문 텍스트
↓
tokenizer
↓
토큰 문자열 또는 토큰 조각
↓
토큰 ID
↓
embedding vector
↓
Transformer layers
↓
출력 토큰 확률분포

예를 들어 다음 문장이 있다고 하자.

나는 오늘 책을 읽었다.

실제 tokenizer는 모델별 vocabulary에 따라 이 문장을 여러 토큰으로 나누고, 각 토큰에 정수 ID를 부여한다.

[토큰 1, 토큰 2, 토큰 3, ...]
↓
[14521, 921, 5510, 8332, ...]

위 숫자는 설명을 위한 예시이며, 실제 ID는 tokenizer와 모델에 따라 달라진다. 같은 문장도 GPT 계열 tokenizer, SentencePiece 기반 tokenizer, WordPiece 기반 tokenizer, byte-level tokenizer에서 서로 다르게 나뉠 수 있다.

생성형 decoder-only LLM의 기본 구조를 단순화하면, 주어진 문맥에서 다음 토큰의 확률분포를 예측하는 과정이 중심에 있다. 다음 문맥을 보자.

The cat sat on the

모델은 mat, floor, chair, rug 같은 후보 토큰에 확률을 부여한다. 디코딩 전략에 따라 가장 확률이 높은 토큰을 고를 수도 있고, 확률분포에서 무작위성을 포함해 선택할 수도 있다. Greedy decoding, beam search, top-k sampling, nucleus sampling 같은 방식은 모두 이 확률분포를 어떻게 사용할 것인가에 관한 전략이다.

이 설명은 생성형 GPT류 모델을 이해하는 데 유용하다. 반면 BERT 같은 masked language model은 입력 일부를 가리고 그 위치의 토큰을 예측하는 방식으로 학습된다. encoder-decoder 번역 모델은 입력 sequence를 encoder가 표현하고 decoder가 출력 sequence를 생성한다. 모두 token을 사용하지만, 학습 목표와 계산 흐름은 다르다.

tiktoken 예시가 보여주는 것

OpenAI Cookbook의 「How to count tokens with Tiktoken」은 tiktoken is great!라는 문자열이 tokenizer에 의해 여러 토큰으로 나뉠 수 있음을 보여준다. 해당 문서는 예시로 t, ik, token, is, great, ! 같은 분해를 제시한다. 여기서 핵심은 두 가지다.

첫째, 공백이 토큰의 일부가 될 수 있다. 사람에게 공백은 단어 사이의 빈칸이지만, tokenizer에게 공백은 문자열 패턴의 일부다. is와 is는 서로 다른 토큰으로 취급될 수 있다.

둘째, 인코딩이 달라지면 분해도 달라질 수 있다. 같은 Cookbook 페이지의 비교 예시는 o200k_base, cl100k_base 같은 encoding에 따라 token integer와 token bytes가 달라질 수 있음을 보여준다. 따라서 tiktoken is great! 예시는 “항상 이 문자열은 반드시 이 방식으로만 나뉜다”는 뜻보다, “tokenizer는 텍스트를 사람이 직관적으로 예상하는 단어 경계와 다르게 나눌 수 있다”는 교육적 사례로 이해해야 한다.

이 Cookbook 문서는 archived 상태이며 오래된 모델이나 API를 언급할 수 있다고 표시한다. 그러므로 최신 모델별 encoding과 token count의 정확한 기준은 항상 해당 시점의 공식 모델 문서와 API 응답 metadata를 확인해야 한다. 예시는 개념 설명에는 유용하지만, 최신 운영 기준의 근거로는 제한적으로 사용해야 한다.

왜 LLM의 주요 제약은 토큰 수와 연결되는가

LLM에서 token은 단순한 전처리 단위가 아니라 시스템 운영의 기본 단위다. 컨텍스트 길이, 입력·출력 비용, 출력 제한, 지연 시간, 메모리 사용량은 모두 토큰 수와 밀접하게 연결된다.

컨텍스트 길이는 모델이 한 번에 처리할 수 있는 토큰 수를 뜻한다. 예를 들어 128k context라고 하면 입력과 출력, 시스템 메시지, 대화 기록, 도구 호출 구조 등을 합쳐 대략 128,000개 수준의 토큰을 다룰 수 있다는 의미다. 이것은 문자 수나 단어 수와 같지 않다. OpenAI Help Center도 토큰이 한 글자만큼 짧거나 한 단어만큼 길 수 있고, 비영어 텍스트가 더 높은 token-to-character ratio를 가질 수 있다고 설명한다.

비용도 토큰 단위로 계산되는 경우가 많다. 입력 프롬프트가 길수록 input token이 늘어나고, 출력이 길수록 output token이 늘어난다. OpenAI Help Center는 token usage가 input tokens, output tokens, cached tokens, reasoning tokens 등으로 추적될 수 있으며, 과금과 사용량 계산에 쓰인다고 설명한다.

출력 제한도 토큰과 연결된다. OpenAI의 응답 길이 제어 문서는 token cap이 비용 관리, latency/performance, 관련성 유지에 도움이 된다고 설명한다. Responses API에서는 max_output_tokens, Chat Completions API에서는 모델에 따라 max_completion_tokens 또는 max_tokens 같은 매개변수가 쓰일 수 있다. 이 구체적 명칭은 API와 모델 세대에 따라 달라질 수 있으므로, 최신 모델별 제한은 공식 모델 문서를 확인해야 한다.

속도와 메모리도 토큰 수의 영향을 받는다. Transformer는 sequence 안의 토큰들 사이 관계를 계산하고, 생성 단계에서는 이전 토큰들의 key-value cache를 유지한다. 입력이 길어지고 출력이 길어질수록 계산 부담과 메모리 사용량이 증가한다.

다만 실제 속도와 메모리는 토큰 수 하나로만 결정되지 않는다. 모델 크기, attention 최적화 방식, batching, 하드웨어, 양자화, KV cache 관리, speculative decoding, 서빙 아키텍처가 함께 작용한다. 그래서 실무에서는 “토큰 수가 중요하다”와 “토큰 수만 보면 충분하다”를 구분해야 한다.

구체적 사례

영어 문장을 보자.

The cat sat on the mat.

전통적 단어 기반 tokenization에서는 다음처럼 나눌 수 있다.

The | cat | sat | on | the | mat | .

하지만 LLM tokenizer는 공백을 다음 단어 앞에 붙여 cat, sat처럼 처리하거나, 구두점을 별도 토큰으로 두거나, 자주 등장하는 문자열을 하나의 토큰으로 유지할 수 있다. 이 때문에 사용자가 보는 단어 수와 모델이 보는 토큰 수가 어긋난다.

한국어 문장을 보자.

나는 오늘 책을 읽었다.

공백 기준으로 나누면 다음과 같다.

나는 | 오늘 | 책을 | 읽었다 | .

형태소에 가깝게 보면 다음처럼 분석할 수도 있다.

나 | 는 | 오늘 | 책 | 을 | 읽 | 었 | 다 | .

LLM tokenizer는 이 둘 중 하나를 그대로 따르지 않을 수 있다. 나는이 하나의 토큰일 수도 있고, 나와 는으로 나뉠 수도 있으며, byte-level 조각으로 더 작게 분해될 수도 있다. 모델별 tokenizer가 다르면 같은 문장의 토큰 수와 경계도 달라진다.

코드에서는 토큰의 성격이 또 달라진다.

for i in range(10):
    print(i)

프로그래밍 언어 관점에서는 for, i, in, range, (, 10, ), :, print 같은 lexical token이 중요하다. LLM tokenizer는 여기에 공백, 줄바꿈, 들여쓰기, 괄호, 콜론, 숫자 등을 별도의 토큰 또는 부분 문자열로 처리할 수 있다. Python처럼 들여쓰기가 문법 구조에 직접 영향을 주는 언어에서는 공백과 줄바꿈이 단순한 장식이 아니라 프로그램 의미의 일부다.

주요 쟁점과 반론

첫 번째 쟁점은 토큰이 언어학적 단위인지 계산 단위인지에 관한 것이다. 언어학적으로 자연스러운 단위는 단어, 형태소, 음절, 문자 등으로 나눌 수 있다. LLM의 토큰은 언어학적 자연스러움과 계산 효율 사이의 절충물이다. 자주 등장하는 문자열은 긴 토큰이 되고, 드문 표현은 작은 토큰으로 분해된다. 따라서 LLM의 토큰을 형태소나 의미 단위로 곧장 해석하면 오류가 생긴다.

두 번째 쟁점은 subword tokenization이 희귀어 문제를 완전히 해결하는지에 관한 것이다. 부분 단어 방식은 OOV와 vocabulary 폭증 문제를 완화하지만, 모든 문제를 없애지는 않는다. 특정 언어에서는 토큰 수가 과도하게 늘어날 수 있고, byte-level tokenizer는 사용자가 직관적으로 이해하기 어려운 분해를 만들 수 있다. 언어별 토큰 효율 차이는 비용, 지연 시간, 긴 문서 처리에서 실제 차이를 만든다.

세 번째 쟁점은 “다음 토큰 예측”이라는 설명의 설명력이다. 이 표현은 생성형 decoder-only LLM의 기본 구조를 이해하는 데 매우 유용하다. 하지만 instruction tuning, RLHF, tool use, retrieval, multimodal input, system prompt, safety layer가 결합된 실제 AI 제품의 동작을 이 한 문장으로 모두 설명할 수는 없다. “다음 토큰 예측”은 기본 계산 구조를 설명하는 말이지, 사용자가 경험하는 전체 시스템의 사회적·제도적·제품적 동작을 모두 설명하는 말은 아니다.

오해와 한계

가장 흔한 오해는 토큰을 단어와 동일시하는 것이다. 영어의 짧은 예문에서는 단어 하나가 토큰 하나처럼 보일 수 있다. 그러나 실제 LLM에서는 하나의 단어가 여러 토큰으로 나뉘거나, 공백을 포함한 문자열이 하나의 토큰이 될 수 있다.

두 번째 오해는 토큰을 의미의 최소 단위로 보는 것이다. 토큰은 의미를 담을 수 있지만, 의미를 보장하지 않는다. 인간에게 의미 없어 보이는 문자열 조각도 모델에는 유용한 분포적 단서가 될 수 있고, 인간에게 의미 있는 단어도 모델 내부에서는 여러 토큰과 embedding의 조합으로 처리될 수 있다.

세 번째 오해는 tokenization을 사소한 전처리로 보는 것이다. 고전적 NLP에서는 전처리 단계처럼 보일 수 있었지만, LLM에서는 tokenizer가 vocabulary, embedding matrix, 학습 데이터 표현, 컨텍스트 길이, 비용, 다국어 성능에 직접 연결된다. 어떤 tokenizer를 쓰느냐에 따라 같은 텍스트가 더 짧게 또는 더 길게 표현되고, 특정 언어·도메인·코드 형식이 더 유리하거나 불리해질 수 있다.

이 설명에도 한계가 있다. 실제 상용 LLM의 tokenizer와 내부 처리 방식은 모델마다 다르며, 일부 세부 구현은 공개되지 않는다. 또한 multimodal 모델에서는 이미지, 음성, 비디오 입력도 내부적으로 discrete token 또는 embedding sequence로 변환될 수 있지만, 텍스트 tokenization과는 다른 처리 과정을 가진다. 이 글은 주로 텍스트 기반 NLP와 생성형 LLM의 tokenization을 설명한다.

정리

토큰은 인간 언어와 기계 계산 사이의 변환 단위다. 컴파일러에서는 소스 코드를 키워드, 식별자, 연산자 같은 어휘 단위로 나누기 위해 쓰였고, 자연어처리에서는 문장을 단어·형태소·문자·부분 단어 단위로 나누기 위해 쓰였다. 초기 NLP에서는 단어 토큰이 중심이었지만, 단어 기반 방식은 희귀 단어, 형태 변화, 언어 다양성 앞에서 한계를 드러냈다. 이를 보완하기 위해 BPE, WordPiece, SentencePiece 같은 subword tokenization 방식이 널리 사용되었다.

현대 생성형 LLM에서 텍스트는 토큰 ID 수열로 바뀌고, 토큰 ID는 embedding으로 변환되며, Transformer는 이 sequence를 바탕으로 출력 토큰의 확률분포를 계산한다. 그래서 컨텍스트 길이, 비용, 출력 제한, 지연 시간, 메모리 사용량 같은 주요 제약이 토큰 수와 연결된다.

한 문장으로 정리하면 다음과 같다.

토큰은 tokenizer가 텍스트를 모델이 계산할 수 있도록 나눈 이산적 처리 단위이며, 현대 생성형 LLM에서는 언어 표현이 숫자 수열과 확률 계산으로 들어가는 입구다.

참고자료

  • Alfred V. Aho, Monica S. Lam, Ravi Sethi, Jeffrey D. Ullman, Compilers: Principles, Techniques, and Tools, 2nd ed., Pearson/Addison-Wesley, 2007.
  • Pearson, “Compilers: Principles, Techniques, and Tools, 2nd edition”, Pearson Subject Catalog, 확인일 2026년 5월 6일.
  • Daniel Jurafsky, James H. Martin, Speech and Language Processing: An Introduction to Natural Language Processing, Computational Linguistics, and Speech Recognition with Language Models, 3rd ed. draft, online manuscript released January 6, 2026, 확인일 2026년 5월 6일.
  • Joseph Weizenbaum, “ELIZA—A Computer Program for the Study of Natural Language Communication between Man and Machine”, Communications of the ACM, 9(1), 1966.
  • Philip Gage, “A New Algorithm for Data Compression”, The C Users Journal, 1994.
  • Rico Sennrich, Barry Haddow, Alexandra Birch, “Neural Machine Translation of Rare Words with Subword Units”, Proceedings of the 54th Annual Meeting of the Association for Computational Linguistics, 2016.
  • Yonghui Wu, Mike Schuster, Zhifeng Chen 외, “Google's Neural Machine Translation System: Bridging the Gap between Human and Machine Translation”, arXiv:1609.08144, 2016.
  • Taku Kudo, John Richardson, “SentencePiece: A Simple and Language Independent Subword Tokenizer and Detokenizer for Neural Text Processing”, Proceedings of the 2018 Conference on Empirical Methods in Natural Language Processing: System Demonstrations, 2018.
  • Ashish Vaswani, Noam Shazeer, Niki Parmar, Jakob Uszkoreit, Llion Jones, Aidan N. Gomez, Łukasz Kaiser, Illia Polosukhin, “Attention Is All You Need”, Advances in Neural Information Processing Systems, 2017.
  • OpenAI, “What are tokens and how to count them?”, OpenAI Help Center, 확인일 2026년 5월 6일.
  • OpenAI, “How to count tokens with Tiktoken”, OpenAI Cookbook, 2022년 12월 16일 게시, archived recipe, 확인일 2026년 5월 6일.
  • OpenAI, “Controlling the length of OpenAI model responses”, OpenAI Help Center, 확인일 2026년 5월 6일.