에이전트 여럿, 저장소 하나 부록 — 도구 지도 2026: 언제 무엇을 쓰나

크게 보기

들어가며: 민지의 북마크 폴더가 넘친다

여섯 편 동안 민지와 도윤은 한 가지 방식을 몸에 익혔습니다. 폴더를 동기화하지 않고 Git으로 주고받는다. 작업 하나에 worktree 하나, 브랜치 하나, 에이전트 세션 하나를 짝짓는다. Mac을 바꿀 때는 push하고 fetch한다. 개발환경은 저장소 안의 mise.toml과 AGENTS.md로 재현한다.

그런데 이 방식에 익숙해질수록 민지의 브라우저 북마크 폴더에는 새 도구가 쌓였습니다. "에이전트 열 개를 한 화면에서 관제하는 앱", "worktree 없이 한 폴더에서 브랜치 여러 개를 동시에 쓰는 git 클라이언트", "git을 대신할 차세대 버전 관리 도구", "GitHub 없이 사내에 두는 코드 호스팅". 전부 좋아 보이고, 전부 "병렬 에이전트 시대의 필수품"이라고 소개합니다.

도윤의 질문은 단순했습니다. "그래서 우리 뭐 깔아야 해? 다 깔 수는 없잖아."

이번 부록은 그 질문에 답하는 지도입니다. 도구마다 무엇인지, worktree와 어떤 관계인지, 언제 쓰고 언제 피하는지, 얼마나 성숙했는지, 라이선스와 플랫폼은 무엇인지를 같은 틀로 정리합니다. 결론을 먼저 말하면, 대부분의 팀은 GitHub + Worktrunk(또는 Claude Code --worktree) + mise로 시작하면 되고, 에이전트 다섯 개 이상이 상시로 돌기 시작하면 그때 관제 앱을 하나 얹으면 됩니다. 나머지는 특별한 이유가 있을 때 꺼내는 도구입니다.

1. 지도를 읽는 법: 모든 도구는 층으로 나뉜다

도구를 하나씩 보기 전에 지도부터 펼쳐 봅시다. 병렬 에이전트 작업에 쓰이는 도구는 다섯 층으로 나누면 머릿속이 정리됩니다. 아파트에 비유하면 이렇습니다. 땅(원격 저장소) 위에 건물 뼈대(git과 worktree)가 서 있고, 그 위에 각 집을 편하게 쓰게 해 주는 설비(CLI와 에이전트 앱 기능)가 붙고, 맨 위에 모든 집을 한눈에 보는 관리실(관제 앱)이 있습니다. 그리고 모든 집에 같은 규격의 전기·수도(개발환경)가 들어갑니다.

이 그림에서 가장 중요한 사실은 가운데 초록색 층입니다. ④층과 ⑤층의 도구는 거의 전부 git worktree 위에 올라가 있습니다. Worktrunk는 git worktree add를 짧게 줄여 주고, Claude Code 데스크톱은 세션마다 worktree를 만들고, Orca와 Conductor 같은 관제 앱도 공식 문서에 "작업공간마다 git worktree를 만든다"고 적혀 있습니다.

이게 왜 중요할까요? 도구를 바꿔도 작업이 사라지지 않기 때문입니다. 관제 앱을 지워도 그 앱이 만든 worktree와 브랜치는 git worktree list와 git branch에 그대로 남아 있습니다. 2편에서 배운 명령으로 언제든 직접 다룰 수 있습니다. 반대로 ③층을 GitButler나 Jujutsu로 바꾸는 것은 뼈대를 바꾸는 일이라, 팀 전체의 습관과 훅·CI까지 영향을 받습니다. 그래서 이 글의 권장은 "위층은 가볍게 갈아 끼우고, 뼈대는 git으로 둔다"입니다.

크게 보기

아래 위젯에서 도구 13개를 형태·격리 방식·라이선스·플랫폼으로 걸러 볼 수 있습니다. 카드를 누르면 worktree와의 관계, 쓸 때와 피할 때가 펼쳐집니다.

도구를 판단할 때 쓸 잣대도 미리 정해 둡시다. 이 글은 다섯 가지를 봅니다.

2. CLI 층: Worktrunk — 터미널 사용자의 기본값

Worktrunk(명령 이름 wt)는 3편에서 직접 실습한 도구입니다. 한 줄 풀이: git worktree를 브랜치처럼 쉽게 쓰게 해 주는 명령줄 도구입니다. 공식 README는 이렇게 소개합니다. "AI 에이전트를 병렬로 돌리기 위해 설계된 git worktree 관리 CLI."

순수 git으로 worktree를 만들고 그 안에서 Claude Code를 띄우려면 git worktree add -b feat ../repo.feat, cd ../repo.feat, claude를 차례로 쳐야 합니다. README의 표현대로 "브랜치 이름을 세 번 쳐야" 하죠. Worktrunk에서는 wt switch -c -x claude feat 한 줄입니다. 정리도 wt remove 한 번이면 폴더와 브랜치를 함께 치웁니다.

3편 내용을 짧게 복습하는 의미로, 스크래치 폴더에 git init --bare로 가짜 원격을 만들고 cafe-menu를 clone해서 에이전트 두 대분의 worktree를 만들어 봤습니다. -x claude 대신 무해한 -x 'pwd'를 넣었습니다. 실제로는 그 자리에서 Claude Code가 뜹니다.

