P6-2.5 보충학습: 운영 관찰값으로 드러나는 토크나이저 계열 차이¶

Section ID: P6-2.5 Version: v2026.07.24

BPE, WordPiece, SentencePiece는 외워야 할 이름 목록이 아닙니다. 같은 문자열도 어떤 토크나이저(tokenizer)를 쓰는지에 따라 조각 경계, 토큰 수, 공백 처리, 희귀 표현 처리가 달라집니다. 이 차이는 곧 비용 예측, 검색 청크, 긴 문서 입력, 혼합 표기 문서의 길이 감각으로 이어집니다.

이 보충학습의 중심은 세 계열의 세부 알고리즘을 모두 외우는 데 있지 않습니다. 계열 이름을 문자열을 자르는 기준으로 읽고, 그 기준 차이가 비용, 청크, 혼합 표기 길이 예측에서 언제 드러나는지 보는 데 있습니다.

계열 이름은 절단 기준을 가리킨다¶

토큰화가 비용과 청크를 바꾼다면, 다음 질문은 왜 모델마다 문자열이 잘리는 감각이 조금씩 다른가입니다. 이 차이를 읽을 때 가장 자주 만나는 이름이 BPE, WordPiece, SentencePiece입니다.

세 이름을 외우기보다, 문자열을 어떤 기준으로 조각내는가가 어디서 갈리는지부터 붙잡습니다. 그래야 길이 감각, 희귀 단어 처리, 공백 해석 차이를 같은 축으로 읽을 수 있습니다.

토크나이저 계열이라는 말은 무엇인가¶

토크나이저(tokenizer)는 텍스트를 모델 계산 단위로 바꾸는 규칙 묶음입니다. 여기에는 보통 두 가지가 함께 붙습니다.

• 어떤 조각을 자주 쓰는가를 정한 조각 사전(vocabulary)
• 원문 문자열을 그 조각들로 어떻게 나눌지 정한 분절 규칙

BPE, WordPiece, SentencePiece는 바로 이런 토크나이저를 만드는 대표 계열 이름입니다.

토큰 경계가 갈리는 기준¶

같은 문장도:

• 어떤 표현을 하나의 조각으로 볼지
• 공백을 얼마나 강하게 믿을지
• 드문 단어를 몇 조각으로 나눌지

이 기준이 달라지면 토큰 수, 길이 감각, 청크 경계도 함께 달라집니다. 그래서 모델 카드나 강의에서는 이 모델은 어떤 토크나이저 계열을 쓰는가를 따로 밝히는 경우가 많습니다.

flowchart TD
  A["모델 카드 / 강의에서<br/>토크나이저 이름을 봄"]
  B["무엇의 이름인가?<br/>대표 토크나이저 계열"]
  C["어떻게 자를까?<br/>분절 방식 힌트"]
  D["어디서 달라질까?<br/>토큰 수 / 청크 경계"]
  E["뒤에서 다시 볼 판단<br/>비용 / 검색 / 길이 관리"]

  A --> B
  B --> C
  C --> D
  D --> E

이 도식은 토크나이저 이름이 토큰 경계, 길이 감각, 공백 해석 차이와 연결된다는 점만 짧게 묶어 보여 줍니다.

셋의 공통점은 무엇인가¶

BPE, WordPiece, SentencePiece의 공통점은 모두 텍스트를 계산하기 좋은 subword 조각으로 바꾸려는 계열이라는 점입니다. 차이는 무엇을 더 자주 붙여 볼 것인가, 어떤 조각 사전이 문자열을 더 잘 설명하는가, 공백을 경계로 고정해도 되는가 같은 절단 기준에서 드러납니다.

따라서 세 이름을 볼 때는 서로 완전히 다른 목적을 가진 기술로 외우기보다, 같은 목표를 두고 조각을 만들고 고르는 기준이 다르다고 읽는 편이 좋습니다.

계열별 절단 기준¶

BPE(Byte Pair Encoding)¶

BPE는 아주 작은 조각에서 시작해, 자주 함께 붙어 나오는 조각 쌍(pair)을 반복해서 더 큰 조각으로 합치는 감각으로 읽습니다.

처음에는 글자나 바이트처럼 더 작은 단위에서 시작하고, 학습 말뭉치(corpus)에서 자주 같이 나타나는 조합을 계속 합치면서 th, ing, token 같은 더 큰 조각을 만들어 갑니다. 여기서 말뭉치는 학습이나 분석에 쓰려고 모아 둔 텍스트 묶음입니다. 그래서 BPE를 처음 읽을 때는 처음부터 단어를 안다기보다 자주 같이 나오는 조각을 점점 굳힌다는 쪽이 더 가깝습니다.

처음 읽을 때는 다음처럼 붙잡습니다.

