Git을 대체할 차세대 버전관리 Jujutsu, '메가머지'로 거대 리팩토링을 다루는 법

Jujutsu가 뭔가요

혹시 Jujutsu(jj) 라는 버전관리 도구 들어보셨나요? 구글 엔지니어 마틴 본 즈웨이게베르겐(Martin von Zweigbergk)이 시작한 프로젝트인데요, 한마디로 "Git을 대체하려는 차세대 VCS"예요. 재밌는 건 Git 저장소 위에서도 동작한다는 점이에요. 그러니까 팀 전체가 Git을 쓰고 있어도 나 혼자 jj를 써서 작업하고 푸시하면 동료들은 그냥 Git 커밋으로 받아볼 수 있어요. 점진적 도입이 가능한 거죠.

Jujutsu가 Git과 가장 다른 점은 "working copy(작업 디렉토리)도 그냥 하나의 커밋" 으로 다룬다는 거예요. Git에서는 "untracked files, staged, committed" 이렇게 단계가 나뉘어 있어서 늘 git add git commit 이중 작업을 해야 하잖아요. jj에서는 파일을 수정하면 그게 곧 현재 커밋의 변경사항이고, jj new를 하면 새 빈 커밋이 만들어지면서 자동으로 기록이 시작돼요. "인덱스라는 개념이 없다" 가 핵심입니다.

메가머지가 뭐길래

이번에 화제가 된 글은 "메가머지(megamerge)"라는 jj의 독특한 워크플로우를 다룹니다. 메가머지가 뭐냐면, 여러 개의 독립적인 브랜치를 한꺼번에 하나의 작업 환경으로 합쳐서 동시에 작업하는 기법 이에요.

예를 들어볼게요. 여러분이 큰 리팩토링 중인데, 동시에 진행 중인 작업이 세 개 있다고 해봐요. 첫째는 인증 모듈 리팩토링, 둘째는 결제 모듈 신규 기능, 셋째는 로깅 시스템 교체. Git이라면 각 브랜치를 왔다갔다하면서 작업하거나, 일단 다 머지해서 작업하다가 나중에 분리하느라 골머리를 앓겠죠.

jj의 메가머지는 이 세 브랜치를 n-way merge 로 하나의 작업 커밋 아래에 합쳐놓고, 마치 모든 변경사항이 동시에 적용된 상태로 작업할 수 있게 해줍니다. 그리고 새 변경사항을 만들 때마다 "이건 인증 브랜치에 속하는 변경이야"라고 지정해서 자동으로 해당 브랜치 위에 쌓이게 할 수 있어요. 통합 테스트는 통합된 상태로 돌리되, PR은 깔끔하게 분리된 상태로 올릴 수 있는 거죠.

어떻게 동작하나요

핵심은 jj의 first-class conflict(일급 충돌) 개념이에요. Git에서는 충돌이 나면 "멈춰. 해결하고 다시 와" 하지만, jj에서는 충돌 자체를 커밋의 한 상태로 저장해두고 작업을 계속할 수 있어요. 충돌이 있는 채로도 다른 브랜치 작업을 하다가 나중에 한가할 때 풀 수 있는 거죠.

또 하나의 강력한 기능은 jj rebase -d와 revset 문법 이에요. revset이 뭐냐면, "특정 조건을 만족하는 커밋들의 집합"을 표현하는 미니 쿼리 언어예요. 예를 들어 jj rebase -s 'description("feat:auth")' -d main 이런 식으로 "설명에 feat:auth가 들어간 모든 커밋을 main 위로 옮겨라" 같은 명령을 한 줄로 쓸 수 있어요. 이게 메가머지를 다시 풀어서 각 브랜치로 보내는 작업을 굉장히 쉽게 만들어주죠.

글쓴이는 이 워크플로우로 "원래는 일주일 걸렸을 멀티 브랜치 작업을 이틀로 줄였다"고 합니다. 핵심은 컨텍스트 스위칭 비용을 거의 없애는 것 이에요. 브랜치 갈아탈 때마다 빌드 다시 돌리고, IDE 인덱스 다시 만들고 하는 그 짜증나는 시간을 안 써도 되는 거죠.

다른 차세대 VCS와 비교하면

Git 대안 진영에는 몇 가지 후보가 있어요. Pijul 은 패치 이론을 기반으로 한 수학적으로 우아한 VCS인데, 학습 곡선이 가파르고 생태계가 작아요. Sapling 은 메타(Facebook)가 만든 건데 모노레포에 특화돼 있고요. Fossil 은 SQLite 만든 사람이 만든 통합형 VCS인데 이슈트래커까지 다 들어있는 올인원이에요.

jj가 이 중에서 두각을 나타내는 이유는 Git 호환성 때문이에요. 다른 VCS들은 "Git을 버려야" 쓸 수 있는데, jj는 Git 저장소 그대로 쓰면서 클라이언트만 바꾸면 돼요. 구글 내부에서 실제로 대규모로 쓰고 있다는 점도 신뢰감을 주고요. 미터미코드(Mercurial)의 좋은 부분과 Git의 분산성을 합친 디자인이라는 평가가 많아요.

한국 개발자에게 어떤 의미일까요

솔직히 말하면, jj는 아직 "오늘 당장 회사에서 쓰자" 단계는 아니에요. 1.0이 안 나왔고, GUI 도구도 부족하고, 동료들에게 트러블슈팅 도와달라고 하기도 어렵죠. 하지만 개인 사이드 프로젝트나 내 로컬에서 실험적으로 도입 해보기엔 정말 좋은 시점이에요. 앞서 말했듯 GitHub에 푸시하는 건 그대로 되니까 동료들 모르게 혼자 쓸 수 있거든요.

특히 추천드리고 싶은 케이스는, 평소에 여러 PR을 동시에 진행하는 분들 이에요. 스택드 PR(stacked PR)을 다뤄보신 분들은 Git의 한계를 절감하셨을 텐데, jj는 그 부분에서 비교가 안 되게 편해요. Graphite 같은 유료 도구를 쓰는 이유의 절반 정도는 jj가 무료로 해결해줍니다.

또 하나, "인덱스가 없다"는 패러다임 자체가 신선한 학습 경험이 돼요. 우리가 당연하게 여기던 git add git commit -m 흐름이 사실 꼭 필요한 게 아니라는 걸 깨닫게 되거든요. 이런 시각의 전환은 다른 도구를 평가할 때도 도움이 됩니다.

마무리

Git이 등장한 지 20년이 넘었지만, 그동안 "Git을 대체할" 도구가 진지하게 논의된 적은 거의 없었어요. jj는 그 어려운 도전을 "호환성 우선" 전략으로 풀어가고 있다는 점에서 의미가 큽니다. 메가머지 같은 새로운 워크플로우는 Git만 쓰던 우리의 사고방식을 확장시켜줄 거예요.

여러분은 어떠세요? Git의 어떤 부분이 가장 답답하신가요? 그리고 새 VCS를 도입한다면 팀 전체의 합의 없이 혼자 쓰기 시작하시겠어요, 아니면 다 같이 옮길 때까지 기다리시겠어요?