AI 코딩 에이전트를 오래 돌리다 보면 실제 코드보다 git status, git diff, 테스트 실패 로그, 빌드 경고, docker ps 같은 반복적인 셸 출력이 컨텍스트를 많이 차지한다. rtk는 이 문제를 “더 작은 모델”이 아니라 셸 출력 필터링 레이어로 풀려는 Rust CLI다.

핵심 아이디어는 단순하다.
에이전트가 셸 명령을 실행하기 전에 명령을 rtk가 감싸도록 만들고, rtk가 원래 명령을 실행한 뒤 LLM에게 필요한 부분만 압축해 돌려준다.
README 기준으로 git, 파일 탐색, 테스트 러너, 빌드/린트, 패키지 매니저, AWS, Docker/Kubernetes, JSON/log/curl 출력 등 100개 이상의 개발 명령을 대상으로 한다.

조사 시점 기준 rtk-ai/rtk는 Rust 프로젝트이며 GitHub 최신 Release와 Homebrew 공식 formula 모두 v0.42.0이다.
GitHub API와 checked-in LICENSE는 Apache License 2.0으로 확인된다.
README의 “60-90% token savings” 수치는 프로젝트 자체 예시이므로 독립 벤치마크처럼 받아들이기보다는, 반복 명령 출력이 큰 에이전트 세션에서 먼저 시험해볼 만한 신호로 보는 편이 안전하다.

RTK 개요

RTK는 LLM 자체를 호출하는 도구가 아니라, LLM 에이전트가 명령 결과를 읽는 방식을 바꾸는 CLI 프록시다.

agent shell command
  → rtk rewrite / hook / plugin
  → original command execution
  → smart filtering + grouping + truncation + deduplication
  → compact output returned to the agent

예를 들어 raw git status가 긴 파일 목록과 안내 문구를 그대로 반환한다면, rtk git status는 변경 상태를 짧게 요약한다.
테스트 명령은 실패 케이스 중심으로 줄이고, 빌드/린트 출력은 파일·규칙별로 묶으며, Docker나 AWS 목록은 LLM이 다음 액션을 정하기 쉬운 형태로 압축하는 식이다.

중요한 점은 RTK가 “터미널 대체 앱”이라기보다 에이전트 앞단의 출력 정리기라는 것이다.
사람이 직접 쓰는 CLI로도 동작하지만, 가장 큰 가치는 Claude Code, Codex, Gemini CLI, Cursor, OpenCode, Hermes 같은 도구가 매번 긴 셸 출력을 컨텍스트에 붙여 넣지 않게 만드는 데 있다.

왜 유용한가

내가 보는 RTK의 실용 포인트는 세 가지다.

  • 반복 명령의 컨텍스트 비용 절감: ls, tree, grep, git diff, npm test, cargo test, docker logs처럼 에이전트가 자주 호출하는 명령의 노이즈를 줄이는 데 초점이 맞춰져 있다.
  • 실패 로그 보존: README 기준 명령 실패 시 전체 원본 출력은 로컬 tee 저장소에 남길 수 있다. 즉, 평소에는 요약을 보고, 정말 필요할 때만 full output을 다시 읽는 흐름이 가능하다.
  • 에이전트별 통합 경로: Claude Code는 PreToolUse hook, Gemini CLI는 BeforeTool hook, OpenCode/OpenClaw/Hermes는 plugin 또는 adapter, Codex는 instruction 파일 방식처럼 도구별 제약에 맞춘 통합 경로를 제공한다.

이런 특성 때문에 RTK는 “한 번 쓰는 CLI”보다 여러 sub-agent가 같은 저장소에서 git, test, build를 반복 호출하는 환경에서 더 빛난다.
특히 장시간 세션에서 컨텍스트가 빨리 포화되거나, raw 로그가 답변 품질을 흐리는 경우에 도입 후보가 된다.

설치와 첫 사용법

README가 가장 먼저 제안하는 경로는 Homebrew다.

brew install rtk

Linux/macOS용 quick install script와 GitHub Release 바이너리도 제공된다.

curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/refs/heads/master/install.sh | sh

Rust 개발 환경이 있다면 GitHub 저장소에서 직접 설치할 수 있다.

cargo install --git https://github.com/rtk-ai/rtk

여기서 주의할 점은 crates.io에도 같은 이름의 다른 rtk가 있다는 것이다.
README가 명시하듯 토큰 최적화용 RTK를 원한다면 cargo install rtk가 아니라 위의 --git 경로를 쓰고, 설치 뒤에는 다음처럼 확인하는 편이 좋다.

