Claude Token Counter에 모델 비교 기능이 붙으면서, 이제 같은 입력이 모델마다 얼마나 다른 토큰 비용으로 계산되는지 더 쉽게 볼 수 있게 됐습니다.1 얼핏 보면 이건 예산 관리용 업데이트처럼 보이지만, 실무에서는 오히려 "왜 이 프롬프트가 비싸고 느리고 들쭉날쭉한가"를 찾는 디버깅 도구에 가깝습니다.
지금 이게 중요한 이유는 단순합니다. Claude 계열은 모델별 가격 차이도 크고, 같은 텍스트라도 모델이나 토크나이저 변화에 따라 토큰 수가 달라질 수 있기 때문입니다. Anthropic 문서 기준으로도 Opus 4.7은 입력 100만 토큰당 5달러, Sonnet 4.6은 3달러, Haiku 4.5는 1달러입니다.2 같은 "장문의 친절한 프롬프트"가 어떤 모델에서는 그냥 비싸고, 어떤 모델에서는 품질까지 깎아먹는 원인이 됩니다.
토큰 카운터가 보여주는 건 비용보다 '프롬프트 습관'이다
많은 사용자가 토큰 카운터를 "이 호출에 몇 원 드나" 확인하는 용도로만 씁니다. 그런데 실제로 더 유용한 순간은, 프롬프트를 조금씩 바꿨을 때 숫자가 어디서 갑자기 뛰는지 볼 때입니다.
보통 토큰을 조용히 불려 놓는 패턴은 비슷합니다. 길어진 시스템 지시문, 매번 다시 붙여넣는 배경 문서, 예시를 과하게 많이 넣는 few-shot 구성, 정리되지 않은 긴 대화 이력입니다. 특히 Claude Code류 워크플로에서는 CLAUDE.md 같은 상시 지침 파일이 매 턴 입력 토큰을 계속 먹습니다. 짧고 반복이 적은 작업에서는 오히려 절약보다 오버헤드가 더 커질 수 있다는 점도 이미 커뮤니티 실험에서 반복해서 지적됐습니다.3
이 숫자가 중요한 이유는, 토큰 증가가 거의 항상 같은 문제를 같이 데려오기 때문입니다. 응답이 느려지고, 긴 대화에서 중요한 규칙이 희석되고, 모델이 앞부분 규칙을 "읽긴 했지만 덜 강하게 따르는" 느낌이 생깁니다. 즉, 토큰 스파이크는 비용 경고이면서 동시에 품질 경고입니다.
큰 토큰 수는 곧바로 실패 확률 신호가 되기도 한다
긴 컨텍스트가 항상 나쁜 건 아닙니다. 문제는 "필요한 길이"와 "방치된 길이"를 구분하지 못할 때입니다.
예를 들어 긴 세션에서는 새 사용자 입력보다 누적 히스토리가 훨씬 큰 비중을 차지합니다. 여러 분석이 공통으로 보여주는 건, 사용자가 방금 쓴 한두 문장보다 시스템 프롬프트와 누적 대화가 전체 토큰의 대부분을 만든다는 점입니다.4 그래서 토큰 카운터로 현재 프롬프트만 보는 게 아니라, "이걸 지금 같은 스레드에서 이어갈지, 요약 후 새 스레드로 갈지" 판단하는 데 써야 합니다.
모델 비교 기능은 여기서 더 실용적입니다. 같은 프롬프트라도 모델별 입력 단가와 출력 단가가 다르고, 토크나이저 차이로 실제 토큰 수도 달라질 수 있습니다. 독립 측정에서는 Opus 4.7의 새 토크나이저가 영어·기술 문서·코드에서 4.6 대비 대략 1.3배 안팎, 일부 샘플은 1.445~1.47배까지 더 많은 토큰을 쓰는 경향이 관찰됐습니다.5 이 수치는 특정 실험 맥락의 관찰이지 모든 작업에 그대로 적용된다고 단정할 수는 없지만, 적어도 "같은 글인데 왜 갑자기 한도와 비용이 빨리 닳지?"를 설명하는 데는 충분히 유용합니다.
토큰 카운터가 실제로 도와주는 세 가지 결정
첫째, 계속 대화할지 요약하고 새로 시작할지 결정할 수 있습니다. 카운터 숫자가 커졌다면, 지금부터 들어갈 새 정보보다 과거 이력이 더 비싸진 상태일 가능성이 큽니다. 이때는 "현재 결정에 필요한 사실만 10줄로 요약"한 뒤 새 스레드로 옮기는 편이 더 낫습니다.
둘째, 규칙을 매번 프롬프트에 넣을지 재사용 템플릿으로 뺄지 판단할 수 있습니다. 반복 작업이라면 짧은 공통 규칙은 템플릿화할 가치가 있습니다. 반대로 한 번성 질문이라면 긴 규칙 파일은 순손해일 수 있습니다.3
셋째, 참고 문서를 통째로 붙일지, 청크로 나눌지, 검색 기반으로 붙일지 고를 수 있습니다. 문서 전문을 매 턴 넣었을 때 토큰이 급증한다면, 그건 "모델이 더 똑똑해질 준비"가 아니라 "컨텍스트 예산을 문서 운반에 다 쓰는 상태"일 수 있습니다.
최적화가 항상 정답은 아니다
여기서 반론도 필요합니다. 모든 프롬프트를 극단적으로 줄이는 게 좋은 건 아닙니다. Anthropic도 Claude 4 계열이 원래 비교적 풍부한 응답을 내는 편이며, 원하는 길이는 프롬프트로 조정하라고 안내합니다.2 즉, 설명이 충분해야 하는 분석 작업, 규정 준수처럼 빠뜨리면 안 되는 업무, 긴 문서 추론은 어느 정도의 토큰 지출이 정상입니다.
그래서 기준은 단순합니다. 토큰을 줄이는 것이 비용, 속도, 품질 셋 중 하나라도 눈에 띄게 개선하면 최적화할 가치가 있습니다. 반대로 숫자만 예뻐지고 결과는 그대로라면 그건 과최적화입니다.
결국 Claude Token Counter를 가장 잘 쓰는 사람은 재무팀이 아니라, 프롬프트가 왜 불안정한지 추적하는 사용자입니다. 매일 Claude를 쓰는데 답변이 자꾸 비싸고, 느리고, 맥락을 놓친다면 지금 봐야 할 건 "모델이 멍청해졌나?"가 아니라 "내 컨텍스트가 어디서 새고 있나?"입니다.
참고
1Claude Token Counter, now with model comparisons
2Models overview - Claude API Docs
4Token Optimization and Cost Management for ChatGPT & Claude | IntuitionLabs
5I Measured Claude 4.7's New Tokenizer. Here's What It Costs You.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.