토큰 절약, 그리고 Caveman

들어가며

caveman이라는 스킬이 요즘 hype을 많이 받고 있습니다. 블로그나 소개글을 보면 원시인 우가우가 수준으로 토큰을 압축하는 줄 알았는데, 실제로 며칠 써보니 그렇진 않더라구요. 이런 오해가 해소될 수 있도록 과거 토큰 압축 시도들에 관한 역사와 현재 caveman까지 간략하게 한번 적어보았습니다.

토큰 절약의 역사

토큰 절약, 토큰 압축. 아마 3~4년 전 AI 엔지니어링을 했던 사람이라면 다들 엄청 고민했을 겁니다. 하지만 토큰 생성과 가격이 효율적이 되면서 요즘은 고려되지 않는 추세였습니다. 그런데 하네스 엔지니어링 이후 점점 automation이 가속화되니 토큰 사용량이 늘고, 다시금 사람들이 토큰 절약에 관심이 많아졌습니다. 이 부분이 흥미로워서 글을 쓰고 있는 거고요.

GPT-3.5 시절, 더 이전 text-davinci를 쓰던 시절에는 속도도 느리거니와 토큰이 많아지면 금액이 천정부지로 올라가서 최적화가 필수였습니다. text-davinci-003만 해도 1k 토큰당 $0.02였고, GPT-3.5-turbo가 나오면서 10배 싸진 $0.002가 되어서야 비로소 컨슈머 애플리케이션이 가능해졌죠. 그 당시 AI 기능이 회사 서비스에 public하게 들어가는 상황이었기에 토큰을 줄이는 데 집착했었습니다. 무료 유저들이 마구잡이로 생성하면 요금을 감당할 수 없으니까요.

컨텍스트 윈도우도 지금과는 비교가 안 됐습니다. GPT-3는 2,048 토큰, text-davinci-003과 GPT-3.5-turbo가 겨우 4K 남짓한 컨텍스트 윈도우였죠. 지금이야 200K, 1M 토큰을 자랑하는 시대지만, 그 당시엔 input/output 합쳐서 4k 안 쓰려고 최대한 짧게 만드는 게 일이었습니다.

또한 지금은 상상하기 어려운데, 그 당시 토큰 생성은 정말 느렸습니다. 지금이야 결과가 문장 단위 혹은 페이지 단위로 짠- 하고 나타나지만, 그때는 토큰 스트림을 찍어보면 하나하나 생성되는 게 눈으로 따라갈 수 있을 정도였습니다.

과거 토큰 절약을 위한 다양한 시도들

이 섹션에서는 전 회사에서 작업하면서 겪은 문제들과 해결책들을 이야기하면서, 과거 어떻게 토큰 절약을 시도했었는지 이야기해 보겠습니다. 토큰 절약에는 여러 가지 방법이 있겠지만, 효율이 진짜 큰 건 아래 3가지였습니다.

우선 포맷 수정이 1순위였습니다. 여기서 포맷이란 JSON이나 XML/HTML 형식으로 쓰는 것 말이죠. 지금이야 마크다운으로 쓰는 게 보편화됐지만, 당시에는 JSON이나 XML 그대로 input/output을 사용하는 사람이 많았습니다. 그런데 그 방식은 실제 토크나이즈 시 생성되는 토큰이 너무 많습니다. 예를 들어 <h1>Hello world</h1>는 8토큰입니다. 그리고 # Hello world를 쓰면 3토큰이죠. 절반 이상 줄어들었습니다. JSON이나 XML은 모든 여는 태그마다 닫는 태그가 필요해서 구조적 오버헤드가 두 배가 됩니다. 최근 비교 분석에서도 XML이 JSON 대비 14% 더 많은 토큰을 쓰고, 마크다운은 동일 표현 대비 약 15% 토큰을 절약한다는 결과가 소개된 바 있습니다.

그래서 마크다운 그리고 #### 같은 1토큰만 쓰는 delimiter를 사용하면서 많은 토큰을 절약할 수 있었습니다.

