BPE vs Byte-level Tokenization: 한글은 왜 영어보다 API 요금이 2-3배 비쌀까?

서론

똑같은 내용의 문서를 영어로 번역했더니 GPT API 요금이 절반으로 줄었다는 경험, 있으신가요?

한글: "안녕하세요, 반갑습니다" → 약 15 토큰
영어: "Hello, nice to meet you" → 약 6 토큰
(토큰 수는 모델/토크나이저 버전에 따라 달라질 수 있음)

같은 의미인데 토큰은 대략 2-3배 차이. 토큰당 과금이니 API 비용도 비슷한 비율로 증가합니다.

왜 한글은 영어보다 토큰이 더 많이 나올까요? 그리고 이게 단순히 돈 문제를 넘어서 모델 성능에는 어떤 영향을 미칠까요?

답은 토큰화(Tokenization) 방식, 특히 영어 중심으로 학습된 BPE(Byte Pair Encoding)의 구조적 한계에 있습니다.

이 글의 대상 독자: LLM API를 사용하는 한국어 개발자, PM, 그리고 토큰화의 언어별 차이에 관심 있는 기술 블로그 독자를 위해 작성했습니다.

BPE(Byte Pair Encoding)란?

BPE는 압축 알고리즘을 토큰화에 적용한 방식입니다. 작동 원리:

1. 개별 문자로 시작
2. 가장 빈번한 문자 쌍을 반복적으로 병합
3. 서브워드(subword) 단위의 어휘 구축

예시:

텍스트: "playing playing playing"
초기 상태: ['p', 'l', 'a', 'y', 'i', 'n', 'g', ...]
병합 후: ['play', 'ing', ...]

와우포인트 1: 영어 중심 학습의 불평등 ⚖️

BPE는 학습 데이터에서 자주 등장하는 패턴을 우선적으로 병합합니다. GPT의 학습 데이터는 영어가 압도적으로 많기 때문에:

영어 단어들 (예시):

• "the": 1개 토큰 (가장 흔한 단어)
• "hello": 1개 토큰
• "computer": 1개 토큰
• "algorithm": 1-2개 토큰

한글 단어들 (예시):

• "안녕": 일부 GPT 토크나이저에서 여러 토큰으로 분절
• "컴퓨터": 영어 "computer"보다 3-4배 많은 토큰
• "알고리즘": 영어 "algorithm"보다 4-5배 많은 토큰

동일한 개념인데 한글은 대체로 2-5배 더 많은 토큰을 소비하는 경향이 있습니다.
(정확한 토큰 수는 모델과 토크나이저 버전에 따라 달라질 수 있습니다)

이것이 바로 API 비용 차이의 근본 원인입니다. 모델 입장에서도 한글은 영어보다 "더 긴 문장"으로 인식됩니다.

Byte-level Tokenization이란?

Byte-level 토큰화는 텍스트를 바이트 시퀀스(0-255)로 처리하는 방식입니다.

중요한 구분:

• 순수 byte-level: 각 바이트가 하나의 토큰 (이론적 극단 케이스)
• Byte-level BPE: 바이트를 기본 알파벳으로 시작하되, BPE 병합 규칙 적용 (실제 GPT 계열이 사용)

이 글에서는 이해를 돕기 위해 "순수 byte-level"을 가정한 극단적 케이스를 예로 들지만, 실제 대부분의 대형 모델(GPT-4 등)은 byte-level BPE를 사용합니다.

순수 byte-level의 장점:

• 고정된 입도: 모든 문자가 일관되게 표현됨
• 미등록 토큰 없음: 모든 텍스트를 인코딩 가능
• 언어 공평성: 영어든 한글이든 바이트는 바이트

단점:

• 시퀀스 길이 폭발: 더 많은 토큰 = 더 많은 연산
• 의미적 압축 부족: 단어 수준 패턴을 효율적으로 활용 불가

와우포인트 2: 시퀀스 길이 폭발

동일한 텍스트에 대한 토큰 개수 비교:

텍스트: "The quick brown fox jumps over the lazy dog."

• GPT-2 BPE: ~10개 토큰
• Byte-level: ~45개 토큰 (공백 포함 문자당 1개)

1,000단어 에세이:

• BPE: ~750개 토큰
• Byte-level: ~5,000개 이상 토큰

이 5-7배 시퀀스 길이 증가는 다음에 직접적 영향:

