왜 “스위처"가 필요해졌나

Claude Code 가 2024년 말 등장한 직후만 해도 사용량 캡은 거의 의식되지 않았다. 그게 바뀐 건 2025-08-28 이다. Anthropic 이 Pro / Max 플랜에 5시간 롤링 윈도우 + 7일 weekly cap 이중 제한을 도입한 날이다. Max 5x ($100/mo) 와 Max 20x ($200/mo) 도 weekly 캡에서 자유롭지 않다.

cap 에 걸리면 두 가지 길이 있다.

  1. 그 주가 끝날 때까지 기다린다
  2. 다른 프로바이더로 옮긴다 — Z.AI 의 GLM Coding Plan, Moonshot 의 Kimi, OpenRouter 의 300개 모델 중 하나, 또는 로컬 Ollama

옮기는 일 자체는 어렵지 않다. Claude Code 가 환경변수 두 개 — ANTHROPIC_BASE_URL 와 ANTHROPIC_AUTH_TOKEN — 만 보고 동작하기 때문이다. 예를 들어 GLM 으로 옮기는 건 Z.AI 공식 가이드 기준 두 줄.

export ANTHROPIC_BASE_URL="https://api.z.ai/api/anthropic"
export ANTHROPIC_AUTH_TOKEN="..."

다른 프로바이더(Kimi, DeepSeek 등) 도 같은 패턴이지만 정확한 Anthropic-호환 엔드포인트 URL 은 각 프로바이더 공식 문서를 직접 확인 해야 한다 — 같은 회사라도 OpenAI-호환 엔드포인트(/v1)와 Anthropic-호환 엔드포인트가 다르고, 후자가 잘못 표기된 글이 인터넷에 흔하다.

문제는 하루에 셋·넷씩 갈아타게 되는 순간이다. 회사 계정 / 개인 계정 / GLM / 로컬 모델 / 임시 OpenRouter — 매번 셸 변수를 바꾸고, 헷갈려서 회사 계정으로 사이드 프로젝트를 돌리고, 캡이 어디서 깎이는지 까먹는다. 이 지점에서 등장한 도구가 CCS (Claude Code Switcher) 다.

CCS 한 줄 요약

@kaitranntt/ccs — Kai Tran(카이 트란) 이 만든 Claude Code 용 멀티 프로바이더·멀티 계정 프로필 매니저. MIT 라이선스, npm 패키지, GitHub ★2.2k, 2026-04-29 기준 v7.75.0 (721 릴리즈, 3,687 커밋. 매우 활발).

홈페이지: https://ccs.kaitran.ca/ 저장소: https://github.com/kaitranntt/ccs

자기 소개는 한 문장이다.

The multi-provider profile and runtime manager for Claude Code and compatible CLIs. — config 파일 갈아엎지 말고, 활성 세션 깨지 않으면서, 몇 초 안에 프로바이더를 옮겨라.

무엇을 지원하나

설치는 한 줄.

npm install -g @kaitranntt/ccs
# 또는
bun add -g @kaitranntt/ccs

ccs config 한 번 돌려 초기 설정 후, 프로필 단위로 사용한다.

명령라우팅
ccs기본값 — Claude Sonnet 4.6
ccs glmZ.AI GLM-5.1 (API 또는 Coding Plan)
ccs kimiMoonshot Kimi (1M context)
ccs geminiGemini 3 Pro/Flash (OAuth)
ccs codexGPT-5.4 / Codex (OAuth)
ccs ollama로컬 Ollama 모델
ccs work / ccs personal같은 Claude 라도 계정 격리
ccs --target droid glmruntime 자체를 Factory Droid 로 바꾸고 모델은 GLM

지원 프로바이더는 점점 늘어 현재 다음을 포함한다.

  • Claude (Sonnet 4.6, Opus 4.6) — 공식
  • GLM-5.1, GLM-5-Turbo, GLM-4.7 — Z.AI
  • Kimi K2.5 — Moonshot
  • Gemini 3 Pro/Flash — Google (OAuth)
  • GPT-5.4 / Codex — OpenAI (OAuth)
  • Antigravity Pro/Turbo — ccs agy (OAuth)
  • OpenRouter — 300+ 모델 한 번에
  • Ollama, llama.cpp, Novita, Alibaba Coding Plan 등 로컬·OpenAI-호환 모두

어떻게 동작하나 — 추상화 한 겹의 정체

