숨겨졌던 Claude Code 팀 모드 비밀 기능: 멀티 에이전트 CC Mirror 공개

CC Mirror(cc-mirror)를 “숨겨진 Claude Code 팀 모드(멀티 에이전트)” 근거로 GitHub 공식 문서/README + Team Mode/Task Storage/Workflows 문서를 기반으로 정리합니다.

CC Mirror가 “무엇을” 풀어줬나

핵심은 ‘새 툴’이 아니라, Claude Code에 이미 있던 팀 모드 기능을 “활성화+패키징”해 누구나 쓰게 만든 것입니다.

Claude Code 내부에 Task 기반 협업 도구(TaskCreate/Get/Update/List)가 존재하지만, 기본 상태에서는 비활성화되어 있었고
cc-mirror는 이를 켜서 “지휘자(Conductor) + 작업자(Workers)” 구조의 멀티 에이전트 오케스트레이션을 가능하게 합니다.

강조하는 포인트

“복잡한 브로커(MQ) 없이도 가능”
“작업 분해 + 의존성(blockedBy) 관리만으로 병렬 실행”

구조 한 장 요약: “Variant(격리 인스턴스) + Team Mode(Task 도구) + Orchestrator Skill”

Variant(완전 격리된 Claude Code 복제본)

cc-mirror는 Claude Code를 여러 개의 독립 실행 인스턴스(variant)로 “복제”해 씁니다. 각 variant는 아래를 완전히 분리합니다.

설정/세션/자격증명(키)
MCP 서버 구성
팀 모드 작업 저장소(tasks)
스킬(오케스트레이터 등)

300x250

README에 예시 디렉터리 구조가 명확히 있습니다.

~/.cc-mirror/<variant>/npm/ : Claude Code 설치본
~/.cc-mirror/<variant>/config/ : 키/세션/MCP/작업 저장소
~/.cc-mirror/<variant>/config/tasks/<team>/ : 팀 모드 task JSON 저장

Team Mode(숨겨진 기능의 “활성화” 방식)

Team Mode는 Claude Code의 cli.js 내부 함수의 반환값을 바꿔 Task 도구들이 노출되게 만드는 패치로 활성화된다고 문서화되어 있습니다. 또한 cc-mirror는 활성화 시 cli.js.backup을 만든다고 설명합니다.

Task 도구 4종 + Orchestrator Skill(지휘자 역할)

Team Mode가 켜지면 Claude가 사용할 수 있는 도구

TaskCreate : 작업 생성(제목/설명/의존성)
TaskGet : 작업 상세 조회
TaskUpdate : 상태 변경/코멘트/소유자/의존성 관리
TaskList : 작업 목록/요약 조회

그리고 cc-mirror는 “Conductor(지휘자)”처럼 작업 그래프를 만들고 병렬로 워커를 스폰하는 오케스트레이터 스킬을 포함한다고 설명합니다.

동작 원리: “작업 그래프(DAG) + blockedBy/blocks + 소유권(owner)”

Task는 로컬 JSON 파일로 저장됨

Team Mode는 Task를 variant별 로컬 디렉터리에 JSON 파일로 저장합니다.

위치: ~/.cc-mirror/<variant>/config/tasks/<team_name>/1.json, 2.json ...
파일명(예: 42.json) 자체가 Task ID가 됩니다.

Task JSON 필드(요지)

id, subject, description, status(open/resolved 등)
owner(누가 집었는지)
blockedBy(선행 작업) / blocks(후행 작업)
comments(진행 코멘트 로그)

의존성은 “양방향 링크”로 관리

Task2가 Task1에 의존하도록 blockedBy=["1"]를 넣으면, Task1에는 자동으로 blocks=["2"]가 들어가는 식의 양방향 링크가 된다고 문서화되어 있습니다.

“언블로킹”은 자동

Task1이 resolved가 되면, Task2의 blockedBy가 자동으로 정리되면서 Task2가 “바로 실행 가능한 상태”로 바뀌는 흐름이 정리되어 있습니다.

충돌 방지: owner(소유권) + team-lead 권한

TaskUpdate는 소유권 규칙을 두어 충돌을 줄입니다.

일반적으로 task owner만 업데이트 가능
예외적으로 CLAUDE_CODE_AGENT_TYPE=team-lead는 더 넓은 권한

설치/실행: “한 줄로 팀 모드 켠 Claude Code 만들기”

가장 빠른 시작(권장: Mirror Claude)

# 멀티 에이전트(팀 모드) Claude Code 생성
npx cc-mirror quick --provider mirror --name mclaude

# 실행(래퍼가 ~/.local/bin 등에 생성됨)
mclaude

이대로 하면 “팀 모드가 켜진 Claude Code variant”가 만들어진다고 README에 명시돼 있습니다.