• 메모리 소비 (어텐션 메커니즘에서 제곱 증가)
• 학습 비용
• 추론 속도

실질적 영향: 비용을 넘어선 성능 문제

1. 컨텍스트 윈도우 낭비

GPT-4의 컨텍스트 윈도우가 128K 토큰이라고 해도:

영어 사용자:

• 128,000 토큰 ÷ 1.3 토큰/단어 = 약 98,000 단어 처리 가능

한글 사용자:

• 128,000 토큰 ÷ 2.8 토큰/단어 = 약 45,000 단어 처리 가능

같은 모델, 같은 비용인데 한글 사용자는 절반밖에 못 씁니다.

와우포인트 3: 생성 속도 차이 🚀

LLM은 한 번에 1개 토큰씩 생성합니다. 즉:

영어로 100단어 생성: ~130 토큰 생성 필요 → 예: 2-3초
한글로 100단어 생성: ~280 토큰 생성 필요 → 예: 4-6초

같은 정보량을 생성하는데 한글이 약 2배 느린 경향이 있습니다.
(실제 속도는 서버 부하, 모델 크기 등 여러 요인에 영향받습니다)

2. 모델 이해도 차이

토큰이 많을수록 어텐션 연산이 복잡해집니다. 한글 문장은:

• 같은 의미인데 토큰 시퀀스가 2배 이상 길음
• 어텐션 메커니즘이 더 많은 토큰 관계를 처리해야 함
• 이론적으로 정보 밀도가 낮아져 이해도에 영향 가능

Byte-level 토큰화는 모든 언어를 동등하게 처리하지만, 시퀀스가 5-7배 더 길어져 또 다른 문제가 생깁니다.

와우포인트 4: 압축 불평등 = 비용 불평등 💰

BPE는 학습 데이터의 언어 분포를 선호하는 압축 편향을 만듭니다:

참고: 위 수치는 여러 레퍼런스와 실전 경험을 바탕으로 한 대략적인 예시입니다. 실제 토큰 수는 모델, 토크나이저, 텍스트 특성에 따라 달라질 수 있습니다.

실제 비용 예시 (GPT-4 API 개념적 계산):

• 영어 1,000단어 문서: ~1,300 토큰 → 약 $0.026
• 한글 1,000단어 문서: ~2,800 토큰 → 약 $0.056

같은 정보량인데 한글 사용자는 대체로 1.5-2배 이상의 비용 부담이 발생하는 경향이 있습니다.

이는 단순히 돈 문제가 아닙니다:

• 컨텍스트 윈도우가 인코딩 오버헤드로 "낭비"됨 (같은 정보에 더 많은 토큰 소비)
• 긴 문서에서 한글은 컨텍스트 제한에 더 빨리 도달
• 생성 속도도 느림 (토큰 단위로 생성하므로)

하이브리드 접근: 두 세계의 장점?

GPT-4나 Llama 같은 최신 모델들은 균형을 맞추려는 변형을 사용합니다:

1. 문자 대체(Character fallback): 미등록 시퀀스에 대한 byte-level 인코딩이 포함된 BPE
2. 다중 입도: 단어 수준, 서브워드, 문자 토큰 혼합
3. 언어별 토크나이저: 다른 문자 체계를 위한 별도 어휘

와우포인트 5: 어휘 크기의 스위트 스팟 📊

어휘가 크다고 항상 좋은 것은 아닙니다:

• GPT-2: 50,257개 토큰
• GPT-3: 50,257개 토큰 (동일!)
• GPT-4 계열 (cl100k_base): ~100,000개 토큰
• Llama 2: 32,000개 토큰

참고: GPT-4의 내부 구조는 비공개이므로, 여기서는 GPT-4 Turbo 등에서 사용되는 것으로 알려진 cl100k_base 토크나이저를 기준으로 설명합니다.

왜 100만 개 토큰은 안 될까요?

1. 임베딩 행렬 비용: vocab_size × hidden_dim 파라미터
2. 소프트맥스 연산: 토큰이 많을수록 생성이 느림
3. 학습 데이터 요구사항: 희귀 토큰은 충분한 예시가 필요

그런데 byte-level은 256개 토큰만! 임베딩 레이어는 작지만, 시퀀스 길이가 폭발합니다.

개발자를 위한 실전 가이드

BPE가 실패하는 경우

