rtk: 에이전트가 읽는 명령 출력을 60~90% 줄이는 Rust 단일 바이너리 프록시

지난 한 해 동안 코딩 에이전트가 예산을 쓰는 방식에는 조용한 변화가 있었다. 모델이 써 내는 토큰보다 읽어 들이는 토큰이 훨씬 많아진 것이다. 에이전트가 셸 명령을 실행할 때마다, 그것이 테스트 실행이든 git 상태 확인이든 디렉터리 목록이든 중간 규모 프로젝트의 빌드든, 출력 전체가 그대로 컨텍스트 창에 들어간다. 빌드 로그는 수천 줄에 이르기도 하는데, 다음 판단에 실제로 영향을 주는 것은 그중 몇 줄뿐인 경우가 많다. 나머지는 토큰 단위로 과금되고, 모델의 주의를 흐리며, 세션이 컨텍스트 한도에 더 빨리 다가가게 해서 요약이나 잘라내기를 앞당긴다. rtk-ai 팀이 공개한 오픈소스 프로젝트 rtk는 바로 이 간과된 낭비를 겨냥한다. 내건 문구는 분명하다. 에이전트가 읽는 bash 출력을 최대 90%까지 줄이는 고성능 CLI 프록시라는 것이다.

위치로 보면 rtk는 또 하나의 에이전트 프레임워크도, 또 하나의 모델 게이트웨이도 아니다. 에이전트와 셸 사이에 끼어드는 얇은 계층이다. 기존에는 에이전트가 명령을 직접 호출하고 표준 출력을 그대로 읽었다. rtk를 쓰면 같은 명령이 프록시를 거치고, 프록시가 명령을 실행해 결과를 걸러 내고 압축한 뒤 짧아진 내용을 모델에 넘긴다. 프로젝트가 제시하는 숫자는 토큰 60%에서 90% 절감이며, README는 상한을 최대 약 90%라고 표현한다. 다만 이는 개발자 스스로의 주장이고, 비율은 명령 종류에 크게 좌우된다. 의존성 설치 로그나 장황한 테스트 진행 표시처럼 잡음이 많고 반복적인 출력은 압축할 여지가 크다. 원래 짧은 출력은 거의 여지가 없다. 범위의 위쪽 끝은 최선의 경우로 보아야 하며 평균으로 받아들여서는 안 된다.

구현 선택도 눈여겨볼 만하다. 에이전트 루프는 명령을 자주 내리고, 작업 하나가 수십 번, 때로는 백 번 넘게 명령을 일으키기도 한다. 프록시가 인터프리터나 무거운 런타임에 의존하면 시작 지연이 호출마다 쌓여 체감되는 대기 시간이 되고, 누군가 관리해야 하는 환경 의존성도 생긴다. 외부 의존성이 없는 네이티브 실행 파일은 호출당 부담이 작고, 경로에 두기만 하면 설치되며, 컨테이너, CI 머신, 개발자 노트북에서 동일하게 동작한다. 저장소에는 Homebrew 포뮬러가 있고, 관대한 Apache-2.0 라이선스를 쓰며, CI 보안 점검 배지를 달고 있고, README를 영어, 프랑스어, 중국어, 일본어, 한국어, 스페인어, 포르투갈어 일곱 언어로 제공한다. 화려하지는 않지만, 주말 데모가 아니라 실제 도입을 염두에 둔 프로젝트임을 보여 주는 신호들이다.

압축은 무엇을 버릴지 정하는 일이며, 이 점을 정면으로 다뤄야 한다. 사람이 긴 로그에서 경고 한 줄을 놓쳐도 잃는 것은 대개 작다. 그러나 에이전트가 치명적인 오류를 하나 놓치면 잘못된 가정 위에서 작업을 이어 가고, 턴을 더 소모하고, 압축하지 않았을 때보다 더 비싸질 수 있다. 따라서 rtk 같은 도구를 절감한 토큰 수만으로 평가하는 것은 잘못이다. 봐야 할 지표는 작업을 성공적으로 끝내는 데 드는 건당 비용이다. 합리적인 절차는 팀의 실제 작업에서 대표 집합을 골라 프록시 유무로 각각 여러 번 실행하고 완료율, 턴 수, 총 토큰을 기록하는 것이다. 실패 경로는 특히 꼼꼼히 확인해야 한다. 컴파일 오류, 어서션 실패, 스택 트레이스, 종료 코드는 잡음으로 버려지지 않고 온전히 보존되어야 한다. 에이전트가 혼란스러워할 때를 대비해 원본 출력을 읽을 수 있는 비상구도 마련해 두어야 한다.

놓치기 쉬운 관련 쟁점이 관측 가능성이다. 프록시가 경로에 들어오면 무엇이 제거되었는지 팀이 알아야 하며, 그렇지 않으면 사후 분석은 추측에 의존하게 된다. 좋은 설계는 압축할 때마다 흔적을 남긴다. 원래 길이, 압축 후 길이, 접힌 구간의 수, 가능하다면 비교를 위해 원문을 복원할 수단이다. 그러면 토큰 절감은 정체 모를 숫자가 아니라 감사하고 조정할 수 있는 공학 지표가 된다. 규제가 있는 환경이라면 도입 전에 원본 출력 전체가 규정 준수와 디버깅을 위해 로컬에 보존되는지도 확인해야 한다. 시야를 넓히면 rtk는 컨텍스트 엔지니어링이 프롬프트 계층에서 도구 계층으로 내려가는 흐름을 보여 준다. 지난 이 년 동안 업계의 관심은 프롬프트 압축, 캐시 재사용, 검색을 통한 선별에 쏠려 있었다. 에이전트가 오래 도는 루프가 되면서 도구가 돌려주는 결과가 컨텍스트의 주된 원천이 되었고, 도구 경계에서 잘라 내는 편이 사후에 요약하는 것보다 싸고 예측하기 쉬운 경우가 많다. 이 방식은 프롬프트 캐싱과 경쟁하지 않고 보완한다. 캐싱은 반복되는 접두부의 단가를 낮추고, 프록시는 접두부에 들어가는 양 자체를 줄이므로 두 효과는 겹쳐진다. 비용 절감에 반드시 더 작은 모델이 필요한 것은 아니라는 점도 일깨워 준다. 때로는 모델이 필요 없는 것을 덜 읽게 하는 것만으로 충분하다.

그래도 신중함은 유지해야 한다. 이 글을 쓰는 시점에서 rtk의 구체적인 필터링 규칙, 잘 지원하는 명령의 범위, 60%에서 90%라는 수치의 근거가 된 벤치마크는 저장소 문서와 직접 측정으로 확인해야 한다. 우리는 이 수치를 독립적으로 재현하지 않았으므로 예산에 사실로 적어 넣는 것은 권하지 않는다. 코딩 에이전트에 크게 의존하는 팀에게 현실적인 길은 중요도가 낮은 프로젝트에서 시험 도입하고, 일주일치 토큰 지출과 작업 성공률을 모은 뒤 확대 여부를 정하는 것이다. 데이터가 뒷받침하면 rtk는 적은 노력으로 눈에 띄는 비용 절감을 얻는 도구가 된다. 그렇지 않더라도 에이전트가 돈을 어디에 쓰고 있었는지는 알게 될 것이다.