wt switch -c agent/search-claude --no-cd -x 'pwd'
wt switch -c agent/search-codex --no-cd
wt list

  Branch               Status      HEAD±     main↕    main…±    Remote⇅  Path                              Commit    Age  Message
@ main                     ^|                                      |     .                                 60aec7c   now  Initial order web app
+ agent/search-claude      _                                             ../cafe-menu.agent-search-claude  60aec7c   now  Initial order web app
+ agent/search-codex       _                                             ../cafe-menu.agent-search-codex   60aec7c   now  Initial order web app

○ Showing 3 worktrees

같은 상태를 git으로 보면 이렇습니다(경로는 /Users/minji로 바꿔 적었습니다).

git worktree list

/Users/minji/cafe-menu                      60aec7c [main]
/Users/minji/cafe-menu.agent-search-claude  60aec7c [agent/search-claude]
/Users/minji/cafe-menu.agent-search-codex   60aec7c [agent/search-codex]

두 출력이 같은 사실을 말한다는 점이 핵심입니다. Worktrunk는 git worktree를 감싸기만 합니다. 내일 Worktrunk를 지워도 저 세 폴더는 그대로 git worktree입니다.

이럴 때 씁니다. 터미널과 tmux·iTerm 탭에 익숙하고, 에이전트 두세 개에서 열 개 정도를 돌릴 때. Claude Code와 Codex를 섞어 쓸 때도 -x 뒤에 띄울 명령만 바꾸면 됩니다. wt merge main으로 squash·rebase·병합·정리를 한 번에 하는 흐름은 5편의 "좋은 것만 합치기"와도 잘 맞습니다.

이럴 땐 피합니다. 터미널 자체가 부담스러운 팀원에게 강요할 때. 그리고 "에이전트 여덟 개 중 누가 지금 권한 승인을 기다리는지"를 한눈에 봐야 할 때입니다. wt list는 상태를 보여 주지만 에이전트가 무엇을 기다리는지까지는 모릅니다. 그 빈자리를 채우는 게 5장의 관제 앱입니다.

3. 에이전트 앱에 이미 들어 있는 것: Claude Code와 Codex

별도 도구를 깔기 전에, 쓰고 있는 에이전트에 이미 worktree 기능이 들어 있다는 사실부터 짚어야 합니다. 3편에서 자세히 다뤘으니 여기서는 두 앱을 나란히 놓고 차이만 봅니다.

Claude Code: CLI의 --worktree와 데스크톱의 worktree 옵션

터미널에서는 claude --worktree 이름(짧게 -w)으로 세션을 시작하면 저장소 루트의 .claude/worktrees/<이름>/에 worktree가 생기고 worktree-<이름> 브랜치에서 세션이 열립니다. 로컬에 설치된 Claude Code 2.1.283의 claude --help에도 -w, --worktree [name]이 "이 세션을 위해 새 git worktree를 만든다"고 나옵니다.

데스크톱 앱에서는 공식 문서에 따르면 새 세션을 열 때 브랜치 이름 옆의 worktree 옵션을 고르면 됩니다. 문서가 밝힌 동작을 추리면 이렇습니다.

• 사이드바의 + New session(macOS Cmd+N)으로 여러 세션을 병렬로 열고, Cmd를 누른 채 다른 세션을 클릭하면 두 세션을 나란히 볼 수 있다.
• worktree는 기본으로 <프로젝트 루트>/.claude/worktrees/에 생기고, 설정에서 위치와 브랜치 접두사를 바꿀 수 있다.
• .worktreeinclude는 --worktree, 서브에이전트, 데스크톱 병렬 세션 모두에 적용된다.
• 다 쓴 세션은 사이드바의 보관(archive) 아이콘으로 정리하고, "PR이 머지되거나 닫히면 자동 보관" 설정을 켤 수 있다.
• diff 화면에서 줄을 클릭해 코멘트를 달고 한 번에 보낼 수 있다.
• 데스크톱은 macOS·Windows·Linux(베타, Ubuntu·Debian용 apt/.deb)를 지원한다.

마지막 두 줄이 눈여겨볼 대목입니다. "diff에 인라인 코멘트를 달아 에이전트에게 되돌려 보내기"는 5장의 관제 앱들이 앞세우는 기능인데, Claude Code 데스크톱에도 들어 있습니다. Claude Code만 쓰는 팀이라면 관제 앱이 필요한 시점이 생각보다 늦게 옵니다.

Codex 앱: 관리형 worktree와 Handoff

Codex 쪽은 OpenAI 개발자 문서의 Worktrees 페이지에서 확인했습니다. 2026년 9월 현재 문서는 Codex 앱을 ChatGPT 데스크톱 앱 안에서 쓰는 것으로 설명합니다. Claude Code와 비슷해 보이지만 설계가 꽤 다릅니다.

재미있는 점은 두 앱 모두 .worktreeinclude라는 같은 이름의 파일을 읽는다는 것입니다. 6편에서 만든 .worktreeinclude 하나로 두 에이전트의 worktree에 .env가 똑같이 복사됩니다. 저장소 안의 파일로 환경을 맞춘다는 세 번째 원칙이 도구가 달라도 통하는 셈입니다.

