본문으로 건너뛰기
블로그로 돌아가기
[TUTORIAL]

2026년 Claude Code 토큰 절감법: Caveman 스킬로 출력 65% 줄이는 방법

8분 읽기1 views

2026년 Claude Code 토큰 절감법: Caveman 스킬로 출력 65% 줄이는 방법

Claude Code나 Codex 같은 AI 코딩 에이전트를 매일 쓰다 보면 이런 생각이 들 때가 있어요. "답변이 왜 이렇게 길지? 코드 몇 줄 물어봤는데 서론이 반이네." 이 서론과 맺음말도 전부 토큰(AI가 글을 처리하는 최소 단위이자 과금 기준)이고, 결국 비용입니다. Claude Code 토큰 절감을 고민하는 분들 사이에서 화제가 된 오픈소스 스킬이 바로 Caveman이에요. AI를 동굴인처럼 짧게 말하게 만들어서, 코드는 한 글자도 안 건드리고 출력(output, AI가 만들어내는 답변 텍스트) 토큰만 평균 65% 줄여준다는 겁니다. 이번 글에서는 이 스킬이 실제로 뭘 하는지, 벤치마크 숫자가 진짜인지, 그리고 제작자가 스스로 밝힌 "언제는 오히려 손해"라는 정직한 트레이드오프까지 하나씩 짚어볼게요.

Caveman이란 무엇인가

Caveman은 개발자 Julius Brussee가 만든 오픈소스 스킬입니다. GitHub 저장소는 2026년 4월 4일에 생성됐는데, 2026년 7월 4일 기준 스타 8만 3,570개, 포크 4,661개를 기록하고 있어요. 3개월 만에 이 정도 반응을 얻은 셈이죠. 라이선스는 MIT, 언어는 JavaScript고, 최신 버전은 2026년 7월 3일에 나온 v1.9.1입니다.

이름 그대로 콘셉트가 재미있어요. "동굴인처럼 말하게" 한다는 뜻인데, 시작은 Reddit의 한 게시물이었다고 해요. 사용자 flatty가 "Claude한테 동굴인 말투로 물어봐도 정답은 똑같이 나온다"는 걸 발견해서 화제가 됐고, 여기서 아이디어가 출발했습니다.

지원 범위도 넓어요. Claude Code, Codex, Gemini CLI, Cursor, Windsurf, Cline, GitHub Copilot 등 30개 이상의 AI 코딩 에이전트에서 쓸 수 있고, 설치는 터미널에서 명령어 한 줄이면 끝나요.

어떻게 토큰을 줄이나 — 걷어내는 것과 지키는 것

Caveman의 정체는 화려한 알고리즘이 아니라 시스템 프롬프트(모델에게 미리 넣어주는 행동 지침) 스킬이에요. 모델한테 "더 짧게 답해"라고 지시하는 게 메커니즘의 전부입니다. 그래서 입력(input, 사용자가 보내는 질문·파일·컨텍스트) 토큰이나 모델의 내부 추론 과정에는 손을 대지 않아요.

걷어내는 건 이런 것들이에요.

  • "좋은 질문이네요!" 같은 인사말
  • 사용자가 이미 말한 문제를 다시 요약해서 반복하는 문장
  • "추가로 궁금한 점 있으시면 말씀해 주세요" 식의 맺음말
  • 불필요한 관사와 수식어

반대로 코드, 터미널 명령어, 에러 메시지는 한 글자도 안 바꿉니다. 압축 대상은 어디까지나 사람이 읽는 설명문 부분이에요.

작동 방식도 에이전트마다 조금씩 달라요. Claude Code에서는 세션이 시작될 때 훅(hook, 특정 시점에 자동으로 실행되는 스크립트)이 작은 표시 파일을 만들어서 별도 명령 없이 첫 메시지부터 동굴인 말투가 적용돼요. Codex와 Gemini는 기본값으로 켜져 있고, 나머지 에이전트는 세션마다 /caveman 명령을 한 번 입력하면 됩니다.

