Git worktree랑 branch 차이 3분 정리 - AI 에이전트가 worktree 쓰는 진짜 이유

다들 worktree 좋다고 해서 검색해봤는데, 진짜일까요?

저도 처음엔 “branch면 충분한데 뭐가 더 필요해?” 했거든요.

근데 AI 에이전트 여러 개 돌리면서 생각이 바뀌었어요.

branch로는 해결 안 되는 게 있더라고요.

Git worktree랑 branch 차이 3분 정리 - AI 에이전트가 worktree 쓰는 진짜 이유

Git branch란? – 논리적 개념

Git branch란? 커밋의 흐름을 나타내는 포인터로, 하나의 작업 디렉토리에서 다양한 코드 상태를 전환할 수 있게 해주는 Git의 기본 버전 관리 단위입니다.

Branch… 뭔 소린지 모르겠죠?

쉽게 말할게요.

“작업의 갈래를 나누는 방법”

끝. 이게 전부예요.

main에서 작업하다가 “이거 새 기능 만들어야겠다” 싶으면 branch 하나 파서 거기서 작업하고, 완성되면 다시 합치는 거죠.

# 브랜치 사용 예시
git checkout main
git checkout feature-branch  # 동일 디렉토리에서 전환

근데 진짜 웃긴 게요.

한 번에 하나만 볼 수 있어요.

feature-branch 보고 싶으면 main을 내려놓고, main 보고 싶으면 feature-branch를 내려놓고.

이게 branch의 본질이에요. 논리적으로는 여러 개 존재하지만, 물리적으로는 하나만 활성화됩니다.

Git worktree란? – 물리적 개념

Git worktree란? 같은 저장소의 여러 브랜치를 각각 독립된 디렉토리에 동시에 체크아웃하여 병렬 작업이 가능하게 해주는 Git 고급 기능입니다. 2015년 Git 2.5 버전부터 도입되었습니다.

Worktree는 개념이 좀 다릅니다.

“같은 저장소를 여러 폴더에 펼쳐놓는 방법”

# Worktree 사용 예시
# 현재 디렉토리: ~/project (main 브랜치)
git worktree add ../project-feature feature-branch

# 이제 두 디렉토리가 동시에 존재:
# ~/project (main 브랜치)
# ~/project-feature (feature-branch)

자, 이제 뭐가 다른지 보이죠?

Branch는 “전환”이고, Worktree는 “복제”에요. (정확히는 복제가 아니라 링크지만, 사용자 입장에서는 복제처럼 보임)

둘의 차이가 뭔데?

여러분 이거 경험 있죠?

feature 작업하다가 갑자기 “main에 버그 발견! 당장 고쳐야 함!” 이런 상황.

Branch 방식의 문제점

# Feature 작업 중...
git stash  # 현재 작업 임시 저장
git checkout main
# 버그 수정
git checkout feature
git stash pop  # 작업 복구

이 과정에서:

IDE가 파일 변경 감지하느라 버벅
LSP 서버 재시작
빌드 캐시 무효화
node_modules 재설치 (경우에 따라)
작업 컨텍스트 손실

stash 안 하면? → 변경사항 날아가거나 conflict 지옥

Worktree 방식의 해결

# Feature 작업 중인 ~/project-feature는 그대로 두고
cd ~/project-main
# 여기서 버그 수정
# 끝나면 다시 feature로 복귀
cd ~/project-feature

아무것도 안 날아가요. 두 작업 공간이 독립적이니까.

구분	Branch	Worktree
동시 작업	❌ 한 번에 하나만	✅ 여러 브랜치 동시 가능
디렉토리	하나 (파일 교체)	여러 개 (독립 폴더)
전환 비용	있음 (checkout)	없음 (디렉토리 이동)
환경 오염	있음 (빌드 파일 섞임)	없음 (완전 격리)
사용 난이도	쉬움	약간 높음

AI 에이전트가 Worktree를 쓰는 이유

근데 진짜 의외였던 게요.

요즘 AI 코딩 도구들 보면 전부 worktree 얘기하더라고요.

왜일까요?

1. 병렬 작업의 필연성

AI 에이전트는 동시에 여러 작업을 수행합니다.

