토크나이저

토크나이저(Tokenizer)는 텍스트를 LLM이 처리할 수 있는 최소 단위인 토큰(token)으로 분할하는 알고리즘입니다. 단어 전체가 하나의 토큰이 될 수도 있고, 단어 일부나 특수문자 하나가 토큰이 될 수도 있습니다.

대표적인 토크나이저 방식으로는 BPE(Byte Pair Encoding), WordPiece, SentencePiece 등이 있습니다. GPT 계열은 BPE 기반의 tiktoken을 사용하고, BERT 계열은 WordPiece를 씁니다. 한국어는 영어보다 토큰 수가 더 많이 소비되는 경향이 있습니다. 예를 들어 영어 'hello'는 1토큰이지만, '안녕하세요'는 여러 토큰으로 분할될 수 있습니다. API 비용은 입출력 토큰 수에 비례하므로, 토크나이저 이해는 비용 최적화에도 중요합니다.

컨텍스트 윈도우도 토큰 단위로 측정됩니다. Claude Opus 4.6는 약 100만 토큰, GPT-5.4는 약 105만 토큰, Llama 4는 최대 1,000만 토큰의 컨텍스트를 지원합니다. OpenAI의 Tokenizer 도구나 tiktoken 라이브러리를 사용하면 텍스트가 몇 토큰인지 직접 확인할 수 있습니다.

토크나이저가 언어마다 다른 결과를 내는 이유를 이해하면 비용을 더 잘 예측할 수 있습니다. 영어는 로마자 기반으로 이미 단어 단위가 명확하고, 자주 쓰이는 단어들이 단일 토큰으로 등록되어 있습니다. 하지만 한국어, 일본어, 중국어 같은 언어는 문자 하나가 여러 바이트로 구성되어 있고, 단어 경계가 명확하지 않아 같은 의미를 표현해도 영어보다 훨씬 많은 토큰을 사용합니다. 한국어 콘텐츠를 많이 처리하는 서비스라면 이 '토큰 비효율'을 미리 고려해야 합니다.

BPE 방식이 어떻게 작동하는지 간단히 살펴보면, 처음에는 모든 문자를 개별 토큰으로 시작합니다. 그 다음 훈련 데이터에서 가장 자주 함께 등장하는 문자 쌍을 찾아 하나의 새로운 토큰으로 합칩니다. 이 과정을 반복하면서 어휘 사전(vocabulary)을 구축합니다. 결국 자주 쓰이는 단어나 접미사는 단일 토큰이 되고, 드문 단어는 여러 토큰의 조합으로 표현됩니다. WordPiece는 BPE와 유사하지만 빈도 대신 우도(likelihood)를 기준으로 병합을 결정하며, Google의 BERT에서 사용합니다.

토크나이저는 모델 간 호환성에도 영향을 줍니다. A 모델로 토큰화한 텍스트를 B 모델에 그대로 입력할 수 없습니다. 각 모델은 자체 토크나이저와 어휘 사전을 가지고 있기 때문에, 같은 텍스트도 모델마다 다른 토큰 수로 계산됩니다. 그래서 모델을 교체할 때는 반드시 토큰 수 변화를 다시 측정해야 합니다. 같은 프롬프트가 모델에 따라 20~40% 더 많은 토큰을 소비할 수 있고, 이는 예상치 못한 비용 증가로 이어집니다.

실용적인 팁으로, 토크나이저를 직접 활용하면 프롬프트 최적화가 가능합니다. tiktoken 라이브러리를 파이썬에서 임포트하면 Claude나 GPT 모델의 토큰 수를 정확히 계산할 수 있습니다. 대량의 문서를 처리하는 파이프라인을 구축할 때 미리 토큰 수를 계산하여 컨텍스트 윈도우 초과를 방지하고 비용을 예측합니다. 또한 특수문자, 줄바꿈, 공백이 예상보다 많은 토큰을 소비하는 경우가 많으므로, 이런 요소를 정리하는 것만으로도 토큰을 절약할 수 있습니다.

토크나이저는 프롬프트 설계에도 직접 영향을 줍니다. 예를 들어 숫자, 날짜, 코드, 특수문자가 많이 포함된 텍스트는 일반 문장보다 토큰 수가 훨씬 많이 나올 수 있습니다. 'print("Hello, World!")'처럼 짧아 보이는 코드 한 줄도 괄호, 따옴표, 쉼표가 각각 토큰으로 분리되면 10개 이상의 토큰이 될 수 있습니다. 코드 생성이나 데이터 분석 서비스를 만들 때는 이 특성을 고려하여 비용을 예측해야 합니다.

토크나이저의 어휘 사전 크기도 모델 성능에 영향을 줍니다. 어휘 사전이 클수록 더 많은 단어와 구문을 단일 토큰으로 표현할 수 있어 효율적이지만, 모델의 임베딩 레이어 크기가 커져 메모리와 연산 비용이 늘어납니다. GPT-4는 약 10만 개의 토큰 어휘를 가지고 있으며, 이 크기는 다국어 지원과 효율성 사이의 균형을 고려하여 설계된 결과입니다. 한국어나 아랍어처럼 문자 체계가 복잡한 언어는 더 큰 어휘 사전이 필요하며, 이것이 다국어 모델이 영어 전용 모델보다 같은 텍스트에서 더 많은 토큰을 소비하는 이유 중 하나입니다.

개발자가 토크나이저를 직접 사용해야 하는 실용적인 상황이 있습니다. 긴 문서를 모델에 입력할 때 컨텍스트 윈도우를 초과하지 않도록 청크(Chunk) 분할을 해야 합니다. 이때 문자 수 기준이 아닌 토큰 수 기준으로 분할해야 정확합니다. 문자 수와 토큰 수가 항상 비례하지 않기 때문입니다. RAG(Retrieval-Augmented Generation) 시스템을 구축할 때 문서를 청크로 나누는 단계에서 토크나이저를 직접 호출하여 각 청크가 원하는 토큰 범위 안에 들어오는지 확인하는 것이 안정적인 파이프라인을 만드는 핵심 작업입니다.