AI 토큰 카운터 — GPT-5·Claude 4.7·Gemini 2.5·o3 토큰 수와 2026 가격 비교

BPE 토크나이저의 동작, 한국어가 비싼 이유, 프롬프트 비용 관리법을 실무 관점에서 정리했습니다.

1. 토큰이란?

토큰은 LLM 이 보는 가장 작은 단위입니다. 최신 모델들은 모두 BPE (Byte-Pair Encoding) 변형을 쓰며 자주 등장하는 문자 조합을 하나의 ID 로 병합합니다. 영문 산문은 평균 약 4글자당 1토큰, 한글은 약 1글자당 1토큰 근처여서 같은 의미라도 한국어 프롬프트가 훨씬 비쌉니다. 토큰 수는 곧 비용, 컨텍스트 한도, 응답 지연 세 가지를 동시에 결정하기 때문에 LLM 비용 최적화는 결국 "토큰을 더 일찍, 더 적게 세는 것"으로 귀결됩니다.

2. 이 페이지에서 사용하는 4개 토크나이저 계열

OpenAI cl100k_base — GPT-3.5 Turbo 와 구형 GPT-4. 10만 어휘, js-tiktoken 으로 JavaScript 포팅. 정확 카운트.
OpenAI o200k_base — GPT-4o 계열과 o-시리즈. 20만 어휘에 다국어 병합이 더 많아 한국어가 cl100k 대비 20~30% 저렴. 정확 카운트.
Anthropic Claude — 라틴 문자에서는 cl100k 와 매우 유사. 브라우저 토크나이저는 공개되지 않았으며, count_tokens API 가 정확합니다. 본 페이지는 근사치입니다.
Google Gemini — 25.6만 어휘의 SentencePiece BPE 로, 다국어 데이터 비중이 높아 한국어·일본어 효율이 좋습니다. Google 은 countTokens REST API 를 제공합니다.
Meta Llama 3 — 12.8만 어휘의 SentencePiece BPE. 비라틴 문자는 대부분 바이트 단위이며 한국어 비율이 가장 나쁩니다. 참고용으로 포함했습니다.

3. 한국어가 토큰을 많이 쓰는 이유

한글 음절 블록(가·나·다…)은 유니코드상 2~3 코드포인트의 자모로 구성되며, 영어 중심의 BPE 는 각 음절을 2~3개의 바이트 토큰으로 쪼갭니다. cl100k 에서 한글은 글자당 1.5~2.0 토큰, o200k 는 1.0 근처, Gemini 는 깨끗한 산문에서 0.7 수준까지 내려갑니다. 한국어 서비스라면 모델 등급보다 토크나이저 선택이 훨씬 큰 비용 지렛대가 됩니다.

4. 비용 계산 치트시트

각 제공사는 1M 토큰당 가격을 공시합니다. 요청당 비용:

cost_usd = input_tokens / 1_000_000 * input_price
         + output_tokens / 1_000_000 * output_price

출력 토큰은 입력보다 3~5배 비쌉니다. max_tokens 상한을 두고, 스트리밍으로 조기 종료가 가능하게 설계하세요.

5. 품질을 해치지 않고 비용 줄이기

프롬프트 캐싱 활성화 (Claude / GPT-4o) — 캐시된 접두부 90% 할인.
난이도별 파이프라인 분리: 가벼운 턴은 Haiku / Flash / mini 로 라우팅.
마크다운 표, 연속 이모지, 반복 공백을 사전에 제거.
RAG 는 정답에 실제로 기여하는 top-K 만 잘라 넣기.
JSON 모드와 타이트한 스키마로 출력 길이 단축.

6. 본 카운터 활용법 — 5가지 실전 워크플로우

이 페이지에 도달하는 경로는 사람마다 다르지만 가장 흔한 시작점은 "내 프롬프트가 너무 비싸 보인다" 라는 직감입니다. 홈 상단 입력창에 프롬프트를 붙여넣으면 약 300밀리초(디바운싱 윈도우) 안에 모든 모델의 토큰 수와 그 한 번의 요청 비용(USD)이 표시됩니다. 예를 들어 6,000자 한국어 시스템 프롬프트는 GPT-4o 에서 약 4,300 토큰, Claude Haiku 에서 약 5,900 토큰 부근으로 나옵니다. 그 숫자 하나가 가격 협상의 출발점입니다.

