에이전트 시대에 git worktree가 다시 뜨는 이유

작업 중인 브랜치를 멈추고 급한 버그를 처리하다 보면 stash가 쌓입니다. git worktree는 이 문제를 줄이는 Git 기능이고, GitHub Blog는 이 기능을 병렬 작업과 에이전트 협업의 기본 단위로 소개합니다.

병렬 작업에는 브랜치보다 worktree가 맞습니다. 같은 저장소를 여러 작업 디렉터리로 나누면 한쪽 컨텍스트를 유지한 채 다른 일도 동시에 진행할 수 있습니다.

이 글에서 다루는 내용은 세 가지입니다.

• worktree가 브랜치와 stash보다 편한 순간
• git worktree add와 git worktree remove가 어떤 흐름을 만드는지
• 에이전트와 인간이 병렬로 움직일 때 worktree가 왜 유리한지

배경 / 왜 필요한가?

브랜치 전환 명령 자체는 어렵지 않습니다. 문제는 “지금 하던 일”의 맥락이 머릿속과 에디터에 쌓여 있을 때 생깁니다.

긴 기능 작업 중 급한 핫픽스가 들어오면 보통은 stash를 남기고 main으로 이동합니다. 새 브랜치를 만들어 수정한 뒤 다시 돌아옵니다. 이 과정에는 파일 재로딩, 의존성 재설치, 작업 맥락 복원이 따라옵니다.

GitHub Blog도 이 전환 비용을 지적합니다. worktree를 쓰면 한 저장소 안에서 여러 작업을 동시에 유지할 수 있습니다.

이 흐름은 AI 에이전트가 여러 세션을 병렬로 돌리는 요즘의 작업 방식과도 잘 맞습니다. 인간도, 에이전트도, 같은 저장소를 두고 각각 독립된 작업 공간을 가지면 덜 흔들립니다.

worktree의 개념

worktree를 쓰면 하나의 Git 저장소에서 여러 작업 디렉터리를 분리해 쓸 수 있습니다.

flowchart TD
  A[하나의 저장소] --> B[원래 작업 디렉터리]
  A --> C[핫픽스용 worktree]
  A --> D[실험용 worktree]
  B --> E[기능 개발 유지]
  C --> F[긴급 수정]
  D --> G[새 아이디어 검증]

원문은 먼저 stash와 브랜치 전환의 불편함을 보여 줍니다. 그다음 같은 상황을 worktree로 처리합니다. 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가 작업 공간의 기본 단위가 됩니다.

GitHub Copilot app도 새 세션을 시작할 때 기본으로 새 worktree를 만듭니다. 도구가 worktree를 기본값으로 두기 시작했습니다.

GitHub Copilot app에서의 의미

원문에 따르면 GitHub Copilot app은 worktree를 별도 설정 없이 쓸 수 있게 통합했습니다. 사용자는 홈 화면에서 새 세션의 작업 위치를 고를 수 있고, 기본값은 새 worktree입니다.

이 이미지는 GitHub Copilot app이 새 세션을 시작할 때 New worktree, Local repository, Cloud 중 어디에서 작업할지 고르게 해 주는 화면을 보여 줍니다.

또 다른 화면에서는 생성된 worktree 이름, 위치, 프로젝트, 변경 사항을 확인할 수 있습니다.

두 화면에서 worktree는 에이전트 기반 작업 흐름의 기본 단위로 다뤄집니다.

주의사항 / 팁

GitHub Blog는 worktree의 단점도 짚습니다.

기억해 둘 것

• worktree를 많이 만들수록 디펜던시 중복이 부담됩니다.
• 작업이 끝난 worktree는 반드시 지워야 합니다.
• .gitignore와 작업 폴더 위치를 미리 정리해 두면 실수가 줄어듭니다.
• 같은 브랜치를 중복 체크아웃할 수 없다는 제약을 이해해야 합니다.

이 제약을 고려해 worktree는 “작은 독립 작업 공간”으로 만들고, 작업이 끝나면 지웁니다.

마무리

지금의 개발은 한 브랜치에 집중하는 방식보다 여러 작업을 동시에 유지하는 방식에 가깝습니다. 그래서 git worktree가 다시 쓰입니다.

브랜치와 stash는 여전히 유용합니다. 병렬 작업, 에이전트 협업, 빠른 컨텍스트 전환이 필요하다면 worktree를 씁니다.

worktree를 쓸지는 다음 기준으로 판단합니다.

1. 지금 작업을 잠깐 멈춰도 되는가?
2. 다른 작업을 같은 저장소에서 바로 병렬로 돌려야 하는가?
3. 컨텍스트를 잃는 비용이 큰가?

세 질문에 “예”가 많다면 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 정보 화면