에이전트가 읽는 터미널 출력을 줄여 토큰을 아끼는 Rust 도구 RTK

금요일 오후에 CI가 깨졌고, 코딩 에이전트에게 “테스트 돌려서 원인 찾아 줘”라고 맡겼다고 합시다(편집부가 만든 장면입니다). 에이전트는 cargo test를 실행하고, 테스트 500개 가운데 498개가 통과했다는 사실을 한 줄씩 전부 읽은 다음에야 실패한 2개에 도달합니다. 통과한 줄은 판단에 쓸모가 없는데도 입력 토큰이 되고, 그 출력은 이후 호출에서도 대화 기록의 일부로 다시 읽힙니다. RTK(Rust Token Killer)는 이 출력을 에이전트가 읽기 전에 줄이는 단일 실행 파일입니다. GitHub 조직 rtk-ai가 관리하며, 2026-10-27 확인 기준 별 8만 4천 6백 개 안팎, 포크 5천 4백 개 안팎이고 최신 정식 릴리스는 10월 25일의 v1.1.0입니다.

이 글은 소개 대신 순서대로 따라 하는 방식으로 씁니다. 이름이 같은 다른 프로젝트를 피해 설치하고, 훅을 등록하고, 위 장면의 cargo test가 어떻게 달라지는지 보고, 줄어든 출력이 모자랄 때 원본을 꺼내고, 절약 숫자를 읽고, 마지막에 깨끗이 지우는 데까지 갑니다. 기준은 Claude Code이고, 다른 에이전트는 중간에 따로 정리합니다.

설치 전에 이름부터 대조한다

rtk라는 이름을 쓰는 프로젝트가 둘 있습니다. 이 글의 Rust Token Killer(rtk-ai/rtk)와, Rust 타입을 만들어 주는 Rust Type Kit(reachingforthejack/rtk)입니다. crates.io의 rtk가 뒤쪽을 가리킬 수 있어서, cargo install rtk는 엉뚱한 도구를 설치할 수 있습니다. 공식 문서는 Cargo로 설치할 때 Git 주소를 지정하라고 안내합니다.

설치 방법은 다섯 가지입니다. 어느 것을 골라도 아래 확인 단계는 같습니다.

# macOS / Linux (Homebrew 탭, 릴리스 바이너리)
brew install rtk-ai/tap/rtk
# Windows
winget install rtk-ai.rtk
# Cargo (Git 주소를 꼭 지정)
cargo install --git https://github.com/rtk-ai/rtk --branch master rtk

README에는 brew install rtk도 나옵니다. 이쪽은 Homebrew 공식 저장소의 소스 빌드 공식이고, 설치 안내서의 rtk-ai/tap/rtk는 릴리스 바이너리를 받는 공식입니다. 설치 스크립트(curl … | sh)와 미리 빌드한 바이너리도 공식 방법입니다. 스크립트는 받은 내용을 읽지 않고 실행하는 형태라서, 파일로 내려받아 훑어본 뒤 실행하거나 패키지 관리자를 쓰는 편이 안전합니다. 소스에서 직접 빌드한다면 Rust 1.91 이상이 필요합니다.

설치가 끝나면 두 명령으로 맞는 프로젝트인지 가립니다.

rtk --version
rtk gain

rtk gain이 절약 대시보드를 보여 주면 맞는 도구입니다. rtk: 'gain' is not a rtk command라는 오류가 나오면 Rust Type Kit을 설치한 것이니, cargo uninstall rtk로 지우고 위의 Git 주소 방식으로 다시 설치합니다. Cargo로 깔았는데 command not found: rtk가 나온다면 ~/.cargo/bin이 PATH에 없는 경우가 보통입니다.

훅을 켜기 전에 바뀔 파일을 본다

rtk를 설치했다고 에이전트의 출력이 줄어들지는 않습니다. 에이전트의 도구 실행 직전에 끼어드는 훅을 등록해야 합니다. 등록은 설정 파일을 고치는 일이라서, 문서가 --dry-run을 먼저 쓰게 되어 있는 순서를 따르는 것이 좋습니다.

