Git 20년, GitHub 스타가 먼저 보내는 신호

'jujutsu'라는 이름의 GitHub 저장소에 별(star)이 쏟아지는 걸 본 적 있으신가요? 저희는 지난 호 '전호 Git 없이 협업한다고? Jujutsu가 온다'에서 Jujutsu의 개념과 협업 시나리오를 다뤘고, 이번 칼럼은 같은 소재를 다시 설명하지 않습니다. 대신 "이 관심이 실제로 얼마나 커졌는가"를 공표된 숫자로만 짚어보는 데이터 중심 칼럼입니다.

왜 지금인가

Git은 2005년 리누스 토르발스가 리눅스 커널 개발을 위해 만든 도구입니다. 2025년 기준으로 거의 20년 가까이 사실상 유일한 표준으로 군림해왔는데, 그 이유는 단순합니다. 대체할 만한 도구가 Git보다 명백히 낫지 않았기 때문입니다. 그런데 최근 Hacker News와 Rust 생태계를 중심으로 "Git의 UX는 끔찍하다"는 말이 자주 나오기 시작했습니다. staging area, HEAD, reflog 같은 개념이 초심자뿐 아니라 숙련자에게도 매번 사고를 유발한다는 지적인데, 이 부분의 구체적 설계 문제는 전호 칼럼에서 이미 다뤘으므로 여기서는 반복하지 않습니다.

핵심은 이 불만이 추상적 논쟁에 머물지 않고, jj 프로젝트의 GitHub 스타 수가 가파르게 늘어나는 구체적인 숫자로 나타나기 시작했다는 점입니다.

이번 칼럼이 궁금한 건 그 관심이 실제로 얼마나 커지고 있는지, 그리고 그 크기를 공개된 숫자로 확인할 수 있는지입니다.

숫자로 보는 현황

먼저 시간축입니다. Git은 2005년 출시되었으니 2025년 현재 약 20년이 지났습니다. 반면 Jujutsu는 Martin von Zweigbergk가 2019년 사이드 프로젝트로 시작해 2022년경 오픈소스로 공개했으니, 올해로 공개 3년차 정도의 비교적 신생 프로젝트입니다.

관심도를 보여주는 숫자는 GitHub 스타 수입니다. jj-vcs/jj 공식 저장소의 스타 수는 2024년 말 약 1만 개에서 2026년 현재 약 3만 개로, 1년여 만에 3배 가까이 늘었습니다(jj-vcs/jj 저장소, star-history.com 집계). 반면 실사용 점유율은 다른 그림을 보여줍니다. Stack Overflow Developer Survey(2022)에 따르면 Git 사용률은 93.87%, SVN은 5.18%, Mercurial은 1.13%였습니다. Jujutsu는 설문 항목에 별도로 등장하지 않아 '기타'에 섞여 있을 가능성이 높습니다.

이 숫자들을 겹쳐 읽으면 그림이 또렷해집니다. 관심(GitHub 스타)은 1년여 만에 3배 가까이 뛰었지만, 실사용 점유율(Stack Overflow 설문)은 Git 93%대로 지난 20년의 균형을 거의 그대로 유지하고 있습니다. 설문 통계는 보통 실사용자층이 어느 정도 두꺼워진 뒤에야 반영되는 지표라서, 커뮤니티 관심이 먼저 움직이고 통계가 뒤따라오는 시차가 존재한다는 뜻으로 읽힙니다.

그림 1. 버전관리 시스템 사용률(SO 2022)

Git의 실사용 점유율은 93.87%로, SVN·Mercurial을 합쳐도 10%가 안 됩니다.

단위: %. 출처: Stack Overflow Developer Survey 2022.

Git 다음을 묻는다는 것의 의미

대체 시스템인가, 보완 레이어인가

여기서 반드시 짚어야 할 지점이 있습니다. Jujutsu는 Git 저장소를 그대로 백엔드로 쓸 수 있게 설계되어 있고, 실제로 많은 사용자가 .git 디렉터리 위에서 jj 명령으로 작업한 뒤 GitHub에 평범한 Git 커밋으로 푸시합니다. 즉 지금 시점의 Jujutsu는 Git을 대체한다기보다 Git 위에서 돌아가는 더 나은 인터페이스 레이어에 가깝습니다. 독자적 백엔드도 개발 중이지만 현실적으로 대다수 사용자는 Git 호환 모드를 쓰고 있고, 이것이 생태계와의 마찰을 최소화한 전략적 선택이라는 점을 이해해야 합니다.

반론: 생태계 성숙도의 간극