detached HEAD 기본값은 알고 있어야 할 함정입니다. 1편에서 정한 브랜치 이름 규칙(agent/search-codex처럼)을 지키려면 Codex worktree에서 작업을 살릴 때 직접 브랜치를 만들어야 합니다. 그렇지 않으면 4편처럼 다른 Mac에서 fetch해 이어받을 이름표가 없습니다. Codex 문서도 "Git은 한 브랜치를 한 곳에서만 체크아웃할 수 있다"는 2편의 규칙을 그대로 강조합니다. worktree에서 브랜치를 만들면 로컬 체크아웃에서는 같은 브랜치를 동시에 열 수 없습니다.

이럴 때 씁니다. 에이전트 하나(또는 한 회사 제품)만 쓸 때. 설치할 것이 하나도 늘지 않습니다. 에이전트 두세 개까지는 이것만으로 충분한 경우가 많습니다.

이럴 땐 부족합니다. Claude Code와 Codex를 동시에 섞어 돌리며 한 화면에서 관제하고 싶을 때. 각 앱은 자기 세션만 보여 줍니다.

4. worktree에 대해 한 번 더: 왜 모두 worktree를 쓰나

관제 앱으로 넘어가기 전에, 왜 거의 모든 도구가 worktree를 고르는지 짚고 가겠습니다. 이 이유를 알아야 6장의 GitButler가 "worktree 대신 한 폴더"를 내세울 때 무엇을 얻고 무엇을 잃는지 판단할 수 있습니다.

2편에서 봤듯 worktree끼리는 .git 안의 기록(커밋·브랜치·태그·설정)을 공유하고, 작업 폴더의 파일·스테이징 영역·HEAD는 따로 가집니다. 에이전트 입장에서 이것은 세 가지를 뜻합니다.

대가도 있습니다. 폴더가 늘어나니 디스크를 더 쓰고, worktree마다 의존성 설치 시간이 듭니다. Worktrunk의 빌드 캐시 공유나 Orca 문서가 말하는 "macOS에서는 가능하면 APFS clone-copy" 같은 기능이 이 대가를 줄이려는 시도입니다. 이 비용이 아깝다고 느끼는 지점에서 GitButler 같은 대안이 등장합니다.

5. 관제 앱(미션 컨트롤): 에이전트가 다섯을 넘을 때

에이전트가 두세 개일 때는 터미널 탭을 오가며 버틸 수 있습니다. 다섯 개를 넘으면 사정이 달라집니다. Daintree의 README가 이 상황을 정확하게 묘사합니다. "터미널 다섯 개, 에이전트 세 개, 누가 멈춰 있는지 모른다." 그리고 "생성은 빠르다. 돌아온 것을 감독하는 일이 하루를 잡아먹는다."

관제 앱은 비행장 관제탑 같은 것입니다. 비행기(에이전트)는 각자 활주로(worktree)에서 뜨고 내리지만, 관제탑은 어느 비행기가 착륙 허가(권한 승인)를 기다리는지, 어느 비행기가 도착(작업 완료)했는지를 한 화면에 보여 줍니다. 2026년 9월 현재 공식 저장소와 문서로 확인한 네 가지를 봅니다.

크게 보기

Daintree — 여러 회사 에이전트를 한데 모으는 위임 환경

Daintree는 저장소 설명에서 스스로를 "AI 코딩 에이전트를 지휘하기 위한 위임 환경(delegation environment)"이라고 부릅니다. Claude, Gemini, Codex 세션을 git worktree마다 띄우고, 통합 터미널·컨텍스트 주입·워크플로 자동화를 제공한다는 설명입니다.

README에서 확인한 핵심 기능은 이렇습니다.

• Fleet Broadcasting: 프롬프트 하나를 N개 에이전트에 한꺼번에 보낸다. 보내기 전에 에이전트별로 고칠 수 있다.
• Worktree Dashboard: 모든 브랜치를 한 화면에. PR·이슈 자동 감지, 개발 서버 관리, 커밋 작성기.
• Notification Center: 무엇이 사람을 기다리고 무엇은 기다려도 되는지 알려 주는 알림함.
• Daintree Assistant: 이미 설치된 에이전트 CLI(Claude Code, Gemini CLI, Codex, GitHub Copilot CLI) 위에서 돌며 에이전트 터미널을 띄우고, 진행을 지켜보고, git 작업을 대신한다. 백엔드가 Claude Code면 로컬 daintree MCP 서버에 붙는다.
• README의 "Works with" 목록에 Claude Code, Codex, Gemini CLI, Cursor, Aider, Goose, Amp 등 17가지 에이전트가 올라 있다.

Orca — 사용자가 가장 많은 오픈소스 관제 IDE

Orca는 README에서 "병렬 에이전트 무리와 일하기 위한 ADE"라고 소개합니다. Codex, Claude Code, OpenCode 등을 각자의 worktree에서 나란히 돌리고 한곳에서 추적한다는 설명입니다. 공식 문서에 따르면 worktree는 git worktree add로 만들고, 삭제할 때 폴더와 브랜치를 함께 지우되 병합 안 된 커밋이 있어 git이 브랜치를 지키면 그 브랜치를 남겨 두고 알려 줍니다.

