멀티 에이전트 충돌 줄이기: git worktree 실전 운영 체크리스트

여러분 이거 경험 있죠? AI 에이전트 3개 띄워놓고 병렬로 코딩 시켰는데, 끝나고 보니 같은 파일 세 군데서 다 건드려놨던 거. merge conflict 해결하느라 원래 작업 시간보다 더 걸린 적. 저도 그랬습니다. 솔직히 이거 겪어본 사람만 아는 고통이에요.

git worktree란? 하나의 Git 저장소에 여러 개의 작업 디렉토리를 연결해서, 서로 다른 브랜치를 동시에 체크아웃할 수 있게 해주는 Git 내장 기능이다. 2026년 2월 기준 Claude Code CLI v2.1.49부터 --worktree 플래그로 에이전트별 자동 worktree 분리를 지원한다.

---

목차

1. 왜 멀티 에이전트에서 작업공간 분리가 핵심인가
2. git worktree 기본 개념과 브랜치 전략 차이
3. Claude Code CLI 적용 시 기대효과와 제한사항
4. 충돌률·속도·회수율로 보는 실험 설계
5. 팀 단위 운영 규칙: 정리 정책, 리뷰 플로우, CI
6. 실전 운영 체크리스트 한 장 정리

---

왜 멀티 에이전트에서 작업공간 분리가 핵심인가

멀티 에이전트 개발이 2026년 들어서 완전히 현실이 됐어요. Claude Code, Codex, Cursor — 도구는 넘쳐나는데, 문제는 늘 같은 곳에서 터집니다.

같은 저장소에서 여러 에이전트가 동시에 작업하면 뭐가 일어나는지 아세요?

구체적으로 세 가지가 꼬여요:

1. 파일 잠금 충돌

에이전트 A가 app.tsx 수정 중인데, 에이전트 B도 app.tsx에 import문 추가하려고 합니다. 둘 다 같은 HEAD에서 시작하니까 누가 먼저 커밋하느냐에 따라 나머지 하나는 무조건 conflict를 만나요. 엔트리 파일이나 설정 파일처럼 여러 기능이 교차하는 파일에서 이게 특히 심합니다.

2. 컨텍스트 오염

에이전트가 파일을 읽을 때, 다른 에이전트가 중간에 바꿔놓은 파일을 읽게 됩니다. “이 함수 시그니처가 이랬는데요?”라면서 이미 변경된 코드 기준으로 작업하는 거예요. 결과물이 이상하게 나오는 원인 중 상당수가 이 컨텍스트 오염이에요.

3. 테스트 환경 간섭

에이전트 A가 테스트 돌리는 중에 에이전트 B가 같은 디렉토리에서 npm install로 패키지를 바꿔버리면? 테스트 결과를 신뢰할 수 없게 됩니다. “왜 갑자기 테스트가 깨졌지?”의 원인이 내 코드가 아니라 옆 에이전트의 dependency 변경인 거죠.

이 세 가지를 한 방에 해결하는 게 작업공간 물리적 분리입니다. 그리고 그 가장 효율적인 방법이 git worktree예요.

왜 그냥 git clone을 여러 개 하면 안 되냐고요?

안 되는 건 아닌데, 비효율적이에요. clone은 .git 디렉토리를 통째로 복제하니까 저장 공간도 먹고, 히스토리 동기화도 수동으로 해야 하고, remote 설정도 각각 관리해야 합니다. worktree는 .git 디렉토리를 공유하면서 작업 디렉토리만 분리하니까 디스크 사용량도 적고 동기화 오버헤드도 거의 없어요.

---

git worktree 기본 개념과 브랜치 전략 차이

30초 핵심 개념

git worktree는 하나의 저장소에 여러 개의 ‘작업 디렉토리’를 붙이는 기능이에요. 각 worktree는 서로 다른 브랜치를 체크아웃하고, 서로의 파일 시스템에 영향을 주지 않습니다.

# 기본 사용법
git worktree add ../project-feature-auth feature/auth
git worktree add ../project-bugfix-login bugfix/login
git worktree add ../project-refactor-api refactor/api

# 현재 worktree 목록 확인
git worktree list

# 작업 완료 후 제거
git worktree remove ../project-feature-auth

이게 끝이에요. 진짜 이게 전부입니다.

기존 브랜치 전략 vs worktree 전략 비교