GitHub PR 리뷰 흐름, GitLab MR, 사내 CI 파이프라인은 전부 Git의 개념과 명령어를 전제로 구축돼 있습니다. Jujutsu를 팀 전체가 쓰려면 이 전제를 다시 설계해야 하는데, 지금 그 비용을 감당할 만큼 성숙한 생태계는 아직 없습니다. 앞서 짚은 대로 관심은 늘어도 실사용 점유율은 아직 그대로인 만큼, '버전관리의 미래'라는 표현은 가능성에 대한 진단이지 현재 상태에 대한 선언이 아니라는 게 더 분명해집니다.

현장의 변화

Jujutsu 창시자 Martin von Zweigbergk는 Google 소속 엔지니어로, 구글 내부의 거대한 모노레포 환경에서 Git의 한계를 체감하며 이 프로젝트를 시작했습니다. 이 배경은 전호 칼럼에서 자세히 다뤘으니 여기서는 한 문장으로 줄입니다. jj 프로젝트는 GitHub에 self-hosting 방식으로 올라가 있어, Jujutsu 명령어로 생성된 커밋 히스토리가 공개 저장소에 그대로 쌓이는 모습을 누구나 확인할 수 있습니다.

전호에서 다룬 '팀 협업' 시나리오와 달리, 최근 눈에 띄는 패턴은 개인 개발자들이 복잡한 feature 작업의 중간 히스토리를 수시로 재구성하며 "완성된 것처럼 보이는 커밋 로그"를 나중에 만드는 워크플로우입니다. Git의 rebase -i로도 가능한 작업이지만, 충돌을 커밋 안의 데이터로 취급하는 Jujutsu의 설계 덕분에 중간에 작업이 끊기지 않는다는 긍정적인 후기가 일부 개발자 블로그·포럼에 올라오고 있습니다 — 다만 이는 수치화되지 않은 개인 경험 보고이며, 조직 단위 도입 사례로 일반화하기엔 아직 이릅니다.

시사점: 우리가 갖춰야 할 것

• 지금 당장 전환할 필요는 없습니다. Stack Overflow 조사가 보여주듯 Git은 여전히 90%대 중반의 실무 표준이고, 채용 공고와 협업 문서는 전부 Git 기준입니다. Jujutsu는 "알아두면 유리한 것"이지 "몰라서 불이익받는 것"이 아닙니다.
• 개인 사이드 프로젝트에서 가볍게 실험해보세요. .git 저장소 위에서 바로 써볼 수 있어 리스크가 거의 없습니다. 주말 토이 프로젝트 하나를 Jujutsu로 운영해보며 충돌 처리 경험을 비교해보는 것으로 충분합니다.
• Git 멘탈 모델부터 제대로 이해하세요. Jujutsu가 왜 다른 설계를 택했는지 이해하려면 역설적으로 Git의 staging area, HEAD, reflog 개념을 먼저 정확히 알아야 합니다. 비교 없이는 차이도 보이지 않습니다.
• 공표된 설문·통계의 발행 주기를 신호로 활용하세요. Stack Overflow Developer Survey는 매년 발행됩니다. 최근 조사에서도 Git이 90%대 중반을 유지하는지, 기타 VCS 항목에 변화가 생기는지를 1년 단위로 추적하는 습관을 들이면 흐름을 먼저 포착할 수 있습니다.
• 팀에 도입하자는 말은 아직 아껴두세요. GUI·PR 연동·교육 비용이 해소되기 전까지는 개인 학습 영역에 머무는 게 현실적입니다.

맺음말

'버전관리의 미래'라는 표현은 지금은 과장에 가깝지만, 관심이 커지는 속도와 실사용 점유율이 움직이는 속도 사이의 격차도 과장이 아닙니다. Git이 당연했던 20년이 끝나가는 게 아니라, 그 당연함에 처음으로 균열이 보이기 시작한 시점이라고 보는 편이 정확합니다. 지금은 올라타는 시점이 아니라 숫자를 지켜보며 손끝으로 느껴보는 시점이니, 여유 있는 주말 하나를 골라 jj 명령어를 설치해보시길 권합니다.

참고 자료

• Stack Overflow, 「Stack Overflow Developer Survey 2022」(버전관리 시스템 사용 비율 항목)
• jj-vcs/jj 공식 GitHub 저장소 및 README
• star-history.com, jj-vcs/jj 스타 추이 기록
• Martin von Zweigbergk 외, Jujutsu 프로젝트 공개 발표 자료 및 블로그 포스트
• 테크창, 「전호: Git 없이 협업한다고? Jujutsu가 온다」
• Git 공식 프로젝트 릴리스 기록(2005년 출시 공지)

테크창 연구팀 | 인천대학교 창의인재개발학과 전공심화연구모임