Claude Code 병렬 작업: worktree, 에이전트, 워크플로

에이전트 병렬 작업에 관한 실용 자료: Ailoot 문서.

이 가이드는 실무 경험과 도구를 어디에 적용할지 보여 주는 지도를 함께 제공합니다. Claude Code의 공식 구성 요소 네 가지, 적용 분야 지도, 그리고 바이브 코더에게 실제로 필요한 병렬 에이전트 수를 판단하는 과장 방지 프레임워크를 다룹니다. 모든 수치와 인용은 Anthropic의 1차 자료를 출처로 합니다.

Claude Code의 멀티 에이전트란 무엇이며, 왜 “에이전트 1000개”가 아닌가#

멀티 에이전트 구성에서는 작업을 여러 개의 독립적인 작업 흐름으로 나누고, 각 흐름이 자기 몫을 처리한 뒤 결과를 반환합니다. 가장 간단한 예를 들어 보겠습니다. 같은 컴퓨터에서 Claude Code 창 하나로 프런트엔드를 작성하고 다른 창으로 백엔드를 작성하며, 두 세션이 git 저장소를 공유합니다. “오케스트레이션”이라는 표현은 불필요하더라도 이것만으로 이미 멀티 에이전트입니다.

조금 더 복잡한 구성에서는 Claude Code 세션 하나 안에서 서로 다른 역할의 서브에이전트 다섯 개(프런트엔드 개발자, 백엔드 개발자, 보안 검토자, 테스터, 문서 작성자)를 실행하고, 각자가 결과의 자기 몫을 공유 대화에 반환합니다. 제어 지점은 하나지만 같은 멀티 에이전트 방식입니다.

더 복잡한 예로 Claude에게 “내 프로젝트의 파일 500개 전체를 매주 보안 감사해”라고 하면, Claude가 JavaScript 오케스트레이터 스크립트를 작성합니다. 런타임은 백그라운드에서 에이전트 수십 개를 시작하고, 각 에이전트가 자기 구역을 감사합니다. 이어 독립 에이전트들이 서로의 발견 사항을 확인하고, 최종 보고서 하나가 반환됩니다. 이것이 Anthropic이 2026년 5월 28일 공개한 Dynamic Workflows입니다. 기능을 자세히 살펴보려면 Dynamic Workflows 별도 가이드를 참조하세요.

이 세 시나리오의 차이는 에이전트 수가 아닙니다. 다음 에이전트가 무엇을 할지 누가 결정하는가가 다릅니다. 첫 번째 시나리오에서는 사용자입니다. 두 번째에서는 대화가 진행되면서 Claude가 결정합니다. 세 번째에서는 Claude가 작성한 JavaScript 스크립트가 결정합니다.

참고로 “에이전트 1000개”는 실제 수치입니다. Claude Code의 단일 Dynamic Workflow에 허용되는 상한입니다. Anthropic 공식 문서는 다음과 같이 설명합니다.

다시 말해 이는 통제 불능 동작을 막는 기술적 보호 장치이지 권장 작업량이 아닙니다. 실제로는 작업의 95%를 병렬 작업 흐름 2–8개로 처리할 수 있습니다. 더 많이 계획하고 있다면, 먼저 각각 무엇을 할지 스스로에게 물어보세요.

Claude Code의 네 가지 구성 요소: 서브에이전트, 스킬, 에이전트 팀, 워크플로#

Claude Code에는 하나의 작업을 여러 에이전트에 나누는 공식 구성 요소가 네 가지 있습니다. Anthropic은 이를 Dynamic Workflows 문서의 비교표에 모아 두었습니다. 쉬운 말로 비교하면 다음과 같습니다.

각 구성 요소는 서로 다른 문제를 해결합니다. 서브에이전트는 한 작업 안에서 2–3가지 검사를 위임할 때 사용합니다. 스킬은 Claude가 따라야 하는 지침이 이미 있을 때(예: “이 체크리스트를 사용해 PR을 검토하라”) 적합합니다. 제품의 여러 부분이 다른 창에 있고 조정자가 필요하다면 에이전트 팀을 사용합니다. 작업이 하나의 컨텍스트 창에 담기에는 너무 크다면 워크플로를 사용합니다.

서브에이전트에 대한 자세한 내용은 Claude Code 서브에이전트 2026 가이드를 참조하세요. 특정 작업에 무엇을 사용할지 결정하는 방법은 스킬, 서브에이전트, MCP, 플러그인 가이드에 있습니다. 이 가이드는 git worktree를 기반으로 멀티 에이전트 구성을 만드는 방법을 설명합니다.

