토큰 90% 절약이라는데? / 도구 설치 전에 Effort부터

Caveman·Ponytail·RTK·Headroom, 줄어든 토큰과 실제 비용은 왜 다를까?

클로드 코드를 쓰다 보면 이런 문구를 그냥 지나치기 어렵습니다.

“토큰 65% 절약.”
“최대 90% 압축.”
“설치만 하면 사용량을 훨씬 오래 쓸 수 있습니다.”

5시간 제한과 주간 사용량을 신경 쓰는 사람에게는 꽤 매력적인 이야기입니다. 저도 사용량 게이지를 보다가 작업을 나눠야 했던 경험이 있어서, 이런 도구가 나오면 일단 궁금해집니다.

그런데 잠깐 생각해볼 부분이 있습니다.

무엇을 90% 줄였다는 것일까요?

터미널에 출력된 로그인지, 마지막 답변의 길이인지, 전체 입력 토큰인지, 아니면 실제 작업을 끝낼 때까지 발생한 비용인지에 따라 의미가 완전히 달라집니다.

최근 소개된 클로드 코드 토큰 절약 도구 비교에서도 이 차이가 핵심이었습니다.

도구가 표시하는 절약률은 인상적인데, 실제 작업 비용은 거의 줄지 않거나 오히려 증가한 사례가 있었다는 것입니다.

그래서 이번에는 ‘무슨 프로그램을 설치할까’보다 **‘어디에서 사용량이 발생하고, 무엇부터 줄일까’**를 중심으로 정리해봤습니다.

확인 범위: 2026년 9월 27일 기준 공식 문서와 각 프로젝트 설명을 확인했습니다. 영상 원문과 ‘108회 실험’의 원시 로그는 독립적으로 확인하지 못했으므로, 아래 실험 수치는 제공된 영상 요약의 보고값으로 구분합니다. 직접 재현한 벤치마크는 아닙니다.

반응형

1. 먼저 바꿔볼 것은 플러그인이 아니라 Effort다

별도 도구를 설치하기 전에 가장 먼저 확인하고 싶은 설정은 추론 강도, Effort입니다.

Anthropic은 복잡한 계획과 추론에 도움이 되는 Thinking이 사용량을 소비하며, Thinking 토큰은 API에서 출력 토큰으로 과금된다고 설명합니다. 깊은 추론이 필요 없는 작업에서는 Effort를 낮춰 비용을 줄이는 방법을 안내합니다. Claude

클로드 코드 대화창에서 다음 명령으로 설정을 확인할 수 있습니다.

/effort

작고 명확한 작업을 시험할 때는 이렇게 지정할 수도 있습니다.

/effort low

다만 여기서 중요한 단서가 있습니다.

low가 모든 개발 작업의 정답은 아닙니다.

공식 문서도 low를 짧고 범위가 분명하며, 고난도 판단이 중요하지 않은 작업에 적합한 수준으로 설명합니다. 복잡한 작업에서는 더 높은 Effort가 필요할 수 있고, 같은 이름의 Effort라도 모델별 의미와 기본값이 다릅니다. Claude

제가 적용한다면 이렇게 구분하겠습니다.

작업먼저 시험할 설정

오타 수정, 명확한 변수명 변경, 문서 형식 정리	low
범위가 정해진 기능 수정, 테스트 추가	모델 기본값 또는 medium
원인이 불명확한 장애, 여러 파일에 걸친 설계 변경	기본값에서 시작해 필요하면 상향
기존 설정으로 반복해서 해결하지 못한 문제	높은 Effort로 재검토

이 표는 공식적인 작업별 보장표가 아니라, 제가 권하는 시험 순서입니다.

낮게 설정해서 한 번 실패하고, 다시 설명하고, 또 고친 뒤 결국 높은 설정으로 돌아온다면 처음부터 충분히 생각하게 한 편이 더 경제적일 수 있습니다.

추론을 적게 시키는 것과, 일을 싸게 끝내는 것은 다릅니다.

