홍드로이드의 야매코딩

AI 토큰 미리 세기 — 모델 바꾸면 30% 더 나옵니다 본문

AI & Vibe Coding

AI 토큰 미리 세기 — 모델 바꾸면 30% 더 나옵니다

홍드로이드 2026. 9. 7. 19:34
반응형

요청을 보내기 전에 토큰이 몇 개인지 미리 알고 싶을 때가 있습니다. 맥락 창을 넘기지 않으려고, 값이 얼마나 나올지 가늠하려고, 아니면 어떤 모델로 보낼지 정하려고요. 그래서 AI 토큰 미리 세기 창구가 따로 있고, 쓰는 값은 0원입니다. 문제는 그 다음입니다. 세어 나온 숫자를 그대로 믿고 계산을 짜면 세 군데서 어긋납니다. 그중 하나는 어긋나는 폭이 30%나 됩니다.

이 글은 공식 문서에 적힌 내용만 다룹니다. 다만 문서 안에서도 눈에 잘 안 띄는 자리에 있는 문장들이라, 기능을 이미 쓰고 계신 분도 한 번쯤 확인해 두실 만합니다. 특히 모델을 갈아끼울 계획이 있다면 두 번째 항목은 지금 읽어 두시는 게 좋습니다.

📌 30초 요약

  • 세는 값은 공짜입니다. 다만 분당 요청 수 한도가 따로 붙습니다(시작 5,000 · 구축 10,000 · 확장 20,000).
  • 그 한도는 실제 호출 한도와 완전히 별개입니다. 아무리 세도 서비스가 쓸 몫이 줄지 않습니다.
  • 모델을 바꾸면 같은 글이 약 30% 더 잡힙니다. 새 토크나이저가 들어간 세대부터입니다.
  • 세기 값이 청구서보다 클 수도 있습니다. 시스템이 끼워 넣는 몫은 세기에는 들어가지만 청구되지 않습니다.
  • 캐시는 반영되지 않습니다. 캐시 지정을 넣어도 세는 단계에서는 캐싱이 일어나지 않습니다.
  • 생각 블록은 모델에 따라 셈법이 갈립니다. 앞선 차례를 모두 보존하느냐 마지막만 보존하느냐로 나뉩니다.

① 공짜입니다, 다만 한도가 따로 붙습니다

토큰 세기는 쓰는 값이 0원입니다. 여기까지는 대부분 알고 계실 겁니다. 덜 알려진 쪽은 한도가 따로 있다는 사실입니다. 공짜라고 무제한은 아닙니다.

사용 등급 분당 요청 수 초당 환산
시작(Start) 5,000 약 83회
구축(Build) 10,000 약 166회
확장(Scale) 20,000 약 333회

더 필요하면 한도 상향을 신청하는 경로가 설정 화면에 따로 있습니다. 넉넉해 보이지만, 들어오는 요청마다 전부 미리 재는 구조라면 서비스 처리량과 1대 1로 붙기 때문에 생각보다 빨리 닿습니다.

여기서 실무적으로 가장 중요한 한 줄이 문서에 있습니다. 토큰 세기와 메시지 생성은 서로 다른 독립된 한도를 씁니다. 한쪽을 쓴다고 다른 쪽 한도가 깎이지 않습니다.

사전 점검을 아무리 돌려도 서비스가 실제로 쓸 처리량은 그대로라는 뜻입니다. 들어오는 요청을 전부 미리 재서 큰 것만 걸러내는 문지기를 앞단에 세워도, 그 문지기가 뒷단 처리량을 잡아먹지 않습니다.

이 성질 덕분에 쓸 만한 패턴이 몇 가지 생깁니다.

  • 앞단 문지기 — 사용자가 붙인 문서가 맥락 창을 넘길 크기인지 보내기 전에 판정합니다. 넘치면 호출 자체를 안 하니 실패 비용이 0입니다.
  • 모델 고르기 — 작은 요청은 값싼 모델로, 큰 요청은 큰 모델로 나눠 보내는 분기의 판단 근거로 씁니다. 문서가 직접 「모델 경로 결정」을 용도로 들고 있습니다.
  • 길이 맞추기 — 정해 둔 목표 길이에 프롬프트를 끼워 넣을 때, 어디까지 잘라야 하는지 재면서 다듬습니다.