레벨 1: 한 세션의 서브에이전트 — 가장 쉬운 시작점#

서브에이전트는 작업을 나누는 가장 간단한 방법입니다. 주 대화가 조정자 역할을 하고, 서브에이전트는 작업 진행 중 주 에이전트가 시작하는 임시 작업자입니다.

설명한 프로젝트의 구체적인 예를 들어 보겠습니다. 가이드 초안을 처음 작성한 뒤 다음과 같이 검토합니다. Claude에게 “서브에이전트 여섯 개를 병렬로 실행해. 하나는 AI 생성 흔적, 두 번째는 법률 용어, 세 번째는 문체와 어조, 네 번째는 WebFetch로 사실 확인, 다섯 번째는 SEO 구조, 여섯 번째는 내부 링크의 정확성을 확인해”라고 요청합니다. 각자 보고서를 반환하고 나면 수정 사항을 적용합니다.

기술적으로는 역할과 도구를 설명하는 .claude/agents/[subagent-name].md 파일을 사용합니다. 주 대화에서 Agent 도구를 통해 호출합니다. 서브에이전트에 요청을 보낼 시점은 Claude가 결정합니다.

잘 맞는 경우. 하나의 결과물(코드, 글, 디자인)을 3–7가지 방식으로 병렬 검토하는 작업입니다. 각 검사는 독립적이고, 결과는 주 컨텍스트 창에 담깁니다.

한계가 생기는 경우. 파일이 50개 이상이거나 검사마다 50K 토큰 컨텍스트가 필요하면 주 창이 가득 찹니다. 워크플로나 에이전트 팀이 필요합니다.

주요 위험. 서브에이전트마다 토큰을 별도로 소비합니다. 200개 파일 프로젝트에서 서브에이전트 여섯 개를 시작하고 각자가 200개 파일 전부를 다시 읽으면 비용은 6×가 됩니다. 따라서 서브에이전트가 확인할 파일을 정확히 지정해야 합니다. 자세한 내용은 Claude Code에서 토큰이 소비되는 곳 가이드를 참조하세요.

레벨 2: git worktree — 병렬 세션 간 파일 격리#

서브에이전트만으로 부족해 서로 다른 터미널에서 같은 저장소를 작업하는 완전한 Claude Code 인스턴스 두 개가 필요해지면 고전적인 문제가 생깁니다. 둘이 같은 파일을 편집하기 시작하고, 한쪽이 먼저 저장하면 다른 쪽이 그 내용을 덮어씁니다. 지난주 한 고객은 지원팀에 “5개가 동시에 서로의 작업을 덮어쓰고 있어요”라고 말했습니다.

해결책은 git worktree입니다. 저장소의 .git을 공유하면서 각자 별도의 브랜치에서 작업하는 여러 작업 복사본을 만들 수 있는 git 내장 기능입니다. 원본은 하나, 디스크상의 디렉터리는 서로 다르며 파일이 겹치지 않습니다. 작동 방식은 Claude Code에서 Git worktree 사용 가이드에 자세히 설명되어 있습니다.

5분 설정에 필요한 명령:

# 주 프로젝트 디렉터리에서
cd ~/projects/my-app

# feature/auth용 worktree 생성
git worktree add ../my-app-auth feature/auth

# feature/billing용 worktree 생성
git worktree add ../my-app-billing feature/billing

# 터미널 창 두 개 열기
cd ~/projects/my-app-auth && claude   # 첫 번째 Claude Code
cd ~/projects/my-app-billing && claude # 두 번째 Claude Code

각 복사본은 자체 브랜치에 있습니다. 각 Claude Code 인스턴스는 자기 디렉터리에 씁니다. 작업이 끝나면 해당 브랜치에서 git push를 실행한 다음 git worktree remove ../my-app-auth를 실행합니다.

알아둘 점. worktree는 node_modules, .venv 또는 .gitignore에 포함된 다른 파일을 복제하지 않습니다. 브랜치마다 독립적인 의존성(각 브랜치에서 다른 라이브러리 버전)이 필요하면 worktree add 이후 새 디렉터리에서 npm install을 별도로 실행하세요.

개발자당 worktree 수. 2026년 팀 설문을 바탕으로 보면 개발자 한 명당 병렬 worktree 4–8개가 현실적인 상한입니다. 제한 요소는 Claude가 아니라 결과를 검토하고 받아들일 수 있는 사람의 능력입니다. worktree가 10개라면 검토를 기다리게 됩니다.