설정을 바꾼 뒤에는 현재 모델과 적용된 Effort를 확인하고, 다음에 어려운 작업을 시작할 때도 그대로 두지 않았는지 살펴보는 편이 좋겠습니다. 명령이 인식되지 않는 환경에서는 /model의 지원 옵션과 설치된 클로드 코드 버전을 확인하면 됩니다. Claude

2. 토큰이 줄었다는데 비용은 왜 그대로일까?

가장 흔한 오해는 부분 절약률을 전체 절약률로 받아들이는 것입니다.

예를 들어 어떤 도구가 클로드의 설명을 짧게 만들어준다고 해보겠습니다.

기존에는 변경 이유를 열 문장으로 설명했는데, 이제는 세 문장으로 끝냅니다. 화면은 확실히 간결해집니다.

하지만 그 전에 수행한 파일 탐색, 코드 생성, 도구 호출, 추론과 대화 맥락 처리는 그대로일 수 있습니다. Effort 역시 화면에 보이는 설명뿐 아니라 Thinking과 도구 호출을 포함한 출력에 영향을 주는 별도 설정입니다. Claude Platform

숫자로 보면 더 쉽습니다.

가상의 예시로, 전체 작업 비용 중 도구가 줄일 수 있는 설명문이 5%를 차지한다고 가정해보겠습니다.

그 설명문을 65% 줄이고 나머지 조건이 모두 같다면, 전체 비용 감소는 다음과 같습니다.

5% × 65% = 3.25%

설명문을 크게 줄였다는 주장도 맞고, 전체 비용은 조금만 줄었다는 결과도 맞을 수 있습니다.

서로 모순이 아닙니다.

줄인 대상과 비교 기준이 달랐던 것입니다.

그래서 ‘90% 절약’이라는 숫자를 보면 이제는 뒤에 붙는 말을 먼저 보려고 합니다.

90% 적은 명령 출력인지, 90% 적은 전체 토큰인지, 90% 낮은 실제 비용인지 말입니다.

3. 네 가지 도구는 사실 같은 일을 하지 않는다

Caveman, Ponytail, RTK, Headroom은 모두 토큰 절약 도구로 묶여 소개되지만, 주로 손대는 부분이 다릅니다.

Caveman: 설명을 간결하게 만드는 접근

Caveman은 불필요하게 긴 표현을 줄이고 짧게 답하도록 유도하는 스킬로 알려졌습니다. 현재 저장소에는 입력을 다루는 프록시 기능도 추가돼 있으므로, 스킬만 시험한 결과와 프록시까지 사용한 결과를 구분해야 합니다. GitHub

설명이 너무 길어서 읽기 불편한 사용자에게는 비용 외의 가치도 있을 수 있습니다.

다만 최종 답변이 짧아졌다는 사실만으로, 그 답변을 만들기까지의 전체 작업량까지 같은 비율로 줄었다고 볼 수는 없습니다.

Ponytail: 불필요한 구현을 줄이는 접근

Ponytail은 이미 있는 코드와 표준 기능을 재사용하고, 필요하지 않은 추상화나 과도한 구현을 피하도록 유도합니다.

프로젝트 설명도 목표가 무조건 가장 적은 토큰을 쓰는 것이 아니라 필요한 코드만 작성하는 것이라고 밝힙니다. 입력 검증, 오류 처리, 보안과 접근성을 줄여서는 안 된다는 원칙도 포함합니다. GitHub

이 방향은 꽤 공감됩니다.

간단한 날짜 입력창 하나가 필요했는데 새 라이브러리와 공통 컴포넌트 체계까지 만들어버리면, 생성 비용보다 이후 관리 비용이 더 부담스러울 수 있으니까요.

다만 구현을 줄이기 위해 여러 대안을 더 검토한다면, 코드량은 줄어도 추론량은 늘어날 수 있습니다. Ponytail 문서 자체도 모델에 따라 비용 효과가 반대로 나타날 수 있음을 설명합니다. GitHub

RTK: 모델에게 전달하는 명령 출력을 줄이는 접근