• 문자 수준 연산 (개수 세기, 뒤집기, 철자)
• 다양한 문자를 사용하는 다국어 애플리케이션
• 코드 토큰화 (변수명, 특수 문자)
• 세밀한 텍스트 조작이 필요한 작업

BPE가 승리하는 경우

• 긴 컨텍스트 이해 (적은 토큰 = 더 긴 컨텍스트)
• 일반적인 언어 이해
• 의미적 작업 (요약, QA, 추론)
• 효율적인 추론 (적은 토큰 = 빠름)

결론: 우리가 알아야 할 것

토큰화는 기술 문제가 아니라 경제 정의 문제

BPE와 byte-level 토큰화 중 어느 것이 "더 나은가"가 아니라 누구에게 유리한가의 문제입니다:

• BPE: 영어 사용자에게 효율적, 비영어권 사용자에게 불리
• Byte-level: 모든 언어에 공평하지만, 모두에게 비효율적

한글 사용자를 위한 현실적 조언

1. API 비용 절감 팁:

• 가능하면 간결한 프롬프트 사용 (한글은 토큰 낭비가 큼)
• 반복적인 지시사항은 시스템 메시지에 한 번만
• 긴 문서는 청킹(chunking)해서 처리

2. 모델 선택:

• 다국어 특화 모델 고려 (Llama 3.1의 다국어 토크나이저 등)
• 비용 민감한 작업은 더 작은 모델 + 더 나은 프롬프트 엔지니어링

3. 미래 전망:

• 적응형 토큰화: 언어별로 최적화된 토크나이저
• 다국어 공정성: 최신 모델들은 한글 토큰 효율이 개선 중 (GPT-4 > GPT-3.5)
• 아키텍처 혁신: 토큰 수에 덜 민감한 새로운 어텐션 메커니즘

핵심 메시지

토큰화는 모델이 세상을 보는 렌즈입니다. 그리고 지금의 렌즈는 영어 중심으로 갈려있습니다.

실제 수치는 텍스트와 모델에 따라 다르지만, 한국어는 같은 정보량 대비 영어보다 대체로 1.5-2.5배 정도 더 많은 토큰을 사용하는 경향이 있습니다.

그 결과 한글 사용자는:

• 같은 정보에 1.5-2배 이상의 비용 부담
• 컨텍스트 윈도우 효율 저하 (체감상 "절반쯤밖에 못 쓰는 느낌")
• 생성 속도도 느림 (토큰 수에 비례)

이것이 단순히 기술적 한계가 아니라 학습 데이터와 토크나이저 설계의 편향이라는 것을 이해하는 것이 중요합니다.

핵심 요약:

1. BPE는 영어 중심 학습 데이터로 인해 한글을 2-5배 더 잘게 쪼개는 경향
2. 토큰 기반 과금 → 한글 사용자는 같은 내용에 1.5-2.5배 비용 부담
3. 컨텍스트 윈도우 효율 저하 → 영어 대비 처리 가능한 단어 수 감소
4. 생성 속도도 느림 → 토큰 단위 생성으로 인한 지연
5. 해결책: 다국어 특화 토크나이저, 간결한 프롬프트, 아키텍처 혁신 필요

참고 자료

이 글은 다음 연구 및 레퍼런스를 참고했습니다:

1. 한국어 BPE 과분절(oversegmentation) 문제
   • 한국어처럼 형태가 복잡한 언어에서 BPE가 단어를 과도하게 쪼개 성능 저하를 유발한다는 연구
   • 참고: Subword Regularization 관련 연구
2. CJK 언어의 byte-level fallback 문제
   • Byte-level BPE에서 중국어/일본어/한국어가 시퀀스 길이를 크게 늘린다는 분석
   • 참고: BBPE: Byte-level BPE 논문
3. 실제 사용자 경험 및 벤치마크
   • OpenAI 포럼 및 개발자 커뮤니티에서 보고된 한국어 토큰 비효율 사례
   • CJK vs 영어 토큰 밀도 실측 블로그들
4. OpenAI Tokenizer 공식 문서
   • OpenAI Tokenizer
   • 직접 테스트해볼 수 있는 공식 도구

면책사항: 이 글의 구체적인 수치(토큰 수, 비용 등)는 설명을 위한 예시이며, 실제 값은 모델, 토크나이저 버전, 텍스트 특성에 따라 달라질 수 있습니다. 정확한 토큰 수는 실제 사용하는 모델의 토크나이저로 직접 측정하는 것을 권장합니다.