처음에는 제 실수라고 생각했습니다. 영어 테스트 문서로 월 예산을 잡았는데, 실제 한국어 문서를 넣었더니 토큰이 두 배 가까이 나왔습니다. 프롬프트를 뒤지고, 설정을 확인하고, 혹시 중복 호출이 있나 로그를 뒤졌습니다. 결론은 제 코드 문제가 아니었습니다. 한국어 자체가 현재 대부분의 대형 언어 모델 토크나이저 구조에서 구조적으로 불리하다는 사실, 그걸 깨닫는 데 꽤 시간이 걸렸습니다.
이 경험을 공유하는 이유는 단순합니다. 한국어 LLM 서비스를 만들 때 가장 먼저 맞닥뜨리는 이 비용 구조 문제에서, 생각보다 많은 분들이 같은 곳에서 넘어집니다. 저처럼 청구서를 받고 나서야 알게 되는 게 아니라, 미리 설계 단계에서 고려할 수 있도록 이 글을 씁니다.
지금 돌이켜보면 이 문제는 충분히 예측 가능했습니다. 영어 중심으로 학습된 모델에 한국어를 집어넣으면 비효율이 생긴다는 건 토크나이저 개념을 조금만 알았어도 짐작할 수 있었습니다. 그 개념 공부를 소홀히 한 것이 첫 번째 실수였고, 프로토타이핑 단계에서 한국어 샘플로 토큰을 먼저 재지 않은 것이 두 번째 실수였습니다.
한국어가 토크나이저에서 불리한 이유
현재 대부분의 대형 언어 모델은 BPE(Byte Pair Encoding) 방식의 토크나이저를 사용합니다. BPE는 자주 등장하는 문자 조합을 하나의 토큰으로 묶는 알고리즘입니다. 핵심은 학습 데이터에서 많이 등장한 언어일수록 더 긴 문자열을 하나의 토큰으로 처리한다는 점입니다. 영어는 단어 하나가 토큰 하나에 가깝게 처리되는 반면, 한국어는 같은 의미를 전달하는 문장이 훨씬 많은 토큰으로 쪼개집니다.
tiktoken으로 직접 측정해봤을 때의 기억이 아직도 선명합니다. tiktoken은 OpenAI가 공개한 토큰 계산 라이브러리로, 특정 텍스트가 몇 개의 토큰으로 분해되는지 정확히 확인할 수 있습니다. 영어 200자짜리 문장과 같은 내용의 한국어 번역문을 각각 토큰화해봤더니, 한국어 쪽이 1.8배에서 2.2배 사이로 토큰이 많이 나왔습니다. 처음에는 프롬프트를 잘못 설계한 줄 알고 한참을 헤맸습니다. 나중에서야 이게 언어 구조 자체의 문제라는 걸 알았을 때의 허탈함이 아직도 남아 있습니다.
한국어가 이렇게 불리한 이유는 토큰 어휘 사전(vocabulary) 구성에 있습니다. 어휘 사전이란 모델이 학습 시 미리 정해둔 토큰 목록인데, 대부분의 주요 모델은 영어 중심으로 이 사전이 구성되어 있습니다. 그 결과 한글 음절이나 자모 단위로 잘게 쪼개질 수밖에 없고, 같은 정보량을 전달하더라도 한국어는 더 많은 토큰을 소비하게 됩니다. 이건 곧 API 호출 비용의 직접적인 상승으로 이어집니다.
여기서 한 가지 더 짚고 싶은 점이 있습니다. 이 문제는 단순히 "한국어가 비효율적"이라는 식으로 넘어가기엔 실무에서 파급력이 큽니다. 서비스 기획 단계에서 영어 기반 레퍼런스를 그대로 가져와 비용을 추정하는 경우가 많은데, 그 수치는 한국어 서비스에 그대로 적용되지 않습니다. 제 경험상 견적 단계에서 영어 비용 기준으로 최소 1.5배를 곱하는 습관이 필요합니다. 이걸 몰랐던 초기에 잡았던 예산과 실제 청구 금액의 차이를 경험하고 나면 절대 잊히지 않습니다.
시스템 프롬프트 최적화와 비용 절감의 트레이드오프
시스템 프롬프트를 영어로 작성하면 토큰이 줄어든다고 알려져 있습니다. 실제로 써봤습니다. 지시사항 전체를 영어로 작성하고 마지막에 "반드시 한국어로 답변하라"는 한 줄만 추가했더니 시스템 프롬프트 토큰이 눈에 띄게 줄었습니다. 프로토타이핑 단계에서는 꽤 유의미한 차이였습니다.
그런데 저는 이 전략에 조건을 달고 싶습니다. Claude나 GPT-4o 계열처럼 한국어 지시사항 이해도가 충분히 높은 모델에서는 영어 프롬프트로 바꿔도 출력 품질 차이가 거의 없습니다. 하지만 경량 모델이나 특정 도메인에 파인튜닝된 모델은 다를 수 있습니다. 파인튜닝이란 기존 사전 학습 모델을 특정 목적에 맞게 추가 학습시키는 과정인데, 이 과정에서 특정 언어의 지시 추종률이 달라지는 경우가 있습니다. 비용을 아끼려다 서비스 품질이 떨어지면 더 큰 손해입니다.
이 점에서 블로그나 커뮤니티에서 "영어 프롬프트로 바꾸면 비용 절감"이라는 식의 단순화된 조언에 비판적입니다. 그 조언이 틀렸다는 게 아니라, 조건이 빠져 있다는 겁니다. 어떤 모델을 쓰느냐, 어떤 도메인이냐, 지시 추종률 변화를 측정했느냐, 이 맥락 없이 "영어로 쓰면 좋다"는 말은 반쪽짜리 정보입니다. 그 반쪽을 믿고 따라갔다가 서비스 품질이 흔들리는 경험을 한 팀을 옆에서 본 적이 있습니다.
비용 절감 전략을 도입할 때는 반드시 지시 추종률(instruction following rate)을 함께 측정해야 합니다. 지시 추종률이란 모델이 주어진 지시사항을 얼마나 정확히 따르는지를 나타내는 지표입니다. 이 수치가 떨어지면 후처리 비용이나 사용자 이탈로 더 큰 손실이 생깁니다. 이 경험 이후로 한국어 프로젝트를 시작할 때 반드시 샘플 100건을 뽑아 평균 토큰을 먼저 측정하고, 영어 프롬프트 전환 시 품질 변화도 A/B 테스트 방식으로 확인하는 루틴을 만들었습니다.
Anthropic 공식 문서에 따르면 Claude는 다양한 언어에서 높은 이해도를 유지하도록 설계되어 있어 영어 프롬프트로 한국어 출력을 유도하는 방식이 비교적 안정적이라고 밝히고 있습니다. 그러나 이게 모든 모델에 해당하는 이야기는 아니므로, 본인이 사용하는 모델에서 직접 검증하는 과정을 건너뛰면 안 됩니다.
비용과 품질 사이의 균형이 핵심이다
결국 토큰 최적화는 단순히 프롬프트 언어를 바꾸는 문제가 아닙니다. 모델 특성과 서비스 요구 품질을 함께 고려하는 설계 문제입니다. 비용만 보고 최적화하면 품질이 무너지고, 품질만 보고 설계하면 예산이 터집니다.
이 둘 사이의 균형을 찾는 과정에서 측정이 전제되어야 합니다. 측정 없이 "이렇게 하면 좋다"는 말은 경험담이지 근거가 아닙니다. 내 서비스의 실제 데이터로 측정하고, 그 측정 결과를 바탕으로 판단하는 것이 유일하게 신뢰할 수 있는 방법입니다.
한국어 LLM 서비스를 계획하고 있다면, 영어 기반 비용 계산을 그대로 가져오지 마세요. 반드시 한국어 샘플로 토큰을 직접 재어보는 것부터 시작하시길 권합니다. tiktoken 한 번 돌려보는 그 한 번의 측정이 나중의 예산 충격을 막아줍니다. 그리고 영어 프롬프트 전환을 고려한다면, 비용 절감 효과와 함께 출력 품질 변화를 반드시 함께 확인하는 습관을 만드세요. 비용과 품질 사이의 트레이드오프를 함께 측정하는 그 습관이 결국 가장 중요합니다.
출처 및 참고
- OpenAI 토크나이저 공식 도구: https://platform.openai.com/tokenizer
- tiktoken 라이브러리: https://github.com/openai/tiktoken
- BPE 토크나이제이션 연구: https://arxiv.org/abs/1508.07909
- 다국어 토큰 효율 분석: https://blog.openai.com/new-and-improved-embedding-model/
- Anthropic 다국어 지원 문서: https://docs.anthropic.com/ko/docs/about-claude