비용만 줄어든 게 아니라 응답 속도도 같이 좋아졌습니다. 당시엔 좀 긴 300자 정도 되는 아웃풋이라면 한 응답에 30초씩 걸리는 경우가 흔했는데, input과 output을 짧게 만드는 것만으로 적게는 30%, 길게는 70%까지 응답 시간이 단축됐죠. 토큰당 생성 속도가 스트림으로 보면 눈으로 생성되는 게 보일 정도로 느렸던 시절이라, output 토큰을 줄이는 게 곧 체감 속도 개선으로 이어졌습니다.

디테일의 시대로

새로운 버전이 나올수록 모델이 스마트해지면서, 2023년 중순부터는 흐름이 바뀌었습니다. 지나치게 간결한 것보다는 좀 더 디테일한 정보를 넣는 방식의 프롬프트 작성으로 전환됐죠. 모델이 똑똑해지니까 충분한 컨텍스트를 줄수록 더 좋은 결과를 내주더군요.

지금은 Anthropic이 Claude에 여전히 XML 태그 사용을 권장합니다. Anthropic 문서에서도 XML 태그가 복잡한 프롬프트를 더 명확하게 구조화하고, instructions, context, examples, input을 구분하는 데 도움 된다고 설명합니다. 토큰을 좀 더 쓰더라도 명확성이 더 중요하다는 거고, 그만큼 토큰 가격이 떨어졌다는 방증이기도 하고요.

결과도 굉장히 좋아졌습니다. 예전에는 JSON output으로 프롬프트를 짜놓아도 별도의 output parser가 없다면 오류 나기 일쑤였는데, 요즘은 따로 output parser가 필요 없을 정도로 정확하게 결과를 포맷에 맞춰 생성해 줍니다.

다시 짧고 간결하게

output 생성이 빠르니 아무리 긴 문장도 예전과 비슷하게, 혹은 더 빠르게 출력해줬습니다. 하지만 역설적이게도 읽을 게 늘어나니 사용자에게도 부담이 되어버렸습니다. 또한 토큰 낭비가 화두에 오르면서 Caveman이나 RTK 같은 툴들이 요즘 다시 각광받고 있습니다. RTK는 CLI 출력을 압축해주는 툴이고, 그 외에도 Codebase Memory MCP, context-mode, Headroom 같은 도구들이 비슷한 맥락에서 등장했죠. 마치 유행이 돌고 돕니다.

토큰 컴프레스 툴 소개

요즘 다시 각광받고 있는 토큰 압축 툴들을 간단히 소개해 봅니다.

Caveman

Caveman은 LLM의 출력을 짧게 만들어서 토큰을 줄이는 방식의 스킬입니다. 절반 이상의 토큰 감소를 시켜준다고 합니다. 핵심은 간단한데, 정중한 마무리, 부연 설명, 인사말 등 실제로 쓸모없는 아웃풋을 줄여주는 방식으로 토큰을 절약합니다.

그러면 왜 caveman일까요? 모드에 따라서 다르지만 진짜 필요한 단어만 있을 정도로 압축해버려서 마치 원시인이 말하듯이 되어버린다고 해서 caveman입니다. 재미있는 네이밍이죠.

예를 들면 이런 식입니다.

일반 Claude (69 tokens):
"The reason your React component is re-rendering is likely
because you're creating a new object reference on each render
cycle. When you pass an inline object as a prop..."

Caveman Claude (19 tokens):
"New object ref each render. Inline object prop = new ref
= re-render. Wrap in useMemo."

기술적 정확성은 그대로 유지하면서 문장을 짧게 만든다는 컨셉이라 재밌더군요.

최근에 프로젝트 헤일메리를 보는데 Caveman 모드가 딱 Rocky의 말투 같더군요. "Question, question!" "Good. Good." 짧지만 의미는 다 통하죠. LLM도 caveman을 켜면 이런 식으로 변합니다.

