버전 관리 시스템 Git은 전 세계 개발 조직의 작업 흐름 한가운데에 자리 잡고 있다. 그런 만큼 새 릴리스에 담긴 변화는 수많은 팀의 일상에 크고 작은 영향을 준다. 최근 공개된 Git 2.56은 700개가 넘는 비병합 커밋을 담은 견실한 릴리스지만, 대다수 사용자의 경험을 근본적으로 바꾸지는 않는다. 오히려 이 릴리스의 성격은 "더 큰 변화를 다음으로 미루고 있는 프로젝트"의 모습에 가깝다. 실무자 입장에서 지금 눈여겨볼 지점은 2.56의 소소한 개선들과, 곧 결정될 3.0이 예고하는 호환성 단절이다.
2.56이 손본 실무의 잔가지들
2.56에서 눈에 띄는 것은 아직 실험적 단계인 git history 도구에 추가된 drop 하위 명령이다. 지정한 커밋을 히스토리에서 제거하고 그 뒤에 쌓인 커밋들을 다시 재생(replay)해주는 기능으로, 문제 있는 커밋 하나를 걷어내는 작업을 한결 쉽게 만든다. 다만 히스토리에 병합 커밋이 하나라도 있으면 동작을 거부하기 때문에, 병합이 일상인 대다수 저장소에서는 아직 쓸모가 제한적이다. 실험 단계임을 감안해 기대치를 조정해두는 편이 낫다.
나머지 변화는 대체로 사용성을 다듬는 성격이다. git status는 추적 대상 브랜치에 뒤처진 로컬 브랜치에 대해 git pull을 제안하기 시작했다. 다만 아직 가져오지 않은(unfetched) 원격 추적 브랜치보다 뒤처져 있어도 여전히 "up to date"라고 표시하는 한계는 남아 있다. 저수준 참조 조작 도구인 git refs에는 create·delete·update·rename 하위 명령이 추가됐는데, 이름 그대로의 동작을 한다는 점이 오히려 Git답지 않게 느껴질 정도다. 이 밖에 병합된 로컬 브랜치를 정리하는 git branch --delete-merged, 이등분(bisect) 중인 브랜치를 실수로 지우려 하면 유용한 메시지와 함께 실패시키는 안전장치, 여러 명령이 동시에 설정 파일을 건드릴 때 잠금 실패를 재시도해 충돌을 줄이는 처리, 충돌이 해결된 파일만 스테이징하는 git add --resolved 등이 더해졌다.
진짜 분기점은 3.0
정작 중요한 물음은 그다음에 있다. 9월 초 Git 관리자 주니오 하마노는 다음 릴리스를 오랫동안 준비해온 3.0으로 낼지, 아니면 그 전에 2.x를 한두 번 더 낼지를 커뮤니티에 물었다. 3.0이 민감한 이유는 여러 호환성 단절을 품고 있어 일부 사용자의 업그레이드를 망설이게 할 수 있기 때문이다.
가장 무게 있는 변화는 기본 해시 함수를 SHA-1에서 SHA-256으로 바꾸는 것이다. Git은 초창기부터 파일·트리·커밋 등 모든 객체를 해시로 식별하고, 이를 통해 커밋 사슬의 무결성을 검증해왔다. SHA-1은 오래전부터 취약하다고 평가돼 왔고, 만약 깨진다면 탐지하기 어려운 방식으로 히스토리를 조작하는 데 악용될 여지가 있다. Git은 알려진 SHA-1 공격에 대한 방어를 이미 내장하고 있어 당장 심각하게 우려하는 이는 드물지만, 더 안전한 함수로 옮겨가는 것은 합리적인 방향이다.
기술적 준비는 상당 부분 끝나 있다. 실험 딱지를 뗀 SHA-256 지원은 2023년 2.42 릴리스부터 존재했다. 발목을 잡아온 것은 주요 포지(forge) 사이트의 지원 여부였다. GitLab은 2024년부터, Forgejo도 지원하지만, 정작 방 안의 코끼리인 GitHub의 지원 시점은 여전히 불투명하다. GitHub과 호환되지 않는 저장소를 만들어내는 Git을 배포하는 것은 부담스러운 일이기 때문이다. 다만 GitHub 직원이자 SHA-256 전환의 핵심 개발자인 brian m. carlson이 하마노의 질문에 "관련 소식이 곧 나올 것"이라며 다음 릴리스를 3.0으로 하는 편이 낫겠다고 답한 점은 의미심장하다.
carlson은 3.0 전에 하나를 더 반영하고 싶어 한다. Git은 객체 ID를 소문자로 다뤄왔지만 대문자 ID도 받아들여, f00f00과 F00F00처럼 겉보기에 다른 두 ID가 사실 같은 값인 상황이 생긴다. 이 모호함에서 버그와 보안 취약점이 나온 것으로 보이며, 그래서 그는 소문자 ID만 허용하도록 동작을 바꾸려 한다. 대부분에게는 문제가 없겠지만, 어딘가에는 기존 동작에 의존하는 사용자가 있을 가능성이 크다.
reftable과 Rust라는 또 다른 축
또 하나 미뤄져 온 변화는 참조 저장 방식을 reftable로 전환하는 것이다. 브랜치·태그·원격 등 참조(ref)는 지금 기본적으로 .git/refs/ 아래 개별 파일로 저장되고, 이를 packed-refs로 묶어 성능을 끌어올린다. 하지만 참조 수가 늘수록 비효율이 커진다. 프로젝트 문서에 따르면 안드로이드 저장소의 참조는 80만 개를 넘는데, 이 규모에서는 특정 커밋을 가리키는 참조를 찾는 일조차 값비싼 작업이 된다. 2.45에서 도입된 reftable은 공간 효율과 빠른 접근을 함께 노린 바이너리 형식으로, Git 자체 사용자에게는 성능 향상 외에 눈에 띄는 변화가 없다. 문제는 Git 저장소에 접근하는 다른 소프트웨어다. carlson은 libgit2를 우려 지점으로 꼽았지만, 패트릭 슈타인하르트가 libgit2에 reftable 지원을 추가했고 SHA-256 지원도 8월부터 기본 활성화됐다고 밝혀 이 장애물은 사실상 해소됐다.
마지막은 Rust 문제다. Git은 Rust로 작성된 코드를 시험적으로 받아들였지만 빌드에 Rust를 필수로 만들지는 않았다. 이 역시 3.0에서 바뀔 전망이라, 이후에는 동작하는 Rust 컴파일러가 없는 플랫폼은 업그레이드할 수 없게 된다. carlson은 지원되지 않는 플랫폼에 Rust를 이식하려는 이가 딱히 없어 보이므로 이 또한 걸림돌이 되어선 안 된다고 봤다. 최종 결정은 하마노의 몫이며, 그는 "이것은 인기투표도 민주주의도 아니다"라고 못 박았다. 다만 질문이 올라온 뒤 2주 가까이 3.x 시대로의 전환에 뚜렷한 반대는 없었다. 기존 SHA-1과 파일 기반 참조 저장소는 계속 완전히 지원되는 만큼, 3.0이 2026년 안에 나오지 않더라도 곧 뒤따를 것으로 보인다.