Git 3.0이 온다는 게 무슨 뜻이냐면
Git 2.0이 나온 게 2014년이에요. 그 뒤로 12년 넘게 2.x 버전만 쭉 이어왔죠. 올해 말쯤 2.56이 나올 예정이고요. LWN이 2.56에 들어갈 내용과 함께, 그 뒤에 기다리고 있는 Git 3.0 이야기를 정리했어요.
Git이 메이저 버전을 올린다는 건 '호환성을 깨는 변경을 한꺼번에 한다'는 뜻이에요. Git 프로젝트는 몇 년 전부터 저장소 안에 BreakingChanges라는 문서를 두고, 3.0에서 바꿀 것들을 미리 적어두고 있었어요. 어느 날 갑자기 터지는 게 아니라 예고된 변화라는 거죠. 그럼 뭐가 바뀌는지 하나씩 볼게요.
1. 기본 해시가 SHA-1에서 SHA-256으로
Git은 모든 커밋, 파일, 트리를 해시값으로 식별해요. 여러분이 매일 보는 a1b2c3d 같은 커밋 ID가 SHA-1 해시의 앞부분이에요. 그런데 SHA-1은 2017년에 충돌(서로 다른 입력이 같은 해시를 내는 것)이 실제로 만들어지면서 암호학적으로는 깨진 알고리즘이 됐어요. Git은 그동안 충돌 탐지 코드를 넣어서 버텨왔지만, 근본 해결은 SHA-256으로 옮기는 거였죠.
SHA-256 지원 자체는 Git 2.29(2020년)부터 있었어요. git init --object-format=sha256으로 만들 수 있었고요. 3.0에서 바뀌는 건 '기본값'이에요. 아무 옵션 없이 git init을 하면 SHA-256 저장소가 만들어지는 거예요.
문제는 생태계예요. SHA-256 저장소는 SHA-1 저장소와 호환되지 않아요. 같은 커밋이라도 해시가 다르니까 push/pull이 안 되죠. 그리고 GitHub는 아직 SHA-256 저장소를 받지 않아요. GitLab은 실험적 지원, Forgejo나 Gitea 같은 곳은 지원하고 있고요. 그래서 3.0이 나온 뒤 새로 git init한 저장소를 GitHub에 올리려다 막히는 상황이 생길 수 있어요. 이 부분은 3.0 출시 전에 호스팅 업체들이 어떻게 대응하느냐가 관건이에요.
2. 레퍼런스 저장 방식이 reftable로
이게 뭐냐면, Git이 브랜치와 태그 정보를 저장하는 방식이 바뀌는 거예요. 지금은 .git/refs/heads/main 같은 파일 하나에 커밋 해시가 텍스트로 적혀 있고, 오래된 것들은 packed-refs라는 파일에 모아둬요. 단순하고 투명하지만, 브랜치가 수만 개인 대형 모노레포에서는 느리고, 파일 시스템 특성상 대소문자 문제나 원자성(여러 변경을 한 번에 적용하거나 전부 취소하는 성질) 문제도 있어요.
reftable은 원래 Google이 JGit용으로 설계한 바이너리 형식인데, Git 2.45부터 옵션으로 쓸 수 있었어요. 여러 ref를 한 번에 원자적으로 갱신할 수 있고, 조회도 빠르고, 대소문자 구분 문제도 없어요. 3.0에서는 이게 새 저장소의 기본값이 돼요. 일반 사용자는 차이를 못 느끼겠지만, .git/refs 디렉토리를 직접 읽는 스크립트나 도구가 있다면 깨질 수 있으니 주의가 필요해요.
3. Rust가 필수 의존성으로
Git은 20년 넘게 C로만 작성돼 왔어요. 그런데 2025년에 Git 코드베이스에 Rust를 도입하는 작업이 시작됐고, 3.0에서는 Rust가 선택이 아니라 빌드에 반드시 필요한 의존성이 되는 방향으로 논의가 진행됐어요. 리눅스 커널이 Rust를 받아들인 흐름과 같은 맥락이에요. 메모리 안전성 문제를 언어 차원에서 막겠다는 거죠.
사용자 입장에선 바이너리로 설치하면 아무 영향이 없어요. 다만 소스에서 직접 빌드하는 환경, 특히 오래된 서버나 임베디드 배포판에서는 Rust 툴체인이 필요해지니까 준비가 필요해요.
4. 오래된 기능 정리
git whatchanged는 2.51에서 폐기 예고됐고 3.0에서 사라져요. git log --raw로 대체하면 돼요. git pack-redundant도 없어지고, .git/branches/와 .git/remotes/ 디렉토리 같은 아주 옛날 설정 방식도 지원이 끊겨요. 기본 브랜치 이름을 master에서 main으로 바꾸는 것도 논의 대상이에요.
한국 개발자에게 주는 시사점
당장 3.0이 나와도 기존 저장소는 그대로 동작해요. 기존 SHA-1 저장소가 자동으로 SHA-256으로 바뀌는 일은 없거든요. 다만 세 가지는 미리 챙겨두세요.
첫째, 회사 스크립트에서 git whatchanged를 쓰는 곳이 있는지 검색해보세요. 오래된 배포 스크립트나 통계 스크립트에 은근히 남아 있어요. 둘째, .git/refs를 직접 읽는 도구가 있다면 git for-each-ref 같은 정식 명령으로 바꿔두세요. 셋째, 3.0 출시 후 새 저장소를 만들 때 GitHub에 올릴 거라면 git config --global init.defaultObjectFormat sha1을 설정해두는 게 안전해요. 호스팅 업체가 SHA-256을 지원할 때까지요.
마무리
한 줄로 정리하면, Git 3.0은 SHA-256, reftable, Rust라는 세 가지 큰 축으로 Git의 기반을 현대화하는 릴리스이고, 예고된 변화니까 미리 준비하면 놀랄 일은 없어요. 여러분은 GitHub가 SHA-256을 지원하기 전에 Git 3.0이 먼저 나오면 어떤 일이 벌어질 거라고 보세요? 그리고 Git에 Rust가 들어오는 것, 환영하시나요?
🔗 출처: Hacker News