Git 3.0이 온다: 20년 만의 가장 큰 변화, 무엇을 준비해야 할까

💡 글의 핵심 3줄 요약

1. Git 개발진은 2026년 말을 목표로 메이저 버전인 Git 3.0을 준비 중이며, 기본 해시 알고리즘이 SHA-1에서 SHA-256으로 바뀌는 것이 가장 근본적인 변화입니다.
2. Git 3.0부터는 Rust가 필수 빌드 요구사항이 되고, 새 저장소의 기본 브랜치 이름도 master에서 main으로 바뀝니다.
3. 다만 GitHub 등 주요 호스팅 플랫폼의 SHA-256 저장소 지원이 아직 완전하지 않아, 실제 전환 속도는 생태계의 준비 상황에 달려 있습니다.

우리가 매일 수십 번씩 두드리는 명령어, git. 너무 공기 같은 존재라서 이 도구에도 메이저 버전 업그레이드가 있다는 사실을 잊고 지내기 쉽습니다. 2005년 리누스 토르발스가 만든 이후 Git은 놀라울 만큼 보수적으로 발전해 왔습니다. Git 2.0이 나온 것이 2014년이니, 메이저 버전이 한 번 바뀌는 데 10년이 걸리는 프로젝트인 셈이죠.

그런데 지금, 그 다음 챕터가 눈앞에 와 있습니다. Git 개발진이 2026년 말 출시를 목표로 Git 3.0을 준비하고 있다는 소식입니다. 단순한 버전 숫자 놀음이 아니라, 해시 알고리즘부터 구현 언어, 기본 브랜치 이름까지 바뀌는 큰 전환입니다. 오늘은 이 변화들이 각각 어떤 의미인지, 그리고 우리는 무엇을 준비하면 되는지 하나씩 짚어보겠습니다.

SHA-1에서 SHA-256으로, 해시 전환이 갖는 의미

Git 3.0의 가장 근본적인 변화는 기본 해시 알고리즘의 교체입니다. Git은 커밋, 트리, 블롭 등 모든 객체를 해시값으로 식별하는데, 지금까지 그 역할을 SHA-1이 맡아 왔습니다. 문제는 SHA-1이 이미 2017년에 실제 충돌 공격(SHAttered)이 시연된, 암호학적으로 은퇴한 알고리즘이라는 점입니다.

Git은 그동안 충돌 탐지 기능이 추가된 SHA-1 변형으로 버텨왔고, SHA-256 저장소 지원 자체는 몇 년 전부터 실험적으로 존재했습니다. 달라지는 것은 기본값입니다. 이미 Git 2.51에서 SHA-256이 Git 3.0의 기본 해시가 될 것임을 예고했고, 3.0부터는 새로 만드는 저장소가 기본적으로 SHA-256 객체 형식을 쓰게 됩니다.

다만 현실적인 걸림돌이 하나 있습니다. 바로 호스팅 플랫폼입니다. GitHub는 아직 SHA-256 저장소를 지원하지 않고 있어서, 로컬에서 SHA-256 저장소를 만들어도 밀어 올릴 곳이 마땅치 않은 상황입니다. Git 3.0의 출시 시점 자체가 GitHub, GitLab 같은 주요 플랫폼의 준비 상황에 달려 있다는 이야기가 나오는 이유입니다. 기존 SHA-1 저장소가 강제로 전환되는 것은 아니니 당장 패닉할 필요는 없지만, 방향은 분명해졌습니다.

C의 성역에 들어온 Rust, 필수 빌드 요구사항이 되다

두 번째 변화는 어쩌면 더 상징적입니다. Git 3.0부터 Rust가 필수 빌드 요구사항이 됩니다. 2005년 탄생 이후 줄곧 C로 작성되어 온 프로젝트가, 이제 Rust 컴파일러 없이는 빌드되지 않는 시대로 들어가는 것입니다.