• Parallel Worktrees: 프롬프트 하나를 다섯 에이전트에 뿌려 각자의 worktree에서 풀게 하고, 결과를 비교해 이긴 것을 머지한다. 5편의 "경쟁 구현"을 앱 기능으로 만든 셈이다.
• Annotate AI Diffs: diff 줄에 코멘트를 달아 에이전트에게 돌려보낸다.
• SSH Worktrees: 원격 서버에서 에이전트를 돌리고 파일 편집·git·터미널을 쓴다.
• Mobile Companion: 휴대폰에서 에이전트 상태를 보고 후속 지시를 보낸다(iOS 앱, Android APK).
• Orca CLI: orca worktree create 같은 명령으로 에이전트가 Orca를 조작한다.

Workstreams — diff 인라인 코멘트에 집중한 macOS IDE

Workstreams는 README 첫 줄이 "격리된 git worktree에서 병렬 AI 코딩 에이전트를 지휘하는 IDE"입니다. 기능은 네 가지로 정리돼 있습니다. worktree별 실시간 추가·삭제 줄 수가 보이는 사이드바, 좌우 분할 diff에 코멘트를 달아 파일 경로·줄 번호·diff 맥락이 담긴 구조화된 프롬프트로 Claude에게 보내는 인라인 리뷰, 작업마다 에이전트를 고르고 worktree를 만드는 생성 화면, 그리고 Claude Code 훅으로 추적하는 에이전트 상태(대기·작업 중·권한 대기·리뷰 준비)입니다. ws init·ws create·ws run·ws dashboard로 이어지는 CLI도 있습니다(Bun 필요).

"diff에 코멘트 → 구조화된 프롬프트로 되돌려 보내기"는 5편에서 사람이 손으로 하던 리뷰 루프를 가장 직접적으로 도구화한 형태입니다. 하지만 도입 전에 알아야 할 점이 셋 있습니다.

에이전트 지원 범위도 문서끼리 조금 다릅니다. README는 "Claude, Codex, Aider 등과 동작"이라고 쓰고, 공식 사이트는 "Claude Code는 깊이 통합, Aider·Gemini 지원, Codex는 곧 지원"이라고 씁니다. 필자는 앱을 직접 설치해 확인하지 않았으므로 Codex 지원 여부는 단정하지 않겠습니다. 정리하면, 인라인 리뷰 흐름을 맛보기로 시험하기에는 좋지만 팀 표준으로 삼기에는 성숙도 신호가 약합니다.

Conductor — Mac 전용 상용 앱 (한 줄 요약)

Conductor는 공식 사이트에서 "Mac에서 Claude Code, Codex, Cursor 에이전트를 격리된 작업공간에서 병렬로 실행"한다고 소개합니다. 공식 문서의 개념 설명에 따르면 작업공간을 만들 때마다 git worktree를 만들고 그 안에서 브랜치를 체크아웃하며, 작업공간은 보통 ~/conductor/workspaces/<저장소 이름>/<작업공간 이름>에 생깁니다. Homebrew에는 conductor 캐스크 0.87.5가 올라 있습니다. 사이트에 가격·엔터프라이즈 메뉴가 있는 상용 제품이고, 필자는 공개된 소스 저장소를 찾지 못했습니다. 구체적인 요금 조건은 확인하지 않았으니 공식 사이트에서 보세요.

관제 앱, 언제 필요한가

네 앱을 보고 나면 공통점이 보입니다. 모두 작업 하나 = worktree 하나라는 1원칙을 그대로 구현합니다. 차이는 그 위의 편의 기능과 성숙도입니다. 그래서 이 글의 기준은 에이전트 수입니다.

관제 앱을 고를 때 한 가지 안심해도 되는 사실이 있습니다. 모두 git worktree 위에 있으므로, 석 달 뒤 더 좋은 앱이 나와 갈아타도 브랜치와 커밋은 그대로입니다. 갈아탈 때 할 일은 옛 앱이 만든 worktree를 git worktree list로 확인하고, 필요 없는 것을 git worktree remove로 치우는 정도입니다(2편).

6. GitButler: worktree 대신 "한 폴더에 브랜치 여러 개"

이제 ③층의 옆 갈래로 넘어갑니다. GitButler는 README에서 "AI 기반 워크플로를 위해 처음부터 만든, GUI와 CLI를 모두 갖춘 git 기반 버전 관리 인터페이스"라고 소개합니다. 기존 git 저장소 어디서든 바로 쓸 수 있고, 데스크톱 앱과 같은 Rust 엔진을 쓰는 but CLI가 있습니다.

GitButler의 대표 기능이 parallel branches(예전 이름 virtual branches)입니다. 한 줄 풀이: 작업 폴더 하나에 여러 브랜치를 동시에 적용해 두고, 바뀐 줄마다 어느 브랜치에 속할지 나눠 담는 방식입니다. 문서의 표현으로는 "브랜치를 계속 오가는 대신 여러 브랜치에서 동시에 작업을 정리한다"입니다.

비유하면 이렇습니다. worktree 방식은 에이전트마다 책상을 따로 주는 것입니다. 책상마다 자기 서류와 자기 연필꽂이가 있습니다. parallel branches는 큰 책상 하나에 서류철을 여러 개 펼쳐 두고, 쓴 종이를 어느 서류철에 넣을지 나중에 나누는 것입니다. 책상을 여러 개 들일 필요가 없지만, 두 사람이 같은 종이에 쓰기 시작하면 곤란해집니다.

크게 보기

공식 문서가 직접 말하는 "언제 worktree, 언제 parallel branches"

