Git Worktree 써보니 브랜치 갈아타는 스트레스가 확 줄었습니다

요즘 개발하면서 느끼는 게 하나 있어요. AI 바이브 코딩이 편하긴 정말 편한데, 이상하게 Git 작업은 더 복잡해지는 순간이 있더라고요. LLM이 코드도 짜주고 테스트 아이디어도 던져주고 리팩토링 방향도 잡아주니까, 예전보다 훨씬 빠르게 여러 가지 시도를 하게 되잖아요. 그런데 그 시도들이 전부 같은 브랜치 위에서 뒤엉키기 시작하면, 그때부터는 생산성이 아니라 정리 노동이 됩니다.

저도 한동안 그랬습니다. AI가 만들어준 신규 기능을 테스트하고 있는데, 갑자기 운영 쪽에서 핫픽스 요청이 들어와요. 그러면 머릿속에서 바로 계산이 시작됩니다. “지금 작업 중인 파일 stash 해야 하나? 아직 커밋하기엔 애매한데? 브랜치 바꾸면 IDE 상태는 또 어떻게 되지?” 뭐랄까, 코딩을 하는 게 아니라 이삿짐을 싸는 기분이랄까요.

그러다 다시 꺼내 쓰기 시작한 게 Git Worktree입니다. 예전에도 알고는 있었는데, 솔직히 그땐 “굳이 이걸 써야 하나?” 싶었거든요. 그런데 요즘처럼 LLM이 만들어준 코드를 여러 갈래로 검증해야 하는 환경에서는 이야기가 좀 다릅니다. 한 번 몸에 익히고 나니까, 브랜치 왔다 갔다 하던 시절로 돌아가기가 꽤 싫어졌습니다.

Git Worktree가 뭐냐면, 브랜치를 폴더째로 나눠 쓰는 느낌입니다

Git Worktree를 너무 어렵게 생각할 필요는 없어요. 하나의 Git 저장소를 기준으로 여러 브랜치를 각각 다른 폴더에 체크아웃해서 쓰는 기능입니다. 그러니까 기존처럼 한 폴더 안에서 git checkout이나 git switch로 브랜치를 바꿔가며 작업하는 게 아니라, 브랜치마다 작업 공간을 따로 만들어두는 방식이에요.

예를 들어 제 로컬에 이런 프로젝트가 있다고 해볼게요.

/workspace/my-service

여기서는 평소처럼 develop 브랜치에서 신규 기능을 보고 있습니다. 그런데 갑자기 운영에서 긴급 버그 수정 요청이 들어왔어요. 예전 같으면 일단 하던 작업을 저장하거나 stash 하고, 브랜치를 바꾸고, 버그 고치고, 다시 돌아와서 stash pop 하고… 이 흐름이었죠. 말은 간단한데 실제로는 귀찮습니다. 특히 수정 중인 파일이 많으면 괜히 손에 땀이 나요.

이럴 때 저는 그냥 새 Worktree를 하나 만듭니다.

git worktree add ../my-service-hotfix hotfix/urgent-bug

그러면 옆에 이런 폴더가 하나 생깁니다.

/workspace/my-service
/workspace/my-service-hotfix

my-service 폴더는 기존 작업 그대로 두고, my-service-hotfix 폴더에서는 hotfix/urgent-bug 브랜치로 바로 작업하면 됩니다. Git 히스토리는 공유하지만 워킹 디렉토리는 분리되어 있어서, 서로 파일 상태가 섞이지 않아요. 새로 clone 받는 것도 아니라서 생각보다 빠르고, 디스크 용량도 훨씬 덜 먹습니다.

작업 방식	기존 브랜치 전환 방식	Git Worktree 방식
작업 중인 파일 보존	stash 또는 임시 커밋 필요	기존 폴더는 그대로 유지
핫픽스 대응	브랜치 전환 후 작업	별도 폴더에서 바로 작업
AI 코드 실험	실패하면 롤백이 번거로움	실험 폴더만 버리면 됨
IDE 상태	브랜치 바뀔 때마다 영향 받음	폴더별로 따로 열 수 있음

