토큰화(Tokenization)의 진화: 단어에서 서브워드까지

자연어 처리(NLP)에서 '토큰의 단위를 어떻게 정의하느냐'는 모델의 성패를 결정짓는 첫 단추입니다. 오늘은 언어의 특성과 태스크의 발전에 따라 변화해온 토큰화 기법들을 비교하고, 특히 한국어에서 왜 서브워드(Subword) 방식이 각광받는지 알아보겠습니다.

 

 

 

---

 

토큰화 방식별 특징 및 장단점 비교

방식	특징	단점	대표 사례
단어 기반	띄어쓰기(Whitespace) 기준 분리. 가장 직관적임.	OOV(Out-of-Vocabulary) 문제 심각. 변형어 인식 불가.	Space-based Tokenizer
형태소 기반	의미의 최소 단위(형태소)로 분리. 교착어에 적합.	신조어/고유명사 대응 취약. 분석기 성능에 의존.	Mecab, Okt, KoNLPy
서브워드 기반	빈번한 하위 문자열 조합으로 분리. 효율적임.	비직관적 토큰 결과, 추가 학습 프로세스 필요.	BPE, WordPiece, Unigram

 

 

한국어에서 '띄어쓰기 기반' 토큰화가 치명적인 이유

한국어는 영어와 달리 띄어쓰기만으로 단어를 분리했을 때 여러 가지 심각한 문제에 직면합니다.

• 단어 집합의 폭발 (Vocabulary Explosion) 한국어는 체언 뒤에 조사가 붙고, 용언 뒤에 어미가 붙는 교착어입니다.
  • 예시: '사과' 하나만 해도 '사과가, 사과는, 사과를, 사과도...' 등 수많은 변형이 생깁니다.
  • 문제점: 모델은 이들을 모두 별개의 단어로 학습하여 저장 공간을 낭비하고, 데이터 희소성(Sparsity) 문제를 야기합니다.
• 동음이의어와 중의성 문제 띄어쓰기가 없거나 잘못되었을 때 형태소 분석 없이 뭉텅이로 인식하면 기괴한 해석이 나옵니다.
  • 예시: "서울시체육회" → [서울시 + 체육회] (정상) vs [서울 + 시체 + 육회] (오류)
• 용언의 복잡한 활용 (Conjugation)
  • 예시: '먹다' → '먹고, 먹으니, 먹어서, 먹었다, 먹을까...'
  • 문제점: 영어(eat, ate, eating)보다 변형의 가짓수가 압도적으로 많아, 이를 모두 개별 단어로 사전에 등록하는 것은 불가능에 가깝습니다.

---

토큰화의 두 기둥: 형태소 기반 vs 서브워드 기반

단어(Word) 단위 토큰화의 한계를 극복하기 위해 등장한 두 가지 핵심 방식입니다.

1. 형태소 기반 토큰화 (Morpheme-based)

"의미를 가진 가장 작은 단위로 쪼갠다"

형태소 기반 토큰화는 언어학적 지식을 바탕으로 문장을 분석합니다. 특히 한국어처럼 명사에 조사가 붙고 동사가 활용되는 교착어에 필수적인 방식입니다.

• 핵심 원리: 문장을 '뜻을 가진 최소 단위'인 형태소로 분리합니다.
• 예시: "나는 사과를 먹었다"
  • 분석: 나(대명사) + 는(조사) + 사과(명사) + 를(조사) + 먹(동사 어근) + 었(과거 선어말어미) + 다(어미)
• 장점:
  • 단순 띄어쓰기보다 훨씬 정확하게 단어의 뿌리(어근)를 찾아낼 수 있습니다.
  • 한국어 특유의 문법적 특성을 모델에게 잘 전달합니다.
• 단점:
  • 신조어 대응 불가: 사전에 등록되지 않은 신조어(예: '좋댓구알', '중꺾마')가 들어오면 분석이 깨집니다.
  • 분석기 성능 의존: MeCab이나 Okt 같은 외부 라이브러리의 성능에 모델 성능이 종속됩니다.

서브워드 기반 토큰화 (Subword-based)