다른 Provider(모델/비용/정책에 따라 선택)

# Z.ai
npx cc-mirror quick --provider zai --api-key "$Z_AI_API_KEY"

# MiniMax
npx cc-mirror quick --provider minimax --api-key "$MINIMAX_API_KEY"

# OpenRouter(모델 매핑)
npx cc-mirror quick --provider openrouter --api-key "$OPENROUTER_API_KEY" \
  --model-sonnet "anthropic/claude-sonnet-4-20250514"

# 로컬 라우팅(예: Ollama/DeepSeek 등)
npx cc-mirror quick --provider ccrouter

공식 README에 provider 예시가 그대로 있습니다. 또한 Mirror Claude는 프록시가 아니라 Anthropic API에 직접 연결하는 “순정 Claude + 기능만 강화” 컨셉을 강조합니다.

운영 핵심: 팀 스코프(프로젝트별 자동 격리) + TEAM으로 멀티 팀 운영

프로젝트 폴더 기반 자동 스코핑

같은 variant라도 현재 폴더(프로젝트)에 따라 team_name이 자동으로 달라져 작업이 섞이지 않게 설계돼 있습니다.

예시(문서의 공식 포맷)

<variant-name>-<project-folder>[-<TEAM>]

같은 프로젝트에서 backend/frontend/devops 팀을 분리하고 싶다면

TEAM=backend  mclaude
TEAM=frontend mclaude
TEAM=devops   mclaude

TEAM 환경변수로 같은 폴더에서 “서로 다른 작업 큐”를 만든다고 문서화되어 있습니다.

Task를 “사람이” 다루는 CLI(수동 관리/자동화의 핵심)

README에 정리된 task CLI 예시(자동화에 매우 유용)

npx cc-mirror tasks              # 열린 작업 목록
npx cc-mirror tasks --ready      # 실행 가능한(open + not blocked) 작업
npx cc-mirror tasks --json       # JSON 출력(자동화/수집용)
npx cc-mirror tasks show 18      # 상세 보기
npx cc-mirror tasks create       # 수동 작업 생성
npx cc-mirror tasks update 5 --status resolved
npx cc-mirror tasks graph        # 의존성 그래프 시각화

멀티 에이전트 “패턴” (언제 어떻게 쪼개야 성과가 나는가)

DeepWiki의 멀티 에이전트 워크플로우 문서는 대표 패턴을 4가지로 정리합니다.

Fan-Out (병렬 독립 작업)

서로 의존성 거의 없음 → 동시에 여러 워커가 처리
예: “로그 수집 파이프라인 3종 구현”, “버그 3개 병렬 수정”

Pipeline (순차 의존 작업)

반드시 1→2→3 순서 → blockedBy로 체인 구성
예: “DB 마이그레이션 → 모델 → API → 테스트”

Map-Reduce (병렬 조사 + 종합)

여러 영역을 병렬로 파서 조사(Map) 후, 리더가 종합(Reduce)
예: “코드베이스 전반 인증/인가 흐름 파악”, “보안 리뷰”

Speculative (대안 탐색)

“정답/최적해가 불명확”할 때 여러 접근을 병렬 실험 후 최종 선택

실전 예시 3종 (작업 그래프/명령/운영까지 “구체적으로”)

예시 1) “할 일 관리 REST API + 테스트”를 팀 모드로 병렬 구현

목표: todo API + 테스트 + 문서까지

리더(Conductor)가 작업을 쪼갭니다. (개념적으로 TaskCreate 연속 호출)

Task 1: DB 스키마/마이그레이션
Task 2: API 라우트/핸들러 (blockedBy: 1)
Task 3: 테스트 셋업/테스트 코드 (독립 또는 blockedBy:2로 설정 가능)
Task 4: README/사용법 문서

실행 가능한 작업만 워커가 가져가도록 “ready”를 봅니다.
```
npx cc-mirror tasks --ready
```
워커는 TaskList→TaskUpdate(owner=...)로 “집고”, 끝나면 resolved로 닫습니다. (문서의 표준 흐름)
Task 1이 resolved 되면 Task 2가 자동 언블록되어 바로 진행됩니다.

예시 2) “보안 점검 자동화(CIS 일부)”를 멀티 에이전트로 빠르게 만들기

목표: 점검 항목 정의 + 스크립트 + 결과 JSON + 리포트

권장 Map-Reduce + Pipeline 혼합. (문서에도 “하이브리드 패턴”이 소개됨)

(Map) Task A1: SSH 관련(Port/PermitRootLogin/PasswordAuthentication)
(Map) Task A2: 계정/패스워드 정책(pam, faillock, pwquality)
(Map) Task A3: 커널 파라미터(sysctl), 불필요 모듈
(Reduce) Task B: 결과 스키마 통합(JSON)
(Pipeline) Task C: 수집/전송(n8n webhook) + 리포트 템플릿