RTK는 셸 명령의 출력을 필터링하고 압축합니다. 테스트 성공 항목을 개수로 묶거나, Git 출력과 검색 결과를 간결하게 만드는 방식입니다.

현재 README의 핵심 표현도 에이전트가 읽는 Bash 출력을 최대 90% 줄인다는 것입니다. 전체 작업 비용을 언제나 90% 줄인다는 뜻은 아닙니다. GitHub

로그가 길고 반복적인 작업에서는 검토할 가치가 있습니다.

반대로 비용 대부분이 복잡한 추론이나 코드 생성에서 발생한다면, 명령 출력만 줄여서는 전체 변화가 작을 수 있습니다.

Headroom: 모델에 전달하기 전 컨텍스트를 정리하는 접근

Headroom은 도구 결과, 로그, 파일, 대화 이력 등을 모델에 전달하기 전에 압축하는 계층입니다. 현재 구현은 원본을 필요할 때 다시 조회하는 기능과 캐시를 보존하기 위한 처리도 설명하고 있습니다. GitHub

이런 프록시형 도구는 압축률뿐 아니라 정보 보존, 캐시 유지, 추가 지연과 재조회 비용까지 함께 봐야 합니다.

따라서 네 도구를 단순히 ‘누가 가장 많이 줄였나’로만 비교하기보다, 내 작업에서 무엇이 많이 소비되는지와 도구가 줄이는 대상이 맞는지부터 보는 편이 낫겠습니다.

4. 제공된 실험 요약에서는 내장 설정의 효과가 가장 컸다

영상 요약에 나온 비용 변화는 다음과 같습니다.

아래 수치는 해당 요약의 보고값이며, 제가 원시 로그로 재검증한 결과는 아닙니다.

비교 대상요약에 제시된 비용 변화

Claude Code 내장 low Effort	15% 감소
Headroom	3% 감소
Caveman	2% 감소
Ponytail	8% 증가
RTK	26% 증가

요약대로라면 별도 설치 없이 바꿀 수 있는 Effort 설정이 가장 큰 절감 효과를 보였습니다.

하지만 이 표를 다음처럼 읽으면 지나친 결론입니다.

“RTK를 설치하면 누구나 비용이 26% 오른다.”
“Headroom은 효과가 없다.”
“앞으로 모든 작업을 low로 해야 한다.”

실험 결과를 해석하려면 모델과 도구 버전, 작업 종류, 캐시 상태, 반복 횟수, 성공 기준을 함께 봐야 합니다. 특히 2~3%처럼 작은 차이는 변동 범위가 공개되지 않으면 의미 있는 효과인지 판단하기 어렵습니다.

108회라는 총실행 횟수만으로 모든 조건이 충분히 검증됐다고 볼 수도 없습니다. 여러 도구와 과제, 설정으로 나뉘었다면 개별 조건의 반복 수는 달라지기 때문입니다.

제가 이 비교에서 가져갈 메시지는 도구의 순위가 아닙니다.

추가 도구를 설치하기 전에, 이미 제공되는 설정으로 기준 결과부터 만들어보자.

외부 도구가 무조건 나쁘다는 결론보다 훨씬 실용적인 접근입니다.

5. “캐시가 90%면 더 줄일 게 없다”는 설명은 조심해야 한다

이 부분은 원래 요약에서 보완이 필요합니다.

캐시 적중률이 높다는 것은 기존 입력을 잘 재사용하고 있다는 좋은 신호입니다. 하지만 90%를 넘으면 추가 최적화가 무의미해진다는 공식 기준은 아닙니다.

캐시로 읽는 토큰도 무료는 아닙니다. Claude API는 캐시 쓰기와 읽기에 별도 가격을 적용하며, 읽기 할인율에도 모델별 차이가 있습니다. Claude Platform

간단한 가정으로 계산해보겠습니다.

전체 입력이 100만 토큰이고, 그중 90만 토큰을 캐시에서 읽는다고 합시다. 일반 입력의 단가를 1, 캐시 읽기를 0.1로 가정하면 다음과 같습니다.

