Magpie VS CC Switch: 내 settings.json은 두 사람을 동시에 사랑할 수 없다

작성자 주: magpie와 CC Switch는 모두 내 컴퓨터의 Agent 설정 파일을 수정해요. 이 글에서는 아키텍처, 릴리스 주기, 기능 차이, 적합한 사용자층을 비교하고, 왜 설정을 작성하는 프로그램은 둘 중 하나만 남겨야 하는지 설명해요.

~/.claude/settings.json의 처지가 요즘 좀 난처해요. CC Switch는 1년 넘게 이 파일을 관리하면서 공급자를 바꿀 때 연결 관련 필드만 수정하고 나머지는 그대로 뒀어요. 그런데 magpie도 이 파일에 설정을 쓰면서 접속 주소를 127.0.0.1:3425로 바꿔요. 두 프로그램이 같은 파일을 수정하면 마지막에 저장한 내용이 적용되고, 앞선 수정 사항은 아무런 알림 없이 덮어써져요. 따라서 이 설정 파일은 한 번에 한 프로그램만 관리해야 해요.

두 프로젝트의 릴리스 주기도 크게 달라요. 2026-10-28 기준으로 magpie의 릴리스 저장소는 2026-09-23에 만들어진 이후 누적 릴리스 번호가 1,000을 넘었어요. 2026-10-27 하루에만 GitHub API에서 87개의 릴리스를 확인할 수 있어요. 반면 CC Switch는 v3.19.0(2026-07-30)부터 v4.0.21(2026-10-26)까지 석 달 동안 정식 버전 30개를 출시했고, 버전마다 중국어 릴리스 노트를 제공했어요. magpie는 영어로 까치라는 뜻인데, 이 까치는 하루에도 수십 번씩 업데이트 소식을 전하는 셈이에요.

커뮤니티에서 magpie에 대한 평가도 엇갈려요. linux.do에는 2026-10-10에 「magpie는 쓰기 너무 복잡해요. CC Switch에 익숙하다면 갈아타는 건 추천하지 않아요」라는 제목의 글이 올라왔어요. 다음 날에는 「다들 왜 magpie를 추천하나요? 설치해 봤는데 뭐가 더 좋은지 모르겠어요」라는 글도 올라왔고요. CC Switch가 대체될까 걱정하는 사람도 있지만, 저희의 결론은 대체되지는 않겠지만 magpie가 일부 사용자를 가져간 것은 사실이라는 거예요.

이 글은 설치 가이드가 아니에요. 어느 쪽이 전반적으로 더 낫다고 판정하기보다, 두 접근 방식의 차이를 살펴보고 어떤 프로그램을 남길지 판단할 수 있도록 도와드릴게요.

Magpie VS CC Switch 출시 주기: 하루 수십 개 패키지 vs 3개월간 30개 버전

두 프로젝트의 차이가 가장 뚜렷한 출시 주기부터 살펴볼게요. magpie의 버전은 0.1.x에 머물러 있지만, 패치 번호는 빠르게 올라가고 있어요. 2026-10-03 13:00부터 10-04 14:00까지 25시간 동안 v0.1.756에서 v0.1.859까지 정확히 100개 버전이 출시됐어요. 2026-10-28 기준 최신 버전은 v0.1.1801이에요. GitHub API는 릴리스 기록을 최대 1,000개까지만 반환하므로 더 오래된 기록은 확인할 수 없으며, 전체 릴리스 수도 계속 늘어나고 있어요.

이 릴리스 번호의 성격은 짚고 넘어갈 필요가 있어요. 자동 빌드로 생성되는 패치 번호로, 거의 모든 커밋마다 패키지가 하나씩 나와요. 기능을 1,000번 업그레이드했다는 뜻은 아니에요. 이 주기는 두 가지를 보여줘요. 유지보수가 활발하고 문제 수정이 빠르다는 점, 그리고 0.1.x가 여전히 빈번하게 시행착오를 거치는 단계라 높은 안정성을 기대하기는 어렵다는 점이에요.

지표（2026-10-28 기준）	magpie	CC Switch
저장소 생성일	2026-09-23	2025-08-04
최신 버전	v0.1.1801	v4.0.21（2026-10-26）
출시 주기	하루 최대 87개 확인, 누적 1,000개 이상	3개월간 정식 버전 30개
GitHub star	약 2.38만 개	약 14.9만 개
지원 도구	README에 Agent 68개 명시	도구 12개, 각각 전용 프리셋 제공
유지보수 방식	외부 PR은 받지 않고 유지보수자만 생성 가능	issue / PR을 통한 협업 허용

