토크나이저와 BPE — LLM이 글자가 아니라 토큰을 보는 이유

토크나이저(tokenizer)는 사람이 쓴 글자를 모델이 다루는 정수 ID의 나열, 즉 토큰으로 쪼개는 부품이다. LLM은 글자나 단어를 직접 보지 않는다. "안녕하세요"는 몇 개의 토큰 ID로 변환된 뒤에야 모델에 들어간다. 이 쪼개는 규칙 중 가장 널리 쓰이는 것이 BPE(Byte Pair Encoding)다. 자주 붙어 다니는 바이트 쌍을 반복해서 하나로 합치며 어휘를 키우는, 놀랄 만큼 단순한 알고리즘이다.

토크나이저는 평소엔 안 보이다가 꼭 이상한 곳에서 발목을 잡는다. 나도 "왜 한국어는 영어보다 토큰을 훨씬 많이 먹지?", "왜 이 모델은 숫자 계산을 자꾸 틀리지?" 같은 의문의 뿌리가 결국 토크나이저였다는 걸 뒤늦게 알았다.

왜 글자도 단어도 아닌 '서브워드'인가

선택지는 셋이다. 글자 단위는 어휘가 작지만 시퀀스가 너무 길어진다. 단어 단위는 짧지만 처음 보는 단어(신조어·오타)를 통째로 모르는 토큰으로 처리해 버린다. 그 사이의 절충이 서브워드(subword)다. 흔한 단어는 한 토큰으로, 드문 단어는 몇 조각으로 나눠서 표현한다. 덕분에 어휘 크기는 적당하고, 모르는 단어도 조각으로 조립할 수 있다.

BPE는 이 서브워드 어휘를 데이터로부터 배운다. 처음엔 모든 걸 바이트(또는 글자) 단위로 두고, 코퍼스에서 가장 자주 인접하는 쌍을 찾아 하나로 병합한다. 이걸 원하는 어휘 크기가 될 때까지 반복한다. 병합 규칙의 순서가 곧 토크나이저의 사전이 된다.

# BPE 학습의 뼈대 (개념용)
vocab = 모든 글자/바이트
while len(vocab) < target:
    pairs = 코퍼스에서 인접한 심볼 쌍의 빈도 집계
    best = 가장 빈번한 쌍            # 예: ("l","o")
    코퍼스에서 best를 하나의 심볼로 병합  # "lo"
    vocab.add(merge(best))
# 추론 시엔 학습된 병합 규칙을 순서대로 적용해 텍스트를 토큰화

바이트 단위 BPE의 영리함

요즘 LLM은 대개 바이트 단위 BPE를 쓴다. 유니코드 문자가 아니라 UTF-8 바이트에서 출발한다는 뜻이다. 왜 이게 좋냐면, 세상의 어떤 문자·이모지·깨진 입력이 와도 최악의 경우 바이트로는 반드시 표현되므로 "완전히 모르는 글자"라는 사고가 안 난다. 어휘에 모든 문자를 넣지 않아도 커버리지가 100%다.

대신 대가가 있다. 학습 코퍼스에서 드문 언어는 병합이 덜 일어나, 한 글자가 여러 바이트 토큰으로 흩어진다. 한국어가 영어보다 토큰을 많이 먹는 근본 이유가 이것이다. 같은 의미의 문장이라도 토큰 수가 많으면 비용도 더 들고, 실효 컨텍스트도 그만큼 빨리 찬다.

토큰화가 일으키는 실전 함정

몇 번 데인 뒤에야 챙기게 된 것들이다. 숫자를 제각각으로 쪼개는 토크나이저는 자릿수 계산에서 실수를 유발한다. 문자열을 정확히 세거나 뒤집는 작업이 유독 약한 것도, 모델이 글자가 아니라 토큰 덩어리로 보기 때문이다. 프롬프트에 공백 하나, 줄바꿈 하나가 토큰 경계를 바꿔 결과가 미묘하게 달라지기도 한다.

토큰은 모델이 세상을 보는 최소 단위다. 비용, 컨텍스트 한도, 심지어 계산 실수까지 — 겉보기와 다른 많은 현상이 이 경계선에서 시작된다.

그래서 나는 다국어나 비용이 민감한 서비스를 만들 땐, 실제 예상 입력을 그 모델의 토크나이저로 돌려 토큰 수를 먼저 재보는 습관을 들였다. 글자 수로 어림하면 한국어에서 크게 빗나간다.

자주 묻는 질문

왜 한국어는 영어보다 토큰을 더 많이 먹나요?

대부분의 LLM 토크나이저가 영어 중심 코퍼스로 학습돼, 한국어는 병합이 덜 일어나기 때문이다. 그 결과 한 글자가 여러 바이트 토큰으로 쪼개지는 경우가 많다. 같은 의미라도 토큰 수가 늘어 비용과 컨텍스트 소모가 커지므로, 다국어 서비스라면 반드시 실제 토큰 수를 측정해 보는 게 좋다.

BPE와 WordPiece, Unigram은 뭐가 다른가요?

모두 서브워드 방식이지만 어휘를 만드는 기준이 다르다. BPE는 빈도가 높은 쌍을 탐욕적으로 병합하고, WordPiece는 병합이 언어모델 우도를 얼마나 높이는지를 기준으로 삼으며, Unigram은 큰 어휘에서 확률적으로 덜 쓸모 있는 토큰을 걷어내며 줄여 간다. 실무 감각으로는 셋 다 "자주 쓰는 조각은 한 토큰, 드문 것은 여러 조각"이라는 결이 비슷하다.

토큰 수를 미리 정확히 알 수 있나요?

있다. 각 모델 제공사는 해당 모델과 동일한 토크나이저를 제공하므로, 그걸로 실제 입력을 인코딩해 길이를 세면 정확하다. 글자 수나 단어 수로 환산하는 어림은 언어에 따라 크게 빗나가니, 비용·컨텍스트 관리가 중요하면 실제 토크나이저로 재는 편이 안전하다.

모델이 숫자 계산을 자꾸 틀리는 것도 토크나이저 탓인가요?

일부 영향이 있다. 숫자를 일관되지 않게 쪼개는 토크나이저에서는 자릿수 정렬이 어려워 산술 실수가 늘 수 있다. 최근 모델들은 숫자를 자릿수 단위로 쪼개는 등 토큰화를 개선해 이 문제를 완화하지만, 근본적으로 정확한 계산이 중요하면 코드 실행 같은 도구를 붙이는 편이 안전하다.