• 시작은 더 작은 조각에서 한다.
• 자주 같이 나오는 조각을 합쳐 더 큰 조각을 만든다.
• 드문 단어도 아예 못 읽기보다 여러 조각으로 나누어 읽게 만든다.

예를 들어 tokenization이라는 문자열이 자주 나온다면, 처음에는 더 잘게 쪼개 읽다가 점점 token, ization 같은 자주 쓰는 조각이 더 큰 단위로 굳어질 수 있습니다. 여기서 중요한 것은 사전 단어를 먼저 외운다가 아니라 자주 반복되는 조각을 점점 키운다는 점입니다.

WordPiece¶

WordPiece는 어떤 조각 사전을 고르면 문장을 더 효율적으로 설명할 수 있을까를 더 강하게 의식하는 계열로 보면 됩니다. BPE와 비슷하게 subword 조각을 쓰지만, 단순히 자주 붙는 쌍을 합치는 감각보다 이 조각 사전이 전체 문장을 얼마나 잘 설명하나를 더 의식한다고 읽으면 됩니다.

처음 비교할 때는 다음 구분이 특히 중요합니다.

• BPE도 조각을 키우지만, WordPiece는 어떤 조각을 사전에 넣는 편이 좋은가를 더 직접 문제로 삼는다.
• 단어 전체가 사전에 없더라도 더 작은 subword 조각으로 나누어 읽는다.
• BERT 계열 설명에서 자주 함께 나오는 subword, longest match, [UNK] 같은 표현과 묶여 등장한다.

예를 들어 unhappiness 같은 표현이 통째로 사전에 없더라도, un, happi, ness처럼 이미 있는 조각들로 나누어 읽을 수 있습니다. 이때 붙잡아야 할 핵심은 모르는 단어를 바로 버리는가가 아니라 이미 아는 조각들로 최대한 설명하려 하는가입니다.

WordPiece를 볼 때 자주 나오는 longest match 감각도 여기서 이해할 수 있습니다. 문자열을 왼쪽부터 읽으며 현재 사전에 있는 더 긴 조각이 있으면 그것을 우선 쓰는 쪽으로 읽는다는 뜻입니다. 그래서 BERT uses WordPiece라는 말은 단순 고유명사가 아니라, BERT는 단어를 더 작은 의미 조각으로 잘라 읽는 규칙을 갖는다는 설명으로 받아들이는 편이 좋습니다.

SentencePiece¶

SentencePiece는 공백이 이미 완벽한 단어 경계라고 가정하지 않고, 공백까지 포함한 문자열 자체를 더 직접 다루는 쪽으로 읽습니다. 그래서 영어처럼 공백이 익숙한 언어만이 아니라, 공백 기준이 덜 안정적이거나 언어가 섞인 환경에서도 비교적 일관된 방식으로 다루기 좋다는 설명이 자주 붙습니다.

SentencePiece를 처음 볼 때 먼저 봐야 할 점은 다음입니다.

• 공백이 있다고 해서 그 경계를 절대 기준으로 믿지 않는다.
• 문자열 전체를 대상으로 조각을 만든다.
• 언어마다 단어 경계 감각이 다른 문제를 더 직접 다루려는 쪽에 가깝다.

예를 들어 한국어, 영어, 숫자, 기호가 섞인 문장을 다룰 때 사람은 눈으로 공백을 먼저 보지만, SentencePiece 계열 설명에서는 공백도 문자열의 일부로 보고 어떤 조각이 반복해서 유용한가를 다시 정합니다. 그래서 this model uses SentencePiece라는 한 줄은 이 모델이 공백을 절대 기준으로 삼지 않을 수 있다는 단서이기도 합니다.

셋을 아주 단순하게 비교하면¶

이 표는 엄밀한 알고리즘 차이를 다 외우라는 뜻이 아닙니다. 먼저 잡아야 할 것은 세 이름이 모두 subword 계열인데, 무엇을 더 강하게 의식하느냐가 조금씩 다르다는 기준입니다.

토크나이저 계열을 읽을 때의 오해¶

1. 셋이 완전히 다른 목적을 가진다고 보는 경우¶

세 이름은 목적이 완전히 다른 별개 장치가 아닙니다. 모두 희귀 단어를 포함한 문자열을 계산 가능한 조각으로 안정적으로 바꾸려는 계열입니다. 차이는 목적보다 조각을 만들고 고르는 감각에 있습니다.

2. 모르는 단어는 바로 읽지 못한다고 보는 경우¶

이 계열들이 중요한 이유 중 하나는 통째로 모르는 단어가 나와도 더 작은 조각으로 다시 나눠 읽을 수 있게 해 준다는 점입니다. 사전에 없는 단어면 끝 아닌가라고 느끼는 지점이 바로 subword 계열이 등장한 이유와 연결됩니다.