반대로 말하면, 세기 한도를 다 써버려도 실제 호출은 멀쩡히 나갑니다. 사전 점검이 막히는 것과 서비스가 막히는 것은 별개 사건이라, 장애를 볼 때 이 둘을 같은 그래프에 겹쳐 놓으면 원인을 잘못 짚기 쉽습니다. 계기판을 나눠 두세요.

쓸 수 있는 곳도 넓습니다. 공식 창구뿐 아니라 아마존·구글·마이크로소프트의 클라우드 경유로도 지원됩니다. 데이터를 보관하지 않는 설정에서도 쓸 수 있고(일부 모델은 제외), 현재 살아 있는 모델은 전부 토큰 세기를 지원합니다.

② 모델을 바꾸면 같은 글이 30% 늘어납니다

이번 글에서 가장 값나가는 사실입니다. 한 세대부터 토크나이저 자체가 바뀌었습니다. 글자를 토큰으로 자르는 규칙이 달라졌다는 뜻입니다.

결과는 이렇습니다. 똑같은 입력 글이 예전 세대보다 약 30% 더 많은 토큰으로 잡힙니다. 정확한 증가폭은 내용과 작업 형태에 따라 다르지만, 방향은 한쪽입니다 — 늘어납니다.

그리고 이건 세기 창구만의 이야기가 아닙니다. 문서가 못박기를, 해당 세대 모델의 사용량과 청구 자체가 이 새 토크나이저의 셈을 따릅니다. 즉 30%는 계산기 눈금이 바뀐 게 아니라 내는 돈이 바뀐 것입니다.

⚠️ 예전 모델에서 잰 수치를 그대로 쓰지 마세요

문서가 직접 경고하는 대목입니다. 새 토크나이저 세대로 옮길 때 예전 모델에서 측정한 토큰 수로 비용을 추정하거나 맥락 창에 들어갈지 판단하면 안 된다고 적혀 있습니다.

비용 계산서를 예전 수치로 짜 두었다면 실제 청구가 예상의 1.3배로 올 수 있습니다. 월 100만 원으로 잡아 둔 예산이라면 130만 원이 나온다는 뜻입니다.

맥락 창도 마찬가지입니다. "여유 있게 들어간다"고 계산해 둔 프롬프트가 새 모델에서는 넘칠 수 있습니다. 특히 한도 가까이에서 아슬아슬하게 운영하던 파이프라인은 모델 교체 당일에 무더기로 실패합니다.

그럼 어떻게 확인할까요. 방법은 단순합니다. 같은 요청을 두 번 세면 됩니다 — 한 번은 지금 쓰는 모델 이름으로, 한 번은 옮겨 갈 모델 이름으로. 세기 창구는 「모델 이름」 칸에 적은 모델의 토크나이저로 셈합니다. 두 결과의 「입력 토큰 수」를 나란히 놓으면 내 작업에서의 실제 증가폭이 나옵니다.

# 같은 프롬프트를 두 모델로 각각 세어 비교한다
curl https://api.anthropic.com/v1/messages/count_tokens \
  -H "x-api-key: $내_열쇠" \
  -H "content-type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "<옮겨 갈 모델 이름>",
    "system": "기본 지시문",
    "messages": [{ "role": "user", "content": "재 볼 내용" }]
  }'

# 돌아오는 값은 이 한 줄뿐이다
→ { "input_tokens": 14 }   ← 「입력 토큰 수」

# 도구 목록까지 넣으면 숫자가 확 뛴다 — 문서 예시 기준
#   글자만:        14
#   도구 1개 추가: 403   ← 스물여덟 배

위 마지막 줄도 그냥 지나칠 게 아닙니다. 문서의 예시에서 도구를 딱 하나 붙였을 뿐인데 14토큰이 403토큰이 됩니다. 도구 정의는 매 요청마다 통째로 실려 가는 고정비라, 도구를 여러 개 물린 에이전트는 사용자가 아무 말도 안 해도 이미 수천 토큰을 깔고 시작합니다. 세기 창구는 그 고정비가 정확히 얼마인지 재는 데도 쓸 수 있습니다.

같은 토크나이저를 공유하는 모델끼리는 결과가 같습니다. 그러니 그 안에서 갈아끼울 때는 다시 안 재도 됩니다. 세대를 건너뛸 때만 조심하면 됩니다.