설명한 실무에서는 보통 병렬 worktree 2–3개를 사용합니다. 진행 중인 작업용 주 worktree 하나, 긴급 수정용 예비 worktree 하나, 실험용 worktree 하나(확신이 없는 새 기능)입니다. 더 많이는 필요하지 않습니다.

레벨 3: 에이전트 팀 — 여러 창과 리드 에이전트 하나#

에이전트 팀은 비교적 새로운 구성 요소입니다. 리드 에이전트 하나가 작업 목록으로 공유 계획을 관리하고, 별도 창에서 작동하는 여러 동료 세션이 리드가 할당한 작업을 맡습니다. 모두 같은 파일시스템을 사용하므로 서로의 중간 결과물을 볼 수 있습니다.

작업이 몇 시간씩 걸리는 큰 작업 흐름 3–5개로 나뉠 때 유용합니다(대형 모듈 마이그레이션, 하위 시스템 재작성, 전체 보안 감사). 이 경우 리드 에이전트는 모든 worktree 밖의 절대 경로에 공유 작업 파일 하나를 유지합니다. 작업자는 그 경로를 읽고 결과를 보고하며 상태 수정은 리드만 담당해 조정 파일의 쓰기 충돌을 피합니다.

기술적으로 에이전트 팀은 git worktree 위에서 여러 창이 공유 계획 지점을 갖고 실행되는 방식입니다. 실제로는 80%의 사람이 위에서 설명한 worktree 방식으로 에이전트 팀을 수동 관리하며 특별한 “팀 프레임워크”를 쓰지 않습니다. 그것도 충분합니다.

프레임워크가 필요한지 확신이 없다면, 거의 확실히 필요하지 않은 것입니다. 수동 worktree와 주 디렉터리의 리드 에이전트 하나를 사용하세요.

레벨 4: Dynamic Workflows — Claude가 JS 오케스트레이션 스크립트를 작성#

앞의 세 레벨에서는 계획을 대화에 둡니다. 주 에이전트의 머릿속에 두거나 리드 에이전트의 작업 목록에 둡니다. Dynamic Workflows는 계획을 코드로 옮깁니다. Claude가 작업을 JavaScript 스크립트로 표현하고 런타임은 이를 격리된 환경에서 실행합니다. 중간 결과는 컨텍스트가 아니라 스크립트 변수에 저장되며, 에이전트가 백그라운드에서 작업하는 동안 세션은 계속 반응합니다.

공식 문서에 나오는 구체적인 예입니다. 다음과 같이 말합니다.

ultracode: audit every API endpoint under src/routes/ for missing auth checks

Claude는 대략 다음 로직을 가진 JavaScript 스크립트를 작성합니다. “src/routes/에서 파일을 전부 가져와 endpoint 30개씩 그룹으로 나누고, 각 그룹에 동일한 검사를 수행하는 에이전트를 실행한 다음, 결과를 검토할 독립 평가 에이전트 두 개를 실행하고 최종 보고서 하나로 통합한다.” 스크립트가 실행되고, 결과 표와 확실히 검토해야 하는 endpoint 목록을 받습니다.

잘 맞는 작업:

• 보안, 타입 지정, 지원 중단된 API 등 하나의 문제에 대해 프로젝트 전체를 감사하는 작업.
• 공통 규칙을 적용하는 대규모 마이그레이션(파일 500개 이상).
• 여러 독립적인 관점에서 확인해야 하는 조사 질문(Anthropic은 내장 /deep-research 명령에서 이를 사용합니다).

Dynamic Workflows와 그 한계, ultracode의 작동 방식에 대한 자세한 분석은 Claude Code의 Dynamic Workflows 별도 가이드를 참조하세요.

사용하지 말아야 할 때. 작업이 선형적이고 명확할 때입니다. “이 컴포넌트를 완성해” 같은 작업에는 워크플로가 필요 없습니다. 작업이 독립적인 하위 작업 10개 이상으로 나뉘고 서로 교차 검증해야 할 때 워크플로가 적합합니다.

주요 한계. 워크플로는 일반 세션보다 훨씬 많은 토큰을 소비합니다. Anthropic은 문서에서 다음과 같이 권장합니다.

다시 말해 첫 워크플로는 프로젝트 전체가 아니라 디렉터리 하나에서 실행하세요. 비용을 확인한 다음 규모를 키울 가치가 있는지 결정하세요.

Outcomes: 기준표와 독립 검토자#

