이 기사에서 알 수 있는 것

Claude Code의 토큰 비용이 걱정되어 "절감 도구"를 찾다 보면, 현재 일본어권에서도 이 4가지가 반드시 등장합니다.

rtk (Rust Token Killer) -
headroom (44.3k⭐, Netflix 엔지니어 개발) lean-ctx h5i

그리고 모두가 "최대 90~99% 절감"이라고 주장합니다. 여기서 많은 사람이 다음과 같은 문제에 부딪힙니다.

"그래서 결국 뭘 설치해야 해? 전부 다? 하나만? 중복되지는 않아?"

결론부터 말하자면, 이 4가지는 서로 충돌하지 않습니다. 압축하는 "레이어 (layer)"가 다르기 때문에, 올바르게는 "적층 (layering)"하여 사용합니다. rtk와 headroom는 동시에 설치해도 둘 다 효과가 있습니다.

이 기사는 4가지 도구를 "같은 선상의 비교"가 아니라 "역할 분담의 지도"로서 정리합니다. 읽고 나면 당신의 사용 방식(코드베이스 중심인지, 장시간 세션 중심인지, 감사 로그가 필요한지)에 따라 설치해야 할 도구와 설치 순서가 결정됩니다.

★ 왜 혼란스러운가 — "최대 99% 절감"이 4번이나 나오는 이유

4가지 모두가 "최대 99% 절감"이라고 말할 수 있는 이유는, 측정하는 대상이 다르기 때문입니다. 같은 숫자라도 깎아내는 부분이 별개입니다.

LLM 에이전트에게 전송되는 토큰은 대략 4개의 층으로 나뉩니다.

쉘 출력층 (Shell Output Layer) — git diff, git log, grep, ls -R 등 명령어의 거대한 표준 출력 (Standard Output) -
파일 읽기층 (File Reading Layer) — Read를 통해 소스를 통째로 읽거나, 같은 파일을 반복해서 읽는 경우 -
대화 컨텍스트층 (Conversation Context Layer) — 장시간 세션에서 불어나는 과거의 대화 전체 -
기록·감사층 (Logging/Audit Layer) — 압축된 원본 데이터를 나중에 완전히 복원할 수 있는지 여부 (Provenance)

"최대 99% 절감"이라는 같은 말이, 1번의 이야기인지 3번의 이야기인지에 따라 의미가 완전히 달라집니다. 이 부분을 혼동한 채로 "어느 것이 가장 많이 깎나?"라고 비교하면 영원히 답을 얻을 수 없습니다.

4가지 도구는 각각 다른 층을 주전장으로 삼고 있습니다. 그래서 비교가 아니라 지도인 것입니다.

💡 이 표를 머릿속에 넣으면, 더 이상 "하나만 골라야 하나?"라고 고민할 필요가 없습니다.

자신의 병목 현상이 어느 층인지를 결정하기만 하면 됩니다.

전제 지식 — 애초에 왜 토큰을 깎는가

토큰 절감이 효과적인 이유는 두 가지가 있습니다.

비용 (Cost): API 종량제라면 입력 토큰이 곧 과금액입니다. 긴 컨텍스트를 매 턴마다 보내는 것은 비용이 많이 듭니다. -
정확도 (컨텍스트 저하): 컨텍스트가 불어나면 모델이 정말 중요한 정보를 놓치는 "lost in the middle" 현상이 발생합니다. 절감은 절약뿐만 아니라, 답변 품질의 유지이기도 합니다.

이 부분이 중요한데, 이 4가지 도구의 우수한 점은 "그냥 지우는 것"이 아니라 "지워도 답이 바뀌지 않는다"는 것을 설계 목표로 삼고 있다는 점입니다. 실제로 후술할 headroom는 표준 벤치마크 (GSM8K 등)에서 압축해도 정답률이 떨어지지 않음을 보여주고 있습니다 (※ 2026년 6월 시점의 공개 벤치마크).

셋업 — 각 도구의 설치 방법 (최소)

각 도구의 도입 커맨드입니다 (※ 2026년 6월 기준. 공식 최신 절차는 각 리포지토리에서 확인하십시오).

rtk (쉘 출력층)

# Rust 제작 · Apache 2.0. GitHub: rtk-ai/rtk
# Claude Code의 settings.json에 PreToolUse 후크를 심어,
# Bash 실행 시마다 명령어 출력을 자동 압축한다 (rtk git diff와 같이 수동 래핑도 가능)
...

lean-ctx (파일 읽기층)

# 파일 읽기를 함수 시그니처 중심으로 압축, 재읽기를 캐시
# 도입은 GitHub: lean-ctx 를 참조

headroom (대화 컨텍스트층)

