Comparison · Already Absorbed

RTK vs semble_rs
vs Loopy-Era Harness

두 도구의 핵심 컨셉은 trend-harvester가 74·85차 수확 (2026-04~05)으로 이미 결정화. 양자택일이 아니라 4축 토큰 압축 생태계의 부분집합으로 통합돼 있습니다.

질문이 잘못 잡혔다
Question

"RTK랑 semble_rs 중에 뭐 쓰면 좋을지, 아니면 보완해서 쓸지?"

양자택일 프레임 자체가 잘못입니다. 두 도구는 레이어가 다른 도구이고, 그 핵심 컨셉은 이미 trend-harvester 74차·85차 수확으로 내 시스템에 rule로 결정화돼 있습니다. 진짜 결정 포인트는 "뭘 쓸지"가 아니라 "결정론적 실행이 필요한가"입니다.
이미 흡수된 매핑

두 도구의 컨셉은 모두 ~/.claude/rules/ 디렉토리에 markdown rule로 결정화되어, 모든 에이전트에 자동 주입됩니다. semble_rs가 단일 바이너리에 통합한 4가지 기능(BM25·semantic·AST·dependency)은 내 시스템에서는 2개의 직교적 rule로 더 세밀하게 분해돼 있습니다.

외부 도구 수확 차수 결정화된 rule 상태
RTK
rtk-ai/rtk
85차
2026-05-02
rules/cli-output-compression.md
CLI 출력 후처리 필터링 (git status 2000→400 토큰)
✓ 컨셉 결정화
semble_rs (johunsang/semble_rs) — BM25 + Semantic + AST + Dependency를 단일 바이너리로 통합. 내 시스템에서는 2개 rule로 분할 흡수.
└ 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에서 수확
✓ 컨셉 결정화
4축 토큰 압축 생태계

RTK·semble_rs는 이 생태계의 1축씩만 담당합니다. 내 harness에는 4축이 모두 직교 통합돼 있어 동시 적용 시 누적 80–95% 토큰 절감이 가능합니다.

LLM Context Window 토큰 80–95% 절감 (4축 동시 적용 시) AXIS 1 · INPUT Input Compression claw-compactor 파일 입력 다단계 압축 -15~82% AXIS 2 · CLI OUTPUT CLI Output Compression RTK ◄── 여기 bash 출력 후처리 -80% AXIS 3 · TOOL OUTPUT Tool Output Sandboxing context-mode 도구 출력 격리 · 세션 6× 연장 -98% AXIS 4 · CODE SEARCH Semantic Code Search semble_rs ◄── 여기 grep/cat/read 대체 -40~93% RTK · semble_rs는 4축 중 2축에 해당 — 나머지 2축은 이미 별도 rule로 활성
Axis 01 · Input

Input Compression

tool: claw-compactor

파일을 LLM에 넣기 전 다단계 압축 파이프라인. 코드/JSON/diff/자연어 type별로 라우팅하여 0 LLM 추론 비용으로 압축.

rules/context-compression-pipeline.md 15–82% file input reduction
Axis 02 · CLI Output · RTK 위치

CLI Output Compression

tool: RTK (rtk-ai/rtk)

bash 명령 출력을 LLM에 전달 전 투명 압축. git status 2000→400 토큰. 100+ 명령 지원. PreToolUse hook으로 끼우는 레이어.

rules/cli-output-compression.md −80% bash output reduction
Axis 03 · Tool Output

Tool Output Sandboxing

tool: context-mode

도구 결과를 서브프로세스 샌드박스에 격리하고 결과만 stdout으로 추출. Playwright 56KB → 299B. 세션 지속시간 30분 → 3시간.

rules/tool-output-sandboxing.md −98% tool output reduction
Axis 04 · Code Search · semble_rs 위치

Semantic Code Search

tool: semble_rs / claude-context

BM25 + dense vector 하이브리드 + Tree-sitter AST 청킹. grep/cat/read를 자연어 검색 1회로 대체. semble_rs는 dependency graph까지 통합.

rules/semantic-code-search-mcp.md + graph-rag-codebase-indexing.md −40~93% code exploration reduction
컨셉 흡수 vs 도구 설치

trend-harvester가 한 것은 컨셉의 결정화지 도구의 설치가 아닙니다. 두 접근은 강제력·범위·운영비용이 다릅니다. 양쪽을 혼동하면 "이미 다 있는데 또 깔까?"라는 잘못된 결정으로 이어집니다.

trend-harvester (이미 완료)

Concept Crystallization

"외부 패턴을 markdown rule로 결정화하여 모든 에이전트에 자동 주입"

수확물
rules/*.md (markdown 텍스트)
강제력
모든 agent에 SOFT 지시 자동 주입
범위
bug-fixer · code-reviewer · team 등 30+ agent
자가진화
self-improve가 rule 자동 강화/HARD 승격
운영비용
0 (파일만, 인덱싱·런타임 없음)
즉시 실행
안 됨 — LLM 판단 필요
비용 절감
간접적 (LLM이 패턴 인지 후 적용)
도구 직접 설치 (선택)

Binary Implementation

"rule을 결정론적 binary/MCP로 실체화"

수확물
실제 실행 파일 (Rust binary, MCP 서버)
강제력
호출 시점에 즉시 결정론적 동작
범위
명시적으로 호출한 hook/agent만
자가진화
없음 — 도구 버전에 고정
운영비용
설치 · 인덱싱 · 버전 갱신 필요
즉시 실행
됨 — exit code · JSON 출력
비용 절감
직접적 (실측 토큰 차감)
진짜 결정 포인트

"뭘 쓸지"가 아니라 "결정론적 실행이 필요한가"가 진짜 질문입니다. 컨셉은 이미 다 흡수돼 있으므로, 도구 설치는 SOFT rule을 HARD binary로 승격할 가치가 있는 시점에만 합니다.

시나리오
rule이 LLM에 SOFT 지시만 하면 충분 (현재 작동 중) 추가 설치 불필요 — 현 상태 유지
매번 결정론적 · 실측 토큰 절감이 필요 RTK 설치 → PreToolUse hook으로 bash 출력 자동 압축
대규모 코드베이스 grep 비용이 실측 문제 semble_rs 설치 → agent의 Grep/Read 화이트리스트에 추가
둘 다 마찰이 큼 — Axis 2 · 4를 HARD로 승격하고 싶음 둘 다 설치 → 4축 생태계의 2 · 4축 binary 실체화
같은 rule이 2회 이상 LLM 판단 실패 soft-to-hard-promotion.md 트리거 — 자동 HARD 승격 후보
핵심 메시지
Frame Shift

"RTK vs semble_rs" 양자택일은 도구 평가 관점입니다.

내 시스템은 두 도구의 컨셉을 이미 74차·85차 수확으로 흡수했으므로, 진짜 질문은 "새 컨셉 추가가 필요한가"가 아니라 "기존 SOFT rule을 HARD binary로 승격할 가치가 있는가"입니다.

RTK·semble_rs를 깐다는 건 새 컨셉을 도입하는 것이 아니라, 이미 흡수된 rule을 결정론적 실행 레이어로 실체화하는 것입니다.

관련 페이지