수업 #16 — 토큰 어디서 새는 거야?

Source: bbojjak-viewer.vercel.app/lessons/lesson-16 Type: article By: 뽀짝이 / 뽀짝이의 서재 (지피터스 AI스터디) Valid as of: 2026-04-28

Key Insight

AI 에이전트의 토큰은 “코드 짜기”보다 “읽기(CLI 출력·API 응답)“에 더 많이 소비된다. RTK로 CLI 출력을 60~90% 압축하고, hook이 안 되면 AGENTS.md 지침으로 동일 효과를 낸다. “자동화가 안 되면 규칙으로.”

핵심 Takeaway

  • 토큰 소비처 5순위: CLI 출력(1위) > API 응답 > 파일 반복 읽기 > 대화 히스토리 > 시스템 프롬프트. 실제 필요 정보는 CLI 출력의 20~30%뿐 (출처: “토큰이 새는 곳을 찾아라” 섹션)
  • RTK = CLI 출력 압축 프록시: rtk git status 2,074자 → 457자 (78% 감소). brew install rtk-ai/tap/rtk && rtk init --global 2줄 설치. 30개+ 명령 지원 (출처: “RTK — 토큰 킬러 등장” 섹션)
  • hook vs 지침 차이: Claude Code는 PreToolUse hook으로 자동 치환. OpenClaw exec는 hook 경로 외부 → AGENTS.md에 “rtk 접두어 붙이기” 지침 한 줄로 동일 효과. “자동화가 안 되면 규칙으로” (출처: “Claude Code에서는 자동, OpenClaw에서는?” 섹션)
  • 14일 토큰 대시보드: 뽀짝이 75%·하트비트 27%·Opus 85%. → 하트비트 Sonnet 전환(1/5 비용), 시스템 프롬프트 390→161줄 다이어트, 장시간 세션 분할 (출처: “타타의 질문” 섹션)
  • 능동적 compact 원칙: 95% 자동 컴팩션 전 10만 토큰에서 능동 compact, 15만에서 메모리 기록 후 세션 정리. 자동 컴팩션은 맥락 유실 위험 (출처: “RTK 말고도” 섹션)

상세 요약

토큰 소비 구조

AI 에이전트에서 “코드를 짜는 데 드는 토큰”보다 “코드를 짜기 위해 읽는 것에 드는 토큰”이 더 많다.

순위소비처특징
1CLI 출력git status 2,000자, 실 필요 정보 20~30%
2API 응답필요 필드 3개에 20개 딸려옴
3파일 반복 읽기AGENTS.md를 세션 중 3~4회 재읽기
4대화 히스토리처리 끝난 CLI 결과가 계속 컨텍스트 차지
5시스템 프롬프트매 턴마다 6개 파일 주입 — 불필요하게 길면 누적 낭비

14일 토큰 대시보드 데이터 (2026-02-26 ~ 2026-03-11)

지표
총 API 환산 비용$928
총 세션915
총 API 호출10,127
뽀짝이 비중75% ($700)
하트비트 비중27% (1위)
Opus 사용 비중85%
가장 비싼 단일 세션$73 (1,329 calls)

→ 개선 포인트: 하트비트 Sonnet 전환(비용 1/5), 시스템 프롬프트 다이어트, 장시간 세션 분할

RTK 작동 원리

rtk git status
→ 불필요한 안내 메시지·스테이징 가이드 제거
→ 핵심 변경 파일 목록만 출력
→ 2,074자 → 457자 (78% 감소)

rtk gain 누적 확인: 11회 실행, 3.8K 토큰(80.2%) 절약.

Hook vs 지침 — 두 가지 실행 환경

항목Claude CodeOpenClaw
RTK 자동 적용PreToolUse hook 자동 등록hook이 exec에 미트리거
설정 위치~/.claude/settings.jsonAGENTS.md 지침
에이전트 인지치환을 인식 안 함규칙 읽고 스스로 실행
효과동일동일

교훈: 시스템 구조(hook)로 자동화할 수 없으면, 에이전트에게 규칙(AGENTS.md)으로 행동을 지시해도 같은 효과를 낼 수 있다. 이는 harness-engineering의 “지침 vs 시스템 2중 방어선”의 실전 적용이다.

토큰 절약 전략 5가지

  1. RTK — CLI 출력 압축 (1위 소비처 직접 공략)
  2. 능동적 compact — 10만 토큰에서 compact, 15만에서 메모리 기록 후 세션 정리
  3. 서브에이전트 Sonnet — 무거운 작업을 Sonnet 서브에이전트에 위임 (Opus 대비 1/5 비용 + 새 컨텍스트)
  4. read offset/limit — 대형 파일 부분 읽기
  5. NO_REPLY — 반응 불필요한 메시지 출력 생략 (답변 생성 자체가 토큰 비용)

연결되는 위키 페이지