새 입력 10만 × 1   = 10만 비용 단위
캐시 입력 90만 × 0.1 = 9만 비용 단위

캐시 적중률은 90%지만, 새 입력이 입력 비용의 절반 이상을 차지합니다. 여기에 출력과 추론 비용도 별도로 존재합니다.

이 예시는 특정 모델의 실제 청구액이 아니라 구조를 이해하기 위한 계산입니다.

핵심은 이것입니다.

토큰 개수의 비율과 비용의 비율은 같지 않습니다.

캐시 적중률이 높아도 필요 없는 대형 맥락을 계속 유지한다면 그 양을 줄일 여지가 있고, 출력이나 추론이 많이 발생한다면 그쪽을 조절할 여지도 있습니다.

반대로 이미 안정적으로 재사용되는 내용을 매번 다르게 바꿔버리면 캐시 이점을 해칠 수 있습니다. 공식 문서도 프롬프트의 어떤 부분이 바뀌느냐에 따라 캐시가 무효화될 수 있다고 설명합니다. Claude

그래서 캐시를 볼 때는 다음 두 질문을 함께 해야 합니다.

“얼마나 잘 재사용하고 있나?”
“그런데 재사용하는 그 내용이 전부 필요한가?”

캐시 95%도 훌륭한 수치지만, 필요 없는 내용을 아주 성실하게 재사용하는 상황일 수는 있습니다.

728x90

6. 사용량은 어디에서 확인하면 될까?

현재 공식 문서 기준으로 /usage는 구독 한도뿐 아니라 세션 토큰과 추정 비용을 확인하는 데도 사용됩니다.

다만 표시 기능은 버전에 따라 다릅니다. Prompt cache (main) 통계는 Claude Code v2.1.251 이상에서 제공되며, 메인 대화 기준으로 서브에이전트는 포함하지 않습니다. Claude

먼저 다음 두 명령을 구분해서 보겠습니다.

/usage
/context

/usage에서는 사용량과 지원되는 세션 통계를 보고, /context에서는 현재 어떤 내용이 컨텍스트를 차지하는지 살펴봅니다. Claude

여기서 비용 표시에 놀랄 필요는 없습니다.

Pro·Max 구독에 포함된 사용량으로 작업했다면, 세션의 달러 표시가 그대로 추가 청구액이라는 뜻은 아닙니다. 클로드 코드가 토큰 수와 가격표로 계산한 추정치이며, API의 실제 청구 내역은 Console에서 확인해야 합니다. Claude

그래서 정액제 사용자라면 두 가지를 따로 보려고 합니다.

하나는 같은 일을 얼마나 적은 토큰과 재시도로 끝냈는지입니다.

다른 하나는 실제 구독 한도 안에서 작업을 얼마나 이어갈 수 있었는지입니다.

추정 API 비용이 15% 줄었다고 해서 제 주간 게이지도 정확히 15% 덜 줄어든다고 단정하지는 않는 편이 좋겠습니다.

7. 외부 도구 없이도 먼저 정리할 부분이 있다

제가 바로 해볼 만하다고 생각하는 것은 거창한 설치가 아니라, 현재 작업 방식에서 불필요한 부분을 줄이는 것입니다.

관계없는 일을 같은 대화에 계속 넣지 않기

로그인 오류를 해결한 세션에서 갑자기 다른 사이트 디자인과 문서 작업까지 이어가면, 다음 작업과 관계없는 맥락이 계속 남습니다.

Anthropic도 관련 없는 작업 사이에는 /clear를, 같은 작업을 이어가면서 긴 이력을 정리할 때는 /compact를 활용하도록 안내합니다. Claude

단, 같은 기능을 계속 개발하는데 매번 지워버릴 필요는 없습니다. 필요한 맥락까지 잃으면 다시 설명하고 읽어오는 일이 생깁니다.

청소가 목적이지, 매번 이사하는 것이 목적은 아닙니다.

조사 범위를 먼저 정하기

“프로젝트 전체에서 문제를 찾아줘”보다, 알고 있는 오류 증상과 우선 확인할 경로를 주는 편이 낫겠습니다.