"통계적으로 자주 나오는 문자열 조합으로 쪼갠다"

언어학적 규칙 대신, 데이터에서 추출한 통계를 바탕으로 토큰을 정의합니다. "하나의 단어는 자주 사용되는 하위 단위(Subword)들의 조합"이라는 가설에서 출발합니다.

• 핵심 원리: 데이터 내에서 자주 함께 등장하는 글자들을 하나의 덩어리로 묶습니다. (BPE, WordPiece 등이 여기에 속함)
• 예시: "unhappiness"
  • 분석: un + happi + ness (의미 있는 단위들이 통계적으로 자주 등장하므로 조각남)
• 장점:
  • 신조어/희귀 단어 처리(OOV 해결): '중꺾마'라는 단어를 몰라도 '중 + 꺾 + 마'처럼 아는 조각으로 나누어 이해하려고 시도합니다.
  • 언어 독립적: 언어학적 지식이 필요 없으므로 한국어, 영어, 심지어 이모지나 코드 데이터에도 똑같이 적용 가능합니다.
• 단점:
  • 형태소와 달리 쪼개진 결과가 인간이 보기에 직관적이지 않을 수 있습니다. (apple -> ap + ple)

💡 왜 결국 '서브워드'인가? (핵심 요약)

비교	형태소 기반	서브워드 기반
기준	언어학적 규칙 (문법)	통계적 빈도/확률
신조어 대응	취약함 (사전 기반)	매우 강함
사전 크기	조절이 어려움	사용자가 원하는 크기로 제한 가능

현대 NLP의 흐름:

과거에는 한국어 성능을 높이기 위해 형태소 분석을 먼저 한 뒤 모델에 넣었지만, 최근 GPT나 Llama 같은 대형 모델들은 방대한 데이터를 학습하며 서브워드(BPE) 방식만으로도 형태소의 경계를 스스로 어느 정도 파악해냅니다. 그래서 요즘은 별도의 형태소 분석 없이 바로 서브워드 토큰화를 적용하는 것이 대세가 되었습니다.
단, 법률, 의료 등 데이터가 적은 특정 도메인의 한국어 모델에서는 여전히 MeCab 등으로 형태소를 먼저 나누는 것이 성능이 훨씬 잘 나옵니다.

---

토크나이저의 두 단계: 학습(Training) vs 추론(Inference)

우리가 토크나이저를 사용할 때는 두 가지 단계를 거칩니다. '병합'은 주로 1번 학습 단계에서 일어나는 핵심 원리입니다.

① 학습 단계: "사전(Vocabulary) 만들기"

처음에는 모든 글자를 낱개(a, b, c, 가, 나, 다...)로 찢어놓습니다. 여기서부터 병합이 시작됩니다.

1. 가장 작은 단위(Character)에서 시작: 모든 글자를 각각 하나의 토큰으로 봅니다.
2. 병합(Merge): "데이터를 보니 's'와 't'가 붙어서 정말 자주 나오네? 그럼 둘을 합쳐서 'st'라는 새로운 토큰을 하나 만들자!"
3. 반복: 이 과정을 사용자가 정한 사전 크기(예: 30,000개)가 될 때까지 반복합니다.
4. 결과: 자주 나오는 뭉치들은 하나의 토큰(playing)이 되고, 가끔 나오는 건 쪼개진 상태(play + ing)로 남습니다.

즉, '병합'은 "어떤 조각들을 합쳐서 우리 모델의 공식 단어장(Token List)에 등록할까?"를 결정하는 기준입니다.

② 추론 단계: "실제 문장 자르기"

학습 단계에서 '병합'을 통해 완성된 사전이 있다면, 이제 새로운 문장이 들어왔을 때 그 사전을 보고 최대한 큰 덩어리부터 찾아내며 잘라냅니다. 

왜 '병합' 기준이 중요한가요?

토크나이저가 단어장을 만들 때 "어떤 기준으로 조각들을 합쳐서 하나의 토큰으로 인정해줄 것인가"에 따라 모델의 성능이 달라지기 때문입니다.

