본문으로 건너뛰기

토큰 사용량(과 비용) 줄이기

중급

들어가는 모든 토큰과 나오는 모든 토큰에 비용을 지불합니다. 좋은 소식: 대부분의 실제 워크로드는 군더더기를 지고 있습니다 — 비대한 시스템 프롬프트, 다시 보내는 맥락, 장황한 응답, 쉬운 작업에 잘못 고른 모델. 그것을 덜어내면 품질을 건드리지 않고도 비용이 내려갑니다. 이 페이지는 대체로 지렛대 효과 순으로 정렬된 파워 유저 도구 모음입니다.

What you'll learn
  • 토큰이 실제로 새는 곳 — 입력 대 출력 대 재사용되는 맥락
  • 간결한 / '동굴인(caveman)' 스타일: 실제로 무엇을 절약하고, 어디서 역효과가 나는지
  • 달러 대 달러의 구조적 절감을 위한 프롬프트 캐싱과 배치
  • 모델 적정화(쉬운 작업엔 Haiku)와 산문 대신 구조화된 출력
  • 토큰 카운팅 엔드포인트로 배포 전에 측정하기

먼저, 토큰이 어디로 가는지 찾아라​

최적화하기 전에 지출을 세 개의 바구니로 나누세요 — 각각 해결책이 다릅니다:

세 개의 토큰 바구니
Enter 또는 스페이스 키를 눌러 카드를 뒤집습니다. 좌우 화살표 키로 카드를 이동할 수 있습니다.용어가 표시되었습니다.
1 / 3

해결책은 깔끔하게 정렬됩니다: 재사용되는 맥락은 캐시하고, 입력은 덜어내고, 출력은 줄이고, 모델은 적정화하고, 시간에 민감하지 않은 것은 배치하세요.

간결한 / "동굴인" 스타일 (출력 절감)​

유행하는 수법은 Claude에게 군더더기를 빼고 조각 문장으로 답하라고 시키는 것입니다 — 오픈소스 caveman Claude Code 스킬(MIT 라이선스, Julius Brussee 제작)이 대중화했으며, 그 표어는 "적은 토큰으로 되는데 왜 많은 토큰을 쓰나(why use many token when few token do trick)"입니다. 짧은 문장, 부정사 동사, 인사말 제로를 강제합니다.

독립 테스트의 정직한 결론: 이 스타일은 내용에는 비용이 들지 않지만(코드, 기술 용어, JSON은 정확히 유지) 절감액은 전적으로 당신의 기준선에 달려 있습니다. 프롬프트가 이미 "간결하게 하라"고 말한다면 대부분의 이득은 이미 확보된 셈입니다. 큰 감소(40–65%)는 설명이 많은 답변에서 나타나고, 구조화된 추출은 거의 움직이지 않습니다.

간결 지시 블록 — 시스템 프롬프트에 붙여넣기

Answer terse. Cut filler, hedging, and pleasantries.
Drop articles (a/an/the) and softeners (just, really, basically, actually).
No preamble, no restating the question, no "happy to help."
Fragments are fine. Keep technical terms and code blocks exact.
Pattern per point: [thing] [action] [reason]. Next step if any.
Pro tip
  • 간결 규칙은 매 사용자 턴이 아니라 시스템 프롬프트에 한 번만 넣으세요 — 반복하면 매 호출마다 입력 비용을 다시 지불합니다.
  • 코드, 식별자, JSON, 숫자는 절대 압축하지 마세요. 산문만 압축하세요.
  • '간결하게. JSON만 반환하라.' 자체가 달성 가능한 출력 절감의 약 60%입니다 — 더 화려한 기교에 손대기 전에 이것부터 쓰세요.
Watch out
  • 간결 스타일은 출력만 줄입니다. 매 호출마다 다시 보내는 2만 토큰짜리 시스템 프롬프트에는 아무 효과가 없습니다 — 그건 입력/캐싱 문제입니다.
  • 확장 사고 작업에서는 추론 토큰이 영향을 받지 않습니다. 최종적으로 보이는 답변만 줄어듭니다.

도구 출력이 맥락에 다시 들어오기 전에 압축하라 (RTK)​

Caveman은 Claude가 쓰는 것을 줄입니다. 에이전트 세션에서 거울처럼 반대편의 누수는 Claude가 다시 읽는 것입니다: 코딩 에이전트가 실행하는 모든 git status, npm test, ls -la, 빌드 로그가 — 헤더, 진행 막대까지 전부 — 다음 턴의 입력 토큰으로 맥락 창에 곧장 파이프됩니다. 긴 Claude Code 세션에서는 그 관찰 노이즈가 종종 시스템 프롬프트를 압도합니다.

