에이전트 토큰을 줄이는 방법 (Caveman vs RTK)

토큰 소모량이 늘어나는 원인을 보통 "모델이 답변을 너무 길게 작성해서"라고 생각하기 쉽지만

실제 멀티턴 코딩 세션에서 가장 큰 토큰 청크를 차지하는 주범은 터미널 출력(Command Output)임

pytest, npm test, git diff, 빌드 및 린트 로그 같은 텍스트가 모델의 컨텍스트에 그대로 들어가면 사람이 읽기에도 버거운
양이 토큰으로 변환되고, 이 문제를 해결하기 위해 많이 사용하는 Caveman과 RTK를 비교 분석해 봄

 

---------------------------------------

 

그래서 그게 뭐야?

 

1. 압축의 방향성의 차이가 있음
두 도구는 토큰을 줄이는 위치와 대상이 완전히 다름

- Caveman: 시스템 프롬프트나 지침을 통해 모델의 답변 스타일을 제어합니다. 미사여구, 중복 설명, 정중한 표현(hedging)을
  제거하고 오직 코드와 핵심 사실만 극단적으로 짧게 답변하도록 유도함. (모델의 입을 줄임)
- RTK: 터미널 명령의 표준 출력 중 중복되는 스택 트레이스나 불필요한 진행 표시 등을
  필터링하여 에이전트에게 전달하기 전에 압축함. (터미널의 출력을 줄임)

단순화한 세션 토큰 구성비 모델로 비교하면

CLI/터미널 출력 (Input 영역):   60%
파일/코드 컨텍스트 (Input 영역): 20%
에이전트 답변 (Output 영역):    15%
사고 과정 (Reasoning):          5%

  - Caveman이 모델 답변(15%)을 65% 줄인다면: 전체 토큰은 약 9.75% 절감
  - RTK가 터미널 출력(60%)을 80% 줄인다면: 전체 토큰은 약 48% 절감

명령 실행이 빈번한 디버깅 워크플로우라면 절감 잠재력은 RTK가 훨씬 더 큼

반면 CLI 명령보다는 긴 설명, 리뷰, 문서 작업 위주의 세션이라면 Caveman이 체감상 더 효과적일 수 있음

2. Caveman 측정

Caveman은 최종 답변 길이를 확실하게 줄여주고, 실제 벤치마크 테스트에서도 안정적인 답변 압축률을 보여줌.

[최종 답변 길이 (자수)]
- JS 테스트 세션:  컨트롤 751자 ➔ Caveman 적용 시 583자
- Python 테스트 세션: 컨트롤 563자 ➔ Caveman 적용 시 310자

장점은 에이전트가 불필요하게 서론/결론을 길게 작성하는 비용을 효과적으로 억제합니다. 최종 답변 데이터만 줄이므로 원문 정보가 누락되어 발생하는 동작 오류 위험도 낮습니다.

한계: 에이전트의 '답변 스타일'만 통제할 뿐, 에이전트가 내리는 명령어 자체를 제어하지는 못합니다. 오히려 에이전트 작동 방식에 따라 자체 검증(Verification)을 위해 git status나 nl 같은 조회 명령을 추가로 계속 실행하게 만들면서 전체적인 입력 토큰이 늘어나는 오버헤드가 발생하기도 합니다.

3. RTK 측정

RTK는 터미널 출력이 클 때 진가를 발휘함

특히 대규모 빌드 로그나 거대한 테스트 프레임워크 출력이 잡히는 JS 환경에서 무겁게 캐시되지 않는 입력(Uncached Input) 토큰을 효과적으로 잡아줌

 

[JS 테스트 세션 - Uncached Input 토큰 비교]
- 컨트롤 (압축 없음):   27,729 토큰
- RTK 강제 적용 (Safe): 13,442 토큰

최근의 LLM API는 프롬프트 캐싱(Prompt Caching)을 적극 활용하기 때문에, 매 턴마다 새로 계산되어 과금되는 Uncached
Input 영역(터미널 출력물)을 압축하는 것은 비용과 Latency 측면에서 엄청난 이득을 가져다줌

* 하지만..... 오히려 늘어나는 경우도 있음

 

가벼운 작업이나 정밀한 수정이 필요한 태스크에서는 RTK 적용 시 오히려 토큰 사용량이 급증하는 현상도 발생

[Python 가벼운 파서 수정 세션]
- 컨트롤 (압축 없음):   Uncached 토큰 25,468 / 실행 명령 수 11회
- RTK 강제 적용 (Safe): Uncached 토큰 59,226 / 실행 명령 수 25회

토큰이 2배 이상 늘어난 이유는?

출력이 지나치게 압축되면 모델에게 일종의 정보 병목이 발생하는데, 정밀한 패치를 생성해야 하는 에이전트 입장에서 '정확한 라인 번호'나 '상세한 컴파일 에러 맥락' 같은 세부 데이터가 누락되어 확신이 떨어지기 때문에 재확인하기 위해 git diff, sed, rg 등 압축되지 않는 순수 명령어(Raw commands)를 연달아 호출하는 '과잉 검증(Verification Loop)' 을 함

정보 압축 ➔ 데이터 누락 ➔ 에이전트의 의심 및 추가 명령 수행 ➔ 전체 토큰 폭증

4. 기능 손실 없이 비용을 아끼는 최적의 조합

이번 벤치마크 실험 조건에서 모든 에이전트 태스크는 성공했음

-> 기능의 손상 없이 비용 효율을 극대화하기 위해서는 이 두 도구를 결합하여 기계적인 압축이 아닌 맥락별 선택적 압축을 적용해야 함

권장 최적 전략
1.  Caveman은 기본 적용
- 정확도가 저해되지 않으면서 에이전트의 답변 비용을 줄여주므로 기본 장착하기 좋음
2.  반복적이고 노이즈가 많은 출력은 RTK Safe 모드로 필터링

- pytest, npm test 등 스택 트레이스가 길게 반복되거나 진척도 바(Progress bar)가 들어간 테스트 출력은 RTK로 핵심만 압축해 전달하는 것이 안전하고 이득
3. 중요한 원문 컨텍스트는 Raw 상태 유지
      - git diff 및 git show (정확한 패치 라인 판독 필요)
      - API 응답 값 및 정밀한 DB 쿼리 결과
      - 구체적인 디버깅용 에러 로그

요약
압축 기술을 무조건 적용한다고 해서 에이전트 토큰이 비례해서 줄어들지는 않음

정보가 너무 과하게 잘려 나가면 AI 에이전트는 정보를 복구하기 위해 더 많은 도구를 마구 실행하게 됨
따라서 안전한 영역(Caveman을 통한 답변 축소 + 무거운 테스트 출력을 줄이는 RTK Safe)에서 비용을 아끼되, 코드에 직접
작용하는 정밀 정보는 원본 그대로 에이전트에게 전달하는게 가성비 있는 사용 방법같음

 

벤치/테스트 결과

dd3ok/caveman-rtk-benchmark

GitHub - dd3ok/caveman-rtk-benchmark

 

 

caveman lite와 보수적인 rtk 적용해 사용중

 

~/.config/rtk/config.toml

exclude_commands = [
  "git diff", "git show", "diff",
  "cat", "read", "sed", "nl", "head", "tail", "less",
  "curl", "wget",
  "psql", "mysql", "sqlite3", "redis-cli", "mongo", "mongosh",
  "docker logs", "docker compose logs", "kubectl logs", "journalctl",
]