반가운 점은 GitButler가 이 선택 기준을 스스로 문서에 적어 두었다는 것입니다. "Parallel agents" 문서의 내용을 옮기면 이렇습니다.

그리고 문서는 이렇게 못 박습니다. "Parallel GitButler branches are not runtime isolation." 에이전트들이 파일 시스템, 의존성 설치, 생성된 파일, 앱 상태를 모두 공유한다는 뜻입니다. 문서는 이것이 겹침과 빌드 문제를 일찍 드러내 주기도 하지만 "우연한 의존성을 숨길 수도 있다"고 덧붙이고, 두 세션이 같은 파일이나 생성물을 건드리면 커밋 전에 에이전트가 겹침을 알리게 하라고 권합니다.

이 기준을 시리즈에 대입하면 답이 분명해집니다. 5편의 "두 에이전트에게 같은 일 시키기"는 문서가 말하는 경쟁하는 시도이므로 worktree가 맞습니다. 2편에서 본 worktree별 포트·node_modules가 필요한 상황은 실행 상태를 따로 가져야 하는 경우이므로 역시 worktree입니다. 반면 "README 오타 수정"과 "메뉴 가격표 CSS 조정"처럼 서로 다른 파일을 건드리는 작은 일 두 개라면 GitButler가 폴더 하나로 가볍게 처리해 줍니다.

알아 둘 동작: gitbutler/workspace 브랜치

GitButler를 켠 저장소는 평범한 git 저장소와 조금 다르게 보입니다. 공식 문서에 따르면 GitButler는 작업 공간에 적용된 parallel branches를 한데 합친 머지 커밋을 gitbutler/workspace라는 특수 브랜치로 만들어 둡니다. 순수 git에는 "여러 브랜치를 동시에 적용"이라는 개념이 없으니, 다른 git 도구가 이해할 수 있는 모양으로 보여 주려는 장치입니다.

그래서 GitButler 모드에서 평소처럼 git commit을 치면 GitButler가 설치한 훅이 "gitbutler/workspace 브랜치에 직접 커밋할 수 없다"며 막습니다. git checkout으로 다른 브랜치로 가려 할 때도 보호 장치가 동작합니다. 순수 git으로 돌아가려면 문서가 안내하는 대로 but teardown을 실행하거나 다른 브랜치를 직접 체크아웃하면 됩니다.

이 동작은 에이전트와 쓸 때 특히 중요합니다. 에이전트는 평소 git commit을 직접 치는 데 익숙합니다. GitButler의 parallel agents 문서는 에이전트가 버전 관리 쓰기 작업을 GitButler로 하게 된 다음에야 같은 저장소에서 두 번째 세션을 열라고 설명하고, README는 여러 에이전트 시스템용 훅이나 스킬을 쉽게 설치할 수 있다고 소개합니다. but agent setup이 써 주는 버전 관리 지침은 커밋 방식을 이끌고 싶을 때 쓰는 것이라고 문서가 덧붙입니다. 에이전트가 GitButler 방식을 모르는 채로 들어오면 커밋이 막혀 헤맬 수 있습니다.

GitButler에도 worktree 명령이 있다는 점도 흥미롭습니다. but worktree는 연결된 worktree를 나열·보관·삭제하는 명령인데, 문서에 "실험적 기능이며 worktreeManipulation 기능 플래그가 필요하다"고 적혀 있습니다. 한 폴더 방식을 앞세우는 도구조차 worktree를 완전히 버리지 않는다는 신호로 읽을 수 있습니다.

이럴 때 씁니다. 에이전트 한두 개가 서로 다른 파일을 만지는 작은 일 여럿을 동시에 할 때. worktree마다 npm install을 기다리기 싫을 때. 그리고 스택 브랜치(브랜치 위에 브랜치를 쌓기)나 무제한 되돌리기 같은 GitButler의 다른 기능이 마음에 들 때입니다.

이럴 땐 피합니다. 같은 일을 경쟁시킬 때, 개발 서버·DB·포트가 부딪칠 때, 팀원이 모두 순수 git 습관을 가지고 있어 gitbutler/workspace 브랜치가 혼란을 줄 때입니다.

7. Jujutsu(jj): git과 호환되는 다른 사고방식

Jujutsu(명령 이름 jj)는 저장소 설명이 "단순하면서도 강력한, Git과 호환되는 버전 관리 시스템"입니다. git 저장소를 그대로 뒷단 저장소로 쓰면서, 위에 전혀 다른 사용 모델을 얹습니다. 이 글에서는 설치하지 않고 공식 문서와 CHANGELOG, brew info로만 확인했습니다.

brew info jj

==> jj: stable 0.45.1 (bottled), HEAD
Git-compatible distributed version control system
https://github.com/jj-vcs/jj
Aliases: jujutsu
Not installed
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/j/jj.rb
License: Apache-2.0

두 가지 큰 차이

첫째, 작업 폴더 자체가 커밋입니다. 공식 문서에 따르면 jj는 작업 폴더 내용이 바뀌면 자동으로 커밋을 만들고, 대부분의 jj 명령이 실행될 때 작업 폴더의 변경을 커밋에 반영합니다. git처럼 add로 골라 담는 스테이징 영역이 없습니다. 에이전트가 파일을 고치는 족족 기록이 남으니 "커밋 안 한 변경이 날아가는" 사고는 줄어듭니다.