3. 이름 암기가 핵심이라고 보는 경우¶

중요한 것은 이름 암기가 아닙니다. 이 모델은 어떤 단위로 문자열을 읽을까, 공백을 얼마나 믿을까, 희귀 표현을 어떻게 쪼갤까를 떠올릴 수 있어야 합니다.

이 구분이 실제 판단에 쓰이는 이유¶

대표 토크나이저 계열은 세부 비교를 외우기 위해서가 아니라, LLM이 문자열을 읽는 방식을 해석하기 위해 필요합니다. 이 이름들을 모르면 아래 질문들이 서로 연결되지 않습니다.

• 왜 같은 뜻의 문장도 모델마다 토큰 수가 달라질 수 있는가
• 왜 어떤 모델은 공백 기준 단어 감각과 다르게 잘리는가
• 왜 희귀 단어, 혼합 표기, 긴 용어에서 길이 감각이 자주 빗나가는가

즉, 여기서 필요한 것은 고유명사 셋을 외우는 일이 아니라 모델이 문자열을 어떤 기준으로 자르는가를 읽는 기준을 갖는 일입니다.

이 구분을 배운 뒤에는 아래 기준으로 스스로 확인할 수 있어야 합니다.

계열별 절단 기준 사례 및 예시¶

사례 1. BPE를 반복 조각 기준으로 읽을 때¶

tokenization이라는 표현이 자주 보이는 말뭉치에서는 처음부터 단어 전체를 안다고 가정하지 않아도 됩니다. 더 작은 조각에서 시작해 token과 ization처럼 자주 붙어 나오는 조각이 점점 굳어질 수 있습니다.

이 사례에서 사람이 먼저 쓰기 쉬운 기준은 tokenization을 영어 단어 하나로 보는 것입니다. 그 기준의 한계는 토크나이저가 단어 사전을 그대로 따라가지 않는다는 데 있습니다. BPE라는 이름을 보면 이 문자열이 어떤 반복 조각에서 커졌는가를 먼저 물어야 합니다.

따라서 BPE 사례에서 닫아야 할 문장은 이것입니다. BPE는 이름 암기 대상이 아니라, 반복해서 붙는 작은 조각이 더 큰 계산 조각으로 굳는다는 절단 기준입니다.

사례 2. WordPiece를 사전 조각 기준으로 읽을 때¶

unhappiness처럼 통째로는 낯선 표현도 un, happi, ness 같은 subword 조각으로 설명할 수 있습니다. BERT 계열 설명에서 WordPiece, subword, longest match, [UNK]가 함께 나오는 이유도 여기에 있습니다.

이 사례에서 사람이 먼저 쓰기 쉬운 기준은 사전에 없는 단어면 모델이 읽지 못할 것이라는 판단입니다. 그 기준의 한계는 subword 계열이 단어 전체가 아니라 이미 가진 조각 사전으로 문자열을 설명하려 한다는 점을 놓친다는 데 있습니다. WordPiece라는 이름을 보면 어떤 조각을 사전에 넣어 두면 전체 문자열을 더 잘 설명하는가를 먼저 물어야 합니다.

따라서 WordPiece 사례에서 닫아야 할 문장은 이것입니다. WordPiece는 모르는 단어를 바로 포기한다는 뜻이 아니라, 이미 있는 subword 조각으로 문자열을 최대한 설명하려는 절단 기준입니다.

사례 3. SentencePiece를 공백 경계 기준으로 읽을 때¶

한국어 문장, 영어 제품명, 숫자, 기호가 섞인 입력에서는 공백만으로 단어 경계를 정하기 어렵습니다. SentencePiece 계열은 공백을 절대 경계로 믿기보다, 공백 표시까지 포함한 문자열 전체에서 반복되는 조각을 찾는 쪽으로 이해할 수 있습니다.

이 사례에서 사람이 먼저 쓰기 쉬운 기준은 공백이 단어 경계라는 판단입니다. 그 기준의 한계는 한국어, 영어 제품명, 숫자, 기호가 섞이면 공백만으로 안정적인 계산 조각을 정하기 어렵다는 데 있습니다. SentencePiece라는 이름을 보면 공백을 절대 경계로 믿어도 되는가를 먼저 물어야 합니다.

따라서 SentencePiece 사례에서 닫아야 할 문장은 이것입니다. SentencePiece는 단순히 다국어 모델에서 자주 보이는 이름이 아니라, 공백 경계를 얼마나 믿을지 다시 묻게 하는 절단 기준입니다.

입력 장면에서 갈리는 토큰화 기준¶