항목	브랜치 전환 방식	worktree 방식
작업 디렉토리	1개 (공유)	N개 (격리)
컨텍스트 전환	git stash → git checkout	디렉토리 이동만
빌드 캐시	전환 시 날아감	각각 보존
동시 작업	불가능	가능
테스트 격리	불가능	완전 격리
디스크 사용	최소	추가 (소스 코드만큼)
.git 디렉토리	1개	1개 (공유)

여기서 핵심은 “.git 디렉토리 공유”입니다. clone은 .git을 통째로 복제하지만, worktree는 메인 .git을 심볼릭 링크로 참조해요. 그래서 커밋 히스토리, remote 설정, 훅 — 전부 한 벌만 관리하면 됩니다.

에이전트에 최적화된 worktree 구조

제가 실제로 쓰고 있는 디렉토리 구조를 보여드리겠습니다:

~/projects/
├── my-app/                    # 메인 worktree (main 브랜치)
│   ├── .git/                  # 진짜 .git 디렉토리
│   └── src/
├── my-app-agent-1/            # Agent 1 전용 worktree
│   ├── .git (파일, 링크)       # 메인 .git 참조
│   └── src/
├── my-app-agent-2/            # Agent 2 전용 worktree
│   └── src/
└── my-app-agent-3/            # Agent 3 전용 worktree
    └── src/

각 에이전트는 자기 디렉토리에서만 작업하니까, 파일 잠금 충돌이 원천적으로 발생하지 않아요. 같은 저장소의 다른 브랜치를 보고 있을 뿐이니까요.

Bare 저장소 전략 (고급)

더 깔끔한 방법도 있어요. 작업 파일 없이 .git 데이터만 가지고 있는 bare 저장소를 만들고, 모든 브랜치를 worktree로 관리하는 겁니다:

# bare 저장소 생성
git clone --bare https://github.com/team/project.git project.git

# 각 에이전트용 worktree 생성
cd project.git
git worktree add ../agent-1 -b agent/feature-1
git worktree add ../agent-2 -b agent/refactor-2
git worktree add ../agent-3 -b agent/bugfix-3

이 방식은 “메인 작업 디렉토리”라는 개념 자체가 없어지면서 모든 브랜치가 동등하게 worktree로 관리돼요. PR 리뷰용 임시 환경을 만들었다가 바로 폐기할 수도 있습니다.

---

Claude Code CLI 적용 시 기대효과와 제한사항

--worktree 플래그: 무엇이 바뀌나

2026년 2월 현재, Claude Code CLI v2.1.49부터 --worktree(단축: -w) 플래그가 추가됐어요. Boris Cherny(Anthropic 소속)가 Threads에서 직접 소개한 기능입니다.

이게 뭘 하는 건지 아세요?

Claude Code CLI를 실행할 때 -w 플래그를 붙이면, 에이전트가 자동으로 격리된 worktree 환경에서 작업을 시작해요. 수동으로 git worktree add를 할 필요가 없어진 거죠.

# 기존 방식 (수동)
git worktree add ../task-1 -b feature/task-1
cd ../task-1
claude code start

# 새 방식 (--worktree 플래그)
claude code --worktree start   # 자동으로 worktree 생성 + 진입

Desktop에서는 이미 비슷한 기능이 있었다고 합니다. 이번에 CLI로 확장된 거예요. 이게 왜 중요하냐면, CLI 환경이야말로 멀티 에이전트를 동시에 여러 개 띄우는 주 무대거든요. 터미널 탭 3개 열어서 각각 에이전트 돌리는 게 CLI에서 자연스러운 패턴이니까요.

Subagent도 worktree 격리

Claude Code의 subagent 시스템도 worktree 격리를 지원해요. 리드 에이전트가 서브 에이전트를 스폰할 때, 각 서브 에이전트가 임시 worktree에서 작업하고 결과만 통합하는 구조입니다.

Lead Agent (main)
├── Subagent A → worktree A (feature/component-1)
├── Subagent B → worktree B (feature/component-2)
└── Subagent C → worktree C (test/integration)

이런 구조면 서브 에이전트끼리 파일 충돌이 날 이유가 없어요.

기대효과 요약

효과	이전	이후
merge conflict 빈도	에이전트 수에 비례 증가	겹치는 파일 있을 때만
컨텍스트 정확도	다른 에이전트 수정분 섞임	각자의 브랜치 기준 100%
테스트 신뢰도	간섭으로 false failure	격리된 환경에서 실행
작업 복구	충돌 해결 실패 시 처음부터	worktree 폐기 후 재생성
디스크 사용량	clone 대비 큼	worktree라서 .git 공유

