claude code 병렬 에이전트 차이점 — Claude Code 병렬 에이전트 3가지 차이점 — 세션·서브에이전트·팀 완전 비교

Claude Code 병렬 에이전트 3가지 차이점 — 세션·서브에이전트·팀 완전 비교

2026.04.18 · 25분 읽기

목차

CI/CD 파이프라인 10개가 동시에 돌아가는 모노레포에서 Claude Code로 작업할 때, 단일 세션 하나로는 병목이 생긴다. 인프라 코드를 수정하면서 동시에 API 테스트를 돌리고, 별도로 문서를 업데이트해야 하는 상황이 일상이다. Claude Code는 이 문제에 대해 세 가지 서로 다른 병렬 처리 방식을 제공한다. claude code 데스크톱 병렬 에이전트 차이점을 정확히 이해하지 않으면, 불필요한 토큰을 소모하거나 Git 충돌에 빠지게 된다.

이 글에서는 데스크톱 병렬 세션, 서브에이전트(Subagents), Agent Teams 세 방식의 아키텍처를 분해하고, 각각이 어떤 워크플로에 적합한지 근거 기반으로 분석한다.

병렬 작업이 필요한 이유와 문제 정의

parallel-work-problem-definition

단일 Claude Code 세션은 하나의 컨텍스트 윈도우에서 순차적으로 작업을 처리한다. 모노레포 환경에서 인프라 변경, 애플리케이션 코드 수정, 테스트 자동화를 동시에 진행하려면 세 가지 문제가 발생한다.

첫째, 컨텍스트 오염이다. Terraform HCL 파일과 React 컴포넌트를 같은 세션에서 다루면, 모델이 이전 작업의 맥락을 현재 작업에 혼입시킨다. 둘째, Git 충돌 위험이다. 같은 브랜치에서 여러 영역을 동시에 수정하면 커밋 히스토리가 꼬인다. 셋째, 대기 시간 낭비다. 하나의 작업이 끝날 때까지 다른 작업을 시작할 수 없으면 전체 처리 시간이 직렬로 합산된다.

Claude Code는 이 세 문제를 각각 다른 추상화 수준에서 해결한다. 데스크톱 병렬 세션은 프로젝트 수준 격리, 서브에이전트는 태스크 수준 위임, Agent Teams는 협업 수준 조율을 담당한다. claude code 데스크톱 병렬 에이전트 차이점의 핵심은 이 추상화 계층의 차이에 있다.

세 방식의 추상화 수준
데스크톱 병렬 세션은 독립된 Git worktree로 프로젝트를 물리적으로 분리한다. 서브에이전트는 단일 세션 내에서 특정 도구만 접근 가능한 하위 프로세스를 생성한다. Agent Teams는 여러 Claude Code 인스턴스가 메시지를 주고받으며 공동 작업한다.
## 데스크톱 병렬 세션의 동작 원리

Claude Code 데스크톱 앱은 병렬 세션, 자동 Git worktree 격리, 드래그앤드롭 레이아웃, 통합 터미널/파일 에디터, 사이드 챗, 비주얼 diff 리뷰, 라이브 앱 프리뷰 기능을 제공한다. 사이드바에서 + New session을 클릭하거나 Cmd+N(macOS)/Ctrl+N(Windows)으로 병렬 작업이 가능하며, 각 세션은 Git worktree로 격리되어 커밋 전까지 서로 영향을 주지 않는다.

Worktree 저장 경로와 설정

데스크톱 앱의 worktree는 <project-root>/.claude/worktrees/에 기본 저장된다. Settings → Claude Code에서 커스텀 디렉토리와 브랜치 접두사 설정이 가능하다. 세션 아카이브 시 worktree가 제거되며, PR 머지/클로즈 후 자동 아카이브 옵션(Auto-archive after PR merge or close)도 지원한다.

CLI에서도 --worktree(-w) 플래그로 동일한 격리를 구현할 수 있다. Claude Code 워크플로 가이드에 따르면 다음과 같이 사용한다.

# Start Claude in a worktree named "feature-auth"
claude --worktree feature-auth

# Start another session in a separate worktree
claude --worktree bugfix-123

# Auto-generates a name like "bright-running-fox"
claude --worktree

이 명령은 .claude/worktrees/feature-auth/에 origin/HEAD에서 분기한 새 브랜치를 만든다. 이름을 생략하면 자동 생성된다. 세션 종료 시 변경사항이 없으면 worktree가 자동 정리되고, 변경사항이 있으면 유지/삭제를 선택할 수 있다.

DevOps 관점에서의 병렬 세션 활용