CCS 의 핵심은 두 가지 컴포넌트다.

1. 로컬 Anthropic-호환 프록시 GLM·Kimi 처럼 이미 Anthropic-호환 엔드포인트를 제공하는 프로바이더는 단순 패스스루. 그렇지 않은 OpenAI-호환 프로바이더(OpenRouter, DeepSeek 등)는 로컬 프록시가 요청 / 응답을 변환해 Claude Code 가 자기 형식대로 받게 만든다.

2. CLIProxyAPI (OAuth 프록시 백엔드) Gemini, Codex, Antigravity 같은 공식 API 키가 없는 OAuth 기반 프로바이더 는 별도 프록시 컴포넌트가 처리한다. 라운드로빈 / fill-first 같은 토큰 관리 정책도 여기서. 커뮤니티 fork(CLIProxyAPIPlus) 도 옵트인으로 사용 가능.

활성화 방식: eval "$(ccs proxy activate)" 같이 셸에 평가시켜 ANTHROPIC_BASE_URL, ANTHROPIC_AUTH_TOKEN 을 그 세션 한정으로 주입한다. 다음 셸 / 다음 디렉토리에서는 다시 깨끗.

# CCS 가 한 번에 처리하는 것
$ ccs glm "이 PR 리뷰해줘"
# 내부적으로:
#  1. ~/.ccs/profiles/glm.settings.json 읽기
#  2. ANTHROPIC_BASE_URL=https://api.z.ai/api/anthropic 주입
#  3. ANTHROPIC_AUTH_TOKEN=$GLM_KEY 주입
#  4. claude code 호출

겉으로는 한 줄이지만 안쪽에서는 수동 env 셋과 같은 일을 프로필이라는 단위로 캡슐화한 셈이다.

장점 — 어디서 가치가 나오나

1. 한 명령 = 한 프로파일 — 회사 Claude / 개인 Claude / GLM / Kimi / 로컬 — 5개를 셸 변수 갈아끼우지 않고 명령 하나로 분리한다.

2. 멀티 계정 격리 — ccs work 와 ccs personal 이 같은 머신에서 동시에 다른 Claude 세션을 돌릴 수 있다. weekly cap 도 따로 깎인다.

3. OAuth + API 두 방식 통합 — Z.AI 처럼 API 키 발급해서 쓰는 곳, Gemini 처럼 OAuth 로 가는 곳, 로컬 Ollama 까지 같은 명령 표면 위로 올라온다.

4. 시나리오 라우팅 — proxy.routing 설정으로 “긴 컨텍스트는 Kimi, 추론은 Claude, 백그라운드는 GLM” 식의 자동 라우팅 가능.

5. 비주얼 대시보드 — config 파일을 손으로 안 만져도 프로필 추가·수정. 한국에서 GLM Coding Plan 처럼 결제·키 발급 자체가 약간 번거로운 프로바이더를 쓸 때 편하다.

6. 활발한 개발 — 721 릴리즈, 평균 거의 매일 업데이트. 새 프로바이더가 나오면 빠르게 흡수된다.

7. 비용 절감 클레임 — 공식 페이지는 “Save $500–1000/month with strategic delegation” 이라 적는다. 검증은 본인 워크로드에 따라 다르지만, 무거운 보일러플레이트는 GLM($10–30/mo) 으로 돌리고 설계만 Claude Max 로 가는 패턴이 실제로 cap 부담을 크게 줄인다.

단점·주의사항 — 솔직히 적기

1. 추상화가 두껍다 — 프록시 두 단계(로컬 + CLIProxyAPI) 가 끼어들고, 각 프로바이더마다 라우팅 룰이 따로 산다. “내 요청이 어디로 갔지?” 가 헷갈리는 순간이 생긴다. 로그(~/.ccs/logs/) 를 켜둘 가치가 있다.

2. 버전 업이 매우 빠르다 — v7.75.0, 721 릴리즈. 이 속도는 새 프로바이더 흡수에는 좋지만 “내 환경에서 안정적인 v7.x” 같은 보수적 운영에는 부담이다. lockfile 로 고정 권장.

3. CLIProxyAPI 라는 외부 의존 — 핵심 기능 일부가 별도 프로젝트에 묶여 있다. 그 쪽 이슈가 CCS 동작에 직결될 수 있다.

