git worktree로 Claude Code 여러 작업 동시에 돌리기: 브랜치 충돌 없이 병렬 개발하는 워크플로우

1. 왜 여러 세션에서 브랜치가 깨질까

한 폴더에서 Claude Code 세션을 여러 개 열고 각각 다른 작업을 시키면, 세션 간 간섭이 생기기 쉽습니다. 한 세션이 브랜치를 바꾸거나 파일을 수정하는 순간 다른 세션이 보고 있던 작업 공간도 함께 변하기 때문입니다.

예를 들어 한 세션은 로그인 기능을 만들고, 다른 세션은 랜딩 페이지를 수정한다고 해봅시다. 두 작업이 서로 다른 브랜치라 해도 같은 디렉터리를 공유하면 git switch와 파일 변경이 상대 세션의 전제를 흔들 수 있습니다. 문제는 Claude Code가 아니라 작업 공간이 하나뿐이라는 데 있습니다.

현재 브랜치로 충분한 경우

작업이 작고 순차적이라면 worktree까지 만들 필요는 없습니다. 다음 조건에 가깝다면 현재 브랜치에서 처리해도 됩니다.

한 번에 실행하는 코딩 세션이 하나다.
변경 파일이 적고, 작업 사이에 커밋한다.
브랜치를 자주 전환하지 않는다.
실패해도 되돌릴 기준점이 명확하다.

worktree로 분리할 신호

다음 중 하나라도 해당하면 작업 공간을 나누는 편이 안전합니다.

세션 두 개 이상이 동시에 파일을 수정한다.
기능별로 독립적인 브랜치가 필요하다.
테스트나 빌드가 오래 걸려 다른 작업을 병행해야 한다.
한 세션이 탐색 작업을 하는 동안 다른 세션은 구현을 진행한다.

조코헌트에는 현재 프로덕트 239개와 출시 메이커 187명이 등록되어 있습니다. 혼자 만드는 사람이 많을수록 시간을 늘리기보다 작업을 겹쳐 실행하는 구조가 중요해집니다.

2. worktree의 핵심 모델

git worktree는 하나의 Git 저장소에 여러 작업 디렉터리를 연결하는 기능입니다. 각 디렉터리는 서로 다른 브랜치를 체크아웃하지만 커밋 객체와 원격 저장소 정보는 공유합니다. 즉, 저장소를 복제하지 않고도 작업 공간만 분리할 수 있습니다.

# 기본 작업 디렉터리에서 기능 브랜치 생성
git switch -c feat/landing

# 별도 디렉터리와 브랜치를 함께 생성
git worktree add ../my-app-auth -b feat/auth main

# 현재 연결된 worktree 확인
git worktree list

실제 경로는 프로젝트 상황에 맞게 정하면 됩니다. 예를 들어 my-app, my-app-auth, my-app-billing처럼 원래 폴더와 나란히 두면 터미널을 잘못 열 가능성이 줄어듭니다.

디렉터리마다 확인할 것

새 세션을 열 때는 작업 지시보다 먼저 위치와 브랜치를 확인하세요.

pwd
git branch --show-current
git status --short

여기서 브랜치가 예상과 다르거나 이미 수정된 파일이 보이면 작업을 시작하지 않는 편이 좋습니다. 각 worktree는 자체 HEAD와 인덱스를 가지므로, 한 디렉터리에서 커밋해도 다른 디렉터리의 체크아웃 상태가 바뀌지는 않습니다.

3. Claude Code 세션을 안전하게 배치

각 worktree를 별도의 Claude Code 세션에 연결하고, 세션마다 담당 범위를 짧게 고정하세요. “앱을 완성해줘”처럼 넓은 지시보다 “app/auth와 관련 테스트만 수정하고 결제 코드는 건드리지 말 것”처럼 경계를 주는 편이 병렬 작업에 적합합니다.

조코헌트 집계에서 AI 도구 분야는 42%, 개발자 도구 분야는 23%입니다. AI 코딩 도구를 실제 개발 흐름에 넣을수록 모델 선택보다 세션 간 경계와 변경 관리가 더 중요한 운영 문제가 됩니다.