세 이름을 읽고도 자주 다시 막히는 지점은 그래서 지금 어떤 질문을 먼저 던져야 하는가입니다. 이때는 이름 자체보다, 현재 입력에서 무엇이 더 눈에 띄는 문제인지 먼저 고르는 편이 안전합니다.

이 표의 목적은 세 계열을 기계적으로 매칭하는 데 있지 않습니다. 모델 카드나 토크나이저 설명을 읽을 때 지금 내가 먼저 확인해야 하는 것이 반복 조각인가, 사전 조각 선택인가, 공백 경계 처리인가를 바로 고르게 만드는 데 있습니다.

토크나이저 계열 비교에서 달라지는 것¶

대표 토크나이저는 읽기만 해서는 감각이 잘 남지 않습니다. 직접 써 봐야 사람이 보는 단어와 모델이 읽는 조각이 어떻게 어긋나는지 바로 보입니다.

직접 사용해 보면 특히 다음 세 가지가 눈에 들어옵니다.

• 같은 뜻의 문장도 표현을 조금 바꾸면 조각 수가 달라질 수 있습니다.
• 공백, 기호, 숫자, 영문 혼합이 길이 감각을 크게 흔들 수 있습니다.
• 같은 문자열도 토크나이저 계열에 따라 조각 경계가 달라질 수 있습니다.

이 경험이 중요한 이유는 대표 계열 이름이 추상적인 고유명사로 남지 않고 실제 조각 경계 감각으로 바뀌기 때문입니다. 직접 한 번도 써 보지 않으면 독자는 토크나이저 계열이 다르다는 문장을 읽어도 여전히 단어와 글자 수 감각으로 되돌아가기 쉽습니다.

작은 비교에서 보이는 차이¶

대표 토크나이저를 깊게 다루기 전에, 아래처럼 아주 작은 비교만 해 봐도 조각 경계 차이가 보입니다.

1. 같은 뜻의 문장을 두세 개 준비합니다.
2. 숫자, 기호, 영문, 줄임말이 섞인 버전을 하나 만듭니다.
3. 각 문장이 몇 조각으로 나뉘는지 봅니다.
4. 어디서 조각 경계가 달라졌는지 확인합니다.

예를 들어 아래 같은 문장을 직접 비교해 볼 수 있습니다.

이 작은 실습의 목적은 어느 계열이 최고인가를 고르는 데 있지 않습니다. 먼저 필요한 것은 사람 눈에 비슷한 문장도 모델 쪽에서는 다르게 잘릴 수 있다는 감각을 자기 손으로 확인하는 일입니다.

선택 실행 예제: 같은 입력을 세 계열에 넣기¶

대표 토크나이저는 이름만 아는 것으로 끝내지 말고, 실행 환경이 준비됐을 때 실제로 한 번씩 써 보는 편이 좋습니다. 다만 이 예제는 패키지 설치만으로 항상 닫히는 기본 실행 예제가 아닙니다. transformers와 sentencepiece가 설치되어 있어도, 처음 실행하는 환경에서는 Hugging Face의 tokenizer 파일을 내려받아야 할 수 있습니다. 인터넷이 막혀 있거나 로컬 캐시에 파일이 없으면 AutoTokenizer.from_pretrained(...) 단계에서 멈출 수 있습니다.

따라서 이 절에서는 두 층위를 분리합니다. 아래 코드는 실제 tokenizer 출력을 직접 확인하는 선택 실행 예제입니다. 바로 실행하지 못하는 환경에서는 저장 관찰값 CSV p6-2-5-tokenizer-family-observations.csv와 이어지는 결과표를 먼저 읽습니다. CSV의 한 행은 입력 하나를 특정 tokenizer에 넣었을 때의 token count와 대표 조각을 뜻합니다.

예제의 목표는 세 가지입니다.

• BPE, WordPiece, SentencePiece를 실제 입력에서 한 번씩 써 본다.
• 같은 문자열도 계열에 따라 조각 경계와 토큰 수가 달라질 수 있음을 확인한다.
• 숫자, 영문, 기호, 혼합 표기가 길이 감각을 어떻게 흔드는지 직접 본다.

예시 모델은 다음처럼 잡을 수 있습니다.

직접 조작할 값은 samples 목록입니다. 한국어, 영어, 숫자, URL, 코드 조각을 넣어 보며 TOKEN COUNT와 TOKENS가 어디서 달라지는지 봅니다. 관찰 순서는 고정합니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

# BPE, WordPiece, SentencePiece tokenizer가 같은 입력 문자열을 어떤 token 조각과 ID로 나누는지 비교하는 예제입니다.
from transformers import AutoTokenizer

