Mercurial는 어떻게 20년을 살아남았을까? Git 천하에서 버티는 또 하나의 버전 관리 시스템 이야기

Git만 있는 줄 알았다면 잠깐만요

요즘 개발을 시작하면 거의 자동으로 Git을 배우게 되죠. GitHub, GitLab, Bitbucket까지 전부 Git을 중심으로 돌아가니까요. 그런데 사실 Git이 세상에 나온 2005년, 거의 같은 시기에 태어난 또 다른 분산 버전 관리 시스템(DVCS)이 있었어요. 바로 Mercurial(머큐리얼), 줄여서 hg라고 부르는 친구입니다.

이 Mercurial이 2026년 FOSDEM에서 "우리 아직 안 죽었어요(Ain't You Dead Yet?)"라는 다소 도발적인 제목의 발표를 들고 나왔어요. 사실 많은 사람들이 "Mercurial은 끝났다"고 생각하지만, 실제로는 20년 동안 꾸준히 개발되고 있고, 심지어 세계 최대급 코드베이스를 가진 회사들이 여전히 메인으로 쓰고 있다는 거예요. 그래서 이 발표가 나온 김에, 도대체 Mercurial이 어떻게 살아남았고 왜 여전히 가치가 있는지 한번 정리해 봤어요.

Mercurial이 뭐냐면, Git의 동갑내기 사촌

역사 얘기를 잠깐 하자면, 2005년에 Linux 커널 개발팀이 쓰던 BitKeeper라는 상용 버전 관리 도구가 갑자기 무료 사용을 막아버렸어요. 그래서 Linus Torvalds는 직접 Git을 만들기 시작했고, 거의 동시에 Matt Mackall이라는 다른 개발자도 같은 문제를 풀려고 Mercurial을 만들었거든요. 두 도구는 출발점이 같았지만 철학이 좀 달랐어요.

Git이 "빠르고 강력하고, 대신 좀 복잡해도 괜찮다"는 쪽이었다면, Mercurial은 "일관성 있고 깔끔한 명령어, 누구나 직관적으로 쓸 수 있어야 한다"는 쪽이었어요. 예를 들어 Git의 git checkout은 브랜치도 바꾸고 파일도 되돌리고 너무 많은 일을 하잖아요? Mercurial은 그런 걸 hg update, hg revert처럼 각 명령이 한 가지 일만 하도록 설계했어요. 그리고 코드도 대부분 Python으로 짜여 있어서 확장 기능을 만들기가 훨씬 쉬웠죠.

왜 안 죽었나? 거대 코드베이스의 비밀

사람들이 잘 모르는 사실인데, Meta(페이스북)와 Google이 사내 메인 버전 관리 시스템으로 Mercurial 기반을 쓰고 있어요. 정확히는 Meta가 만든 Sapling, Google이 만든 Piper 같은 시스템들인데, 뿌리는 Mercurial에서 출발했죠. 왜 그럴까요?

이유는 모노레포(monorepo) 때문이에요. 모노레포가 뭐냐면, 회사의 모든 코드를 하나의 거대한 저장소에 다 때려넣고 관리하는 방식이에요. Meta 같은 회사는 코드베이스가 수십 GB, 파일 수백만 개 수준인데, Git은 이런 규모에서 성능이 확 떨어져요. Git의 데이터 구조는 "전체 히스토리를 다 가지고 다닌다"는 전제로 설계됐거든요. 반면 Mercurial은 구조가 더 유연해서, 부분적으로만 받아오는 "shallow clone"이나 가상 파일시스템 같은 확장이 잘 붙어요. 그래서 거대 코드베이스에는 오히려 Mercurial이 더 적합했던 거예요.

또 하나, Mercurial은 revset과 template이라는 강력한 쿼리 언어를 가지고 있어요. 예를 들어 "지난주에 author가 alice이고 main 브랜치에 머지된 커밋" 같은 걸 한 줄로 표현할 수 있죠. Git에서 비슷한 걸 하려면 git log에 옵션을 줄줄이 붙여야 하는데, Mercurial은 SQL처럼 깔끔하게 짤 수 있어요.

그럼 왜 우리는 다 Git을 쓰고 있을까

결국 승부를 가른 건 GitHub였어요. 2008년에 등장한 GitHub가 오픈소스 생태계를 완전히 빨아들이면서, Git을 모르면 협업이 안 되는 세상이 됐죠. Bitbucket이 한때 Mercurial을 지원하긴 했는데, 2020년에 결국 Mercurial 지원을 끊어버렸어요. 호스팅 플랫폼이 사라지면 사실상 사망 선고나 마찬가지인데, 그 와중에도 Heptapod 같은 GitLab 포크 프로젝트가 Mercurial 호스팅을 이어가고 있고, Mercurial 자체는 계속 릴리스되고 있어요.

경쟁 도구로 보면 요즘 떠오르는 게 Jujutsu(jj), Pijul, Fossil 같은 차세대 DVCS들인데, 이들 중 상당수가 Mercurial의 설계 철학에서 영감을 받았어요. 특히 Jujutsu는 Google에서 만든 건데, "Git과 호환되면서도 Mercurial처럼 깔끔한 UX"를 목표로 하고 있죠. 즉, Mercurial은 사용자 수로는 졌지만 아이디어로는 살아남아서 다음 세대에 영향을 주고 있다는 얘기예요.

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

솔직히 "내일부터 Mercurial 쓰세요"라고 권하긴 어려워요. 한국 회사 99%는 GitHub나 GitLab을 쓰고, 신입 면접에서도 Git을 묻지 Mercurial을 묻진 않으니까요. 하지만 두 가지는 챙겨볼 만해요.

첫째, 버전 관리 시스템을 한 가지만 알고 있으면 시야가 좁아져요. Git이 왜 그렇게 설계됐는지, 다른 선택지는 어떤 트레이드오프를 가지는지 알면 Git을 훨씬 깊게 이해할 수 있어요. "커밋 그래프란 뭔가", "히스토리를 다시 쓴다는 게 무슨 뜻인가" 같은 본질적인 개념이 더 잘 보이거든요. 둘째, 회사가 커지면서 모노레포를 고민하게 되는 순간이 와요. 그때 Sapling이나 Jujutsu 같은 대안을 검토할 텐데, 그 뿌리가 Mercurial이라는 걸 알면 의사결정이 훨씬 빨라져요.

마무리

Mercurial 이야기는 결국 "기술이 더 좋다고 꼭 이기는 건 아니다"라는 오래된 교훈이에요. 동시에 "이긴 줄 알았던 기술도 끝까지 살아남은 대안의 영향을 계속 받는다"는 얘기이기도 하고요. 여러분이 매일 쓰는 Git 명령어 뒤에는 사실 이런 평행 우주의 역사가 깔려 있어요.

질문을 하나 던져볼게요. 만약 GitHub가 2008년에 Git이 아니라 Mercurial을 골랐다면, 지금 우리의 개발 문화는 어떻게 달라져 있을까요? 댓글로 상상해 보면 재미있을 것 같아요.