한국어를 다루신다면 이 문제가 겹쳐서 옵니다. 한국어는 원래도 같은 뜻의 영어보다 토큰을 더 먹습니다(한국어 토큰 1.44배 실측). 거기에 토크나이저 교체분이 더 얹히는 구조라, 영어권 사례로 잡은 예산은 한국어 서비스에서 특히 크게 빗나갑니다. 남의 벤치마크 대신 내 실제 프롬프트로 직접 재는 게 유일하게 믿을 만한 방법입니다.

③ 세어 나온 값과 청구서가 어긋나는 두 방향

문서는 세기 결과를 「추정치」라고 부릅니다. 실제로 메시지를 만들 때 쓰이는 입력 토큰 수와 조금 다를 수 있다고 적혀 있습니다. 여기까지는 예상 범위입니다.

덜 알려진 쪽은 어긋나는 방향이 하나가 아니라는 것입니다. 보통은 "세기가 실제보다 적게 나오면 어쩌지"를 걱정하는데, 문서가 명시한 경로는 반대쪽입니다.

어긋나는 경로 방향 문서가 밝힌 내용
추정 오차 양쪽 실제 사용량과 소폭 다를 수 있음
시스템이 끼워 넣는 몫 세기 > 청구 최적화를 위해 자동으로 더해지는 토큰이 세기 값에 포함될 수 있으나 청구되지 않음
캐시 미반영 세기 > 실제 부담 세는 단계에서는 캐싱이 일어나지 않음
서버 쪽 도구 세기 < 총 사용량 도구 토큰은 첫 호출에만 잡힘

두 번째 줄이 핵심입니다. 문서의 표현은 이렇습니다 — 「시스템이 더한 토큰에 대해서는 청구하지 않습니다. 청구는 여러분의 내용만 반영합니다.」 즉 세기 창구가 돌려준 숫자에는 내가 안 낼 몫이 섞여 있을 수 있습니다.

네 번째 줄은 방향이 반대라 더 조심해야 합니다. 여러 차례 오가며 도구를 쓰는 작업이라면, 한 번 세어 본 값으로 전체 작업 비용을 가늠하면 크게 모자랍니다. 세기는 첫 삽만 재 주고, 나머지 삽질은 세지 않습니다.

실무 결론은 간단합니다. 세기 값은 맥락 창에 들어갈지 판단하는 데는 안전한 쪽입니다(넉넉히 잡으니까). 반대로 정산·청구 대조에 쓰면 안 됩니다. 실제 청구 숫자는 응답에 함께 오는 사용량 정보를 봐야 합니다. 재는 자와 계산서는 다른 물건이라고 생각하시면 됩니다.

④ 캐시·생각 블록은 셈법이 다릅니다

캐시부터. 세기 요청에 「캐시 지정」 블록을 넣는 것 자체는 됩니다. 오류도 안 납니다. 그런데 세는 단계에서는 캐싱이 실제로 일어나지 않습니다. 캐싱은 메시지를 진짜로 만들 때만 작동합니다. 문서의 자주 묻는 질문 칸에 이 답이 그대로 적혀 있습니다.

그래서 세기 값은 언제나 「캐시가 하나도 안 먹었을 때의 숫자」입니다. 캐시를 잘 쓰고 있는 서비스라면 실제로 새로 읽히는 양은 이보다 훨씬 적습니다. 여기서 흔한 착각이 생깁니다 — 세기 값이 줄지 않는다고 캐시가 안 듣는다고 판단하는 것인데, 애초에 세기 쪽은 캐시를 보지 않으니 줄 리가 없습니다.

캐시가 언제 깨지는지는 별도로 챙기셔야 합니다(프롬프트 캐싱 깨지는 순간 8가지). 읽기와 쓰기 단가가 갈리는 문제도 함께 보셔야 하고요(AI 캐시 요금 3사 비교).

생각 블록은 모델에 따라 갈립니다. 이건 규칙이 두 갈래라 헷갈리기 쉽습니다.

대상 입력 토큰에 들어가나
지금 차례의 생각 들어갑니다
이전 차례의 생각 — 앞선 대화를 모두 보존하는 모델 들어갑니다
이전 차례의 생각 — 마지막 차례만 보존하는 모델 떼어내므로 안 들어갑니다

긴 대화를 이어가는 서비스라면 이 차이가 누적됩니다. 앞선 차례를 모두 보존하는 모델에서는 생각이 쌓인 만큼 매 요청의 입력이 계속 불어나고, 마지막만 보존하는 모델에서는 그 부담이 없습니다. 같은 대화를 두 모델로 각각 세어 보면 회차가 늘수록 격차가 벌어지는 게 눈에 보입니다.