병렬 세션은 본질적으로 사람이 직접 컨텍스트를 전환하는 구조다. 세션 A에서 Terraform 모듈을 수정하고, 세션 B에서 Helm chart를 업데이트하되, 두 세션 사이에 자동 조율은 없다. 각 세션이 독립 브랜치에서 작업하므로 Git 충돌은 PR 단계에서 해결한다.

worktree 자동 정리 활용
PR 머지 후 자동 아카이브 옵션을 켜두면 `.claude/worktrees/` 디렉토리가 무한히 늘어나는 것을 방지할 수 있다. 장기 작업 브랜치가 아닌 이상, 이 옵션을 활성화하는 것이 디스크 관리에 유리하다.
## Subagent 아키텍처와 claude code 데스크톱 병렬 에이전트 차이점

서브에이전트는 단일 세션 안에서 동작하는 하위 AI 인스턴스다. Claude Code 서브에이전트 문서에 따르면, 서브에이전트는 전용 컨텍스트 윈도우, 커스텀 시스템 프롬프트, 특정 도구 접근 권한, 독립 퍼미션을 갖는 특화 AI 어시스턴트다. 컨텍스트 보존, 제약 적용, 프로젝트 간 설정 재사용, 특화 동작, 비용 절감(Haiku 같은 경량 모델 라우팅) 등의 이점이 있다.

💡 관련 상품: 노트북 이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.

내장 서브에이전트 종류

Claude Code에는 세 가지 내장 서브에이전트가 있다.

서브에이전트모델도구 접근용도
ExploreHaiku읽기 전용코드베이스 탐색, 파일 검색
Plan메인 모델 상속읽기 전용구현 전략 설계, 아키텍처 분석
General-purpose메인 모델 상속모든 도구복잡한 멀티스텝 작업

Explore 에이전트가 Haiku로 라우팅되는 점이 비용 관리에 중요하다. 코드베이스 검색처럼 반복적이고 단순한 작업에 고비용 모델을 쓸 필요가 없기 때문이다.

커스텀 서브에이전트 정의

프로젝트별 서브에이전트는 .claude/agents/ 디렉토리에 마크다운 파일로 정의한다.

---
name: code-reviewer
description: Reviews code for quality and best practices
tools: Read, Glob, Grep
model: sonnet
---

You are a code reviewer. When invoked, analyze the code and provide
specific, actionable feedback on quality, security, and best practices.

이 파일을 .claude/agents/code-reviewer.md에 저장하면 해당 프로젝트에서 code-reviewer 서브에이전트를 사용할 수 있다. 사용자 수준 서브에이전트는 ~/.claude/agents/에, 프로젝트 수준은 .claude/agents/에 저장한다.

CLI에서 --agents 플래그로 세션 단위 서브에이전트를 JSON으로 정의하는 방법도 있다.

claude --agents '{
  "code-reviewer": {
    "description": "Expert code reviewer. Use proactively after code changes.",
    "prompt": "You are a senior code reviewer. Focus on code quality, security, and best practices.",
    "tools": ["Read", "Grep", "Glob", "Bash"],
    "model": "sonnet"
  }
}'

Worktree 격리와 서브에이전트

서브에이전트의 isolation 필드를 worktree로 설정하면 임시 Git worktree에서 독립 실행되며, 변경사항이 없으면 자동 정리된다. 이 방식은 데스크톱 병렬 세션의 worktree와 같은 메커니즘을 사용하지만, 핵심 차이는 서브에이전트의 결과가 메인 에이전트에게 자동으로 보고된다는 점이다. 데스크톱 병렬 세션은 사람이 수동으로 결과를 확인하고 머지해야 한다.

서브에이전트 간 통신 불가
서브에이전트는 메인 에이전트에게만 결과를 보고하고, 서브에이전트끼리는 통신하지 않는다. 서브에이전트 A의 결과를 서브에이전트 B가 참조해야 하는 워크플로라면, 메인 에이전트가 중간에서 결과를 전달하는 구조를 설계해야 한다.
## Agent Teams의 구조와 협업 메커니즘

Agent Teams는 여러 Claude Code 인스턴스가 공유 태스크 리스트와 메일박스를 통해 협업하는 실험적 기능이다. 한 세션이 팀 리드가 되어 작업을 조율하고, 팀원들은 독립 컨텍스트 윈도우에서 작업하며 서로 직접 메시지를 주고받을 수 있다. Claude Code Agent Teams 문서에 명시된 대로, 환경변수로 활성화한다.

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

네 가지 핵심 컴포넌트

Agent Teams의 아키텍처는 네 컴포넌트로 구성된다.

