Git 3.0과 SHA-256, 더 안전한 해시의 숨은 청구서

핵심 요약

• Git의 해시 체계를 바꾸면 파일 내용이 같아도 커밋을 식별하는 값이 달라집니다.
• SHA-256은 SHA-1의 충돌 취약성을 벗어나기 위한 보안 선택지입니다.
• 새 저장소의 기본값을 바꾸는 일과 기존 저장소를 변환하는 일은 별개입니다.
• 전환 비용은 Git뿐 아니라 호스팅, 자동 빌드, 배포 기록 등 주변 도구에서도 발생할 수 있습니다.

Git 3.0에서 SHA-256을 기본값으로 삼는 문제는 얼핏 간단해 보입니다. 더 안전한 해시가 있다면 바꾸면 될 듯합니다. 하지만 커밋 해시는 코드 리뷰와 배포 기록을 연결하는 이름표이기도 합니다. 해시를 바꾸려면 이 기록들이 어떻게 이어지는지도 살펴야 합니다.

해시는 지문이면서 주소이기도 합니다

해시는 데이터를 일정한 길이의 값으로 바꾸는 함수입니다. Git은 이 값으로 파일 내용이나 커밋 같은 객체를 식별합니다. 내용이 달라졌는지 확인하는 지문이자, 특정 객체를 찾아갈 때 쓰는 주소입니다.

SHA-1의 전체 해시를 16진수로 표시하면 40자리입니다. SHA-256은 64자리입니다. 화면에 보이는 짧은 커밋 번호는 이 식별자의 앞부분만 보여줍니다.

다만 전환은 “입력 칸을 24자리 늘리는 작업”보다 복잡합니다. 커밋에는 파일 상태를 가리키는 정보와 부모 커밋의 식별자가 들어갑니다. 참조하는 식별자가 바뀌면 그 값을 담은 커밋의 내용도 달라집니다.

그래서 같은 변경 이력이라도 해시 체계가 달라지면 커밋 식별자가 달라집니다. 기존 식별자로 남겨둔 기록을 계속 쓰려면 예전 값과 새 값이 어떻게 대응하는지 확인할 방법도 필요합니다.

SHA-1의 문제는 충돌 취약성입니다

SHA-1의 문제는 충돌입니다. 서로 다른 데이터가 같은 해시를 갖도록 만드는 공격을 더는 안전하게 막을 수 없다는 뜻입니다.

Git처럼 해시로 객체를 식별하는 시스템에서는 이 문제가 중요합니다. 서로 다른 내용에 같은 식별자가 붙으면 둘을 구분하기 어려워집니다. 그 식별자를 믿고 내용을 검증하는 과정에도 문제가 생길 수 있습니다.

다만 충돌 공격이 가능하다는 말이 곧 “공격자가 원하는 기존 커밋을 마음대로 바꿔치기할 수 있다”는 뜻은 아닙니다. 같은 해시를 갖는 두 입력을 만드는 일과 이미 정해진 해시에 맞춰 다른 입력을 만드는 일은 구분해야 합니다.

SHA-256으로 바꾸려는 이유는 이런 충돌 위험을 줄이기 위해서입니다. 하지만 해시를 바꾼다고 계정 탈취나 악성 코드가 담긴 정상 커밋까지 막을 수는 없습니다. 보안 효과가 적용되는 범위를 정확히 알아야 전환으로 얻는 이점과 그에 드는 비용을 제대로 비교할 수 있습니다.

기본값 변경은 모든 저장소의 강제 이주가 아닙니다

새 저장소를 어떤 형식으로 만들지 정하는 일과 이미 운영 중인 저장소를 다른 형식으로 바꾸는 일은 나눠서 봐야 합니다. 둘 다 SHA-256을 쓰는 문제지만, 해야 할 작업은 다릅니다.

새 저장소의 기본값이 SHA-256이 되더라도 그 설정만으로 기존 SHA-1 저장소가 다시 작성되지는 않습니다. 기본값을 바꾸는 일과 기존 이력을 변환하는 일은 별개입니다.

그렇다고 새 저장소만 바꾸면 호환성 문제가 사라지는 것도 아닙니다. 개발자가 쓰는 Git부터 원격 저장소를 운영하는 서비스와 자동 빌드 도구까지 해당 객체 형식을 다룰 수 있어야 합니다. 중간에 변환 기능을 둔다면 그 기능도 검증하고 운영해야 합니다.

기본값은 사용자의 선택에도 영향을 줍니다. 별도 설정 없이 만든 저장소가 새로운 형식을 쓴다면, 호환성 확인은 일부 사용자가 실험할 때만 필요한 일이 아닙니다. 일반적인 개발 과정에서도 확인해야 할 문제가 됩니다.

따라서 “SHA-256을 지원하는가”만 물어서는 충분하지 않습니다. “우리 팀의 코드가 거쳐 가는 도구들이 함께 처리할 수 있는가”도 확인해야 합니다.

Git 주변 도구에도 전환 비용이 듭니다

예를 들어 사내 배포 시스템에서 커밋 해시를 저장하는 칸을 40자리로 제한했다고 가정해 보겠습니다. Git이 SHA-256 저장소를 정상적으로 처리하더라도 배포 시스템은 그 값을 저장하지 못할 수 있습니다.

커밋 번호를 검사하는 스크립트도 마찬가지입니다. 정확히 40자리만 허용하도록 작성했다면 고쳐야 합니다. 해시를 빌드 캐시의 키로 쓰는 시스템에서는 식별자가 바뀔 때 캐시에 어떤 영향이 생기는지도 살펴야 합니다.

기존 저장소를 변환할 때는 연결 관계가 더 복잡해집니다. 릴리스 문서와 장애 분석 기록, 코드 리뷰에 남은 커밋 식별자가 어떤 변경을 가리키는지 계속 추적할 수 있어야 합니다. 코드가 그대로여도 기록 사이의 연결은 끊어질 수 있습니다.

전환 비용의 핵심은 연결된 도구와 기록에 있습니다. 해시를 계산하는 기능을 구현하는 데 드는 작업과 조직 전체가 새 식별자를 문제없이 쓰도록 하는 데 드는 작업은 범위가 다릅니다.

그렇다고 비용이 든다는 이유만으로 기존 방식을 계속 유지할 수도 없습니다. 팀의 부담을 줄이려면 호환성을 점검하는 일부터 구분해 진행해야 합니다. 새 저장소에 적용하는 일과 기존 저장소를 변환하는 일도 나눠야 합니다. 기본값을 정할 때도 이처럼 단계적으로 도입할 수 있는지가 중요한 판단 기준입니다.

SHA-256 전환이 ‘비싼 실수’가 되는 건 연결된 도구가 얼마나 준비됐는지 과소평가했을 때입니다. 보안을 강화하는 선택 자체가 문제는 아닙니다. Git 3.0의 기본값을 판단할 때도 알고리즘의 안전성과 실제로 전환할 방법을 함께 살펴야 합니다. 팀에서 커밋 해시를 저장하거나 비교하는 곳이 몇 군데인지 확인하는 데서 시작할 수 있습니다.