나머지 두 가지도 실무에서 걸립니다.

  • 큰 이미지 거절 설정은 세기에서도 그대로 작동합니다. 크기 초과 시 오류로 처리하도록 해 두었다면, 실제 호출과 똑같이 세기 단계에서 거절됩니다. 불편해 보이지만 뒤집어 보면 돈 드는 호출 전에 걸러내는 무료 검문소로 쓸 수 있다는 뜻입니다.
  • PDF는 실제 호출과 같은 제약을 그대로 받습니다. 세기에서만 통과되는 형식 같은 건 없으니, 세기를 통과했다면 본 호출도 형식 때문에 막히지는 않습니다.

⑤ 자주 묻는 질문 (FAQ)

Q. 정말 돈이 안 드나요?

네, 토큰 세기 자체는 무료입니다. 다만 분당 요청 수 한도는 있습니다. 등급별로 5,000~20,000회이고, 더 필요하면 설정 화면에서 한도 상향을 신청하는 경로가 따로 있습니다. 그리고 이 한도는 실제 호출 한도와 독립이라, 세기를 많이 쓴다고 서비스가 느려지지는 않습니다.

Q. 세기 값으로 청구서를 검산해도 되나요?

권하지 않습니다. 추정 오차가 있는 데다, 시스템이 자동으로 더한 몫이 세기 값에는 들어가지만 청구에는 안 들어갑니다. 반대로 여러 번 오가며 도구를 쓰는 작업은 세기 값이 총 사용량보다 모자랍니다. 검산용으로는 응답에 함께 오는 실제 사용량 정보를 쓰세요. 세기 값은 보내기 전 판단에 쓰는 도구입니다.

Q. 예전에 재 둔 수치를 그대로 쓰면 안 되나요?

새 토크나이저가 들어간 세대로 옮기는 거라면 안 됩니다. 같은 글이 약 30% 더 잡히고, 그 셈이 실제 청구에도 그대로 적용됩니다. 옮겨 갈 모델 이름으로 다시 세십시오. 같은 토크나이저를 쓰는 모델끼리는 결과가 같으니 그 안에서는 재사용해도 됩니다.

Q. 개발자로서 지금 뭘 해두면 좋을까요?

세 가지입니다. ① 쓰는 모델 이름을 설정값 한 곳에 모아 두고, 세기 요청과 실제 호출이 같은 값을 참조하게 하세요 — 모델을 갈아끼울 때 세기 쪽만 옛 이름으로 남는 사고가 가장 흔합니다. ② 배포 전에 대표 프롬프트 몇 개를 두 모델로 세어 증가폭을 기록해 두세요. ③ 도구 목록만 넣고 한 번 세어 고정비가 얼마인지 알아 두세요. 안 쓰는 도구 하나를 빼는 것만으로 매 요청이 가벼워집니다.

✨ 정리

토큰 세기는 보내기 전에 쓰는 자입니다. 공짜인 데다 실제 호출 한도를 갉아먹지도 않으니 앞단에 넉넉히 세워 두셔도 됩니다. 다만 그 자의 눈금은 모델마다 다르고, 청구서와도 완전히 같지는 않습니다. 맥락 창에 들어갈지 재는 데는 믿고 쓰시고, 돈을 맞추는 데는 실제 사용량을 보세요. 그리고 모델을 옮길 땐 반드시 다시 재십시오 — 30%는 그냥 넘길 차이가 아닙니다.

더 읽을거리: AI 개발 비용·도구 총정리 허브

출처: Anthropic 공식 문서 「Token counting」(platform.claude.com, 2026년 9월 확인). 등급별 분당 요청 수, 약 30% 증가, 시스템 추가분 비과금, 캐시 미반영, 생각 블록의 모델별 처리, 서버 쪽 도구의 첫 호출 한정은 모두 해당 문서에 명시된 내용입니다. 다만 30%는 문서가 "대략"이라고 밝힌 값이며 내용과 작업 형태에 따라 달라집니다 — 필자가 직접 측정한 수치가 아닙니다. 도구 1개에 403토큰이라는 숫자도 문서의 예시값이며 도구 정의 길이에 따라 크게 달라집니다. 한도·가격 정책은 변동될 수 있으니 실제 적용 전 공식 문서를 확인하세요.

반응형
Comments