제한사항 — 솔직히 다 장밋빛은 아녜요

제가 직접 써보면서 느낀 제한사항 몇 가지 짚어볼게요.

1. 의존성 설치가 각 worktree마다 필요해요

worktree는 소스 파일만 분리하지, node_modules나 Python venv 같은 의존성 폴더는 공유하지 않아요. 새 worktree 만들 때마다 npm install이나 pip install을 따로 해줘야 합니다. 프로젝트가 크면 이 설치 시간이 곱해져요.

실전 팁: node_modules를 symlink로 공유하는 트릭이 있긴 한데, 브랜치별로 package.json이 다르면 오히려 문제가 되니까 추천하지 않습니다. 차라리 pnpm이나 yarn berry의 PnP 모드처럼 전역 캐시를 쓰는 패키지 매니저가 나아요.

2. IDE 연동에 신경 써야 해요

VS Code는 각 worktree를 별도 윈도우로 열면 문제없어요. 하지만 한 윈도우에서 멀티 루트 워크스페이스로 열면 Git 파일 감시가 꼬일 수 있어요. JetBrains IDE도 worktree를 잘 인식하지만, 인덱싱이 worktree마다 별도로 돌면서 메모리를 좀 먹습니다.

3. 같은 브랜치를 두 worktree에서 체크아웃 못 해요

이건 Git의 설계 제약이에요. main 브랜치를 이미 메인 worktree에서 보고 있으면, 다른 worktree에서 main을 체크아웃할 수 없습니다. 에이전트마다 브랜치를 나눠줘야 해요.

4. 성능 오버헤드 수치가 아직 공개 안 됐어요 #검증필요

Boris Cherny의 Threads 포스트에서 기능 소개는 했지만, 구체적인 성능 오버헤드(CPU, 메모리, 디스크 I/O)수치는 언급되지 않았어요. 대규모 모노레포에서 worktree 10개 이상 운영할 때 성능이 어떨지는 직접 벤치마킹이 필요합니다.

---

충돌률·속도·회수율로 보는 실험 설계

“진짜 효과 있어?” — 이 질문에 답하려면 숫자가 필요해요. 제가 실험을 설계해본 프레임워크를 공유합니다.

실험 조건

항목	대조군 (기존 방식)	실험군 (worktree 방식)
저장소	동일	동일
에이전트 수	3	3
병렬 작업	같은 디렉토리	각자 worktree
태스크	동일 (Feature 3개)	동일 (Feature 3개)
측정 기간	1주일	1주일

핵심 측정 지표 3가지

1. 충돌률 (Conflict Rate)

충돌률 = merge conflict 발생 횟수 / 총 merge 시도 횟수 × 100

기존 방식에서 에이전트 3개가 하루 평균 10회 commit + merge 한다면, 제 경험상 2~3회는 conflict가 터져요. 약 20~30%의 충돌률인 거죠. worktree 방식에서는 이론적으로 0%까지 낮아질 수 있는데, 실제로는 같은 파일을 건드리는 태스크가 있으면 merge 시점에서 여전히 발생합니다. 다만 작업 중간이 아니라 merge 시점에서만 발생하니까 예측 가능하고 관리 가능해져요.

2. 작업 속도 (Cycle Time)

Cycle Time = 태스크 시작 ~ merge 완료까지 소요 시간

기존 방식은 conflict 해결 시간이 cycle time에 포함돼요. worktree 방식은 작업 자체는 conflict 없이 진행되고, merge는 한 번에 모아서 하니까 전체 cycle time이 줄어들 가능성이 높습니다.

3. 회수율 (Recovery Rate)

회수율 = 문제 발생 후 원래 상태로 복구하는 데 걸린 시간

기존 방식: conflict 해결 실패 → git reset --hard → 재작업. worktree 방식: 해당 worktree 삭제 → 새 worktree 생성 → 0부터 재시작.

worktree를 날리는 게 훨씬 깔끔해요. 실패한 작업이 다른 에이전트에 영향을 안 주니까요.

기록 템플릿

실험할 때 이런 식으로 기록하면 됩니다:

## 실험 기록

| 날짜 | 방식 | 에이전트 수 | 총 merge | conflict | 충돌률 | Cycle Time (평균) | 비고 |
|------|------|-----------|----------|----------|--------|------------------|------|
| 0221 | 기존 | 3 | 12 | 3 | 25% | 45분 | 엔트리 파일 충돌 |
| 0222 | worktree | 3 | 12 | 1 | 8% | 32분 | merge 시점에서만 |

