AI에 넣을 한국어 문서는 글자 수만으로 잴 수 없다

한국어 문서의 글자 수와 토큰 수가 다른 이유를 공개 토크나이저의 실측으로 살펴본다. 입력 길이 계산, 잘림으로 사라지는 조건, RAG와 대화 입력의 예산을 구분한다.

토큰 분할을 비유한 AI 생성 개념 이미지. 실제 측정값을 그린 도표가 아니다.

회의록을 AI에 넣기 전에 문서 편집기의 글자 수를 확인한다. 짧아 보이는 한국어 문서이니 입력 한도에도 여유가 있을 것 같다. 그런데 실제 요청을 만들면 예상보다 토큰이 많고, 문서 끝의 조건이 잘려 나가기도 한다. 사람에게 짧은 문장이 모델의 입력에서도 짧다는 보장은 없다.

토큰은 단어 수를 영어로 부르는 말이 아니다. 모델이 처리하도록 텍스트를 나눈 단위이며, 어디에서 나누는지는 토크나이저의 어휘와 규칙에 달려 있다. 같은 문서를 두고도 글자 수, 저장 바이트 수, 토큰 수가 각각 다른 답을 낸다. 한국어 업무 문서의 입력 예산을 잡으려면 이 세 숫자를 구분해야 한다.

한 글자가 한 토큰이라는 약속은 없다

Hugging Face의 토크나이저 안내는 텍스트 정규화와 분할, 토큰 ID 변환, 특수 토큰 처리를 입력 준비 과정으로 설명한다. 모델에는 우리가 보는 문서가 그대로 들어가는 대신, 해당 토크나이저가 만든 ID의 열이 전달된다.

많은 토크나이저는 단어보다 작은 조각을 사용한다. 토큰화 알고리즘 문서가 설명하는 BPE는 학습 자료에서 자주 함께 나타나는 조각을 결합해 어휘와 병합 규칙을 만든다. 실제 입력을 나눌 때는 이렇게 정해진 규칙을 사용한다. 익숙한 문자열은 큰 덩어리로, 어휘에 덜 잘 맞는 문자열은 여러 작은 조각으로 표현될 수 있다.

바이트 수준 BPE에서는 그 조각이 사람이 보는 한 글자보다 작을 수도 있다. 한글 음절 하나를 UTF-8로 저장하는 바이트들과 토큰의 경계가 일치할 필요가 없기 때문이다. 토큰 목록을 출력했을 때 낯선 기호들이 보인다고 해서 원문이 반드시 손상된 것은 아니다. 전체 토큰 열을 다시 디코딩했을 때 원문으로 돌아오는지 별도로 확인해야 한다.

이 원리는 “한국어는 항상 영어보다 몇 배 비싸다”는 고정 환산표를 주지 않는다. 어휘, 병합 규칙, 정규화, 문장 구성에 따라 결과가 달라진다. 모델을 바꾸면서 예전 모델에서 쓰던 글자 수 기준을 그대로 옮기면, 같은 길이라고 판단한 문서들의 실제 입력 길이가 달라질 수 있다.

짧은 문장 네 개를 실제로 세어 보면

2026년 11월 7일, 공개된 SmolLM2-135M의 토크나이저를 내려받아 네 문장을 측정했다. 모델 가중치나 추론은 실행하지 않았다. tokenizers 0.22.2에서 해당 파일을 직접 읽고, 패딩과 입력 잘림을 끄고, add_special_tokens=False로 본문만 인코딩했다. 네 문장 모두 전체 토큰 열을 디코딩한 결과가 입력과 정확히 같았다.

표의 글자 수는 공백과 문장부호를 포함해 Python의 len(text)로 센 유니코드 코드 포인트 수다. 모든 문자 조합에서 사람이 보는 글자 수와 같은 정의는 아니지만, 이 예문의 계산 기준은 고정되어 있다. 한국어 두 문장이 똑같이 13글자여도 토큰은 28개와 24개로 달랐다. 한국어 요청은 영어 요청보다 글자 수가 적으면서도 더 많은 토큰을 사용했다.

다만 이 차이를 현재 AI 서비스 전체의 한국어 비용 비율로 읽어서는 안 된다. SmolLM2는 공식 모델 카드에서 주로 영어를 이해하고 생성하는 모델이라고 밝힌다. 여기서는 공개 파일과 계산 조건을 고정할 수 있어 관찰 대상으로 삼았다. 다른 토크나이저에서도 같은 수치가 나오는지, 어떤 모델이 한국어를 더 잘 이해하는지는 이 실험으로 확인하지 않았다.

마지막 두 문장도 중요한 차이를 보여 준다. 토큰 수가 줄었다는 것만으로 문서가 더 좋아졌다고 판단할 수 없다. “증가하지 않았다”에서 부정을 빼면 길이는 줄지만 사실 관계가 뒤집힌다. 토큰 절약은 표현과 근거를 보존한 뒤에 평가할 조건이다.

입력을 잘라 맞추면 조건도 함께 사라진다