멀티 에이전트 작업에서 가장 위험한 것은 에이전트의 결과를 신뢰하는 것입니다. 각 에이전트는 완성된 작업처럼 보이는 텍스트를 반환합니다. 인용은 사실처럼 보이고, 보고서는 완성된 것 같으며, 마이그레이션은 끝난 듯합니다. 에이전트 하나라면 직접 확인할 수 있습니다. 10개라면 확인할 수 없습니다. 시간이 부족하기 때문입니다.

Anthropic은 2026년 5월 6일 공개한 Managed Agents 기능 Outcomes로 이 문제를 다룹니다. 방식은 간단합니다. 첫 번째 에이전트의 작업을 엄격한 기준표에 따라 확인하는 일만 맡는 두 번째 에이전트(평가자)를 세션에 둡니다.

기술적인 작동 방식은 다음과 같습니다. “완료”의 의미, 확인할 출처, 사용할 라벨을 상세히 나열한 markdown 문서로 기준표를 작성합니다. 플랫폼은 새 컨텍스트 창에서 평가자 에이전트를 자동으로 만듭니다. 이 에이전트는 기준표와 결과만 받으며 다른 정보는 받지 않습니다. 주 에이전트(작성자)가 시도할 때마다 평가자는 결과를 다시 읽고 통과시키거나, 아직 완료되지 않은 항목을 하나씩 나열해 반환합니다.

Anthropic Cookbook에서 인용하면 다음과 같습니다.

실제 성과 수치입니다. Outcomes를 Claude Managed Agents에 통합한 후 AI 기업 Harvey의 작업 완료율은 약 6× 높아졌습니다. 의료 문서화 업체 Wisedocs에서는 문서 검토 시간이 50% 감소했습니다. 이 수치는 기능 공식 발표에서 가져왔습니다.

기업이 아닌 바이브 코더에게 중요한 점은 무엇일까요? Outcomes는 특정 기능만이 아니라 하나의 패턴입니다. 같은 기준을 .claude/agents/grader.md에 설명하고 주 에이전트에게 매번 시도한 뒤 실행하라고 요청하면 자체 평가자 에이전트를 만들 수 있습니다. Managed Agents뿐 아니라 어떤 멀티 에이전트 구성에서도 사용할 수 있습니다.

Cookbook에 나온 기준표 작성의 핵심 규칙은 일반적인 지시가 아니라 검증 가능한 항목을 지정하는 것입니다. “브리프에서 청구 관련 내용을 확인해”가 아니라 “브리프를 열고 청구 섹션을 찾아 금액이 $ 단위로 표시되어 있거나 매출의 비율로 명시되어 있는지 확인해”라고 해야 합니다. 첫 번째 지시는 평가자가 훑어보고 체크 표시를 하게 합니다. 두 번째 지시는 문서를 열고 구체적인 숫자를 찾게 합니다.

안티패턴: “헛일을 하는 에이전트 50개”#

이것이 멀티 에이전트의 핵심 안티패턴입니다. 누군가 Claude Code가 한 번에 에이전트 16개를 실행할 수 있고 Dynamic Workflows는 실행당 1000개까지 돌릴 수 있다는 사실을 알게 됩니다. 그래서 에이전트를 실행하기 시작합니다. 결과는 0입니다. 토큰 소비량은 일반 세션의 10×입니다.

간단히 점검하는 방법이 있습니다. 종이 한 장에 에이전트마다 상자를 하나씩 그리세요. 각 상자에 다음을 적습니다.

1. 정확히 무엇을 하는가(한 문장).
2. 어떤 파일을 다루는가.
3. 무엇을 반환하는가.
4. 누가 확인하는가.

이 중 하나라도 30초 안에 답할 수 없다면 그 에이전트는 필요하지 않습니다. 이 규칙은 서브에이전트, 에이전트 팀, Dynamic Workflows 등 모든 수준에서 통합니다.

두 번째 안티패턴은 순차적으로 해야 할 작업을 병렬로 실행하는 것입니다. 프런트엔드가 API 스키마를 읽기 위해 백엔드가 먼저 필요하다면 둘을 병렬로 실행하지 마세요. 백엔드를 먼저 하고 그다음 프런트엔드를 하세요. 작업은 서로 독립적일 때만 병렬로 진행해야 합니다.

