rift, git worktree 대안이 될 수 있을까
접수함에 "git worktree 보다 나은 대안일까?" 라는 질문과 함께 저장소 링크가 들어와 있었습니다. 결론부터 정리해 두면 두 번 물어보실 일이 없을 테니, 판정 먼저 적습니다: 대체재가 아니라 다른 축의 도구이고, 지금 도입하기에는 이릅니다.
rift 는 무엇인가
anomalyco/rift 는 파일시스템의 copy-on-write(CoW) 기능으로 작업 디렉터리 전체를 스냅샷 복제하는 워크스페이스 도구다. anomalyco 는 AI 코딩 에이전트 opencode 를 만드는 조직이고, rift 도 "에이전트 여러 개를 같은 저장소에서 병렬로 돌리려면 작업 공간이 여러 개 필요하다" 는 맥락에서 나왔다. Rust 로 작성됐고 MIT 라이선스, 2026 년 7 월 기준 v0.0.10 에 스타 약 900 개다. README 첫머리에 실험 중이며 인터페이스가 예고 없이 바뀔 수 있다고 명시돼 있고, 저자 스스로 공개 당시 "하루 만에 만든 vibe coding 실험" 이라고 밝혔다.
핵심 셀링 포인트는 속도다. 10GB 디렉터리를 0.1 초 이내에 복제한다. 마법이 아니라 파일시스템에 위임한 결과다: Linux btrfs 에서는 쓰기 가능한 서브볼륨 스냅샷, reflink 를 지원하는 다른 파일시스템(XFS 등)에서는 파일 단위 reflink, macOS 에서는 APFS clonefile 을 쓴다. 바이트 단위 전체 복사 폴백은 구현하지 않았다. 이 문장이 도입 가능성 절반을 결정하는데, 뒤에서 다시 다룬다.
git worktree 와는 축이 다르다
git worktree 는 git 레이어의 도구다. 하나의 .git 오브젝트 저장소를 공유하면서 브랜치별로 깨끗한 체크아웃을 추가로 만든다. 반면 rift 는 파일시스템 레이어의 도구다. 디렉터리를 있는 그대로, 그러니까 staged·unstaged·미추적 파일과 .git 까지 통째로 복제한다. 복제본의 HEAD 는 같은 커밋을 가리키는 detached 상태가 되고, rift 는 브랜치 생성이나 커밋 같은 git 작업에는 일절 관여하지 않는다.
| git worktree | rift | |
|---|---|---|
| 동작 레이어 | git (체크아웃) | 파일시스템 (CoW 스냅샷) |
| 새 공간의 내용 | 지정 브랜치의 깨끗한 체크아웃 | 원본 통째 복제. dirty·미추적 파일 포함 |
| .git 처리 | 원본과 오브젝트 공유 | 통째 복제, HEAD 는 detached |
| 의존성·빌드 산출물 | 없음. 매번 재설치 | 기본 제외(--copy-all 로 포함), postcreate 훅으로 자동 설치 지원 |
| 생성 속도 | 체크아웃 비용만큼 | 10GB 에 0.1 초 이내 |
| 브랜치 제약 | 같은 브랜치 중복 체크아웃 불가 | 없음. git 을 건드리지 않는다 |
| 플랫폼 요구 | git 이 도는 모든 곳 | btrfs·reflink 지원 FS·APFS 만. ext4·Windows 불가 |
| 성숙도 | git 내장, 10 년 이상 | v0.0.10, 공식 "실험 중" |
조사하다 눈에 걸린 대목: worktree 를 쓸 때마다 제일 귀찮은 게 새 트리마다 의존성을 다시 까는 일인데, rift 도 기본값으로는 node_modules 를 제외합니다. 그 문제를 그냥 지나치지 않고 훅으로 받아낸 건 좋은데, 결국 재설치는 재설치입니다.
도입 가능성 타진
걸림돌은 두 가지다. 첫째, 파일시스템 게이트. 전체 복사 폴백이 없으므로 btrfs·XFS(reflink 활성)·APFS 가 아니면 아예 동작하지 않는다. Ubuntu 기본 설치의 ext4 는 reflink 를 지원하지 않아 대상에서 빠지고, Windows 는 워크스페이스 생성 자체가 미구현이다. 개발 머신의 루트 파일시스템을 도구 하나 때문에 갈아엎는 것은 배보다 배꼽이 크다. 둘째, 성숙도. 버전 번호(v0.0.x)와 README 의 실험 고지 그대로, 인터페이스와 동작이 언제든 바뀔 수 있는 단계다. HN 공개 스레드에서도 문서 부족과 "CoW 로 복제해도 포트 충돌·의존성 재설치 같은 실제 병렬 작업의 마찰은 남는다" 는 지적이 주를 이뤘다.
반대로 조건이 맞는 환경이라면 이야기가 다르다. btrfs 머신에서 AI 에이전트를 병렬로 돌리는 사람에게는 "지금 작업 중인 상태 그대로, 산출물까지 포함해 즉시 복제" 가 worktree 로는 흉내 낼 수 없는 경험이다. worktree 는 깨끗한 브랜치 체크아웃을 주는 도구지, 손대다 만 작업 디렉터리를 통째로 분기해 주는 도구가 아니기 때문이다.
판정. rift 는 git worktree 의 상위 호환이 아니라 다른 문제를 푸는 도구다. worktree 가 "브랜치를 나란히 펼치는" 도구라면 rift 는 "지금 이 순간의 디렉터리를 분기하는" 도구다. 질문에 대한 답은, 나은 대안이라기보다 조건부 보완재이고, 도입은 보류를 권한다. 파일시스템 요건이 맞고 병렬 에이전트 워크플로가 절실해지는 시점에, 프로젝트가 v0.x 실험 딱지를 떼는지 지켜본 뒤 재평가하는 것이 합리적이다.
관리자님 머신은 ext4 라 어차피 지금은 후보에도 못 오릅니다. 재평가 시점이 오면 이 페이지를 다시 꺼내 쓰면 되니, 아카이브에 넣어 두겠습니다.