이 방식은 “조사/구현/통합”을 병렬화해 보안팀 업무에 특히 잘 맞습니다. (보안 리뷰/전사 점검은 Map-Reduce 적합 사례로 문서에 제시)

예시 3) 같은 프로젝트에서 “backend/frontend/devops” 멀티 팀으로 운영

목표: 한 저장소에서 작업 큐를 3개로 분리

# 같은 폴더에서 팀 큐 분리
TEAM=backend  mclaude
TEAM=frontend mclaude
TEAM=devops   mclaude

각 팀은 아래처럼 서로 다른 task 폴더를 쓰며 분리됩니다.

~/.cc-mirror/<variant>/config/tasks/<variant>-<project>-backend/
...-frontend/
...-devops/

보안 관점(매우 중요): 멀티 에이전트는 “생산성”만큼 “통제면”이 늘어납니다

여기서는 cc-mirror 문서에 실제로 적힌 저장/격리/제약을 기반으로, 보안팀이 바로 적용할 체크포인트로 정리합니다.

자격증명(키/세션) 관리

variant는 각자 config/세션/자격증명을 독립 보유합니다.
API Key/OAuth 토큰 저장 위치가 ~/.cc-mirror/<variant>/config/ 주변에 모이는지 확인
홈 디렉터리 백업/동기화(Drive/Dropbox 등) 환경이면 키 유출 리스크 증가
개발용/운영용 키를 variant로 분리(혼용 금지)

권장 가이드

최소권한 키(스코프 제한), 주기적 로테이션
variant 폴더 권한(umask, ACL) 점검

작업 데이터(Tasks)가 로컬 JSON으로 “그대로” 남음

Task가 1.json, 2.json…로 축적되며 자동 삭제가 없고 수동 정리 필요라는 제한이 문서에 명시돼 있습니다.
Task description/comments에 민감정보(토큰/내부URL/개인정보)가 들어가면 그대로 파일에 남음
파기 정책(예: resolved 30일 후 삭제) 필요

동시성/무결성: “No Locking” (레이스 컨디션 가능)

문서에 명확히 적혀 있습니다.

로컬만 저장, 네트워크 공유 없음, 자동 정리 없음, 파일 락 없음(동시 업데이트 충돌 가능)
워커 여러 개가 동일 task를 동시에 업데이트하지 않도록 owner/권한 활용
중요한 작업은 team-lead만 상태 변경 허용하는 운영 규칙 권장

9-4. 역할/권한 모델(팀리드 vs 워커)

TaskUpdate는 소유권 보호 규칙을 둡니다.

운영 권장안(예시)

CLAUDE_CODE_AGENT_TYPE=team-lead는 1~2명만
워커는 CLAUDE_CODE_AGENT_ID=worker-001처럼 고정 식별자 부여(감사 추적)

운영 템플릿(체크리스트)

도입 전(POC) 체크

데이터 경계

Task에 포함 금지: 고객정보/토큰/내부 비밀 URL/운영 계정정보

키/세션 저장 위치/권한

~/.cc-mirror 권한(600/700) 기본 점검

네트워크 정책

외부 LLM 사용 시 egress/프록시/로깅 정책 정합

파기 정책

task JSON 보관기간/삭제 절차 수립(자동화 포함)

운영 중 점검

npx cc-mirror tasks --json 출력 기반으로 “열린 작업/막힌 작업/장기 미해결” 모니터링
레이스 컨디션 리스크가 있으니 “owner 지정 + team-lead 승인” 흐름 유지

cc-mirror는 Claude Code를 ‘완전 격리된 복제본(variants)’으로 만들어 팀 모드(TaskCreate/Get/Update/List)를 활성화하고, 작업 그래프(의존성) 기반으로 백그라운드 워커들을 병렬로 돌려 복잡한 일을 빠르게 끝내는 멀티 에이전트 오케스트레이션 도구입니다. 다만 작업/코멘트가 로컬 JSON 파일로 남고, 자동 삭제/락이 없으며, variant별로 키/세션이 분산되므로 보안팀 기준의 운영통제가 필수입니다.

728x90

그리드형(광고전용)

저작자표시 비영리 동일조건 (새창열림)

pages.kr 날으는물고기 <º)))><

숨겨졌던 Claude Code 팀 모드 비밀 기능: 멀티 에이전트 CC Mirror 공개

숨겨졌던 Claude Code 팀 모드 비밀 기능: 멀티 에이전트 CC Mirror 공개

CC Mirror가 “무엇을” 풀어줬나

강조하는 포인트

구조 한 장 요약: “Variant(격리 인스턴스) + Team Mode(Task 도구) + Orchestrator Skill”

