Karpathy GPT Tokenizer 실습: BPE와 minBPE로 토큰화 실패 줄이기 | DAKER 커뮤니티
문자열을 UTF-8 bytes, BPE merges, token ids로 바꾸는 GPT Tokenizer NotebookLM 카드.
Karpathy GPT Tokenizer 실습은 LLM 앞단에서 문자열이 token id로 바뀌는 별도 학습 단계를 직접 확인하는 과정입니다. 지금 중요한 이유는 한국어, 이모지, 특수 토큰, 긴 프롬프트 비용 문제가 모델 본체가 아니라 tokenizer에서 시작되는 경우가 많기 때문입니다.
토크나이저란, 문자열과 모델이 처리하는 token id 사이를 encode와 decode로 변환하는 LLM 파이프라인 구성요소를 의미합니다.
오늘 배울 것은 무엇인가요?
한 줄 요약: GPT from scratch 실습 흐름을 이해하려면, 그 앞에서 문자열을 숫자로 바꾸는 tokenizer를 독립된 시스템으로 봐야 합니다.
이 글은 Karpathy GPT Tokenizer 강의와 minBPE로 BPE merge를 직접 따라 하려는 학습자에게 실습 순서를 제공합니다.
중심 주제: Karpathy GPT Tokenizer
함께 익힐 표현: BPE 실습, minBPE, 토큰화 오류, encode decode
연결 학습: nanochat 파이프라인 지도와 nanochat 전체 흐름 글에서 LLM 전체 단계 중 tokenizer 위치를 먼저 확인하세요.
GPT Tokenizer는 왜 모델 본체와 분리해서 봐야 하나요?
공식 확인 기준으로 Karpathy의 Zero to Hero tokenizer 강의는 Tokenizer를 LLM 파이프라인의 필요하고 널리 쓰이는 구성요소로 설명하며, 문자열과 token id를 오가는 encode()와 decode()를 별도 단계로 다룹니다. 이 글은 2026년 6월 27일 확인한 공개 강의 페이지와 minbpe 공식 README 기준입니다.
Tokenizer는 학습 데이터, 학습 알고리즘, vocabulary, merge 규칙을 따로 갖습니다. 그래서 모델이 “한국어를 이상하게 자른다”, “이모지가 여러 토큰이 된다”, “특수 토큰이 위험하다” 같은 문제는 attention block을 보기 전에 tokenizer에서 먼저 재현해야 합니다.
핵심 개념은 BPE merge를 어떻게 기록하는 것인가요?
단계 | 무엇을 하나요? | 실습 증거 |
|---|---|---|
byte 변환 | 문자열을 UTF-8 byte id로 바꿉니다. | 한국어와 이모지가 여러 byte인지 확인 |
pair 집계 | 가장 자주 붙는 이웃 pair를 찾습니다. | 빈도표를 짧게 기록 |
merge 등록 | 새 token id를 vocabulary에 추가합니다. | merge 순서와 id를 저장 |
encode/decode | 문자열과 token id를 왕복합니다. | decode 결과가 원문과 같은지 확인 |
짧은 문자열에서 pair 빈도, merge 등록, encode/decode 왕복, special token 경고까지 보는 NotebookLM 워크플로 카드.
따라 해볼 실습은 어떤 순서가 좋을까요?
긴 데이터셋 대신 “aaabdaaabac” 같은 짧은 문자열로 시작합니다.
처음 256개 byte token이 기본 vocabulary라는 점을 확인합니다.
가장 자주 등장하는 pair를 하나 merge하고 새 id를 붙입니다.
merge를 3번만 반복한 뒤 encode 결과와 decode 결과를 비교합니다.
“안녕하세요 😉”처럼 한국어와 이모지가 섞인 문자열의 token 수를 확인합니다.
special token은 allowed_special처럼 의도를 명시해야 한다는 경고를 체크합니다.
자주 막히는 지점은 어디인가요?
처음부터 큰 말뭉치와 큰 vocab_size로 시작해 merge 과정을 눈으로 놓칩니다.
token id를 외우려고 하고 decode 왕복 검증을 빼먹습니다.
RegexTokenizer가 category boundary를 왜 나누는지 보지 않습니다.
special token을 사용자 입력에서 자동 허용해도 된다고 착각합니다.
한국어 프롬프트 비용 문제를 모델 성능 문제로만 해석합니다.
다음 학습 연결은 어떻게 잡으면 좋을까요?
makemore bigram 글은 가장 작은 문자 언어모델을, WaveNet shape-first 글은 더 깊은 문자 구조를, nanochat 파이프라인 지도는 tokenizer 이후 학습·평가·추론 흐름을 보여 줍니다. tokenizer를 따로 보면 이 흐름이 “문자열 -> token ids -> logits -> sample”로 선명해집니다.
공식 출처 기준으로 어디까지 확실한가요?
Karpathy Zero to Hero 공식 페이지는 tokenizer가 문자열과 토큰을 오가며, 별도 training set과 BPE training algorithm을 가진다고 설명합니다.
karpathy/minbpe README는 byte-level BPE의 minimal clean code이며 BasicTokenizer, RegexTokenizer, GPT4Tokenizer를 소개합니다.
minbpe README는 special token을 encode할 때 의도를 명시하지 않으면 위험한 footgun이 될 수 있다고 경고합니다.
이 글의 공개 링크는 DAKER 정책에 따라 확인된 DAKER 내부 글만 사용했습니다.
자주 묻는 질문
BPE를 왜 짧은 문자열부터 봐야 하나요?
짧은 문자열에서는 pair 빈도와 merge 순서를 눈으로 추적할 수 있습니다. 이 과정을 이해한 뒤에야 큰 vocabulary의 의미가 보입니다.
한국어 토큰화는 왜 비용과 연결되나요?
문자열이 더 많은 token id로 쪼개지면 같은 의미라도 context와 비용을 더 씁니다. 실제 비용은 사용하는 tokenizer와 모델에 따라 달라집니다.
encode와 decode 중 무엇을 먼저 확인해야 하나요?
둘을 항상 같이 봐야 합니다. encode 결과만 보면 token id 배열은 맞아 보여도 원문 복원이 깨지는 문제를 놓칠 수 있습니다.
special token은 왜 조심해야 하나요?
사용자 입력이 시스템용 토큰처럼 해석되면 의도하지 않은 동작으로 이어질 수 있습니다. 허용할 special token을 명시하는 습관이 안전합니다.
Tokenizer 다음에는 무엇을 배우면 좋나요?
Tokenizer 다음에는 GPT from scratch의 attention block을 보고, 그다음 nanochat처럼 사전학습·평가·추론·UI까지 이어지는 파이프라인을 보면 좋습니다.
오늘은 긴 프롬프트를 넣기 전에, 짧은 한국어 문장 하나가 몇 개 token으로 쪼개지는지부터 직접 확인해 보세요.