# Python
pip install "headroom-ai[all]"
# 또는 Node
...

라이브러리로도 사용할 수 있습니다.

from headroom import compress
compressed = compress(messages) # messages를 압축하여 반환

h5i (기록·감사층)

# 출력을 압축하면서, 원본 데이터를 git에 커밋하여 완전 복구가 가능하게 함
# 도입은 GitHub: h5i-dev/h5i 를 참조

핵심 — 4가지 도구가 "경합하지 않는" 실례

가장 효과적인 방법은 층(layer)을 가로질러 쌓는 것입니다. 대표적인 예가 rtk + headroom입니다.

• rtk가 명령어 실행 순간에 거대한 git diff를 압축합니다 (① 입구에서 깎아냄)
• headroom이 세션 전체에서 과거 대화를 계속해서 압축합니다 (③ 축적된 양을 깎아냄)

두 도구는 깎아내는 지점이 겹치지 않기 때문에, 더했을 때 효과가 나타납니다. 이것이 "경합이 아닌 적층"의 의미입니다.

반대로, 같은 층을 노리는 도구들(예: 셸 출력층의 rtk와 h5i)은 역할이 비슷하기 때문에 둘 중 하나를 선택해야 합니다. h5i는 "압축 + git을 통한 완전 복구(감사 로그)"가 주 목적이므로, 순수하게 줄이는 것이 목적이라면 rtk, 복구 가능한 기록이 필요하다면 h5i로 구분하여 사용합니다.

⚠️ 여기가 정리의 핵심입니다:

경합하는 것은 "같은 층"의 도구뿐입니다. 다른 층이라면 함께 사용할 수 있습니다.

5가지 "층별 벤치마크" — 어떤 층에서 몇 %를 줄일 수 있는가

공개 벤치마크와 각 공식 README를 바탕으로, 층별 절감률의 대표값을 정리합니다 (※ 모두 2026년 6월 기준이며, 출처는 각 리포지토리/공개 벤치마크입니다. 반드시 자신의 워크로드로 재측정하십시오).

• 셸 출력층 (rtk): git log에서 약 84%, git diff에서 약 99%, grep에서 약 97%. 거대하고 반복적인 출력일수록 효과적입니다.
• 셸 출력층 (h5i): git log -p에서 약 99%, grep에서 약 94%. 단, ls -laR과 같은 작은 출력에서는 오버헤드로 인해 오히려 늘어날 수 있습니다.
• 파일 읽기층 (lean-ctx): 함수 시그니처만 추출할 경우 약 96%, 동일 파일의 재읽기 캐시는 거의 제로(십수 토큰 급)까지 압축합니다. 반면 git diff는 의도적으로 **그대로 통과(0%)**시킵니다.
• 대화 컨텍스트층 (headroom): 약 30만 토큰의 대화에서 약 93% 절감. GSM8K(산수)에서 정답률 저하가 없으며, TruthfulQA는 오히려 미세하게 개선되었다는 보고가 있습니다. 가역 압축(CCR)을 통해 원본 데이터는 로컬에 유지하며, 필요 시 복구합니다.
• 실제 워크로드 (headroom 공식): 코드 검색 92%, SRE 디버깅 92%, Issue 트리아지 73%. 표준 벤치마크(GSM8K/SQuAD/BFCL 등)에서는 19~32% 압축 시 정확도를 유지합니다.

같은 "99%"라 하더라도, git diff(rtk/h5i)와 재읽기 캐시(lean-ctx), 그리고 대화 압축(headroom)은 완전히 다른 방식의 절약임을 알 수 있습니다.

공식의 관점 — headroom이 "가역성"에 집착하는 이유

headroom이 다른 도구와 차별화되는 점은 **CCR (가역 압축, Lossless Compression)**입니다. 압축하여 LLM에 전달하는 페이로드(payload)는 정보를 걸러내지만, 원본 데이터는 로컬에 그대로 남습니다. 모델이 "역시 상세 정보가 필요하다"라고 판단하면 headroom_retrieve를 통해 완전 복구할 수 있습니다.

이는 "손실 압축(lossy)으로 깎아내면, 나중에 모델이 곤란해진다"는 실패를 피하기 위한 설계입니다. 토큰 절감 도구의 최대 리스크는 "너무 많이 깎아서 답변의 질이 저하되는 것"입니다. 가역성은 그에 대한 보험이 됩니다.

또한 headroom은 CacheAligner를 통해 프리픽스(prefix)를 안정화하여 **KV 캐시의 히트율(hit rate)**을 높입니다. 이는 "절감"과는 별개의 축으로, 캐시가 효과적으로 작동하면 실제 비용이 추가로 낮아지는 이중 구조를 가집니다.