---

팀 단위 운영 규칙: 정리 정책, 리뷰 플로우, CI

혼자 쓸 때는 대충 해도 되는데, 팀이 되면 규칙이 필요해요. 제가 정리한 운영 규칙입니다.

1. 이름 짓기 규칙 (Naming Convention)

# 패턴: {프로젝트}-{에이전트역할}-{태스크}
git worktree add ../myapp-agent-auth           -b agent/auth
git worktree add ../myapp-agent-refactor-api   -b agent/refactor-api
git worktree add ../myapp-review-pr-142        -b review/pr-142

왜 이렇게 해야 하냐면, git worktree list 했을 때 한눈에 누가 뭘 하고 있는지 보이거든요:

/Users/dev/myapp                    abc1234 [main]
/Users/dev/myapp-agent-auth         def5678 [agent/auth]
/Users/dev/myapp-agent-refactor    ghi9012 [agent/refactor-api]
/Users/dev/myapp-review-pr-142     jkl3456 [review/pr-142]

2. 정리 정책 (Cleanup Policy)

이게 진짜 중요해요. worktree를 안 지우면 디스크가 점점 차고, git worktree list가 쓸데없는 항목으로 가득 차요.

개인적으로는 이 규칙을 사용합니다:

# 규칙 1: merge 완료된 worktree는 즉시 삭제
git worktree remove ../myapp-agent-auth

# 규칙 2: 3일 이상 작업 없는 worktree는 체크 후 삭제
git worktree list --porcelain | grep -B2 "prunable"

# 규칙 3: 수동 삭제 후 메타데이터 정리
git worktree prune

# 규칙 4: 중요 worktree는 잠금
git worktree lock ../myapp-agent-auth --reason "장기 작업 중"

자동 정리 스크립트 (실전 사용 중):

#!/bin/bash
# worktree-cleanup.sh
# merge 완료된 worktree 자동 정리

MAIN_BRANCH="main"

for wt in $(git worktree list --porcelain | grep "^worktree" | awk '{print $2}'); do
  if [ "$wt" = "$(pwd)" ]; then continue; fi
  
  branch=$(git -C "$wt" branch --show-current 2>/dev/null)
  if [ -z "$branch" ]; then continue; fi
  
  # main에 이미 merge된 브랜치인지 확인
  if git branch --merged "$MAIN_BRANCH" | grep -q "$branch"; then
    echo "🧹 Removing merged worktree: $wt ($branch)"
    git worktree remove "$wt" 2>/dev/null
  fi
done

git worktree prune
echo "✅ Cleanup complete"

3. 리뷰 플로우

멀티 에이전트 결과물을 merge하기 전에 리뷰가 필요해요. 제가 쓰는 플로우입니다:

1. 에이전트 작업 완료 → 각자 브랜치에 커밋
2. integration 브랜치 생성 (main에서 분기)
3. 에이전트 브랜치를 integration에 순차 merge
   - conflict 발생 시 해당 에이전트에게 conflict 해결 요청
4. integration에서 통합 테스트 실행
5. 통과 시 main에 merge
6. 사용한 worktree 정리

main ─────────────────────────────────── merge ← integration
       ↘                                ↗
        integration ──── merge ← A, B, C
       ↗         ↗         ↗
Agent A   Agent B   Agent C
(wt-1)    (wt-2)    (wt-3)

이 플로우의 핵심요점은? main에 직접 merge하지 않는 거예요. integration 브랜치에서 먼저 합쳐보고, 문제없으면 main으로 올립니다.

4. CI 연동

CI/CD 파이프라인에서 worktree를 활용하면 빌드 속도를 올릴 수 있어요.

# .github/workflows/multi-agent.yml
name: Multi-Agent Build

on:
  push:
    branches: ['agent/*']

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      # 겹치는 파일 사전 감지
      - name: Check file overlap
        run: |
          BRANCHES=$(git branch -r --list 'origin/agent/*')
          for b1 in $BRANCHES; do
            for b2 in $BRANCHES; do
              if [ "$b1" \< "$b2" ]; then
                OVERLAP=$(git diff --name-only "$b1" "$b2" | sort | uniq -d)
                if [ -n "$OVERLAP" ]; then
                  echo "⚠️ Overlap detected: $b1 vs $b2"
                  echo "$OVERLAP"
                fi
              fi
            done
          done
      
      - name: Run tests
        run: npm test

