들어가며
스캐터랩은 자체 LLM으로 제타(zeta)의 수많은 유저에게 매일 새로운 이야기를 전하고 있습니다. 그동안 저희 블로그에서는 가장 재밌는 모델을 찾는 법, 유저 신호로 선호를 학습하는 법, 그것을 온라인으로 학습하는 법을 소개해 드렸는데요. 오늘은 조금 다른 층의 이야기를 해보려고 합니다. 모델이 사람의 글을 이해할 수 있게 만드는 도구, 토크나이저입니다.
한국어와 일본어 전용 토크나이저를 직접 만들고, 이미 학습된 백본에 이어붙이고, 서비스에 실제로 배포하기까지의 이야기입니다. 결과부터 말씀드리면 실서비스에서 GPU 사용량이 절반 가까이 줄었고 유저의 이용 시간은 오히려 늘었습니다. GPU 비용이 천정부지로 치솟고 있는 요즘, 목적에 맞는 단순한 접근만으로도 비즈니스에 큰 임팩트를 낼 수 있다는 것을 보여주는 프로젝트였습니다.
1. 토크나이저 불공정 (tokenizer unfairness)
제타는 한국, 일본, 미국 시장에서 서비스를 하기 위하여 다양한 오픈소스 모델들을 활용합니다. 국가별로 특화된 오픈소스 모델을 쓸 수도 있지만, 운영의 단순함을 위해 성능이 가장 좋은 모델 하나를 골라 각 언어로 학습시켜 사용합니다. 다만 이 선택에는 대가가 따릅니다. 바로 언어별 비효율입니다. 일반적인 오픈소스 모델의 토크나이저는 수십 개 언어를 어휘 사전 하나로 표현해야 합니다. 사전의 크기는 한정되어 있는데 학습 데이터에는 영어가 압도적이니, 그 한정된 자리의 대부분을 영어가 차지합니다. 그렇다면 한국어와 일본어는 공용 토크나이저 안에서 구조적으로 손해를 보고 있을 가능성이 큽니다. 저희는 이 가설을 실제 데이터로 확인해봤습니다.
기존 토크나이저의 10만 개 이상 어휘 가운데 라틴 문자가 들어간 토큰이 2/3였고, 일본어 문자(가나, 한자)나 한글이 들어간 토큰은 각각 5%에 못 미쳤습니다. 단순히 이 수치만으로도 우리가 모델의 임베딩 파라미터들을 비효율적으로 활용하고 있다는 것을 알 수 있습니다.
실제 서비스 환경에서 토크나이저가 얼마나 다양한 토큰을 활용하는지 확인하기 위해, 일본어 서비스 텍스트 800만 자를 잘라 토큰별 등장 횟수를 세어 봤습니다. 전체 어휘 중 3.5%만 한 번 이상 등장했고, 전체 토큰의 99%는 어휘의 1.9%, 약 2,500개에서 나왔습니다. 한국어도 비슷했습니다(4.4%와 2.8%). 십수만 개짜리 어휘를 가진 모델이 일본어를 쓸 때는 사실상 2,500개 어휘만으로 말하고 있었던 거죠. 나머지 96%는 임베딩 파라미터만 차지하고 있는 짐이었습니다.
ㅤ | 일본어 텍스트 | 한국어 텍스트 |
한 번 이상 등장한 어휘 비율 | 3.5% | 4.4% |
전체 토큰의 99%를 차지하는 어휘 비율 | 1.9% | 2.8% |
표 1. 기존 토크나이저의 어휘 중 실제 서비스 텍스트(각 수백만 자)에 등장한 비율.
어휘가 이렇게 적으면 흔한 표현도 잘게 쪼개집니다. 한글 어휘가 몇 천 개뿐이니 "ㅋㅋㅋ", "ㅠㅠ" 같은 자모 표현은 어휘에 없어서 글자 하나가 바이트 단위의 여러 토큰으로 쪼개지고, 웃음과 감탄이 섞인 한 줄 대사가 수십 토큰이 되기도 했습니다. 제타 유저들이 가장 자주 쓰는 표현이 가장 비싼 표현이었던 셈입니다. 같은 의미의 문장을 영어, 한국어, 일본어로 옮긴 병렬 코퍼스 [1]를 일반 토크나이저로 잘라 보면, 영어를 1로 놓았을 때 한국어는 1.32배, 일본어는 1.52배의 토큰이 필요합니다. 같은 GPU로 감당할 수 있는 대화량이 영어의 2/3에 그쳤다는 뜻입니다.
같은 의미의 문장을 영어로 썼을 때와 다른 언어로 썼을 때와 토큰 수가 크게 달라지는 현상은 "토크나이저 불공정(tokenizer unfairness)"이라는 이름으로 연구되어 왔습니다. 2023년 Petrov et al.은 GPT-4 토크나이저가 같은 내용을 일본어로 쓰면 영어의 2.3배, 한국어로 쓰면 2.4배의 토큰을 쓴다는 것을 보였고 [2], 2026년에는 최신 GPT-5 토크나이저로도 저자원 언어의 유효 컨텍스트가 영어의 11%까지 줄어든다는 측정이 나왔습니다 [3]. 이제는 BPE 학습 단계에서 격차 자체를 줄이는 알고리즘(Parity-Aware BPE)까지 제안되는 단계입니다 [4]. 다만 토큰 효율이 곧 downstream 성능은 아니라는 점도 여러 연구가 짚었습니다 [5, 6]. 효율은 비용의 문제고 품질은 따로 확인해야 하는데, 저희도 뒤에서 이 둘을 분리해서 보겠습니다.
프론티어 모델들도 토크나이저를 계속 바꾸고 있습니다. OpenAI는 GPT-4o에서 어휘를 두 배로 늘려 한국어 1.7배, 일본어 1.4배의 토큰 절감을 내세웠고 [7], 이후 주요 오픈 모델들도 어휘를 20만~26만 개로 키우는 추세입니다. 반대 방향도 있습니다. Anthropic은 2026년 Claude의 토크나이저를 교체하면서 토큰이 약 30% 늘어난다고 공지했는데, 독립 측정에 따르면 그 증가는 영어와 코드에 집중되고 한국어·일본어·중국어는 거의 변하지 않았습니다 [8].
한국어와 일본어를 주력으로 하는 팀들도 같은 결론에 도달했습니다. 2026년 1월 한 달 사이에 SKT의 A.X K1, LG의 K-EXAONE, Upstage의 Solar Open이 각각 어휘를 새로 설계했고 [9, 10, 11], 일본에서는 SB Intuitions의 Sarashina3가 GPT-5보다 32% 적은 토큰으로 일본어를 처리한다고 발표했습니다 [12]. 다만 이들은 모두 자국어 중심으로 처음부터 사전학습한 모델입니다. 저희처럼 이미 학습된 오픈소스 백본 위에서 시작하는 경우에는 기존 어휘에 자국어 토큰을 덧붙이는 확장이 일반적이었고, 최근에는 어휘 크기와 토큰 번호를 그대로 둔 채 쓰이지 않는 자리만 교체하는 방식도 제안되고 있습니다 [13]. 저희의 선택은 후자에 가깝습니다. 백본도 어휘 크기도 그대로 두고, 어휘의 내용만 주력 언어로 통째로 바꾸는 것입니다. 파라미터가 늘지 않고 사전학습을 다시 하지 않아도 되지만, "옛 어휘로 학습된 모델에 새 어휘를 어떻게 이어붙이느냐"가 관건이 됩니다. 이 부분은 4장에서 이야기하겠습니다.
2. 토크나이저를 교체하는 방법
토크나이저를 바꾸면 모델의 입력 임베딩과 출력층(어휘마다 한 행씩 있습니다)이 통째로 의미를 잃습니다. 학습된 모델은 3번 토큰이 ‘안녕’이라고 알고 있는데, 새로운 토크나이저에서 3번 토큰은 전혀 다른 의미를 가지니까요. 의미적인 불일치를 해결하기 위한 토크나이저 교체 방법에는 다음과 같이 세 가지 방법이 있습니다.
- 확장: 기존 어휘는 그대로 두고 한국어, 일본어 토큰을 추가합니다.
- 공유 교체: 한국어, 일본어, 영어를 모두 담는 새 토크나이저 하나로 바꿉니다.
- 언어별 전용 교체: 한국어 모델은 한국어 토크나이저, 일본어 모델은 일본어 토크나이저를 씁니다.
일단 여기서 1번은 제외하였습니다. 아랍어, 그리스어와 같이 당장 지원하지 않을 언어들의 어휘를 모두 유지하면서 파라미터 수를 키우는 것은 비효율적이라고 판단하였습니다. 저희는 2번과 3번 사이에서 고민하였습니다. 2번과 3번 버전으로 각각 같은 어휘 크기로 토크나이즈를 하였을 때 전용이 공유보다 한국어 4%, 일본어 8% 더 효율적이었습니다. 생각보다 큰 차이는 아니었습니다. 공유 토크나이즈는 언어와 상관없이 통일된 토크나이저를 가져간다는 측면에서 운영적으로 용이하고 향후 여러 언어를 동시에 지원하는 모델을 준비하기에도 좋았습니다.
하지만 저희는 시장별 전용 토크나이저를 사용하기로 결정하였습니다. 그 이유는 현재 제타가 시장별로 독립된 모델을 대규모로 운영하는 상황에서 조금의 효율도 큰 개선으로 이어질 수 있다는 점도 있지만 향후 운영 방향에 대한 고려도 있었습니다. 만약 제타가 새로운 언어의 모델을 추가하게 되었을 때 이 정책을 유지한다면 그 언어를 포함한 새로운 공유 토크나이저를 만들어 기존 모델들을 모두 교체해야 합니다. 한 언어를 추가할 때 마다 기존 모든 모델을 교체하는 방식은 비효율적이라고 판단했습니다.
전용 토크나이저를 만들면서도 어휘수는 기존과 똑같이 유지했습니다. 모든 언어가 같은 크기의 어휘가 필요한 것은 아니지만 그동안 내부적으로 현재 모델 사이즈에서의 연구 데이터가 축적되어왔기 때문에 굳이 바꾸지 않았습니다. 단, 영어 전용 토크나이저는 새로 만들지 않았습니다. 이미 영어는 대부분의 토크나이저에서 효율적으로 구성이 되어있기 때문에 전용 토크나이저를 구성하더라도 이점이 크지 않았기 때문입니다. 그만큼 기학습된 모델에서 토크나이저를 교체하는 것은 큰 이점이 없다면 왠만하면 감수하고 싶지 않은 위험한 방법이라고 판단한 것도 있습니다.
3. 토크나이저 만들기
BPE 토크나이저는 학습 코퍼스에 자주 나오는 조각을 하나씩 합쳐 가며 어휘를 만드는 알고리즘입니다. 어떤 텍스트를 넣으면 그 텍스트에서 자주 나오는 표현이 짧아지고, 넣지 않은 텍스트는 그만큼 길어집니다. 정해진 어휘 크기 안에서 어디에 어휘를 쓸지 배분하는 문제인 거죠.
저희가 노린 것은 두 가지였습니다. 하나는 당연히 언어입니다. 영어에 몰려 있던 어휘를 한국어와 일본어로 가져오는 것. 다른 하나는 조금 덜 당연한데, 제타라는 서비스 자체입니다. 제타의 대화는 생각보다 일반적인 텍스트들과는 다릅니다. *와 같이 제타에서만 쓰이는 특수한 표현 뿐만 아니라 자/모음과 같이 대화체에서만 나오는 특유의 문체들은 책이나 뉴스에 거의 없는 패턴입니다. 제타에서만 쓰일 토크나이저라면 제타의 문체에 가장 최적화된 토크나이저가 가장 효율적일 것입니다.
그래서 코퍼스를 네 종류로 구성하였습니다. 문어체의 장문 서사 텍스트가 모델의 문장력을 지켜 주는 어휘를 만들고, 실제 서비스 대화 로그가 화자 표기나 지문, 자모 표현 같은 도메인에서의 분포를 가르칩니다. 여기에 저희 서비스의 프롬프트 형식 만으로 구성된 텍스트(마크업과 시스템 프롬프트)와 소량의 영어를 더했습니다. 언어당 20억 자 규모입니다. 이 네가지 코퍼스 비율을 조금씩 바꿔가며 비교해 보았습니다.
가장 큰 트레이드오프는 서사와 대화 사이에 있었습니다. 대화 비중을 올리면 대화 효율은 오르지만 장문 서사의 효율이 훨씬 빠르게 무너졌습니다. 한 지점에서는 대화가 4.8% 좋아지는 동안 서사가 18.4% 나빠졌습니다. 제타는 대화 서비스지만 모델의 문장력은 서사 텍스트에서 오기 때문에, 대화는 30% 근처에서 멈췼습니다. 프롬프트 형식 텍스트는 5%면 충분했습니다. 비중을 4배로 늘려 봐도 마크업 토큰 수는 거의 줄지 않고 서사 효율만 나빠졌거든요. 영어도 아예 빼 보았는데, 일본어 모델이라도 프롬프트와 대사 안에는 영어 단어와 마크업이 섞여 있어서 영어 0%에서는 마크업 한 줄이 42토큰이 됐습니다. 5%를 넣으니 39토큰으로 내려오고, 그 이상은 큰 변화가 없었습니다.
다 만들고 나서 공개 한국어 코퍼스만으로 학습한 토크나이저와 서비스 텍스트를 30% 섞은 토크나이저를 같은 어휘 크기로 만들어 실제 서비스 텍스트에 적용해 비교해 보았습니다. 한국어 코퍼스만으로도 기존보다 토큰이 24% 줄었는데, 서비스 텍스트를 섞으니 13.5%가 더 줄었습니다. 대략 이득의 7할은 어휘를 한국어에 집중한 데서, 3할은 제타에서의 표현을 배운 데서 온 셈입니다.
4. 토크나이저 이식
토크나이저를 만들었으면 모델에 이어붙여야 합니다. 새 토큰 하나는 옛 토크나이저에서는 여러 조각이었을 테니, 그 조각들의 임베딩 평균을 새 토큰의 초기값으로 씁니다. EEVE가 쓴 방식이고 [14], 여러 초기화 기법을 비교한 연구에서도 이 단순한 평균이 대부분의 경우 가장 안정적이었습니다 [15].
이어붙인 다음에는 두 단계로 학습했습니다. 먼저 임베딩을 제외한 모델 파라미터들을 고정하고 임베딩만 짧게 워밍업해서 새 토큰이 제자리를 찾게 하고, 그 다음 전체를 풀어 수백억 토큰 규모의 continued pre-training(CPT)을 돌렸습니다.
이 부분이 가장 초조했던 부분이었습니다. 큰 리소스가 들어가는 것에 비해서 모델이 잘 학습되고 있는지 확인하기 어려웠기 때문입니다. 토크나이저가 다른 두 모델의 loss는 서로 비교할 수 없습니다. 토큰 하나가 더 많은 글자를 담는 모델은 토큰당 loss가 당연히 높습니다. 맞혀야 할 정보가 더 많으니까요. 그래서 저희는 모든 비교를 글자당 NLL(또는 bits-per-byte)로 환산해서 판단했습니다. 이를 통해 학습이 정상적으로 이루어지고 있는 점을 확인할 수 있었습니다.
5. 새 토크나이저 학습 검증
같은 SFT 데이터로 기존 백본과 새 토크나이저 백본을 각각 학습해서 실제 일본 유저에게 A/B로 내보냈습니다. 다른 건 모두 같고, 토크나이저(와 그에 따른 CPT)만 다릅니다.
ㅤ | 기존 토크나이저 | 일본어 전용 토크나이저 |
유저당 이용 시간 | 기준 | −0.5% (오차 범위 내) |
턴당 출력 토큰 | 기준 | −45% |
턴당 입력 토큰 | 기준 | −34% |
턴당 응답 지연 | 기준 | −52% |
재생성률 | 기준 | +1~3pp (소폭 악화) |
토큰당 글자 수 | 기준 | 1.7배 |
길이 상한에 걸린 응답 | 11.7% | 0.2% |
표 2. 동일 SFT 데이터, 토크나이저만 다른 두 모델의 A/B 결과 (일본, 각 군 수만 명, 24시간).
결과는 생각보다 더욱 놀라웠습니다. 이용 시간으로 본 품질은 그대로인데 같은 대화를 절반의 토큰으로 처리하고 응답은 두 배 빨라졌습니다. 1장의 병렬 코퍼스로 다시 재 보면 같은 내용에 필요한 토큰 수는 영어 대비 일본어 1.52에서 0.92로, 한국어 1.32에서 0.98로 내려와 영어와 같은 수준이 됩니다. 응답의 글자 수는 거의 같았습니다(−7%). 유저에게 전달되는 내용은 그대론데 절반의 토큰만 사용한 것입니다.
덤으로 발견한 것도 있습니다. 기존 모델은 응답의 약 12%가 길이 상한에 걸려 문장 중간에서 끊기고 있었습니다. 영어 모델에서는 거의 없는 일인데요. 새 토크나이저에서는 이 비율이 0.2%로 내려가 사실상 사라졌습니다.
6. 새 백본 위에 쌓은 모델, 그리고 전체 배포
새 토크나이저 백본 위에 저희가 그동안 해 오던 SFT와 선호 최적화 사이클을 다시 돌렸습니다. 그 결과 모델을 기존 프로덕션 모델과 3군 A/B로 비교했습니다. 각 군 십만 명 이상, 11일입니다.
지표 | 기존 프로덕션 | 새 백본 모델 (2종) |
유저당 총 이용 시간 | 기준 | +8.2% / +7.3% (z > 10) |
평균 세션 길이 | 기준 | +6% |
재생성률 (답변을 버린 비율) | 40.5% | 32.6% / 34.6% |
D7 리텐션 | 기준 | +1.4pp / +0.8pp |
GPU pod-hour / 백만 턴 | 기준 | −46% |
표 3. 프로덕션 A/B 결과. GPU는 동일 기종, 세 군의 트래픽 비중은 동일.
유저 쪽에서 먼저 보이는 건 컨텍스트입니다. 같은 컨텍스트 창에 들어가는 대화가 글자 수로 1.75배가 됐습니다. 모델이 열 턴 전에 나온 설정을 기억하고, 유저가 오래 쌓아 온 관계의 맥락을 놓치지 않는 범위가 그만큼 넓어진 겁니다. 응답이 길이 상한에 걸려 중간에 끊기는 일도 사라졌고, 답이 두 배 빨리 오니 유저는 같은 시간에 더 많은 턴을 주고받았습니다(+17%). 세션은 6% 길어지고 답변을 버리는 재생성은 40%에서 33%로 줄었습니다. 이용 시간 8%는 이것들이 합쳐진 결과입니다.
모델 쪽에서도 같은 일이 벌어집니다. 저희 SFT와 선호 최적화는 정해진 시퀀스 길이 안에서 대화를 잘라 학습하는데, 토큰이 절반이 되니 같은 길이에 담기는 대화 턴이 두 배 가까이 늘었습니다. 모델이 학습 중에 보는 맥락이 그만큼 길어졌다는 뜻입니다. 똑같은 선호 최적화 사이클을 돌렸는데 결과가 더 좋아진 이유를 저희는 여기서 찾고 있습니다. 더 긴 맥락 위에서 선호를 배운 모델이 더 긴 맥락을 유지하는 답을 내놓게 된 것이 아닐까 추정합니다.
이 모델은 이후 일본 전체 유저에게 배포됐습니다. 배포와 함께 GPU 한 장이 감당하는 동시 유저 수 설정을 1.8배로 올렸고, 그 상태로 프로덕션 GPU pod-hour는 트래픽이 조금 늘어나는 와중에도 41% 줄었습니다. 턴당 응답 지연도 약 40% 줄었습니다. 같은 GPU로 두 배 가까운 유저에게, 더 긴 기억을 가진 모델을, 더 빨리 서빙하게 된 셈입니다.
7. 남은 숙제였던 반복
좋은 이야기만 있었던 건 아닙니다. 새 백본 모델은 "같은 문장을 반복한다"는 유저 신고가 기존 모델보다 41% 많았습니다. 다른 카테고리의 신고는 같거나 줄었는데 이 항목만 튀었죠.
해결은 뜻밖에 학습이 아니라 디코딩에서 나왔습니다. 기존에 관성적으로 사용하던 생성 파라미터 중 nucleus sampling[16]의 top_p를 0.8에서 1.0으로 올리자 반복 신고가 69% 줄어 기존 모델보다도 낮아졌고, 이용 시간은 변하지 않았습니다.
저희가 추정한 이유는 다음과 같습니다. 기존에 top_p가 0.8이 효과적이었던 이유는 어차피 토큰의 대부분이 쓰이지 않았기 때문에 적은 가능성의 토큰들을 과감하게 버리는 것이 더 나았기 때문입니다. 하지만 새로 학습한 언어별 어휘에서는 기존의 내용을 반복하는 토큰도 포함되지만 더욱 다양한 확률 분포를 가지고 있는 상황에서 0.8이 그 선택지를 좁혔기 때문으로 추정하고 있습니다.
마치며
토크나이저는 단순히 비용 항목이 아니라 모델이 언어를 보는 해상도와 같습니다. 같은 모델, 같은 데이터, 같은 GPU로 일본어 유저에게 두 배 빠르고 끊기지 않는 답을 줄 수 있었고, 그 위에 쌓은 개선은 이용 시간 8% 증가로 이어졌습니다. 이미 존재하는 방법을 활용한 단순한 기법이지만 저희 서비스의 맥락에 맞는 연구와 의사결정을 통하여 서비스에 큰 임팩트를 줄 수 있었습니다. 스캐터랩 모델팀에서는 단순히 벤치마크에서 끝나는 연구를 넘어 비용과 매출, 그리고 유저에게 실질적인 임팩트를 줄 수 있는 연구를 진행하고 있습니다. 토크나이저부터 강화학습, 서빙 최적화까지 모델 파이프라인의 모든 층에서 함께 고민할 동료를 기다리고 있습니다. 읽어주셔서 감사합니다.
참고 문헌
[1] Federmann et al., NTREX-128 – News Test References for MT Evaluation of 128 Languages, 2022.
[2] Petrov et al., Language Model Tokenizers Introduce Unfairness Between Languages, NeurIPS 2023.
[3] Somide, The African Language Tax: Tokenization Disparities Across 20 African Languages, arXiv 2606.24460, 2026.
[4] Foroutan et al., Parity-Aware Byte-Pair Encoding, ACL 2026.
[5] Ali et al., Tokenizer Choice For LLM Training: Negligible or Crucial?, Findings of NAACL 2024.
[6] Lotz et al., Beyond Text Compression: Evaluating Tokenizers Across Scales, ACL 2025.
[7] OpenAI, Hello GPT-4o, 2024.
[8] Anthropic, Claude Opus 4.7 release notes, 2026; S. Willison, Claude's new tokenizer, 2026-04-20 (독립 측정).
[9] SK Telecom, A.X K1 Technical Report, arXiv 2601.09200, 2026.
[10] LG AI Research, K-EXAONE Technical Report, arXiv 2601.01739, 2026.
[11] Upstage, Solar Open Technical Report, arXiv 2601.07022, 2026.
[12] SB Intuitions, Sarashina3 のトークナイザについて, 기술 블로그, 2026-08-07.
[13] Didenko, Writing-System-Level Tokenizer Adaptation for Byte-Level BPE, arXiv 2608.00582, 2026.
[14] Kim et al., Efficient and Effective Vocabulary Expansion Towards Multilingual Large Language Models (EEVE), 2024.
[15] Yamaguchi et al., How Can We Effectively Expand the Vocabulary of LLMs with 0.01GB of Target Language Text?, 2024.
[16] Holtzman et al., The Curious Case of Neural Text Degeneration, ICLR 2020.
Share article