Caveman이란?: Claude Code·Codex 등 AI 코딩 에이전트가 인사말·군더더기·문제 재진술을 빼고 짧게 답하도록 만드는 오픈소스 시스템 프롬프트 스킬이다. 코드·명령어·에러는 그대로 두고 설명 텍스트만 압축해 출력 토큰을 평균 65% 줄인다.

벤치마크로 확인한 출력 토큰 65% 절감

말로만 하는 주장인지 궁금해서 공식 저장소에 커밋된 벤치마크를 확인해봤어요. Claude API로 10개 프롬프트를 실측한 결과인데, 표로 정리하면 이렇습니다.

작업일반 응답 (토큰)Caveman 응답 (토큰)절감률
React 리렌더 버그 설명1,18015987%
인증 미들웨어 토큰 만료 수정70412183%
PostgreSQL 커넥션 풀 설정2,34738084%
git rebase vs merge 설명70229258%
콜백 → async/await 리팩터38730122%
아키텍처: 마이크로서비스 vs 모놀리스44631030%
PR 보안 리뷰67839841%
Docker 멀티스테이지 빌드1,04229072%
PostgreSQL 레이스 컨디션 디버그1,20023281%
React 에러 바운더리 구현3,45445687%
평균1,21429465%

절감 폭은 작업 유형에 따라 22%에서 87%까지 넓게 분포하는데, 평균을 내면 65%가 나와요. 중요한 건 기술적 정확도가 100% 유지됐다는 점입니다. 즉 답이 틀려서 짧아진 게 아니라, 같은 정답을 더 적은 글자로 전달했다는 뜻이에요.

정직한 숫자 — 언제는 오히려 손해인가

여기서부터가 이 스킬을 소개하는 진짜 이유예요. 제작자가 HONEST-NUMBERS.md라는 문서를 따로 만들어서 마케팅 없이 트레이드오프를 직접 밝혀놨거든요.

핵심은 이거예요. 스킬 자체가 매 턴마다 약 1,000~1,500 토큰의 입력 비용을 추가로 먹습니다. SKILL.md라는 규칙 파일(약 5KB 분량)이 매번 모델의 컨텍스트에 주입되기 때문이에요. 그리고 입력 토큰 절감은 정확히 0%입니다. Caveman은 출력 스타일만 바꾸는 도구지, 입력을 압축하는 도구가 아니거든요.