길이를 맞추는 두 작업은 구분할 필요가 있다. 패딩은 짧은 입력에 자리를 채워 배치의 길이를 맞춘다. 잘림, 즉 truncation은 긴 입력에서 토큰 일부를 제외한다. 후자는 요약이나 중요도 판단이 아니다. 길이 제한에 맞춰 자르는 연산이다.

같은 토크나이저로 “이 문서는 업무 보고서입니다. ”를 네 번 쓴 뒤 “단, 외부 공유는 금지합니다.”를 붙였다. 전체는 170토큰이었다. 오른쪽을 자르는 방식으로 최대 길이를 32토큰으로 설정하자, 디코딩한 본문은 “이 문서는 업무 보고서입니다”만 남았다. 마지막 공유 금지 조건은 입력에서 사라졌다.

이는 실제 서비스에서 정보가 유출됐다는 실험이 아니다. 토크나이저가 만든 입력에서 조건이 누락되는 과정을 확인한 합성 사례다. 모델을 호출하지 않았으므로 이후 답변이나 도구 행동은 관찰하지 않았다. 그렇더라도 이 검사는 문제의 위치를 보여 준다. 입력 준비 과정에서 빠진 조건을 뒤 단계 모델의 주의력만으로 되살릴 수는 없다.

따라서 긴 보고서를 처리할 때는 잘림 전후의 토큰 수뿐 아니라 살아남은 내용을 확인해야 한다. 예외 조항, 적용 기간, 표의 단위, 인용 출처처럼 답을 바꾸는 부분이 남아 있는가. 원문을 그대로 넘길 수 없다면 문서 구조에 따라 구간을 나누고, 필요한 조건을 어느 입력에 포함할지 정해야 한다. 단순한 뒤쪽 삭제를 문서 요약으로 취급해서는 안 된다.

업무 예산은 최종 입력에서 계산한다

문서 본문을 세었다고 실제 요청 전체를 센 것은 아니다. 대화 템플릿 안내에 따르면 역할과 내용을 담은 메시지 목록도 모델별 형식과 제어 토큰을 포함한 토큰 열로 바뀐다. 본문에 더해 시스템 지시, 대화 이력, 검색 근거와 역할 구분이 들어간다. 템플릿 적용 전의 문자열 길이와 최종 입력 길이를 혼동하지 않아야 한다.

RAG에서는 검색용 임베딩 모델과 답변 생성 모델이 서로 다른 토크나이저를 쓸 수도 있다. 검색 청크를 만들 때 한 모델의 길이 제한을 맞췄다고, 여러 청크를 합친 생성 요청도 한도 안에 들어가는 것은 아니다. 청크의 제목·출처·보충 문맥까지 합친 뒤 실제 소비 모델의 기준으로 다시 세어야 한다. 검색 단위의 의미 보존은 청크와 문서 맥락을 다룬 글의 문제와 이어진다.

운영 기록에는 모델과 토크나이저의 식별자·리비전, 특수 토큰과 템플릿의 적용 여부, 잘림 전후 길이를 함께 남기는 편이 좋다. 모델 변경을 검토할 때는 팀에서 실제로 다루는 한국어, 숫자, 표, 코드, 약어가 섞인 문서 표본으로 다시 측정한다. 호스팅 API라면 제공자가 지원하는 해당 모델의 토큰 계산과 실제 사용량을 대조해야 한다. 다른 공개 모델의 토크나이저로 센 값은 그 API의 청구량을 증명하지 않는다.

길이를 정확히 재는 일과 무엇을 넣을지 고르는 일은 함께 필요하다. 작업별 맥락 예산이 필수 근거와 여유 공간을 배정한다면, 토큰 계산은 그 배정이 실제 입력 형식에서도 맞는지 확인한다. 입력 한도에 들어갔다는 사실은 내용을 제대로 이해했다는 보증이 아니므로, 최종 답의 근거와 조건 준수도 따로 평가해야 한다.

한국어 문서를 AI에 넘길 때 필요한 기준은 “몇 글자까지 괜찮다”는 하나의 숫자가 아니다. 어떤 토크나이저로, 어떤 형식의 입력을 만들었고, 길이를 맞추는 동안 무엇이 남았는지 확인하는 것이다. 짧아진 문서보다 중요한 것은 업무의 뜻을 지킨 입력이다.

확인한 자료와 측정 범위

• Hugging Face Transformers의 Tokenizers, Tokenization algorithms, Chat templates를 2026년 11월 7일 확인했다. 공개 저장소의 기본 브랜치 main과 해당 문서 파일은 커밋 0f53828e83f2212060233d2ea552cc76617b8712에서 대조했다.
• 직접 측정한 파일은 HuggingFaceTB/SmolLM2-135M의 리비전 93efa2f097d58c2a74874c7e644dbc9b0cee75a2에 있는 tokenizer.json이다. Python 3.14.7, tokenizers 0.22.2를 사용했다. 네 문장의 본문 인코딩과 한 건의 합성 잘림 사례만 실행했으며, 모델 성능·추론 속도·API 비용은 측정하지 않았다.