4. Anthropic 공식 API 만 쓸 거면 오버킬 — 다른 프로바이더 안 쓰고 회사·개인 두 계정만 격리하는 거라면, direnv 나 .envrc 같은 더 가벼운 도구가 충분하다. CCS 는 옮겨다닐 곳이 셋 이상 부터 의미 있다.

5. OAuth 우회는 ToS 회색지대 — Codex, Antigravity 같은 비공개 OAuth 프로바이더를 우회로 쓰는 건 각 서비스 이용약관 위반 소지가 있다. 회사 환경에서 쓸 때는 한 번 확인하는 게 안전하다.

6. 한국에서 GLM/Kimi 결제 자체가 별도 작업 — Z.AI Coding Plan 은 분기 결제(분기당 $30–80), Moonshot Kimi 는 위안화 결제. CCS 가 결제까지 해결해주지는 않는다.

7. weekly cap 회피 도구로 광고되지만 — Anthropic 입장에서 보면 “한 사람이 멀티 계정 돌려 cap 돌파” 패턴이 쌓이면 정책이 다시 조여질 수 있다. 도구의 책임은 아니지만 시장 동학을 의식할 가치는 있다.

한국 커뮤니티 반응 — 긱뉴스 / 스레드 신호

CCS 자체에 대한 긱뉴스(news.hada.io) 단일 글은 (작성 시점 기준) 아직 없지만, CCS 같은 도구가 왜 등장했는지를 보여주는 신호는 긱뉴스에 풍부하다.

스레드(Threads) 쪽에서는 한국어 사용자들이 비슷한 도구를 다양하게 시도 중이라는 점이 눈에 띈다 — vibe proxy 로 Claude Code + AntiGravity + GLM 라이드 매핑, oh-my-opencode(★9K) 가 Kimi K2.5 + GLM 5 를 메인 오케스트레이터로 튜닝, free-claude-code 가 NVIDIA NIM 무료 API 로 Claude Code 를 무료 운영 — 한국 개발자들이 프록시 + 멀티 프로바이더 라는 패턴 자체에 적극적으로 베팅하고 있다는 의미다. CCS 는 그 흐름의 가장 잘 정리된 도구 중 하나.

대안 비교

CCS 만 있는 게 아니다. 같은 영역에 여러 도구가 경쟁 중이다.

도구별강점약점
CCS (kaitranntt)★2.2kOAuth 프록시 + GUI 대시보드 + 활발한 업데이트추상화 두꺼움, 의존성 복잡
claude-code-router (musistudio)★33.2k시나리오 라우팅(background/think/longContext), 토큰 임계값 자동 전환, JS 플러그인OAuth 미지원
cc-switch (farion1231)(데스크톱)데스크톱 GUI, Claude Code/Codex/OpenCode/Gemini 통합CLI 친화도 낮음
claude-code-switch (foreveryh)(소규모)미니멀, 한 명령으로 Anthropic 모델만 전환Anthropic 외 미지원
OpenCode (opencode.ai)(별도 트리)75+ 프로바이더, 완전 오픈, Claude Code 호환 인터페이스자체 CLI 라 Claude Code 그대로는 아님
DIY (.zshrc 두 줄)—의존성 없음, 가장 투명함프로필 3개 넘어가면 관리 불가

선택 가이드:

  • API 키 기반 프로바이더 2개 이내 + 라우팅 욕심 → claude-code-router. 별 수도 가장 많고 시나리오 라우팅이 가장 강하다.
  • OAuth 프로바이더 끼고 멀티 계정 → CCS. 이 영역 거의 유일.
  • 데스크톱 친화 + 멀티 툴 통합 GUI → cc-switch.
  • Anthropic 만, 단순함 우선 → DIY 또는 claude-code-switch.

시나리오: 회사 Team + Enterprise 두 계정만 쓴다면

CCS 가 풀려는 문제가 프로바이더 다양화 와 OAuth 우회 라면, Anthropic 만 쓰면서 회사 계정 두 개(Team + Enterprise) 만 격리하는 시나리오는 정확히 그 두 핵심 가치가 빠진 케이스다. 이때는 도구 선택이 달라진다.

이 시나리오의 본질은 한 가지로 줄어든다 — 두 ANTHROPIC 계정 사이 빠른·정확한 전환. 다른 프로바이더, 시나리오 라우팅, 로컬 모델 모두 무관.