공식 모범 사례도 범위 없는 탐색 대신 조사 대상을 좁히고, 결과를 검증할 수 있는 테스트나 기준을 제공하라고 권합니다. Claude

물론 원인이 예상 범위 밖에 있다면 넓혀야 합니다. 범위를 정한다는 것은 다른 곳을 절대 보지 말라는 뜻이 아니라, 처음부터 불필요한 전체 탐색으로 시작하지 않자는 의미입니다.

짧은 답변과 부실한 검증을 구분하기

출력 절약을 위해 다음처럼 요청할 수는 있습니다.

“중복 설명은 줄이고 변경 사항과 검증 결과를 중심으로 알려줘.”

하지만 다음까지 줄이고 싶지는 않습니다.

“왜 위험한지 설명하지 마.”
“예외 처리는 빼.”
“테스트는 생략하고 완료라고 해.”

제가 아끼고 싶은 것은 반복되는 설명이지, 필요한 검증이 아닙니다.

실제로 Ponytail도 최소 구현을 강조하면서 검증·오류 처리·보안은 생략 대상이 아니라고 명시합니다. GitHub

8. 테스트한다면 한 번에 하나만 바꾸자

도구 네 개를 한꺼번에 설치하고 “어제보다 오래 쓴 것 같다”고 판단하면 무엇이 효과를 냈는지 알기 어렵습니다.

반대로 비용이 늘어도 어느 설정을 되돌려야 할지 모릅니다.

제가 권하는 비교 방식은 단순합니다.

같은 시작 코드와 같은 요청을 준비하고, 한 번에 한 가지 설정만 바꿔봅니다.

가능하면 다음 조건도 유지합니다.

항목비교할 때 맞출 조건

시작 코드	동일한 커밋·파일 상태
모델	동일한 모델과 버전
설정	Effort 또는 도구 중 한 가지만 변경
캐시	차가운 시작인지, 이미 사용 중인 세션인지 구분
완료 기준	같은 테스트와 요구사항
기록	토큰·추정 비용·시간·재시도·사람의 수정량

같은 작업은 반복해보고, 잘된 한 번만 고르기보다 중간값과 편차를 함께 보는 편이 낫겠습니다. 어려운 과제를 포기해서 비용이 낮아진 실행은 성공한 절약 사례로 세면 안 됩니다.

시험 순서는 이렇게 잡아볼 수 있습니다.

기본 상태 → 작은 작업에서 low Effort → 필요한 외부 도구 하나 → 같은 기준으로 비교.

처음부터 108번을 재현할 필요는 없습니다. 제 업무에 자주 등장하는 작은 과제 몇 개로도 도입 여부를 판단할 출발점은 만들 수 있습니다.

다만 한두 번의 개인 테스트로 ‘모든 사용자에게 30% 절약’ 같은 결론을 내리지는 않는 편이 좋겠습니다.

9. 바로 써볼 수 있는 ‘과잉 작업 방지’ 요청

토큰을 아끼겠다고 문법을 모두 없애거나, 중요한 요구사항까지 줄일 필요는 없습니다.

저라면 다음 정도로 요청하겠습니다.

이번 목표는 [수정할 기능 또는 오류]를 해결하는 것이다.

우선 확인할 범위:
[관련 파일 또는 디렉터리]

작업 원칙:
- 필요한 코드를 먼저 확인하고 최소한의 변경으로 해결한다.
- 범위 밖 문제를 발견하면 영향만 보고하고 임의로 확장하지 않는다.
- 입력 검증, 예외 처리, 보안 검사를 생략하지 않는다.
- 기존 테스트를 통과시키기 위해 테스트 기준을 낮추지 않는다.
- 같은 접근으로 실패가 반복되면 수정부터 계속하지 말고 원인을 정리한다.
- 완료 조건을 충족하면 새 기능을 추가하지 않는다.

결과 보고:
- 무엇을 바꿨는지
- 어떤 테스트를 실제 실행했는지
- 남은 위험이나 미검증 항목

