ADE 도구들이 전부 쓰는 git worktree — 디스크 아끼려는 게 아니었습니다

ADE · 바닥 다지기

디스크 아끼려는 거라고
생각했는데, 재보니 아니었습니다.

에이전트를 여러 개 돌리는 도구들이 하나같이 git worktree 위에 서 있습니다. 왜인지 궁금해서 직접 돌려봤습니다. 제가 짐작했던 이유는 측정 결과 틀렸고, 다른 이유가 나왔습니다.

앞선 두 편에서 ADE 도구들을 GitHub에서 직접 세어봤고, 라이선스가 셋 다 다르다는 것도 확인했습니다. 그런데 도구 소개만 읽다 보면 정작 "그래서 이게 어떻게 동작하는 건데"가 안 잡힙니다. 이번엔 도구를 덮고 그 밑에 깔린 것을 봤습니다.

📌 30초 요약

• git worktree는 저장소 하나에 작업 폴더를 여러 개 만드는 기능입니다.
• 워크트리의 .git은 폴더가 아니라 146바이트짜리 파일이었습니다.
• "디스크를 아낀다"는 제 추측은 틀렸습니다. 로컬 git clone도 하드링크를 써서 용량이 같았습니다 — 실측 59MB 대 59MB.
• 진짜 차이는 커밋이 서로 보이느냐였습니다. clone은 0건, worktree는 즉시 1건.
• 걸리는 지점 셋: 같은 브랜치 두 번 불가 · 파일 남으면 삭제 거부 · 폴더를 손으로 지우면 prune 필요.

🔬 이 글의 실측 범위 — 먼저 밝힙니다

직접 실행한 것 : 아래 나오는 git worktree 명령과 출력 전부. 임시 저장소를 만들어 돌렸고, 붙여넣은 출력은 편집하지 않았습니다(경로만 줄였습니다). 환경은 Windows · git 2.55.0입니다.

하지 않은 것 : ADE 도구는 하나도 설치하지 않았습니다. Orca도 cmux도 실행하지 않았습니다. 그 도구들이 내부적으로 worktree를 어떻게 쓰는지는 제가 코드를 열어 확인한 게 아닙니다. 그리고 tmux는 이 PC(윈도우)에 없어서 tmux 이야기는 아예 하지 않겠습니다.

① 문제부터 — 에이전트 셋이 한 폴더를 쓰면

AI 에이전트에게 일을 시키다 보면 자연스럽게 욕심이 납니다. "하나씩 기다리지 말고 세 개를 동시에 돌리면 안 되나?" 그런데 그냥 세 개를 띄우면 곧바로 부딪힙니다. 셋이 같은 폴더의 같은 파일을 고치기 때문입니다.

브랜치를 나누면 될 것 같지만 안 됩니다. 브랜치를 바꾼다는 건 같은 폴더의 파일을 갈아끼우는 일이라, 한 에이전트가 브랜치를 바꾸면 나머지 둘의 발밑이 통째로 바뀝니다. 그래서 필요한 건 작업 폴더 자체가 여러 개인 구조입니다.

② 실제로 만들어봤습니다

커밋 두 개짜리 저장소를 만들고 워크트리를 붙였습니다. 아래는 제 화면에 찍힌 그대로입니다.

$ git worktree add ../feat-a -b feature-a
Preparing worktree (new branch 'feature-a')
HEAD is now at f187fd0 add app

$ git worktree list
.../wt-lab/demo     f187fd0 [main]
.../wt-lab/feat-a   f187fd0 [feature-a]

폴더가 두 개가 됐고, 각자 다른 브랜치를 물고 있습니다. 파일이 정말 독립인지도 확인했습니다.

# feat-a 쪽 파일만 고쳐본 뒤
$ cat app.py            # 메인 폴더
print('hello')

$ cat ../feat-a/app.py  # 워크트리
print('CHANGED in feat-a')

완전히 따로 놉니다. 에이전트 셋에게 폴더를 하나씩 주면 서로 안 밟는다는 게 이 지점입니다.

③ .git이 폴더가 아니었습니다

여기서 제일 재미있었던 대목입니다. 워크트리 폴더의 .git을 열어봤더니 디렉터리가 아니라 파일이었습니다.

$ ls -la ../feat-a/.git
-rw-r--r-- 1 admin 197121 146 Aug 13 20:04 ../feat-a/.git
        ↑ 맨 앞이 d 가 아니라 - 입니다. 파일입니다.

$ cat ../feat-a/.git
gitdir: .../wt-lab/demo/.git/worktrees/feat-a

146바이트짜리 쪽지 한 장입니다. 내용은 "진짜 저장소는 저쪽에 있다"는 안내가 전부입니다. 워크트리는 저장소를 복제하는 게 아니라 원본을 가리키는 포인터만 들고 있는 작업 폴더입니다.

④ 제가 틀렸습니다 — 디스크 때문이 아니었습니다