두 번째 활용은 토크나이저 쇼핑입니다. "한국어 효율" 패널은 동일한 한국어 고정 문단을 모든 모델로 토크나이즈해 글자당 토큰 수를 보여줍니다. Gemini 1.5 Flash 와 GPT-4o mini 가 거의 항상 우세하며, cl100k 기반 모델과 Llama 3 은 한국어에서 구조적으로 불리합니다. 한 번에 비교 가능한 화면을 통해 모델 선택의 비용 차이를 시각화할 수 있습니다.

세 번째 활용은 아직 배포되지 않은 기능의 비용 추정입니다. 대표 프롬프트 1건의 비용에 예상 월 호출 수를 곱하면 됩니다. 많은 팀이 출력 토큰이 입력의 4~5배라는 점을 잊습니다. 2,000 토큰 프롬프트에 200 토큰의 응답이 붙으면 출력이 입력만큼 비싸질 수 있습니다.

네 번째 활용은 예산 거버넌스입니다. 대표 프롬프트의 달러 금액을 코드 안의 요청별 상한값으로 박아두세요. 사용자의 요청이 그 선을 넘으면 더 싼 모델로 라우팅하거나 명확한 메시지로 거절하는 1일짜리 작업이 일주일 안에 본전을 뽑습니다.

다섯 번째 활용은 다국어 A/B 테스트입니다. 일부 팀은 한국어 사용자를 상대로도 시스템 프롬프트만은 영어로 작성합니다. 영어 시스템 프롬프트가 30~40% 더 저렴하기 때문입니다. 두 버전을 모두 붙여 비교하면 비용 차이가 즉시 보이며, 유저 메시지를 한국어로 유지하면 품질 손실은 거의 없습니다.

7. 실전 예시 — 세 가지 시나리오

예시 A — 한국어 고객 상담 챗봇. 검색된 컨텍스트 청크 1개가 한국어 800자, 시스템 프롬프트 1,200자, 사용자 메시지 300자라고 가정해 봅시다. cl100k 에서는 한 턴당 약 4,500 입력 토큰, o200k 에서는 2,400, Gemini Flash 에서는 1,800 토큰입니다. 하루 20,000 턴이 발생한다면 cl100k 와 Gemini Flash 의 차이는 하루 약 5,400만 토큰으로, 동일 제품인데 월 청구액이 4자릿수 달러 차이가 나는 수준입니다.

예시 B — 장문 요약기. 200쪽 PDF는 한국어 약 12만 자 분량이며, Claude Sonnet(한국어 기준 cl100k 유사)에서는 약 21만 토큰으로 200k 컨텍스트를 넘깁니다. 같은 문서가 Gemini 1.5 Pro 에서는 13만 토큰 부근에 들어와 안전하게 처리됩니다. 토크나이저 계열 선택이 "기능이 동작하느냐 동작하지 않느냐"의 차이를 만들기도 합니다.

예시 C — 프롬프트 캐싱. 사용자 요청마다 6,000 토큰 시스템 프롬프트를 재사용하는 B2B 에이전트 제품을 가정해 봅시다. 캐싱이 없으면 매 요청마다 전체 비용을 지불하지만, Claude 프롬프트 캐싱(캐시된 토큰 90% 할인)을 켜면 추가 사용자 메시지 1건의 한계 비용이 약 1/10 로 떨어집니다. 캐시 쓰기 비용은 1회만 청구되고 읽기 비용은 할인된 단가로 청구되므로, 본 카운터로 시스템 프롬프트의 정확한 토큰 수를 미리 확인한 뒤 캐싱을 활성화하는 것이 안전합니다.

8. 자주 하는 실수

채팅 envelope 를 빠뜨리고 본문 토큰만 계산 — Chat Completion API 는 역할/메시지 포맷으로 3~7 토큰, 어시스턴트 프라이밍으로 약 3 토큰이 추가됩니다. 본 페이지는 순수 텍스트만 세므로 실제 청구서는 조금 더 높게 나옵니다.
토큰을 단어 수·글자 수와 혼동 — 영어 단어 1개는 평균 약 1.3 토큰, 한국어 글자 1개는 약 1.0~1.5 토큰입니다. 스프레드시트에서 단위를 섞으면 비용 추정이 어긋나는 가장 흔한 원인입니다.
출력 비용 망각 — 응답이 긴 제품은 결국 출력이 비용의 대부분입니다. max_tokens 를 허용 가능한 최소값으로 잡는 것이 단일 최대 효과 최적화입니다.
"GPT-4"는 모두 같은 토크나이저" 라고 가정 — GPT-3.5 Turbo·원본 GPT-4 는 cl100k, GPT-4o·o-시리즈는 o200k 입니다. 모델을 바꾸기만 해도 한국어 토큰 수가 20~30% 달라집니다.
Claude 근사치를 정확값으로 보고함 — Anthropic 은 브라우저 토크나이저를 공개하지 않습니다. 청구서 단위로 일치시켜야 한다면 count_tokens API 호출이 정답입니다.