둘째, worktree 대신 workspace가 있습니다. jj workspace add로 저장소 하나에 작업 폴더를 여러 개 붙이는데, 각 workspace는 자기 .jj/ 디렉터리로 본 저장소에 연결되고 서로 다른 커밋을 동시에 체크아웃할 수 있습니다. 개념은 git worktree와 거의 같습니다. 다 쓴 workspace는 jj workspace forget으로 추적을 끊고(폴더 삭제는 따로), 한 workspace에서 다른 workspace의 작업 커밋을 고쳐 쓰면 그쪽이 "stale(낡은)" 상태가 될 수 있어 jj workspace update-stale로 맞춥니다.

git과 섞어 쓸 때: colocated 저장소와 2026년 9월의 한계

jj의 git 호환성 문서에 따르면 jj git init이나 jj git clone으로 만든 저장소는 기본으로 colocated(같은 폴더에 .jj와 .git이 함께 있는) 상태가 됩니다. CHANGELOG를 보면 이 기본값은 0.34.0(2025-10-01)부터입니다. colocated 저장소에서는 jj와 git 명령을 순서 상관없이 섞어 써도 되지만, 문서는 "git은 주로 읽기 전용 명령으로 쓰고 변경은 jj로 하는 편이 추적하기 쉽다"고 권합니다.

여기서 이 시리즈에 중요한 한계가 나옵니다. 같은 문서의 기능표에는 git worktree: 지원 안 함, 대신 jj workspace를 쓰라고 적혀 있습니다. 그리고 2026년 9월 최신 릴리스인 0.45.1까지는 colocated 저장소에서 jj workspace add로 만든 추가 workspace에 .git이 없습니다. 그 폴더 안에서는 순수 git 명령이 평소처럼 동작하지 않는다는 뜻이고, 폴더에서 git을 찾는 Claude Code의 --worktree나 관제 앱과도 자연스럽게 이어지지 않습니다.

변화는 코앞에 있습니다. jj 저장소 main 브랜치의 CHANGELOG "Unreleased" 항목에 jj workspace add가 --colocate/--no-colocate 옵션을 지원해 workspace와 함께 git worktree를 만든다는 내용, 그리고 jj workspace forget이 해당 git worktree도 지운다는 내용이 올라 있습니다. 이 때문에 최소 git 버전도 2.42로 오릅니다(git worktree add --orphan 사용). jj는 대체로 매달 초에 릴리스를 내 왔으니 곧 나올 다음 버전에 들어갈 가능성이 높지만, 이 글을 쓰는 시점에는 아직 릴리스되지 않았습니다.

Claude Code 쪽에서도 아직 jj를 일급으로 지원하지는 않습니다. Claude Code 저장소에 "/diff 패널에서 Jujutsu 작업 복사본 지원" 기능 요청이 2026-09-26에 열려 있는 상태입니다. Claude Code worktree 문서에는 git이 아닌 버전 관리 시스템을 위해 WorktreeCreate·WorktreeRemove 훅으로 worktree 생성·정리 로직을 바꿔 끼우는 방법이 있지만, 이 훅을 쓰면 .worktreeinclude가 처리되지 않는다는 단서가 붙어 있고, 필자는 jj와 이 훅을 엮어 직접 시험해 보지 않았습니다.

이럴 때 씁니다. 혼자 쓰는 저장소나 사이드 프로젝트에서 새 모델을 배워 보고 싶을 때. colocated 저장소라 팀원은 계속 git을 쓰고 나만 jj를 쓸 수 있다는 점이 입문 장벽을 낮춥니다.

이럴 땐 피합니다. 팀 표준으로 삼을 때. 6편에서 만든 pre-commit 훅과 LFS 구성이 jj에서는 동작하지 않고, 에이전트 도구들의 지원도 아직 git 중심입니다. 다음 릴리스의 --colocate가 나온 뒤 한 번 더 살펴볼 만합니다.

8. Forgejo: GitHub 대신 사내에 두는 원격 저장소

지금까지는 내 Mac 안의 도구였습니다. 이번에는 ②층, 원격 저장소입니다. 이 시리즈는 GitHub를 원격으로 썼지만, 코드가 회사 밖으로 나가면 안 되는 조직도 있습니다. 그럴 때 가장 먼저 검토할 만한 것이 Forgejo입니다. 한 줄 풀이: 직접 설치해서 운영하는 가벼운 코드 호스팅 서버입니다. 저장소·이슈·PR·CI를 사내 서버에 둘 수 있습니다.

Forgejo는 이 시리즈의 방식과 충돌하지 않습니다. 2원칙 "Mac 사이 이동 = push / fetch"에서 원격 주소만 바뀔 뿐입니다. 맥북과 맥 스튜디오가 https://github.com/minji/cafe-menu.git 대신 사내 Forgejo 주소로 push하고 fetch하면 됩니다. worktree·에이전트·관제 앱은 원격이 어디인지 신경 쓰지 않습니다.

버전 고르기: 운영 서버는 LTS로

Forgejo에서 가장 먼저 알아야 할 것은 릴리스 주기입니다. 공식 릴리스 일정 문서에 따르면 안정 버전은 분기마다(약 3개월) 고정 일정으로 나오고, 일반 버전은 다음 버전이 나온 뒤 짧은 겹침 기간까지만 지원됩니다. 몇 버전마다 하나씩 LTS(장기 지원) 버전이 지정됩니다.

