12 KiB
12 KiB
tags
| tags | |||||||
|---|---|---|---|---|---|---|---|
|
ClawRouter 멀티 LLM 라우팅 적용성 리서치
관련 문서
- OpenClaw 기반 로빙 개선 아이디어
- OpenClaw 컨텍스트·메모리 리서치
- 모델 SSOT 하드코딩 분산과 workspace-config 로컬이식 통합 리서치
- 260316 gpt-5-mini 전환과 skill-news provider-agnostic 정리
목적
BlockRunAI/ClawRouter를 실제 1차 자료 기준으로 확인하고, 로빙에 도움이 되는 요소와 바로 쓰기 어려운 요소를 분리합니다.- 이번 문서는 외부 레포 소개가 아니라
로빙이 어떤 레이어를 흡수해야 하는가를 닫기 위한 리서치입니다. - 구현 범위 고정과 우선순위는 후속
plans에서 다룹니다.
Facts
1. ClawRouter는 실제 공개 오픈소스이며, 2026-03-22 기준 빠르게 성장 중입니다
- GitHub API 기준 저장소는
BlockRunAI/ClawRouter, 기본 브랜치는main, 라이선스는MIT입니다. - GitHub API 기준 스타는
6155, 포크는491, 공개 이슈는26입니다. - 저장소 생성일은
2026-02-03, 마지막 푸시는2026-03-21T23:54:11Z입니다.
2. 이 프로젝트의 실제 핵심은 "OpenAI 호환 프록시 + 로컬 라우터 + x402 결제"입니다
README.md,docs/architecture.md,src/proxy.ts기준으로 ClawRouter는localhost에 OpenAI 호환 프록시를 띄우고, 그 앞단에서 요청을 분류한 뒤 BlockRun API로 보냅니다.src/proxy.ts에는Dedup,route,fallback chain,balance monitor,response cache,session pinning,context compression이 한 프록시 경로 안에 묶여 있습니다.- 즉 단순 SDK 래퍼가 아니라
모델 선택 + 비용 계산 + 결제 + 재시도 + 세션 정책을 같이 소유하는 인프라 레이어입니다.
3. "차원 수"와 "지원 모델 수" 설명은 문서마다 일관되지 않습니다
- 저장소 메인 README는
15 dimensions,44+ models를 말합니다. docs/smart-llm-router-14-dimension-classifier.md는14 weighted dimensions,46 models를 말합니다.openclaw.plugin.json과skills/clawrouter/SKILL.md는41+ models를 말합니다.- 따라서 이 저장소는 빠르게 진화 중이지만, 마케팅 문구와 기술 문서 수치가 아직 완전히 수렴한 상태는 아닙니다.
4. 현재 확인 가능한 실제 라우팅 코어는 규칙 기반 분류 + 일부 LLM 보조 분류입니다
src/router/selector.ts는 티어별 primary/fallback 모델 체인, 비용 추정, baseline 대비 savings 계산을 수행합니다.src/router/llm-classifier.ts는 규칙 기반 분류가 애매할 때만 저가 모델로SIMPLE/MEDIUM/COMPLEX/REASONING재분류를 수행합니다.docs/smart-llm-router-14-dimension-classifier.md기준 분류축은 reasoning, code, multi-step, technical terms, token count, creative, question complexity, agentic, constraint, imperative, output format, simple indicators, reference complexity, domain specificity입니다.- 즉 "모든 요청을 LLM이 판단"하는 구조가 아니라, 로컬 룰을 우선하고 애매한 경우에만 작은 비용의 보조 분류를 붙이는 구조입니다.
5. OpenClaw 플러그인 결합은 강하지만, 로직 대부분은 OpenAI 호환 프록시 패턴으로 분리 가능합니다
openclaw.plugin.json과skills/clawrouter/SKILL.md기준으로 배포 표면은 OpenClaw 플러그인입니다.- 하지만 실제 핵심 기능은
src/proxy.ts,src/router/*,src/response-cache.ts,src/retry.ts,src/session.ts,src/compression/*에 있으며, OpenClaw 전용으로만 묶인 것은 아닙니다. - 즉 설치 UX는 OpenClaw 플러그인 중심이지만, 기술 아이디어 자체는 일반 프록시/게이트웨이에도 이식 가능합니다.
6. ClawRouter는 라우팅 외에도 운영 안정화 장치를 많이 가지고 있습니다
src/proxy.ts에는 요청 중복과 이중과금을 막기 위한 deduplication이 있습니다.docs/features.md에는 response cache, tool detection, context-length-aware routing, free-tier fallback, session persistence가 정리돼 있습니다.src/compression/index.ts에는 7단계 context compression이 있습니다.src/journal.ts에는 세션별 핵심 행동을 따로 남기는 경량 journal 계층이 있습니다.
7. 로빙은 이미 "provider 직접 호출 제거"와 "모델 SSOT 수렴"을 일부 시작한 상태입니다
- 260316 gpt-5-mini 전환과 skill-news provider-agnostic 정리 기준으로
skill-news의 Gemini 직접 호출은 제거됐고,rb8001 /api/llm/generate공용 경로가 도입됐습니다. - 같은 worklog 기준으로
workspace-config/runtime.env의DEFAULT_LLM_MODEL을 중심으로 런타임 수렴을 확인했습니다. - 즉 로빙은 아직 멀티 모델 자동 라우팅은 없지만, 적어도 "중앙 LLM 경로"와 "모델 SSOT"로 이동하는 방향 자체는 이미 시작됐습니다.
8. 로빙과 ClawRouter의 차이는 결제보다 "라우팅 소유권 위치"에 있습니다
- ClawRouter는 요청 직전 프록시에서 모델 선택을 수행합니다.
- 로빙은 현재
DEFAULT_LLM_MODEL중심 단일 기본값 운용이 강하고, 서비스별 잔존 분기 제거를 계속 정리하는 단계입니다. - 따라서 로빙 관점 핵심 질문은 "USDC 결제를 붙일 것인가"보다 "모델 선택 규칙을 어디에 둘 것인가"입니다.
Interpretation
1. 로빙에 가장 유용한 것은 결제 레이어가 아니라 라우팅 정책 계층입니다
- 로빙은 현재 OpenClaw 단일 개인 에이전트보다는
rb8001 + skill-* + gateway중심의 내부 서비스 구조입니다. - 따라서
wallet signature + x402 + USDC는 현재 문제의 직접 해법이 아닙니다. - 반대로 아래 세 가지는 바로 도움이 됩니다.
- 요청 난이도/행동성 기반 tier 분류
- tier별 primary/fallback 체인
- tool/vision/context-length 조건에 따른 모델 필터
2. ClawRouter의 기본 모델 매핑을 그대로 가져오면 안 되고, 로빙 트래픽으로 다시 벤치마크해야 합니다
- ClawRouter의 티어 매핑은 BlockRun의 가격표, OpenClaw 사용 패턴, x402 결제 지연, 특정 유지율 가정 위에 놓여 있습니다.
- 로빙의 실제 요청은 슬랙 응답, 이메일 분석, RAG 요약, 내부 문서 질의, 스케줄·브리핑 등으로 구성돼 있어 분포가 다릅니다.
- 따라서 로빙에 필요한 것은 "ClawRouter의 모델 목록 복제"가 아니라 "로빙 요청 유형별 분류축과 비용·품질 벤치마크"입니다.
3. 로빙에는 ClawRouter 전체 도입보다 rb8001 공용 LLM 경로 앞단 라우터가 맞습니다
- 현재 로빙은 이미
rb8001 /api/llm/generate로 일부 수렴 중이므로, 가장 자연스러운 위치는 이 공용 경로의 앞단입니다. - 즉 구조는
skill-* -> rb8001 공용 LLM 호출 -> 라우터 -> provider adapter쪽이 맞습니다. - 이 방식이면 서비스별 직접 SDK 호출을 다시 늘리지 않고, 중앙 라우팅 정책만 독립 계층으로 키울 수 있습니다.
4. 1차 적용 범위는 "4티어 + 3~5개 검증 모델 + 명시적 폴백" 정도가 적절합니다
- ClawRouter처럼 처음부터 40개 이상 모델을 열면 운영 표면이 너무 넓어집니다.
- 로빙 1차는
SIMPLE / MEDIUM / COMPLEX / REASONING4티어만 두고, 각 티어별 1개 primary + 1~2개 fallback 정도가 적절합니다. - 이때 최소 검증 포인트는 아래가 적합합니다.
- 일반 응답용 저비용 모델
- 코드/분석용 상위 모델
- reasoning 전용 모델
- tool-calling 안정 모델
5. 로빙에 특히 유용한 부가 아이디어는 fallback, cache, context filter입니다
- fallback 체인은 현재 provider 장애나 429, 모델별 호환성 차이를 가시적으로 흡수할 수 있습니다.
- response cache와 dedup은 브리핑, 반복 질의, 재시도 경로에서 비용과 지연을 같이 줄일 수 있습니다.
- context-length-aware routing은 긴 내부문서/RAG 응답에서 "토큰 초과 후 실패"를 줄이는 데 직접 도움이 됩니다.
6. 반대로 ClawRouter의 세션 journal과 compression은 바로 이식하기보다 별도 검토가 필요합니다
- journal은 현재 로빙의 conversation log, 자기개선 루프, 메모리 방향과 일부 겹칩니다.
- compression도 provider별 시스템 프롬프트 처리 차이, 한국어 문맥 보존, RAG 근거 인용 품질에 미치는 영향을 따로 검증해야 합니다.
- 따라서 이 둘은 1차 적용 항목이 아니라 2차 검토 항목으로 두는 편이 맞습니다.
7. 결론적으로 ClawRouter는 "참고 가치 높음, 직접 채택 범위는 제한적"입니다
- 참고 가치가 높은 이유는
로컬 규칙 기반 분류 -> 티어별 모델 선택 -> 조건 기반 필터 -> 명시적 폴백을 실제 코드로 보여주기 때문입니다. - 직접 채택 범위가 제한적인 이유는 결제·지갑·OpenClaw 플러그인 UX가 로빙의 현재 운영 문제와 직접 맞닿지 않기 때문입니다.
- 따라서 로빙에는
ClawRouter식 멀티 LLM 라우팅 계층이 유효하고,ClawRouter 자체를 그대로 붙이는 것은 우선순위가 낮습니다.
Unresolved
- 로빙의 실제 요청 로그를 기준으로 티어 분류축을 어떻게 정의할지
- 1차 검증 모델 풀을 어떤 provider 조합으로 고정할지
rb8001 /api/llm/generate앞단에 둘지, 별도llm-router서비스로 분리할지- fallback 발생, savings, latency를 어떤 메트릭 스키마로 남길지
- response cache를 user/session/context hash 기준으로 둘지, 요청 body hash 기준으로 둘지
추천 다음 단계
plans문서에서rb8001 공용 LLM 경로 앞단 4티어 라우터1차 도입 범위를 고정합니다.- 지난 2주 운영 로그 기준으로 로빙 요청을
simple / medium / complex / reasoning / tool-using / long-context로 샘플링합니다. - 각 샘플에 대해 3~5개 후보 모델의 비용·지연·출력품질을 같은 프롬프트셋으로 비교해 로빙 전용 티어 매핑을 만듭니다.
- 1차 구현은
라우팅 + fallback + metrics까지만 두고,compression과journal은 2차로 분리합니다.
1차 자료 링크
- ClawRouter GitHub 저장소
- ClawRouter README
- ClawRouter Architecture
- ClawRouter 14-Dimension Classifier
- ClawRouter Features
- ClawRouter Plugin Manifest
한 줄 결론
- ClawRouter는 로빙에 그대로 붙일 제품이라기보다,
rb8001 공용 LLM 경로 앞단에 멀티 LLM 라우팅 계층을 세우는 방법을 보여주는 강한 벤치마크 대상입니다.