star 14.9만 개와 하루 패키지 100개라는 수치를 나란히 놓고 보면 두 프로젝트가 서로 다른 단계에 있다는 걸 알 수 있어요. CC Switch는 이미 방대한 사용자층을 확보했고, magpie는 아직 빠르게 개선을 거듭하고 있어요. 어느 쪽이 더 부지런한지가 아니라 팀의 작업 주기와 위험을 감수하는 정도가 다른 거예요. CC Switch 제작자는 4.0을 재구성하면서 과거 issue 500여 개를 닫았다고 밝혔어요. magpie는 한 달여 만에 star가 약 2.38만 개로 늘었지만, 인기와 안정성은 따로 살펴봐야 해요.

한 가지 더 있어요. APIYI 문서 사이트의 CC Switch 페이지（docs.apiyi.com 사용 시나리오 튜토리얼）에는 여전히 v3.12.0과 도구 5개가 적혀 있어요. 도구 12개와 v4.0.21을 안내하는 공식 저장소보다 정보가 오래됐으니, 버전은 GitHub를 기준으로 확인하세요.

Magpie VS CC Switch 핵심 차이: 설정 파일을 바꿀까, 로컬 게이트웨이를 거칠까

두 도구의 가장 큰 차이는 접근 방식이에요. CC Switch는 Agent 중심이고, magpie는 게이트웨이 중심이에요.

CC Switch는 전환할 때 각 도구의 설정 파일에서 요청 주소, Key, 모델 등 연결 필드만 바꿔요. 플러그인, Hook, MCP, 직접 추가한 설정과 주석은 그대로 유지하고, 처음 수정하기 전에는 원본 파일을 자동으로 백업해요. Claude Code, Codex, Gemini CLI는 「전환형」으로, 한 번에 하나의 공급자만 활성화돼요. OpenCode, OpenClaw, Hermes, Pi는 「공존형」으로, 여러 공급자를 도구 자체 설정에 함께 기록해요. CC Switch에도 로컬 라우팅 기능이 있지만 직접 활성화해야 해요. 활성화하면 Anthropic Messages, OpenAI Chat Completions, OpenAI Responses, Gemini Native 간 프로토콜을 변환할 수 있고, 장애 조치 대기열과 서킷 브레이커도 제공해요.

반면 magpie는 먼저 각 Agent의 접속 주소를 127.0.0.1:3425로 통일하고, 키를 magpie에 집중 저장한 다음 게이트웨이를 통해 업스트림으로 요청을 전달해요. 게이트웨이는 네 가지 프로토콜 간 상호 변환을 지원하며, 스트리밍 출력, 도구 호출, 추론 내용도 변환할 수 있어요. magpie 역시 Agent 자체 설정의 핵심 필드를 수정해요. README에서는 “magpie edits the one key that matters in the agent’s own config”라고 설명하며, 원자적 쓰기를 사용해 주석과 순서, 형식을 유지해요. 설정 파일을 수정하고 싶지 않다면 OPENAI_BASE_URL, ANTHROPIC_BASE_URL, GOOGLE_GEMINI_BASE_URL을 로컬 게이트웨이로 지정하고 Key에 magpie를 입력하면 돼요.

비교 항목	magpie	CC Switch
역할	로컬 게이트웨이 + 전환 도구	데스크톱 설정 관리자 + 선택적 로컬 라우팅
전환 방식	요청이 `127.0.0.1:3425`를 거쳐 전송됨	각 도구 설정의 연결 필드를 수정
계정 장애 대응	라우팅 그룹의 다섯 가지 모드 + 다중 계정 장애 조치 + Daily warm-up	장애 조치 대기열 + 서킷 브레이커 + 상태 모니터링
일상 관리	Library: 지침, MCP, skills, subagent를 한 번만 작성	MCP 패널 + Skills + 프롬프트 라이브러리 + 세션 관리자
세션	목록에 매번 발생한 비용을 표시하고 터미널에서 원클릭으로 다시 열기	구조화된 내용으로 파싱, 대화 턴 요약, 내보내기 및 복원 명령
실행 환경	데스크톱, TUI, CLI, Web UI, Docker, Termux	데스크톱 + 트레이

magpie의 강점: 라우팅, 장애 대응과 마이그레이션

magpie가 사용자에게 매력적인 이유는 다음과 같아요.