1. 무엇이 바뀌는지 본다. rtk init --global --dry-run은 만들거나 고칠 파일을 [dry-run] would … 줄로 보여 주고 아무것도 쓰지 않습니다
2. 연결한다. rtk init --global이 Claude Code 전역 훅을 설치하고 ~/.claude/settings.json에 등록합니다. 지침 파일 RTK.md도 함께 만들어집니다
3. 에이전트를 다시 시작한다. 훅은 새로 뜬 세션부터 적용됩니다
4. 등록을 확인한다. rtk init --show로 훅이 등록됐는지 보고, grep rtk ~/.claude/settings.json으로 설정 파일에도 항목이 있는지 봅니다
5. 평소처럼 일한다. 몇 번 명령을 돌린 뒤 rtk gain과 rtk gain --history를 엽니다

프로젝트 하나에만 쓰고 싶다면 --global 없이 rtk init을 실행합니다. 이 경우 훅은 설치되지 않고 CLAUDE.md에 안내문이 들어가며 .rtk/filters.toml 템플릿이 생깁니다. 훅 없이 안내문만 있으면 에이전트가 rtk를 쓰도록 부탁받을 뿐이므로, 줄이는 효과를 제대로 보려면 전역 훅이 맞습니다. Windows에서는 v0.37.2부터 훅이 네이티브 바이너리 명령(rtk hook claude)으로 등록되어 WSL이 필요 없습니다. 다른 에이전트는 옵션만 바뀝니다. Codex는 rtk init -g --codex, Gemini CLI는 rtk init -g --gemini, Cursor는 rtk init -g --agent cursor입니다.

같은 cargo test가 두 모양으로 돌아온다

이제 처음의 장면으로 돌아갑니다. 훅이 없을 때와 있을 때, 모델이 읽는 cargo test 출력을 나란히 놓았습니다. 두 화면 모두 문서가 설명하는 필터 동작에 맞춰 편집부가 만든 예시이고, 실제 출력은 프로젝트와 버전에 따라 다릅니다.

그림 1. 왼쪽은 통과한 테스트까지 모두 흐르는 출력, 오른쪽은 모델이 실제로 읽는 출력(설명용 예시)

오른쪽의 첫 줄이 통과·실패 개수이고, 그 아래에는 실패한 테스트와 핵심 오류만 남았습니다. 맨 끝줄 [full output: rtk recall 36365b69eda6c4f1]이 이 도구의 안전장치입니다(해시는 공식 문서의 예시 형식입니다). 명령이 실패했거나 필터가 긴 목록을 잘랐을 때 RTK는 전체 출력을 로컬 데이터베이스에 저장하고, 줄어든 출력 끝에 이 힌트를 붙입니다. 에이전트가 원인을 보려면 전체가 필요하다고 판단하면 힌트에 적힌 그대로 rtk recall 36365b69eda6c4f1을 실행하면 되고, 이때는 왕복이 한 번 더 듭니다.

필터는 사용자의 의도를 존중하게 설계되어 있습니다. 프로젝트의 설계 원칙은 상세 출력을 직접 요청하면 더 많이 통과시키는 것입니다. cargo test는 실패만 보여 주지만 cargo test -- --nocapture는 출력 전체를 보존하고, ls -la처럼 상세 옵션을 준 경우도 같은 취지로 다룹니다. 필터 결과가 원래 출력보다 토큰이 늘어나는 일이 없도록 하는 보호 장치(never_worse)도 코드에 있다고 문서가 설명합니다. 지시문에 git status -sb나 | tail -20, --quiet를 쓰라고 적어 두는 방법으로도 같은 목적에 다가갈 수 있지만, 명령마다 사람이 정해야 하고 에이전트가 지시를 잊으면 효과가 없습니다. RTK는 그 일을 명령 앞에서 자동으로 합니다. 두 방법은 충돌하지 않아서 함께 써도 됩니다.

명령 하나가 훅을 지나가는 길

화면이 바뀐 이유를 길로 따라가 보겠습니다. Claude Code에서는 PreToolUse 훅이 동작합니다. 도구를 실행하기 직전에 훅이 명령 문자열을 받아 rtk rewrite로 규칙표를 조회하고, 대응하는 rtk 명령으로 바꿔 돌려줍니다. 에이전트도 사용자도 rtk라는 이름을 입력하지 않습니다.

그림 2. 훅은 Bash 도구 호출에만 걸린다. 점선은 rtk를 못 찾거나 오류일 때의 길과 원본 저장

