최근 Jujutsu 사용자들 사이에서 '메가머지' 워크플로가 주목받고 있습니다. 핵심은 여러 작업 브랜치를 계속 오가며 맞추는 대신, 하나의 큰 작업용 머지 위에서 얽힌 변경들을 함께 굴리는 방식입니다.1 지금 이 얘기가 중요한 이유는, 팀의 실제 문제는 브랜치 수가 적어서가 아니라 반쯤 끝난 작업들이 서로 같은 파일과 같은 맥락을 공유한다는 데 있는 경우가 많기 때문입니다.
특히 Jujutsu는 Git 위에서 동작하면서도 작업 복사본을 커밋처럼 다루고, 충돌 상태를 그래프에 남기며, 변경을 안정적인 change ID로 추적하는 모델을 갖고 있습니다.23 그래서 메가머지는 "신기한 병합 요령"이 아니라, 얽힌 작업을 잃지 않고 계속 전진시키는 운영 방식으로 읽는 편이 맞습니다.
진짜 질문은 브랜치 개수가 아니라 의존성 혼잡도다
보통은 브랜치를 많이 나누면 일이 깔끔해진다고 생각합니다. 독립적인 기능 개발이라면 맞는 말입니다. 리뷰 단위도 선명하고, 실패 범위도 작습니다.
하지만 현실에는 브랜치를 잘게 나눌수록 오히려 더 복잡해지는 작업이 있습니다. 예를 들면 긴 리팩터링, 서로 의존하는 3~5개의 변경, AI 도구가 동시에 만든 병렬 수정, 그리고 여러 WIP가 같은 파일 묶음을 건드리는 경우입니다. 이런 상황에서 브랜치-per-feature 모델은 "분리된 작업"을 관리하는 데는 좋지만, "서로 얽힌 작업"을 관리하는 데는 자주 약합니다.
메가머지가 유용한 이유는 여기 있습니다. 여러 갈래의 미완성 변경을 한곳에 합쳐 미리 충돌을 드러내고, 함께 테스트하고, 맥락을 유지한 채 진전시킬 수 있습니다.1 즉, 브랜치를 줄이는 게 목적이 아니라 의존성 혼잡을 조기에 표면화하는 게 목적입니다.
반대로 요구사항 경계가 뚜렷하고 파일 충돌도 드문 팀이라면, 굳이 메가머지를 들일 이유가 없습니다. 그 경우엔 평범한 기능 브랜치가 더 단순하고, 단순함은 거의 항상 이깁니다.
Git 사용자들이 예상 못 하는 일상 변화
Jujutsu의 기본 철학은 Git과 꽤 다릅니다. 작업 복사본 자체가 현재 커밋이고, 충돌도 "막힌 상태"가 아니라 저장 가능한 상태입니다.24 이 차이가 메가머지에서 크게 드러납니다.
Git식 감각으로는 충돌이 생기면 멈춰서 해결해야 합니다. 하지만 Jujutsu에선 충돌이 작업 그래프 안에 남기 때문에, 미해결 충돌을 포함한 통합 상태를 더 일찍 볼 수 있습니다.24 이것은 단순한 편의성 문제가 아닙니다. 어떤 변경들이 실제로 함께 살아남을 수 있는지, 어디서 설계가 어긋나는지 더 빨리 알게 해줍니다.
또 하나는 브랜치 점프가 줄어든다는 점입니다. 메가머지에서는 여러 작업을 오가더라도 "현재 통합된 작업면"이 하나라서, 계속 체크아웃과 재리베이스를 반복하는 감각이 덜합니다. 대신 대가도 있습니다. 작업의 정신적 모델이 브랜치 중심에서 변경 그래프 중심으로 바뀌어야 합니다. Git에 익숙한 팀원에겐 이게 생산성 향상일 수도 있고, 불필요한 이질감일 수도 있습니다.
그래서 판단 기준은 간단합니다. "브랜치를 나누면 마음이 편한가?"가 아니라 "얽힌 작업을 함께 보는 시간이 실제로 줄어드는가?"입니다.
가장 안전한 시험 도입법: 공개 브랜치는 그대로, 개인 통합 공간만 바꾸기
메가머지를 팀 규칙으로 바로 밀어붙일 필요는 없습니다. 오히려 그러면 실패 확률이 큽니다. Jujutsu는 Git 저장소와 공존할 수 있어 개인 단위 실험이 가능하다는 점이 강점입니다.24
가장 현실적인 방식은 이렇습니다. 하나의 지저분한 작업을 고르세요. 예를 들어 리팩터링 1개, API 수정 1개, 테스트 보강 1개, 후속 버그 수정 1개처럼 3~5개의 상호 의존 변경이 있는 묶음입니다. 그리고 리뷰용 브랜치와 PR은 기존 Git 습관대로 유지하세요. 메가머지는 내 로컬의 사설 통합 작업공간으로만 씁니다.
이렇게 하면 얻는 게 분명해집니다. 충돌이 일찍 보이는지, 함께 테스트하기 쉬운지, 리뷰로 내보낼 때는 다시 잘게 정리할 수 있는지 확인할 수 있습니다. 반대로 로컬에서는 편한데 리뷰 단위가 계속 흐려진다면, 그건 워크플로가 아니라 작업 쪼개기 자체가 실패한 신호입니다.
메가머지는 강력하지만, 제품 결정의 빈자리를 가려주진 못한다
여기서 가장 중요한 반론이 있습니다. 메가머지는 복잡한 코드를 다루는 도구이지, 흐린 요구사항을 정당화하는 도구가 아닙니다.
경계가 불분명한 작업을 억지로 한데 묶으면 메가머지는 "모든 게 연결돼 있다"는 착시를 만들어줍니다. 사실은 스코프가 부풀었거나, 리뷰 discipline이 약하거나, 제품 결정이 늦어진 것일 수 있습니다. 이때 메가머지는 문제를 해결하는 대신 늦게 드러나게 만듭니다.
그래서 좋은 사용법은 분명합니다. 코드 현실이 얽혀 있어서 임시 통합면이 필요한 경우에만 쓴다. 그러나 외부 리뷰와 배포 단위까지 한 덩어리로 만들진 않는다. Jujutsu의 undo 가능한 작업 로그와 충돌 보존 모델은 이런 실험을 안전하게 해주지만,24 그 안전망이 좋은 설계 판단까지 대신해주지는 않습니다.
지금 이 워크플로를 신경 써야 할 사람은 분명합니다. 긴 리팩터링, 의존 PR 체인, AI가 늘린 병렬 수정 때문에 "브랜치는 많은데 일은 안 풀리는" 팀입니다. 반대로 작업 경계가 선명한 팀이라면, 메가머지는 혁신이 아니라 자초한 복잡성일 가능성이 더 큽니다. 판단 기준은 멋져 보이느냐가 아니라, 충돌과 맥락 손실을 더 빨리, 더 싸게 드러내느냐입니다.
참고
1Jujutsu megamerges for fun and profit
2Why a Former Mercurial Maintainer Built a Git Replacement That Feels Simpler
4How jj Fixes the Git Workflow That's Been Wasting Your Time
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.