낮은 마이그레이션 비용: 공급업체 페이지의 Import 기능으로 CC Switch의 공급업체를 바로 가져올 수 있어 몇 분이면 마이그레이션이 끝나요. CC Switch에 가장 직접적인 영향을 주는 기능이에요.
라우팅 그룹: group/daily-coding처럼 그룹을 하나의 모델로 만들어 에이전트에 제공할 수 있어요. 그룹 내에서는 smart, order, rotate, usage, pace의 다섯 가지 모드를 지원해요. 캐시를 활용할 가치가 있는 세션은 처음 응답한 계정에 유지돼요.
구독을 공급업체로 활용: 로그인한 Claude, ChatGPT, Copilot 등의 구독을 다른 에이전트가 사용할 수 있는 공급업체로 설정할 수 있어요. 이 기능은 개인정보 설정에서 끌 수 있어요.
개인정보 마스킹: 키, 토큰, 이메일 등의 정보를 로컬에서 플레이스홀더로 바꾼 뒤 전송해요. 기본적으로 꺼져 있으며, 활성화한 후 마스킹이 적용되어야 하는데 적용되지 않으면 원문을 보내지 않고 503을 반환해요.
로컬 네트워크 공유와 배포: 클라이언트마다 별도의 게이트웨이 키를 발급하고 지출 한도를 설정할 수 있어요. Docker를 이용해 NAS에서 실행할 수도 있어요.

CC Switch의 강점: 더 세심한 일상 관리

CC Switch는 일상적인 관리 기능이 더 세심해요.

MCP 통합 패널: 도구별로 동기화할 항목을 선택하고, 각 도구에서 기존 설정을 가져올 수 있어요.
Skills 관리: GitHub이나 ZIP 파일에서 클릭 한 번으로 설치하고, 전체 항목을 한 번에 업데이트할 수 있어요.
프롬프트 라이브러리: 활성화하면 CLAUDE.md / AGENTS.md에 프롬프트를 기록해요. 그전에 파일의 기존 내용은 프롬프트 라이브러리에 저장해요.
세션 관리자: 각 대화 턴을 한 줄 요약으로 접어 보여주고, 실패한 단계는 빨간색으로 표시해요. 복구 명령을 복사해 대화를 이어갈 수도 있어요.
프로젝트 스냅샷: 공급업체, MCP, Skills, 프롬프트를 프로젝트별로 한꺼번에 전환할 수 있어요.

v4.0.21에는 여러 Claude 공식 구독 계정 간 전환 기능도 추가됐어요. 로그인은 공식 절차를 따르고, 토큰은 Claude Code 자체 저장 위치에만 보관돼요. CC Switch는 토큰을 기록하거나 업로드하지 않으며, 사용량 한도에 따라 계정을 자동으로 순환하지도 않는다고 명시해요. magpie와는 정반대의 보수적인 설계예요.

도구는 요청만 전달해요: Magpie와 CC Switch에 필요한 모델과 API 키

어떤 도구를 선택하든 역할은 요청을 전달하는 것뿐이에요. 모델과 API 키는 별도로 준비해야 하며, 원활하게 사용하려면 안정적으로 이용할 수 있는 claude-opus-5-5 API 키가 필요해요. APIYI(apiyi.com)는 Anthropic 호환 엔드포인트와 OpenAI 호환 엔드포인트를 모두 제공하므로 두 도구에서 바로 연결할 수 있어요.

연결 항목	입력 내용	설명
Anthropic 호환 주소	`https://api.apiyi.com`	`/v1`을 붙이지 않으며, Claude Code에 적합
OpenAI 호환 주소	`https://api.apiyi.com/v1`	Codex 등 OpenAI 프로토콜을 사용하는 도구에 적합
모델명	`claude-opus-5-5`	thinking 버전인 `claude-opus-5-5-thinking`도 가격 동일
가격(백만 토큰당)	입력 $4 / 출력 $20 / 캐시 읽기 $0.2	2026-10-28 기준이며, 모델과 가격은 플랫폼의 모델 목록을 확인
엔드포인트와 그룹	chat, messages; ClaudeCode, Default, SVIP 등 그룹	용도에 맞게 그룹 선택