• BPE의 병합 기준 (빈도): "단순히 같이 제일 많이 붙어 있는 놈들끼리 합치자."
• WordPiece의 병합 기준 (우도): "단순 빈도가 아니라, 합쳤을 때 전체 문장의 발생 확률을 가장 높여주는 단짝들끼리 합치자."

---

BPE vs WordPiece: "무엇을 합칠 것인가?"

두 방식 모두 '자주 등장하는 문자열을 병합'한다는 공통점이 있지만, 병합 기준에서 결정적인 차이가 있습니다.

 

① BPE (Byte Pair Encoding): "다다익선(多多益善)"

• 기준: 단순 빈도수(Frequency).
• 특징: 무조건 많이 나오는 쌍을 합칩니다. 예를 들어 'er'이나 '은/는' 처럼 의미적 결합력이 약해도 단순히 많이 보이면 하나의 토큰이 될 가능성이 큽니다. 코퍼스 전체의 광범위한 패턴을 잡는 데 유리합니다.

② WordPiece: "유유상종(類類相從)"

• 기준: 우도(Likelihood) 기반의 정보 획득량.
• 특징: 단순히 많이 나오는 게 아니라, "A가 나왔을 때 B가 나올 확률"이 얼마나 높은지를 계산합니다. 'poly' 뒤에 항상 'mer'가 온다면, 빈도가 낮더라도 이 둘을 강하게 결합합니다.

🔍 심층 탐구: WordPiece의 '우도(Likelihood)' 원리

WordPiece는 병합했을 때 전체 데이터셋의 확률(우도)을 최대화하는 방향으로 움직입니다. 이를 수식 관점에서 쉽게 풀이하면 다음과 같습니다.

두 유닛 $x$와 $y$가 있을 때, WordPiece는 다음 점수를 계산하여 가장 높은 쌍을 병합합니다.

$$Score = \frac{P(xy)}{P(x)P(y)}$$

• 분자 $P(xy)$: 두 문자가 연달아 등장할 확률 (빈도)
• 분모 $P(x)P(y)$: 두 문자가 각각 독립적으로 등장할 확률

 

만약 $Score = 1$이라면: 분자와 분모가 같습니다. 즉, 두 글자는 그냥 각자 나올 확률만큼 우연히 붙어 나온 것뿐입니다. (합칠 필요 없음)

만약 $Score > 1$이라면: 두 글자가 독립적으로 존재할 때보다 함께 붙어 있을 확률($P(xy)$)이 훨씬 높다는 뜻입니다.

• 점수가 높을수록 "이 둘은 우연이 아니라, 원래 하나의 의미 있는 덩어리(단어)일 가능성이 매우 높다"고 판단하는 것이죠.

 

왜 이렇게 할까요?

만약 'the'라는 단어가 아주 많이 나온다고 가정해 봅시다. BPE라면 't'와 'h'를 바로 합치겠지만, WordPiece는 고민합니다. "'t'와 'h'는 각각 다른 단어에서도 엄청나게 많이 쓰이는데($P(x), P(y)$가 큼), 굳이 둘을 하나로 묶는 게 효율적일까?"라고 판단하는 것이죠.

반면, 'tri'와 'angle'은 각각의 빈도는 낮을지 몰라도 둘이 붙어 있을 때의 확률($P(xy)$)이 개별 확률의 곱보다 훨씬 크다면, WordPiece는 이 둘을 의미 있는 단위로 보고 병합합니다. 즉, 조합의 예측 가능성이 높은 쌍을 우선시하는 것입니다.

 

💡 예를 들어볼까요?

• 전체 코퍼스 내의 글자 수 대비 확률:
  • $P(\text{t})$: 0.2 (매우 흔함)
  • $P(\text{h})$: 0.1 (매우 흔함)
  • $P(\text{tri})$: 0.01 (희귀함)
  • $P(\text{angle})$: 0.01 (희귀함)

케이스 1: 너무 흔한 녀석들의 만남 ('t' + 'h')

영어에서 'the', 'there', 'that' 등에 쓰이며 'th'는 엄청나게 자주 등장합니다.

