문제는 이것이었습니다. AI 코딩 도구가 쓰는 토큰(AI가 주고받는 글자 단위입니다. 많을수록 비용과 시간이 늘어납니다)을 줄여 준다는 도구 둘이 눈에 들어왔습니다. 하나는 터미널 명령 결과를 줄여 주는 Rust Token Killer입니다. 다른 하나는 파이썬 코드 검색기 semble을 Rust로 다시 만든 Rust판 semble입니다. 둘 중 무엇을 쓸지 골라야 했습니다. 그래서 제가 만든 trend-harvester(바깥의 AI 도구·트렌드를 모아 제 작업 규칙으로 정리해 두는 수집기)의 기록부터 뒤져 봤습니다. 결론부터 말하면, 두 도구의 핵심 기능은 이미 제 시스템 안에 들어와 있었습니다. 74번째·85번째 수확(2026년 4~5월)에서 두 도구의 아이디어를 규칙으로 굳혀 놨기 때문입니다. 그래서 '둘 중 뭘 쓸까'는 잘못된 질문이었습니다. 두 도구는 토큰을 줄이는 네 가지 방법을 묶은 큰 그림의 한 조각으로 이미 합쳐져 있습니다.
"Rust Token Killer랑 Rust판 semble 중에 뭐 쓰면 좋을지, 아니면 보완해서 쓸지?"
두 도구가 하는 일은 모두 제 컴퓨터의 ~/.claude/rules/ 폴더 안에 markdown 규칙 파일(rule, AI에게 '이렇게 해라'라고 미리 적어 둔 지시문)로 저장돼 있습니다. 그래서 제가 쓰는 모든 AI 에이전트에 자동으로 들어갑니다. Rust판 semble은 네 가지 기능을 실행 파일 하나에 몰아넣었습니다. 제 시스템에서는 그 네 기능이 서로 겹치지 않는 규칙 2개로 더 잘게 나뉘어 들어와 있습니다. 네 기능은 키워드가 딱 맞는 곳을 찾는 검색(검색 엔진이 오래 써 온 점수 방식입니다), 뜻이 비슷한 곳을 찾는 검색(semantic), 코드를 문법 구조대로 나눠 읽는 분석(Tree-sitter 구문 분석기가 만드는 구문 트리, abstract syntax tree 기준), 파일 간 의존 관계 추적(dependency)입니다. 영문 이름은 이 순서대로 다음과 같습니다. BM25 · semantic · Tree-sitter AST · dependency graph
| 외부 도구 | 수확(수집) 회차 | 정리된 규칙(rule) | 상태 |
|---|---|---|---|
RTKRust Token Killer · rtk-ai/rtk |
85차 2026-05-02 |
rules/cli-output-compression.md터미널 명령 결과를 걸러서 줄입니다 (예: git status 결과가 2000토큰 → 400토큰) |
✓ 아이디어 흡수 완료 |
semble_rs (johunsang/semble_rs) · 키워드 일치 검색·뜻 검색(semantic)·코드 구문 트리 분석(Tree-sitter)·의존 관계 추적(dependency)을 실행 파일 하나에 다 넣은 코드 검색기입니다. 파이썬 도구 semble을 Rust로 다시 만든 것입니다. 제 시스템에서는 이 기능이 규칙 2개로 나뉘어 들어와 있습니다. |
|||
└ BM25 + Semantic + Tree-sitter AST |
85차 2026-05-02 |
rules/semantic-code-search-mcp.mdzilliztech/claude-context라는 오픈소스(코드를 뜻으로 검색해 주는 MCP 연결 서버)에서 아이디어를 가져왔습니다 |
✓ 아이디어 흡수 완료 |
| └ Dependency Graph + Impact (Blast Radius) | 74차 2026-04-30 |
rules/graph-rag-codebase-indexing.mdabhigyanpatwari/GitNexus라는 오픈소스(코드 의존 관계를 그래프로 그려 "이걸 바꾸면 어디가 깨지나"를 답하는 도구)에서 아이디어를 가져왔습니다 |
✓ 아이디어 흡수 완료 |
Rust Token Killer와 Rust판 semble은 이 네 가지 방법 중 각각 한 가지씩만 맡습니다. 반면 제 하네스(harness — AI가 일을 제대로 하도록 짜 둔 실행 틀)에는 네 가지가 서로 겹치지 않게 모두 들어가 있습니다. 한꺼번에 적용하면 토큰을 최대 80~95%까지 줄일 수 있습니다.
tool: claw-compactor · input: code / JSON / diff / text
파일을 AI(LLM)에 넣기 전에 여러 단계로 압축하는 처리 과정입니다. 코드·구조화된 데이터 파일·수정 내역(diff)·일반 문장처럼 종류별로 알맞은 방법에 나눠 보냅니다. AI를 한 번도 쓰지 않고(추가 비용 0으로) 크기를 줄입니다.
rules/context-compression-pipeline.md
15–82%
file input reduction
CLI Output Compressiontool: RTK · Rust Token Killer (rtk-ai/rtk)
터미널 명령(bash)의 결과를 AI에 넘기기 전에 자동으로 줄여 줍니다. 사용자는 원래대로 보되 AI에게만 짧게 전달합니다(투명 압축). 예를 들어 git status 결과가 2000토큰에서 400토큰으로 줍니다. 100개가 넘는 명령을 지원합니다. AI가 명령을 실행하기 직전에 끼어드는 층(PreToolUse hook, 도구 실행 직전에 자동으로 도는 작은 스크립트)입니다.
rules/cli-output-compression.md
−80%
bash output reduction
tool: context-mode
도구가 쏟아내는 결과를 따로 떼어 낸 공간(샌드박스)에서 처리하고, 핵심 결과만 뽑아 AI에 넘깁니다. 예를 들어 웹 자동화 도구 Playwright의 출력이 56KB에서 299B(바이트)로 줄어, 한 번의 대화 세션을 30분에서 3시간까지 이어 갈 수 있습니다.
rules/tool-output-sandboxing.md
−98%
tool output reduction
tool: semble_rs / claude-context · method: BM25 + dense vector + Tree-sitter AST
키워드가 딱 맞는 곳을 찾는 검색(검색 엔진이 오래 써 온 점수 방식)과 뜻이 비슷한 곳을 찾는 검색(dense vector, 문장을 숫자 벡터로 바꿔 가까운 것을 찾는 방식)을 섞습니다. 코드는 문법 구조대로 잘라(Tree-sitter라는 구문 분석기가 만든 구문 트리 기준) 정리합니다. grep·cat·read 같은 파일 뒤지기 명령 여러 번을 '평소 말로 묻는 검색' 한 번으로 대체합니다. Rust판 semble은 파일 간 의존 관계 지도(dependency graph)까지 함께 담았습니다.
rules/semantic-code-search-mcp.md + graph-rag-codebase-indexing.md
−40~93%
code exploration reduction
제 수집기(trend-harvester)가 한 일은 아이디어를 규칙으로 굳힌 것이지, 도구를 직접 설치한 것이 아닙니다. 이 둘은 강제하는 힘, 적용 범위, 유지 비용이 서로 다릅니다. 둘을 헷갈리면 '이미 다 있는데 또 깔아야 하나?' 하는 잘못된 결론에 빠집니다. 왼쪽 카드가 '권고' 층이고, 오른쪽 카드가 '강제' 층입니다.
SOFT"외부 도구의 좋은 패턴을 markdown 규칙으로 정리해, 모든 AI 에이전트에 자동으로 넣는다"
SOFTSOFT → HARDHARD"규칙을 늘 똑같이 작동하는 실행 파일(binary)이나 연결 서버(MCP)로 실제로 만든다"
exit code + JSON진짜 질문은 '무엇을 쓸까'가 아니라 '늘 똑같이 자동으로 실행되는 장치가 필요한가'입니다. 아이디어는 이미 다 흡수했습니다. 그러니 도구를 새로 설치하는 건 '권고 규칙'을 '반드시 실행되는 프로그램'으로 끌어올릴 만한 상황일 때만 합니다. SOFT → HARD
| 이런 상황이라면 | 이렇게 하세요 |
|---|---|
| 규칙이 AI에게 '이렇게 해라'라고 권고만 해도 충분한 경우 (지금 이대로 잘 돌아감) | 새로 설치할 필요가 없습니다. 지금 그대로 둡니다 |
| 매번 똑같이 작동하고, 토큰이 실제로 줄어드는 게 필요한 경우 | Rust Token Killer 설치 → AI가 명령을 실행하기 직전(PreToolUse hook)에 터미널 결과를 자동으로 줄입니다 |
| 코드가 아주 많아, 파일을 뒤지는(grep) 비용이 실제로 부담되는 경우 | Rust판 semble 설치 → 에이전트가 쓸 수 있는 도구 목록(화이트리스트)에 검색·읽기 도구로 넣습니다 |
두 가지 모두 자주 걸리적거려서, 2번·4번 방법을 '반드시 실행되는 프로그램'으로 올리고 싶은 경우 HARD |
둘 다 설치 → 네 가지 방법 중 2번·4번을 실제 실행 파일로 만듭니다 |
| 같은 규칙을 AI가 두 번 넘게 못 지킨 경우 | '권고를 강제로 올리는 규칙'(같은 실패가 두 번 이상 반복되면 강제 후보로 올리는 규칙 파일입니다)이 작동합니다. 자동으로 강제 규칙 후보가 됩니다 soft-to-hard-promotion.md |
'Rust Token Killer냐 Rust판 semble이냐' 하고 둘 중 하나를 고르는 건, 도구를 놓고 비교 평가하는 시각입니다.
제 시스템은 두 도구의 아이디어를 이미 74·85차 수확 때 흡수했습니다. 그래서 진짜 물어야 할 것은 '새 아이디어를 더 들여와야 하나'가 아니라 '권고 규칙을 반드시 실행되는 프로그램으로 올릴 값어치가 있나'입니다. SOFT → HARD
Rust Token Killer나 Rust판 semble을 설치한다는 건 새 아이디어를 들여오는 일이 아닙니다. 그것은 이미 흡수한 규칙을 늘 똑같이 실행되는 실제 층으로 만들어 내는 것입니다.
74번째·85번째 수확의 원본 기록입니다. 바깥의 AI 새 소식을 다섯 가지 기준으로 걸러 제 시스템에 자동으로 반영한, 회차별 정리입니다.
harvest logAI 연구자 카파시(Karpathy)가 말한 'AI가 스스로 개선하는 시대' 개념을 실제로 구현한, 스스로 발전하는 반복 구조입니다. 제 수집기(trend-harvester)가 들어 있는 3축 시스템의 뼈대입니다.
architecture키워드 일치 검색·뜻 검색(semantic)·코드 구문 트리 분석(Tree-sitter)·의존 관계 지도(dependency graph)를 하나로 합쳐, grep·cat·read 같은 파일 뒤지기 명령을 대신하는 코드 검색기입니다. 파이썬 도구 semble을 Rust로 다시 만든 것으로, 실행 파일 하나로 돌아갑니다.
BM25 + semantic + Tree-sitter AST + dependency graph
johunsang/semble_rs
github
터미널 명령 결과를 AI에 넘기기 전에 자동으로 줄여 줍니다(사용자 화면은 그대로). git status 결과가 2000토큰에서 400토큰으로 줍니다. 100개가 넘는 명령을 지원합니다.
rtk-ai/rtk
github