이 흐름이 낯설지 않으실 겁니다. 리눅스 커널이 Rust 코드를 받아들였고, 최근에는 커널 개발진이 Rust 도입 실험이 성공적으로 끝났다고 선언하기도 했죠. 미국 정부 기관들까지 메모리 안전 언어 사용을 권고하는 상황에서, 전 세계 개발 인프라의 핵심인 Git이 메모리 안전성 문제로부터 자유로워지려는 것은 자연스러운 수순입니다. Git처럼 신뢰성이 생명인 도구에서 버퍼 오버플로 같은 메모리 버그 계열의 취약점을 원천적으로 줄일 수 있다면, 장기적으로 모든 사용자가 수혜자가 됩니다.

물론 반작용도 있습니다. Rust 툴체인이 지원되지 않는 오래된 플랫폼이나 특수한 임베디드 환경에서는 Git 빌드가 어려워질 수 있다는 우려가 커뮤니티에서 오가고 있습니다. NonStop 같은 특수 플랫폼 유지보수자들에게는 실제로 부담이 되는 결정이지만, Git 개발진은 생태계 전체의 이익이 더 크다고 판단한 것으로 보입니다.

main 기본 브랜치와 reftable, 체감될 변화들

세 번째는 많은 분들이 이미 체감으로 예상했을 변화입니다. Git 3.0부터 새 저장소의 기본 브랜치 이름이 master에서 main으로 바뀝니다. GitHub가 2020년부터 신규 저장소의 기본 브랜치를 main으로 바꿨고, GitLab 등 다른 플랫폼들도 뒤따른 지 오래죠. 정작 Git 본체만 master를 유지해 왔는데, 이제 도구와 생태계의 기본값이 일치하게 됩니다. init.defaultBranch 설정으로 이미 main을 쓰고 계셨다면 달라질 것은 없습니다.

성능 쪽 개선도 주목할 만합니다. 참조(ref) 저장 방식으로 reftable이라는 새 포맷이 자리를 잡아가고 있는데, 수만 개의 브랜치와 태그를 가진 대형 저장소에서 기존 방식 대비 fetch와 push 성능이 크게 개선되는 것으로 보고되고 있습니다. 개인 프로젝트에서는 차이를 느끼기 어렵겠지만, 모노레포나 대규모 사내 저장소를 운영하는 조직이라면 반가운 소식입니다.

우리는 지금 무엇을 준비하면 될까

거창한 준비는 필요 없습니다만, 세 가지 정도는 점검해 둘 만합니다. 첫째, CI 스크립트나 배포 자동화에 master라는 브랜치 이름이 하드코딩되어 있지 않은지 확인해 보세요. 둘째, Git 객체 해시를 40자 고정 길이로 가정하고 파싱하는 스크립트가 있다면 손봐야 합니다. SHA-256 해시는 64자이기 때문입니다. 셋째, 사내에서 Git을 직접 빌드해서 배포하고 있다면 빌드 환경에 Rust 툴체인을 추가할 준비를 해두시는 것이 좋습니다.

결론: 조용하지만 확실한 세대 교체

정리해 보겠습니다. Git 3.0은 SHA-256 기본 해시 전환, Rust 필수화, main 기본 브랜치, reftable 성능 개선이라는 굵직한 변화를 안고 2026년 말 출시를 목표로 다가오고 있습니다. 출시일은 호스팅 플랫폼들의 SHA-256 지원 속도에 따라 밀릴 수 있지만, 방향 자체는 되돌릴 수 없는 흐름입니다.

버전 관리 도구는 조용할수록 좋은 도구입니다. 그래서 이번 변화도 대부분의 사용자에게는 어느 날 자연스럽게 스며들 가능성이 큽니다. 하지만 하드코딩된 브랜치 이름 하나, 해시 길이를 가정한 스크립트 한 줄이 어느 날 CI를 빨간불로 만들 수도 있죠. 큰 파도가 오기 전에 발밑을 한 번 점검해 두는 것, 그것이 이번 소식에서 우리가 챙길 실속입니다.