# 조작 변수: 여기에 문장을 추가하거나 표현을 바꾸면 토큰 조각과 토큰 수가 달라집니다.
samples = [
    "회의는 내일 열립니다.",
    "회의는 내일 10:00 AM에 열립니다.",
    "회의는 내일 10:00 AM, Zoom 링크 포함입니다.",
    "tokenization",
    "tokenization helps models read rare words",
]

tokenizers = {
    "BPE / gpt2": AutoTokenizer.from_pretrained("gpt2"),
    "WordPiece / bert-base-uncased": AutoTokenizer.from_pretrained("bert-base-uncased"),
    "SentencePiece / google/mt5-small": AutoTokenizer.from_pretrained("google/mt5-small"),
}

for name, tokenizer in tokenizers.items():
    print(f"\n=== {name} ===")
    for text in samples:
        pieces = tokenizer.tokenize(text)
        ids = tokenizer.convert_tokens_to_ids(pieces)
        print(f"\nTEXT: {text}")
        print("TOKENS:", pieces)
        print("TOKEN COUNT:", len(pieces))
        print("TOKEN IDS:", ids)

위 코드는 대표 tokenizer 사용법을 직접 확인하는 설명형 예제입니다. 동시에 samples 목록을 바꾸면 토큰 조각과 토큰 수가 달라지므로, 작은 실험으로도 확장할 수 있습니다. 정확한 토큰 문자열을 외울 필요는 없습니다. 대신 어느 입력 변화가 토큰 수를 크게 바꾸는가, 어느 계열에서 경계가 더 잘게 갈리는가, 공백과 기호가 어떤 조각으로 남는가를 질문과 해설로 함께 읽어야 합니다.

실행에 실패했다면 먼저 실패 원인을 구분합니다. transformers import가 실패하면 패키지 의존성 문제이고, from_pretrained()에서 멈추면 tokenizer 파일 다운로드나 로컬 캐시 문제입니다. 이 구분이 있어야 예제의 핵심을 설치 문제로 오해하지 않습니다. 여기서 배울 것은 다운로드 절차가 아니라, 같은 입력을 서로 다른 계열이 어떻게 다르게 조각내는가입니다.

특히 다음 두 비교는 꼭 해 보는 편이 좋습니다.

출력 조각과 토큰 수의 차이¶

위 예시 코드를 실행하면 다음과 같은 형태의 차이를 관찰할 수 있습니다. 아래 수치는 저장 관찰값 CSV와 같은 기준으로 정리한 예시입니다. 라이브러리와 tokenizer 파일 버전에 따라 세부 조각은 달라질 수 있으므로, 아래 표에서는 정확한 고정 정답보다 계열별 차이를 읽는 법을 봅니다.

숫자만 먼저 봐도 몇 가지가 바로 드러납니다.

• 같은 한국어 문장인데도 gpt2 BPE는 매우 잘게 쪼개졌습니다.
• bert-base-uncased WordPiece도 한국어를 세밀하게 나눴지만, 문장 앞부분을 [UNK]로 처리한 경우가 보였습니다.
• mt5-small SentencePiece는 회의, ▁내, ▁열, 립니다처럼 더 큰 조각을 유지했습니다.
• tokenization은 단어 하나처럼 보여도 세 계열 모두 하나의 단일 조각으로만 두지 않았습니다.
• 숫자와 영문이 섞인 뒤 세 계열 모두 토큰 수가 늘었지만, 늘어나는 폭은 서로 달랐습니다.

대표 조각만 보면 차이는 더 분명합니다.

영어 문장에서도 차이가 보였습니다. tokenization helps models read rare words는:

• BPE gpt2: token, ization, Ġhelps, Ġmodels, Ġread, Ġrare, Ġwords
• WordPiece bert-base-uncased: token, ##ization, helps, models, read, rare, words
• SentencePiece google/mt5-small: ▁, token, ization, ▁help, s, ▁models, ▁read, ▁rare, ▁words

즉, 영어 한 단어 하나를 보는 장면에서도 tokenization을 어떻게 가를지, 공백을 어떻게 표시할지, helps를 통째로 둘지 help와 s로 나눌지가 실제로 달라졌습니다.

이 결과에서 독자가 닫아야 할 판단은 이것입니다. 모델 카드나 tokenizer 설명에서 BPE, WordPiece, SentencePiece라는 이름을 보면, 이름 자체를 외우기보다 반복 조각, 사전 조각, 공백 포함 문자열 중 어떤 절단 기준을 떠올려야 하는지 확인해야 합니다.

이 예제의 핵심은 계열 이름을 실제 조각 경계로 바꿔 읽는 습관을 만드는 데 있습니다. 토큰화 종류 차이가 언제 드러나는지 볼 때도, 먼저 이 기준 차이를 떠올려야 합니다.