위쪽 초록 영역이 훅이 서 있는 길입니다. 점선 하나는 rtk를 찾지 못하거나 필터가 오류를 낼 때의 길로, 훅은 조용히 종료하고 원래 명령이 그대로 실행됩니다. 프로젝트의 설계 원칙 중 하나가 “RTK는 명령의 실행이나 출력을 막아서는 안 된다”입니다. 아래쪽 붉은 영역이 가장 헷갈리기 쉬운 부분입니다. 에이전트의 내장 Read, Grep, Glob 결과는 훅을 거치지 않아 줄어들지 않습니다. 줄이고 싶다면 셸 명령(cat, rg, find)을 쓰게 하거나 rtk read, rtk grep, rtk find를 직접 호출해야 합니다.

훅이 명령을 바꾸는 방식에는 알아 둘 규칙이 있습니다.

• 복합 명령. cargo fmt --all && cargo test 2>&1 | tail -20은 &&·||·; 양쪽이 각각 rtk cargo fmt --all, rtk cargo test로 바뀝니다. 파이프의 중간 단계는 원본 그대로 두고, 맨 끝 단계나 뒤따르는 명령이 표시용일 때만 앞쪽을 바꿉니다
• 따옴표 안의 스크립트. bash -c "head foo && grep -R bar ."는 bash -c "rtk read foo --head-lines 10 && rtk grep -R bar ."가 됩니다. sh, bash, zsh, fish의 -c 형태를 다룹니다
• 건드리지 않는 경우. 히어독(<<)이나 $((가 들어간 명령, 이미 rtk로 시작하는 명령, RTK_DISABLED=1이 붙은 명령은 바꾸지 않습니다
• 권한 규칙. Claude Code의 deny 규칙에 걸리는 명령은 거부되고, ask 규칙이면 확인을 요청합니다. v1.1.0부터는 설정 파일을 읽거나 해석하지 못하면 허용하지 않고 막는 쪽(fail closed)으로 동작하고, 변수 대입이나 래퍼 뒤의 명령에도 deny·ask 규칙이 맞춰집니다

줄어드는 폭은 명령마다 다르다

README는 필터가 하는 일을 네 가지로 요약합니다. 군더더기 제거, 비슷한 항목 묶기, 길이 자르기, 반복 로그를 횟수로 합치기입니다. 개발 문서는 이를 12가지 전략으로 세분하고 전략마다 설계가 목표로 하는 감소 범위를 적어 둡니다. 아래는 그중 이 글에서 다루는 명령이 속한 것들을 한 축에 놓은 그림입니다.

그림 3. 개발 문서의 설계 목표 범위(실측이 아님)

구간이 오른쪽에 몰려 있다는 점이 먼저 보입니다. 출력이 정형화되어 있고 핵심이 몇 줄뿐인 git 상태와 테스트 결과는 90% 이상을 목표로 하고, 구조를 지켜야 하는 ls는 절반 안팎, 코드를 읽는 rtk read는 최소 모드에서도 20~40%로 가장 낮습니다. 명령에 필터가 없으면 그대로 통과하고 0%로 기록됩니다. 이 범위는 내 세션에서 나오는 값이 아니라 설계 목표이니, 실제 값은 뒤에서 rtk gain으로 확인합니다. 설계 문서의 git log 예시는 원본 약 500자(125토큰)가 20자(5토큰)의 요약으로 줄어 96%가 됩니다.

README와 공식 문서가 소개하는 대표 명령은 이렇게 달라집니다.

명령	에이전트가 받는 출력
ls / tree	파일 수를 곁들인 트리 형태
git status	상태별로 묶은 짧은 요약
git diff	주변 맥락을 줄이고 머리글을 뺀 diff
git log	해시·작성자·제목만
git add/commit/push	진행 상황 대신 확인 한 줄
cargo test / npm test	실패한 것만, 통과한 테스트는 개수로
pytest	실패 항목과 줄인 트레이스백
tsc / eslint	오류를 규칙·파일별 건수로 묶음
docker ps	이름·이미지·상태·포트처럼 꼭 필요한 열만
docker logs / kubectl logs	같은 줄을 한 번과 횟수로
curl	응답 본문만, 헤더 제거

첫 gain 숫자를 읽는 법

며칠 쓴 뒤 rtk gain을 열면 Save% 숫자가 나옵니다. 이 값은 “셸 출력 바이트가 얼마나 줄었나”입니다. 공식 문서는 여러 번 선을 긋습니다. 청구액이 줄어든 비율이 아니고, 줄어드는 것은 입력 토큰의 일부인 셸 출력뿐이며, 모델의 답변(출력 토큰)과 프롬프트, 대화 기록은 건드리지 않습니다.

숫자가 어떻게 희석되는지 가정 두 가지로 계산해 보았습니다. 한 번의 호출에서 입력이 100,000토큰이고, 셸 출력이 90% 줄었다고 합니다. 셸 출력이 입력의 20,000토큰인 대화 중심 세션은 입력이 82,000토큰이 되어 18% 줄고, 셸 출력이 60,000토큰인 테스트·빌드 반복 세션은 46,000토큰이 되어 54% 줄어듭니다.

그림 4. 같은 90% 필터, 세션 성격에 따라 총 입력 감소는 18%와 54%(가정값, 편집부 계산)

같은 필터인데 결과가 세 배 가까이 다릅니다. 셸 출력이 입력의 대부분을 차지하는 세션일수록 효과가 크다는 뜻이고, 거기에 모델이 쓰는 출력 토큰은 그대로이니 청구액의 감소는 이보다 더 작습니다. 그래서 내 세션에서 어느 쪽에 가까운지가 중요합니다.

문서의 예시 출력은 명령 10개에서 입력 50,000, 출력 5,000, 절약 45,000(90.0%)이라고 적혀 있지만 “예시 값”이라는 단서가 붙어 있습니다. README의 60~90%도 프로젝트 자체 자료이고, 편집부가 확인한 범위에서 독립된 제3자의 측정은 찾지 못했습니다. 정확한 값이 필요하면 원본과 필터 결과를 모델의 토크나이저에 넣어 직접 세면 됩니다.

숫자 말고 “걸리고 있는가”를 보는 명령도 있습니다.

rtk gain --history      # 최근 명령 10개와 절약 내역
rtk discover            # 필터 없이 지나간 명령을 찾아 추정치 표시
rtk session             # 최근 세션에서 명령이 rtk를 거친 비율
rtk -vvv git status     # 필터링 과정을 stderr에 자세히 표시
rtk cc-economics        # 캐시 쓰기·읽기량과 함께 보기

rtk discover 목록에 설치 뒤에도 명령이 계속 올라온다면 그 에이전트에서 훅이 활성화되지 않았다는 신호라고 문서가 안내합니다. rtk session의 적용률이 낮을 때는 RTK_DISABLED=1로 꺼 두었거나, 특정 서브에이전트에서 훅이 활성화되지 않은 경우가 많다고 합니다. 프롬프트 캐시는 걱정하지 않아도 된다고 공식 문서가 설명합니다. 필터가 명령당 한 번 출력을 걸러 기록에 고정하므로 캐시가 맞춰 보는 앞부분이 바뀌지 않고, 캐시 쓰기는 입력 단가의 1.25배, 읽기는 0.1배라서 결과가 작을수록 처음 쓸 때도 매 턴 다시 읽을 때도 가볍습니다.

내 에이전트에서도 걸리는지 확인하기

README는 18개 도구를 지원한다고 소개하고, 에이전트 지원 문서의 표는 Copilot(VS Code·CLI)과 Trae(프로젝트·전역)를 따로 세어 20행입니다. 이 표가 중요한 이유는 “지원한다”가 곧 “출력이 줄어든다”는 뜻이 아니기 때문입니다. 에이전트의 훅 API가 무엇을 허용하느냐에 달려 있습니다. 20행 중 명령 재작성을 허용하는 것이 16개, rtk init이 그 훅을 설치해 주는 것이 14개이고, 출력 사후 압축은 8개가 허용하며 7개를 설치해 줍니다.

에이전트	걸리는 범위
Claude Code	재작성·차단·출력 압축·세션 시작 훅·프록시 경유 모두 가능. 가장 넓음
Codex	재작성이 명시적 allow 결정과 함께일 때만 적용. 아니면 훅이 실패하고 원래 명령이 실행됨
Gemini CLI	입력을 수정할 때마다 “도구 입력이 수정됨” 시스템 메모가 붙어 몇 토큰이 되돌아옴
Kilo Code, Cline, Windsurf(Devin), Kimi Code, Antigravity	훅 대신 규칙 파일을 써서 모델에게 rtk <명령>을 쓰라고 요청할 뿐. 지금은 막거나 바꾸거나 압축하지 않음
Roo Code	훅 없음. 프록시 경로만 있음
OpenCode	1.18.29 이상이어야 플러그인이 설치되고, rtk가 에이전트가 보는 PATH에 있어야 함

규칙 파일만 쓰는 에이전트에서는 rtk init이 끝나도 재작성이 일어나지 않습니다. 이때 [awareness] level이 중요해집니다. 기본값 default는 에이전트에게 RTK를 알리지 않고 RTK.md가 “줄어든 출력을 읽는 법”만 알려 줍니다. high로 올리면 rtk gain과 우회 방법도 설명하고, full은 모든 명령에 rtk 접두를 붙이라고 합니다. 훅이 없는 에이전트는 항상 full입니다.

훅이 안 먹는 것 같을 때의 점검 순서도 문서에 있습니다. rtk --version과 rtk gain으로 설치를 확인하고, rtk init --global을 다시 실행한 뒤 에이전트를 재시작하고, rtk init --show와 ~/.claude/settings.json의 rtk 항목으로 등록을 봅니다. 저장소에는 설치·경로·훅 상태를 한 번에 점검하는 scripts/check-installation.sh도 있습니다.

줄어든 출력이 모자랄 때 쓰는 우회로

필터는 정보를 줄이니, 줄어든 부분이 필요해지는 날이 옵니다. 그때 쓰는 순서는 이렇습니다.

• 되찾기. 힌트의 rtk recall <해시>가 저장해 둔 원본을 돌려줍니다. 사람이 볼 때는 rtk recall <해시> --grep 패턴으로 검색하고, rtk recall --list로 목록을 봅니다. 저장소는 기본적으로 내장 SQLite이고 gzip으로 무손실 압축하며, 기본 보관 한도는 건당 10 MiB, 200건(오래된 것부터 삭제), 30일입니다. 방식은 rtk config recall sqlite|tee|disabled로 바꿉니다
• 한 번만 원본으로. rtk bypass <명령>이나 RTK_DISABLED=1 git rebase main처럼 앞에 붙이면 그 명령만 필터를 건너뜁니다. 복구 저장을 한 번만 끄려면 RTK_RECALL=0을 붙입니다
• 아예 제외. 상태가 중요한 명령은 설정의 [hooks] exclude_commands = ["git rebase", "docker exec"]에 넣어 두면 훅이 건드리지 않습니다. ^로 시작하는 항목은 정규식입니다
• 어느 필터가 숨기나. rtk gain --recalls는 필터별로 “잘라낸 출력을 에이전트가 되찾으러 간 비율”을 보여 줍니다. 높은 필터는 에이전트에게 필요한 정보를 자주 숨긴다는 신호라서 한도를 올리거나 제외 목록에 넣을 후보이고, 낮은 필터는 자른 부분이 정말 잡음이었다는 뜻입니다

내 명령용 필터를 직접 만드는 방법도 있습니다. .rtk/filters.toml(프로젝트)과 ~/.config/rtk/filters.toml(전역)에 match_command, strip_lines_matching, keep_lines_matching, max_lines, on_empty 같은 필드로 정의하고 [[tests…]]에 입출력 예를 적어 검증합니다. 필터는 에이전트가 보는 것을 바꾸므로, 저장소에 들어 있는 .rtk/filters.toml을 받는 즉시 적용하면 남이 만든 규칙이 내 에이전트의 눈을 가릴 수 있습니다. 그래서 RTK는 내용의 SHA-256을 기준으로 rtk trust로 확인하기 전까지 그 파일을 조용히 건너뜁니다. 저장소 문서도 이것이 동의와 변조 흔적을 남기는 장치이지 샌드박스는 아니며, 같은 사용자 권한으로 파일을 쓸 수 있는 공격자는 신뢰 목록도 고칠 수 있다고 한계를 적습니다. 모르는 저장소를 열 때는 rtk trust에 --yes를 붙이지 말고 내용을 읽으세요.

에디션과 프록시를 고르는 기준

내려받는 것이 세 가지라서 설치 전에 구분해야 합니다. 앞의 설치 단계는 첫 줄(rtk)을 기준으로 했습니다.

내려받는 것	라이선스	들어 있는 것
rtk	Apache-2.0 + BUSL-1.1	훅, 모든 명령 필터, 압축 엔진
rtk-oss	Apache-2.0만	훅과 명령 필터(엔진 없음)
rtk-proxy	BUSL-1.1	API 트래픽을 압축하는 별도 데몬

rtk와 rtk-oss는 같은 이름의 실행 파일을 설치하므로 함께 둘 수 없습니다. Homebrew는 두 공식에 충돌을 선언해 두 번째 설치를 막고, deb·rpm 패키지는 충돌 선언이 없어서 파일 충돌에서 멈추니 한쪽을 지운 뒤 설치하세요. rtk-oss는 RTK_EDITION=oss를 붙인 설치 스크립트나 brew install rtk-ai/tap/rtk-oss로 받습니다. 엔진이 빠지면 rtk pipeline·rtk methods·rtk tasks와 PostToolUse 압축(pipeline.toml에 rtk:posthook 확장을 켜야 에이전트의 Read와 MCP 출력까지 압축하는 기능)을 못 쓰지만, 매일 쓰는 부분인 재작성 훅, 모든 명령 필터, rtk gain, rtk discover는 같습니다.

BUSL-1.1은 소스는 공개하지만 오픈소스 정의에는 맞지 않는 소스 공개(source-available) 라이선스입니다. 저장소 문서에 따르면 운영 환경에서의 사용은 무료이고, RTK나 그 파생물을 제3자에게 상용 제품·서비스로 제공하는 것은 허가 범위 밖입니다. 회사 정책이 모든 바이너리에 OSI 승인 라이선스를 요구한다면 rtk-oss를 고르면 됩니다. Homebrew 공식 저장소의 rtk 공식은 라이선스를 Apache-2.0으로 표기하고 탭의 공식은 Apache-2.0과 BUSL-1.1로 표기하는 차이가 있으니, 정책이 걸려 있다면 에디션 이름이 분명한 쪽으로 설치하는 것이 확실합니다.

프록시는 한 단계 위에서 일합니다. 훅이 셸 명령 출력을 줄인다면 rtk-proxy는 에이전트가 모델에 보내는 요청 전체(대화 기록, 도구 결과, 파일 내용)를 줄입니다. 127.0.0.1:8080에서 도는 로컬 HTTP 데몬이고, 에이전트의 ANTHROPIC_BASE_URL이 데몬을 가리키게 하거나 rtk claude 한 줄로 데몬을 띄워 Claude Code를 경유시킵니다. 훅과는 독립적인 선택 사항입니다. 요청이 이 프로세스를 거쳐 가므로 신뢰 경계를 하나 더 넓히는 일이라, 문서가 밝힌 범위를 알고 켜야 합니다. 프롬프트와 응답 본문은 저장하지 않고, 옵트인 기능인 CCR만 압축한 원본을 rtk-proxy-memory.db에 7일 보관합니다. 원격 통계는 기본 꺼짐이며 rtk telemetry enable로 동의해야 하루 한 번 익명 핑(버전·OS·명령 수·상위 명령 이름·절약률)이 나가고, 명령 내용과 파일 경로는 보내지 않는다고 명시되어 있습니다.

최근 열흘의 릴리스 흐름도 알아 두면 좋습니다. 릴리스 목록에는 dev-1.1.0-rc.574 같은 사전 릴리스가 자주 올라오므로, 일반 사용자는 정식 릴리스나 패키지 관리자 버전을 쓰면 됩니다.

1. 10월 14일v1.0.1 gain이 존재하는 명령만 안내하도록 수정, 프록시 시작이 바인드 설정을 따르도록 수정
2. 10월 20일dev-1.0.2-rc.567 반복되는 Ruff·SQLFluff 설명을 압축
3. 10월 23일사전 릴리스 rc.568~573 fish 스크립트 감싸기(옵트인), Angular 빌드 표 압축 개선
4. 10월 25일v1.1.0 권한 설정을 못 읽으면 막기, 도움말 옵션 통과, Claude Code 관리 워크트리에서 git 재작성 안 함, 재작성한 명령의 무결성 검증, pytest 오류 줄 유지

되돌리는 순서

마음에 들지 않으면 설치의 반대로 지웁니다. 먼저 훅과 지침 파일을 걷어 냅니다.

rtk init -g --uninstall     # 훅, RTK.md, settings.json 항목 제거

그다음 설치한 방식에 맞춰 실행 파일을 지웁니다. Homebrew는 brew uninstall rtk, winget은 winget uninstall rtk-ai.rtk, Cargo는 cargo uninstall rtk입니다. 프록시 설정을 했다면 init이 쓴 ANTHROPIC_BASE_URL도 함께 제거됩니다(데몬 주소를 가리키는 경우). 통계 기록은 별도로 남아 있어서, macOS에서는 ~/Library/Application Support/rtk/history.db(기본 보관 90일)가 그대로이니 rtk gain --reset으로 확인 후 초기화하거나 파일을 직접 지웁니다. 훅을 걷어 낸 뒤 에이전트를 다시 시작하고 cargo test를 한 번 돌려 출력이 원래 모양으로 돌아왔는지 보면, 처음 장면에서 시작한 순서가 한 바퀴 닫힙니다.