Team Lead는 메인 세션으로, 팀을 생성하고 작업을 조율한다. Teammates는 독립 Claude Code 인스턴스로, 각각 자체 컨텍스트 윈도우를 갖는다. Task List는 팀 전체가 공유하는 작업 목록이다. Mailbox는 에이전트 간 메시징 시스템으로, 팀원끼리 직접 메시지를 주고받는 채널이다.

팀 설정은 ~/.claude/teams/{team-name}/config.json에, 태스크는 ~/.claude/tasks/{team-name}/에 저장된다. v2.1.32 이상이 필요하다.

표시 모드: in-process vs split panes

Agent Teams는 두 가지 표시 모드를 지원한다. in-process(기본, 모든 터미널 호환)와 split panes(tmux 또는 iTerm2 필요)다. in-process 모드에서는 Shift+Down으로 팀원 간 전환하고, split panes 모드에서는 각 팀원이 자체 pane을 갖는다.

{
  "teammateMode": "in-process"
}

이 설정은 ~/.claude.json에서 구성한다. DevOps 환경에서 SSH로 원격 서버에 접속해 작업하는 경우, tmux가 이미 설치되어 있을 가능성이 높으므로 split panes 모드가 시각적 모니터링에 유리하다.

실험적 기능 상태
Agent Teams는 2026-04 기준 실험적 기능이다. 환경변수 `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1`로 명시적으로 활성화해야 하며, 프로덕션 워크플로에 도입하기 전에 제한사항을 반드시 확인해야 한다.
## 세 방식의 비교 분석 — claude code 데스크톱 병렬 에이전트 차이점 종합

세 방식은 격리 단위, 통신 방식, 조율 주체에서 명확히 갈린다.

비교 항목데스크톱 병렬 세션서브에이전트Agent Teams
격리 단위Git worktree (물리적)컨텍스트 윈도우 (논리적)독립 인스턴스 (프로세스)
통신 방식없음 (수동 확인)메인→서브 단방향 보고메일박스 양방향 메시징
조율 주체사람메인 에이전트팀 리드 + 공유 태스크 리스트
모델 선택세션별 독립에이전트별 지정 (Haiku 등)인스턴스별 독립
Git 충돌 해소PR 단계worktree 사용 시 PR 단계PR 단계
상태 공유없음결과만 메인에 반환태스크 리스트 + 메시지
최소 요구 버전데스크톱 앱CLI/데스크톱 모두 지원v2.1.32 이상
안정성정식 기능정식 기능실험적

핵심 차이: 통신 토폴로지

서브에이전트와 Agent Teams의 핵심 차이는 통신 구조에 있다. 서브에이전트는 단일 세션 내에서 메인 에이전트에게만 결과를 보고하고 서로 통신하지 않는다. Agent Teams의 팀원들은 공유 태스크 리스트를 통해 자율 조율하고, 서로 직접 메시지를 주고받을 수 있다. 서브에이전트는 결과만 중요한 집중 작업에, Agent Teams는 토론과 협업이 필요한 복잡한 작업에 적합하다.

세 방식의 통신 구조를 Mermaid로 표현했다.

flowchart TB
    subgraph Desktop["데스크톱 병렬 세션"]
        S1[세션 A] ---|"격리"| S2[세션 B]
        S1 ---|"격리"| S3[세션 C]
        S2 ---|"격리"| S3
        U[사용자] --> S1
        U --> S2
        U --> S3
    end

    subgraph Sub["서브에이전트"]
        M[메인 에이전트] --> SA1[서브 A]
        M --> SA2[서브 B]
        M --> SA3[서브 C]
        SA1 -.->|"결과 보고"| M
        SA2 -.->|"결과 보고"| M
        SA3 -.->|"결과 보고"| M
    end

    subgraph Team["Agent Teams"]
        TL[팀 리드] <-->|"메일박스"| T1[팀원 A]
        TL <-->|"메일박스"| T2[팀원 B]
        T1 <-->|"메일박스"| T2
        TK[공유 태스크 리스트] --- TL
        TK --- T1
        TK --- T2
    end

데스크톱 병렬 세션은 허브 없는 분산 구조, 서브에이전트는 스타 토폴로지, Agent Teams는 메시 토폴로지에 가깝다. 자동화 파이프라인에서 이 차이는 태스크 간 의존성 처리 방식을 결정한다.

워크플로별 선택 기준과 의사결정 프레임워크

세 방식 중 어떤 것을 선택할지는 작업의 성격에 따라 달라진다. 다음 의사결정 트리로 선택한다.