쉽게 하는 오해

블로그나 유튜브 등에서 진짜 원시인처럼 말하듯이 컨텍스트를 변환하는 것처럼 설명하고 있어서 많이들 오해하는데, 여러 모드를 지원하기도 하고 기본 모드면 사실 예전에 be concise를 맨 끝에 추가하는 정도로 압축합니다. 아마 유튜브나 다른 블로그들에서 말하는 건 드라마틱한 변화를 보여주기 위해 최대 압축 모드를 사용했기 때문일 겁니다. 그렇기에 걱정하는 것처럼 성능에 크게 이슈도 없고, 오히려 가끔 더 결과가 좋기도 하더군요.

언제 쓰면 좋을까?

개인적으로는 결과에 영향이 간다는 이야기도 있고 해서, 아래 상황에서 보통 쓰곤 합니다.

1. 구독 모델의 1주일 사용량 quota가 얼마 안 남았을 때
2. Goal/Ouroboros/autopilot 등 토큰을 장기간 많이 사용하는 작업을 할 때
3. 리뷰하기 편하게 응답이 간결했으면 좋겠을 때

Caveman Compress

그 외에도 caveman compress라는 기능도 있습니다. 기존에 사용 중인 시스템 프롬프트나 스킬들을 효율적으로 압축해줍니다. 프롬프트 엔지니어링이 한창 유행할 때 사람이 직접 해야 했던 것들인데, 이제 LLM 성능이 하도 좋으니 저도 마지막으로 프롬프트 하나하나 꼼꼼하게 짠 적이 언젠지 가물가물하네요.

RTK

RTK(Rust Token Killer)는 caveman과는 접근 방식이 다릅니다. Caveman이 LLM의 출력 자체를 짧게 만드는 방식이라면, RTK는 CLI 명령어의 결과를 LLM에게 전달되기 전에 압축하는 프록시 방식이죠. 예를 들어 git status, ls, cargo test 같은 명령어 결과의 군더더기를 잘라내서 60~90% 토큰을 줄여줍니다. Claude Code의 Bash 훅으로 자동 동작해서 명령어가 알아서 rtk git status 같은 식으로 rewrite됩니다. Caveman과 RTK를 같이 쓰면 입력과 출력 양쪽에서 토큰을 줄일 수 있는 셈입니다.

Caveman vs RTK

둘은 경쟁 관계가 아니라 보완 관계입니다. 같이 쓰면 input/output 양쪽 모두에서 토큰을 아낄 수 있습니다.

마치며

요즘 AI를 한 2~3일 빡세게 쓰면 Codex Pro 사용량의 70%가 증발합니다. Gemini는 아직 믿고 쓰지 못하고 있어서 Claude Max로 다시 업그레이드해야 하나 고민하던 차였는데, 최근 회사에서 Dave 형님이 caveman을 추천해 줘서 써보게 됐습니다.

퀄리티를 걱정했으나 여러 모드를 지원하고, 심지어 2026년 3월 논문에서는 brevity 제약이 특정 벤치마크에서 정확도를 26포인트 향상시켰다는 결과도 있다고 하니, 짧게 쓰는 게 꼭 손해는 아닌 것 같습니다.

결국 옛날에 토큰 하나하나 아껴 쓰던 그 노력이 지금은 스킬 한 줄 설치로 끝나는 시대가 됐네요.

Refs

• JuliusBrussee/caveman (GitHub)
• rtk-ai/rtk (GitHub)
• Elastic-caveman for token reduction with Claude
• Caveman Review: The Claude Code Skill That Cuts 65% of Tokens
• Does Caveman AI Really Cut 65% of Claude Tokens?
• Reduce Claude Code Tokens: 10 Tested Tools (RTK, Caveman, etc.)
• How I Cut Claude Code Token Usage by 90%+ With 5 Tools
• Markdown vs. XML in Prompts for LLMs: A Comparative Analysis
• Prompt Compression: 8 Techniques to Reduce LLM Costs