AI 코딩 에이전트의 토큰 절약 — 뇌가 아니라 입을 줄인다

AI 코딩 에이전트에게 "이 React 컴포넌트가 왜 리렌더되지?"라고 물으면 답을 한다. 그런데 답이 오기 전에 "물론이죠! 기꺼이 도와드리겠습니다. 말씀하신 문제는 아마도…"가 먼저 깔린다. 정작 쓸모 있는 문장은 마지막 한 줄인데, 그 한 줄까지 가는 길이 문단 세 개다. 매 응답이 그런 식이면 토큰(token, 모델이 글을 처리·과금하는 최소 단위 — 대략 단어 한 조각)이 쌓인다.

오픈소스 caveman은 이 군더더기만 걷어 내는 도구다. 같은 질문에 대한 정상 응답이 69토큰이라면 caveman을 켠 응답은 19토큰이다. 답의 내용은 같다. 10개 프롬프트로 잰 출력 토큰 평균 65% 감축(범위 22~87%)이라는 실측 숫자가 저장소에 커밋돼 있다. 흥미로운 건 방식이다. caveman은 모델이 아는 것을 줄이지 않는다. 말하는 것만 줄인다.

무엇을 줄이는지부터 정확히 해 두자. caveman의 본체 스킬이 깎는 것은 모델이 뱉는 출력이다. 입력이 아니다. 그리고 이 도구는 어떤 파일도 압축하지 않는다 — 디스크에 놓인 문서를 고쳐 쓰는 게 아니라, `SKILL.md`에 적힌 규칙문 한 뭉치가 시스템 프롬프트에 얹혀 "이렇게 짧게 말하라"고 모델의 말버릇을 바꿀 뿐이다. 손대는 자리가 오직 응답 문장이라는 것 — 이 한계가 뒤에서 손익 계산을 뒤집는 열쇠가 되니 기억해 두자. (같은 저장소에 입력을 깎는 별도 도구들이 따로 있는데, 그건 이 시리즈의 세 번째 글에서 다룬다.)

브레인은 그대로, 마우스만 작아진다

caveman의 한 줄 슬로건이 "brain big, mouth small"이다. 모델의 지식과 추론은 손대지 않고, 그것을 문장으로 뱉는 표현층에서만 압축한다는 뜻이다. 이 구분이 이 도구의 전부이자 핵심이다.

다이어그램 설명. AI가 답을 만드는 과정을 세 칸으로 나눈 그림이다. "모델이 아는 것"은 리렌더 원인을 짚어 내는 지식과 추론 — caveman은 여기를 전혀 건드리지 않는다. 압축은 오직 "표현층", 즉 그 지식을 사람이 읽을 문장으로 옮기는 자리에서만 일어난다. 그 결과 "출력"이 평균 65% 짧아진다. 핵심은 답의 정확도가 아니라 분량만 줄인다는 점이다. 흔히 "토큰을 아낀다"고 하면 모델을 더 작거나 덜 똑똑하게 만드는 걸 떠올리기 쉬운데, caveman은 정반대다 — 뇌는 그대로 두고 입만 다물린다.

무엇을 버리고 무엇을 지키나

그럼 표현층에서 정확히 무엇을 잘라 낼까. caveman의 규칙(SKILL.md)은 버릴 것과 지킬 것을 못 박아 둔다. 버리는 쪽은 뜻을 지니고 있지 않은 껍데기다.

▲ 버리는 것 — 정보량 0의 표현

다이어그램 설명. caveman이 응답에서 걷어 내는 네 부류다. "인사말"은 "물론이죠, 기꺼이…" 같은 예의 표현, "관사"는 영어의 a·an·the, "filler"는 just·really·basically처럼 뜻 없이 문장을 늘리는 군말, "hedging(헤징)"은 "아마도", "제 생각엔 이렇게 권합니다" 같이 단정을 피하는 완충어다. 네 부류의 공통점은 지우고 읽어도 기술적 의미가 하나도 사라지지 않는다는 것 — 그래서 안전하게 버린다.