이렇게 하면 에이전트 브랜치 간에 겹치는 파일을 merge 전에 미리 감지할 수 있어요. “이 두 에이전트가 같은 파일 건드렸으니 조심하세요”라고 알려주는 거죠.

5. .gitignore에 worktree 경로 추가하는 거 잊지 마세요

의외로 많이 놓치는 부분이에요:

# .gitignore에 worktree 경로는 추가할 필요 없어요
# worktree는 저장소 *외부*에 생성되니까
# 대신 IDE의 workspace 설정에서 제외해야 합니다

실은 .gitignore에 넣을 필요가 없어요. worktree는 보통 프로젝트 디렉토리 밖에 만드니까요. 대신 IDE가 상위 폴더를 워크스페이스로 열고 있다면, 다른 worktree 디렉토리가 검색에 포함될 수 있으니 IDE 설정에서 exclude 처리해야 합니다.

---

실전 운영 체크리스트 한 장 정리

여기까지 읽으셨으면, 이제 실제로 적용할 차례예요. 한 장짜리 체크리스트로 정리했습니다:

🔧 초기 세팅

• [ ] Git 버전 2.15+ 확인 (git --version)
• [ ] Claude Code CLI v2.1.49+ 확인 (claude --version)
• [ ] worktree 저장 디렉토리 위치 결정 (프로젝트 상위 디렉토리 권장)
• [ ] 네이밍 컨벤션 팀 합의 ({project}-{role}-{task})
• [ ] IDE worktree 지원 설정 확인

🚀 작업 시작

• [ ] git worktree add 또는 claude code -w 로 worktree 생성
• [ ] 각 worktree에서 의존성 설치 (npm install / pip install)
• [ ] 에이전트별 브랜치 이름 충돌 없는지 확인
• [ ] 태스크 간 파일 겹침 사전 체크

🔄 작업 중

• [ ] 각 에이전트는 자기 worktree에서만 작업
• [ ] 정기적으로 main(또는 integration) 브랜치 변경사항 pull
• [ ] git worktree list로 현재 상태 수시 확인
• [ ] 상호 의존성 있는 태스크는 순서 지정

🔀 Merge 단계

• [ ] integration 브랜치 생성 (main에서 분기)
• [ ] 에이전트 브랜치를 integration에 순차 merge
• [ ] conflict 발생 시 해당 에이전트 또는 수동 해결
• [ ] integration에서 통합 테스트 실행
• [ ] 통과 후 main에 merge

🧹 정리

• [ ] merge 완료된 worktree 즉시 삭제 (git worktree remove)
• [ ] 메타데이터 정리 (git worktree prune)
• [ ] 3일 이상 미사용 worktree 점검
• [ ] 장기 작업 중인 worktree는 lock 처리

📊 측정

• [ ] 충돌률 기록 (merge conflict / 총 merge 시도)
• [ ] Cycle Time 기록 (태스크 시작 ~ merge 완료)
• [ ] 1주일 단위로 기존 방식 대비 개선율 비교

---

내가 느낀 점

솔직히 처음에 git worktree를 에이전트용으로 쓸 생각은 안 했어요. 그냥 핫픽스할 때 편하게 쓰는 도구 정도로만 알았거든요.

근데 에이전트 3개를 동시에 돌리면서 매번 conflict 해결하느라 시간을 날릴 때, “이거 뭔가 근본적으로 잘못된 거 아닌가?” 하는 생각이 들었습니다. 에이전트가 코드를 빠르게 써주는 건 좋은데, 그걸 합치는 데 드는 시간이 작성 시간보다 길어지면 무슨 의미가 있나요.

worktree로 작업 환경을 물리적으로 분리하고 나니까, “아, 진작 이렇게 할 걸”이라는 생각이 들더라고요. 특히 각 에이전트의 작업 결과가 깔끔하게 각자 브랜치에 있으니까 리뷰할 때도 편해요. “이 에이전트는 이 파일들만 건드렸구나”가 한눈에 보이니까요.

---

솔직한 마음

불안한 부분도 있어요. Claude Code CLI의 --worktree 플래그가 아직 초기라서, 공식 문서가 부족하고 production에서의 안정성 데이터가 충분하지 않아요. “이거 써도 괜찮나?” 하는 마음이 있는 게 사실입니다.

그리고 worktree가 만능은 아니에요. 같은 파일을 동시에 수정해야 하는 상황이라면 결국 merge 시점에서 conflict가 나고, 그건 워크트리를 써도 피할 수 없어요. 태스크를 잘 나누는 게 워크트리보다 더 근본적인 해결책일 수도 있다는 생각도 합니다.

