DOCS/journey/research/260322_ClawRouter_멀티LLM_라우팅_적용성_리서치.md
2026-03-22 22:57:33 +09:00

12 KiB

tags
tags
research
robeing
llm
routing
ClawRouter
OpenClaw
cost-optimization

ClawRouter 멀티 LLM 라우팅 적용성 리서치

관련 문서

목적

  • 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.md14 weighted dimensions, 46 models를 말합니다.
  • openclaw.plugin.jsonskills/clawrouter/SKILL.md41+ 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.jsonskills/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.envDEFAULT_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 / REASONING 4티어만 두고, 각 티어별 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 기준으로 둘지

추천 다음 단계

  1. plans 문서에서 rb8001 공용 LLM 경로 앞단 4티어 라우터 1차 도입 범위를 고정합니다.
  2. 지난 2주 운영 로그 기준으로 로빙 요청을 simple / medium / complex / reasoning / tool-using / long-context로 샘플링합니다.
  3. 각 샘플에 대해 3~5개 후보 모델의 비용·지연·출력품질을 같은 프롬프트셋으로 비교해 로빙 전용 티어 매핑을 만듭니다.
  4. 1차 구현은 라우팅 + fallback + metrics까지만 두고, compressionjournal은 2차로 분리합니다.

1차 자료 링크

한 줄 결론

  • ClawRouter는 로빙에 그대로 붙일 제품이라기보다, rb8001 공용 LLM 경로 앞단에 멀티 LLM 라우팅 계층을 세우는 방법을 보여주는 강한 벤치마크 대상입니다.

상위 원칙