# Branch 방식의 충돌
Agent A: feature-1 작업 중
Agent B: "잠깐, main에서 버그 픽스 좀..." 
→ Agent A의 작업 공간이 날아감 (checkout으로 파일 교체)

# Worktree 방식
Agent A: ~/project/main (계속 작업)
Agent B: ~/project/feature-1 (독립 작업)
Agent C: ~/project/hotfix (긴급 패치)
→ 모두 동시 실행 가능

사람은 순차적으로 생각하잖아요. “이거 끝나면 저거 하지” 이런 식으로.

근데 AI는 병렬로 생각해요. “이것도 하고 저것도 하고 동시에”

Branch = 순차 사고, Worktree = 병렬 사고

이게 핵심이에요.

2. 컨텍스트 유지

Dev.to의 한 개발자는 실제로 5개 AI 에이전트를 worktree로 병렬 실행해서 생산성이 5배 올랐다고 보고했습니다 (2026년 1월 기준).

왜 그럴까요?

Branch checkout할 때마다 발생하는 숨은 비용이 어마어마하거든요:

# Branch checkout의 숨은 비용
git checkout feature-branch
# → IDE가 파일 변경 감지
# → LSP 서버 재시작
# → 빌드 캐시 무효화
# → 의존성 재설치
# → 에이전트의 메모리/컨텍스트 손실

Worktree는 각 디렉토리가 완전히 독립이니까 이런 비용이 없어요.

각 에이전트가 자기 공간에서 자기 빌드, 자기 캐시, 자기 의존성 유지하는 거죠.

3. 환경 오염 방지

이거 정말 짜증나는 문제인데요.

branch 전환하면 빌드 아티팩트가 섞여요.

# main에서 빌드
npm run build  # dist/ 폴더 생성

# feature로 전환
git checkout feature
# dist/ 폴더는 그대로 남아있음!
# 새로 빌드하면 이전 빌드와 섞임

Worktree는 이런 일이 없어요. 각 폴더가 독립이니까.

Nx Blog (2026년 2월)에서도 이 문제를 강조했어요:

“Branch switching causes environment contamination. Build artifacts and node_modules cross-contaminate between branches.”

4. 에이전트 자율성

AI 에이전트는 사람처럼 “작업 전환”을 하지 않아요.

각 에이전트가 자기 workspace를 가지고 독립 실행됩니다.

# 에이전트 시스템 설계 예시
agent_pool = {
    "main": Agent(workspace="~/project/main"),
    "feature-1": Agent(workspace="~/project/feature-1"),
    "review": Agent(workspace="~/project/review"),
}

# 동시 실행
asyncio.gather(
    agent_pool["main"].monitor(),
    agent_pool["feature-1"].develop(),
    agent_pool["review"].code_review(),
)

각 에이전트가 독립된 파일 시스템에서 작업해야 충돌이 없어요.

이게 worktree가 AI 시대에 필수가 된 이유예요.

Worktree가 유용한 실전 상황

제가 3주 동안 써본 결과, 진짜 유용한 케이스들이 있더라고요.

상황 1: 긴급 패치

feature 작업 중인데 production에 버그 발견.

# 기존 feature 작업은 그대로 두고
git worktree add ../hotfix main
cd ../hotfix
# 핫픽스 작업 후 바로 복귀

stash 필요 없음. 걍 폴더만 이동하면 끝.

상황 2: 코드 리뷰

PR 리뷰하면서 내 작업도 유지하고 싶을 때.

git worktree add ../review-pr-123 pr-123
# 별도 디렉토리에서 리뷰
# 끝나면 삭제
git worktree remove ../review-pr-123

리뷰하면서 내 branch는 건드리지 않아요.

상황 3: 빌드 테스트

여러 브랜치 동시 빌드 비교.

git worktree add ../build-v1 release-1.0
git worktree add ../build-v2 release-2.0

# 터미널 2개 띄워서 동시 빌드
# v1, v2 성능 비교

이거 진짜 편해요. 왔다갔다 안 해도 되니까.

상황 4: CI/CD 파이프라인

여러 환경을 동시에 유지해야 할 때.

~/myapp/main          # 프로덕션 모니터링
~/myapp/staging       # 스테이징 테스트
~/myapp/experiment-1  # 새 기능 실험
~/myapp/hotfix        # 긴급 패치 대기