흔히 저지르는 안티 패턴 6선

토큰 절감 도구를 사용할 때 빠지기 쉬운 전형적인 사례를 듭니다.

• "가장 많이 줄여주는 도구"를 하나만 찾는다 — 층이 다르기 때문에 "가장 좋은 것"은 존재하지 않습니다. 병목이 발생하는 층을 먼저 특정하는 것이 우선입니다.
• 작은 출력에도 압축을 적용한다 — ls

정도 낮은 소량의 출력은 압축 오버헤드로 인해 오히려 늘어날 수 있다 (h5i의 예). 임계값(Threshold)을 설정할 것. -
비가역적 압축으로 중요 정보를 삭제함— 에러 로그나 스택 트레이스(Stack Trace)를 너무 요약하여 디버깅이 불가능해짐. 가역적(CCR/h5i의 git 저장) 방식을 선택하거나, 대상을 선별할 것. -
diff를 압축 대상에서 누락하거나 / 반대로 너무 뭉개버림— lean-ctx는 diff를 그대로 통과시키는 철학을 가짐. diff는 정보 밀도가 높으므로 압축 방식에 주의할 것. -
캐시를 망가뜨리는 압축을 수행함— 프리픽스(Prefix)가 매번 바뀌는 압축을 하면 KV 캐시(KV Cache)가 작동하지 않아, 비용 절감의 대가로 캐시 할인 혜택을 잃게 됨. -
"도입하면 끝"이라며 측정하지 않음— 절감률은 워크로드(Workload)에 따라 다름. 자신의 로그로 before/after를 측정하기 전까지는 효과를 알 수 없음.

판단 플로우 — 당신은 무엇을 도입해야 하는가

병목(Bottleneck)이 발생하는 층에서 역으로 찾아갑니다.

→ 우선 git diff / grep / 로그에서 컨텍스트(Context)가 폭발하고 있다면 rtk (가장 쉽고 효과가 큼) -

• 거대한 코드베이스를 반복해서 다시 읽고 있다면 → lean-ctx (재읽기 캐시 효과가 극적임) -
• 장시간 세션에서 대화 기록이 무겁거나 / API 비용이 높다면 → headroom (대화 층을 압축하며, 가역적이라 안전함) -
• 삭제한 원본 데이터를 감사하거나 완전히 복구해야 한다면 (팀/규제) → h5i (git provenance)

그리고 계층화의 황금 패턴은:

rtk (입구에서 셸 출력을 줄임) + headroom (세션 전체를 줄임)

먼저 이 두 가지를 쌓는 것이 최소한의 노력으로 최대 효과를 내는 시작점입니다.

관련 도구 비교표 (보존용)

※ 모두 2026년 6월 기준 공개 벤치마크 / 공식 README 유래. 자신의 환경에서 재측정하는 것을 전제로 함.

실전 체크리스트

도입 전에 이것만 확인하면 사고를 방지할 수 있습니다.

• 자신의 토큰 낭비가 어느 층인지 특정했는가 (diff? 재읽기? 대화 기록?) -
• 해당 층에 대응하는 도구를 하나 선택했는가 (처음부터 전부 도입하지 말 것) -
• 압축이 가역적인지 확인했는가 (에러 로그를 뭉개버리는 설계인지) -
• 소량 출력에는 압축을 적용하지 않도록 임계값을 설정했는가 -
• 도입 후, before/after를 자신의 로그로 측정했는가 -
• KV 캐시를 망가뜨리지 않았는지 (프리픽스 안정성) 확인했는가 -
• 효과가 나타나면 rtk + headroom의 계층화를 검토했는가

요약

• Claude Code의 토큰 절감 도구 4종 (rtk / lean-ctx / headroom / h5i)은 경쟁 관계가 아니라 층이 다르므로, 계층화하여 사용한다. -
• "최대 99% 절감"이라는 말이 4번 나오는 이유는 절감하는 층이 다르기 때문이다. 같은 선상에서 비교해서는 안 된다. -
• 선택 방법은 "가장 많이 줄이는 도구 찾기"가 아니라 "자신의 병목 층에서 역으로 찾기"이다. -
• 고민된다면 rtk (셸 출력) + headroom (대화 컨텍스트) 조합부터 시작하라. 가역성 (CCR / git 저장)을 통해 과도한 압축 사고를 방지한다. -
• 절감률은 워크로드에 따라 다르다. 반드시 자신의 로그로 before/after를 측정할 것.

토큰 절감은 "절약"인 동시에 "컨텍스트 저하를 방지하여 정밀도를 유지하는" 전략이기도 합니다. 지도를 들고, 자신의 층부터 차근차근 쌓아 나가시길 바랍니다.

Discussion