Variant(완전 격리된 Claude Code 복제본)

Team Mode(숨겨진 기능의 “활성화” 방식)

Task 도구 4종 + Orchestrator Skill(지휘자 역할)

동작 원리: “작업 그래프(DAG) + blockedBy/blocks + 소유권(owner)”

Task는 로컬 JSON 파일로 저장됨

의존성은 “양방향 링크”로 관리

“언블로킹”은 자동

충돌 방지: owner(소유권) + team-lead 권한

설치/실행: “한 줄로 팀 모드 켠 Claude Code 만들기”

가장 빠른 시작(권장: Mirror Claude)

다른 Provider(모델/비용/정책에 따라 선택)

운영 핵심: 팀 스코프(프로젝트별 자동 격리) + TEAM으로 멀티 팀 운영

프로젝트 폴더 기반 자동 스코핑

같은 프로젝트에서 backend/frontend/devops 팀을 분리하고 싶다면

Task를 “사람이” 다루는 CLI(수동 관리/자동화의 핵심)

멀티 에이전트 “패턴” (언제 어떻게 쪼개야 성과가 나는가)

Fan-Out (병렬 독립 작업)

Pipeline (순차 의존 작업)

Map-Reduce (병렬 조사 + 종합)

Speculative (대안 탐색)

실전 예시 3종 (작업 그래프/명령/운영까지 “구체적으로”)

예시 1) “할 일 관리 REST API + 테스트”를 팀 모드로 병렬 구현

예시 2) “보안 점검 자동화(CIS 일부)”를 멀티 에이전트로 빠르게 만들기

예시 3) 같은 프로젝트에서 “backend/frontend/devops” 멀티 팀으로 운영

보안 관점(매우 중요): 멀티 에이전트는 “생산성”만큼 “통제면”이 늘어납니다

자격증명(키/세션) 관리

작업 데이터(Tasks)가 로컬 JSON으로 “그대로” 남음

동시성/무결성: “No Locking” (레이스 컨디션 가능)

9-4. 역할/권한 모델(팀리드 vs 워커)

운영 템플릿(체크리스트)

도입 전(POC) 체크

운영 중 점검

댓글

티스토리툴바

숨겨졌던 Claude Code 팀 모드 비밀 기능: 멀티 에이전트 CC Mirror 공개

숨겨졌던 Claude Code 팀 모드 비밀 기능: 멀티 에이전트 CC Mirror 공개

CC Mirror가 “무엇을” 풀어줬나

강조하는 포인트

구조 한 장 요약: “Variant(격리 인스턴스) + Team Mode(Task 도구) + Orchestrator Skill”

Variant(완전 격리된 Claude Code 복제본)

Team Mode(숨겨진 기능의 “활성화” 방식)

Task 도구 4종 + Orchestrator Skill(지휘자 역할)

동작 원리: “작업 그래프(DAG) + blockedBy/blocks + 소유권(owner)”

Task는 로컬 JSON 파일로 저장됨

의존성은 “양방향 링크”로 관리

“언블로킹”은 자동

충돌 방지: owner(소유권) + team-lead 권한

설치/실행: “한 줄로 팀 모드 켠 Claude Code 만들기”

가장 빠른 시작(권장: Mirror Claude)

다른 Provider(모델/비용/정책에 따라 선택)

운영 핵심: 팀 스코프(프로젝트별 자동 격리) + TEAM으로 멀티 팀 운영

프로젝트 폴더 기반 자동 스코핑

같은 프로젝트에서 backend/frontend/devops 팀을 분리하고 싶다면

Task를 “사람이” 다루는 CLI(수동 관리/자동화의 핵심)

멀티 에이전트 “패턴” (언제 어떻게 쪼개야 성과가 나는가)

Fan-Out (병렬 독립 작업)

Pipeline (순차 의존 작업)

Map-Reduce (병렬 조사 + 종합)

Speculative (대안 탐색)

실전 예시 3종 (작업 그래프/명령/운영까지 “구체적으로”)

예시 1) “할 일 관리 REST API + 테스트”를 팀 모드로 병렬 구현

예시 2) “보안 점검 자동화(CIS 일부)”를 멀티 에이전트로 빠르게 만들기

예시 3) 같은 프로젝트에서 “backend/frontend/devops” 멀티 팀으로 운영

보안 관점(매우 중요): 멀티 에이전트는 “생산성”만큼 “통제면”이 늘어납니다

자격증명(키/세션) 관리

작업 데이터(Tasks)가 로컬 JSON으로 “그대로” 남음

동시성/무결성: “No Locking” (레이스 컨디션 가능)

9-4. 역할/권한 모델(팀리드 vs 워커)

운영 템플릿(체크리스트)

도입 전(POC) 체크

운영 중 점검

관련글

댓글

티스토리툴바