Git은 아직 충분한가? 현대 버전 관리에 대한 논쟁

10년 넘게 Git은 버전 관리 분야에서 확고한 산업 표준이었습니다. 그 속도, 분산 구조, 강력한 브랜칭 모델은 우리가 소프트웨어를 구축하는 방식을 형성해 왔습니다. 하지만 프로젝트 규모가 커지고 개발 패턴이 진화함에 따라—특히 모노레포와 AI 지원 코딩의 부상과 함께—점점 더 많은 개발자 커뮤니티가 다음과 같은 질문을 던지고 있습니다: Git은 정말 괜찮은가?

Git의 사용성에 대한 비판과 Jujutsu (jj)와 같은 새로운 도구의 등장으로 촉발된 최근 논의에 따르면, Git은 기능적으로 완전하지만 사용자 경험은 현대의 고속 엔지니어링 팀의 요구에 뒤처지는 경우가 많다고 합니다.

현대 워크플로우의 마찰

Git에 대한 주요 비판 중 하나는 "스택된" 변경을 처리할 때의 경직성입니다. 고생산성 환경에서는 개발자들이 여러 상호 연관된 기능을 동시에 작업하는 경우가 많습니다. 이는 선형이 아닌 트리 형태의 워크스트림을 만들게 됩니다.

개발자가 변경을 여러 브랜치에 나누어야 할 때—예를 들어 하나는 핵심 API 변경, 다른 하나는 기능 구현, 또 다른 하나는 빠른 버그 수정—Git의 브랜치 중심 모델은 번거로워질 수 있습니다. 한 개발자가 이렇게 언급했습니다:

I work on one thing, but it causes changes in other package and I have no clear no way to say: this changes go to branch #1, this other set of changes to branch #2, and another small fix to branch #3... Switching branches is not a solution, cause all of this changes develop at the same time.

이러한 마찰은 단일 변경이 여러 패키지에 영향을 미치는 모노레포에서 더욱 증폭됩니다. 커밋을 브랜치 간에 격리하고 이동하는 과정이 "Git 마법"이라 할 만큼 번거로운 작업이 됩니다.

Jujutsu (jj)의 부상과 가변성에 대한 탐구

이러한 문제점을 해결하기 위해 Jujutsu (jj)와 같은 도구가 주목받고 있습니다. 이러한 새로운 시스템에 대한 핵심 주장은 몇 가지 주요 개선점에 초점을 맞추고 있습니다:

미커밋 상태의 더 나은 처리: Git의 인덱스(스테이징 영역)는 종종 장애물로 여겨집니다. 새로운 도구는 상태를 보다 유연하게 추적하여 복잡한 리베이스 중 작업 손실 위험을 줄이는 것을 목표로 합니다.
스택된 PR에 대한 일등 지원: 커밋을 보다 가변적이고 유연하게 다룸으로써, 이러한 도구는 지속적인 수동 리베이스의 "의식" 없이도 종속적인 변경 시리즈를 쉽게 발전시킬 수 있게 합니다.
인지 부하 감소: 목표는 복잡한 작업이 DAG(Directed Acyclic Graph)의 내부 구조에 대한 깊은 이해를 필요로 하는 시스템에서 벗어나는 것입니다.

반론: "Git은 괜찮다"

이러한 비판에도 불구하고, 커뮤니티의 상당 부분은 여전히 설득되지 않았습니다. "Git은 괜찮다" 진영은 일반적으로 세 가지 사고 범주로 나뉩니다:

1. "근육 기억" 관점

많은 시니어 개발자들은 Git의 복잡함이 단순히 학습 곡선이라고 주장합니다. 리베이스와 브랜치 관리 명령이 근육 기억이 되면 마찰이 사라집니다. 이러한 사용자에게 복잡함은 Git이 제공하는 강력함의 특징이며, 버그가 아닙니다.

2. 자동화 솔루션

도구를 바꾸는 대신, 일부 개발자는 자동화를 통해 Git의 장황함을 해결합니다. 여기에는 스택된 리베이스를 처리하기 위한 맞춤 쉘 스크립트를 작성하거나 Magit과 같은 고급 IDE 통합을 사용해 워크플로우를 간소화하는 것이 포함됩니다.

3. AI 브리지

흥미롭게도, LLM의 등장은 Git을 두려워하는 사람들에게 일시적인 구제를 제공했습니다. 많은 개발자들이 이제 AI를 사용해 특정 리베이스나 재작성에 필요한 복잡한 Git 명령 시퀀스를 정확히 생성함으로써, AI를 의도와 Git의 난해한 구문 사이의 번역 계층으로 활용하고 있습니다.

종합: 도구 vs. 프로세스

Git의 적합성에 대한 논쟁은 소프트웨어 엔지니어링에서 더 깊은 긴장을 드러냅니다: 견고하고 분산된 시스템과 간소화된 개발자 경험 사이의 트레이드오프.

일부는 Git을 관리하기 위해 복잡한 도구가 필요하다는 것이 "과잉 설계"와 프로세스 실패의 신호라고 주장하는 반면, 다른 이들은 도구가 개발자들의 실제 작업 현실에 맞게 진화해야 한다고 주장합니다—특히 AI 기반 코딩이 동시에 이루어지는 변경량을 크게 늘릴 때는 더욱 그렇습니다.

Jujutsu가 결국 Git을 대체하거나 파워 유저를 위한 틈새 도구로 남든, 이 대화는 중요한 진실을 강조합니다: 코드를 관리하는 방식은 우리가 작성하는 코드만큼이나 중요합니다. 우리의 워크스트림이 더 "트리 형태"가 될수록, 이를 관리하는 도구는 적응하거나 병목이 될 위험을 안게 됩니다.