rtk("Rust Token Killer", Apache-2.0, homebrew-core 등록)는 바로 이것을 겨냥한 CLI 프록시입니다. rtk init -g는 Claude Code PreToolUse 훅을 Bash 도구에(rtk hook claude) 설치하여, 각 명령을 rtk <command>로 투명하게 다시 쓰고 그 출력을 압축합니다 — 헤더와 시각적 노이즈를 벗기고, 유사한 줄을 묶고, 반복을 카운터로 중복 제거하고, 불필요한 부분을 잘라내어 — 모델에 도달하기 전에.

RTK 설치 및 전역 훅 연결 (macOS)

brew install rtk          # see the repo for cargo / other installers
rtk init -g --hook-only   # PreToolUse(Bash) hook only, no RTK.md file
# undo anytime: rtk init -g --uninstall

--hook-only 플래그는 토큰 예산에 중요합니다: 기본 rtk init은 매 세션마다 로드되는 RTK.md 지시 파일도 씁니다 — 절감액과 부분적으로 싸우는 고정 입력 비용입니다. 훅 전용은 출력 압축을 유지하면서 프리픽스에 아무것도 더하지 않습니다. 훅이 로드되도록 rtk init -g 후 Claude Code를 재시작하세요.

Pro tip
  • RTK와 caveman은 중복이 아니라 상호 보완적입니다: caveman은 모델 출력을 압축하고, RTK는 도구 결과 입력(매 턴 다시 공급되는 관찰)을 압축합니다. 둘을 쌓으면 양방향을 모두 커버합니다.
  • 훅은 Bash 호출마다 발동해 투명하게 다시 씁니다 — 프롬프팅 방식을 바꾸지 않습니다.
  • README가 아니라 실제 청구서로 측정하세요. 세션에 셸 명령이 적다면 RTK가 압축할 것이 거의 없습니다 — 그 이득은 도구 출력이 얼마나 시끄러운가에 비례합니다.

재사용되는 프리픽스를 캐시하라 (입력 절감)​

많은 호출이 크고 변하지 않는 덩어리를 공유한다면 — 긴 시스템 프롬프트, 도구 카탈로그, 참조 문서 — 프롬프트 캐싱은 그것을 한 번 처리하고 이후 모든 호출에서 입력 가격의 일부만으로 재사용합니다. 이것은 채팅과 에이전트 워크로드에서 단일 최고 지렛대 구조 변경입니다. 매 턴마다 되갚기 때문입니다.

단 하나의 규칙: 캐시된 프리픽스는 호출 간에 바이트 단위로 동일해야 합니다. 상단 근처의 떠도는 타임스탬프 하나나 재정렬된 도구 목록이 조용히 히트율을 0으로 떨어뜨립니다. 전체 메커니즘, 복사-붙여넣기 cache_control 스니펫, 히트 검증법은 프롬프트 캐싱 & 비용 최적화에 있습니다.

Guided walkthrough1 of 3
  1. 시스템 프롬프트, 도구, 문서를 앞으로 옮기고, 사용자의 변하는 턴은 끝에 두세요.

보내는 맥락을 덜어내라​

캐싱은 맥락을 싸게 재사용하지만, 가장 싼 토큰은 아예 보내지 않는 토큰입니다. 창에 실제로 무엇이 들어 있는지 감사하세요:

  • 시스템 프롬프트를 쳐내세요. 긴 지시 블록은 군더더기가 쌓입니다. 더 이상 토큰값을 못 하는 예시는 잘라내고, 평범한 다섯 개보다 강한 하나를 유지하세요.
  • 검색하되 쏟아붓지 마세요. 문서 전체를 붙여넣는 대신, 관련 구절만 가져오세요(RAG). 질문 하나에 답하려고 50페이지 PDF를 보내는 것이 가장 흔한 낭비입니다.
  • 긴 세션을 압축하세요. 대화가 커지면, 모든 메시지를 영원히 지고 가는 대신 오래된 턴을 짧은 요약으로 대체하세요. 히스토리는 매 호출마다 다시 지불하는 입력 토큰입니다.
  • 도구 카탈로그를 적정화하세요. 각 도구 정의는 매 요청의 입력 토큰입니다. 현재 작업에 필요한 도구만 노출하세요.
  • 정적 메모리 파일을 압축하세요. CLAUDE.md와 메모리 노트는 매 세션 다시 지불하는 재사용 입력입니다. 이들을 간결한 "동굴인" 산문으로 다시 쓰면(예: caveman 플러그인의 caveman-compress 명령) 일부를 덜어냅니다 — 하지만 이미 군살 없는 파일에서는 한 자릿수를 기대하세요: 빡빡한 약 350단어 CLAUDE.md를 직접 손본 결과 약 10%만 줄었습니다. 지렛대는 실재하지만 작습니다. 이것을 좇느라 전역 설정의 지시 명료성을 희생하지 마세요.

모델을 적정화하라​

Haiku급 작업에 Opus 요금을 내지 마세요. 분류, 추출, 단순 형식화, 라우팅은 대개 가장 작은 모델에서 토큰당 가격의 일부로 훌륭하게 돌아갑니다. 더 큰 모델은 정말로 어려운 추론에만 남겨두고, 라우팅을 고려하세요: 싼 모델이 쉬운 다수를 처리하고 어려운 경우만 승급합니다. 절충점은 모델 선택하기와 토큰, 컨텍스트 & 가격을 보세요.

