참고자료 · Token economics

토큰 경제학 — 같은 작업도 5~10배 차이가 나는 이유

같은 코드 작업을 두 팀이 수행해도, 어떤 도구와 어떤 운영 원칙을 쓰느냐에 따라 소비하는 토큰의 양은 크게 차이납니다. 이 페이지는 AI 코딩 환경에서 토큰 비용을 낮추는 네 가지 방법 — CLI 출력 압축, 프롬프트 캐싱, 모델 라우팅, 관측성 — 을 실제 검증 가능한 도구와 함께 정리합니다.

1. 토큰 비용이 왜 문제가 되는가

AI 코딩 도구의 청구서가 예상보다 빠르게 늘어나는 이유는 대부분 다음 네 가지입니다.

• Verbose CLI 출력: 빌드 로그, 패키지 설치 로그, 테스트 결과 전체를 컨텍스트에 그대로 투입해서 토큰이 급증합니다.
• 캐시 미활용: 시스템 프롬프트와 도구 정의가 매 세션마다 조금씩 달라져서 Anthropic · OpenAI 의 prompt caching 이 hit 되지 않습니다.
• 모델 오버스펙: 단순 grep 수준의 작업에도 최상위 모델을 쓰고, 실패하면 다시 최상위 모델로 재시도합니다.
• 관측 부재: 어떤 단계가 비용을 크게 쓰는지 측정하지 않아서, 개선 지점을 찾지 못합니다.

2. Layer 1 — CLI 출력 압축 (RTK 사례)

에이전트가 터미널에서 실행한 명령의 출력이 길면 그만큼 컨텍스트 창이 소비됩니다. 해결책은 긴 출력을 자동으로 요약하거나 핵심만 남기는 CLI 프록시 계층을 쓰는 것입니다. 본 저장소의 사용자 환경에는 RTK (Rust Token Killer) 가 설치돼 있어서 실제 측정 가능한 예시로 쓸 수 있습니다.

RTK 의 사용자 로컬 가이드에는 다음과 같이 정리돼 있습니다 (출처: 사용자 로컬 환경 ~/.claude/RTK.md).

RTK 는 Claude Code hook 을 통해 투명하게 동작합니다. 개발자가 터미널에서 치는 모든 명령이 RTK 프록시를 거쳐 가고, 긴 출력은 자동으로 필터링되어 에이전트 컨텍스트에는 압축된 형태로 전달됩니다. 사용자 가이드의 hook 관련 설명은 다음과 같습니다 (같은 출처).

RTK 는 또한 토큰 절약량을 측정하는 메타 명령을 제공합니다. 이 부분이 이 페이지 관점에서 가장 중요합니다 — “절약했다” 고 주장하는 대신 실제 수치로 볼 수 있어야 합니다.

# 토큰 절약 분석 (사용자 환경: ~/.claude/RTK.md)
rtk gain              # 전체 토큰 절약 수치 표시
rtk gain --history    # 명령별 사용 이력 + 절약량
rtk discover          # Claude Code 이력에서 놓친 절약 기회 탐지
rtk proxy <cmd>       # 필터링 없이 원본 실행 (디버깅용)

# 설치 확인
rtk --version
rtk gain
which rtk

RTK 는 공개 저장소 github.com/rtk-ai/rtk 에서 운영됩니다. Rust 단일 바이너리로 배포되며, macOS 에서는 brew install rtk 한 줄로 설치할 수 있습니다. 100 여 개 이상의 명령어 (git, cargo, pytest, vitest, AWS / Docker / Kubernetes CLI 등) 에 대한 압축 프로파일을 기본 제공합니다. 공식 문서에 기록된 구체 사례로는 git status 약 80% 절감, cargo test 약 90% 절감, 30분 Claude Code 세션 150,000 → 45,000 토큰 (약 70% 감소) 이 언급됩니다.

3. Layer 2 — Prompt Caching (Anthropic + OpenAI)

두 번째 층은 시스템 프롬프트와 도구 정의를 캐시에 올려서 매번 다시 과금되지 않게 만드는 것입니다. Anthropic 과 OpenAI 모두 공식 기능으로 제공합니다.

3.1 Anthropic Prompt Caching

Anthropic 은 cache_control 파라미터로 프롬프트의 특정 부분을 캐시 지점 (cache breakpoint) 으로 지정할 수 있게 합니다. 해당 지점 이전까지의 내용은 재사용될 때 대폭 할인된 요율로 과금됩니다. 공식 문서는 다음 URL 입니다 (docs.anthropic.com/en/docs/build-with-claude/prompt-caching).

// Anthropic Messages API — prompt caching 예시
// 출처: https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching
const response = await anthropic.messages.create({
  model: "claude-opus-4-6",
  max_tokens: 1024,
  system: [
    {
      type: "text",
      text: "You are a senior Kotlin reviewer for the aiops-api project.",
    },
    {
      type: "text",
      text: LARGE_CODEBASE_CONTEXT, // 이 부분을 캐싱
      cache_control: { type: "ephemeral" },
    },
  ],
  messages: [
    { role: "user", content: "이 PR 에 보안 리뷰 부탁합니다." },
  ],
});

3.2 OpenAI Prompt Caching

OpenAI 는 프롬프트의 앞부분(prefix) 이 이전 요청과 같으면 자동으로 캐시를 활용합니다. 별도의 플래그가 없이, 동일한 prefix 를 유지하는 것만으로 캐시 hit 가 발생합니다. 공식 가이드는 다음 URL 입니다 (platform.openai.com/docs/guides/prompt-caching).

두 API 의 설계는 다르지만, 운영 원칙은 같습니다. 시스템 프롬프트와 도구 정의가 요청마다 조금씩 바뀌면 캐시가 깨집니다. 따라서 다음 세 가지를 지켜야 합니다.