독립적 병렬 작업 → 데스크톱 병렬 세션

작업 간 의존성이 없고, 각각이 서로 다른 디렉토리나 모듈을 수정하는 경우다. 예를 들어 프론트엔드 리팩토링과 백엔드 API 추가를 동시에 진행하되, 두 작업이 완료된 후 PR로 합치는 워크플로에 적합하다.

적합한 시나리오:

  • 모노레포에서 서로 다른 패키지를 동시에 수정
  • 핫픽스와 피처 개발을 동시 진행
  • 여러 환경(staging, production)의 설정을 독립적으로 변경

결과만 필요한 위임 작업 → 서브에이전트

메인 작업 흐름 중에 특정 하위 작업을 위임하고, 그 결과만 돌려받으면 되는 경우다. 코드 리뷰, 코드베이스 탐색, 테스트 실행 같은 작업이 여기에 해당한다. 서브에이전트는 Haiku 같은 경량 모델로 라우팅할 수 있어 비용 효율이 높다.

적합한 시나리오:

  • 코드 변경 후 자동 리뷰 실행
  • 대규모 코드베이스에서 특정 패턴 검색
  • 변경 영향 범위 분석 후 결과 요약

상호 조율이 필요한 복합 작업 → Agent Teams

여러 작업이 서로의 진행 상황을 참조하며 조율해야 하는 경우다. 팀원 A가 데이터베이스 스키마를 변경하면, 팀원 B가 그에 맞춰 API 엔드포인트를 수정하고, 팀원 C가 프론트엔드를 업데이트하는 식의 연쇄 의존 작업이 해당한다.

적합한 시나리오:

  • 데이터베이스 마이그레이션 + API 변경 + 프론트엔드 수정이 연쇄적으로 필요한 경우
  • 여러 마이크로서비스의 인터페이스를 동시에 변경해야 하는 경우
  • 코드 작성과 테스트 작성을 별도 에이전트가 동시에 진행하며 피드백을 교환하는 경우

서브에이전트는 경량 모델 라우팅으로 토큰 비용을 절감할 수 있다. Agent Teams는 팀원 수만큼 독립 인스턴스가 실행되므로 토큰 소모가 증가한다. 공식 문서에 구체적인 비용 증가 배수는 명시되어 있지 않으므로, 실제 사용 시 토큰 사용량을 모니터링해야 한다.

실전 구성 예제: DevOps 파이프라인 자동화

CI/CD 파이프라인에서 claude code 데스크톱 병렬 에이전트 차이점을 활용한 실전 구성을 살펴본다. 세 방식을 혼합하는 것이 실무에서 가장 현실적이다.

서브에이전트 기반 코드 리뷰 자동화

인프라 코드 변경 후 자동으로 코드 리뷰를 실행하는 서브에이전트를 정의한다. .claude/agents/infra-reviewer.md 파일에 다음 내용을 저장한다.

---
name: infra-reviewer
description: Reviews infrastructure code changes
tools: Read, Glob, Grep
model: sonnet
---

Terraform, Helm, Dockerfile 변경사항을 분석한다.
보안 그룹 개방 범위, 리소스 사이징, 시크릿 노출 여부를
중점적으로 검토하고 구체적 수정 제안을 제공한다.

이 서브에이전트는 Read, Glob, Grep만 접근 가능하므로 코드를 수정하지 않는다. 읽기 전용 제약이 리뷰 작업의 안전성을 보장한다.

CLI에서 worktree + 서브에이전트 조합

하나의 worktree에서 인프라 변경을 진행하면서, 서브에이전트가 변경 영향도를 분석하는 워크플로다.

# worktree에서 인프라 변경 작업 시작
claude --worktree infra-update

# 별도 worktree에서 동시에 모니터링 설정 변경
claude --worktree monitoring-config

두 세션은 서로 격리되어 있으므로, infra-update 워크트리에서 Terraform 모듈을 수정하는 동안 monitoring-config 워크트리에서 Prometheus 설정을 독립적으로 변경할 수 있다. 각 세션 내부에서는 서브에이전트를 활용해 코드 리뷰나 탐색 작업을 위임한다.

Agent Teams를 활용한 멀티서비스 업데이트

여러 마이크로서비스의 API 버전을 동시에 올려야 하는 상황을 가정하자. 팀 리드가 변경 범위를 정의하고, 각 팀원이 서비스별로 작업을 분담한다.

이 워크플로에서 teammateMode를 in-process로 설정하면 단일 터미널에서 Shift+Down으로 팀원 간 전환이 가능하다. tmux를 사용하는 환경이라면 split panes 모드가 각 팀원의 진행 상황을 동시에 모니터링하기에 적합하다.

