Claude Code가 인증 기능을 20분째 손보던 참에, Slack에 프로덕션 장애 알림이 뜹니다. 지금 당장 핫픽스가 필요하다는 내용입니다.

Git 워크트리(worktree)는 2015년 Git 2.5부터 있던 기능이지만, AI 코딩 에이전트가 늘어난 2025~2026년 들어 개발자들 사이에서 필수 인프라로 재조명받고 있습니다. 엔지니어링 리드 타미르 드레셔는 이 방식으로 마이크로소프트 글로벌 해커톤에서 여러 AI 에이전트를 동시에 운영한 경험을 자신의 블로그에 공유했습니다.

출처: Scaling Your AI Development Team with Git Worktrees – Tamir Dresher

조용한 충돌 사고

기존 방식이라면 하던 작업을 스태시(stash)로 밀어두고, 브랜치를 바꾸고, 에이전트가 쌓아둔 맥락을 통째로 날린 뒤, 버그를 고치고, 다시 브랜치를 돌아와 에이전트를 처음부터 다시 상황에 맞춰야 합니다. 에이전트를 두 개 동시에 같은 폴더에서 돌리고 있었다면 상황은 더 나쁩니다. 두 에이전트가 같은 package.json을 동시에 건드리다가, 하나가 다른 하나의 작업을 아무 경고도 오류도 없이 조용히 덮어써버립니다. 한 시간쯤 지나 테스트가 이상하게 실패하는 걸 보고서야 뭔가 잘못됐다는 걸 알게 됩니다.

하나의 저장소, 여러 개의 독립된 작업 공간

워크트리는 같은 저장소에서 체크아웃한 별도의 디렉터리입니다. 필요한 만큼 여러 개를 만들 수 있고, 각각 다른 브랜치 위에서 동시에 존재합니다. .git 폴더 하나를 여러 작업 폴더가 공유하는 구조라, 히스토리와 커밋은 모두 공유되지만 실제 파일과 작업 상태는 폴더마다 완전히 분리됩니다. 한 폴더에서 에이전트가 벌이는 작업은 다른 폴더에서 전혀 보이지도, 닿지도 않습니다.

저장소를 통째로 여러 번 복제하는 것과는 다릅니다. 복제는 디스크 용량을 그만큼 잡아먹고, 저장소끼리 히스토리도 공유되지 않죠. 워크트리는 한 번만 복제해두면, 추가되는 작업 공간마다 체크아웃한 파일만큼의 용량만 더 씁니다.

실제로 이 방식이 필요해진 배경에는 숫자도 있습니다. 전문 개발자의 51%가 AI 도구를 매일 쓰지만, AI 에이전트를 쓰는 개발자 중 실제로 팀 협업이 나아졌다고 답한 비율은 17%에 그칩니다. 이 격차는 도구 자체의 문제라기보다, 그 도구를 받쳐줄 작업 방식이 따라가지 못한 결과에 가깝습니다.

코드를 짜는 사람에서, 에이전트를 감독하는 사람으로

이 워크트리 방식을 실전에서 검증한 사례가 있습니다. 엔지니어링 리드 타미르 드레셔는 2025년 마이크로소프트 글로벌 해커톤에서 익숙한 문제에 부딪혔습니다. 처리할 기능은 많은데 시간은 부족했고, 저장소를 여러 번 복제해가며 작업하는 건 너무 번거로웠습니다.

그가 택한 해법은 워크트리로 일종의 가상 AI 개발팀을 꾸리는 것이었습니다. 기능마다 워크트리를 하나씩 만들고, 워크트리마다 VS Code 창을 하나씩 열고, 창마다 AI 에이전트를 하나씩 돌렸습니다. 그러자 드레셔 자신의 역할이 달라졌습니다. 코드를 직접 짜는 대신, 작업 범위를 정해주고, 결과물을 검토하고, 막힌 에이전트를 이끌어주고, 끝난 작업을 병합하는 쪽으로 옮겨간 겁니다.

각 창은 완전히 독립적으로 움직였습니다. 한 창에서는 Roo로 빠른 기능 개발을 진행하고, 다른 창에서는 Visual Studio와 Copilot으로 복잡한 버그를 디버깅했습니다. 서로 다른 도구를 작업 성격에 맞춰 섞어 쓴 겁니다. 한 에이전트가 작업을 마치면, 드레셔는 그 결과물을 리뷰하고 승인한 뒤 풀 리퀘스트를 열었습니다. 동료 개발자의 PR을 검토하는 것과 다르지 않은 절차였습니다.

기능 하나를 도중에 포기해야 할 때도 부담이 없었습니다. 해당 창을 닫고 워크트리를 지우면 끝이었고, 다른 에이전트들은 아무 영향을 받지 않았죠. 드레셔는 이 경험을, 관리해야 할 저장소 복제본 부담 없이 여러 명의 개발자가 자기 컴퓨터에서 동시에 일해주는 것 같았다고 표현합니다.

다만 너무 오래 방치하면

이 구조에도 주의할 지점은 있습니다. 워크트리 하나를 메인 브랜치와 오래 동기화하지 않고 며칠씩 그대로 두면, 그사이 벌어진 변화가 쌓여 나중에 병합할 때 풀기 어려운 충돌로 돌아옵니다. 실무에서는 에이전트가 의미 있는 작업 단위를 끝낼 때마다 메인 브랜치의 최신 상태를 가져와 맞춰두는 식으로 이 문제를 관리합니다.

결국 이 변화가 말해주는 건 도구 하나의 편의성이 아닙니다. 여러 에이전트를 동시에 굴릴 수 있게 되면서, 개발자의 일 자체가 코드를 순서대로 짜는 것에서 여러 작업을 병렬로 감독하고 판단하는 쪽으로 옮겨가고 있다는 신호에 가깝습니다.

참고자료: Git Worktrees for AI Development – KDnuggets