Worktrunk는 git worktree보다 명령을 얼마나 줄일까
Worktrunk는 git worktree를 대체하는 격리 기술이 아니고, 브랜치 이름으로 작업 폴더의 생성·이동·상태 확인·병합·정리를 묶는 CLI다. 기존 커밋 하나를 main에 fast-forward하고 정리하는 절차에서 셸 래퍼를 켠 Worktrunk는 6명령, 기본 Git은 9명령이었다. 2026-11-09 macOS arm64에서 Worktrunk v0.81.0, Git 2.50.1을 격리 실행한 결과다.
Worktrunk가 덜어 주는 것은 브랜치 이름과 경로를 오가는 이동과 정리 절차다.
git worktree와 Worktrunk는 무엇이 다른가
작업 폴더 분리는 기본 Git이 이미 한다. Git 공식 git-worktree 매뉴얼(2026-11-09 확인)은 git worktree add로 연결된 작업 디렉터리를 만들고 list, remove, prune으로 관리한다고 설명한다. 두 도구 모두 모델의 파일 접근이나 네트워크를 막는 보안 샌드박스는 아니다.
차이는 이동 단위다. Worktrunk v0.81.0 릴리스 참조 문서(2026-11-09 확인)에 따르면 wt switch는 브랜치에 대응하는 작업 폴더를 찾거나 만든다. 같은 폴더에서 브랜치만 바꾸는 git switch와 다르다.
에이전트마다 브랜치별 폴더를 나눠 주며 경로를 직접 따라가는 일이 번거롭다면 검토할 만하다.
같은 작업에서 명령 수는 얼마나 달랐나
부모 커밋을 main, 릴리스 태그 v0.81.0을 feature로 두고 양쪽에서 생성, 목록, 이동, 병합, 정리를 직접 실행해 봤다. Worktrunk는 일회성 자식 Bash에서 셸 래퍼를 켠 뒤 아래 6명령을 썼다.
wt switch --create feature --base v0.81.0 --no-hooks
wt list
wt switch main --no-hooks
wt switch feature --no-hooks
wt merge main --no-commit --no-rebase --no-remove --no-hooks
wt remove feature --foreground --no-hooks모두 종료코드 0이었다. wt list는 브랜치 상태와 main 대비 1커밋 앞섬(↑1), 변경 줄 수(+88 -2), 경로를 한 표로 보여 줬다.
Branch Status HEAD± main↕ main…± Remote⇅ Path Commit Age Message
@ feature ↑ ↑1 +88 -2 ../wt-clean.feature e42f0f6 2w Release v0.81.0 (#4534)
^ main ^ . a4a3063 2w test(remove): retry the drain when a forked child still holds the trash lock (#4530)기본 Git은 폴더 이동과 브랜치 삭제를 따로 불러야 해서 9명령이었다. 역시 모두 종료코드 0이었다.
git worktree add -b feature ../plain-clean.feature v0.81.0
cd ../plain-clean.feature
git worktree list
cd ../plain-clean
cd ../plain-clean.feature
cd ../plain-clean
git merge --ff-only feature
git worktree remove ../plain-clean.feature
git branch -d feature기본 git worktree list도 두 폴더의 경로와 커밋, 브랜치를 함께 표시했다. 최종 상태는 양쪽이 같았다.
| 비교 항목 | 기본 Git | Worktrunk v0.81.0 |
|---|---|---|
| 생성과 이동 | git worktree add 뒤 별도 cd | wt switch --create 뒤 셸 래퍼가 이동 |
| 목록 표시 | 경로, 커밋, 브랜치 | 미커밋 변경, main 대비 앞섬·뒤처짐, 줄 증감 추가 |
| 병합과 정리 | git merge, worktree remove, branch -d 각각 | wt merge, wt remove로 폴더·브랜치까지 정리 |
| 이번 명령 수 | 9 (cd 4회 포함) | 6 (--no-remove로 병합·제거 분리) |
| 미커밋 폴더 삭제 | 종료코드 128로 거부, 파일 보존 | 종료코드 1로 거부, 파일 보존 |
이 숫자는 cd를 포함해 셸에서 부른 명령 수다. 기본 Git도 git -C나 셸 함수로 줄일 수 있으니 일반적인 감소율로 읽으면 안 된다.
미커밋 변경이 남은 dirty 폴더 삭제는 양쪽 모두 거부했다. wt remove dirty --foreground --no-hooks는 종료코드 1, git worktree remove ../plain-clean.dirty는 종료코드 128로 멈췄다.
수정한 README.md와 새 파일 UNTRACKED_PROBE.txt는 양쪽 모두 남았다. Worktrunk는 커밋이나 git stash -u를 먼저 하라고 안내했다.
Worktrunk 경로는 생성·이동, 상태 확인, 병합, 정리를 브랜치 이름으로 묶는다. 자동 이동에는 셸 래퍼가 필요하고, 미커밋 상태에서는 양쪽 모두 정리 단계에서 멈춘다.
왜 플래그와 셸 설정을 따로 챙겨야 하나
자동 이동은 셸 설정에 달려 있고, 기본 동작은 단순 이동보다 많은 일을 하기 때문이다.
첫째, 자동 이동은 셸 래퍼가 맡는다. 참조 문서의 Shell integration 항목에 따르면 자식 바이너리는 부모 셸의 현재 폴더를 바꿀 수 없어서 셸 함수가 대신 cd한다. 바이너리를 절대경로로 부르거나 --no-cd를 주면 이동하지 않는다.
둘째, 참조 문서의 wt merge 항목에 따르면 기본 동작은 untracked·unstaged 변경까지 커밋·squash하고 rebase, 로컬 fast-forward, 폴더·브랜치 정리까지 묶는다. 기존 커밋을 그대로 합치려면 --no-commit --no-rebase를 함께 줘야 한다. 이번에는 정리를 따로 보려고 --no-remove도 붙였다.
셋째, wt hook 항목은 pre-start, pre-merge, post-remove 등 10종의 생애주기 훅을 설명한다. 프로젝트 명령은 처음 실행할 때 승인을 묻지만, 첫 시험에서는 --no-hooks와 빈 설정 파일로 아예 막는 편이 낫다고 본다.
기존 환경을 건드리지 않고 시험하는 절차
전역 설치 스크립트를 돌리거나 셸 프로필을 고치지 않고 격리 환경에서 실행하면 된다.
- 릴리스 자산
worktrunk-aarch64-apple-darwin.tar.xz를<폴더>/vendor에 받아, SHA-256이 릴리스 API digest와 같은지 확인하고 압축만 푼다.wt --version이wt v0.81.0인지 본다. 같은 릴리스의LICENSE와Cargo.toml은MIT OR Apache-2.0중 선택하는 이중 라이선스로 적혀 있다. - 자식 프로세스의
HOME,XDG_CONFIG_HOME,TMPDIR를<폴더>아래로 두고GIT_CONFIG_GLOBAL=/dev/null,GIT_CONFIG_NOSYSTEM=1을 준다.WORKTRUNK_CONFIG_PATH등 세 설정 경로 변수는 빈 TOML 파일을 가리키게 한다. git init으로 폐기용 저장소를 만들고core.hooksPath를/dev/null로 지정한 뒤,fetch --depth 2로 비교할 태그만 가져오고,git switch -c main <부모 커밋>으로 시작 브랜치를 만든다.bash --noprofile --norc자식 셸에서만eval "$(wt config shell init bash)"를 실행하고--no-hooks,--no-commit --no-rebase를 붙여 호출한다.
확인하지 않은 것과 준비 중 실패
이번 비교로 병렬 에이전트의 생산성이나 품질을 말할 수는 없다. 모델 CLI는 한 번도 호출하지 않았고 충돌 감소나 시간·비용도 재지 않았다.
기본 wt merge의 자동 커밋·rebase, 훅 실행, wt list --full의 원격 CI 조회도 시험하지 않았다. Windows·Linux·다른 셸과 서명 검증도 범위 밖이다.
준비 중 실패도 있었다. 얕은 저장소를 --depth 없이 로컬 fetch하자 shallow 경계가 빠졌고, wt list는 5개 작업 실패 경고를 내고도 종료코드 0을 반환했다. wt merge는 종료코드 1로 멈췄다.
같은 저장소에서 git merge-base --is-ancestor main feature도 종료코드 128을 냈으니 이력 준비 문제로 본다. 다만 wt list를 자동화에 쓴다면 종료코드와 함께 경고 문구도 읽어야 한다.
폴더를 나누는 일과 에이전트 결과를 검증·통합하는 일은 별개다. 통합 병목은 코드는 빨랐는데 — jira-agent 다섯 에이전트 4일 회고 (구축기 3편)에서 다뤘다. 모델을 지휘하는 오케스트레이션 제품은 오케스트레이션이 제품이 됐다 — Sakana Fugu가 말하는 것과 안 말하는 것에서 따로 정리했다.
결론
Worktrunk는 git worktree의 생성·이동·상태 확인·병합·정리를 브랜치 이름 중심으로 묶는 관리 도구이고, 새 격리 기술은 아니다. 이번 로컬 절차에서는 9명령이 6명령이 됐지만, 한 번의 비교에서 나온 값이다. 결국 도입 기준은 통합 상태 표와 자동 이동, 생애주기 훅이 내 작업 방식에 필요한가다. 시험해 보려면 셸 프로필을 고치기 전에 격리 환경변수와 --no-hooks, --no-commit --no-rebase를 건 자식 셸에서 폐기용 저장소로 먼저 돌려 보자.
댓글
댓글 쓰기