여기까지 보고 저는 답을 다 안 줄 알았습니다. "clone을 세 번 하면 저장소가 세 벌이니까, worktree가 디스크를 아끼는 거구나." 그럴듯했고, 실제로 그렇게 설명하는 글도 봤습니다. 그래서 재봤습니다.

히스토리에 20MB짜리 부피를 만들어 넣고, 같은 저장소를 clone한 것과 worktree add한 것을 나란히 놓고 용량을 쟀습니다.

측정 대상	단독 측정	원본과 합산
원본 저장소	39 MB	—
git clone	39 MB	59 MB
worktree add	20 MB	59 MB

🔍 합산하면 똑같습니다 — 왜인지 확인했습니다

단독으로 재면 clone이 두 배로 보이는데, 원본과 함께 재면 둘 다 59MB로 같습니다. 이상해서 팩 파일의 아이노드를 찍어봤습니다.

원본  pack: inode=6755399441303995 links=4
clone pack: inode=6755399441303995 links=4
              ↑ 같은 아이노드 = 같은 파일입니다

같은 디스크에서 로컬 clone을 하면 git이 객체 파일을 하드링크로 연결합니다. 복사가 아니라 같은 파일을 가리키는 겁니다. 그러니 "worktree가 clone보다 디스크를 아낀다"는 제 추측은 이 조건에서 틀렸습니다. 단독 측정치만 봤으면 그대로 틀린 글을 쓸 뻔했습니다.

다만 범위는 좁혀서 말하겠습니다. 하드링크가 걸리는 건 같은 디스크에서, 로컬 경로로 clone할 때입니다. GitHub 같은 원격에서 clone하면 히스토리를 처음부터 다시 받아야 하니 그때는 이야기가 다릅니다. 그리고 이건 제가 윈도우 한 대에서 잰 결과입니다 — 파일시스템이 다르면 달라질 수 있습니다.

⑤ 그럼 진짜 이유는 — 커밋이 보이느냐

디스크가 아니라면 뭘까. 양쪽에서 커밋을 하나씩 만들고 원본에서 그 커밋이 보이는지 확인했습니다.

# clone 안에서 커밋한 뒤, 원본에서 찾아보면
$ git log --oneline --all | grep -c 'commit in clone'
0

# worktree 안에서 커밋한 뒤, 원본에서 찾아보면
$ git log --oneline --all | grep -c 'commit in worktree'
1

💡 이게 답이었습니다

clone은 저장소가 둘입니다. 에이전트가 거기서 뭘 하든 원본은 모릅니다. 가져오려면 push나 fetch를 한 단계 더 거쳐야 합니다.

worktree는 저장소가 하나입니다. 폴더만 여러 개일 뿐 브랜치도 커밋도 전부 공유합니다. 에이전트 셋이 각자 폴더에서 일하고, 끝나면 그 자리에서 바로 합칠 수 있습니다. 병렬로 돌리는 도구가 이 구조를 고르는 이유로는 이쪽이 훨씬 말이 됩니다.

다만 여기서 한 발 더 나가지는 않겠습니다. 이건 제가 worktree와 clone을 비교해 얻은 결론이지, ADE 도구 개발자들이 그 이유로 골랐다는 걸 확인한 게 아닙니다. 그들의 설계 문서를 읽거나 코드를 열어본 게 아니니까요. "이래서 유리하다"까지가 제가 말할 수 있는 범위입니다.

⑥ 걸리는 지점 셋 — 미리 알고 가세요

실제로 돌리면서 막힌 곳들입니다. 전부 제가 직접 받은 에러 메시지입니다.

1. 같은 브랜치를 두 곳에서 열 수 없습니다

$ git worktree add ../dup main
Preparing worktree (checking out 'main')
fatal: 'main' is already used by worktree at '.../demo'

불편해 보이지만 안전장치입니다. 같은 브랜치를 두 폴더에서 열면 어느 쪽 상태가 진짜인지 알 수 없어집니다. 그래서 에이전트마다 브랜치를 따로 주는 게 강제됩니다.

2. 파일이 남아 있으면 삭제를 거부합니다

$ git worktree remove ../feat-a
fatal: '../feat-a' contains modified or untracked files,
       use --force to delete it

에이전트가 로그나 임시 파일을 흘려놓으면 매번 여기서 걸립니다. --force를 붙이면 지워지는데, 그 안에 커밋 안 한 작업이 있으면 같이 날아갑니다. 습관적으로 --force부터 치지 마세요.

3. 폴더를 손으로 지우면 목록에 유령이 남습니다

# 탐색기에서 폴더를 지운 뒤
$ git worktree list
.../wt3   8a5e840 [b3] prunable

$ git worktree prune   # 이걸 돌려야 목록에서 빠집니다

git이 prunable이라고 표시는 해줍니다. 폴더 삭제는 탐색기로 하지 말고 git worktree remove로 하는 게 깔끔합니다.

⑦ 지워도 작업은 안 없어집니다