계열 이름을 실제 조각 경계로 읽었다면, 같은 관찰값을 비용, 청크, 길이 예측 문제로 다시 연결할 수 있어야 합니다.

차이가 운영 장면에서 보이는 순간¶

토크나이저 계열 이름을 안다고 해서 바로 충분하지는 않습니다. 실제로 중요한 것은 그 차이가 언제 보이기 시작하는가입니다.

이 절의 핵심은 어느 계열이 더 좋으냐를 먼저 묻지 않는 데 있습니다. 먼저 봐야 하는 것은 차이가 드러나는 장면입니다.

같은 뜻인데 비용 감각이 갈릴 때¶

사람은 환불 정책을 알려줘와 환불 관련 정책을 간단히 설명해 줘를 비슷한 질문으로 봅니다. 하지만 토크나이저에 따라 관련, 간단히, 설명해 같은 표현이 더 잘게 나뉘면 실제 토큰 수와 비용은 달라질 수 있습니다.

즉, 같은 뜻이라고 해서 같은 입력 비용이 보장되지는 않습니다.

위에서 실제로 토크나이저를 돌려 본 결과도 이 감각을 확인해 줍니다.

같은 일정 안내 장면이라도 숫자와 영문이 붙는 순간 세 계열 모두 토큰 수가 늘었고, 늘어나는 폭도 같지 않았습니다. 이 차이가 바로 같은 뜻인데 비용 감각이 달라질 수 있다는 말의 실제 모습입니다.

검색 청크가 어색하게 끊길 때¶

문단을 보기 좋게 나눈다고 해서 검색에 유리한 청크가 되는 것은 아닙니다. 핵심 조건과 예외 조항이 서로 다른 조각으로 찢어지면 검색 결과는 원칙만 가져오고 예외를 놓칠 수 있습니다.

이 장면에서는 공백 기준 문단보다 토큰 조각 경계가 더 중요해질 수 있습니다.

실제 조각 예시를 보면 왜 그런지 더 분명합니다.

• BPE gpt2는 한국어를 매우 잘게 쪼개는 경향이 있어, 사람이 한 덩어리로 보는 구절도 더 많은 조각으로 흩어질 수 있습니다.
• WordPiece bert-base-uncased는 한국어 일부를 [UNK]로 처리하면서 나머지를 subword로 잇는 방식이어서, 언어 혼합 구간에서 사람이 기대한 경계와 다르게 읽힐 수 있습니다.
• SentencePiece google/mt5-small는 회의, ▁내, ▁열, 립니다처럼 더 큰 조각을 유지해, 같은 문장도 비교적 큰 의미 단위가 남는 모습을 보였습니다.

여기서 핵심은 어느 계열이 무조건 낫다가 아닙니다. 청크를 자를 때 사람이 생각한 의미 단위와 실제 토큰 조각 단위가 얼마나 어긋나는지가 검색 품질을 흔든다는 점입니다.

혼합 표기 문서에서 길이 감각이 흔들릴 때¶

한국어 설명 문장 안에 영문 제품명, 버전 문자열, URL, 코드 조각이 함께 들어가면 사람 눈에는 짧은 문장처럼 보여도 실제 토큰 수는 빠르게 늘 수 있습니다.

이 장면에서는 겉보기 문장 길이보다 혼합 표기 밀도가 더 중요한 판단 기준이 됩니다.

위 예제의 세 번째 입력도 같은 장면을 잘 보여 줍니다.

같은 문장을 사람이 보면 숫자와 제품명이 조금 들어간 일정 안내 정도로 느낄 수 있습니다. 하지만 실제로는 10:00, AM, Zoom, 링크 같은 구간이 계열마다 다르게 잘리면서 토큰 수가 크게 벌어졌습니다. 혼합 표기 문서에서 길이 예측이 자주 빗나가는 이유가 바로 여기 있습니다.

같은 장면을 운영 메모처럼 다시 줄이면 다음과 같습니다.

아주 단순하게 그리면¶

flowchart TD
  A["같은 토크나이저 질문"]
  B["비슷한 요청<br/>토큰 수가 달라지는가?"]
  C["청크 경계<br/>핵심 조건이 붙어 있는가?"]
  D["이후 검색 / 비용<br/>다운스트림 동작이 달라지는가?"]

  A --> B
  A --> C
  B --> D
  C --> D

이 도식에서 확인해야 할 점은 토크나이저 차이가 이름 차이로만 끝나지 않는다는 것입니다. 같은 뜻의 문장도 자르는 방식이 달라지면 토큰 수, 청크 경계, 이후 검색과 비용 판단까지 함께 달라질 수 있습니다.

운영 장면에서 다시 보는 토큰화 차이¶

운영 장면 사례 및 예시¶