반대로 지키는 쪽은 글자 하나만 틀려도 답이 망가지는 기술적 substance(실질 — 코드·명령·에러·용어)다. 여기는 100% 원문 보존이다.

▲ 지키는 것 — 압축 금지 구역

다이어그램 설명. caveman이 절대 손대지 않는 네 부류다. "코드 블록"과 "CLI 명령(터미널에 그대로 붙여 넣는 명령어)"은 한 글자만 바뀌어도 실행이 깨지므로 byte-for-byte, 즉 바이트 단위로 똑같이 보존한다. "에러 문자열"도 원문 그대로 인용해야 검색·진단이 되고, "기술 용어와 API 이름"은 짧게 줄이면 다른 뜻이 돼 버린다. 규칙에는 재미있는 디테일이 하나 있다. cfg·impl·req 같은 임의 약어를 새로 만들지 말라는 것이다. 토크나이저(tokenizer, 글을 토큰으로 쪼개는 부품)가 cfg를 config와 똑같은 조각 수로 쪼개서 토큰은 하나도 안 아끼면서 읽는 사람만 해독하게 만들기 때문이다. 그래서 버릴 건 과감히 버리되, 지킬 건 원형 그대로 둔다.

같은 답, 3분의 1 길이

규칙을 실제 응답에 대면 이렇게 된다. "React 컴포넌트가 왜 리렌더되나"라는 같은 질문, 같은 결론인데 길이만 다르다.

정상 응답 (69토큰)

당신의 React 컴포넌트가 리렌더되는 이유는 아마도 매 렌더 사이클마다 새로운 객체 참조를 만들고 있기 때문일 것입니다. 인라인 객체를 prop으로 넘기면 React의 얕은 비교가 매번 다른 객체로 인식해 리렌더를 유발합니다. useMemo로 객체를 메모이제이션하기를 권합니다.

caveman 응답 (19토큰)

New object ref each render. Inline object prop = new ref = re-render. Wrap in useMemo.

예시 설명. 두 응답이 담은 결론은 동일하다 — 매 렌더마다 새 객체 참조가 생기고, 그게 리렌더를 부르니 useMemo로 감싸라. 정상 응답은 "아마도", "권합니다" 같은 헤징과 관사·연결어로 문장을 채웠고, caveman 응답은 그걸 다 걷어 내 조각(fragment, 완전한 문장이 아닌 명사구·짧은 토막) 세 개로 끝냈다. 그런데 진짜 알맹이인 useMemo라는 API 이름은 두 응답 모두에 글자 그대로 남아 있다. 버릴 걸 버려도 지킬 게 지켜지는 이유가 이 한 예에 다 들어 있다.

왜 짧은 게 유용한가. 비용은 오히려 부차적이다. 사람이 읽는 속도가 빨라지고, 알맹이가 군말에 묻히지 않는다. 덤으로 2026년 3월 논문 한 편(Brevity Constraints Reverse Performance Hierarchies in Language Models)은 31개 모델을 시험해, 큰 모델에게 간결한 답을 강제했더니 일부 벤치마크에서 정확도가 약 26점 올라갔다고 보고했다. 짧게 말하라는 제약이 때로는 더 정확한 답을 끌어낸다는 이야기다.

정직한 한계 — 오직 '출력'만 줄인다

여기서 멈추면 광고가 된다. caveman 문서(HONEST-NUMBERS.md)가 스스로 밝히는 한계가 이 글에서 가장 중요한 대목이다. caveman은 시스템 프롬프트에 얹히는 규칙일 뿐이라, 모델이 더 짧게 쓰게 만드는 게 전부다. 그 외에는 아무것도 압축하지 않는다.