각각 독립된 프로세스 실행:

서로 다른 포트에서 서버 구동
서로 다른 DB 연결
서로 다른 빌드 설정

이게 worktree의 진짜 파워예요.

주의사항 & 제약

완벽해 보이는 worktree지만, 함정도 있어요.

제약 1: 같은 브랜치 중복 불가

git worktree add ../copy-main main
# fatal: 'main' is already checked out at '/original/path'

하나의 branch는 하나의 worktree에만 체크아웃 가능해요.

이유는 간단해요. 두 곳에서 동시에 같은 branch를 수정하면 충돌 나니까.

제약 2: 디렉토리 위치 중요

# ❌ 나쁜 예 (프로젝트 안에 생성)
git worktree add ./feature feature-branch

# ✅ 좋은 예 (형제 디렉토리로 생성)
git worktree add ../project-feature feature-branch

프로젝트 안에 만들면 Git이 혼란스러워해요. 무시 목록 설정도 복잡해지고.

제약 3: 디스크 용량

각 worktree가 working files를 별도로 가지니까, 용량이 좀 먹어요.

물론 .git 폴더는 공유하니까 clone보다는 훨씬 나아요.

구분	Clone (3개)	Worktree (3개)
.git 폴더	3개 (각 100MB)	1개 (100MB)
작업 파일	3개 (각 50MB)	3개 (각 50MB)
총 용량	450MB	250MB

대략 반 정도 절약되네요.

Bare Repo 패턴 (고급)

요즘 권장되는 패턴이 있는데요. Bare Repository 방식이에요.

기존 방식:

~/project/          # main worktree (특별 대우)
~/project-feature/  # 추가 worktree
~/project-hotfix/   # 추가 worktree

Bare Repo 방식:

~/project.git/      # bare repo (작업 파일 없음)
~/project-main/     # worktree
~/project-feature/  # worktree
~/project-hotfix/   # worktree

모든 worktree를 동등하게 취급해요.

Agent of Empires 같은 도구는 이걸 자동화해줘요. 설정 한 번이면 끝.

솔직히 처음엔 “이게 뭔 차이야?” 했는데, 써보니까 관리가 더 깔끔하더라고요.

Branch만으로 충분한 경우

worktree가 항상 정답은 아니에요.

이런 경우엔 그냥 branch 쓰세요:

순차 작업

feature 개발 → 리뷰 → 머지 → 다음 feature

한 번에 하나씩만 하면 branch로 충분해요.

간단한 수정

"오타 하나 고치기"
"주석 추가하기"

이런 거에 worktree 쓰면 오버 엔지니어링이에요.

디스크 공간 부족

노트북이나 SSD 용량 빡빡하면 worktree 여러 개 만들기 부담스러워요.

팀 협업 초기

팀원들이 worktree 모르면 혼란스러워요. “왜 프로젝트가 3개야?” 이런 반응.

내가 느낀 점

3주 동안 worktree 써보면서 느낀 건요.

“이거 branch 대체가 아니라 보완이구나”

branch는 기본. worktree는 옵션.

대부분 작업은 branch로 충분해요. 근데 병렬 작업이 필요한 순간이 오면, worktree는 진짜 구원자예요.

특히 AI 에이전트 여러 개 돌릴 때. 각 에이전트에게 독립 공간 줘야 하니까 worktree가 필수더라고요.

솔직한 마음

처음엔 “왜 이렇게 복잡하게 만들었어?” 했어요.

근데 알고 보니까 Git 설계가 원래 이랬던 거예요. Branch는 “논리적 분기”, Worktree는 “물리적 작업 공간”

이 둘이 독립적인 개념인 거죠.

AI 시대가 오면서 병렬 작업이 중요해졌고, 그래서 worktree가 다시 조명받는 거고요.

솔직히 아직도 완전히 익숙하진 않아요. 가끔 “어? 이거 어느 폴더에서 작업했더라?” 헷갈릴 때 있어요.

근데 점점 손에 익는 중이에요.

앞으로 할 것들

이제 제가 실천하려는 것들이에요:

1. Bare Repo 패턴으로 전환

기존 프로젝트들 bare repo로 마이그레이션해볼 생각이에요.