사례 1. 환불 질문 템플릿 세 개를 돌릴 때¶

환불 정책을 알려줘, 환불 관련 정책을 간단히 설명해 줘, 환불이 가능한 조건만 짧게 정리해 줘는 같은 의도처럼 보이지만, 토크나이저에 따라 조각 경계와 토큰 수가 다르게 늘 수 있습니다.

이 사례의 문제 장면은 같은 의도 요청을 템플릿으로 여러 번 보내는 상황입니다. 사람이 먼저 쓰는 기준은 뜻이 비슷하면 비용도 비슷할 것이라는 판단입니다. 그 기준의 한계는 표현이 조금 길어지거나 수식어가 붙을 때, 토크나이저 종류에 따라 조각 수가 서로 다르게 늘 수 있다는 점을 놓친다는 데 있습니다.

따라서 이 사례에서 닫아야 할 문장은 이것입니다. 토큰화 종류 차이는 이론 설명보다 먼저 같은 뜻의 요청인데 비용이 왜 다르게 잡히는가라는 장면에서 드러납니다.

사례 2. 정책 청크가 자꾸 어색하게 끊길 때¶

연차는 3일 전 신청과 긴급 병가는 사후 보고 가능을 같은 근거 묶음으로 남겨야 하는데, 토큰 조각과 청크 경계가 어긋나면 검색 결과는 원칙만 가져오고 중요한 예외를 놓칠 수 있습니다.

이 사례의 문제 장면은 문단 기준으로는 자연스럽게 보이는 정책 문서가 검색에서는 자주 틀리는 상황입니다. 사람이 먼저 쓰는 기준은 문단이 보기 좋게 나뉘었으니 청크도 괜찮을 것이라는 판단입니다. 그 기준의 한계는 청크가 실제로는 글자 수나 문단 수가 아니라 토큰 수와 토큰 경계 위에서 잘린다는 점을 놓친다는 데 있습니다.

따라서 이 사례에서 닫아야 할 문장은 이것입니다. 토큰화 종류 차이는 검색기가 틀렸다는 결과 뒤에서 필요한 의미 단위가 같은 토큰 묶음 안에 남았는가라는 청크 경계 문제로 드러납니다.

사례 3. 혼합 표기 문서에서 비용이 튈 때¶

SDK v2.1, Authorization, 긴 URL, 코드 조각이 섞인 문장은 겉보기보다 토큰 수가 더 빨리 늘 수 있습니다. 같은 문서라도 어떤 토크나이저는 이런 구간을 더 잘게 읽고, 다른 토크나이저는 더 큰 조각으로 남길 수 있습니다.

이 사례의 문제 장면은 문서가 길어 보이지 않는데 실제 입력 길이가 자주 튀는 상황입니다. 사람이 먼저 쓰는 기준은 짧은 문장 몇 줄이니 입력도 짧을 것이라는 판단입니다. 그 기준의 한계는 숫자, 버전 문자열, URL, 코드 조각, 대소문자 혼합이 tokenizer에게는 여러 조각으로 갈라질 수 있다는 점을 놓친다는 데 있습니다.

따라서 이 사례에서 닫아야 할 문장은 이것입니다. 토큰화 종류 차이는 평범한 문장보다 숫자·영문·기호·코드가 섞인 구간에서 길이 감각이 무너지는 방식으로 더 선명하게 드러납니다.

실패 장면에서 보이는 토큰화 차이¶

토큰화 종류 차이를 읽을 때 자주 하는 실수는, 세 계열 이름을 떠올린 뒤에도 정작 지금 문제를 어느 장면으로 읽어야 하는지 바로 못 고르는 일입니다. 이때는 어느 계열이 더 좋으냐보다 지금 어떤 실패가 먼저 보이는가를 먼저 고르는 편이 안전합니다.

이 표의 목적은 토크나이저 계열을 다시 설명하는 데 있지 않습니다. 실제 운영 장면을 봤을 때 지금 드러난 차이가 비용 문제인지, 청크 문제인지, 혼합 표기 길이 문제인지를 먼저 분기하게 만드는 데 있습니다.

여기서 닫을 판단은 분명합니다. 토큰화 종류 차이는 이름 차이가 아니라, 비용 차이, 청크 경계, 혼합 표기 길이 예측에서 실제로 드러나는 관찰값입니다.

연습: 관찰값을 실패 장면으로 분기하기¶

토큰화 종류 차이를 추상 비교로만 두지 말고, 같은 입력을 서로 다른 계열에 넣었을 때 어떤 차이가 생기는지 다시 확인해 봅니다.

위 예제 코드 결과를 바탕으로 세 장면을 직접 분기해 봅니다. 질문마다 먼저 스스로 답한 뒤, 바로 아래 해설과 비교합니다.