두 도구가 동일한 에이전트 설정을 읽는다는 점에 유의하세요. CC Switch는 API 키를 ~/.claude/settings.json에 저장하고, Magpie는 게이트웨이에 저장하지만, 최종적으로는 같은 상위 계정에 연결돼요. 따라서 API 키는 APIYI 콘솔에서 한 번만 변경하면 되고, 잔액과 사용량도 한곳에서 확인할 수 있어요. 두 도구에 각각 입력할 필요는 없어요.

Magpie VS CC Switch 상황별 추천: 누구에게 무엇이 맞을까?

CC Switch를 계속 쓰는 게 좋은 사람

주로 Claude Code를 사용하고, 공급자가 한두 곳뿐이며, 안정성을 중시한다면 CC Switch가 더 잘 맞아요. 업그레이드할 때마다 문제를 살펴볼 필요도 적죠. 설정을 변경하는 범위가 작고 백업 기능도 잘 갖춰져 있어, 문제가 생기면 설정 파일을 열어 원인을 확인할 수 있어요. MCP, Skills, 프롬프트를 자주 정리하거나 이전 대화를 다시 살펴보는 사용자에게도 CC Switch의 화면과 사용 방식이 더 익숙할 거예요.

10월 10일 게시글 작성자는 이렇게 말했어요. “공급자들이 뒤섞여 있어서 굳이 이걸로 바꿀 필요가 없어요. 너무 복잡하고, 더 불편한 건 이 소프트웨어에서 모델을 선택하면 CLI에서 다시 바꿀 수 없다는 거예요.” 같은 글에서 “아직 CCS를 압도할 만한 고유 기능은 느끼지 못했다”는 의견도 나왔어요. 클릭 한 번으로 공급자를 바꾸고 싶은 사용자라면 CC Switch로도 충분해요.

magpie로 바꾸면 좋은 사람

Codex, Gemini CLI, OpenCode, Pi 등 여러 에이전트를 함께 사용하고, 구독과 API 키도 여러 개라면 magpie의 게이트웨이 방식이 더 잘 맞아요. 사용량 한도에 도달했을 때 자동으로 전환하고 비용 대시보드도 확인할 수 있기 때문이에요. 같은 날 한 게시글에는 이런 의견이 올라왔어요. “오후에야 ccswitcg에서 magpie로 갈아탔는데, 드디어 중계 서비스를 하나씩 테스트하지 않아도 되네요.” 10월 11일 게시글에서도 “magpie가 ccs보다 추가와 전환이 편하고 라우팅 규칙도 강력하다”는 의견이 있었어요. CC Switch를 Codex 앱에서 사용할 때 모델을 제대로 표시하거나 전환할 수 없다는 사용자도 있었고요.

magpie에 대한 부정적인 피드백은 구분해서 봐야 해요. magpie를 연결한 뒤 Claude 캐시가 제대로 작동하지 않는 것 같고 비용이 늘었다는 사용자가 있었어요. 또 다른 사용자는 중간 계층에 프롬프트 검열이 추가된 것으로 의심되며, 그 때문에 요청이 거부됐다고 말했어요. 두 사례 모두 단일 제보이며 재현 방법은 확인되지 않았어요. 따라서 이를 근거로 magpie에 해당 문제가 있다고 단정할 수는 없어요. 이 글의 정보는 프로젝트의 공식 설명, 제3자의 단일 제보, 아직 결론이 나지 않은 내용으로 나뉘니 각각 구분해서 봐주세요.

Magpie VS CC Switch 선택 가이드: 다섯 가지 상황별 추천

사용 상황	추천	이유
Claude Code만 쓰고, 공급자가 한두 곳이며 안정성이 중요함	CC Switch	변경 범위가 작고 백업 기능이 있으며, 3개월간 정식 버전 30개를 출시할 만큼 업데이트 주기가 안정적임
여러 Agent와 계정을 쓰며 자동 장애 대응과 비용 대시보드가 필요함	magpie	라우팅 그룹 + 페일오버 + 사용량 통계
MCP, Skills, 프롬프트, 세션 검색이 주된 고민임	CC Switch	관리 패널이 더 세밀하고 세션 분석 기능이 더 완전함
로컬 네트워크 공유, NAS 실행, 미지원 Agent의 프로토콜 변환이 필요함	magpie	게이트웨이와 Docker 배포를 지원함
둘 다 사용하고 싶음	한 프로그램만 설정을 쓰도록 지정	다음 섹션 참고

