# 토큰 압축의 착시: RTK에 회의적인 이유 > Clean Markdown view of GeekNews topic #30660. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=30660](https://news.hada.io/topic?id=30660) - GeekNews Markdown: [https://news.hada.io/topic/30660.md](https://news.hada.io/topic/30660.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-06-20T15:21:18+09:00 - Updated: 2026-06-20T15:21:18+09:00 - Original source: [mroczek.dev](https://mroczek.dev/articles/the-token-compression-illusion-why-im-skeptical-of-rtk/) - Points: 1 - Comments: 1 ## Topic Body - RTK는 코딩 에이전트의 터미널 출력을 압축해 비용을 낮추겠다고 약속하지만, **원시 출력 감소**가 곧 더 저렴하고 안전하며 정확한 소프트웨어 엔지니어링을 뜻하지는 않음 - “60~90% 절감”은 **LLM 청구액**이 그만큼 줄었다는 뜻이 아니라, RTK가 제거한 명령줄 출력 비율에 가까움 - 터미널 출력이 조용히 손상되거나 누락되는 **silent failure**가 생기면, 에이전트는 중요한 스택 트레이스나 컴파일러 문맥 없이 잘못된 판단을 내릴 수 있음 - 토큰 절감 그래프만으로는 충분하지 않으며, 자율 에이전트가 실제 작업을 끝냈는지 보여주는 **작업 성공률**과 SWE-bench식 정확도 평가가 필요함 - RTK는 독립 제품보다 개발 도구 기능에 가까워 보이며, `git`, `cargo`, `npm`, `grep` 같은 CLI 출력 변화에 취약해 프로덕션 에이전트의 중요 경로에 넣기엔 운영 리스크가 큼 --- ### 절감 수치가 가리는 실제 비용 구조 - [RTK](https://www.rtk-ai.app/)는 코딩 에이전트용 터미널 출력 압축으로 **토큰 사용량 절감**과 비용 감소를 내세움 - GitHub 스타 60k 이상을 얻었고, 업계가 이 홍보에 크게 반응하고 있음 - 다만 “너무 좋아 보이는” 개발 도구 주장은 실제 구조를 따져봐야 함 - “60~90% 절감”이라는 바이럴 수치는 **실제 API 청구액 절감**과 같지 않음 - RTK가 줄이는 것은 Bash 출력의 일부임 - 깊은 파일 읽기, 저장소 컨텍스트, 시스템 프롬프트, 모델 내부 추론 토큰처럼 더 큰 비용 요인이 남아 있음 - `rtk gain` 같은 명령은 근본적인 아키텍처 최적화보다 소셜 미디어 스크린샷이나 비기술 관리자에게 보여주기 좋은 지표에 맞춰진 것처럼 보임 - 최근 GitHub 이슈에서도 과장된 지표에 대한 문제 제기가 시작됨 ### 정확성과 운영 안정성이 더 큰 변수 - 최적화는 정확성이 따라오지 않으면 의미가 없으며, 저장소의 공개 이슈에는 터미널 출력이 **조용히 망가지거나 누락**되는 사례가 이미 나타남 - 핵심 위험은 AI 에이전트가 텍스트가 압축됐다는 사실을 모른다는 점임 - RTK가 스택 트레이스나 컴파일러 문맥의 중요한 줄을 몇 토큰 절약을 위해 제거하면, 사용자와 LLM 모두 불완전한 정보로 작업하게 됨 - RTK 도입은 수많은 CLI 도구의 출력을 의미 손실 없이 파싱·해석·축약해야 하는 외부 계층에 의존하는 선택임 - RTK는 토큰 절감 그래프를 보여주지만, 실제로 중요한 **작업 성공률** 지표가 빠져 있음 - 자율 에이전트가 실행 루프 끝에서 소프트웨어 엔지니어링 문제를 해결했는지가 핵심임 - 프롬프트 비용을 80% 줄여도 문맥 저하 때문에 에이전트가 환각을 일으키거나 빌드에 실패하거나 루프를 돌면 결국 더 많은 토큰을 쓸 수 있음 - 비용 그래프와 함께 엄밀한 SWE-bench식 정확도 평가가 나오기 전까지 RTK의 서사는 불완전함 - 아키텍처 관점에서 RTK는 에이전트와 셸 사이의 **동기식 중요 경로**에 취약한 외부 의존성을 추가함 - 출력 최적화는 독립 제품이나 플랫폼보다 기능에 가까움 - 주요 CLI와 개발 도구가 LLM 소비에 맞춘 네이티브 `--compact` 또는 `--json-stream` 플래그를 제공하면 RTK의 주요 장점은 사라질 수 있음 - RTK는 사람이 읽는 stdout/stderr 형식을 구체적으로 파싱하는 방식에 크게 의존해 유지보수가 어려움 - `git`, `cargo`, `npm`, `grep`이 터미널 포맷의 공백 몇 개나 오류 레이아웃을 바꾸면 RTK의 정규식과 파싱 필터가 깨질 수 있음 - 이 경우 명시적 오류 대신 조용히 실패해 손상되거나 부분적인 텍스트를 에이전트에 공급할 수 있음 - RTK는 원시 터미널 토큰 감소라는 화려한 지표를 위해 **결정적 신뢰성**, 의미적 완전성, 아키텍처 단순성을 맞바꾸게 함 - silent degradation을 해결하고 투명한 작업 정확도 벤치마크를 제공하기 전까지, 프로덕션 에이전트 워크플로의 중요 경로에 넣는 것은 할인 폭에 비해 운영 리스크가 큼 ## Comments ### Comment 60013 - Author: neo - Created: 2026-06-20T15:21:19+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48588755) - 이런 글들이 **LLM 마법 상자 산업** 전반에 대해 드디어 힘을 얻기 시작해서 반가움 caveman mode부터 RTK, 의미 검색까지 개발자들이 엔지니어라기보다 주문을 외우는 마법사가 된 느낌이고, 직장에서는 특히 각자 자기 주문이 궁극의 토큰 절약법이라고 확신해서 피곤함 기준은 이렇다: **평가 하네스** 안에 없는 아이디어는 대체로 별로이고, 좋은 아이디어는 결국 Codex/Claude로 올라온다고 봄. GitHub에서 토큰을 몇 퍼센트 절약한다고 광고하는 것도 믿기 어려움 이런 분야에서 사기성 도구를 피하기 어렵고, 사람들이 더 비판적으로 보기 시작했으면 함 - 완전히 틀렸고, 최전선 업체들이 **LLM 모델을 만드는 것 외의 영역**에서는 얼마나 무능한지 과소평가하고 있음 1년 동안 “게임 엔진처럼 작성된” 깜박이는 TUI 같은 사례도 있었고, 직접 여러 벤치마크를 돌려보니 같은 결과를 내면서도 토큰을 줄이는 검증된 방법들이 있음. 예를 들어 같은 CVE를 찾거나, 코드 리뷰에서 같은 버그를 찾는 식임 내 작은 증명으로 [https://maki.sh]()를 보면 됨 - 그래서 모든 것을 **블라인드 A/B 테스트**함 토큰은 많이 태우지만, 실제로 가치가 있다는 걸 증명해야 하고 대부분은 그 기준에 전혀 못 미침 내 AI 에이전트에도 여러 기능이 들어 있지만, 4개월 전 블라인드 A/B 테스트 결과가 오늘도 의미 있다고 보지는 않음. 내가 쓰는 단어 선택만으로도 결과가 크게 달라질 수 있음 그래도 직접 가치를 확인하고 눈으로 보기 위해 테스트함. 구체적인 블라인드 A/B 테스트 결과는 굳이 공개하지 않음 다른 사람들이 블라인드 A/B 테스트를 아주 잘못하는 것도 봤고, 측정이 부실하면 테스트 자체가 무의미함 우리 모두 이 문제를 같이 풀고 있고, 흑마법이 많아서 hooks에 많이 의존함. 내 작은 AI 에이전트에도 흑마법이 잔뜩 있을 것임 확실히 아는 건, 나에게는 동작한다는 것뿐임. 이걸 안 쓰면 지금 사람들이 AI로 어떻게 일하는지 솔직히 모르겠음 링크는 남기지만, 네가 뭘 하든 추천한다는 뜻은 아님. 대부분 다른 소프트웨어 엔지니어들만 쓰고, 내가 해야 하는 일에 매우 특화되어 있음. 잘해야 직접 구현할 아이디어를 줄 수 있는 정도임 [https://github.com/notque/vexjoy-agent]() - “좋은 아이디어는 Codex/Claude로 올라온다”는 말은, 누군가 **RTK 같은 도구**를 만들고 다른 사람들이 써볼 때만 성립함 이번 판을 지켜보기만 하는 것도 괜찮지만, RTK, Headroom, caveman mode 같은 도구는 처리해야 하는 입력·출력 토큰을 줄이고, 로컬 LLM에서는 측정 가능한 속도 향상을 만들 수 있음 최종 출력 품질을 해치는지는 말할 만큼 데이터가 충분하지 않지만, 알아보기 위해 만져보는 건 즐거움 - 아이디어 자체는 타당함. **문맥 창의 신호 대 잡음비**를 낮출 수 있다면 좋은 일임 다만 RTK가 실제로 그렇게 하는지는 아직 입증되지 않았음. “최대 90%” 같은 의미 없는 문구가 아니라, 이 도구가 실제로 만드는 차이를 제대로 벤치마크한 결과를 보고 싶음 - 더 나아가, `git status` 같은 명령에 대해 rtk에서 본 일부 최적화는 이미 **모델 계층**으로 올라간 것으로 보임 Codex가 이제 `git status` 대신 `git status --short` 같은 도구 호출을 자주 함 - 글쓴이임. 솔직히 말하면, 소프트웨어 엔지니어로서 **rtk ai**가 아주 이상해 보여서 썼음 별 수, 정확도 언급 부재, 그리고 경영진이 비용 최적화를 위해 이런 걸 밀어붙이는 방식이 걸렸음. 이제 사람들은 가능한 모든 명령을 rtk로 감싸고, 주요 명령을 전부 처리하려 하며 어떤 출력을 받아야 하는지까지 결정하려고 함 - [https://www.github.com/jahala/tilth]()에 대한 생각을 진심으로 듣고 싶음 RTK와는 다른 접근이고, **정답당 비용**을 약 40% 줄이는 것으로 벤치마크했음 - 왜 주장을 뒷받침할 **실제 사용 수치**를 하나도 제시하지 않았는지 모르겠음. 별로 도움이 되지 않았음 - 도구 출력은 내 출력에서 큰 비중을 차지함. 입력 390만 토큰 중 370만 토큰을 아낄 수 있다면 받겠음. **절약된 토큰은 절약된 토큰**임 RTK 사용자로서 정확도 벤치마크가 있으면 좋겠지만, 압축 때문에 모델이 중요한 것을 놓쳤다는 증거는 아직 못 봤음 설계 철학상 정확성 보존을 매우 엄격하게 다루고, 필터가 실패하면 원본 출력으로 되돌아갈 정도임. 자주 쓰는 명령들의 소스도 직접 봤고, 마음에 들었으며 지금까지는 신뢰를 얻었다고 봄 git, cargo, npm, grep이 터미널 서식을 몇 칸 바꾸거나 오류 레이아웃을 바꾸면 RTK의 정규식과 파서가 깨질 거라는 우려도 있지만, 필터가 실패하면 원본 출력으로 되돌아감. RTK는 손상되거나 부분적인 텍스트를 에이전트에 먹이면 안 되도록 설계된 도구임 우려는 타당하지만, 비판은 증거로 뒷받침됐으면 함. RTK를 써봤는지, 정확성을 보존하지 못한다는 증거를 찾았는지 궁금함 - 이슈를 조사하면서 봤는데, 눈에 띈 몇몇 이슈는 꽤 안 좋아 보임 [https://github.com/rtk-ai/rtk/issues/2494]() [https://github.com/rtk-ai/rtk/issues/2462]() [https://github.com/rtk-ai/rtk/issues/2395]() - **절약된 토큰은 절약된 토큰**이 아닐 때도 있음 RTK는 플래그와 다른 정보를 제거함. 때로는 그걸 나중에 되찾으려고 더 많은 토큰을 쓰게 됨. 해당 도구 호출에서 토큰 70%를 아꼈더라도, 지표에는 도구 호출을 1번 대신 3번 했는지가 드러나지 않음 제거된 출력 때문에 **추론 토큰**을 더 쓰게 되는지도 따져봐야 함 - 정확성을 아주 엄격하게 보존한다는 것만으로는 충분하지 않다고 봄 최신 모델과 뒤처진 오픈 가중치 모델 사이의 비용 차이, 또는 가장 큰 모델과 그 아래 모델의 비용 차이를 고려하면 성능을 매우 신중하게 측정해야 함 비판하는 쪽이 증거를 대야 한다기보다, **RTK가 성능을 떨어뜨리지 않는다는 것**을 RTK가 입증해야 함 - 핵심은 AI를 더 좋게 만든다는 도구는 수없이 많은데, **AI가 실제로 더 잘 작동하는지 측정할 방법**은 없다는 것임 인기 제품을 가진 큰 회사들은 방법이 있음. 일반 제품 분석과 챗봇 평가 사이 어딘가에서 사용자가 세션에서 성공하고 있는지 파악함. 그게 일임 하지만 하루 3~50개 세션을 돌리는 개별 개발자는 어떤 것이 LLM을 더 낫게 만드는지 알 방법이 거의 없음. 전부 감임 우리 회사에는 선호하는 하네스, 모델, skills, 코드 구조까지 전체 스택이 있음. Claude Code의 100만 분의 1 규모에서도 이 설정이 우리에게 작동하는지 측정할 방법이 있어야 함 - 내 제품에서는 명시적으로 에이전트에게 물어보라고 함. 직접 시도해볼 수 있는 실제 예시와 실제 저장소가 있음 [https://gitsense.com]() [https://github.com/gitsense/smart-ripgrep]() [https://github.com/gitsense/smart-codex]() 평균 토큰 절약에는 크게 관심이 없음. 더 관심 있는 건 AI가 불필요한 파일을 문맥에 올리지 않는지이고, 이는 추론에 영향을 줄 수 있음 작업 후 에이전트에게 “파일의 목적을 먼저 알았다면 읽지 않았을 파일이 몇 개라고 생각하느냐”고 물어보면 됨 - 유효한 벤치마크를 만드는 노력은 엄청남. 아마 맞는 말이고, 그래서 더 짜증남 이미 프레임워크를 두고도 논쟁이 많았는데, 이건 훨씬 더 심함. 네 감 대 내 감의 싸움이 됨. **비결정적 출력**이 우리를 여기까지 데려올 줄 누가 알았겠음 - 답은 있음. 이런 도구들은 단순한 토큰 절약이 아니라 **정답당 비용**으로 벤치마크해야 함 - 직접 써봤는데, 내 문맥의 90%를 차지하는 메시지는 압축하지 않아서 전체 토큰 사용량 중 작은 부분만 압축했음 글을 주의 깊게 읽으면 바로 그렇게 쓰여 있음. `/context`를 보면 아마 토큰을 쓰는 곳이 도구 호출이 아니라는 걸 알 수 있음. 그래서 도구 호출만 압축하는 프록시는 도구 호출을 8배 압축한다는 말이 사실이더라도 큰 영향을 주지 못함 긴 코딩 세션에서는 내게 그다지 중요하지 않았음 “native/built-in Read or cat tools, the data is not intercepted by RTK's shell hook” - 이 글은 반박을 뒷받침할 데이터가 거의 없고, 대부분 **LLM이 생성한 글**처럼 읽힘 - Semble에서도 이런 불만을 받은 적이 있음. 타당한 불만이라고 생각하지만, 이런 종류의 벤치마크를 만드는 건 **하네스 × 모델 × MCP/CLI 조합** 때문에 매우 어렵고 비쌈 전통적인 기계학습이나 도구에서는 벤치마크를 보여주지 않는 것이 보통 위험 신호였음. 하지만 LLM 도구에서는 잘 모르겠음 - 에이전트가 RTK 압축을 인지하고 우회 옵션을 갖게 하면 **잘림을 감지**하게 만들 방법은 있음. 나는 원본 전체 텍스트를 복원하는 방식으로 `RTK_DISABLE=1`을 씀 잘 동작하고, 맞음. 명령 출력만 압축하므로 “압축” 관점에서는 입력 토큰만 영향을 받음 - 주류 CLI와 개발자 도구가 LLM 소비에 맞춘 네이티브 `--compact`나 `--json-stream` 플래그를 제공할 수 있다는 말은 맞지만, 그들이 곧 그렇게 하지는 않을 것임 그래서 rtk, caveman, ponytail 같은 도구들이 계속 커지는 비용을 줄이려는 것임. 2천 명 규모 조직이면 현재 약 250만 달러 수준이고, 모두가 이런 **절충**을 알고 조정 중임 글쓴이의 주장과 달리 우리는 절충을 잘 알고 있고, 도구를 포크하고 벤치마크하고 출력 품질이 필요에 맞는지 검증하면서 쓰고 있음. 맹목적으로 쓰는 게 아님 개인 개발자라면 꼭 필요 없을 수 있고, 비용 절감을 위해 다른 모델을 자체 호스팅하는 편이 나을 수도 있음. 하지만 조직에서는 꽤 매운 부분임 이런 글이 조명을 비추는 건 좋지만, 도구를 대하듯 이런 글도 어느 정도 걸러서 읽어야 함 - Mac에서 `rtk gain`을 쳐봤음. 주 개발 머신은 메모리 문제 때문에 다시 이미지했고 몇 가지가 꼬여서 확인 못 했지만, Mac에서는 대략 **입력 5.1만 토큰**과 출력 2.3만 토큰을 줄였고, 명령당 평균 3초를 아꼈음 왜 이렇게 분노하는지, 왜 굳이 글까지 썼는지 잘 모르겠음 누가 스택 추적을 RTK로 파이프하는지는 모르겠음. 나는 아주 특정 프로그램에만 쓰고, 컴파일러 출력을 밀어 넣는 건 어리석어 보임. 에이전트에게 RTK를 특정 명령 집합에만 쓰라고 지시하면 됨