연습 1. 비용 차이가 드러나는 순간 찾기¶

관찰값:

먼저 스스로 답해 봅니다.

• 숫자와 영문이 붙은 뒤 각 계열에서 토큰 수는 몇 개씩 늘었는가?
• 이 차이는 어느 계열이 더 좋다는 결론인가, 아니면 비용 차이가 언제 드러나는가를 보여 주는가?

해설: BPE는 31 - 24 = 7개, WordPiece는 23 - 17 = 6개, SentencePiece는 11 - 8 = 3개 늘었습니다. 여기서 정답은 특정 계열의 우열이 아닙니다. 같은 일정 안내라도 숫자와 영문이 붙는 순간 계열마다 증가 폭이 다르므로, 토큰화 종류 차이는 비용 예측 장면에서 먼저 드러날 수 있습니다.

연습 2. 청크 경계 차이가 드러나는 순간 찾기¶

관찰값:

먼저 스스로 답해 봅니다.

• 사람이 한 덩어리로 보는 한국어 구절이 더 잘게 흩어질 위험이 큰 쪽은 어디인가?
• 이 차이가 검색 청크에서 왜 문제가 될 수 있는가?

해설: 이 관찰값에서는 BPE gpt2와 WordPiece bert-base-uncased가 한국어 구절을 더 잘게 흩뜨리는 모습을 보입니다. SentencePiece google/mt5-small은 상대적으로 큰 한국어 조각을 남겼습니다. 이 차이는 문단이 자연스러워 보여도 실제 토큰 묶음에서는 의미 단위가 갈라질 수 있음을 보여 줍니다. 따라서 토큰화 종류 차이는 검색 결과가 조건이나 예외를 놓치는 청크 경계 문제로 드러날 수 있습니다.

연습 3. 혼합 표기 길이 예측이 흔들리는 순간 찾기¶

관찰값:

먼저 스스로 답해 봅니다.

• Zoom 링크 포함이 붙은 뒤 각 계열에서 토큰 수는 몇 개씩 늘었는가?
• 이 장면에서 먼저 다시 볼 축은 비용, 청크, 혼합 표기 길이 예측 중 무엇인가?

해설: BPE는 39 - 31 = 8개, WordPiece는 30 - 23 = 7개, SentencePiece는 16 - 11 = 5개 늘었습니다. 세 계열 모두 늘었지만 증가 폭은 같지 않습니다. 이 장면의 핵심은 비용 계산 하나가 아니라, 10:00, AM, Zoom, 링크처럼 숫자·영문·기호·한국어가 섞인 구간에서 길이 감각이 흔들린다는 점입니다. 따라서 먼저 다시 볼 축은 혼합 표기 길이 예측입니다.

이 연습의 목표는 세 계열 중 정답 하나를 고르는 일이 아닙니다. 필요한 것은 토큰화 종류 차이가 비용, 청크, 혼합 표기 길이 예측에서 실제로 드러나는 순간을 읽는 일입니다.

체크리스트¶

• 같은 뜻의 문장도 토큰 수 차이가 날 수 있다는 점을 설명할 수 있는가?
• 토큰화 종류 차이가 청크 경계와 길이 예측 문제에서 드러날 수 있다는 점을 말할 수 있는가?
• 어느 계열이 더 우수한가보다 차이가 언제 보이는가를 먼저 봐야 한다는 점을 이해했는가?
• 대표 토크나이저를 직접 써 보면 글자 수 감각과 실제 조각 경계 차이가 드러난다는 점을 설명할 수 있는가?

출처와 참고 자료¶

• Rico Sennrich, Barry Haddow, Alexandra Birch, Neural Machine Translation of Rare Words with Subword Units, ACL 2016, 확인 날짜: 2026-07-19. BPE와 부분 단어 단위가 희귀어와 미등록어 처리에 쓰이는 배경 근거로 사용했다.
• Taku Kudo, John Richardson, SentencePiece: A simple and language independent subword tokenizer and detokenizer for Neural Text Processing, EMNLP 2018, 확인 날짜: 2026-07-19. SentencePiece의 언어 독립적 raw sentence 처리와 공백 처리 설명 근거로 사용했다.
• Hugging Face, Summary of the tokenizers, Transformers documentation, 확인 날짜: 2026-07-19. BPE, WordPiece, SentencePiece 차이가 실제 tokenizer별 조각 경계와 토큰 수 차이로 드러난다는 설명 확인에 사용했다.
• Hugging Face, AutoTokenizer, Transformers documentation, 확인 날짜: 2026-07-19. 예제 코드의 AutoTokenizer.from_pretrained, tokenize, convert_tokens_to_ids 사용 흐름 확인에 사용했다.