Git에 지친 개발자들이 Jujutsu(jj)로 갈아타는 이유

Git을 매일 쓰는데도 매번 긴장되는 이유

개발자라면 Git을 모르는 분은 거의 없을 거예요. 그런데 솔직히 말해서, Git을 정말 "편하게" 쓰고 있다고 자신 있게 말할 수 있는 분이 얼마나 될까요? git rebase -i로 커밋을 정리하다가 실수해서 작업 내용을 날려본 경험, git reflog로 겨우 살려낸 적, 머지 충돌이 무서워서 자잘한 커밋을 그냥 그대로 남겨둔 경험… 다들 한 번쯤은 있을 거예요.

이런 피로감을 "Git Rigour Fatigue(깃 엄격성 피로)"라고 부르는 글이 최근 개발자들 사이에서 공감을 얻고 있어요. 깔끔한 커밋 히스토리를 유지하려고 노력하면 할수록 더 피곤해지는 그 느낌, 그래서 결국 "에라 모르겠다, 그냥 squash merge나 하자" 하고 포기하게 되는 그 마음을 정확히 짚어낸 거죠. 그리고 그 대안으로 등장한 도구가 바로 Jujutsu(jj)입니다.

Jujutsu가 뭐냐면

Jujutsu는 Google 엔지니어인 Martin von Zweigbergk가 만든 새로운 버전 관리 시스템이에요. 가장 큰 특징은 Git 저장소와 그대로 호환된다는 점이에요. 즉, 기존 Git 리포지토리 위에 jj를 얹어서 쓸 수 있고, 동료들은 여전히 Git을 쓰고 있어도 나만 jj를 쓸 수 있는 거예요. GitHub, GitLab도 그대로 사용 가능하고요.

그럼 뭐가 다른 걸까요? Git에서는 "작업 디렉토리"와 "스테이징 영역(index)", 그리고 "커밋"이 분리되어 있잖아요. 파일을 수정하고, git add로 스테이징하고, git commit으로 확정하는 3단계요. jj에서는 이 개념이 완전히 사라져요. 모든 변경 사항이 즉시 "working copy commit(작업 커밋)"으로 자동 저장되거든요. 파일을 수정하는 순간, 그게 곧 커밋이 됩니다.

처음 들으면 "엥, 그럼 커밋이 엉망진창 되는 거 아니야?" 싶죠. 그런데 여기서 jj의 진짜 강점이 나와요. 모든 커밋을 자유롭게 수정, 분할, 병합, 재배열할 수 있도록 설계되어 있어요. jj split으로 한 커밋을 여러 개로 쪼개고, jj squash로 합치고, jj rebase로 옮기는 게 너무 자연스러워서 Git의 interactive rebase 때 느끼던 그 긴장감이 없어진다고 해요.

Git과 결정적으로 다른 점

첫째, 충돌(conflict)을 일급 객체로 취급해요. Git에서는 머지 충돌이 나면 일단 해결해야 다음 작업을 할 수 있잖아요. jj는 충돌이 난 상태 그대로 커밋이 저장되고, 나중에 천천히 해결할 수 있어요. 리베이스 도중에 충돌이 났다고 작업이 멈추지 않는다는 거죠. 이게 별 거 아닌 것 같지만 실제로 써보면 정말 큰 차이예요.

둘째, 브랜치 개념이 거의 없어요. 정확히는 Git의 브랜치 대신 "bookmark(북마크)"라는 개념을 쓰는데, 작업할 때마다 브랜치를 만들고 체크아웃하는 그 번거로움이 사라져요. 그냥 새 커밋을 만들면 그게 새로운 작업 흐름이 되거든요. 여러 작업을 동시에 진행하면서 왔다 갔다 하기가 훨씬 편해져요.

셋째, undo가 자연스러워요. jj undo 한 번이면 직전 작업이 깔끔하게 되돌아가요. Git에서 reset --hard나 reflog 뒤져가며 복구하는 그 스트레스가 없어지는 거예요.

비슷한 시도들과 비교해보면

과거에도 Git의 복잡함을 해결하려는 시도는 많았어요. Mercurial(hg)은 더 단순한 명령어 체계로 인기를 끌었지만 Git에 밀려서 지금은 사용자가 많이 줄었고, Pijul은 patch 기반의 새로운 접근으로 주목받았지만 생태계가 작아서 실무 도입은 어려웠죠. Sapling은 Meta(페이스북)에서 만들었는데 자체 서버가 필요해서 개인 개발자가 쓰기엔 부담스러웠어요.

jj가 다른 점은 "Git 생태계를 버리지 않고 UX만 바꾼다"는 접근이에요. 백엔드는 Git 그대로 쓰면서 프론트엔드(명령어 체계와 모델)만 새로 만든 거죠. 그래서 도입 비용이 거의 0에 가깝고, 마음에 안 들면 언제든 다시 git 명령어로 돌아갈 수 있어요. Google 내부에서도 일부 팀이 실제로 사용하고 있다고 알려져 있고요.

한국 개발자에게 주는 시사점

당장 회사 전체에 jj를 도입하자고 제안하긴 어려울 거예요. 하지만 개인 프로젝트나 사이드 프로젝트에서 한번 써보기엔 충분히 가치가 있어요. 특히 자주 커밋을 다시 정리하거나, 여러 기능을 병렬로 개발하는 스타일이라면 생산성 향상을 체감할 수 있을 거예요. brew install jj(macOS)나 cargo install --locked jj-cli로 설치할 수 있고, 기존 Git 리포에서 jj git init --colocate만 실행하면 바로 같이 쓸 수 있어요.

또 하나, jj를 공부하다 보면 Git의 동작 원리를 더 깊이 이해하게 되는 부수효과도 있어요. "내가 그동안 Git의 어떤 부분 때문에 피곤했는지" 명확히 보이거든요. 실무에서 Git을 계속 쓰더라도 그 이해도가 올라간다는 건 무시할 수 없는 이점이에요.

마무리

도구가 사람을 피곤하게 만든다면, 그 도구를 더 잘 쓰려고 노력하기 전에 "다른 도구는 없을까?" 하고 한번 둘러볼 필요가 있어요. jj는 아직 1.0도 안 된 신생 도구지만, 빠르게 성숙해지고 있고 무엇보다 "커밋을 정리하는 작업"의 심리적 부담을 크게 낮춰준다는 점에서 시도해볼 가치가 충분해요.

여러분은 Git의 어떤 부분이 가장 피곤하신가요? rebase의 두려움, 충돌 해결의 스트레스, 아니면 브랜치 관리의 번거로움? 댓글로 공유해주시면 jj가 그 문제를 어떻게 다르게 푸는지 함께 이야기해봐요.