이게 별것 아닌 것 같아도 실제로 해보면 꽤 큽니다. 특히 나이가 들수록, 아니 경력이 쌓일수록 더 그런 것 같아요. 코드를 잘 짜는 것만큼 중요한 게 머릿속 컨텍스트를 덜 깨는 것이거든요. 핫픽스 때문에 흐름이 끊겼다가 다시 돌아왔을 때, “내가 아까 뭘 보던 중이었지?” 하는 순간이 제일 아깝습니다.

AI 바이브 코딩할 때 Worktree가 진짜 편한 이유

요즘 LLM을 개발에 쓰다 보면 이런 일이 자주 생깁니다. AI에게 “이 서비스 로직 좀 깔끔하게 리팩토링해줘”라고 부탁했더니 생각보다 큰 변경안을 줘요. 또 다른 채팅에서는 “성능 개선 버전으로 바꿔보자”고 했더니 전혀 다른 구조를 제안합니다. 둘 다 흥미롭습니다. 그런데 둘 다 바로 develop에 넣기엔 무섭죠.

저는 이럴 때 Worktree를 실험실처럼 씁니다. 메인 프로젝트 폴더는 늘 안정적인 브랜치에 둡니다. 보통 main이나 develop이죠. 그리고 AI가 제안한 코드는 전부 별도 Worktree에서 먼저 굴려봅니다.

git branch experiment/ai-refactor
git worktree add ../my-service-ai-refactor experiment/ai-refactor

이렇게 해두면 마음이 편합니다. AI가 만든 코드가 좋으면 가져오면 되고, 별로면 폴더째 정리하면 됩니다. 괜히 기존 작업 폴더를 더럽히지 않아도 돼요. 사실 이 심리적 안정감이 꽤 중요합니다. 실험이 쉬워지면 좋은 시도도 늘어나거든요.

상황	제가 쓰는 Worktree 패턴	좋았던 점
AI 리팩토링 검증	experiment/ai-refactor 브랜치 생성	기존 코드와 비교하기 쉬움
운영 핫픽스	hotfix/... 전용 Worktree 사용	작업 중인 기능 개발을 멈추지 않아도 됨
대규모 의존성 업그레이드	upgrade/... 폴더에서 테스트	깨져도 부담이 적음
프롬프트별 코드 비교	프롬프트 전략마다 Worktree 분리	어떤 답변이 더 나은지 눈으로 확인 가능

특히 LLM 토큰을 아끼는 방법으로도 은근히 괜찮습니다. Worktree를 나눠두면 “지금 이 브랜치는 어떤 실험용이다”라는 맥락이 명확해지거든요. AI에게 매번 프로젝트 전체 배경을 길게 설명하지 않아도 됩니다. 그냥 변경 대상 파일과 현재 브랜치의 목적만 짧게 말해도 충분한 경우가 많아요.

예를 들면 예전에는 이런 식으로 길게 물어봤습니다.

현재 develop 브랜치에서 사용자 권한 체크 로직을 수정 중인데,
기존 코드가 이렇고, 관련 서비스는 이렇고,
다른 브랜치에서 일부 변경한 내용도 있고...

Worktree로 분리한 뒤에는 훨씬 짧아졌습니다.

이 브랜치는 권한 체크 리팩토링 실험용이야.
아래 UserPermissionService의 조건 분기를 줄이고 싶어.
동작은 유지하고 테스트가 깨지지 않게 리팩토링 방향을 제안해줘.

작아 보이죠. 그런데 이런 차이가 쌓이면 꽤 큽니다. 토큰도 아끼고, 질문도 선명해지고, 답변 품질도 좋아집니다. AI에게 많은 걸 던져주는 것보다, 좁고 선명한 작업 공간을 만들어주는 것이 더 낫다는 걸 요즘 자주 느낍니다.

제가 실제로 쓰는 Worktree 폴더 구조

처음에는 저도 프로젝트 옆에 아무렇게나 Worktree 폴더를 만들었습니다. project-test, project-hotfix, project-new 이런 식으로요. 그런데 며칠 지나면 헷갈립니다. 이게 뭐 하던 폴더였는지 기억이 안 나요. 개발자라면 다들 알잖아요. 이름 대충 지으면 미래의 내가 벌을 받습니다.

그래서 지금은 보통 이런 식으로 정리합니다.

/workspace
  /my-service
  /my-service.hotfix-urgent-bug
  /my-service.exp-ai-refactor
  /my-service.exp-cache-strategy
  /my-service.upgrade-spring-boot