• 함께 등장할 확률 $P(\text{th})$: 0.05 (매우 높음)
• WordPiece Score 계산:
  $$Score = \frac{P(\text{th})}{P(\text{t}) \times P(\text{h})} = \frac{0.05}{0.2 \times 0.1} = \frac{0.05}{0.02} = \mathbf{2.5}$$
• 해석: 분명 자주 나오긴 하지만, 't'와 'h'는 각자 다른 데서도 너무 많이 쓰입니다. 점수가 생각보다 높지 않습니다.

케이스 2: 찰떡궁합의 만남 ('tri' + 'angle')

수학 논문 데이터를 학습 중이라 'triangle'이라는 단어가 꽤 자주 나온다고 가정해 봅시다.

• 함께 등장할 확률 $P(\text{triangle})$: 0.009 (절대 빈도는 낮음)
• WordPiece Score 계산:
  $$Score = \frac{P(\text{triangle})}{P(\text{tri}) \times P(\text{angle})} = \frac{0.009}{0.01 \times 0.01} = \frac{0.009}{0.0001} = \mathbf{90}$$
• 해석: 절대적인 빈도($P(xy)$)는 'th'보다 훨씬 낮지만, 'tri'가 나오면 거의 항상 'angle'이 따라붙습니다. 점수는 90점으로 'th'보다 압도적으로 높습니다.

WordPiece의 선택: BPE였다면 'th'를 먼저 합쳤겠지만, WordPiece는 'triangle'을 먼저 하나의 토큰으로 묶습니다. 왜냐하면 't'와 'h'는 따로 떼어놔도 다른 단어를 설명할 때 쓸모가 많지만(범용성), 'tri'와 'angle'은 붙여 놓았을 때 훨씬 더 강력하고 고유한 의미 정보를 전달하기 때문입니다.

 

---

BPE(Byte Pair Encoding)는 오히려 워드피스보다 더 많이 쓰인다고 봐도 될 정도로 현재 주류입니다!

허깅페이스 라이브러리 내에서 WordPiece가 BERT의 전유물이라면, BPE는 현재 AI 생태계를 지배하고 있는 거대 언어 모델(LLM)들의 표준입니댜ㅏ.

1. BPE를 사용하는 대표적인 모델들

지금 우리가 아는 대부분의 최신 모델은 BPE(특히 Byte-level BPE)를 사용합니다.

• GPT 시리즈 (GPT-2, GPT-3, GPT-4): OpenAI의 모든 모델은 BPE 기반입니다.
• Llama 시리즈 (Meta): 현재 오픈소스 진영에서 가장 핫한 Llama도 BPE를 씁니다.
• RoBERTa: BERT의 업그레이드 버전인데, 워드피스 대신 BPE를 선택했습니다.
• Mistral, Anthropic(Claude) 등: 대부분의 LLM이 BPE 계열을 선호합니다.

2. 왜 WordPiece보다 BPE가 더 많이 쓰일까요?

워드피스도 훌륭하지만, 최근 모델들이 BPE(정확히는 Byte-level BPE)를 고집하는 이유가 있습니다.

• OOV(Out-of-Vocabulary)의 완벽한 제거: 일반적인 BPE는 문자 단위로 쪼개지만, Byte-level BPE는 텍스트를 '바이트(Byte)' 단위로 봅니다. 이 세상의 모든 텍스트는 결국 바이트로 표현되므로, 어떤 생소한 유니코드나 이모지가 들어와도 절대 <UNK>(모르는 단어) 처리를 하지 않고 조각조각이라도 다 읽어낼 수 있습니다.
• 효율성: 워드피스의 '우도(Likelihood)' 계산은 통계적으로 정교하지만, 학습 코퍼스가 거대해질수록 계산 복잡도가 높습니다. 반면 BPE는 빈도 기반이라 대규모 데이터를 빠르게 처리하는 데 매우 효율적입니다.

WordPiece vs BPE (실제 사례)

비교 항목	WordPiece (BERT 등)	BPE (GPT, Llama 등)
병합 기준	확률(우도) 기반	빈도(Frequency) 기반
서브워드 표시	## 사용 (예: ##ing)	Ġ (공백 문자) 사용 (예: Ġing)
미지어 처리	<UNK> 발생 가능성 있음	바이트 단위 처리로 <UNK> 거의 없음
현재 위상	구글 계열 모델들이 주로 사용	현세대 LLM의 표준 알고리즘

