긴급 전화 한 통

새로운 결제 기능을 만들고 있습니다. 코드를 절반쯤 작성했는데, 슬랙 알림이 울립니다. 운영 서버에서 로그인 버그가 발생했다는 긴급 보고입니다. 지금 당장 고쳐야 합니다.

문제는, 지금 작업 중인 코드가 아직 완성되지 않았다는 것입니다. 커밋하기에는 미완성이고, 그렇다고 변경사항을 버릴 수도 없습니다. 긴급 수정을 위해 브랜치를 전환하려면 현재 작업을 어딘가에 임시 저장해야 합니다. git stash로 넣어 두고, 브랜치를 바꾸고, 수정하고, 다시 원래 브랜치로 돌아와서 스태시를 꺼내고... 복잡합니다. 실수가 끼어들 여지가 곳곳에 있습니다.

깃 워크트리(Git Worktree)는 이 상황을 근본적으로 해결합니다.

워크트리란 무엇인가

깃(Git)의 기본 구조에서 하나의 저장소(repository)는 하나의 작업 디렉터리와 연결됩니다. 그 디렉터리 안에서 한 번에 하나의 브랜치만 체크아웃할 수 있습니다. 다른 브랜치에서 작업하려면 현재 브랜치의 변경사항을 정리한 뒤 브랜치를 전환해야 합니다.

워크트리는 이 제약을 깨뜨립니다. 하나의 저장소에서 여러 브랜치를 동시에 체크아웃할 수 있습니다. 각 브랜치가 별도의 폴더에 존재합니다.

비유하자면 이렇습니다. 기존 방식은 책상이 하나뿐인 사무실입니다. 프로젝트 A의 서류를 펼쳐 놓고 작업하다가 프로젝트 B를 해야 하면, A의 서류를 전부 치우고 B의 서류를 꺼내야 합니다. 워크트리는 책상을 여러 개 놓는 것입니다. A 서류는 첫 번째 책상에 그대로 펼쳐 두고, 두 번째 책상에서 B 작업을 합니다. 각 책상은 독립적이지만, 같은 사무실(저장소) 안에 있습니다.

[그림 30-1] 기존 단일 작업 디렉터리 vs. 워크트리 복수 디렉터리 구조 비교

워크트리의 기본 사용법

워크트리를 생성하는 깃 명령어는 간결합니다.

git worktree add ../hotfix-login hotfix/login-bug

이 명령어는 현재 저장소에서 hotfix/login-bug라는 브랜치를 체크아웃한 새 작업 디렉터리를 ../hotfix-login 경로에 만듭니다. 기존 작업 디렉터리는 건드리지 않습니다.

이제 두 개의 폴더가 있습니다. 원래 폴더에는 개발 중인 결제 기능 코드가 그대로 남아 있고, 새 폴더에는 긴급 수정용 브랜치가 깨끗하게 체크아웃되어 있습니다. 두 폴더를 오가며 작업할 수 있고, 서로의 파일에 영향을 주지 않습니다.

워크트리 목록을 확인하려면:

git worktree list

작업이 끝난 워크트리를 제거하려면:

git worktree remove ../hotfix-login

실제로 폴더를 통째로 복사하는 것이 아니기 때문에, 디스크 사용량도 효율적입니다. 깃의 내부 데이터(.git 디렉터리)는 공유되고, 각 워크트리에는 해당 브랜치의 파일만 체크아웃됩니다.

[그림 30-2] git worktree 명령어 실행 후 생성된 디렉터리 구조

클로드 코드의 네이티브 워크트리 지원

클로드 코드는 깃 워크트리를 네이티브로 지원합니다. 깃 명령어를 직접 입력하지 않아도 됩니다.

claude --worktree feature-payment

이 한 줄이면 클로드 코드가 자동으로 워크트리를 생성하고, 새 브랜치를 만들고, 해당 워크트리에서 클로드 코드 세션을 시작합니다. 깃 워크트리의 복잡한 명령어 체계를 몰라도 워크트리의 이점을 그대로 누릴 수 있습니다.

물론 세부적인 제어가 필요하다면 깃 명령어를 직접 사용할 수도 있습니다. 클로드 코드의 네이티브 지원은 편의를 위한 것이지, 깃의 기능을 제한하는 것이 아닙니다. 두 방식을 상황에 따라 혼용하면 됩니다.

다중 세션 운영: 실전 시나리오

워크트리의 진가는 클로드 코드와 결합했을 때 드러납니다. 각 워크트리에서 독립적인 클로드 코드 세션을 실행할 수 있기 때문입니다.

구체적인 시나리오를 그려 보겠습니다.

상황: 전자상거래 플랫폼을 개발 중입니다. 세 가지 작업이 동시에 필요합니다.