세 번째 안티패턴은 속도를 높이려고 멀티 에이전트를 사용하는 것입니다. 어느 정도까지만 효과가 있습니다. 작업을 독립적인 작업 흐름 네 개로 나누면 조정에 드는 시간을 조금 더해, 하나의 흐름이 걸리는 시간 정도면 끝납니다. 하지만 한 대의 컴퓨터에서 50개 작업 흐름을 실행하면 CPU를 공유해야 하므로 각각 더 느려집니다. 노트북에서 동시에 실행하기 좋은 실질적인 상한은 Claude Code 인스턴스 4–6개입니다. 그 이상이면 속도 제한이 시작됩니다.

비용은 얼마나 들며 한도를 소진하지 않으려면 어떻게 해야 할까?#

2026년 5~6월, 업계는 AI 코딩 비용이 예상보다 많이 든다는 현실에 직면했습니다.

일반 Claude Code 채팅 세션 하나는 비교적 합리적인 비용이 듭니다. Dynamic Workflows를 저장소 전체에 적용하면 청구액이 20× 높아질 수 있습니다. Anthropic 공식 문서의 설명은 다음과 같습니다.

실무에서는 어떻게 해야 할까요? 설명한 경험에서 나온 절약 규칙은 다음과 같습니다.

1. 각 에이전트가 사용할 파일을 정확히 지정합니다. “프로젝트를 살펴보고 문제를 찾아”가 아니라 “src/auth/*.ts를 보고 모든 함수가 userId를 검증하는지 확인해”라고 하세요. 두 번째 프롬프트는 비용을 지불하는 작업이 무엇인지 정확히 지정합니다.

2. 항상 먼저 디렉터리 하나에서 워크플로를 시험합니다. src/ 전체가 아니라 src/auth/에서 시작하세요. 결과가 마음에 들고 비용을 이해했다면 더 넓게 적용하세요.

3. 기본적으로 /effort high를 사용하고 ultracode는 의도적으로만 선택합니다. /effort ultracode는 xhigh에 자동 오케스트레이션을 더한 설정입니다. 비용이 매우 큽니다. 작업에 병렬 작업 흐름 여러 개가 정말 필요한 경우에 사용하세요.

4. 가능하면 서브에이전트에 더 작은 모델을 사용합니다. 서브에이전트 여섯 개가 가이드 하나를 검토한다면 AI 여부를 확인하는 QA 에이전트나 내부 링크 검토자에게 Opus는 필요 없습니다. Sonnet이면 충분합니다. 사용량을 3–5× 줄일 수 있습니다.

토큰 절약에 관한 자세한 내용은 Claude Code에서 토큰이 소비되는 곳 가이드와 Claude Code 한도를 소진하지 않는 방법을 참조하세요.

오늘 시작하는 방법: 30분 체크리스트#

1. Claude Code를 v2.1.154+로 업데이트

   Dynamic Workflows를 지원하는 최소 버전입니다. 터미널에서 claude update를 실행하세요.

2. /config에서 Dynamic Workflows 활성화

   Pro 요금제에서는 기본적으로 비활성화되어 있습니다. /config를 열고 “Dynamic workflows” 항목을 찾아 활성화하세요. Max, Team, Enterprise에서는 이미 활성화되어 있습니다.

3. 첫 worktree 만들기

   주 프로젝트 디렉터리에서 git worktree add ../<project>-experiment <branch>를 실행하세요. 해당 디렉터리에서 터미널 창을 하나 더 열고 claude를 실행하세요.

4. 공유 작업 목록 추가

   모든 worktree 밖의 절대 경로 하나를 사용하세요. 각 worktree의 tasks.md는 별개 파일이며 자동 동기화되지 않습니다. 리드 세션만 수정하고 작업자는 공유 목록을 읽어 결과를 보고하세요.

   조정 디렉터리와 목록을 한 번 만드세요.

   mkdir -p "$HOME/projects/my-app-coordination"
   printf '%s\n' '# Tasks' '- Auth: assigned to the auth worktree' '- Billing: assigned to the billing worktree' > "$HOME/projects/my-app-coordination/tasks.md"
   

   첫 터미널:

   cd "$HOME/projects/my-app-auth"
   printf 'Shared task list: %s\n' "$HOME/projects/my-app-coordination/tasks.md"
   claude
   

   두 번째 터미널:

   cd "$HOME/projects/my-app-billing"
   printf 'Shared task list: %s\n' "$HOME/projects/my-app-coordination/tasks.md"
   claude
   

   두 세션에 위에서 출력한 같은 확장된 절대 경로를 주며 요청하세요. “공유 작업 목록을 읽고 맡은 작업과 파일만 수정하세요. 목록은 수정하지 말고 완료와 장애를 상태 수정 담당 리드에게 보고하세요.” 시작 전에 두 에이전트가 정확히 그 파일을 읽을 수 있는지 확인하고 해당 경로의 권한 요청을 해결하세요. 목록은 상태를 조정하며 코드 변경은 각 worktree에 남습니다.

5. 일주일 동안 이 방식으로 작업

   GUI 래퍼를 바로 설치하지 마세요. 일주일 동안 worktree 두 개로 수동 작업을 해 보세요. 무엇이 부족한지 알게 된 다음 특정 불편을 해결하기 위해 도구를 선택하세요.

6. 그다음에만 `/effort ultracode` 활성화

   “src/routes/에서 인증 검사가 없는 API endpoint를 모두 찾아”처럼 작업 하나를 선택하세요. /effort ultracode를 활성화하고 Claude가 어떤 워크플로를 작성하는지, 비용은 얼마인지, 어떤 결과를 내는지 확인하세요. 이것이 첫 Dynamic Workflow가 됩니다.

다음 단계: 세션 간 메모리, Code Review, Multi-Agent v2#

2026년 5~6월에 등장한 기능과 Claude Code의 멀티 에이전트가 나아갈 방향을 살펴봅니다.

Dreaming을 포함한 Managed Agents. 2026년 5월 6일 Code with Claude에서 공개됐습니다. 세션 사이에 에이전트의 과거 대화 기록을 읽고 반복되는 패턴을 찾아 메모리를 업데이트하는 예약 프로세스입니다. AI 법률 기업 Harvey의 작업 완료율은 특히 Dreaming을 도입한 뒤 6배 증가했습니다. 아직 연구 미리보기 단계입니다.

Managed Agents 기능인 Outcomes. 위에서 설명했습니다. Claude Code CLI에서 직접 사용할 수는 없고 Claude Agent SDK를 통해 이용할 수 있습니다. 지금도 평가자 서브에이전트를 사용해 같은 패턴을 수동으로 적용할 수 있습니다.

Claude Agent SDK의 Multi-Agent Orchestration v2. 리드 에이전트가 공유 파일시스템을 사용해 서브에이전트에 직접 위임합니다. “서브에이전트 N개를 수동으로 실행”하는 방식에서 “작업을 설명하면 리드가 누구에게 어떻게 위임할지 스스로 결정”하는 방식으로 나아갑니다. 이제 막 서브에이전트를 배우고 있다면 아직 v2를 걱정하지 마세요. “주 에이전트 하나 + 역할이 있는 서브에이전트 3–5개”라는 고전적인 패턴을 익히고 3–6개월 후 자연스럽게 v2로 옮겨가세요.

에이전트 팀의 Code Review. Anthropic은 Code with Claude에서 PR을 열 때 자동으로 코드 리뷰를 수행하는 기능을 발표했습니다. AI 에이전트 팀이 변경 사항을 병렬로 확인하고, 버그를 찾고, 서로 발견 사항을 검증하고, 심각도에 따라 순위를 매깁니다. Team과 Enterprise에서 제공되며 Pro에는 아직 제공되지 않습니다.

Plugin Marketplace. 2026년 5월 23일 v2.1.128-136에서 출시됐습니다. 마켓플레이스 플러그인 중 일부는 바로 사용할 수 있는 멀티 에이전트 구성을 제공합니다(parallel-review, security-audit, migration-helper). /plugin install <name>@claude-plugins-official로 설치해 구성을 살펴보면 직접 만드는 방법을 배우기에 좋습니다.

Claude Code의 멀티 에이전트는 아직 성숙도가 서로 다른 구성 요소의 집합입니다. 서브에이전트와 git worktree는 안정적이고 검증되어 어디서나 작동합니다. 에이전트 팀은 절반은 자동화되고 절반은 수동입니다. Dynamic Workflows는 연구 미리보기 단계이며 빠르게 바뀌고 있습니다. Managed Agents v2는 기업용입니다. 따라서 앞으로 1년 동안 바이브 코더에게 최적인 구성은 최신 릴리스가 아니라 작업에 필요한 최소 구성일 것입니다. 한 달 동안 집중적으로 작업하는 데 worktree 두 개와 평가자 서브에이전트 하나면 충분합니다. 제약이 느껴지기 시작할 때만 복잡성을 더하세요.

바이브 코딩을 위한 실용적인 구성#

실용 자료: Ailoot 문서.

더 많은 자료와 도구: Ailoot.