그래서 다음 경우엔 오히려 순손해가 날 수 있어요.

  1. 짧은 코딩 질문: 원래 답이 150 토큰 정도로 짧으면, 아껴봐야 70~100토큰인데 스킬이 추가하는 1,000토큰+ 오버헤드를 못 따라잡아요. 실제로 이슈 #145에서 사용자가 이 상황을 직접 실측 보고했습니다.
  2. 요청 단위로 과금하는 에이전트: GitHub Copilot처럼 "토큰 수"가 아니라 "요청 횟수"로 과금하는 도구는, 답이 짧아져도 크레딧 소모량이 그대로예요(이슈 #506).
  3. 세션 전체로 보면: 입력 토큰(프롬프트·파일·주입된 규칙 전체)이 출력보다 훨씬 크기 때문에, 독립 측정 기준으로 output이 많은 작업에서도 세션 총 절감은 대략 14~21% 수준이고, 짧은 대화 위주 세션에서는 0% 미만(즉 손해)으로 떨어질 수 있어요.

제작자가 제시하는 경험칙은 명확해요. 일반 응답이 1,500~2,000 output 토큰보다 길어지는 작업이면 이득, 그보다 짧거나 요청 단위 과금이면 손해라는 겁니다. 다만 어느 쪽이든 답을 읽는 시간은 확실히 줄어드니, 그건 공짜로 따라오는 이득이라고 봐도 될 것 같아요. 참고로 Caveman은 텔레메트리나 별도 계정, 백엔드 서버가 없어서 설치 후 네트워크 호출이 0건이라는 점도 확인됐어요.

짧게 답하면 오히려 더 정확하다는 반전 논문

토큰 절감 이야기를 하다가 뜬금없어 보일 수 있는데, 이 스킬을 흥미롭게 만드는 또 다른 근거가 있어요. 2026년 3월 arXiv에 올라온 논문 "Brevity Constraints Reverse Performance Hierarchies in Language Models"입니다.

이 논문은 파라미터 수 5억 개부터 4,050억 개까지 31개 모델을 대상으로, 1,485개 문제와 5개 데이터셋으로 평가를 진행했어요. 결과가 흥미로운데, 벤치마크 문제의 7.7%에서 더 큰 모델이 더 작은 모델보다 오히려 28.4%포인트 낮은 정확도를 보였어요. 파라미터가 10배에서 100배나 많은데도 말이죠. 원인으로 지목된 건 모델 규모가 커질수록 자발적으로 더 장황해지는 경향(scale-dependent verbosity)이었어요. 설명을 길게 늘어놓다가 오히려 논리가 새는 셈이죠.

반대로 답변 길이를 짧게 제약하면 정확도가 최대 26%포인트까지 올라갔고, 큰 모델과 작은 모델 사이의 성능 격차도 최대 3분의 2가 줄어들었어요. 수학·과학 벤치마크 일부에서는 아예 성능 순위가 뒤집혀서, 큰 모델이 7.7~15.9%포인트 우위로 돌아서기도 했습니다.

이 연구가 말하는 건 "모델이 원래 못 한다"는 근본적 한계가 아니라, 프롬프트 설계로 교정 가능한 문제라는 점이에요. 즉 짧게 답하게 하는 건 단순히 비용을 아끼는 트릭이 아니라, 경우에 따라 답을 더 정확하게 만드는 방법이기도 하다는 뜻입니다.

내 워크로드에 쓸까 판단법

지금까지 나온 숫자를 정리하면 이렇게 요약할 수 있어요.

  • 출력 토큰은 평균 65% 준다 (22~87% 범위)
  • 입력 토큰은 안 줄고, 스킬 자체가 턴당 1,000~1,500 토큰을 더 쓴다
  • 세션 전체로 보면 총 절감은 대략 14~21% 선
  • 답변이 1,500~2,000 output 토큰보다 긴 작업이면 이득이 확실하다
  • 짧은 질답이나 요청 단위 과금 도구에서는 손해가 날 수 있다

그러니 판단 기준은 명확해요. 긴 설명, 코드 리뷰, 아키텍처 문서, 디버깅 리포트처럼 답이 원래 긴 작업이 많다면 Caveman을 써볼 가치가 있어요. 반대로 간단한 문법 질문 위주로 쓰거나, Copilot처럼 요청 단위 과금 도구를 쓰고 있다면 큰 효과를 기대하기 어렵습니다.

여기서 QJC가 강조하고 싶은 건 하나예요. "이 스킬이 65% 절감된대"라는 마케팅 문구를 그대로 믿기보다, 내 실제 작업 패턴으로 직접 A/B 테스트를 해보는 게 정확합니다. 다행히 Caveman은 /caveman-stats 명령으로 실제 절감량과 예상 절약 금액을 상태줄에 보여주기 때문에, 켜고 끄면서 며칠만 써보면 내 워크로드에서 이득인지 손해인지 스스로 확인할 수 있어요.

마무리

Caveman은 코드는 그대로 두고 사람이 읽는 설명문만 짧게 만들어서, Claude Code를 비롯한 30개 이상의 AI 코딩 에이전트에서 출력 토큰을 평균 65% 줄여주는 오픈소스 스킬입니다. 다만 제작자 스스로 밝혔듯 입력 토큰은 그대로고 스킬 자체의 오버헤드도 있어서, 짧은 질문 위주 작업이나 요청 단위 과금 도구에서는 오히려 손해가 날 수 있다는 점이 중요한 포인트예요. 답이 원래 길게 나오는 작업이 많다면 시도해볼 만하고, 짧게 답하면 정확도까지 오른다는 2026년 연구 결과도 함께 참고하면 좋을 것 같습니다. 무엇보다 숫자를 믿기 전에 내 워크로드로 직접 재보는 게 가장 정확한 판단법입니다.

참고자료