하지만 “작업 환경 분리”라는 개념 자체는 멀티 에이전트 개발에서 포기할 수 없는 전제 조건이에요. worktree가 아닌 다른 방법으로라도 — Docker 컨테이너든, VM이든 — 분리는 반드시 해야 합니다. 그중에서 worktree가 가장 가볍고 Git 네이티브한 방법이라서 저는 이걸 선택했어요.

---

앞으로 할 것들

1. 이번 주: 실제 프로젝트에서 에이전트 3개로 1주일 실험 → 충돌률/Cycle Time 데이터 수집
2. 이번 달: Claude Code CLI --worktree 옵션의 정식 문서, 릴리스 노트 추적
3. 관찰: 공식 cleanup 정책, CI 연동 가이드가 Anthropic 문서에 추가되는지 모니터링
4. 공유: 실험 데이터가 쌓이면 worktree vs 기존 방식 비교 결과 후속 글 작성

---

FAQ

Q1. git worktree와 git clone의 차이가 뭔가요?

git clone은 저장소를 통째로 복제합니다. .git 디렉토리, 히스토리, remote 설정 모두 별도로 생기죠. git worktree는 .git 디렉토리를 공유하면서 작업 디렉토리만 분리합니다. 디스크 절약 + 히스토리 동기화 자동.

Q2. worktree에서 만든 커밋은 메인 저장소에서 바로 보이나요?

네, 보입니다. .git을 공유하니까요. worktree에서 커밋하면 메인 저장소에서 git log --all로 바로 확인 가능해요.

Q3. Claude Code CLI --worktree 플래그는 어떤 버전부터 지원하나요?

2026년 2월 기준 v2.1.49부터 도입되었어요. 정확한 안정화 버전은 릴리스 노트를 확인하세요.

Q4. worktree를 수동으로 삭제해도 되나요?

되긴 하는데, 메타데이터가 남아요. rm -rf로 디렉토리만 지우면 .git/worktrees/에 찌꺼기가 남습니다. 반드시 git worktree remove를 쓰거나, 수동 삭제 후 git worktree prune을 실행하세요.

Q5. 한 저장소에 worktree를 최대 몇 개까지 만들 수 있나요?

Git 자체에 제한은 없어요. 다만 디스크 공간과 시스템 리소스에 의해 실질적으로 제한됩니다. 모노레포가 아닌 일반 프로젝트라면 10개 이내로 운영하는 게 실용적이에요.

Q6. worktree 간에 node_modules를 공유할 수 있나요?

symlink로 공유하는 트릭이 있지만, 브랜치별로 package.json이 다를 수 있으니 추천하지 않아요. pnpm 같은 전역 캐시 기반 패키지 매니저를 쓰면 중복 설치를 줄일 수 있습니다.

Q7. worktree와 Docker를 함께 쓸 수 있나요?

네, 각 worktree마다 별도 Docker 컨테이너를 실행하면 환경 격리가 더 확실해져요. 단, 그만큼 리소스를 더 쓰니까 프로젝트 규모에 맞게 판단하세요.

---

결론

멀티 에이전트 개발에서 병렬 작업 충돌은 피할 수 없는 문제예요. 하지만 git worktree로 작업 환경을 물리적으로 분리하면, “어디서 충돌이 날지”를 예측 가능한 시점(merge 시점)으로 모을 수 있습니다.

Claude Code CLI v2.1.49의 --worktree 플래그가 이 과정을 자동화해주고 있고, 이제 CLI 환경에서도 에이전트별 격리가 한 줄 명령으로 가능해졌어요.

핵심은 세 가지입니다:

1. worktree로 물리적 격리: 파일 충돌과 컨텍스트 오염을 원천 차단
2. integration 브랜치로 단계적 통합: main 보호 + 충돌 예측 가능성 확보
3. 정리 정책으로 위생 관리: worktree가 쌓이지 않도록 자동화

이 체크리스트를 따라서 한번 돌려보세요. 충돌률이 확 줄어드는 걸 체감하실 거예요.

---

참고 자료

• Git 공식 문서 — git worktree (⭐⭐⭐ 공식)
• Boris Cherny Threads — Claude Code CLI git worktree 지원 (⭐⭐⭐ Anthropic 소속)
• Claude Code 공식 문서 (⭐⭐⭐ 공식)