Hacker News 2026.04.12 37

Git의 대안? 수학 이론 기반 버전 관리 시스템 Pijul을 파헤쳐 보자

Git이 전부는 아니에요

개발자라면 거의 매일 Git을 쓰고 있을 거예요. 브랜치 만들고, 커밋하고, 머지하고… 너무 익숙해서 "버전 관리 = Git"이라고 생각하기 쉬운데요. 사실 Git도 완벽하지는 않거든요. 머지 충돌이 복잡하게 꼬이거나, 리베이스하다가 히스토리가 엉망이 된 경험, 다들 한 번쯤은 있잖아요. 이런 문제를 근본적으로 해결하겠다고 나온 오픈소스 분산 버전 관리 시스템이 있어요. 바로 Pijul(피줄)이에요.

Pijul은 Rust로 작성된 오픈소스 프로젝트인데요, 가장 큰 특징은 패치 이론(patch theory)이라는 수학적 기반 위에 설계되었다는 거예요. 그냥 "Git이랑 비슷한데 좀 다른 거" 수준이 아니라, 버전 관리의 핵심 개념 자체를 다르게 접근한 프로젝트라서 한번 살펴볼 가치가 충분해요.

패치 이론이 뭔데?

이게 뭐냐면, Git은 기본적으로 스냅샷(snapshot) 기반이에요. 커밋할 때마다 파일 전체 상태를 찍어두는 식이죠. 그래서 두 브랜치를 합칠 때 "이 스냅샷과 저 스냅샷의 차이를 어떻게 합칠까?"를 계산해야 하는데, 이 과정에서 충돌이 복잡해지는 거예요.

Pijul은 다르게 생각해요. 모든 변경사항을 패치(patch)라는 단위로 다루는데, 이 패치들이 수학적으로 교환 법칙(commutative)을 만족하도록 설계되어 있어요. 교환 법칙이라고 하면 어려울 수 있는데, 쉽게 말하면 "패치 A를 먼저 적용하고 패치 B를 적용한 결과"와 "패치 B를 먼저 적용하고 패치 A를 적용한 결과"가 항상 같다는 뜻이에요. 마치 1+2나 2+1이나 결과가 3인 것처럼요.

이게 실무에서 어떤 의미가 있냐면, 패치의 적용 순서에 상관없이 결과가 동일하기 때문에 Git에서 흔히 겪는 리베이스 문제가 원천적으로 사라져요. Git에서는 같은 변경사항을 리베이스하면 이미 해결한 충돌이 다시 나타나는 경우가 있잖아요. Pijul에서는 그런 일이 구조적으로 발생하지 않아요.

Git과 구체적으로 뭐가 다른가

실제 사용 관점에서 차이를 좀 더 풀어볼게요. Git에서 브랜치 두 개를 머지할 때, 공통 조상을 찾고 three-way merge를 수행하잖아요. 이 과정에서 충돌이 나면 수동으로 해결해야 하고, 한번 해결한 충돌이 cherry-pick이나 rebase 과정에서 다시 나타나기도 하죠.

Pijul에서는 각 패치가 자신의 의존성(dependency)을 명시적으로 추적해요. 패치 B가 패치 A의 결과물 위에서만 의미가 있다면, B는 A에 의존한다고 선언되는 거죠. 이런 의존 관계가 DAG(방향 비순환 그래프) 형태로 관리되는데, 충돌이 발생하면 이 충돌 자체도 하나의 명시적인 상태로 기록돼요. Git처럼 충돌을 "해결해서 없애는" 게 아니라, 충돌이 있는 상태와 충돌을 해결하는 패치가 별도로 존재하는 구조예요.

또 하나 재미있는 점은, Pijul에는 리베이스 개념 자체가 없어요. Git에서 리베이스는 사실상 "커밋을 새로 만들어서 히스토리를 다시 쓰는" 작업인데, Pijul은 패치의 교환 법칙 덕분에 굳이 히스토리를 다시 쓸 필요가 없거든요. 원하는 패치를 원하는 순서로 적용해도 결과가 같으니까요.

내부 저장소 구조도 흥미로운데, Pijul은 Sanakirja라는 자체 개발한 키-밸류 저장소를 사용해요. 이건 copy-on-write B-트리 기반인데, 트랜잭션을 지원하고 메모리 맵(mmap) 기반으로 동작해서 성능도 꽤 괜찮다고 해요.

비슷한 시도들과 비교

사실 Git의 대안을 만들려는 시도는 Pijul이 처음은 아니에요. 가장 대표적인 게 Darcs라는 Haskell로 만든 버전 관리 시스템인데, Darcs도 패치 이론을 사용해요. Pijul은 Darcs에서 영감을 받되, Darcs가 가진 성능 문제(exponential merge 문제라고 불리는, 특정 상황에서 머지가 기하급수적으로 느려지는 문제)를 해결하려고 만들어진 측면이 있어요.

최근에는 Google에서 만든 Jujutsu(jj)도 주목받고 있어요. Jujutsu는 Git과 호환되면서도 더 나은 머지 경험을 제공하려는 프로젝트인데, Git 저장소를 그대로 쓸 수 있다는 점에서 마이그레이션 부담이 훨씬 적어요. 반면 Pijul은 완전히 독자적인 저장소 형식을 쓰기 때문에 기존 Git 생태계와의 호환성은 아쉬운 부분이에요.

Mercurial(hg)도 여전히 존재하고 Meta(구 Facebook)에서는 Sapling이라는 자체 버전 관리 도구를 만들어 쓰기도 하죠. 이런 흐름을 보면, "Git이 최선인가?"라는 질문은 업계에서 꾸준히 제기되고 있고, 각자 다른 방식으로 답을 찾고 있는 셈이에요.

한국 개발자에게는 어떤 의미가 있을까

솔직히 말하면, 당장 실무에서 Git을 Pijul로 교체하는 건 현실적이지 않아요. GitHub, GitLab 같은 플랫폼 생태계가 전부 Git 기반이고, 팀원 모두가 새로운 도구를 배워야 하니까요. Pijul의 호스팅 플랫폼인 The Nest도 있긴 하지만, GitHub의 생태계와 비교하기는 어렵죠.

하지만 Pijul을 공부해볼 가치는 분명 있어요. 우선, 패치 이론이라는 개념 자체가 CS 이론적으로 매력적이에요. 카테고리 이론이 실제 소프트웨어 도구에 적용된 사례를 직접 체험해볼 수 있거든요. 그리고 Git의 내부 동작을 더 깊이 이해하는 데도 도움이 돼요. "Git이 왜 이렇게 동작하는지"를 다른 접근법과 비교하면서 배우면 이해가 훨씬 선명해지거든요.

개인 프로젝트나 사이드 프로젝트에서 한번 써보는 것도 추천해요. pijul init, pijul record, pijul push 같은 명령어로 Git과 비슷한 워크플로우를 체험할 수 있고, 충돌 처리 방식의 차이를 직접 느껴보면 상당히 인상적이에요.