BitTorrent 창시자 Bram Cohen이 말하는 "우리가 버전 관리를 잘못 하고 있는 이유"

Git의 아버지가 아닌, 또 다른 전설이 버전 관리를 이야기한다

Bram Cohen이라는 이름, 혹시 들어보셨나요? BitTorrent를 만든 사람이에요. P2P 파일 공유의 판도를 완전히 바꾼 그 프로토콜이요. 그런데 이 사람이 버전 관리 시스템에 대해서도 아주 오랫동안 깊이 고민해왔거든요. 이번에 그가 블로그에 올린 글은 현재 버전 관리 시스템들, 특히 Git이 가진 근본적인 한계와 더 나은 접근 방식에 대한 이야기예요.

Git의 머지, 사실 좀 이상하지 않았나요?

Git을 쓰다 보면 머지(merge) 충돌을 해결하는 게 가장 고통스러운 순간 중 하나잖아요. Bram Cohen의 핵심 지적 중 하나가 바로 이 머지 알고리즘의 문제예요. Git의 3-way 머지는 두 브랜치와 그 공통 조상을 비교해서 변경 사항을 합치는 방식인데요, 이게 생각보다 많은 케이스에서 "잘못된" 결과를 내놓는다는 거예요.

이게 뭐냐면, 쉽게 비유하자면 이래요. 두 사람이 같은 문서를 각자 수정했다고 해볼게요. A는 2번째 문단을 고쳤고, B는 3번째 문단을 고쳤어요. 이건 쉬워요, 둘 다 합치면 돼요. 그런데 A가 2번째 문단을 삭제하고 B가 2번째 문단 바로 옆에 새 내용을 추가했다면? Git은 이런 상황에서 때때로 엉뚱한 결과를 만들거나, 충돌이 아닌데 충돌이라고 하거나, 반대로 충돌인데 조용히 잘못된 결과를 내놓기도 해요.

Bram Cohen은 이런 문제를 해결하기 위해 "의미적 머지(semantic merge)" 수준까지는 아니더라도, 최소한 텍스트 기반 머지를 더 정확하게 만드는 알고리즘이 필요하다고 이야기해요. 단순히 줄 단위로 비교하는 게 아니라, 변경의 "의도"를 더 잘 추적해야 한다는 거죠.

스냅샷 vs 패치: 역사를 어떻게 저장할 것인가

Git은 내부적으로 스냅샷(snapshot) 기반이에요. 각 커밋이 프로젝트 전체의 "사진"을 찍는 거죠. 반면 Darcs 같은 시스템은 패치(patch) 기반이에요. "어디를 어떻게 바꿨다"는 변경 기록 자체를 관리하는 방식이에요.

Bram Cohen은 두 접근 방식의 장단점을 꽤 깊이 분석하는데요. 스냅샷 방식은 "지금 상태"를 빠르게 복원하는 데 유리하지만, 변경의 맥락을 잃어버리기 쉬워요. 반대로 패치 방식은 변경의 이력을 풍부하게 보존하지만, 특정 시점의 상태를 재구성하는 게 복잡해질 수 있죠.

흥미로운 건, 그가 제안하는 방향은 두 가지를 결합하는 하이브리드 접근이에요. 변경 사항을 패치처럼 의미 있는 단위로 추적하면서도, 스냅샷의 성능 이점을 가져가는 방식이죠. 이건 사실 최근에 나온 Jujutsu(jj) 같은 차세대 VCS가 시도하고 있는 방향과도 맞닿아 있어요.

파일 이동과 리네임: 아직도 해결 못 한 문제

Git을 쓰면서 파일 이름을 바꾸거나 디렉토리를 옮길 때 히스토리가 끊기는 경험을 해보셨을 거예요. git log --follow로 어느 정도 추적할 수 있지만, 완벽하지 않거든요. 이건 Git이 파일 이동을 명시적으로 추적하지 않고, "이전 파일 삭제 + 새 파일 생성"으로 처리한 뒤 나중에 유사도를 비교해서 "아마 같은 파일일 것"이라고 추측하는 방식이기 때문이에요.

Bram Cohen은 이걸 근본적으로 고쳐야 한다고 주장해요. 파일의 정체성(identity)을 버전 관리 시스템이 명시적으로 추적해야, 리네임이나 이동 후에도 히스토리가 자연스럽게 이어진다는 거예요. 이건 실무에서 대규모 리팩토링을 할 때 정말 절실하게 느끼는 부분이에요. 패키지 구조를 바꾸면 히스토리가 통째로 날아가는 건 누구나 한번쯤 겪어본 고통이잖아요.

업계 맥락: Git 이후의 세계

Git은 2005년에 탄생한 이후 사실상 버전 관리의 표준이 됐어요. 하지만 20년이 넘은 도구인 만큼 한계도 명확하고, 이를 개선하려는 시도가 꾸준히 이어지고 있어요. Google의 Jujutsu(jj)는 Git과 호환되면서도 더 나은 머지와 리베이스 경험을 제공하고, Pijul은 패치 이론(patch theory)에 기반한 수학적으로 정확한 머지를 지향해요. Sapling(Meta)은 대규모 모노레포에 최적화된 접근을 취하고 있고요.

Bram Cohen의 글은 이런 차세대 VCS들이 공통적으로 해결하려는 문제들을 정확하게 짚어내고 있어요. 특히 BitTorrent를 설계하면서 쌓은 분산 시스템에 대한 통찰이 버전 관리 문제를 바라보는 관점에 잘 녹아 있다는 점이 인상적이에요.

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

당장 Git을 버릴 필요는 없어요. Git은 여전히 가장 성숙한 생태계를 가지고 있고, GitHub/GitLab 같은 플랫폼과의 통합도 훌륭하거든요. 하지만 Jujutsu(jj)처럼 Git 저장소와 호환되면서도 더 나은 워크플로우를 제공하는 도구는 한번 사이드 프로젝트에서 실험해볼 만해요. 특히 머지 충돌이 자주 발생하는 팀이라면 Git의 머지 전략 자체를 재검토해보는 것도 좋겠고요.