# 마이그레이션 계획
git clone --bare . ../myproject.git
cd ../myproject.git
git worktree add ../myproject-main main

2. AI 에이전트 워크플로우 개선

Cursor, Windsurf 같은 도구들 worktree 기반으로 재설정.

각 에이전트마다 독립 workspace 할당.

3. 팀 가이드 문서 작성

팀원들한테 worktree 개념 공유하고, 언제 쓰면 좋은지 가이드 만들기.

“이런 상황엔 worktree 고려해보세요” 체크리스트 형태로.

4. 자동화 스크립트

# 자주 쓰는 worktree 패턴 스크립트화
wt-feature() {
  git worktree add ../$(basename $PWD)-feature-$1 -b feature/$1
}

wt-hotfix() {
  git worktree add ../$(basename $PWD)-hotfix main
}

이런 헬퍼 함수 만들어서 쉘에 추가하기.

FAQ

Q: Worktree 생성하면 clone하는 건가요?

A: 아니요. Clone은 전체 저장소(.git 포함)를 복제하는 거고, worktree는 작업 파일만 별도 디렉토리에 펼치는 겁니다. .git 폴더는 공유하므로 훨씬 가볍습니다. 2026년 2월 기준 Git 공식 문서에 따르면, worktree는 git clone 대비 약 50% 적은 디스크 용량을 사용합니다.

Q: Worktree 여러 개 만들면 느려지나요?

A: Git 명령어 자체는 느려지지 않습니다. .git 폴더를 공유하니까요. 다만 각 worktree에서 빌드하면 당연히 시간이 좀 걸리죠. 병렬로 빌드한다면 오히려 시간 절약될 수 있어요.

Q: 회사 프로젝트에 써도 되나요?

A: Git 2.5(2015년) 이후 공식 기능이므로 안정적입니다. 다만 팀원들이 모르면 혼란스러울 수 있으니 가이드 공유가 필요합니다.

Q: 어떻게 삭제하나요?

A: git worktree remove <경로> 명령어로 삭제합니다. 디렉토리도 같이 지워져요. 또는 수동으로 폴더 삭제 후 git worktree prune으로 정리 가능합니다.

Q: IDE에서 worktree 지원하나요?

A: VS Code는 각 worktree를 별도 폴더로 열면 됩니다. JetBrains 계열은 2024년 버전부터 worktree 감지 기능이 추가됐어요. Cursor나 Windsurf는 자동으로 감지합니다.

Q: Branch 대신 worktree만 쓰면 안 되나요?

A: 안 됩니다. Worktree도 결국 branch를 체크아웃하는 거예요. Branch는 필수, worktree는 선택입니다. “branch를 여러 폴더에 동시에 펼치는 도구”가 worktree예요.

Q: Worktree에서 커밋하면 어떻게 되나요?

A: 정상적으로 커밋됩니다. 해당 branch에 커밋이 추가되고, 다른 worktree에서 git fetch 없이 바로 보입니다. 모든 worktree가 같은 .git을 공유하니까요.

Q: 같은 branch를 2개 worktree에서 체크아웃할 수 있나요?

A: 안 됩니다. 2개 장소에서 동시에 같은 branch를 수정하면 충돌이 나니까 Git이 막습니다. 각 worktree는 서로 다른 branch를 체크아웃해야 해요.

결론

Worktree는 branch의 대체가 아니라 보완이에요.

Branch는 “무엇을 작업할지”를 결정하고, Worktree는 “어디서 작업할지”를 결정합니다.

AI 시대에 병렬 작업이 중요해지면서, worktree는 이제 필수 스킬이 됐어요.

여러분도 한번 써보세요. 처음엔 어색한데, 익숙해지면 없으면 불편해요.

참고 자료

Git Worktrees for AI Coding: Run Multiple Agents in Parallel – Dev.to (2026년 2월)
Git Worktrees: How to Have Multiple AI Agents Working Simultaneously – frr.dev (2026년 2월)
How Git Worktrees Changed My AI Agent Workflow – Nx Blog (2026년 2월)
Git Worktrees for Parallel AI Development – Agent of Empires (2026년)
What’s the Difference Between Git Worktree and Git Branch? – Dev.tldrlss (2026년 2월)
Git Official Documentation – Worktrees