• 새로운 위시리스트 기능 개발
• 결제 페이지의 UI 리뉴얼
• 프로덕션에서 발생한 장바구니 버그 긴급 수정

실행:

터미널 A에서:

claude --worktree feature-wishlist

"위시리스트 기능을 구현해 줘. 사용자가 상품을 추가하고 제거할 수 있어야 하고, 목록을 공유할 수 있어야 해."

터미널 B에서:

claude --worktree redesign-checkout

"결제 페이지 UI를 모바일 우선으로 재설계해 줘. 현재 디자인의 스크린샷을 참고해."

터미널 C에서:

claude --worktree hotfix-cart

"장바구니에서 수량 변경 시 총액이 갱신되지 않는 버그를 수정해 줘."

세 세션이 동시에 작동합니다. 각 세션은 자기 워크트리 안에서만 파일을 수정하므로 충돌이 발생하지 않습니다. 긴급 수정이 먼저 끝나면 해당 브랜치를 메인에 병합하고, 나머지 기능은 계속 개발을 진행합니다.

[그림 30-3] 세 개의 워크트리에서 동시에 진행되는 클로드 코드 세션 구성도

기능 개발과 긴급 수정의 동시 처리

위 시나리오에서 핵심은 긴급 수정이 기존 개발 작업을 방해하지 않는다는 것입니다.

워크트리가 없었다면 어떻게 됐을까요? 위시리스트 기능을 반쯤 만들다가 작업을 멈추고, 변경사항을 스태시(stash)하거나 미완성 커밋을 만들고, 브랜치를 전환하고, 버그를 고치고, 다시 원래 브랜치로 돌아와서 스태시를 복원해야 합니다. 이 과정에서 스태시 충돌이 날 수도 있고, 미완성 커밋이 히스토리를 더럽힐 수도 있습니다.

워크트리에서는 이런 번거로움이 없습니다. 위시리스트 작업은 그 자리에 그대로 있습니다. 새 터미널을 열고, 새 워크트리에서 버그를 고칩니다. 끝나면 워크트리를 제거합니다. 위시리스트 작업으로 돌아갈 때 복원할 것도, 전환할 것도 없습니다. 원래 있던 터미널에서 계속하면 됩니다.

이 안전성은 클로드 코드를 여러 세션 돌릴 때 더욱 중요해집니다. 사람이 직접 코드를 작성하면 실수를 바로 인지할 수 있지만, AI 에이전트가 코드를 작성할 때는 서로의 작업을 덮어쓰는 사고가 은밀하게 벌어질 수 있습니다. 워크트리는 이 사고를 구조적으로 불가능하게 만듭니다.

워크트리 관리의 실용적 조언

워크트리를 많이 만들다 보면 관리가 필요합니다. 몇 가지 실용적인 팁을 정리합니다.

명명 규칙을 정하십시오. feature-, hotfix-, refactor- 같은 접두사를 일관되게 사용하면, 어떤 워크트리가 어떤 목적인지 한눈에 파악됩니다.

작업이 끝난 워크트리는 즉시 제거하십시오. 방치하면 어떤 워크트리가 활성 상태인지 혼란이 생깁니다. 브랜치를 메인에 병합한 뒤에는 git worktree remove로 깔끔하게 정리합니다.

워크트리 디렉터리의 위치를 일관되게 잡으십시오. 프로젝트 폴더와 같은 수준의 상위 디렉터리에 두거나, 프로젝트 내 특정 폴더를 지정하는 등 규칙을 만들어 두면, 워크트리를 찾으러 헤매는 일이 없어집니다.

[그림 30-4] 워크트리 관리 모범 사례 요약표

병렬 개발의 안전망

워크트리는 화려한 기술이 아닙니다. 깃의 기본 기능을 확장한 것에 불과합니다. 하지만 이 확장이 만들어내는 차이는 큽니다.

하나의 브랜치에서 하나의 작업만 할 수 있다는 제약이 사라지면, 작업 방식이 근본적으로 바뀝니다. 긴급 수정 때문에 기능 개발을 중단하지 않아도 됩니다. 여러 에이전트가 같은 프로젝트에서 동시에 일하면서도 서로 방해하지 않습니다. 실험적인 시도를 별도의 워크트리에서 마음껏 해 볼 수 있습니다.

이렇게 자유롭게 여러 세션을 운영하려면, 각 세션에 어느 정도의 권한을 줄 것인지에 대한 판단도 필요합니다. 에이전트가 파일을 자유롭게 수정하게 할 것인지, 아니면 매번 승인을 받게 할 것인지. 자율성과 통제 사이의 균형을 잡는 방법을 살펴볼 차례입니다.