RTK, Terminal-Bench에서 DeepSeek 비용 평균 17% 증가

RTK가 줄인 출력은 모델이 학습에서 보던 셸 출력과 다름. 그 때문에 모델이 혼란스러워 더 많은 턴을 쓰는 결과가 이상하지 않음

차세대 모델이 RTK식 출력도 학습하면 얘기가 달라질 수 있음. 컨텍스트에는 실제로 토큰이 덜 들어가고, 낯선 형식 때문에 추가 호출할 일도 줄어들 테니까

RTK나 각종 스킬 번들은 대체로 과장이라고 봄. 나는 로컬 임베딩 모델로 코드베이스를 색인해 의미 검색을 붙였더니 토큰과 벽시계 시간이 줄었는데, CPU 비용과 벤치마크 잡음은 감안해야 함

남의 토큰 절감 주장은 뱀기름이라면서 자기 Lumen의 30% 절감 주장은 왜 믿어야 함? 작은 저장소와 모노레포, 기업 환경까지 된다는 홍보 문구도 똑같이 의심스러움

JetBrains IDE의 MCP 액션이 더 나은 해법일 수 있음. 에이전트가 구현 위치나 사용처를 grep으로 추측하지 않고 IDE의 검색, 사용처, 구현 이동 기능을 직접 호출하면 됨

Lumen 벤치마크도 저자가 아닌 사람이 재현해 봐야 함. 나는 Dirac 결과를 Pi에서 재현하려다 실패했고, 저자와 같은 모델과 하네스에서도 결과에 가까이 못 갔음

로컬 RAG 자체는 현실적인 접근임. 그래도 일부 작업에서는 도구 호출을 남겨둬야 한다고 봄

C#에서는 Roslyn MCP를 쓰면 많이 아낌. 다만 RTK처럼 CLI 출력을 줄이는 도구와 달리 코드베이스를 다루는 방식 자체를 더 낫게 바꾸는 거라 같은 비교 대상은 아님

Roslyn MCP를 초기에 써봤는데 너무 느렸음. 편집을 따라가지 못한 분석 결과가 들어와서 에이전트가 혼란스러워하더라

에이전트 비용도 직원 비용처럼 지나치게 아끼려 하면 손해를 볼 수 있음

글의 결론이 너무 뒤에 나옴. 시도당 평균 비용은 Claude/Fable이 $1.72에서 $1.64로 약 5% 내렸고 DeepSeek은 $0.115에서 $0.121로 약 5% 올랐는데, Claude 절감분도 거의 한 작업에서 나왔음

이런 도구가 인기를 얻는 이유를 모르겠음. 대개 성능이 나쁘거나 큰 대가가 붙음

모델이 더 똑똑해지면 큰 출력을 예상해서 셸 명령 자체를 조절할 수 있음. 이런 우회책보다 모델 능력이 이기는 bitter lesson 사례 같음

Maven처럼 쓸데없는 로그를 많이 찍는 도구는 조용한 모드를 쓰게 하거나 RTK를 적용할 만함. 로그 파일 위치만 알려주는 간단한 build.sh도 빠른 해결책임

Dirac에 넣으려고 RTK를 시험했는데 CPU 시간과 정확도 모두 손해였음. grep Return * | wc -l은 0.38초에 966을 냈지만 RTK를 거치면 23초에 260을 냈고, 틀린 출력은 에이전트 전체를 망가뜨림

내 경험상 토큰을 줄이는 일 자체는 가능하지만 기본적인 출력 압축보다 훨씬 어려움. 단위 테스트 같은 QA 도구를 --quiet로 돌려 경고와 실패만 출력하게 하는 정도가 먼저 할 일임

일반적인 bash 도구의 출력은 모델이 익숙하게 학습한 형식임. 출력을 바꾸면 도구가 고장 났다고 판단해 호출을 늘릴 수 있으니, 특수 래퍼 대신 grep과 tail을 적극 쓰라고 프롬프트에 적는 편이 나을 수 있음