---

 

 

단어 사전(Vocabulary) 관리와 OOV 문제

학습 데이터는 소수의 단어가 지배적인 멱함수 분포(Zipf's Law)를 따릅니다. 따라서 효율적인 사전을 구성하려면 다음 전략이 필요합니다.

• 포함 우선순위: 의미를 담고 있으면서도 자주 등장하는 고빈도 단어를 최우선으로 포함합니다. 빈도가 너무 낮은 희귀 단어는 메모리만 차지하므로 제외합니다.
• OOV(Out-of-Vocabulary)의 위험성: 모델이 모르는 단어를 만나면 벡터화할 수 없어 해당 정보를 무시하거나 노이즈로 처리합니다. 이는 맥락 왜곡과 성능 저하로 직결됩니다.
• <UNK> 토큰의 역할: "모르는 단어"라는 사실을 모델에게 명시적으로 알려줍니다. 학습 시 일부러 저빈도 단어를 <UNK>로 바꿔 모델이 주변 맥락으로 의미를 추론하도록 훈련시킵니다.

---

왜 허깅페이스 Tokenizer가 '천하통일'을 했을까?

🚀 압도적인 속도 (Rust 기반)

허깅페이스의 tokenizers는 핵심 로직이 Rust 언어로 작성되어 있습니다. 파이썬 기반의 구형 라이브러리들과는 비교도 안 될 만큼 빠릅니다. 수십 GB의 텍스트를 토큰화할 때 그 차이가 극명하게 드러나죠.

🧩 유연성과 호환성

BPE, WordPiece, Unigram 등 거의 모든 서브워드 알고리즘을 하나의 인터페이스로 지원합니다. 또한, 결과물이 바로 PyTorch나 TensorFlow 텐서로 변환되기 때문에 모델 학습 파이프라인에 태우기가 너무 편합니다.

📚 공유 생태계 (Model Hub)

누군가 이미 학습시켜 놓은 토큰화 설정(예: bert-base-multilingual-cased)을 이름 한 줄만으로 그대로 불러올 수 있습니다. 직접 학습(Train)시키는 수고를 덜어주죠.

 

그럼에도 다른 라이브러리를 쓰는 경우 (예외 상황)

모든 상황에서 허깅페이스만 쓰는 것은 아닙니다. 특히 한국어나 특수 태스크에서는 다른 도구를 섞어서 씁니다.

① 한국어 형태소 분석이 먼저 필요할 때

서브워드 토큰화를 하기 전에 "형태소 단위로 먼저 나누고 싶다"면 아래 도구들을 거쳐야 합니다.

• MeCab / KoNLPy: 한국어의 조사와 어미를 깔끔하게 떼어내고 싶을 때 사용합니다.
• 카카오 khaiii: 딥러닝 기반의 정교한 형태소 분석이 필요할 때 씁니다.
• 활용법: MeCab으로 형태소 분리 -> 허깅페이스 BPE로 최종 토큰화 하는 식으로 하이브리드 구성을 하기도 합니다.

② 센텐스피스 (SentencePiece)

구글에서 만든 라이브러리입니다. 사실 허깅페이스 내부에서도 센텐스피스 알고리즘을 지원하지만, T5나 LLaMA 같은 특정 모델들은 원본 sentencepiece 라이브러리에 의존성이 걸려 있는 경우가 있어 직접 쓰기도 합니다.

③ 특정 도메인 특화

• Tiktoken: OpenAI(ChatGPT 등) 모델들이 사용하는 전용 토큰라이저입니다. OpenAI 모델의 토큰 수를 정확히 계산해야 할 때는 이 라이브러리가 필수입니다.

요즘의 국룰(Standard)

상황	사용하는 도구
대부분의 딥러닝 모델 학습	Hugging Face tokenizers
한국어 성능 극대화	MeCab/KoNLPy(전처리) + Hugging Face
ChatGPT 토큰 계산	Tiktoken