점 하나 들어간 이름이 별거 아닌데, 제 눈에는 꽤 잘 들어옵니다. 원본 프로젝트와 Worktree가 같은 계열이라는 것도 보이고, 목적도 바로 보입니다. 팀원에게 화면 공유할 때도 덜 민망하고요.

• hotfix는 운영 긴급 수정용으로만 씁니다.
• exp는 AI 코드 실험이나 구조 변경 검증용으로 씁니다.
• upgrade는 라이브러리, 프레임워크 버전 업그레이드용으로 둡니다.
• wip는 하루 안에 버릴 가능성이 높은 작업에만 붙입니다.

이름 규칙을 정해두면 생각보다 마음이 편합니다. 특히 Worktree가 3개 이상 생기기 시작하면 규칙이 없을 때 금방 지저분해져요. 개인 작업이라도 어느 정도는 질서가 필요합니다. 나 자신도 협업 대상이니까요.

명령어는 몇 개만 손에 익히면 됩니다

Git Worktree가 좋아 보여도 명령어가 많으면 손이 잘 안 가잖아요. 저도 새로운 도구 배울 때 명령어 20개씩 나오면 살짝 피곤합니다. 그런데 실제로 매일 쓰는 건 몇 개 안 됩니다.

하고 싶은 일	명령어	제가 붙이는 설명
새 Worktree 만들기	git worktree add ../my-service.exp-ai-refactor experiment/ai-refactor	브랜치를 별도 폴더로 꺼내기
새 브랜치와 함께 만들기	git worktree add -b experiment/cache ../my-service.exp-cache	브랜치 생성과 폴더 생성을 한 번에 처리
목록 확인하기	git worktree list	지금 열린 작업 공간 확인
Worktree 지우기	git worktree remove ../my-service.exp-ai-refactor	실험 끝난 폴더 정리
깨진 참조 정리	git worktree prune	폴더를 수동 삭제했을 때 뒤처리

저는 특히 git worktree list를 자주 칩니다. 하루 끝날 때 한 번씩 보면 은근히 좋습니다. 지금 내가 벌려놓은 일이 뭔지 눈에 보이거든요. 업무도 그렇고 개발도 그렇고, 벌려놓은 걸 눈으로 확인하는 순간 정리할 마음이 생깁니다.

git worktree list

출력은 대충 이런 식으로 나옵니다.

/workspace/my-service                     abc1234 [develop]
/workspace/my-service.hotfix-urgent-bug   def5678 [hotfix/urgent-bug]
/workspace/my-service.exp-ai-refactor     9ab012c [experiment/ai-refactor]

이걸 보면 “아, 핫픽스는 끝났으니 지워도 되겠다” 하는 판단이 바로 됩니다. 작은 습관인데 나중에 로컬 폴더가 쓰레기장 되는 걸 막아줍니다.

주의할 점도 있습니다, 편하다고 막 만들면 또 다른 혼란이 와요

좋은 도구라고 해서 아무렇게나 쓰면 결국 또 꼬입니다. Worktree도 마찬가지예요. 처음 며칠은 신나서 막 만듭니다. 실험용 하나, 핫픽스용 하나, 리팩토링용 하나, 테스트용 하나. 그러다 어느 순간 “이 폴더 뭐였지?” 하는 시간이 옵니다. 저도 왔습니다.

제가 겪어보고 정착한 기준은 이렇습니다.

• 하루 이상 볼 작업만 Worktree로 뺍니다. 10분짜리 확인 작업까지 다 Worktree로 만들면 오히려 번잡합니다.
• 브랜치 이름과 폴더 이름을 비슷하게 맞춥니다. 나중에 목록 봤을 때 바로 이해되어야 합니다.
• 작업 끝난 Worktree는 바로 지웁니다. 로컬에 남겨둔다고 추억이 되진 않더라고요.
• 같은 브랜치를 두 Worktree에서 동시에 쓰려고 하지 않습니다. Git이 막아주긴 하지만, 그런 구조 자체가 좋지 않습니다.
• IDE 설정 파일은 커밋 여부를 꼭 확인합니다. Worktree마다 설정 파일이 생기면 의도치 않게 올라갈 수 있습니다.

삭제할 때는 가능하면 Worktree를 만든 원래 저장소 쪽에서 처리하는 게 마음 편합니다.