2026년 9월 현재 최신 릴리스는 v16.0.5(2026-09-17)이고 brew info forgejo도 16.0.5를 가리킵니다. 하지만 v16은 LTS가 아니라서 2026년 10월 29일에 지원이 끝납니다. 그 뒤에도 보안 수정을 받으려면 v17로, 그다음엔 v18로 석 달마다 올라가야 합니다. 반면 현재 LTS인 v15.0(2026년 9월 기준 v15.0.9)은 2027년 7월 15일까지 지원됩니다.

그래서 권장은 분명합니다. 서버를 돌볼 시간이 넉넉하지 않은 조직의 운영 서버는 LTS(v15)로 시작하세요. 최신 기능이 꼭 필요하고 분기마다 업그레이드할 사람이 있다면 일반 버전을 따라가도 됩니다. 이 글이 발행되는 10월 13일 무렵에는 v17 출시가 이틀 뒤이니, 새로 설치한다면 날짜를 다시 확인하세요.

CI와 설치에서 알아 둘 것

• Forgejo Actions는 GitHub Actions와 호환을 목표로 하지 않습니다. 공식 문서의 표현은 "GitHub Actions 사용자에게 익숙하게 설계됐지만 호환되도록 설계되지는 않았다"이고, 워크플로를 옮길 때 "약간의 손질이 거의 틀림없이 필요하다"고 합니다. 6편에서 만든 CI를 옮길 때 이 점을 계산에 넣어야 합니다.
• CI를 돌리려면 Runner가 따로 필요합니다. 워크플로는 Forgejo 서버가 직접 실행하지 않고 Forgejo Runner에게 넘겨 실행합니다. 서버 하나에 Runner 하나 이상을 더 운영한다고 생각하세요.
• 설치는 Linux 바이너리나 컨테이너 이미지로. 공식 다운로드 문서는 Linux amd64 바이너리와 Docker 등에서 쓰는 컨테이너 이미지를 안내합니다. Homebrew에도 있으니 Mac에서 시험 삼아 띄워 볼 수는 있습니다.
• 라이선스는 GPL-3.0-or-later(Homebrew 포뮬러 기준)입니다.

서버를 운영하기 싫다면: Codeberg

직접 운영은 부담스럽지만 GitHub 말고 다른 곳을 원한다면 Codeberg가 있습니다. Codeberg 문서에 따르면 Codeberg는 Forgejo로 운영되는 비영리 호스팅입니다. 다만 사명이 "자유 소프트웨어를 장려하는 것"이라 자유 소프트웨어 프로젝트용이고, 비공개 저장소는 자유 소프트웨어 기여자에게 "편의를 위해 100MB까지"만 허용하며 "비공개 호스팅 서비스는 제공하지 않는다"고 명시합니다. 회사의 비공개 주문 앱 cafe-menu를 올릴 곳은 아닙니다. 오픈소스로 공개하는 프로젝트라면 좋은 선택지입니다.

9. 잠깐, 파일 동기화 도구는?

1편에서 "저장소 폴더를 Syncthing·iCloud·Dropbox로 동기화하지 말라"고 했습니다. 그렇다면 이 도구 지도에서 동기화 도구의 자리는 어디일까요?

소스가 아닌 자료입니다. git에 넣기에 부적절하고 에이전트가 만질 일도 없는 파일, 예를 들어 디자이너가 넘겨준 메뉴 사진 원본 묶음, 참고용 PDF, 개인 메모 같은 것은 Mac 사이에서 Syncthing(2026년 9월 기준 2.1.5, MPL-2.0 오픈소스)으로 맞춰도 됩니다. 단, 그 폴더는 저장소 밖에 두세요. 저장소 폴더나 worktree 폴더, 특히 .git 폴더를 동기화하면 1편에서 설명한 대로 두 Mac이 같은 기록 파일을 동시에 고치다 저장소가 망가질 수 있습니다. 저장소가 꼭 참조해야 하는 큰 파일은 6편의 Git LFS나 S3 쪽으로 보내는 것이 맞습니다.

10. 결정 흐름도와 한눈에 보는 비교표

지금까지 본 것을 순서대로 묻는 흐름도로 정리합니다. 위에서부터 질문에 답하며 내려오면 됩니다.

직접 답을 골라 보면 추천 조합이 바로 바뀌는 위젯도 준비했습니다.

그리고 이 글의 모든 도구를 한 표에 모았습니다. 모바일에서는 표를 옆으로 밀어 보세요.

권장 출발점

표가 길어도 출발점은 짧습니다.

민지와 도윤이 고른 조합도 이것입니다. 민지는 Claude Code 데스크톱의 worktree 세션을, 도윤은 터미널에서 Worktrunk를 씁니다. 둘 다 같은 GitHub 원격과 같은 mise.toml을 보기 때문에 도구가 달라도 브랜치를 주고받는 데 문제가 없습니다. 요즘 도윤은 에이전트를 여섯 개씩 돌리는 날이 늘어서 관제 앱을 시험 중입니다. 관제 앱이 만든 worktree도 결국 git worktree list에 나오니, 마음에 안 들면 지우고 돌아오면 된다는 것을 알기 때문에 부담이 없습니다.

자주 하는 질문(FAQ)