추천 우선순위:

  1. direnv ⭐ — 프로젝트 디렉토리 기반 자동 전환. .envrc 에 export ANTHROPIC_API_KEY=... 한 줄을 두 회사 디렉토리에 각각 두면 cd 만으로 자동 로드. 실수로 한 회사 코드에 다른 회사 키가 가는 사고를 디렉토리 경계로 차단 — 이 시나리오에서 가장 큰 리스크가 그것이고, direnv 가 그 리스크를 가장 깔끔히 푼다.

  2. 셸 alias — 가장 단순. ~/.zshrc 에 두 줄.

    alias cct='ANTHROPIC_AUTH_TOKEN=$TEAM_TOKEN claude'
alias cce='ANTHROPIC_AUTH_TOKEN=$ENT_TOKEN claude'

    디렉토리에 묶이지 않아 빠르지만, 어느 회사 컨텍스트인지 사람이 기억해야 함.

  3. claude-code-switch (foreveryh) — Anthropic 전용 미니멀 스위처. CCS 보다 가볍고 이 시나리오에 정확히 맞춰져 있음.

  4. CCS 의 멀티-계정 모드만 — ccs auth create team / ccs auth create ent 두 프로필. 동작은 한다. 다만 CCS 의 95% 기능(프로바이더 다양화, 프록시, OAuth)을 쓰지 않으면서 의존성·복잡도는 그대로 가져가는 셈. 추후 GLM 같은 외부 프로바이더로 확장할 가능성이 있을 때만 CCS 를 미리 깔아두는 의미가 있다.

Enterprise 가 SSO 강제인 경우: 단순 API 키 토글 도구가 안 통하고 OAuth 로그인 사이클이 필요하다. 이때는 direnv 만으로 부족하고, CCS 의 OAuth 프로필 분리 또는 Anthropic Console 의 organization 스위처를 써야 한다. 이 한 가지가 CCS 를 정당화하는 거의 유일한 회사-시나리오 케이스.

한 줄 결론: API 키 기반 두 계정이면 direnv 면 충분. SSO 강제 + 잦은 전환이면 CCS. 그 외는 CCS 가 오버엔지니어링.

설정·대화는 공유하면서 계정만 분리하고 싶다면

같은 시나리오의 변종 — 두 회사 계정을 전환은 하되, 슬래시 커맨드·MCP·hooks·CLAUDE.md·대화 히스토리는 한 군데에서 공유하고 싶은 경우. 정답이 다르다.

먼저 Claude Code 가 무엇을 어디 두는지 알면 답이 나온다.