💡 선택 팁: 어떤 도구를 고를지 모르겠다면 같은 키로 두 도구를 각각 반나절씩 사용해 보세요. CC Switch 연결 방법은 APIYI 튜토리얼 docs.apiyi.com/scenarios/programming/cc-switch에서, magpie 통합 게이트웨이 연결 방법은 help.apiyi.com/magpie-unify-claude-code-codex-pi-hermes-api-gateway.html에서 확인할 수 있어요. 처음부터 혼자 알아볼 필요 없이 튜토리얼을 따라 설정하면 됩니다.

동시 설치 시 주의점: settings.json은 한 프로그램만 관리해야 해요

처음의 질문으로 돌아가 볼게요. magpie와 CC Switch는 ~/.claude/settings.json, ~/.codex/config.toml처럼 같은 파일을 수정해요. 두 도구를 동시에 실행한 상태에서 한쪽의 공급자를 전환하면, 다른 쪽 설정이 아무런 알림 없이 덮어써져요. 이후 Claude Code가 실제로 사용할 공급자는 마지막으로 설정을 쓴 도구에 따라 달라집니다.

두 도구를 함께 쓰려면 설정 파일을 누가 관리할지 정해야 해요. 한 도구가 쓰기를 담당하고, 다른 도구는 읽기만 하거나 사용 후 종료하는 방식입니다. 예를 들어 CC Switch로 MCP와 프롬프트를 관리하고 공급자 전환은 magpie에 맡기거나, 반대로 역할을 나눌 수 있어요. 두 프로그램이 계속 각자 설정을 쓰게 해서는 안 됩니다. 이전할 계획이라면 magpie의 Import 기능으로 CC Switch의 공급자를 가져온 뒤, 정상적으로 이전됐는지 확인하고 기존 도구를 종료하세요.

위험과 계정 차단은 본인 책임: Magpie와 CC Switch 모두 먼저 백업하세요

다음 사항을 미리 알아두세요.

두 도구 모두 서드파티 오픈소스 도구이며 MIT 라이선스를 사용해요. 둘 다 로컬 Agent의 설정 파일을 수정하므로, 설치 전에 ~/.claude/settings.json, ~/.codex/config.toml 등을 직접 백업하세요. 도구의 자체 백업에만 의존하지 않는 편이 좋아요.
공식 클라이언트 외부에서 구독을 사용하면 약관 위반 위험이 있어요: Claude, ChatGPT, Copilot 구독을 공식 클라이언트 밖에서 사용하면 서비스 제공자의 약관을 위반할 수 있어요. CC Switch 문서에도 비슷한 안내가 있습니다. magpie의 「구독을 공급자로 사용」 기능은 Settings → Privacy에서 끌 수 있어요.
결과는 사용자가 책임져야 해요: 설정 덮어쓰기, 사용 한도 손실, 계정 위험 등의 결과는 사용자 본인의 책임이며, 이 글은 어느 쪽도 보증하지 않아요. 먼저 보조 계정이나 중요도가 낮은 프로젝트에서 시험해 보세요.

자주 묻는 질문 FAQ

Q1: Magpie와 CC Switch를 동시에 설치할 수 있나요?

동시에 설치할 수는 있지만, 동시에 설정을 쓰면 안 돼요. 두 도구가 같은 `~/.claude/settings.json` 파일을 수정하므로, 하나만 쓰기를 담당하고 다른 하나는 읽기 전용으로 사용하거나 종료해야 해요.

Q2: magpie는 한 달여 만에 수천 개 버전이 출시됐는데, 불안정한가요?

대부분 자동 빌드로 생성된 패치 버전으로, 유지보수가 활발하고 수정도 빠르다는 뜻이에요. 다만 0.1.x는 아직 시행착오를 겪는 단계라, 안정성이 중요하다면 조금 더 지켜보는 편을 권해요.

Q3: magpie를 쓰면 캐시가 무효화되고 비용이 늘어날 수 있나요?

현재는 소수의 사용자만 보고한 사례이고 재현 방법도 없어 결론을 내릴 수 없어요. 걱정된다면 전환 전후의 사용량 대시보드를 비교해 직접 확인해 보세요.

Q4: 도구를 바꾸면 API 키를 다시 발급받아야 하나요?

아니요. 두 도구 모두 요청을 전달할 뿐이므로 기존 API 키를 그대로 쓸 수 있어요. APIYI apiyi.com 콘솔에서 관리하는 동일한 키를 CC Switch나 magpie에 입력하면 돼요.

Q5: claude-opus-5-5에는 어떤 주소를 입력해야 하나요?