Q. 관제 앱을 쓰면 Worktrunk는 필요 없나요? 대부분은 필요 없습니다. 관제 앱이 worktree를 직접 만들고 지우니까요. 다만 한 저장소에서 두 도구가 각자 worktree를 만들면 위치 규칙이 둘로 갈립니다(Worktrunk는 저장소 옆 폴더, Claude Code는 .claude/worktrees/, Conductor는 ~/conductor/workspaces/, Codex는 $CODEX_HOME/worktrees). 어느 도구를 쓰든 가끔 git worktree list로 전체를 확인하고, 안 쓰는 것은 git worktree remove와 git worktree prune으로 정리하세요(2편).

Q. GitButler를 쓰다가 worktree로 돌아갈 수 있나요? 공식 문서에 따르면 but teardown을 실행하거나 다른 브랜치를 직접 체크아웃하면 순수 git 방식으로 돌아옵니다. GitButler의 parallel branches는 결국 평범한 git 브랜치이므로, 돌아온 뒤 각 브랜치를 git worktree add로 따로 꺼내 쓰면 됩니다. 필자는 GitButler를 직접 설치해 이 과정을 시험하지는 않았으니, 중요한 저장소라면 먼저 원격에 모든 브랜치를 push해 두고 시도하세요.

Q. Jujutsu를 쓰면 에이전트가 헷갈리지 않나요? colocated 저장소의 기본 workspace는 .git이 있어 에이전트가 git 명령을 써도 동작합니다. 문제는 추가 workspace입니다. 2026년 9월 최신 0.45.1에서는 추가 workspace에 .git이 없어 에이전트가 평소처럼 git status를 치면 기대와 다르게 동작합니다. 다음 릴리스의 --colocate가 이 간극을 메울 예정이니, 병렬 에이전트 용도라면 그때까지 기다리는 편이 낫습니다.

Q. Forgejo 최신 버전(v16)으로 설치하면 안 되나요? 안 되는 것은 아니지만 v16은 2026년 10월 29일에 지원이 끝나는 일반 릴리스라서, 계속 보안 수정을 받으려면 석 달마다 업그레이드해야 합니다. 서버 운영에 쓸 시간이 적은 팀이라면 2027년 7월 15일까지 지원되는 v15 LTS가 맞습니다.

Q. Workstreams가 오픈소스라고 들었는데 라이선스가 왜 문제인가요? 공식 사이트는 "fully open source"라고 쓰지만 저장소의 LICENSE 파일은 Elastic License 2.0입니다. 소스는 볼 수 있지만 OSI가 승인한 오픈소스 라이선스가 아니고 일부 사용 방식이 제한됩니다. 대표적으로 LICENSE에 "소프트웨어를 제3자에게 호스팅·관리형 서비스로 제공할 수 없다"는 조항이 있습니다. 개인이 쓰는 데는 대개 문제가 없지만, 회사에서 고쳐 쓰거나 재배포할 계획이라면 법무 확인이 필요합니다. GitButler의 FSL도 비슷하게 "경쟁 제품 금지 + 2년 뒤 MIT"라는 조건이 붙습니다.

Q. 이 글의 버전 정보는 언제까지 믿을 수 있나요? 짧게는 몇 주입니다. Orca는 확인한 당일에도 새 릴리스가 나왔고, Daintree는 9월에만 다섯 번 릴리스했습니다. 도구의 역할과 worktree와의 관계는 오래 가지만 버전·플랫폼·가격은 금방 바뀝니다. 설치 전에 출처 링크를 다시 확인하세요.

이번 편 요약(치트시트)

시리즈를 마치며

「에이전트 여럿, 저장소 하나」가 이 부록으로 끝납니다. 일곱 편을 한 줄씩 돌아보면 이렇습니다.

도구는 해마다, 어쩌면 달마다 바뀔 것입니다. 이 글의 표도 내년이면 절반쯤 고쳐 써야 할지 모릅니다. 그래도 바뀌지 않을 것이 있습니다. 작업 하나에 worktree 하나, Mac 사이는 push와 fetch, 환경은 저장소 안의 파일. 이 세 원칙을 지키는 한 어떤 새 도구가 나와도 "이건 몇 층 도구인가, worktree 위에 있나 옆에 있나"만 물으면 제자리를 찾을 수 있습니다.

출처

모두 2026년 9월 27일에 확인했습니다.

• Worktrunk: GitHub 저장소 max-sixty/worktrunk · worktrunk.dev
• Claude Code: Worktrees 문서 · Desktop 문서
• Codex: Codex 앱 Worktrees 문서 · openai/codex 저장소
• Daintree: GitHub 저장소 daintreehq/daintree · daintree.org
• Orca: GitHub 저장소 stablyai/orca · Worktrees 문서
• Workstreams: GitHub 저장소 workstream-labs/workstreams · runws.dev
• Conductor: conductor.build · Git worktrees 개념 문서
• GitButler: GitHub 저장소 gitbutlerapp/gitbutler · Parallel agents 문서 · Workspace Branch 문서 · but worktree 문서 · Parallel Branches 문서 · CLI 설치 문서
• Jujutsu: GitHub 저장소 jj-vcs/jj · Git compatibility 문서 · Working copy 문서 · CHANGELOG · Claude Code 기능 요청 #97508
• Forgejo: Releases · Release schedule 문서 · Download · Forgejo Actions 개요
• Codeberg: FAQ
• mise: mise.jdx.dev · Syncthing: syncthing.net