git worktree remove ../my-service.hotfix-urgent-bug

가끔 Finder나 탐색기에서 그냥 폴더를 지워버리는 경우도 있잖아요. 저도 급할 때 그랬습니다. 그러면 Git 입장에서는 “분명 Worktree가 있었는데 폴더가 없네?” 하는 상태가 될 수 있어요. 그럴 때는 아래 명령어로 정리하면 됩니다.

git worktree prune

그리고 Worktree에서 쓰던 브랜치까지 완전히 정리하고 싶다면, Worktree 제거 후에 로컬 브랜치를 지우면 됩니다.

git branch -D experiment/ai-refactor

물론 원격에 push한 브랜치라면 팀 규칙에 맞춰서 처리해야 합니다. 혼자 실험한 브랜치라면 과감히 지워도 되지만, 누군가 보고 있을 가능성이 있으면 조심해야죠. Git은 기술이기도 하지만, 결국 협업의 약속이니까요.

IDE랑 같이 쓸 때는 설정을 살짝 챙겨두면 훨씬 편합니다

Worktree는 폴더가 분리되니까 VSCode나 JetBrains 계열 IDE에서 각각 별도 프로젝트처럼 열 수 있습니다. 이게 정말 편해요. 한쪽 창에는 develop, 다른 창에는 hotfix, 또 다른 창에는 AI 리팩토링 실험 브랜치. 모니터가 넓으면 거의 관제실 느낌입니다.

다만 설정 파일은 조금 신경 써야 합니다. 예를 들어 VSCode를 쓰면 .vscode 폴더가 생길 수 있고, JetBrains IDE를 쓰면 .idea 폴더가 생길 수 있죠. 팀에서 공유하는 설정이면 괜찮지만, 개인 설정이 섞이면 커밋할 때 애매해집니다.

저는 보통 프로젝트 성격에 따라 이렇게 처리합니다.

설정 종류	처리 방식	이유
디버그 설정	필요하면 Worktree로 복사	매번 실행 설정 잡는 시간이 아까움
개인 IDE 설정	.gitignore로 제외	팀원 환경을 오염시키지 않기 위해
런처 스크립트	공유 가능한 형태로 유지	Worktree마다 동일하게 실행하기 편함

급하게 Worktree를 만들고 바로 개발 서버를 띄워야 할 때는 설정 복사가 꽤 도움이 됩니다.

cp -r ../my-service/.vscode ../my-service.hotfix-urgent-bug/

물론 이건 팀마다 다릅니다. 어떤 팀은 .vscode 설정을 공유하고, 어떤 팀은 철저히 개인 설정으로 둡니다. 중요한 건 “Worktree가 많아질수록 설정 파일도 많아질 수 있다”는 걸 알고 있는 거예요. 모르고 지나가면 어느 날 커밋 목록에 .idea/workspace.xml 같은 게 올라와 있습니다. 그때 살짝 민망합니다.

LLM에게 프롬프트할 때도 Worktree 기준으로 말하면 편합니다

이건 제가 요즘 꽤 중요하게 보는 부분입니다. AI에게 코드를 부탁할 때, 프롬프트를 잘 쓰는 것도 중요하지만 작업 공간을 잘 나누는 것도 그만큼 중요합니다. Worktree로 브랜치 목적이 분리되어 있으면 AI에게 설명할 내용도 훨씬 줄어듭니다.

예를 들어 my-service.exp-cache-strategy라는 Worktree를 열어둔 상태라면, 프롬프트도 이렇게 간단해집니다.

이 브랜치는 캐시 전략 실험용이야.
현재 UserProfileService에서 외부 API 호출이 너무 잦아.
Redis 캐시를 붙이되, 기존 응답 형식은 바꾸지 않는 방향으로 수정안을 제안해줘.
우선 변경 파일은 UserProfileService와 UserProfileCacheRepository로 제한하고 싶어.

저는 여기서 “변경 파일을 제한한다”는 표현을 자주 씁니다. LLM이 의욕이 넘치면 여기저기 손대거든요. 구조까지 갈아엎어주면 고맙긴 한데, 회사 코드는 그렇게 낭만적으로 바꾸기 어렵습니다. 장애 나면 제 이름이 남으니까요.

Worktree와 프롬프트를 같이 쓸 때 제가 자주 넣는 문장도 있습니다.

