토크나이저(Tokenizer)는 여러분이 모델에 보낸 문장이 가장 먼저 거치는 부품으로, 이해를 담당하지 않고 자르고 번호를 매기는 일만 합니다. 텍스트가 대규모 모델에 들어가기 전에 토크나이저는 먼저 그것을 token 단위로 자른 뒤 어휘표의 번호로 바꿉니다. 모델이 실제로 읽는 것은 이 번호들의 나열입니다. 이 점만 이해해도 많은 의문이 풀립니다. token은 글자도 아니고 단어도 아닙니다.
자르는 기준은 글자가 아니라 등장 빈도
현재 주류 토크나이저는 대부분 BPE(바이트 쌍 인코딩)라는 알고리즘을 씁니다. 학습 과정에서 알고리즘은 어떤 문자 조합이 함께 자주 등장하는지 세고, 자주 등장할수록 통째로 하나의 token으로 합쳐지기 쉽습니다. 그 결과 흔한 단어와 자주 쓰이는 부분 단어는 덩어리째 남는 경우가 많아 영어 단어 하나가 token 1개가 되기도 하고, 생소한 단어나 이름, 신조어는 더 잘게 쪼개져 한 단어가 서너 조각으로 나뉘기도 합니다.
공백, 문장부호, 숫자, 코드도 자르는 대상에 포함되며 규칙이 직관적이지 않습니다. 영어에서는 단어 앞의 공백이 단어와 묶여 같은 token으로 계산되는 경우가 많고, 줄바꿈, 연속된 숫자, 들여쓴 코드는 각각 따로 처리됩니다. 그래서 같은 내용이라도 서식을 조금 바꾸면 token 수가 달라질 수 있습니다.
같은 문장인데 모델이 바뀌면 왜 수가 다를까
모델마다 어휘표는 따로 학습되며 크기, 병합 규칙, 중점을 두는 언어가 모두 다릅니다. 어휘표가 클수록 긴 조각을 통째로 유지하는 경우가 대체로 많습니다. 중국어 커버리지가 좋은 어휘표에서는 한자 한 글자가 token 1개일 수 있지만, 커버리지가 나쁘면 한 글자가 바이트 단위의 여러 token으로 쪼개지기도 합니다.
이것이 제목의 질문에 대한 답입니다. 경험적으로 영어에서 token 1개는 대략 3~4글자에 해당합니다. 중국어는 편차가 훨씬 커서 한 글자가 token 1개를 차지하는 일이 흔하고, 2개 이상이어도 이상할 것이 없으며, 어떤 모델인지에 달려 있습니다. A 모델의 개수로 B 모델의 사용량을 가늠했는데 맞지 않는 것은 정상이며, 어느 모델이 잘못 센 것이 아닙니다.
token 수는 실제 비용과도 직결됩니다. 사용량 과금에서는 입력과 출력 대부분이 token 단위로 정산되고, 컨텍스트 창의 상한과 한 번에 넣을 수 있는 대화 기록의 양도 token으로 셉니다. 생성해야 할 token이 많을수록 답장은 보통 느려집니다. 지식베이스를 만들 때는 더 분명해집니다. RAG란 정확히 무엇인가? 파인튜닝, 프롬프트 엔지니어링과의 차이에서 다룬 문서 청크 나누기 역시 글자 수가 아니라 token을 기준으로 하며, 청크가 너무 크면 창을 낭비하고 너무 작으면 의미가 끊기기 쉽습니다.
자주 틀리는 세 가지 계산
첫째는 글자 수로 비용을 바로 가늠하는 것입니다. 글자 수와 token 수 사이에는 고정된 환산이 없고, 영어와 중국어, 코드가 섞이면 오차는 더 커져서 글자 수로 잡은 예산은 낮게 나오기 쉽습니다.
둘째는 중국어가 무조건 더 저렴하다거나 무조건 더 비싸다고 단정하는 것입니다. 더 정확히 말하면 이렇습니다. 주류 어휘표 대부분에서는 같은 뜻을 말할 때 중국어가 영어보다 token을 더 많이 쓰는 편인데, 영어의 흔한 단어는 통째로 맞아떨어지기 쉽고 중국어는 쪼개지기 쉽기 때문입니다. 하지만 절대적인 법칙은 아닙니다. 중국어에 잘 최적화된 어휘표로 바꾸면 격차는 눈에 띄게 줄어드니, 결론은 항상 구체적인 모델에 붙여서 내려야 합니다.
셋째는 token 수를 모델 성능의 증거로 여기는 것입니다. 같은 문장이 어떤 모델에서는 80 token, 다른 모델에서는 110 token이라 해도 그것은 자르는 방식이 다르다는 뜻일 뿐, 누가 더 똑똑한지와 직접적인 관계는 없습니다. 어휘표 설계는 원래 맞바꿈입니다. 어휘표가 크면 거칠게 자르지만 token 하나를 표현하는 비용이 커지고, 어휘표가 작으면 잘게 자르는 대신 배열이 길어집니다.
토크나이저가 할 수 없는 일
토크나이저는 모델 자체가 아닙니다. 텍스트를 어떤 단위로 넣을지만 정할 뿐, 의미를 이해하지도, 문장이 맞는지를 판단하지도 않습니다. 자르는 방식이 적절하냐에 따라 모델의 실력 발휘가 달라지기는 합니다. 엉성하게 자르면 숫자 연산이나 생소한 단어의 이해가 더 힘들어지지만, 이해와 추론은 결국 모델 파라미터의 일입니다. 이 둘을 구분해야 토크나이저에 과한 기대를 걸거나 엉뚱한 대상을 탓하지 않게 됩니다.
일상에서 쓸 수 있는 간단한 점검법이 있습니다. 비용과 길이를 가늠할 때 글자 수를 머리로 세지 말고, 지금 쓰는 모델에 맞는 토큰 카운터 도구로 실제 텍스트를 한 번 세어 보세요. 시스템 프롬프트, 대화 기록, 출력 여유까지 함께 넣고 20% 정도의 여유를 두는 것이 좋습니다. 글자 수가 아니라 token 기준으로 예산을 잡는 습관이 들면 청구서와 컨텍스트 초과는 대부분 미리 피할 수 있습니다.
