한글 토큰 세금 완전 정복 — 왜 한국어 API 요금은 영어보다 비쌀까?

aitokenomicskorean-taxtokenizertiktokensentencepieceqwenclaudeoptimization

안녕하세요! 재니미입니다.

“같은 분량의 기획서인데 영문 프롬프트는 800 토큰이 나오는데, 한글로 번역해서 넣으니 1,500 토큰이 찍힙니다.”
“분명 단가표는 Claude와 OpenAI가 비슷한데, 한 달 뒤 청구서를 보면 한국어 챗봇 비용이 왜 이렇게 많이 나올까요?”

LLM을 실제 프로덕트에 도입해 본 엔지니어라면 누구나 한 번쯤 겪어본 기현상입니다. 업계에서는 이를 ‘비영어권 토큰 세금(Non-English Token Tax)’, 한국에서는 ’한글 토큰 세금(Korean Tax)’이라고 부릅니다.

결론부터 말씀드리면, 한국어 API 요금이 영어보다 비싼 이유는 글자 수나 단어 수 때문이 아니라, 거대언어모델이 텍스트를 읽을 때 사용하는 ’토크나이저(Tokenizer)’의 어휘 사전 설계 방식 때문입니다. 서구권 중심의 사전에서는 한글 단어가 음절이나 바이트 단위로 잘게 쪼개지면서 토큰 수가 불어나게 됩니다.

지난 1편 「한국 사용자를 위한 가성비 AI 랭킹 — 프론티어 7사 토큰 비용과 벤치마크 종합 분석」에서 모델별 가성비 순위를 살펴보며 이 토큰 세금을 가볍게 언급해 드렸는데요. 이번 2편에서는 왜 이런 현상이 발생하는지 토크나이저 알고리즘 수준에서 원인을 짚어보고, 실제 1,000줄 텍스트 청구서 시뮬레이션과 비용 절감 팁을 알기 쉽게 정리해 보았습니다.

1. 한글 토큰 세금은 왜 생기는가?

컴퓨터와 언어 모델은 사람이 쓰는 글자 자체를 직접 이해하지 못합니다. 텍스트를 숫자로 변환하기 위해 가장 먼저 글자를 최소 의미 단위인 ’토큰(Token)’으로 쪼개는 과정을 거치는데, 이 역할을 수행하는 프로그램을 **토크나이저(Tokenizer)**라고 합니다.

대부분의 최신 LLM은 BPE(Byte-Pair Encoding) 또는 SentencePiece 알고리즘을 사용합니다. 자주 등장하는 글자 조합을 하나의 토큰으로 사전에 등록해 두고, 사전에 없는 단어는 글자나 바이트 단위로 잘게 쪼개는 방식입니다.

flowchart TD
    A["'자연어 처리' (6글자) 입력"] --> B{"토크나이저 어휘 사전 (Vocab) 탐색"}
    B -- "사전에 '자연어'가 등록된 경우 (Qwen/Gemini)" --> C["['자연어', ' 처리'] 👉 2 토큰 (효율적)"]
    B -- "사전에 없어 음절/바이트로 쪼개지는 경우" --> D["['자', '연', '어', ' 처', '리'] 👉 5 토큰 (토큰 급증)"]

왜 한글에서 유독 토큰 수가 폭증할까?

  1. 서구권 중심의 어휘 사전(Vocab Table):
    OpenAI나 Anthropic 등 글로벌 빅테크 모델들은 전체 훈련 데이터의 8090% 이상이 영어입니다. 그러다 보니 보통 10만20만 개 크기의 토크나이저 어휘 사전의 대부분을 영어 단어와 프로그래밍 코드가 차지하게 됩니다.
  2. 조합형 언어인 한글의 특성:
    영어는 알파벳 26자의 조합이지만, 한글은 초성·중성·종성이 결합해 총 11,172개의 음절을 만들어냅니다. 사전에 등록되지 못한 한글 단어는 글자 단위, 심지어 UTF-8의 바이트(Byte, 한 글자당 3바이트) 단위로 잘게 쪼개지면서 토큰 수가 1.5배에서 2배 가까이 불어나게 됩니다.

2. 주요 모델별 토크나이저 구조 비교

각 모델이 채택한 토크나이저의 어휘 사전 크기와 한글 분절 방식에 따라 실질적인 ’한글 세금’의 크기가 결정됩니다.

모델 계열 토크나이저 방식 사전 크기 (Vocab Size) 한글 토큰 압축률 (영문 대비 소모 배율) 주요 특징
Alibaba Qwen (3.x) BPE (CJK 고밀도) ~152K 약 1.2배 (최상) 한중일 다국어 단어가 대량 수록되어 한글 음절 쪼개짐이 가장 적음
DeepSeek (V4) Byte-level BPE ~128K 약 1.3배 (우수) 코드 및 다국어 최적화로 한글 음절 결합 처리 준수
Google Gemini (4 / 3.8) SentencePiece ~256K (초대형) 약 1.35배 (우수) 방대한 사전 크기 덕분에 웬만한 한글 단어들이 통째로 토큰화됨
OpenAI (GPT-6 / 4o) o200k_base (tiktoken) ~200K 약 1.4배 ~ 1.5배 (보통) 구형 cl100k(GPT-4 시절 2.2배) 대비 비약적으로 개선됨
Anthropic Claude (5.5) SentencePiece 변형 가변 약 1.7배 ~ 1.9배 (세금 높음) 문장력은 뛰어나지만 한글 단어가 세밀하게 분절되어 토큰 소모가 큼