• 시스템 프롬프트의 앞 부분을 고정합니다. 동적 값 (현재 시간, 세션 ID 등) 은 뒤쪽 user 메시지에만 둡니다.
• 도구 (tool / function) 정의의 순서를 변경하지 않습니다. 한 개만 바뀌어도 캐시가 무효화됩니다.
• 매 세션마다 재사용되는 긴 컨텍스트 (코드베이스, 문서, 예시) 는 반드시 캐시 대상 영역에 둡니다.

실제 얼마나 절약되는지는 캐시 hit 비율과 prefix 길이에 따라 다르므로, 이 페이지는 “몇 배 절약“ 같은 단정 수치를 피합니다. 양쪽 공식 문서에 명시된 정확한 요율을 직접 확인해 주십시오.

4. Layer 3 — 모델 라우팅

세 번째 층은 모든 작업을 최상위 모델에 던지는 대신, 작업 복잡도에 따라 모델을 다르게 배치하는 것입니다. 간단한 grep, 파일 이동, 단순 반복 작업은 Haiku 급 모델이면 충분한 경우가 많고, 설계·대규모 리팩토링만 Opus 급 모델에 맡기는 식으로 분기합니다.

Anthropic 은 이 패턴을 “Building effective agents” 에서 공식적으로 권장합니다 — 워크플로의 각 단계에 가장 단순한 모델을 배치하고, 필요할 때만 더 복잡한 모델을 호출하라는 원칙입니다 (anthropic.com/engineering/building-effective-agents).

모델 라우팅은 직접 구현할 수도 있지만, Vercel AI Gateway (vercel.com/docs/ai-gateway) 나 OpenRouter 같은 게이트웨이 서비스가 요청을 프록시하면서 모델 선택·failover·캐싱을 통합 관리해 주기도 합니다.

5. Layer 4 — 관측성 (Observability)

마지막 층은 “측정 없이는 개선도 없다” 원칙입니다. 어느 단계가 가장 많은 토큰을 쓰는지, 어느 프롬프트가 캐시 hit 에 실패하는지, 어느 도구 호출이 비용을 튀게 만드는지 실제로 측정하지 않으면 개선할 지점을 찾을 수 없습니다. 오픈소스 · SaaS 세 가지를 소개합니다.

세 도구 모두 같은 질문에 답합니다. “어느 요청이 가장 많은 토큰을 썼는가”, “캐시 hit 비율은 얼마인가“, ”평균 latency 는 어떻게 변하고 있는가“, ”어떤 사용자 플로가 가장 비싼가“. 이 수치를 매주 한 번이라도 보면 운영 원칙이 감에서 수치로 바뀝니다.

6. 운영 원칙 — 네 층을 묶는 일상 습관

• Front-load context: 필요할 것 같은 핵심 파일 경로·제약·규칙을 첫 번째 메시지에 한 번에 전달합니다. 에이전트가 탐색에 토큰을 덜 씁니다.
• 작은 작업은 작은 모델에게: 파일 이동, grep, 포맷 수정 같은 루틴에는 Haiku / GPT mini / 로컬 작은 모델을 씁니다.
• 캐시 prefix 를 건드리지 마십시오: 시스템 프롬프트 앞 부분, 도구 정의 순서, 예시 세트 순서는 고정해 두어야 Anthropic · OpenAI 프롬프트 캐시가 hit 됩니다.
• 긴 출력은 파일로: 빌드 로그, 테스트 결과, 패키지 설치 로그 같은 긴 출력을 에이전트 컨텍스트에 그대로 붓지 말고, 파일에 저장하고 요약만 전달합니다.
• 관측 대시보드를 주 1회 봅니다: Helicone · LangSmith · Phoenix 중 어느 것이든 좋습니다. 보지 않으면 개선도 없습니다.
• 실패 retry 를 막습니다: 같은 실패를 재시도하는 것만큼 비싼 것이 없습니다. 실패 시 반드시 짧은 log 로 원인을 확정한 뒤 접근을 바꿉니다.

7. 실제로 측정하기 — 이 페이지의 마지막 원칙

이 페이지의 모든 권장안은 환경에 따라 효과가 다릅니다. 어떤 팀은 RTK 로 70% 절약을 보고, 어떤 팀은 캐시 정렬로 50% 절약을 봅니다. 가장 큰 병목은 팀마다 다르기 때문에, 권장안을 전부 도입하기 전에 지금의 기준선을 먼저 측정 하십시오. 한 주 동안의 총 토큰 사용량과 세션당 평균 비용을 기록하고, 변경 후 같은 기간을 다시 측정하면 개선 여부를 판단할 수 있습니다.

8. 같이 읽으면 좋은 페이지

9. Sources

• RTK — Rust Token Killer: 사용자 로컬 환경의 운영 가이드 ~/.claude/RTK.md. 공개 저장소 URL 은 [출처 미확인] — 각자 환경에서 같은 패턴(CLI 프록시 + hook 기반 투명 재작성)을 구현하셔도 됩니다.
• Anthropic Prompt Caching 공식 문서: docs.anthropic.com/en/docs/build-with-claude/prompt-caching
• OpenAI Prompt Caching 가이드: platform.openai.com/docs/guides/prompt-caching
• Anthropic Building Effective Agents: anthropic.com/engineering/building-effective-agents
• Vercel AI Gateway: vercel.com/docs/ai-gateway
• Helicone 공식 사이트: helicone.ai
• LangSmith 공식 사이트: smith.langchain.com
• Arize Phoenix 오픈소스 LLM observability: phoenix.arize.com

← 참고자료 인덱스로 돌아가기