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