Claude Code는 Anthropic 프로토콜을 사용하므로 `/v1`이 없는 주소를 입력하세요. Codex처럼 OpenAI 프로토콜을 사용하는 도구에는 `/v1`이 포함된 주소를 입력하면 돼요. 2026년 10월 28일 기준 가격은 100만 토큰당 입력 $4, 출력 $20, 캐시 읽기 $0.2이며, 자세한 내용은 apiyi.com 모델 목록을 확인하세요.

Q6: magpie가 CC Switch를 대체할까요?

그렇지 않아요. 두 도구는 역할이 달라요. CC Switch는 에이전트의 설정을 관리하고 전환하며, magpie는 모든 요청이 로컬 게이트웨이를 먼저 거치도록 해요. 주로 영향을 받는 쪽은 「클릭 한 번으로 provider만 바꾸면 되는」 CC Switch 사용자예요.

Magpie VS CC Switch 핵심 요약

접근 방식이 달라요: CC Switch는 설정 파일을 수정하고, magpie는 요청을 로컬 게이트웨이 127.0.0.1:3425로 먼저 보내요.
출시 속도가 달라요: 2026-10-28 기준으로 magpie의 누적 릴리스 번호는 1,000개를 넘었고, CC Switch는 3개월 동안 정식 버전 30개를 출시했어요.
각자의 강점이 있어요: magpie는 라우팅, 장애 대응, 프로토콜 변환에 강하고, CC Switch는 MCP, Skills, 세션 관리에 강해요.
동시에 설정 파일을 수정할 수 없어요: 두 도구가 같은 settings.json을 수정하므로 하나의 도구만 쓰기 권한을 가져야 해요.
부정적인 피드백은 대부분 개별 사례예요: 캐시나 검열 등에 관한 피드백에는 재현 방법이 없어 결론으로 받아들이기 어려워요.
키는 한 번만 관리하면 돼요: APIYI 콘솔에서 키를 한 번에 교체하면 두 도구 모두 같은 Agent 설정을 읽어요.

정리

magpie와 CC Switch의 차이는 결국 접근 방식의 차이예요. 하나는 게이트웨이를 중심으로 빠르게 개선하고, 다른 하나는 Agent 설정을 중심으로 꾸준히 완성도를 높여요. magpie는 ‘클릭 한 번으로 provider만 바꾸고 싶은’ 사용자들의 선택을 받았고, CC Switch는 일상적인 관리 기능에서 여전히 더 세심해요. 커뮤니티의 논쟁은 당분간 이어지겠지만, 개인 사용자의 선택은 비교적 간단해요.

~/.claude/settings.json은 한 번에 하나의 프로그램만 관리할 수 있어요. 앞서 살펴본 다섯 가지 사용 시나리오에 맞춰 도구 하나를 고르고 계속 사용하면 돼요. 두 도구를 번갈아 쓸 필요는 없어요.

모델과 키는 APIYI apiyi.com에서 준비할 수 있어요. 같은 키로 claude-opus-5-5에 접속하므로 어떤 도구를 선택해도 바로 사용할 수 있어요.

📚 참고 자료

magpie GitHub 저장소: 로컬 통합 AI 게이트웨이 및 모델 전환 도구
링크: github.com/yetone/magpie
설명: README에 68개 에이전트 목록과 게이트웨이 설명이 있으며, 중국어 버전은 README.zh-CN.md에서 확인할 수 있어요.
magpie 공식 문서: 기능 및 설정 안내
링크: usemagpie.ai/docs
설명: 라우팅 그룹, 개인정보 마스킹, 로컬 네트워크 공유 등 기능을 자세히 설명해요.
CC Switch GitHub 저장소: 크로스 플랫폼 올인원 관리 도구
링크: github.com/farion1231/cc-switch
설명: 릴리스 노트와 수정 내역을 확인할 수 있어요. 버전 정보는 이 저장소를 기준으로 해요.
CC Switch 공식 사이트: 제품 소개 및 다운로드
링크: ccswitch.io
설명: 지원 도구 목록과 사용 방법을 확인할 수 있어요.

작성자: APIYI 기술팀
기술 문의: APIYI 웹사이트 홈페이지에서 문의할 수 있어요. 더 많은 연동 자료는 docs.apiyi.com 문서 센터에서 확인하세요.

Magpie VS CC Switch: 내 settings.json은 두 사람을 동시에 사랑할 수 없다

Magpie VS CC Switch 출시 주기: 하루 수십 개 패키지 vs 3개월간 30개 버전