차기 메이저 버전인 Git 3.0에서 콘텐츠 해시 알고리즘의 기본값이 기존 SHA-1에서 SHA-256으로 바뀔 예정이다. 이 변경을 두고 한 개발 도구 업체의 블로그는 "이해하기 힘들 만큼 비용이 크고, 결국 얻는 것은 거의 없으며, 피할 수 있었던 전 지구적 골칫거리"가 될 것이라는 강한 비판을 내놓았다. 단순한 내부 구현 변경처럼 보이지만, 전 세계 거의 모든 소프트웨어 개발 워크플로의 바닥에 깔려 있는 도구인 만큼 그 파급 효과를 가볍게 보기 어렵다.
왜 해시 알고리즘을 바꾸려 하는가
배경을 이해하려면 Git이 해시를 어디에 쓰는지부터 짚어야 한다. Git은 커밋, 트리, 블롭 같은 모든 객체를 그 내용으로부터 계산한 해시값으로 식별한다. 즉 해시는 암호 보안을 위한 서명이 아니라 '내용 주소(content address)' 역할을 한다. 오랫동안 이 자리를 SHA-1이 맡아 왔는데, SHA-1은 이미 학계와 업계에서 충돌(서로 다른 내용이 같은 해시를 갖는 상황)을 인위적으로 만들 수 있음이 입증된 알고리즘이다. 이런 이유로 Git 프로젝트는 수년에 걸쳐 더 견고한 SHA-256으로 넘어가기 위한 작업을 진행해 왔고, 그 연장선에서 3.0의 기본값 전환이 논의되고 있다.
보안 관점만 보면 방향 자체는 자연스럽다. 더 강한 해시로 옮겨 가는 것은 장기적으로 피하기 어려운 과제이고, 새로 만드는 저장소라면 처음부터 SHA-256을 쓰는 편이 안전하다. 문제는 '언제, 어떤 방식으로' 그 전환을 밀어붙이느냐에 있다.
비판의 핵심은 '생태계 비용'
비판론이 겨냥하는 지점은 알고리즘의 우열이 아니라 전환에 수반되는 생태계 비용이다. 현재 전 세계에 존재하는 거의 모든 Git 저장소, 그리고 이를 다루는 호스팅 서비스·CI 파이프라인·빌드 도구·에디터 플러그인·스크립트는 40자리 SHA-1 해시를 전제로 만들어져 있다. 기본값이 SHA-256으로 바뀌면 새로 생성되는 저장소의 객체 식별자 길이와 형식이 달라지고, 이를 가정하고 작성된 수많은 주변 도구가 미묘하게 어긋날 수 있다. 저장소 하나를 바꾸는 비용은 작아 보여도, 전 세계 규모로 곱해지면 '피할 수 있었던 거대한 혼란'이 된다는 것이 글쓴이의 논지다.
특히 SHA-1 저장소와 SHA-256 저장소 사이의 상호 운용이 매끄럽지 않다는 점이 실무적으로 뼈아프다. 서로 다른 해시 체계의 저장소를 자유롭게 주고받거나 섞어 쓰는 경로가 완전히 갖춰지지 않은 상태에서 기본값만 먼저 바꾸면, 그 혼란의 상당 부분이 개별 사용자와 조직에게 전가된다.
한국 실무자가 점검해야 할 것들
국내 개발팀 입장에서 당장 패닉에 빠질 필요는 없다. 기본값 변경은 '새로 만드는 저장소'에 적용되는 이야기이고, 이미 운영 중인 SHA-1 저장소가 어느 날 갑자기 깨지는 성격의 변화는 아니다. 다만 몇 가지는 미리 확인해 둘 가치가 있다. 사내에서 쓰는 Git 호스팅과 CI/CD 도구, 사내 자동화 스크립트가 SHA-256 해시를 전제로 동작할 수 있는지, 그리고 조직 표준으로 어떤 해시를 쓸지에 대한 방침이 있는지다. 특히 커밋 해시를 문자열 길이로 자르거나 정규식으로 파싱하는 사내 도구가 있다면 전환기에 가장 먼저 문제를 일으킬 후보다.
여기서 유의할 점은 이 기사가 근거로 삼은 원문이 중립적 발표문이 아니라 특정 업체의 비판적 주장이라는 사실이다. Git 3.0의 구체적인 기본값 전환 범위와 상호 운용 지원 수준은 실제 릴리스 시점의 공식 문서로 확인해야 한다. 그럼에도 "보안상 더 나은 선택"과 "지금 전면 기본값으로 밀어붙이는 것이 현명한가"는 분리해서 볼 문제라는 이번 논쟁의 구도만큼은, 대규모 저장소를 운영하는 팀이라면 미리 자기 환경에 대입해 볼 만한 질문이다.