토큰 90% 절감의 함정: 코딩 에이전트용 RTK를 의심해야 하는 이유
한눈에 보기
최근 GitHub 스타 6만 개를 넘기며 화제가 된 RTK는 코딩 에이전트의 터미널 출력을 압축해 토큰 비용을 "60~90%" 줄여준다고 약속합니다. 하지만 mroczek.dev의 한 소프트웨어 엔지니어는 이 수치가 일종의 착시일 수 있다고 지적합니다. 핵심만 먼저 정리하면 이렇습니다.
- "60~90% 절감"은 실제 API 청구액이 줄었다는 뜻이 아니라, RTK가 제거한 명령줄 출력의 비율에 가깝습니다.
- 압축 과정에서 스택 트레이스나 컴파일러 문맥이 **조용히 누락(silent failure)**되면, 에이전트는 잘못된 판단을 내릴 수 있습니다.
- 토큰 절감 그래프만으로는 부족하며, 작업 성공률과 SWE-bench식 정확도 평가가 함께 나와야 합니다.
절감 수치가 가리는 진짜 비용 구조
RTK가 줄이는 것은 Bash 출력의 일부일 뿐입니다. 실제 청구액을 좌우하는 더 큰 비용 요인들, 즉 깊은 파일 읽기, 저장소 컨텍스트, 시스템 프롬프트, 모델 내부 추론 토큰은 그대로 남아 있습니다.
rtk gain 같은 명령으로 보여주는 화려한 절감 지표는 근본적인 아키텍처 최적화라기보다, 소셜 미디어 스크린샷이나 비기술 관리자에게 보여주기 좋은 숫자에 가깝다는 것이 글쓴이의 시각입니다. 실제로 최근 GitHub 이슈에서도 과장된 지표에 대한 문제 제기가 시작됐습니다.
정확성과 운영 안정성이라는 더 큰 변수
진짜 위험은 AI 에이전트가 텍스트가 압축됐다는 사실을 모른다는 점입니다.
- RTK가 몇 토큰을 아끼려고 스택 트레이스의 중요한 줄을 제거하면, 사용자와 LLM 모두 불완전한 정보로 작업하게 됩니다.
- 프롬프트 비용을 80% 줄여도, 문맥 저하로 에이전트가 환각을 일으키거나 빌드에 실패하거나 루프를 돌면 결국 더 많은 토큰을 쓸 수 있습니다.
git,cargo,npm,grep이 출력 포맷의 공백 몇 개나 오류 레이아웃을 바꾸면, RTK의 정규식·파싱 필터가 깨질 수 있습니다. 이때 명시적 오류 대신 조용히 실패하면 손상된 텍스트가 그대로 에이전트에 공급됩니다.
결국 RTK는 결정적 신뢰성, 의미적 완전성, 아키텍처 단순성을 원시 토큰 감소라는 지표와 맞바꾸는 셈입니다.
RTK는 제품이라기보다 '기능'에 가깝다
글쓴이는 출력 최적화가 독립 제품이나 플랫폼보다는 개발 도구의 한 기능에 가깝다고 봅니다. 만약 주요 CLI들이 LLM 소비에 맞춘 네이티브 --compact나 --json-stream 플래그를 제공하기 시작하면, RTK의 핵심 장점은 사라질 수 있습니다.
실제로 Hacker News 토론에서는 이미 이런 흐름이 관찰된다는 의견이 나왔습니다. 예를 들어 Codex가 이제 git status 대신 git status --short 같은 호출을 자주 한다는 것이죠. 즉, 일부 최적화는 이미 모델 계층으로 올라가고 있다는 의미입니다.
반론도 새겨들을 만하다
물론 RTK 옹호 의견도 설득력이 있습니다. 한 사용자는 "입력 390만 토큰 중 370만을 아낄 수 있다면 받겠다. 절약된 토큰은 절약된 토큰"이라며, RTK가 필터 실패 시 원본 출력으로 되돌아가도록 설계됐다고 반박합니다.
반면 다른 의견은 "RTK가 플래그 정보를 제거해 나중에 되찾으려고 도구 호출을 1번 대신 3번 하게 되면, 그건 절약이 아니다"라고 짚습니다. 그리고 모두가 공감한 결론은 이것입니다.
이런 도구는 단순 토큰 절약이 아니라 **정답당 비용(cost per correct answer)**으로 벤치마크해야 한다.
마치며
RTK 자체가 무가치하다는 이야기는 아닙니다. 문맥 창의 신호 대 잡음비를 낮춘다는 아이디어는 충분히 타당합니다. 다만 "최대 90%"라는 바이럴 문구 대신, silent degradation을 해결하고 투명한 작업 정확도 벤치마크를 내놓기 전까지는, 프로덕션 에이전트의 중요 경로에 넣기엔 운영 리스크가 할인 폭보다 클 수 있습니다. 새로운 AI 도구를 도입할 때 비용 그래프 뒤에 숨은 정확성 지표를 함께 따져봐야 하는 이유입니다.