최근 제 업무에서 Claude Code가 차지하는 비중은 상당합니다. 실제로 대부분의 코드를 Claude에게 맡기고 있고, 이제는 “코드를 짠다”기보다 “작업을 설계한다”는 표현이 더 어울릴 정도입니다.
이쯤 되면 자연스럽게 이런 생각이 듭니다.
Claude를 여러 개 동시에 돌리면 더 빠르지 않을까?
결론부터 말하면 맞는 생각입니다. 다만 아무 준비 없이 같은 프로젝트 폴더에서 여러 Claude Code 세션을 실행하면, 생각보다 빠르게 문제를 맞이하게 됩니다. 파일이 덮어써지고, 버그가 발생하며, 결과물의 품질이 눈에 띄게 떨어집니다.
이 글에서는 Git Worktree를 활용해 Claude Code를 안전하게 병렬 실행하는 방법을 공유합니다.
Claude Code의 동작 방식을 이해하려면 먼저 컨텍스트 윈도우를 알아야 합니다.
컨텍스트 윈도우는 Claude가 현재 세션에서 참고할 수 있는 일종의 작업 메모리입니다.
여기에는 지금까지의 대화 내용, 읽어들인 파일, 실행한 명령의 결과, CLAUDE.md 설정 등이 모두 포함됩니다. Claude Opus 4.5 기준으로 약 200K 토큰 정도를 담을 수 있습니다.
문제는 이 공간이 무한하지 않다는 점입니다. 작업이 길어질수록 컨텍스트는 점점 차고, 대략 75% 정도가 채워지면 Claude Code는 자동으로 이전 대화를 요약해 공간을 확보합니다. 이 과정을 흔히 압축, compact라고 부릅니다.
압축이 한두 번이면 괜찮지만, 반복되면 문제가 생깁니다. 초기에 전달했던 중요한 지시가 누락되거나, 요약된 내용을 다시 요약하면서 정확도가 눈에 띄게 떨어집니다. 실제로 작업 만족도가 급격히 낮아진다는 유저를 많이 보았습니다.
하지만 Claude Code의 컨텍스트 윈도우는 세션마다 완전히 독립적입니다. 세션 A와 세션 B는 서로의 맥락을 전혀 모릅니다.
그래서 서로 다른 작업을 시킬 경우에는 반드시 세션을 분리하는 것이 좋습니다.
가장 흔한 문제입니다.
세션 A가 auth.js를 수정해 저장한 직후, 세션 B가 같은 파일을 수정해 저장하면 세션 A의 변경 사항은 그대로 사라집니다.
더 큰 문제는 각 세션이 이 사실을 모른 채 작업을 계속 진행한다는 점입니다. 서로 다른 가정을 기반으로 코드가 쌓이고, 최종 결과물의 품질은 급격히 떨어집니다.
한 세션의 변경 사항이 다른 세션의 파일 읽기에 영향을 주는 경우도 많습니다.
예를 들어 세션 B가 파일을 읽었는데, 그 내용이 방금 세션 A가 수정한 버전이라면 세션 B의 컨텍스트에는 자신이 만들지 않은 코드가 들어가게 됩니다. 이 상태에서 코드를 생성하거나 수정하면, 의도하지 않은 버그가 발생할 가능성이 매우 높아집니다.
같은 브랜치에서 여러 세션이 동시에 커밋을 만들면 히스토리도 빠르게 꼬입니다. 나중에 어떤 변경이 어떤 의도로 들어간 것인지 추적하기 어려워지고, 리뷰와 병합 비용이 크게 증가합니다.
이 문제를 해결하는 가장 깔끔한 방법이 Git Worktree입니다.
Git Worktree는 하나의 Git 저장소에서 여러 브랜치를 각각 다른 폴더에 동시에 체크아웃할 수 있게 해주는 기능입니다. 겉보기에는 프로젝트 폴더를 통째로 복사한 것처럼 보이지만, 실제로는 훨씬 효율적으로 동작합니다.
일반적으로 이런 상황을 많이 겪습니다.
feature-a 브랜치에서 작업 중hotfix 브랜치로 전환해야 하고git stash로 작업을 임시 저장한 뒤git stash pop을 실행작업 흐름이 끊기고, 실수할 여지도 많습니다.
Worktree를 사용하면 브랜치마다 폴더가 생깁니다.
my-project에는 mainmy-project-feature-a에는 feature-amy-project-hotfix에는 hotfix브랜치를 바꿀 필요 없이, 그냥 폴더를 이동하면 됩니다.
중요한 점은 이 폴더들이 같은 Git 저장소를 공유한다는 것입니다.
.git 디렉토리는 원본에만 있고, 각 worktree에는 이를 가리키는 링크만 존재합니다. 덕분에 디스크 사용량도 적고, git fetch 같은 작업도 한 번에 반영됩니다.
기본적인 사용 명령어는 다음과 같습니다.
git worktree add ../project-feature-a -b feature-a git worktree add ../project-bugfix bugfix-branch git worktree list git worktree remove ../project-feature-a
인증 시스템 구현, 대시보드 개발, 로그인 버그 수정을 동시에 진행한다고 가정해봅시다.
먼저 프로젝트 루트로 이동합니다.
cd ~/projects/my-app
작업별 worktree를 생성합니다.
git worktree add ../my-app-auth -b feature/auth git worktree add ../my-app-dashboard -b feature/dashboard git worktree add ../my-app-hotfix -b hotfix/login-bug
이제 각 폴더에서 터미널을 열고 Claude Code를 실행합니다.
cd ../my-app-auth claude "JWT 기반 인증 시스템을 구현해줘"
cd ../my-app-dashboard claude "관리자 대시보드를 만들어줘"
cd ../my-app-hotfix claude "로그인 실패 시 에러 메시지가 안 뜨는 버그를 수정해줘"
각 Claude는 완전히 독립된 폴더와 컨텍스트에서 작업합니다. 파일 충돌도 없고, 컨텍스트가 섞일 일도 없습니다.
Worktree는 파일 시스템을 분리합니다.
따라서 node_modules, .venv 같은 개발 환경도 각 worktree마다 따로 준비해야 합니다.
Node.js 프로젝트라면 각 폴더에서 npm install을,
Python 프로젝트라면 가상 환경을 각각 생성해야 합니다.
작업이 끝나면 브랜치를 병합합니다.
cd ~/projects/my-app git merge feature/auth git merge feature/dashboard git merge hotfix/login-bug
또는 PR을 통해 리뷰 후 병합해도 됩니다. 병합이 끝났다면 worktree를 정리합니다.
git worktree remove ../my-app-auth git worktree remove ../my-app-dashboard git worktree remove ../my-app-hotfix
Worktree로 격리를 확보했다고 끝은 아닙니다. 몇 가지는 여전히 신경 써야 합니다.
프론트엔드 UI 작업과 백엔드 리팩토링처럼 영역이 분리된 작업은 병렬화에 적합합니다. 반대로 핵심 설정 파일이나 대규모 리팩토링처럼 의존성이 높은 작업은 병렬 실행을 피하는 게 좋습니다.
CLAUDE.md를 적극 활용하는 것도 도움이 됩니다.각 worktree 루트에 현재 작업 목표, 기술 스택, 수정 금지 파일 등을 명시해두면 Claude가 훨씬 안정적으로 작업합니다.
기능 단위로 커밋을 남기고, 장시간 작업 시에는 주기적으로 main과 리베이스하면 병합 시 충돌을 크게 줄일 수 있습니다.
여러 Claude를 동시에 실행하면 사용량이 빠르게 늘어납니다. Usage Limit을 염두에 두고 작업해야 합니다.
Git Worktree와 Claude Code의 조합은 여러 명의 개발자와 병렬로 협업하는 것과 매우 비슷합니다. 각 Claude가 독립된 공간에서 작업하고, 결과만 깔끔하게 병합하면 됩니다.
10분짜리 작업에 worktree를 만드는 건 과합니다.
하지만 30분 이상 걸리는 독립적인 작업 여러 개를 동시에 처리해야 한다면, 이 방법은 개발 속도를 확실하게 끌어올려 줍니다.