9. 한국어 LLM 시장 변화와 본 도구의 위치

2024년 이후 한국어 처리에 강한 모델 라인업이 두 갈래로 정리됐습니다. 하나는 글로벌 모델 중 한국어 병합이 잘 된 계열(GPT-4o·Gemini)이고, 다른 하나는 한국어 특화 학습이 추가된 국내 모델(HyperCLOVA X, Solar, EXAONE 등)입니다. 다만 본 카운터는 글로벌 4계열만 다룹니다 — 국내 모델은 토크나이저가 공개되지 않거나 자체 API 사양이 빠르게 바뀌어 안정적인 비교가 어렵기 때문입니다. 글로벌 모델만으로도 한국어 비용을 줄일 여지가 충분히 크기 때문에 우선순위 면에서는 본 페이지의 범위로 90% 의사결정이 가능합니다.

국내 모델을 도입하려는 팀에게도 본 카운터는 의미가 있습니다. 같은 한국어 텍스트가 GPT-4o, Claude, Gemini 에서 각각 몇 토큰인지 미리 알면 국내 모델 벤더와 협상할 때 "글로벌 모델 대비 토큰 효율을 얼마나 보장하느냐" 라는 질문을 구체적인 숫자로 던질 수 있습니다. 국내 모델은 토크나이저가 비공개라 벤더가 제시하는 가격표가 글로벌 모델 대비 실제로 저렴한지를 외부에서 검증하기 어려운데, 본 페이지의 글로벌 4종 토큰 수를 기준점으로 삼으면 협상 테이블에서 비교가 가능합니다.

10. 토큰 효율을 더 끌어내는 텍스트 정리 기법

같은 의미를 더 적은 토큰으로 표현하는 일은 단순한 다이어트가 아니라 실제 모델의 출력 품질에도 영향을 줍니다. 모델은 컨텍스트가 길어질수록 주의를 분산시키기 때문에 잡음이 줄어들면 응답이 더 또렷해지는 부수 효과가 있습니다. 다음 6가지는 한국어 프롬프트에서 안정적으로 5~20% 토큰 절감 효과를 본 경험적 기법입니다.

중복 조사 제거 — "그 결과는 매우 중요한 것이다" 같은 문장에서 "것이다"를 "이다"로 줄이는 식의 평범한 다듬기로도 한국어 토큰 수는 3~5% 줄어듭니다. 모델 응답에는 영향이 거의 없습니다.
존댓말 → 평어 (시스템 프롬프트 한정) — 시스템 프롬프트의 존댓말은 사용자에게 보이지 않기 때문에 평어로 바꿔도 됩니다. "해 주십시오" → "하라" 만으로도 토큰 수가 크게 줄어듭니다. 사용자에게 보이는 응답은 별도 지시로 존댓말을 유지하도록 명시하면 됩니다.
마크다운 표 제거 — 표 형식은 한국어 BPE 에서 특히 비효율적입니다. 동일한 정보를 불릿 리스트나 JSON 으로 바꾸면 토큰이 30% 이상 줄어드는 경우가 흔합니다. 본 카운터로 같은 데이터를 세 가지 포맷으로 비교해 보세요.
긴 변수명·식별자 단축 — 함수 이름·테이블 이름이 길수록 토큰이 늘어납니다. 코드 샘플을 프롬프트에 넣을 때는 핵심 함수만 남기고 보조 함수의 본문은 시그니처만 남기는 방식이 효과적입니다.
예시 갯수 줄이기 — Few-shot 예시는 보통 3~5개면 충분합니다. 7개 이상의 예시는 한계 효과가 급격히 떨어지면서 토큰 비용만 누적시킵니다. 본 카운터로 N 개씩 잘라 가며 비용 차이를 확인하면 최적점을 빠르게 찾을 수 있습니다.
중복된 시스템 지시 통합 — "친절하게 답해 주세요"와 "정중한 어조로 답변하세요"가 둘 다 들어 있는 시스템 프롬프트가 의외로 흔합니다. 의미가 겹치는 지시를 한 줄로 합치는 것만으로도 10% 안팎의 토큰 절감을 얻을 수 있습니다.