3. [시뮬레이션] 한글 1,000줄 처리 시 모델별 실제 청구 비용

동일한 내용의 **한국어 비즈니스 보고서 1,000줄(약 25,000 단어 / 한글 약 80,000자)**을 처리(입력 80% + 출력 20%)한다고 가정했을 때, 토크나이저 효율이 반영된 실제 청구 금액을 계산해 보았습니다.

※ 영문 기준 약 40,000 토큰 분량에 해당하는 의미론적 텍스트

xychart-beta
    title "한국어 1,000줄 처리 시 소모 토큰 수 (단위: 천 토큰)"
    x-axis ["영어 원문", "Qwen 3.8", "DeepSeek V4", "Gemini 3.8", "GPT-6.1", "Claude 5.5"]
    y-axis "소모 토큰 (k)" 30 --> 80
    bar [40, 48, 52, 54, 58, 72]

모델별 실제 청구 비용 계산

모델명 1M 토큰 공식 단가 (입력/출력) 실질 소모 토큰 수 실제 1회 청구 비용 비용 체감 배율
Qwen 3.7-Plus $0.40 / $1.60 48,000 토큰 $0.031 기준 (가장 저렴)
DeepSeek V4 Pro $0.66 / $1.98 (할인시간) 52,000 토큰 $0.048 약 1.5배
Gemini 3.8 Flash $0.75 / $3.75 54,000 토큰 $0.073 약 2.3배
Qwen 3.8-Max $2.00 / $6.00 48,000 토큰 $0.134 약 4.3배
GPT-6.1 Sol $2.00 / $10.00 58,000 토큰 $0.209 약 6.7배
Claude Sonnet 5.5 $2.00 / $10.00 72,000 토큰 $0.260 약 8.4배

여기서 주목할 점이 있습니다. 공식 단가표상 GPT-6.1 Sol과 Claude Sonnet 5.5는 둘 다 $2.00 / $10.00로 정확히 동일합니다. 하지만 한글 토큰 세금 차이(1.45배 vs 1.8배)로 인해, 동일한 한국어 문서를 넣었을 때 실제 청구 금액은 Claude가 약 24% 더 많이 나오게 됩니다.

4. 한글 토큰을 줄이는 4가지 실전 팁

API 요금을 아끼고 컨텍스트 윈도우 조기 소진을 막기 위해 바로 적용해 볼 수 있는 팁들입니다.

① 시스템 프롬프트는 영어로, 입출력만 한국어로

LLM은 다국어 정렬이 잘 되어 있어 지시사항(System Prompt)을 영어로 적어도 한국어 답변을 자연스럽게 출력합니다.

  • 비효율: "당신은 IT 컨설턴트입니다. 아래 문서를 읽고 핵심 요구사항 3가지를 정리하세요."
  • 최적화: "You are an IT consultant. Read the document and summarize 3 key requirements in Korean."
  • 효과: 고정적으로 매 요청마다 들어가는 시스템 프롬프트 토큰을 40~50% 절감할 수 있습니다.

② 프롬프트 캐싱(Prompt Caching) 적극 활용

  • Claude는 캐시 적중(Cache Hit) 시 입력 토큰 비용을 대폭 할인해 줍니다.
  • Qwen과 DeepSeek 역시 캐시 적중 시 토큰 비용이 매우 저렴해집니다.
  • 자주 사용하는 가이드 문서나 사내 규정은 캐싱을 걸어두어 한글 세금으로 인한 비용 증가를 상쇄하는 것이 유리합니다.

③ 대용량 RAG 파이프라인에서 모델 분리

  • 수만 장의 한국어 문서를 검색하고 요약하는 사전 파이프라인에는 한글 압축률이 뛰어난 Qwen 3.7-Plus를 배치합니다.
  • 최종적으로 사용자에게 유려한 문체로 다듬어 응답을 전달하는 엔드포인트에만 Claude Sonnet을 연결하는 ’하이브리드 라우팅’을 적용하면 비용과 품질을 모두 챙길 수 있습니다.

④ 불필요한 공백과 줄바꿈 정리

  • 일부 한글 토크나이저는 연속된 공백이나 불필요한 줄바꿈(\n\n\n)을 각각 독립된 토큰으로 처리합니다.
  • API 호출 전 정규식(re.sub(r'\s+', ' ', text))으로 연속 공백을 정리해 주는 것만으로도 수천 토큰의 낭비를 막을 수 있습니다.

다음 편 예고

모델별 토큰 단가와 토크나이저의 비밀까지 살펴보았습니다.

이어지는 3편 「용도별 AI 모델 선택 가이드 — 코딩부터 대규모 RAG까지 최적 아키텍처」에서는 개인 코딩 에이전트부터 기업용 대규모 RAG까지 비용과 품질을 모두 잡는 최적의 모델 아키텍처 구성법을 다뤄보겠습니다. 어떤 서비스에 어떤 모델을 배치해야 가장 가성비가 높은지 실전 아키텍처를 살펴보겠습니다.