중복 설명은 줄이되, 판단에 필요한 근거는 남겨줘.

이 프롬프트 역시 특정 절감률을 보장하는 비법은 아닙니다.

다만 무엇을 해야 하고 어디에서 멈춰야 하는지를 분명히 해, 필요 없는 작업을 줄이려는 요청입니다.

외부 프로그램 하나를 더 설치하는 것보다 먼저 시도하기도 쉽습니다.

10. 그렇다고 절약 도구를 전부 지울 필요는 없다

이번 비교를 보고 “결국 이런 도구는 다 쓸모없구나”라고 결론 내리고 싶지는 않습니다.

긴 로그가 문제라면 출력 정리 도구가 도움이 될 수 있습니다. 과도한 구현이 반복된다면 코드 재사용을 유도하는 스킬이 도움이 될 수 있습니다. 대용량 도구 응답이 자주 들어온다면 컨텍스트 압축을 검토할 이유도 있습니다.

다만 문제를 먼저 찾고, 거기에 맞는 도구를 고르는 순서여야 합니다.

또 비용 외의 효과도 볼 수 있습니다.

설명이 간결해져 검토가 쉬워졌는지, 변경 범위가 작아졌는지, 필요한 로그를 더 빨리 찾을 수 있는지도 중요합니다.

반대로 프록시 설정과 업데이트 때문에 관리할 일이 늘거나, 필요한 내용을 다시 찾아오느라 시간이 더 든다면 비용표에 표시되지 않는 부담이 생깁니다.

특히 프롬프트와 도구 결과를 중간에서 처리하는 프로그램이라면, 설치 전에 코드와 권한, 로그 저장 위치, 원래 설정으로 되돌리는 방법도 확인하려 합니다.

토큰을 아끼려고 연결한 도구가 또 하나의 운영 대상이 된다는 점은 잊지 않으려고 합니다.

결론: 절약률보다 먼저 볼 것은 ‘완료한 작업’이다

이번 내용에서 제가 가져갈 결론은 “외부 도구는 실패했고 low만 정답이다”가 아닙니다.

조금 더 현실적으로는 이렇습니다.

클로드 코드 토큰 절약은 플러그인 쇼핑보다, 비용이 발생하는 지점을 확인하는 데서 시작해야 한다.

최종 설명이 길다면 표현을 줄일 수 있습니다.

불필요한 맥락이 많다면 세션과 자료를 정리할 수 있습니다.

쉬운 일에도 깊은 추론을 시키고 있다면 Effort를 낮춰볼 수 있습니다.

로그가 지나치게 길다면 해당 출력을 다루는 도구를 시험할 수 있습니다.

그리고 무엇을 바꾸든, 테스트를 통과하고 사람이 받아들일 수 있는 결과까지 포함해 비교해야 합니다.

답변이 짧아졌는데 다시 물어볼 일이 늘었다면 절약인지 애매합니다.

코드가 줄었는데 예외 처리가 사라졌다면 더더욱 아닙니다.

반대로 조금 더 사용했더라도 한 번에 정확하게 끝났다면 그쪽이 더 경제적일 수 있습니다.

줄여야 하는 것은 토큰 숫자 자체보다 불필요한 작업입니다.

저도 다음 절약 도구를 설치하기 전에 먼저 /usage와 /context, 현재 Effort부터 확인해보려고 합니다.

AI를 효율적으로 쓰기 위해 도구를 하나 더 익히는 것도 좋습니다.

그런데 가끔은 도구를 늘리는 대신, 제가 너무 많은 것을 시키고 있지는 않은지 돌아보는 편이 더 빠를 것 같습니다.

토큰은 조금 아꼈는데 설정을 공부하느라 주말을 다 썼다면, 제 시간까지 포함한 가계부는 적자일 테니까요.

---

검색 설명: Claude Code 토큰 절약 도구 Caveman·Ponytail·RTK·Headroom의 효과를 어떻게 판단해야 할까? 부분 압축률과 실제 비용의 차이, /effort low 설정, 캐시 90%의 오해와 직접 비교하는 방법을 정리했습니다.