제일 마음이 놓였던 부분입니다. 워크트리를 --force로 지운 뒤 브랜치 목록을 봤습니다.

$ git worktree remove --force ../feat-a
$ git branch --list
  feature-a   ← 브랜치는 그대로 남아 있습니다
* main

워크트리를 지우는 건 폴더를 치우는 것이지 브랜치를 지우는 게 아닙니다. 커밋해둔 작업은 브랜치에 그대로 있으니, 나중에 다시 worktree add ../다시 feature-a로 꺼내 쓰면 됩니다. 에이전트를 여러 개 돌리다 정리할 때 안심하고 치워도 되는 이유가 여기 있습니다.

⑧ 5분이면 직접 해보실 수 있습니다

쓰던 저장소 말고 새 폴더에서 해보세요. 아래는 제가 돌린 순서 그대로입니다.

# 1) 연습용 저장소
git init -b main demo
cd demo
git commit --allow-empty -m init

# 2) 워크트리 붙이기
git worktree add ../feat-a -b feature-a

# 3) 확인
git worktree list
cat ../feat-a/.git      # 쪽지 한 장

# 4) 정리
git worktree remove ../feat-a
git branch --list       # 브랜치는 남습니다

이 바닥을 한 번 만져보고 나면 ADE 도구 소개글이 다르게 읽힙니다. "에이전트를 격리한다"는 문구가 무슨 뜻인지, 왜 브랜치를 하나씩 만드는지가 그림으로 잡히거든요.

자주 묻는 것

Q. 그럼 clone은 쓰면 안 되나요?

그런 말이 아닙니다. 완전히 격리해야 할 때는 clone이 맞습니다 — 저장소가 아예 둘이니 한쪽이 망가져도 다른 쪽이 무사합니다. 다만 "여러 갈래로 일하고 곧 합칠 것"이라면 worktree 쪽이 단계가 적습니다.

Q. 워크트리를 몇 개까지 만들 수 있나요?

모릅니다. 상한 문서를 확인하지 않았고, 저는 최대 세 개까지만 만들어봤습니다. 다만 작업 파일은 폴더마다 실제로 복사되니(공유되는 건 히스토리 쪽입니다) 저장소가 크면 디스크는 개수만큼 늘어납니다.

Q. node_modules 같은 건 어떻게 되나요?

git이 추적하지 않는 파일은 새 워크트리에 딸려오지 않습니다. 폴더마다 다시 설치해야 한다는 뜻입니다. 다만 이건 제가 실제로 설치해보고 잰 게 아니라 추적 대상이 아니라는 사실에서 나오는 결론이라, 도구별로 어떻게 처리하는지는 따로 보셔야 합니다.

Q. 윈도우에서도 되나요?

이 글의 출력이 전부 윈도우에서 나온 것입니다. git 2.55.0 기준으로 문제없이 동작했습니다.

✨ 정리하면

워크트리는 저장소 하나에 작업 폴더를 여러 개 다는 기능입니다. .git은 146바이트 쪽지 한 장이고요.

디스크를 아끼려는 거라고 짐작했는데 재보니 아니었습니다. 로컬 clone도 하드링크를 써서 용량이 같았습니다. 진짜 차이는 커밋이 서로 보이느냐였습니다 — clone 0건, worktree 즉시 1건.

도구를 고르기 전에 이 바닥을 5분만 만져보세요. 소개글이 다르게 읽힙니다.

🔗 ADE 시리즈

• 1편 — 비교글을 믿기 전에 GitHub에서 직접 세어봤습니다
• 2편 — 설치 전에 라이선스부터, 세 개가 전부 달랐습니다
• 모델 쪽 라이선스 — Qwen3.8은 Apache가 아니었습니다
• 사용량 지출 상한 거는 법 — 병렬은 토큰도 병렬입니다
• 내 PC로 어떤 AI가 돌아가나 — 여러 개 돌리기 전 사양 확인

---

확인 시점 — 2026년 8월 13일 저녁. ✅ 직접 실행 : 임시 저장소를 만들어 git worktree add / list / remove / prune, 로컬 clone과의 용량 비교(du), 팩 파일 아이노드 확인(stat), 양쪽 커밋 가시성 비교. 환경은 Windows 10 · git 2.55.0.windows.3이며, 인용한 출력은 경로만 줄였고 문구는 그대로입니다. 테스트 저장소는 측정 후 삭제했습니다. 확인하지 않은 것 : ADE 도구(Orca·cmux·Claude Squad 등) 설치·실행 및 내부 구현 · 그 도구들이 worktree를 선택한 실제 이유 · 워크트리 개수 상한 · tmux 관련 사항(이 PC에 없음) · 리눅스·맥 및 다른 파일시스템에서의 동작. 디스크 측정은 같은 디스크·로컬 경로 clone 조건이며, 원격에서 clone하면 결과가 다릅니다. 제휴·협찬 없습니다.