산문보다 구조화된 출력을 선호하라​

설명 문단 대신 JSON(또는 다른 빡빡한 스키마)을 요청하면 출력 토큰을 줄이고 동시에 다운스트림의 파싱 추측을 없앱니다. Claude에게 {"label": ..., "score": ...} 같은 간결한 객체만 반환하라고 시키면 수다스러운 답변의 극히 일부만 생성하고 — "결과는 다음과 같습니다:" 같은 서두를 통째로 건너뜁니다. 자세한 내용은 구조화된 출력에 있습니다.

시간에 민감하지 않은 것은 배치하라​

초 단위 답이 필요 없는 오프라인 작업 — 평가, 대량 분류, 데이터셋 레이블링, 아카이브 요약 — 에 대해 Anthropic의 Message Batches API는 요청을 비동기로 실행하며 입력과 출력 토큰 모두 50% 할인하고, 결과는 보통 24시간 이내에 반환됩니다.

이것을 캐싱과 적정화된 모델에 쌓으면 큰 오프라인 작업의 결합 할인은 극적입니다.

측정하라 — 추측하지 마라​

느낌이 아니라 숫자에 맞춰 최적화하세요. Anthropic의 토큰 카운팅 엔드포인트는 보내기 전에 요청의 정확한 입력 토큰 수를 반환합니다 — Messages 호출과 같은 형태이며, 무료입니다(속도 제한 있음). 비대한 프롬프트와 덜어낸 프롬프트를 비교하고, 모델 라우팅 결정을 내리고, 프롬프트를 맥락 창 안에 유지하는 데 사용하세요.

보내기 전 토큰 세기 (Python SDK)

import anthropic

client = anthropic.Anthropic()

resp = client.messages.count_tokens(
  model="claude-opus-4-8",
  system="You are a scientist",
  messages=[{"role": "user", "content": "Hello, Claude"}],
)
print(resp.input_tokens)  # exact input count, no charge for counting
Pro tip
  • 다른 모델의 토크나이저(예: tiktoken)를 쓰지 마세요 — 모델 계열마다 수치가 다릅니다. Anthropic의 엔드포인트를 쓰세요.
  • 새 토크나이저는 같은 텍스트에 대해 구형 모델보다 약 30% 더 많은 토큰을 낼 수 있습니다 — 마이그레이션 시 다시 세고, 오래된 추정치를 재사용하지 마세요.
  • 응답 usage에서 input_tokens, cache_read_input_tokens, output_tokens를 읽어 프로덕션에서 절감이 실현됐는지 확인하세요.

카운팅 규칙과 비용 추정 공식은 토큰, 컨텍스트 & 가격을 보세요.

처음부터 끝까지 전후 비교​

지원 트리아지 어시스턴트가 매 티켓마다 동일한 4,000토큰 시스템 프롬프트 + 도구 카탈로그를 실행하고 수다스러운 600토큰 답변을 씁니다.

Guided walkthrough1 of 4
  1. 매 호출마다 정가로 다시 보내는 약 4,000 입력 토큰 + 약 600 장황한 출력 토큰, 큰 모델에서. 캐시 없음, 동기, 산문 답변.

각 지렛대는 곱셈적입니다: 캐시된 입력 × 더 작은 모델 × 더 간결한 출력 × 배치 할인이 복리로 큰 총감소를 만듭니다 — 이 쉬운 작업의 답변 품질은 변하지 않은 채로. 각 단계를 count_tokens로 측정해 이득을 가정이 아니라 증명하세요.

스스로 확인하기

0/4
  1. '동굴인' / 간결 스타일은 주로 어떤 토큰을 줄이는가?
  2. 매 호출마다 같은 1만 토큰 시스템 프롬프트를 다시 보냅니다. 최선의 해결책은?
  3. Message Batches API의 50% 할인에 가장 잘 맞는 워크로드는?
  4. 프롬프트 변경이 실제로 토큰을 절약했는지 어떻게 검증해야 하는가?
Key takeaways
  • 지출을 입력, 출력, 재사용 맥락으로 나누세요 — 각 바구니마다 해결책이 다릅니다.
  • 간결/'동굴인' 스타일은 출력만 줄입니다. 산문에서는 이득이 크고, 이미 간결한 구조화 작업에서는 작습니다.
  • 안정 프리픽스(바이트 단위 동일)를 캐시해 매 호출의 입력을 달러 대 달러로 절약하세요.
  • 맥락을 덜어내고, 모델을 적정화하고, 산문보다 JSON을 선호하세요 — 싸고 복리로 쌓이는 이득입니다.
  • 급하지 않은 작업은 50% 할인을 위해 배치하고, 추측하는 대신 항상 count_tokens로 측정하세요.

출처 & 더 읽을거리​

다음​