• “이 브랜치는 실험용이라 과감한 제안도 괜찮아.”
• “이 브랜치는 핫픽스용이라 최소 수정만 원해.”
• “테스트가 깨지면 안 되고, public API는 유지해야 해.”
• “변경 파일은 아래 목록 안에서만 제안해줘.”
• “전체 코드를 다시 쓰지 말고 diff 중심으로 설명해줘.”

이렇게 말하면 답변이 확실히 실용적으로 바뀝니다. 토큰도 덜 쓰고요. AI에게 “똑똑하게 해줘”라고 말하는 것보다, 어디까지 건드려도 되는지를 알려주는 게 훨씬 효과적입니다. 이건 사람한테 코드 리뷰 부탁할 때도 똑같더라고요.

그래도 모든 작업에 Worktree가 정답은 아닙니다

제가 Worktree를 좋아하긴 하지만, 모든 상황에 무조건 쓰라고 말하고 싶진 않습니다. 아주 작은 수정이나 브랜치 전환이 거의 없는 개인 프로젝트라면 굳이 복잡하게 만들 필요 없어요. 도구는 편하려고 쓰는 거지, 도구를 쓰기 위해 일을 만드는 건 좀 이상하잖아요.

제 기준으로는 이런 경우에 Worktree를 씁니다.

• 운영 핫픽스처럼 지금 작업을 멈추고 바로 대응해야 할 때
• AI가 만든 코드를 안전하게 실험해보고 싶을 때
• 리팩토링 방향을 여러 개 비교해야 할 때
• 라이브러리 업그레이드처럼 깨질 가능성이 큰 작업을 할 때
• 장기 작업과 단기 작업이 계속 섞일 때

반대로 이런 경우엔 그냥 브랜치 전환으로 끝냅니다.

• 수정 파일이 1~2개뿐이고 바로 커밋할 수 있을 때
• 작업 시간이 아주 짧을 때
• IDE를 새로 열 필요가 없을 때
• 로컬 폴더를 더 늘리는 게 오히려 귀찮을 때

뭐든 적당한 선이 있는 것 같습니다. 좋은 도구일수록 쓸 때와 안 쓸 때를 구분해야 오래 갑니다. Worktree도 그런 쪽에 가까워요. 제대로 필요한 순간에 쓰면 정말 고맙고, 필요 없을 때까지 쓰면 그냥 폴더만 늘어납니다.

브랜치 전환에 자주 지친다면 한 번은 꼭 써보세요

Git Worktree는 처음 보면 조금 낯설지만, 실제로 써보면 생각보다 단순합니다. 브랜치를 폴더 단위로 나눠서 작업할 수 있게 해주는 도구. 딱 그 정도로 이해하고 시작하면 됩니다. 거창하게 Git 고수가 되어야 쓸 수 있는 기능은 아니에요.

저는 요즘 AI가 만들어준 코드를 검증할 때 Worktree를 거의 기본 옵션처럼 씁니다. 신규 기능은 신규 기능대로, 핫픽스는 핫픽스대로, 실험 코드는 실험 코드대로 나눠두면 머릿속이 덜 복잡합니다. 특히 LLM과 함께 개발할 때는 작업 단위를 작고 선명하게 만드는 게 정말 중요하더라고요. 그래야 프롬프트도 짧아지고, 검증도 쉬워지고, 실패했을 때 버리는 것도 편합니다.

이 글은 브랜치 바꿀 때마다 stash 때문에 불안한 분, AI 코드 실험을 자주 하는 분, 핫픽스와 기능 개발이 자꾸 겹쳐서 피곤한 분에게 특히 도움이 될 것 같습니다. 저처럼 오래 개발했는데도 아직 Git 앞에서 가끔 한숨 쉬는 분들 있잖아요. 그런 분들에게는 꽤 괜찮은 작은 무기가 될 거예요.

한 번만 이렇게 해보세요.

git worktree add ../my-service.exp-test experiment/test

그리고 그 폴더에서 마음껏 실험해보세요. 잘되면 가져오고, 아니면 지우면 됩니다. 개발하면서 이런 가벼움이 생기는 도구는 생각보다 귀합니다. 저는 그래서 Worktree를 좋아합니다. 조용한데, 일 잘하는 동료 같거든요.

🔍 관련 정보 더 보기