요약

  • Git의 2018년 해시 전환 설계는 SHA-256을 선택하고 옛 객체 이름과 새 이름을 양방향으로 연결하는 방안을 제시했다. 그것은 구현 목표였다.
  • Git 2.29.0 설명서는 2020년 SHA-256 저장소를 실험용으로 소개했다. Git 2.54.0 설명서는 2026년에도 두 형식의 저장소 사이에 상호 운용성이 없다고 명시한다.

파일의 이름과 역사의 이름

파일 내용이 그대로라면 새 알고리즘으로 그 파일의 새 이름을 계산할 수 있다. Git의 blob은 비교적 단순하다. 문제는 트리와 커밋이다. 트리는 파일과 하위 트리의 객체 이름을 담고, 커밋은 트리와 부모 커밋의 이름을 담는다. 태그도 다른 객체를 가리킬 수 있다. Git의 설계 문서는 한 참조의 이름을 바꾸면 그 이름을 적은 객체의 바이트도 바뀐다고 설명한다. 그 객체 역시 다른 이름을 얻는다. 따라서 저장된 역사의 연결 구조를 따라 작업이 번진다.

2018년 문서는 SHA-1의 취약성과 2017년 SHAttered 충돌을 논의한 뒤 SHA-256을 선택했다. 저장소를 하나씩 바꾸면서 SHA-1 서버와 소통하려면 두 이름을 연결하는 양방향 대응표가 필요하다고 봤다. 설계는 단계별 작업을 제시했고, 새 프로토콜 지원은 초기 범위 밖에 뒀다. 도면을 그린 시점과 다리가 열린 시점을 혼동하면 이 역사의 핵심을 놓친다.

옵션이 먼저 도착했다

2020년 Git 2.29.0의 git-init 설명서에는 --object-format=sha256가 있다. 곧바로 실험적 기능이라는 경고가 따라온다. 일반적인 SHA-1 저장소와 작업을 공유하기 어렵고 시험 목적으로 쓰라는 내용이다. 새로운 형식의 저장소를 로컬에서 생성하는 것과 기존 협업망에서 밀고 당기는 것은 별개의 기능이다.

2026년 Git 2.54.0 설명서는 기본 객체 형식을 여전히 sha1로 적고 sha256을 선택지로 둔다. 두 형식 사이의 상호 운용성도 현재 없다고 밝힌다. 이 문장이 2018년의 야심을 지워 버리지는 않는다. 대신 무엇이 아직 완료되지 않았는지 정확히 보여 준다. 해시를 바꾸는 명령은 생겼고, 다른 형식의 저장소와 함께 일하는 계약은 남았다.

Git의 BreakingChanges 계획은 Git 3.0에서 새 저장소의 기본 형식을 SHA-256으로 바꾸려 한다. 출시 날짜는 제시하지 않았고 라이브러리, 앱, 호스팅 서비스의 준비를 조건으로 둔다. SHA-1 객체 형식을 폐지할 계획도 아직 없다. 새로 들어오는 저장소의 출입문을 바꿔도 이미 쌓인 저장소를 한밤중에 옮길 수는 없다.

누구의 소프트웨어가 국경인가

유지관리자는 원하는 해시와 새 기본값을 정할 수 있다. 하지만 원격 서비스와 의존 라이브러리, 빌드 도구와 오래된 저장소는 각자 다른 사람의 통제 아래 있다. 옛 이름과 새 이름을 맞춰야 하는 지점마다 전환 비용이 생긴다. Git에서 이름은 단순한 장식이 아니라 데이터 속의 참조다. 이름의 안전성을 높이려는 결정이 실제 협업으로 이어지려면, 동작 중인 소프트웨어들이 그 결정을 함께 처리해야 한다. 작업은 발표문보다 느린 시계로 움직인다.