프롬프트 정제기가 보여주는 토큰 수는 가짜다 — 0.25 근사식의 함정

가이드 · 2026-08-19 최종 확인

프롬프트 정제 도구에서 정제 전후로 "~토큰: 1,234 → 987"처럼 숫자가 줄어드는 걸 보면 실제로 API 비용이나 컨텍스트 사용량이 그만큼 줄었다고 믿기 쉽습니다. 하지만 이 숫자는 실제 토크나이저를 돌린 값이 아니라, 문자 수에 고정 비율을 곱한 근사치입니다. 이 가이드는 그 근사식이 정확히 무엇이고, 왜 한국어에서 특히 신뢰할 수 없는지 설명합니다.

1. 실제 소스 코드에 박혀 있는 근사식

modoohub.com의 프롬프트 정제기(prompt-cleaner.html)를 직접 열어보면, 토큰 수를 계산하는 함수는 이렇게 되어 있습니다.

즉 문자 4개당 토큰 1개라는 단순 선형 비율입니다. 이 도구의 자체 FAQ에도 "실제 토크나이저를 실행하지 않고 문자 수 × 0.25라는 근사식만 사용합니다"라고 명시돼 있어, 숨겨진 버그가 아니라 의도된 단순화입니다.

2. "4글자당 1토큰"은 어디서 온 숫자인가

OpenAI의 tiktoken이나 Claude의 토크나이저는 BPE(Byte-Pair Encoding) 계열 알고리즘으로, 자주 등장하는 바이트/문자 조합을 하나의 토큰으로 병합하도록 대량의 텍스트로 학습된 어휘 사전을 사용합니다. 영어 산문을 이 방식으로 토큰화하면 평균적으로 문자 4개당 토큰 1개 정도가 나온다는 것이 널리 알려진 경험적 수치입니다. 이 도구의 0.25 계수는 바로 이 영어 기준 경험치를 그대로 가져다 쓴 것입니다.

3. 왜 한국어에서 유독 크게 어긋나는가

BPE 어휘 사전은 학습 데이터의 언어 분포를 그대로 반영합니다. 대부분의 범용 토크나이저는 학습 코퍼스에서 영어 비중이 압도적으로 높기 때문에, 영어의 흔한 단어·접두사·접미사 조합은 통째로 하나의 토큰으로 묶여 있는 경우가 많습니다. 반면 한글은 어휘 사전에서 상대적으로 덜 최적화돼 있어, 음절 하나하나 혹은 음절을 이루는 바이트 시퀀스가 여러 토큰으로 쪼개지는 경우가 흔합니다. 그 결과 같은 글자 수라도 한국어 텍스트의 실제 토큰 수는 "문자 수 × 0.25" 공식이 예측하는 값보다 훨씬 많이 나오는 경우가 많습니다 — 이 근사식은 한국어에서 실제 토큰 소비량을 체계적으로 과소평가하는 방향으로 어긋납니다.

4. 실무에서 벌어지는 일

이 도구로 프롬프트를 정제한 뒤 화면의 "절약된 토큰 수"만 보고 "이제 컨텍스트 창에 여유가 생겼다" 또는 "API 비용이 이만큼 줄었다"고 판단하면, 특히 한국어 프롬프트에서는 실제 값과 차이가 날 수 있습니다. 절약률(%) 역시 같은 근사식으로 정제 전후 값을 계산한 것이므로 똑같은 오차를 그대로 물려받습니다. 정제 기능 자체(공백 정리·빈 줄 처리·탭 변환 등)는 실제로 문자 수를 줄여주므로 유효하지만, 화면에 뜨는 토큰 숫자를 실제 청구/컨텍스트 계산의 근거로 쓰는 것은 위험합니다.

5. 정확한 토큰 수가 필요하다면

• OpenAI 계열 모델: tiktoken 라이브러리(또는 이를 감싼 온라인 도구)로 실제 인코딩을 돌려 토큰 수를 확인하세요.
• Claude 계열 모델: Anthropic API/SDK가 제공하는 토큰 카운트 기능을 사용하세요.
• 비교가 목적이라면: 정제 전 텍스트와 정제 후 텍스트를 각각 위 방법으로 실제 토큰화해서 직접 차이를 확인하는 것이 유일하게 신뢰할 수 있는 방법입니다.

이 사이트의 AI 토큰 카운터도 참고할 수 있지만, 어떤 도구든 브라우저에서 문자 수 기반 근사식을 쓰는지 실제 토크나이저를 호출하는지 먼저 확인하는 습관이 중요합니다.

자주 묻는 질문