이 글은 다음 언어로도 읽을 수 있습니다: 繁體中文 · English · 日本語 · Bahasa Indonesia · Bahasa Melayu · ไทย · Português (Brasil) · Español · Türkçe · Tiếng Việt
결론부터 말하면, 토큰에는 업계 통일 정의가 없습니다. 토큰은 모델마다 학습할 때 고정해 버린 ‘글자 분할표’로 정해지고, 같은 텍스트를 서로 다른 모델에 넣으면 나뉘는 개수가 다릅니다. 같은 회사의 다른 세대 모델끼리도 다릅니다. 그래서 ‘토큰 하나는 몇 글자인가’라는 질문에는 경험칙만 있을 뿐 고정된 지표는 없습니다.
업계에서 실제로 통일된 것은 토큰 자체가 아니라 과금 구조입니다. 100만 토큰당 얼마, 입력과 출력을 따로 계산한다는 구조입니다. 이 차이는 비용 계산표를 만들 때 치명적인 차이가 됩니다.
토큰이란: 목표는 압축이지 의미가 아니다
토큰은 모델이 텍스트를 잘게 나눈 가장 작은 처리 단위입니다. 나누는 방식은 BPE(Byte Pair Encoding)라는 계열의 알고리즘에서 나오며, 세 단계로 이뤄집니다.
- 방대한 말뭉치를 통계 내어, 가장 자주 함께 나타나는 문자 조합을 반복해서 합칩니다.
- 그렇게 합친 결과로 어휘표(vocabulary)를 만듭니다. 규모는 보통 5만~20만 항목입니다.
- 이후 모든 입력은 이 어휘표와 대조해 분할합니다.
핵심은 이 알고리즘의 목표가 의미 이해가 아니라 압축이라는 점입니다. 자주 쓰이는 문자열, 예를 들어 영어의 the나 and, 중국어의 的(의)나 因為(왜냐하면), 코드 속의 function은 통째로 토큰 하나가 됩니다. 반대로 드문 단어는 잘게 쪼개집니다. 사람 이름, 고유명사, 오타는 흔히 토큰 35개로 나뉩니다.
그러니 토큰은 ‘글자’도 아니고 ‘단어’도 아닙니다. ‘그 모델이 알아보는 가장 작은 부품’입니다. 뒤에 나오는 모든 비용 문제를 이해하는 전제가 이것입니다.
왜 통일된 표준이 있을 수 없나
저도 처음에는 이상하다고 생각했습니다. 벌써 2026년인데, 이렇게 기본적인 과금 단위에 왜 표준이 없을까요?
답은 어휘표가 모델 가중치의 일부라서 학습이 끝나면 바꿀 수 없다는 데 있습니다. 어휘표는 본질적으로 모델의 부품이지 외부 규격이 아니므로, 표준화를 시도할 기술적 지점이 아예 없습니다. 두 회사에 같은 어휘표를 쓰라고 요구하는 것은 같은 모델을 쓰라고 요구하는 것과 마찬가지입니다.
여기서 더 걸려 넘어지기 쉬운 상황이 하나 이어집니다. 같은 회사도 세대를 바꿀 때 토크나이저를 바꿉니다. Claude는 Opus 4.7 세대에서 토크나이저를 바꿨고, 같은 텍스트라도 이전 세대와 토큰 수가 다릅니다. 비용 모델을 작년에 만들었다면 세대가 바뀐 뒤 그 표는 이미 맞지 않습니다. 게다가 오류 메시지도 띄우지 않고, 예측치만 조용히 어긋나게 만듭니다.
경험칙: 어림잡기에는 쓰되 견적에는 쓰지 말 것
| 콘텐츠 유형 | 대략적인 환산 | 비고 |
|---|---|---|
| 영어 | 토큰 1개 ≈ 4문자, 약 0.75단어 | 업계에서 가장 많이 인용되는 어림값 |
| 중국어 | 한자 1자 ≈ 0.6~1.5토큰 | 범위가 넓음, 이유는 다음 절 참고 |
| 코드와 JSON | 눈에 띄게 많음 | 들여쓰기, 중괄호, 따옴표에도 모두 비용이 듦 |
| 이미지 | 크기에 따라 환산 | 이미지 한 장에 흔히 1,000~2,000토큰 |
이 표의 용도는 하나뿐입니다. ‘이 일을 할 가치가 있는가’를 판단하는 것입니다. 대략적인 규모를 잡고 착수할지 정하는 데는 이것으로 충분합니다. 하지만 견적, 예산, 고객에 대한 약속이 얽히는 순간 이 표는 쓰면 안 됩니다. 중국어와 코드에서는 오차가 두 배까지 벌어질 수 있기 때문입니다.
중국어는 왜 불리하고, 얼마나 불리한지는 왜 일정하지 않나
UTF-8 인코딩에서 한자 한 글자는 3바이트를 차지합니다. 그 모델의 어휘표에 해당 단어가 실려 있다면 두세 글자가 토큰 하나로 합쳐질 수 있습니다. 실려 있지 않다면 바이트 단위에 가까운 분할로 후퇴해, 한 글자가 토큰 2~3개를 잡아먹습니다.
그래서 중국어의 토큰 효율은 전적으로 그 모델이 학습한 중국어 말뭉치가 얼마나 두꺼운지에 달려 있습니다. 이것은 좀처럼 제대로 설명되지 않는 비용 요인입니다. 같은 중국어 문단이라도 회사마다 모델의 비용이 두 배 넘게 차이 날 수 있는데, 단가표만 봐서는 전혀 알 수 없습니다.
제가 ‘단가 비교’라는 비교 방식을 별로 믿지 않는 이유도 여기에 있습니다. 단가가 낮다고 싼 것이 아닙니다. 중국어 토큰 효율이 30% 나쁜 모델은 단가가 20% 싸더라도 실제로는 여전히 더 비쌉니다.
과금 구조: 업계 공통인 부분은 이것이다
| 항목 | 업계 관행 |
|---|---|
| 과금 단위 | 언제나 100만 토큰당 몇 달러 |
| 입력과 출력 | 따로 과금하며, 출력이 보통 4~5배 비쌈 |
| 캐시(prompt caching) | 반복되는 앞부분(프리픽스)을 캐시에 쓰고 나면, 읽기 비용은 흔히 일반 입력의 10분의 1 |
| 배치 처리 | 즉시 응답이 필요 없는 일괄 작업은 보통 50% 할인 |
| 사고(thinking) 토큰 | 출력으로 계산되며, 내용이 보이지 않아도 똑같이 지불 |
2026년 중반 Anthropic 공식 API를 예로 들면, Claude Opus 5는 입력 약 5달러, 출력 25달러, Sonnet 5는 2달러와 10달러, Haiku 4.5는 1달러와 5달러입니다(100만 토큰당). 가격은 바뀝니다. 이 숫자들을 적는 것은 견적에 쓰라는 뜻이 아니라 구조를 보라는 뜻입니다. 출력은 언제나 입력의 4~5배입니다.
이 구조는 설계 결정을 바로 바꿉니다. 긴 보고서를 만들어 내는 기능과 분류만 해서 세 글자를 출력하는 기능은 입력량이 같아도 비용의 자릿수가 하나 달라질 수 있습니다. 비용을 줄이려면 출력 칸부터 봐야 합니다.
가장 과소평가되는 것: 비용은 선형이 아니다
이것이 따로 떼어 이야기할 가치가 가장 크다고 생각하는 부분입니다.
모델 자체에는 기억이 없습니다. 방금 무슨 이야기를 했는지 알게 하려면 대화가 한 번 오갈 때마다 앞의 모든 대화 기록을 다시 보내야 합니다. 그래서 스무 번째 턴에 ‘좋아요’ 한마디를 해도, 실제 과금은 앞의 열아홉 턴 전체를 입력으로 다시 계산한 것입니다.
수학적으로 말하면 긴 대화의 비용은 선형이 아니라 제곱에 가깝게 늘어납니다. 실무에서는 세 가지가 따라 나옵니다.
- 긴 대화의 비용은 고르게 퍼져 있지 않고 후반에 몰립니다. 세 번째 턴에서는 아주 싸다고 느껴도, 서른 번째 턴의 한 턴 비용은 그 열 배일 수 있습니다.
- 시스템 프롬프트는 처음에 한 번 내고 끝나는 것이 아니라 매 턴 반복 과금되는 고정비입니다. 아주 자세하게 쓴 역할 설정이 있다면, 한마디 할 때마다 그 비용을 한 번씩 냅니다.
- 캐시 기능은 바로 이 문제 때문에 존재합니다. 변하지 않는 앞부분을 고정해 두고, 반복되는 부분을 약 10분의 1 가격으로 다시 읽어 옵니다. 현재 긴 대화에 가장 효과적인 방법입니다.
정확한 숫자를 원한다면 방법은 하나뿐
그 모델의 토크나이저로 직접 재 보는 것입니다.
Anthropic은 count_tokens라는 엔드포인트를 제공하며, 호출할 때 실제로 쓸 모델 ID를 반드시 함께 넘겨야 합니다. 모델마다 숫자가 다르기 때문입니다. OpenAI 쪽에서 이에 해당하는 것은 tiktoken 패키지입니다.
여기에는 흔한 오차의 원인이 하나 있습니다. tiktoken으로 Claude 사용량을 추정하면 약 15~20% 적게 나오고, 중국어와 코드는 차이가 더 큽니다. 두 회사의 분할표가 다르니 애초에 서로 대신 쓰면 안 됩니다. 이런 식으로 만든 비용 계산표를 저는 한 번 이상 보았고, 결과는 실제 청구액이 예측보다 20% 높게 나오는데 원인을 찾지 못하는 것이었습니다.
네 가지 상황별로 어떤 계산법을 쓸까
| 상황 | 써야 할 방법 |
|---|---|
| 대략 잡아서 할지 말지 정할 때 | 경험칙: 영어는 문자 수 ÷ 4, 중국어는 글자 수 × 1 |
| 견적을 내거나 예산에 넣을 때 | 실제 서비스에 쓸 모델 ID로 count_tokens를 돌려 실측 |
| 이미 운영 중이고 비용을 관리할 때 | 응답마다 돌아오는 사용량 필드, 특히 캐시 적중률 확인 |
| 회사 간 가격 비교 | 같은 샘플을 각 회사의 토크나이저로 따로 실측, 단가만 비교하면 안 됨 |
네 칸의 차이는 정밀도가 아니라, 그 숫자로 어떤 결정을 내리느냐에 있습니다. ‘할지 말지’를 정할 때는 20% 틀려도 괜찮습니다. 하지만 ‘고객에게 얼마를 받을지’를 정할 때 20% 틀리면, 그 20%는 내 이익에서 빠져나갑니다.
마지막으로 처음 질문으로 돌아가 보겠습니다. 토큰이란 무엇일까요? 그 모델이 알아보는 가장 작은 부품이고, 모델마다 알아보는 것이 다릅니다. 이 사실을 받아들여야 비용 모델이 제대로 된 바탕 위에 세워집니다.
자주 묻는 질문
토큰 하나는 몇 글자인가요?
정해진 답은 없습니다. 영어는 토큰 1개가 약 4문자, 약 0.75단어에 해당하고, 중국어는 한자 1자가 약 0.6~1.5토큰에 해당합니다. 범위가 이렇게 넓은 이유는 UTF-8에서 한자 한 글자가 3바이트를 차지하고, 그 단어가 해당 모델의 어휘표에 실려 있는지에 따라 결과가 두 배 넘게 차이 나기 때문입니다. 이 숫자들은 할지 말지 어림잡을 때만 쓰고 견적에는 쓰지 마세요.
토큰에는 왜 업계 통일 표준이 없나요?
어휘표가 모델 가중치의 일부라서 학습이 끝나면 바꿀 수 없기 때문입니다. 어휘표는 본질적으로 모델의 부품이지 외부 규격이 아니므로, 표준화를 시도할 기술적 지점이 없습니다. 두 회사에 같은 어휘표를 쓰라는 것은 같은 모델을 쓰라는 것과 같습니다. 같은 회사도 세대를 바꿀 때 토크나이저를 바꾸므로, 작년에 만든 비용 모델이 올해는 이미 맞지 않을 수 있고, 그래도 오류는 나지 않습니다.
tiktoken으로 Claude 사용량을 추정해도 되나요?
권하지 않습니다. tiktoken은 OpenAI의 토크나이저라서 Claude에 쓰면 약 15~20% 적게 추정되고, 중국어와 코드는 차이가 더 큽니다. 정확한 숫자를 얻는 방법은 하나뿐입니다. 그 모델 자신의 토크나이저로 실측하는 것이고, Anthropic의 경우 count_tokens 엔드포인트이며 호출할 때 실제로 쓸 모델 ID를 반드시 넘겨야 합니다.
긴 대화는 왜 갈수록 비싸지나요?
모델 자체에는 기억이 없어서, 턴마다 앞의 모든 기록을 다시 보내야 하기 때문입니다. 스무 번째 턴에 하는 ‘좋아요’ 한마디는 실제로는 앞의 열아홉 턴 전체를 입력으로 다시 계산해 과금됩니다. 그래서 비용은 선형이 아니라 제곱에 가깝게 늘어납니다. 같은 이유로 시스템 프롬프트는 처음에 한 번 내고 끝나는 비용이 아니라 매 턴 반복 과금되는 고정비이며, prompt caching은 바로 이 부분을 줄이려고 존재합니다.
단가가 싼 모델이 꼭 더 저렴한가요?
그렇지 않습니다. 중국어의 토큰 효율은 그 모델이 학습한 중국어 말뭉치가 얼마나 두꺼운지에 달려 있어서, 같은 중국어 문단이 회사마다 토큰 수가 두 배 넘게 차이 날 수 있고, 이는 단가표에서 전혀 보이지 않습니다. 중국어 토큰 효율이 30% 나쁜 모델은 단가가 20% 싸더라도 실제로는 더 비쌉니다. 가격을 비교하려면 같은 샘플을 두 회사의 토크나이저로 각각 실측해야 합니다.
이 글의 키워드: AI 토큰이란, 토큰, 토크나이저, BPE, AI 비용, LLM 요금, prompt caching, count_tokens
출처: 중국어 원문 최초 게시일: 2026-09-15; 원문 정보 수정일: 2026-09-15. 가격은 2026년 중반 기준 Anthropic 공식 API 참고 가격이며 바뀔 수 있습니다. 토큰 환산 경험칙은 원문에 실린 영어와 중국어 텍스트만 다루며, 한국어 환산값은 이 글에 포함되어 있지 않습니다. 번역판 발행일은 원문 정보의 갱신일이 아닙니다.
이 글은 joelin.cc의 번체 중국어 원문을 현지화한 버전입니다. 내용의 기준은 중국어 원문입니다. 중국어 원문