위치무엇계정 종속?
~/.claude/settings.json사용자 설정 (theme, env, hooks 트리거 등)❌ (계정 무관)
~/.claude/commands/, agents/, skills/커스텀 슬래시 커맨드·에이전트·스킬❌
~/.claude/CLAUDE.md글로벌 메모리❌
~/.claude/projects/<path-hash>/*.jsonl대화 히스토리 (프로젝트 경로 기준)❌
OS 키체인 / ANTHROPIC_AUTH_TOKEN인증 토큰✅

핵심은 계정 종속은 토큰 한 가지뿐 이라는 점이다. 즉 토큰만 갈아끼우면 나머지는 자동으로 공유된다. 따라서 정답:

  1. direnv 로 토큰만 스위칭 — .envrc 에 export ANTHROPIC_AUTH_TOKEN=... 한 줄만. ~/.claude/ 는 그대로 두고 토큰만 디렉토리별로 바꾼다. 슬래시 커맨드, hooks, MCP, 대화 — 전부 자동 공유.

  2. CCS 의 isolated profile 모드는 피해야 한다 — ccs auth create work 같은 isolated profile 은 정확히 이 공유 자체를 분리 한다. CCS 자체는 쓸 수 있지만 isolation 옵션은 끄고 토큰만 바꾸는 모드로만 사용.

  3. 여러 머신 간에도 공유하려면 dotfiles — ~/.claude/ 를 git 으로 관리. 한 머신에서 만든 슬래시 커맨드가 회사 노트북·집 데스크톱에서 같이 동작. 단, settings.json 안에 토큰이 평문으로 들어가지 않게 주의 (.gitignore 에 settings.local.json 등록).

Enterprise 데이터 격리 주의 — Enterprise 플랜의 약관에 따라 대화 데이터를 다른 organization 환경과 섞으면 안 되는 조항이 있을 수 있다. 특히 PII·고객 데이터·비공개 코드를 다루는 프로젝트라면 ~/.claude/projects/ 를 공유하는 것이 회사 보안 정책 위반일 수 있다. 사내 보안팀에 한 번 확인하는 게 안전하다. 정책 위반 우려가 있으면 프로젝트 디렉토리 자체를 회사별로 분리 해서 자연히 다른 <path-hash> 로 떨어뜨리는 패턴이 가장 깔끔하다 (예: ~/work/team/, ~/work/ent/ 두 루트).

한 줄: 설정·대화 공유는 토큰만 바꾸면 디폴트로 된다. 분리하는 도구를 굳이 끌어들이면 그게 오히려 깨는 일.

SSO 강제 환경 — 한국 회사 현실에 더 가까운 케이스

위 두 서브섹션은 API 키를 사용자가 직접 발급받을 수 있다 는 전제 위에 있다. 그런데 국내 대기업·금융권·보안 민감 조직 대부분은 그 전제 자체가 깨져 있다. Team/Enterprise 플랜에서 SSO를 강제하면 사용자 API 키 발급이 비활성화되고, 인증은 OAuth + IdP MFA 사이클로만 가능하다. 이 환경에서는 도구 선택이 다시 한 번 달라진다.

먼저 구조를 짚으면:

  1. claude login → 브라우저 → 회사 IdP 로그인 (SSO + MFA) → Anthropic Console → 토큰 발급
  2. 토큰은 OS 키체인 또는 ~/.claude/.credentials.json 에 저장
  3. 토큰은 보통 시간 제한이 있고 (몇 시간~며칠), 만료되면 다시 SSO 사이클
  4. 한 머신의 한 OS 유저는 동시에 한 organization 의 세션 만 보유 가능

즉 SSO 강제 환경에서 두 회사 organization 사이를 전환 하려면 본질적으로 logout → login(다른 org) → 다시 작업 사이클을 돌아야 한다. 이건 도구가 우회할 수 있는 영역이 아니다 — IdP 가 매번 MFA 를 요구한다.

실용적으로 동작하는 패턴들 (현실적 운영 순):

  1. 하나의 organization 만 쓰는 게 답인 경우 — 가장 많은 케이스. 회사가 Enterprise 한 개를 표준화했고 Team 은 레거시·POC 였다면 굳이 둘 다 유지할 가치가 없다. 이게 가장 깔끔한 결론. 회사 IT 에 정리 요청.

  2. 두 organization 이 같은 Anthropic Workspace 안의 서로 다른 workspace — Enterprise 안에서 admin 이 workspace 를 분리해 운영하면 organization 전환 없이 claude /switch-workspace 같은 in-session 전환이 가능. 이게 가능한지부터 회사 IT 에 확인. 가능하면 가장 매끄럽다.

  3. 두 organization 이 진짜 별개인 경우 — OS 유저 분리 — 같은 노트북에 두 OS 계정을 만들어 각각 SSO 로그인 상태를 독립 보유. 키체인이 자연히 분리되고 ~/.claude/ 도 분리된다. 단점: 설정·대화 공유가 깨짐. dotfiles 를 두 OS 유저 간에 공유하는 추가 작업이 필요.

  4. CCS 의 OAuth 프로필 분리 — ccs auth create work-team / ccs auth create work-ent 두 OAuth 프로필. 이론상 이 시나리오에 정확히 맞는다. 다만 회사 IdP 가 Anthropic 의 OAuth 흐름에 어떤 추가 검증 (IP 화이트리스트, 디바이스 트러스트, MFA 빈도)을 거는지 에 따라 CCS 가 토큰을 캐시하는 방식이 IdP 정책과 충돌할 수 있다. 시도해 보기 전엔 모른다 가 솔직한 평가. 사내 보안팀과 사전 협의 권장.

  5. VM / 컨테이너 격리 — 두 회사용 Dev Container 또는 VM 을 따로 띄워 각각 한 organization 으로 로그인. 가장 보수적·안전. 단점: 무겁고 호스트 키체인 활용 불가.

SSO 환경에서 동작하지 않는 패턴들:

  • direnv + ANTHROPIC_AUTH_TOKEN 토글 — 사용자 API 키 자체가 없으니 토글할 게 없다.
  • 셸 alias 로 토큰 swap — 같은 이유.
  • “session 토큰을 추출해서 재사용” — 만료가 짧고 IdP 가 디바이스 핑거프린팅으로 거부할 가능성. ToS 회색지대.
  • 두 organization 의 ~/.claude/.credentials.json 을 수동으로 백업/복구 — 동작은 할 수 있지만 MFA 빈도 정책 을 우회하는 모양새가 되어 정책 위반 우려.

한국 회사 현실에 맞는 결론 한 줄: SSO 강제면 organization 전환 자체가 비용이 크다 는 사실을 인정하고, 두 organization 을 동시에 자주 오가지 않는 워크플로우 자체 를 설계하는 게 정답. 오전엔 Team org 에서 한 덩어리, 오후엔 Enterprise org 에서 다른 덩어리 — 식의 시간 분할이 도구로 매끄럽게 만드는 것보다 운영 부담이 훨씬 적다. 도구는 그 다음 문제다.

실전 팁 9가지

블로그 / GitHub 이슈 / 본 도구 README 의 패턴을 종합해 한국 환경에서 바로 쓸 만한 팁만 모았다.

1. 시나리오별 모델 분리 — 가장 큰 가치는 라우팅 자동화가 아니라 자기 워크플로우에 맞는 분리다. 권장 시작점:

  • 설계·아키텍처: ccs (Claude Sonnet)
  • 보일러플레이트·테스트 정리: ccs glm
  • 1M 컨텍스트 필요한 대규모 리뷰: ccs kimi
  • 민감 코드: ccs ollama (로컬)

2. 회사·개인 계정은 무조건 격리 — ccs auth create work / ccs auth create personal. weekly cap 이 섞이지 않아 둘 다 마음 편히 쓸 수 있다.

3. shell eval 영구화 — 매번 eval 치기 싫으면 ~/.zshrc 에 한 줄.

[[ -s "$HOME/.ccs/init.zsh" ]] && source "$HOME/.ccs/init.zsh"

4. weekly cap 스마트 보존 — Claude Max 의 weekly cap 이 60% 이상 깎였으면 그 주 남은 작업의 70% 정도는 GLM 으로 돌리는 룰을 자기 안에 정해두면 cap 이 끊기는 사고가 사라진다.

5. 1M 컨텍스트 작업은 Kimi — Claude Sonnet 4.6 이 1M 컨텍스트를 지원하지만 토큰 가격이 비싸다. 큰 monorepo 전체 리뷰는 ccs kimi 한 번이 훨씬 싸다.

6. 로컬 Ollama 로 prompt 디버깅 — 새 prompt 가 안정적인지 확인할 때, 첫 5–10번은 ccs ollama 로 무료 반복하다가 만족스러우면 Claude 로 옮겨도 된다.

7. 라우팅 룰은 단순하게 시작 — proxy.routing 의 시나리오 라우팅을 처음부터 복잡하게 짜면 어디로 갔는지 못 따라간다. 모델 직접 지정 → 일주일 운용 → 패턴 보이면 그때 룰 추가.

8. CLIProxyAPIPlus fork 옵션 인식 — 기본 CLIProxyAPI 가 못 잡는 프로바이더를 옵트인 fork 가 잡아주는 경우가 있다. 새 프로바이더 추가 안 되면 fork 활성화부터 시도.

9. 로그 켜기 — CCS_LOG=debug ccs glm "..." 식으로 한번 돌려보면 어느 base URL 로 갔는지, 어느 토큰을 썼는지 정확히 보인다. 멀티 계정 사고 디버깅 시 필수.

한 줄로

CCS 는 Claude Code 가 환경변수 두 개로 정의되는 도구라는 사실을 그대로 받아들인 도구다. 그 두 변수를 프로파일 이라는 단위로 정리하고, OAuth 우회와 다중 계정까지 한 명령 표면 위로 올려놓았다. weekly cap 시대에 한 프로바이더에만 의지하는 게 부담스러워진 사용자에게 기본기에 가까운 도구가 됐고, 같은 영역에 claude-code-router 같은 더 큰 별 수의 경쟁자도 있다. 자기 워크플로우가 옮겨다닐 곳이 셋 이상 인지부터 보고, 그 다음에 도구를 고르는 순서가 맞다.

→ 다음 편: Claude Code Switcher (CCS) 2편 — 디렉토리·설정·라우팅의 실제 — 사용자 머신의 ~/.ccs/ 를 직접 들여다보며 instance / shared 격리 모델, config.yaml 의 9개 영역, 로컬 프록시의 5단계 변환을 풀어 봅니다.

참고