다이어그램 설명. AI 한 번의 응답이 소비하는 토큰을 네 갈래로 쪼갠 그림이다. caveman이 실제로 깎는 건 "출력 토큰" 하나뿐이다. 내가 보낸 "입력 토큰(프롬프트·컨텍스트·파일)"과 "추론 토큰(모델이 답을 내기 전 속으로 굴리는 사고량)"은 조금도 줄지 않는다. 게다가 caveman 규칙 자체가 매 턴 "입력 +1~1.5k"만큼 비용을 더한다 — 규칙문(약 5KB)이 매번 컨텍스트에 실리기 때문이다. 놓치기 쉬운 함정이 여기 있다. 에이전트 코딩에서는 입력 토큰이 출력 토큰을 압도하므로, 출력만 65% 줄여도 세션 전체 절감은 14~21% 수준으로 훨씬 작아진다.

그래서 정직한 손익 계산이 필요하다. 정상 응답이 원래 1.5~2k 토큰을 넘는 장황한 워크로드(설명·아키텍처 토론·코드 리뷰·디버깅 설명)라면 출력 절감이 규칙 비용을 넘어 이득이다. 반대로 평소 응답이 150토큰짜리 짧은 코딩 Q&A라면, 아껴 봐야 70~100토큰인데 규칙이 매 턴 1k 넘게 더하니 오히려 손해다. 요청 단위로 과금하는 도구(예: GitHub Copilot)라면 답이 짧아져도 요청 수는 그대로라 비용이 안 준다. caveman 문서는 이 경우들을 이슈 번호까지 달아 "그럴 땐 끄라"고 적어 둔다 — 도구가 작동하길 바라는 마음이 도구를 작동시키지는 않는다면서.

그러면 정작 덩치가 큰 입력 쪽은 누가 줄이나? 이 계산이 알려 주는 게 바로 그 질문이다. 출력만 깎아서는 천장이 낮으니, 매 세션 컨텍스트에 실려 나가는 텍스트 자체를 손봐야 한다 — 에이전트가 읽는 메모리 파일(`CLAUDE.md`, 할 일 목록, 선호 설정)과 요청마다 프롬프트에 얹히는 MCP 도구 설명 같은 것들이다. caveman 저장소에는 정확히 그 일을 하는 도구가 따로 들어 있고(`caveman-compress`, `caveman-shrink`), 거기서는 "산문은 줄이되 코드는 한 byte도 건드리면 안 된다"는 전혀 다른 난제가 튀어나온다. 이 시리즈 세 번째 글의 주제가 그것이다.

정리 — 줄일 것은 지식이 아니라 표현이다

caveman이 주는 교훈은 도구 하나보다 크다. AI의 토큰을 아끼겠다고 할 때 우리는 흔히 모델을 줄이거나 답을 성기게 만드는 쪽을 떠올린다. caveman은 반대 자리를 짚는다 — 알맹이는 100% 지키고 껍데기만 버린다. 코드·명령·에러·용어는 글자 그대로 두고, 인사말·관사·filler·헤징만 걷어 낸다. 그리고 그 절감이 출력에만 걸린다는 한계까지 스스로 밝혀, 언제 쓰고 언제 끌지를 사용자가 판단하게 한다.

개인 작업에 대입하면 질문이 하나 생긴다. 내가 AI에게 받는 답에서 진짜 알맹이는 몇 퍼센트이고, 나머지는 매번 값을 치르며 흘려보내는 껍데기가 아닌가. 뇌를 줄일지 입을 줄일지 — 그 구분부터 하는 게 토큰 절약의 출발점이다.

---

참고한 공개 자료:

• https://github.com/JuliusBrussee/caveman
• https://github.com/JuliusBrussee/caveman/blob/main/docs/HONEST-NUMBERS.md
• https://github.com/JuliusBrussee/caveman/blob/main/skills/caveman/SKILL.md
• https://arxiv.org/abs/2604.00025 — Brevity Constraints Reverse Performance Hierarchies in Language Models

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.