GitButler, 1700만 달러 투자 유치 — "Git 이후의 버전 관리"를 만들겠다고?

Git을 대체하겠다는 도전

Git은 리누스 토르발즈가 2005년에 만든 이후 거의 20년 동안 소프트웨어 개발의 버전 관리를 사실상 독점해왔어요. SVN, Mercurial, Perforce 같은 경쟁자들이 있었지만, Git + GitHub 조합이 업계 표준으로 자리 잡은 지 오래죠. 이제 개발자 대부분에게 "버전 관리 = Git"인 시대예요.

그런데 여기, "Git 이후에 오는 것을 만들겠다"며 시리즈 A에서 1700만 달러(약 230억 원)를 투자받은 스타트업이 있어요. 바로 GitButler예요. 이 회사는 단순한 Git GUI 도구가 아니라, Git의 근본적인 한계를 해결하는 새로운 버전 관리 경험을 만들겠다는 비전을 제시하고 있어요.

GitButler가 해결하려는 문제

Git을 써본 분이라면 다들 공감할 거예요. Git은 강력하지만 정말 어렵다는 거. 브랜치, 머지, 리베이스, 체리픽, 인터랙티브 리베이스, 스태시, 서브모듈… 개념 하나하나는 이해할 수 있지만, 이것들이 복잡하게 얽히면 경험 많은 개발자도 당황하는 순간이 생기거든요.

GitButler가 특히 주목하는 문제는 "동시에 여러 작업을 하는 상황"이에요. 현실의 개발 작업은 깔끔하게 하나의 브랜치에서 하나의 기능만 작업하는 경우가 드물잖아요. 코드를 고치다 보면 관련 없는 버그를 발견하기도 하고, 리팩토링이 필요한 부분이 눈에 들어오기도 해요. 이런 변경사항들을 Git에서 분리하려면 git stash, git checkout, git cherry-pick 같은 명령어를 여러 번 조합해야 하는데, 이 과정이 번거롭고 실수하기 쉬워요.

GitButler는 이걸 가상 브랜치(Virtual Branch)라는 개념으로 해결하려고 해요. 이게 뭐냐면, 하나의 작업 디렉토리에서 여러 개의 논리적 브랜치를 동시에 관리할 수 있는 기능이에요. 파일 A의 변경은 "기능 추가" 브랜치에, 파일 B의 변경은 "버그 수정" 브랜치에 드래그 앤 드롭으로 할당하는 식이죠. Git의 checkout으로 브랜치를 오가지 않아도 되는 거예요.

기술적으로 어떻게 다른가

GitButler의 핵심은 Git 위에 새로운 추상화 레이어를 올리는 거예요. 내부적으로는 Git을 사용하지만, 사용자에게 노출되는 워크플로우는 Git과 다르게 설계되어 있어요.

전통적인 Git에서는 작업 트리(working tree)가 하나의 브랜치에 대응돼요. 다른 브랜치에서 작업하려면 checkout이나 switch로 브랜치를 바꿔야 하고, 그러면 작업 트리의 파일이 바뀌잖아요. GitButler는 이 제약을 없애서, 하나의 작업 트리에서 여러 브랜치의 변경사항을 동시에 편집하고 관리할 수 있게 해요.

또한 GitButler는 소유권(ownership) 개념을 도입해서, 특정 파일이나 코드 영역의 변경이 자동으로 적절한 브랜치에 할당되도록 하는 기능도 제공해요. AI를 활용해서 커밋 메시지를 자동 생성하거나, 변경사항의 의미를 분석해서 분류하는 기능도 포함되어 있고요.

1700만 달러의 투자금으로는 이 핵심 제품을 더 발전시키는 것뿐 아니라, Git을 넘어서는 새로운 버전 관리 백엔드를 개발하겠다는 계획도 밝혔어요. 단순히 Git의 프론트엔드가 아니라, 장기적으로 Git 자체를 대체할 수 있는 새로운 버전 관리 시스템을 목표로 하고 있는 거예요.

업계 맥락: Git을 대체하려는 시도들

Git을 대체하거나 개선하려는 시도는 GitButler만 하는 게 아니에요. Jujutsu(jj)는 Google 출신 개발자가 만든 버전 관리 도구로, Git과 호환되면서도 더 나은 머지와 충돌 해결 경험을 제공해요. Google 내부에서 사용 중이고, 오픈소스로 공개되어 있어요. Sapling은 Meta(Facebook)가 내부에서 쓰던 소스 관리 도구를 오픈소스로 공개한 건데, Git과는 완전히 다른 접근을 취해요.

흥미로운 건, 이런 시도들이 모두 비슷한 문제를 지적한다는 거예요. Git의 브랜칭 모델이 현대적인 개발 워크플로우에 맞지 않는 부분이 있다는 거죠. 특히 대규모 모노레포, AI 지원 코딩, 동시 다발적인 코드 리뷰 같은 환경에서요.

하지만 Git을 대체하는 건 정말 어려운 도전이에요. Git의 가장 큰 강점은 기술적 우수성이 아니라 네트워크 효과거든요. GitHub, GitLab, Bitbucket 등 거대한 생태계가 Git 위에 구축되어 있고, 모든 CI/CD 도구, 코드 리뷰 시스템, 배포 파이프라인이 Git을 전제로 설계되어 있어요. 이 생태계 전체를 옮기는 건 기술 문제가 아니라 생태계 문제예요.

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

당장 Git을 버리고 다른 걸 쓸 필요는 전혀 없어요. GitButler가 아무리 투자를 많이 받아도, Git 생태계를 대체하려면 수년에서 수십 년이 걸릴 수 있어요. 하지만 주목할 만한 포인트는 있어요.

첫째, GitButler의 가상 브랜치 개념은 당장 써볼 수 있어요. GitButler 클라이언트는 오픈소스(Rust + Tauri 기반)로 공개되어 있고, 기존 Git 저장소에서 바로 사용할 수 있어요. 동시에 여러 작업을 하면서 변경사항을 깔끔하게 분리하는 게 어려웠다면 한번 써볼 가치가 있어요.

둘째, 이 투자는 개발 도구 시장이 여전히 뜨겁다는 신호예요. Cursor, Windsurf 같은 AI 코딩 도구에 이어, 버전 관리 영역까지 혁신의 대상이 되고 있다는 건 개발자 도구 전반이 큰 변화의 시기에 있다는 뜻이에요.

셋째, Jujutsu나 Sapling 같은 대안 도구를 살짝 경험해보는 것도 좋아요. Git의 개념을 더 깊이 이해하는 데 도움이 되고, 미래에 어떤 도구가 표준이 되든 빠르게 적응할 수 있는 안목이 생기거든요.

마무리

"Git 이후"가 실제로 올지는 아무도 몰라요. 하지만 Git의 불편함을 해결하려는 시도 자체는 환영할 만하고, 그 과정에서 나온 도구들은 지금 당장 생산성을 높이는 데 쓸 수 있어요.

Git에서 가장 불편하다고 느끼는 점은 뭔가요? 브랜치 관리, 머지 충돌, 아니면 또 다른 무언가?