프로젝트 구성 예시:
~/.claude/teams/api-upgrade/
├── config.json          ← 팀 설정
└── ...
~/.claude/tasks/api-upgrade/
├── task-001.json        ← auth 서비스 API v2 마이그레이션
├── task-002.json        ← payment 서비스 API v2 마이그레이션
└── task-003.json        ← notification 서비스 API v2 마이그레이션

팀원 A가 auth 서비스의 API 스키마를 변경하면, 메일박스를 통해 팀원 B에게 변경된 인터페이스를 전달한다. 팀원 B는 이를 참조해 payment 서비스의 클라이언트 코드를 수정한다. 이 자율 조율이 Agent Teams만의 차별점이다.

한계점, 주의사항과 실전 선택 가이드

세 방식 모두 각각의 제약이 있다. 프로덕션 워크플로에 도입하기 전에 이 한계를 명확히 인식해야 한다.

Agent Teams의 제한사항

Agent Teams는 실험적 기능으로, 다음 제한이 있다. in-process 팀원은 /resume으로 복원할 수 없다. 태스크 상태 반영에 지연이 발생할 수 있다. 종료 속도가 느릴 수 있다. 세션당 하나의 팀만 허용되며, 중첩 팀은 불가능하다. 팀 리드를 변경할 수 없다. 팀원 퍼미션은 생성 후 개별 변경만 가능하다. split pane 모드는 VS Code 통합 터미널, Windows Terminal, Ghostty에서 지원되지 않는다.

복원 불가 주의
in-process 모드의 팀원은 세션이 끊기면 `/resume`으로 복원할 수 없다. 장시간 작업에서는 split panes 모드를 사용하거나, 작업 단위를 작게 나누어 진행하는 것이 안전하다.
### 공식 문서에 명시되지 않은 영역

한국어 공식 문서에서 데스크톱 병렬 세션, Agent Teams, 서브에이전트 세 개념을 통합 비교한 가이드는 존재하지 않는다. Agent Teams의 토큰 비용이 구체적으로 몇 배 증가하는지도 공식 문서에 명시되어 있지 않다. 데스크톱 앱에서 Agent Teams를 GUI로 관리하는 방법에 대한 문서도 별도로 없으며, CLI 기반 설명만 존재한다. 병렬 작업 시 .worktreeinclude 파일을 활용한 환경변수 복사 패턴의 실전 예제도 부족하다.

서브에이전트 스코프 관리

서브에이전트는 .claude/agents/(프로젝트), ~/.claude/agents/(사용자), 플러그인, managed settings 등 다양한 스코프에서 관리 가능하다. 이 다층 스코프는 유연하지만, 같은 이름의 서브에이전트가 여러 스코프에 존재할 때 어떤 것이 우선하는지 파악해야 한다. DevOps 관점에서 팀 전체가 공유하는 서브에이전트는 managed settings로 중앙 관리하고, 개인 실험용은 사용자 스코프에 두는 것이 운영 복잡도를 줄인다.

격리 수준과 통신 구조가 세 방식 선택의 핵심 기준이다. 독립 작업은 데스크톱 병렬 세션, 위임 작업은 서브에이전트, 협업 작업은 Agent Teams가 각각의 영역을 담당한다. 세 방식을 혼합하는 구조가 실무에서 토큰 효율과 작업 안전성을 동시에 확보한다 — worktree로 브랜치를 격리하고, 각 세션 내에서 서브에이전트로 반복 작업을 위임하며, 크로스커팅 변경이 필요할 때만 Agent Teams를 활성화하는 방식이다.

Agent Teams가 실험적 기능에서 정식으로 전환되면, Claude Code 멀티 에이전트 비교의 판도가 달라질 수 있다. 현 시점에서는 서브에이전트를 중심으로 자동화 파이프라인을 구축하고, Agent Teams는 제한된 범위에서 검증하는 접근이 합리적이다. 다음으로 확인할 영역은 Claude Code subagent 만들기에서 isolation: worktree를 활용한 병렬 코드 리뷰 자동화, 그리고 Claude Code 팀 협업 에이전트의 태스크 리스트를 CI 파이프라인 트리거와 연동하는 패턴이다. --worktree 플래그와 커스텀 서브에이전트 조합만으로도 Claude Code 병렬 작업 워크플로의 상당 부분을 커버할 수 있으므로, 이 조합부터 검증하는 것이 claude code 데스크톱 병렬 에이전트 차이점을 실무에 적용하는 가장 현실적인 출발점이다.

관련 글

이 글 공유하기