11. 본 카운터의 갱신 주기와 신뢰성

LLM 가격표는 평균 분기당 1회 변동하며, 새로운 모델이 출시되는 시점에는 비정기적으로 추가됩니다. 본 페이지는 분기 정기 갱신과 주요 모델 출시 즉시 갱신을 병행하며 페이지 상단에 마지막 갱신 일자를 명시합니다. 토크나이저 자체는 모델 별로 동결돼 있어 갱신 주기가 빠르지 않지만, 가격 정책은 자주 바뀌므로 청구서에 직접 영향을 주는 정보는 갱신 일자를 반드시 확인하시기 바랍니다.

또한 본 도구는 광고와 무관하게 모든 모델을 동일한 기준으로 표시합니다. 특정 모델을 추천하거나 특정 벤더로 유인하기 위한 가중치는 없습니다. Korean efficiency 패널의 순위는 매 측정마다 그 시점의 토크나이저와 가격을 기반으로 자동으로 다시 계산되며, 운영자가 임의로 조작하지 않습니다.

12. 한국어 토큰 카운팅이 곧 비용 통제인 이유 — 마무리

한국 시장에서 LLM 기반 서비스를 운영해 본 분이라면 "한국어가 비싸다" 라는 말을 추상적인 불평이 아니라 매월 청구서의 실제 숫자로 체감하셨을 겁니다. 같은 기능, 같은 트래픽, 같은 모델임에도 한국어 응답을 영어 응답으로 단순 교체하기만 해도 토큰 비용이 절반 가까이 줄어드는 경우가 있습니다. 반대로 영어로 설계된 시스템 프롬프트를 무리하게 한국어로 옮기다가 청구서가 두 배가 되는 일도 드물지 않습니다. 본 카운터는 그 의사결정을 직관이 아니라 측정으로 바꾸기 위한 도구입니다.

현장에서 가장 자주 활용되는 흐름은 단순합니다. 첫째, 대표 프롬프트 1건을 카운터에 붙여 모든 모델의 토큰 수와 단가를 본다. 둘째, 가장 효율이 좋은 모델 후보 2개를 골라 짧은 응답·긴 응답 두 시나리오로 예상 월 비용을 계산한다. 셋째, 시스템 프롬프트에서 줄일 수 있는 부분(중복 지시, 마크다운 표, 긴 존댓말)을 다듬어 다시 측정한다. 넷째, 캐싱 가능 여부를 확인하고 가능한 경우 캐시 적용 후 단가를 다시 계산한다. 다섯째, 산출된 단가를 코드 내 요청 예산 상한에 반영한다. 이 다섯 단계는 한 시간 안에 끝나며, 그 한 시간이 통상 연 단위 청구서를 의미 있게 바꿉니다.

결국 LLM 비용은 모델 선택 한 번으로 끝나지 않고, 매 요청마다 누적되는 토큰의 흐름입니다. 모델 제공사가 가격을 갱신하고, 새로운 모델이 출시되고, 사용자의 입력 패턴이 변할 때마다 이 흐름의 모양이 바뀝니다. 본 카운터는 그 변화를 빠르게 측정해 결정에 반영할 수 있도록 항상 같은 위치에 두는 일종의 계량저울 역할을 하고자 합니다. 한국어 서비스 운영자에게 그 저울은 모델 선택보다 더 큰 가치를 줄 수 있다는 것이 본 도구를 만든 가장 중요한 동기입니다.

마지막으로 한 가지 — 본 카운터는 광고 한 줄을 노출하더라도 어떤 모델이 더 좋다거나 어떤 벤더가 더 저렴하다고 결론을 내려 주지 않습니다. 결정은 항상 운영자의 몫이고, 본 도구는 그 결정에 필요한 객관적 숫자만 제공합니다. 한국어 글자당 토큰 수, 입력·출력 단가, 캐시 후 단가, 컨텍스트 윈도우 한도 네 가지 숫자만 정확히 알면 한국어 LLM 비용 의사결정의 90% 가 끝납니다. 이 페이지가 그 네 가지 숫자를 가장 빠르게 보여드리는 도구가 되길 바랍니다.

AI 토큰 계산 가이드