rtk --version
rtk gain

에이전트 통합은 보통 rtk init 계열로 시작한다.

rtk init -g              # Claude Code / Copilot 기본 경로
rtk init -g --gemini     # Gemini CLI
rtk init -g --codex      # Codex
rtk init --agent hermes  # Hermes
rtk init --show          # 설치 상태 확인

Windows는 지원하지만, README 기준 자동 재작성 hook은 Unix shell에 더 잘 맞는다.
네이티브 Windows에서는 필터 자체는 쓸 수 있으나 hook은 CLAUDE.md 주입 방식으로 제한되고, 완전한 hook 경험은 WSL을 권장한다.

활용 포인트

RTK를 바로 모든 프로젝트에 전역 적용하기보다는, 먼저 출력이 큰 저장소 하나에서 다음 흐름으로 시험하는 편이 좋다.

# 설치 후 현재 통합 상태 확인
rtk init --show

# 원래 명령과 RTK 명령을 비교
rtk git status
rtk git diff
rtk test npm test
rtk docker ps

# 절약 통계 확인
rtk gain
rtk discover

에이전트가 자동 재작성 hook을 쓰는 환경이라면, 실제 사용자는 git status처럼 평소 명령을 그대로 입력하고 에이전트 앞단에서만 rtk git status로 바뀌게 된다.
반대로 hook이 닿지 않는 도구나 built-in file reader를 쓰는 경우에는 rtk read, rtk grep, rtk find처럼 명시적으로 호출해야 한다.

팀 환경에서는 exclude_commands 설정도 중요하다.
예를 들어 curl, Playwright, 배포 스크립트처럼 출력 형식이나 side effect를 정확히 봐야 하는 명령은 자동 재작성 대상에서 빼는 편이 안전할 수 있다.

주의할 점

첫째, RTK는 에이전트 설정을 실제로 바꾼다.
Claude Code hook, Codex/Hermes/OpenCode용 instruction 또는 plugin 파일처럼 로컬 에이전트 런타임의 동작 경로에 들어가므로, dotfile을 직접 관리하거나 보안 정책이 엄격한 환경에서는 rtk init --show, 설정 파일 diff, uninstall 경로를 먼저 확인해야 한다.

둘째, 출력 압축은 언제나 정보 손실 가능성을 가진다.
테스트 실패나 빌드 오류는 보통 요약이 유용하지만, flaky test, race condition, 긴 stack trace처럼 전체 맥락이 필요한 문제에서는 tee로 저장된 원본 로그를 확인하거나 raw 명령을 다시 실행해야 한다.

셋째, telemetry 문서를 확인해야 한다.
README와 docs/TELEMETRY.md 기준 telemetry는 기본 비활성화이며 rtk init 또는 rtk telemetry enable에서 명시 동의가 필요하다고 설명한다.
그래도 에이전트 도구 사용량, 명령 category, token savings 같은 로컬 사용 통계를 다루는 도구이므로 회사 장비에서는 rtk telemetry status, rtk telemetry disable, RTK_TELEMETRY_DISABLED=1 같은 제어 방법을 정책에 맞춰 확인하는 것이 좋다.

넷째, 공식 Release asset은 macOS, Linux, Windows용으로 제공되지만 플랫폼별 경험은 다르다. macOS/Linux/WSL은 hook 기반 흐름이 자연스럽고, 네이티브 Windows는 CLI 필터 사용과 instruction fallback 중심으로 보는 편이 맞다.

내 판단

RTK는 “에이전트가 명령을 덜 실행하게 하는” 도구라기보다, 실행한 명령의 결과를 LLM이 덜 비싸게 읽게 하는 도구다.
큰 mono-repo, 테스트 로그가 많은 Rust/Node/Python 프로젝트, Docker·Kubernetes·AWS 상태를 자주 확인하는 에이전트 워크플로라면 꽤 직접적인 체감이 있을 수 있다.

반대로 사람이 짧은 명령만 직접 실행하는 작은 프로젝트, 이미 에이전트용 출력 제한이 충분히 잡힌 환경, hook이 로컬 정책상 허용되지 않는 회사 장비라면 전역 설치가 과할 수 있다.
내 기준 추천 방식은 한 프로젝트에서 명시적 rtk git, rtk test, rtk docker 호출로 먼저 품질을 보고, 괜찮으면 전역 hook이나 agent별 plugin 통합으로 넓히는 것이다.

참고한 공개 자료