세션 시작 체크리스트

올바른 worktree 디렉터리에서 터미널을 연다.
현재 브랜치와 변경 상태를 확인한다.
CLAUDE.md와 프로젝트 규칙을 읽게 한다.
수정 허용 경로와 금지 경로를 명시한다.
완료 조건을 테스트, 타입 체크, 커밋 단위로 적는다.

프로젝트 규칙 파일을 아직 정리하지 않았다면 CLAUDE.md 작성법의 구조를 참고할 수 있습니다. 반복되는 포맷이나 검증 절차는 Claude Code 훅 활용법처럼 자동화하면 세션마다 설명하는 비용도 줄어듭니다.

환경변수 파일과 로컬 데이터베이스처럼 worktree마다 자동으로 생기지 않는 파일도 있습니다. 복사할 때 비밀키가 커밋되지 않는지 확인하고, 공유 파일을 동시에 수정해야 한다면 담당 세션을 하나로 정하세요.

4. 충돌을 줄이는 병렬 작업 규칙

파일 충돌보다 계약 충돌을 먼저 막기

서로 다른 파일을 수정해도 같은 기능의 데이터 구조나 함수 인터페이스를 바꾸면 병합 시 충돌합니다. 병렬화하기 좋은 조합은 화면과 독립적인 테스트, API 구현과 문서처럼 의존성이 약한 작업입니다.

반대로 다음 파일은 여러 세션이 동시에 만지지 않는 편이 안전합니다.

데이터베이스 스키마와 마이그레이션
공통 타입과 인증 로직
package.json, 잠금 파일, 전역 설정
라우팅 구조와 공통 레이아웃

공통 기반을 먼저 정한 뒤 세션을 나누거나, 한 세션이 기반 변경을 끝낸 다음 다른 세션이 최신 브랜치에서 시작하도록 순서를 잡으세요.

커밋을 병합 가능한 단위로 만들기

각 세션에는 작업이 끝나면 다음을 요청할 수 있습니다. “변경 범위를 요약하고, 관련 테스트를 실행한 뒤, 하나의 목적을 설명하는 커밋을 만들어줘.” 커밋이 작으면 리뷰와 되돌리기가 쉬워집니다.

병합 전에는 git diff main...feat/auth처럼 차이를 확인하고, 한 브랜치씩 통합하세요. 여러 브랜치를 한꺼번에 합치기보다 첫 번째 병합 후 테스트하고 다음 작업으로 넘어가는 흐름이 1인 개발자에게 관리하기 좋습니다. Codex로 코드 리뷰 받기처럼 diff 중심으로 검토하는 습관도 함께 적용하면 좋습니다.

5. 끝내고 정리하는 루틴

기능이 병합된 뒤에는 worktree를 계속 쌓아두지 말고 정리합니다.

git worktree list
git status --short -- ../my-app-auth
git worktree remove ../my-app-auth
git worktree prune

삭제 전에 확인할 항목

해당 worktree에 미커밋 변경이 없는가
필요한 커밋과 테스트 결과를 기록했는가
원격 브랜치나 리뷰 중인 변경이 남아 있지 않은가
로컬에서만 필요한 설정이나 로그를 별도로 보관했는가

정리 명령에 강제 옵션을 붙이는 것은 신중해야 합니다. 남은 변경을 잃을 수 있으므로, 상태가 깨끗하지 않다면 먼저 diff를 저장하거나 커밋한 뒤 제거하세요.

worktree의 핵심은 세션을 많이 여는 데 있지 않습니다. 각 세션이 독립된 폴더, 명확한 브랜치, 좁은 작업 범위를 갖도록 만드는 데 있습니다. 작은 수정은 현재 브랜치에서 빠르게 처리하고, 서로 다른 기능을 동시에 개발할 때만 worktree를 꺼내 쓰면 복잡도와 생산성 사이의 균형을 잡을 수 있습니다.