작업 중인 브랜치를 멈춰두고 급한 버그를 처리하려다 stash만 늘어난 경험이 있다면, git worktree가 왜 다시 주목받는지 바로 이해할 수 있습니다. GitHub Blog는 이 기능을 단순한 Git 고급 기능이 아니라, 병렬 작업과 에이전트 협업에 맞는 기본 단위로 봅니다.
먼저 결론부터 말하면, worktree는 브랜치보다 “병렬 작업”에 더 잘 맞는 실행 단위입니다. 같은 저장소를 여러 작업 디렉터리로 나누면, 한쪽 컨텍스트를 유지한 채 다른 일도 동시에 진행할 수 있습니다.
2026-07-15 · GitHub Blog 원문 스냅숏 기준입니다.
이 글에서 다루는 내용은 세 가지입니다.
- worktree가 브랜치와 stash보다 편한 순간
git worktree add와git worktree remove가 어떤 흐름을 만드는지- 에이전트와 인간이 병렬로 움직일 때 worktree가 왜 유리한지
배경 / 왜 필요한가?
브랜치 전환 자체는 익숙합니다. 문제는 “지금 하던 일”이 머릿속과 에디터에 깊게 박혀 있을 때 생깁니다.
긴 기능 작업 중 급한 핫픽스가 들어오면 보통은 stash를 남기고 main으로 이동한 뒤 새 브랜치를 만들고, 수정하고, 다시 돌아옵니다. 단순해 보이지만 실제로는 파일 재로딩, 의존성 재설치, 기억 복원이 따라옵니다.
GitHub Blog가 강조하는 포인트도 여기입니다. worktree는 이 전환 비용을 줄여서, 한 저장소 안에서 여러 작업을 동시에 유지하게 해 줍니다.
이 흐름은 AI 에이전트가 여러 세션을 병렬로 돌리는 요즘의 작업 방식과도 잘 맞습니다. 인간도, 에이전트도, 같은 저장소를 두고 각각 독립된 작업 공간을 가지면 덜 흔들립니다.
핵심 개념
worktree의 핵심은 간단합니다. 하나의 Git 저장소에서 여러 작업 디렉터리를 분리해 쓸 수 있다는 점입니다.
flowchart LR
A[하나의 저장소] --> B[원래 작업 디렉터리]
A --> C[핫픽스용 worktree]
A --> D[실험용 worktree]
B --> E[기능 개발 유지]
C --> F[긴급 수정]
D --> G[새 아이디어 검증]원문은 먼저 stash와 브랜치 전환의 불편함을 보여 준 뒤, 같은 상황을 worktree로 바꾸면 훨씬 덜 흔들린다고 설명합니다. 핵심은 기존 브랜치 상태를 지우지 않고 새 작업 공간을 여는 것입니다.
브랜치 전환과 stash의 부담
원문은 이런 식의 흐름을 보여 줍니다.
git stash "wip feature login"
git checkout main
git checkout -b hotfix-bug이 방식은 익숙하지만, 컨텍스트 스위칭 비용이 큽니다. 어떤 파일을 어디까지 수정했는지, 지금 어떤 문맥이었는지 다시 되살려야 하니까요.
worktree가 만드는 흐름
worktree를 쓰면 원래 작업은 그대로 두고, 별도의 폴더에 새 브랜치를 붙여서 일할 수 있습니다.
git worktree add ../hotfix-workspace -b hotfix-bug main이 한 줄이 만드는 변화는 큽니다. 기존 기능 작업 디렉터리를 그대로 둔 채, 새 폴더에서 핫픽스만 처리할 수 있습니다.
GitHub Blog는 이 방식이 stash 충돌 위험이 없고, 에디터 문맥이 깨지지 않으며, 진짜 병렬 작업이 가능하다고 정리합니다.
제거도 명시적으로
작업이 끝나면 worktree를 정리해야 합니다.
git worktree remove ../hotfix-workspace이 부분은 꽤 중요합니다. worktree는 편하지만, 정리하지 않으면 폴더가 금방 늘어납니다.
왜 지금 다시 뜨나?
Git worktree 자체는 새 개념이 아닙니다. 다만 최근에 다시 주목받는 이유는 작업 방식이 바뀌었기 때문입니다.
GitHub Blog는 지금의 개발이 예전보다 훨씬 더 병렬적이라고 봅니다. 한 사람이 여러 세션을 동시에 운영하고, 코드 작성만큼 코드 리뷰와 검증이 중요해졌으며, 에이전트도 하나의 작업 단위로 계속 병렬 실행됩니다.
이때 worktree는 꽤 자연스러운 바닥입니다.
| 상황 | 브랜치 + stash | worktree |
|---|---|---|
| 급한 핫픽스 대응 | 기존 문맥을 잠시 접어야 함 | 별도 폴더에서 바로 처리 |
| 실험용 수정 | 현재 작업과 충돌하기 쉬움 | 독립 공간에서 안전하게 검증 |
| 에이전트 병렬 작업 | 세션이 겹치기 쉬움 | 작업 디렉터리를 분리하기 쉬움 |
| 돌아오기 | 문맥 복구가 필요함 | 원래 작업을 그대로 유지 |
GitHub Copilot app이 기본적으로 새 worktree를 만드는 흐름을 지원하는 것도 같은 맥락입니다. 도구가 worktree를 기본값으로 밀기 시작했다는 건, 이 패턴이 실제 작업 흐름으로 자리 잡고 있다는 뜻입니다.
GitHub Copilot app에서의 의미
원문은 GitHub Copilot app에서 worktree가 “그냥 되는” 수준으로 통합되어 있다고 보여 줍니다. 사용자는 홈 화면에서 새 세션의 작업 위치를 고를 수 있고, 기본값이 새 worktree입니다.
이 이미지는 GitHub Copilot app이 새 세션을 시작할 때 New worktree, Local repository, Cloud 중 어디에서 작업할지 고르게 해 주는 화면을 보여 줍니다.
또 다른 화면에서는 생성된 worktree 이름, 위치, 프로젝트, 변경 사항을 확인할 수 있습니다.
이 둘을 같이 보면 메시지는 분명합니다. worktree는 단순한 Git 고급 기능이 아니라, 에이전트 기반 작업 흐름의 기본 단위로 다뤄지고 있습니다.
주의사항 / 팁
GitHub Blog도 worktree의 단점을 꽤 솔직하게 짚습니다.
기억해 둘 것
- worktree를 많이 만들수록 디펜던시 중복이 부담됩니다.
- 작업이 끝난 worktree는 반드시 지워야 합니다.
.gitignore와 작업 폴더 위치를 미리 정리해 두면 실수가 줄어듭니다.- 같은 브랜치를 중복 체크아웃할 수 없다는 제약을 이해해야 합니다.
이건 단점이라기보다, worktree를 “작은 독립 작업 공간”으로 다뤄야 한다는 신호에 가깝습니다.
마무리
git worktree가 다시 뜨는 이유는 단순합니다. 지금의 개발은 한 브랜치에 한 마음만 두는 방식보다, 여러 작업을 동시에 유지하는 방식에 더 가깝기 때문입니다.
브랜치와 stash는 여전히 유용합니다. 다만 병렬 작업, 에이전트 협업, 빠른 컨텍스트 전환이 필요한 순간에는 worktree가 더 자연스럽습니다.
이 글을 읽고 나면 다음 기준으로 판단하면 됩니다.
- 지금 작업을 잠깐 멈춰도 되는가?
- 다른 작업을 같은 저장소에서 바로 병렬로 돌려야 하는가?
- 컨텍스트를 잃는 비용이 큰가?
세 질문에 “예”가 많다면, worktree를 기본값으로 둘 이유가 충분합니다.
실제로 GitHub Copilot app까지 이 흐름을 기본값으로 밀고 있는 만큼, worktree는 이제 “알아두면 좋은 기능”을 넘어 “병렬 작업의 기본 패턴”에 가깝습니다.
참고 자료
- What are git worktrees, and why should I use them? - The GitHub Blog ↗ — 원문 본문과 스크린샷
- GitHub Blog worktree 스크린샷 1 ↗ — Copilot app의 새 worktree 선택 화면
- GitHub Blog worktree 스크린샷 2 ↗ — 생성된 worktree 정보 화면