Git 3.0이 SHA-256으로 바뀐다는데 | 출시일·논쟁·내 저장소에 미칠 영향, 지금 할 일

"Git 3.0부터 SHA-256이 기본"이라는 말이 해커뉴스와 개발자 커뮤니티에 돌고 있습니다. 10월 1일 GitHub 공동 창업자 스콧 샤콘(Scott Chacon)이 "값비싼 실수"라는 글을 올리면서 논쟁에 불이 붙었습니다.

결론부터 말하면 지금 당장 바뀌는 것은 없습니다. Git 공식 문서에는 3.0 출시일이 아직 없고, 기존 SHA-1 저장소를 없앨 계획도 없습니다. 그래도 바뀌면 push와 서브모듈, 해시 40자를 가정한 스크립트가 걸릴 수 있습니다. 공식 문서와 원문을 기준으로 무엇이 정해졌고 무엇이 아직 소문인지 나눠 봤습니다.

Git 공식 BreakingChanges 문서는 Git 3.0에서 새로 만드는 저장소의 기본 해시를 SHA-1에서 SHA-256으로 바꾼다고 적고 있다. 같은 문서에 "아직 정해진 출시일은 없다"와 "SHA-1 형식을 폐기할 계획은 없다"가 함께 적혀 있다. 최신 버전은 2026년 9월 28일 나온 Git 2.56이다. LWN은 Kernel Recipes 발표를 인용해 2026년 12월 2.98, 2027년 4월 2.99 장기지원판과 3.0을 함께 낸다는 계획을 전했지만 Git 공식 문서에는 아직 날짜가 없다. 샤콘은 충돌 공격이 현실적 위협이 아니고 전환 비용이 크다며 반대했고, 비판 측은 해시 공격 비용이 계속 떨어진다고 반박한다. 지금 사용자가 할 일은 없고, 궁금하면 git init --object-format=sha256으로 시험 저장소를 만들어 볼 수 있다.

목차

1. 무엇이 정해졌고 무엇이 소문인가

2. Git 3.0에서 바뀌는 다른 기본값

3. 논쟁: "값비싼 실수" 대 "미리 바꿔야 한다"

4. 바뀌면 무엇이 걸리나

5. 지금 할 일: 없다, 시험해 보려면 이렇게

1. 무엇이 정해졌고 무엇이 소문인가

Git은 파일과 커밋마다 내용을 요약한 지문, 곧 해시를 붙여 관리합니다. 지금까지는 SHA-1이라는 방식으로 40자 해시를 만들었는데, Git 3.0부터 새 저장소는 SHA-256으로 64자 해시를 쓰게 바꾸자는 것이 이번 논쟁의 출발점입니다.

출처: git-scm.com BreakingChanges 문서 갈무리

내용	상태	근거
Git 3.0에서 새 저장소 기본 해시를 SHA-256으로	Git 3.0에 예정된 변경	Git 공식 BreakingChanges 문서
Git 3.0 출시일	정해지지 않음	같은 문서: "no planned release date"
기존 SHA-1 형식 폐기	계획 없음	같은 문서
2026년 12월 2.98, 2027년 4월 2.99·3.0 동시 출시	개발자 발표로 전해진 계획(공식 문서엔 없음)	LWN, Kernel Recipes 발표 인용
GitHub의 SHA-256 저장소 지원	공식 발표 확인 못 함	샤콘 글: 지금은 push 불가

BreakingChanges 문서는 SHA-1의 약점으로 2017년 SHAttered, 2020년 Shambles 같은 실제 충돌 공격을 들었습니다. 이어 이 전환에는 "Git 라이브러리와 앱, 호스팅 서비스 생태계가 SHA-256을 지원할 준비가 돼야 한다"는 조건을 붙였습니다.

주의 "Git 3.0에서 SHA-256이 기본이 됐다"는 표현은 아직 틀린 말입니다. 3.0은 나오지 않았고, 출시 시점도 공식적으로 정해지지 않았습니다.

2. Git 3.0에서 바뀌는 다른 기본값

SHA-256만 바뀌는 것이 아닙니다. 공식 문서에는 참조(브랜치·태그) 저장 방식을 files에서 reftable로 바꾸는 계획, 새 저장소의 기본 브랜치 이름을 main으로 바꾸는 계획, 빌드에 Rust를 필수로 넣는 계획이 함께 올라 있습니다. 숨어 있는 bare 저장소를 자동으로 찾지 않도록 safe.bareRepository 기본값을 explicit으로 바꾸는 보안 변경도 들어 있습니다.

마지막 변경은 GitSpawn 글에서 다룬 "받은 저장소를 열기만 해도 명령이 실행되는" 공격 유형과 맞닿아 있습니다. 문서는 3.0 직전 버전을 장기지원(LTS) 판으로 정하고, 버그 수정은 최소 4번, 보안 수정은 6번의 출시 주기 동안 이어 간다고 적었습니다.

3. 논쟁: "값비싼 실수" 대 "미리 바꿔야 한다"

출처: GitButler 블로그(2026.10.01) 갈무리

샤콘은 GitButler 블로그 글에서 세 가지를 주장했습니다. 첫째, 일부러 같은 해시를 만드는 충돌 공격은 비용이 커서 현실적 위협이 아니라고 봤습니다. 둘째, 실제로 악성 코드가 들어오는 길은 해시 충돌이 아니라 인기 패키지의 관리권을 넘겨받는 식의 사회공학이라고 짚었습니다. 셋째, 모든 저장소가 SHA-1과 SHA-256 두 갈래로 나뉘면서 생기는 비용이 이득보다 훨씬 크다고 했습니다.

대안도 냈습니다. 커밋이나 태그에 서명할 때 작업 트리 전체의 SHA-256 체크섬을 따로 계산해 서명 안에 넣자는 방식입니다. 그는 직접 만든 시험 도구로 크로미움(작업 트리 35GB, 파일 210만 개)을 5초, 리눅스 커널 트리를 257ms에 처리했다고 밝혔습니다.

직접 실행한 화면(macOS Git 2.50.1, 2026-10-02)

해커뉴스 토론에서는 반론도 많았습니다. 해시 공격은 시간이 지날수록 싸지고 효율적이 될 수 있고, 서명의 안전성도 결국 그 서명이 가리키는 해시만큼이라는 것입니다. Git 프로젝트 문서 역시 "알려진 공격은 막고 있지만 앞으로 더 많은 공격이 나올 것"이라며 미리 준비하겠다는 입장입니다.

핵심 논쟁은 두 겹입니다. 샤콘은 기본값 변경 자체를 하지 말자는 쪽이고, Git 프로젝트는 바꾸되 "생태계가 준비된 뒤에"라는 조건을 걸었습니다. 그래서 전환 여부와 시점이 함께 다퉈지고 있습니다.

4. 바뀌면 무엇이 걸리나

기본값이 바뀌어도 기존 저장소는 그대로 SHA-1로 동작합니다. 문제는 새로 만든 저장소가 SHA-256이 되면서 기존 도구·서비스와 맞물리는 지점입니다.

걸리는 곳	무슨 일이 생기나	대응
GitHub 등 호스팅	SHA-256 저장소를 받지 않는 곳에는 push가 거절됨	서비스 지원 여부 확인 전까지는 SHA-1로 생성
서브모듈	해시 방식이 다른 저장소끼리는 묶을 수 없음	라이브러리 쪽 해시 방식 확인
CI·배포 스크립트	해시를 40자로 가정한 정규식·검사가 깨짐	길이 대신 형식 확인으로 수정
기존 저장소 변환	모든 해시가 바뀌어 서명·커밋 링크가 끊김	당장 변환할 이유 없음

샤콘도 GitHub에 SHA-256 저장소를 올릴 수 없는 문제가 3.0이 늦어지는 가장 큰 이유일 것이라고 봤습니다. LWN에 따르면 GitHub 개발자 brian m. carlson은 이 문제에 대한 소식이 곧 나온다고 답했고, libgit2는 8월부터 SHA-256 지원을 기본으로 켰습니다.

5. 지금 할 일: 없다, 시험해 보려면 이렇게

출처: LWN 기사 갈무리(공식 문서 밖 일정)

반응형

Git 2.56은 9월 28일 정식 공개됐지만 기본 해시는 그대로입니다. LWN이 전한 계획대로라면 Git 3.0은 2027년 4월에 나오고, 이 날짜는 아직 Git 공식 문서에 없습니다. 그러니 기존 프로젝트를 바꾸거나 서두를 일은 없습니다.

SHA-256 시험 저장소 만들기 (Git 2.29 이상)

# 1) 테스트용 SHA-256 저장소 만들기 (기존 저장소는 건드리지 않음)
git init --object-format=sha256 sha256-test
cd sha256-test

# 2) 이 저장소가 어떤 해시를 쓰는지 확인
git rev-parse --show-object-format   # sha256

# 3) 기존 저장소의 방식 확인
cd ~/내프로젝트 && git rev-parse --show-object-format   # 대부분 sha1

제가 macOS 기본 Git 2.50.1에서 직접 돌려 보니 커밋 해시가 64자로 나왔고, 기존 저장소는 sha1로 표시됐습니다. 3.0이 나온 뒤에도 SHA-1 저장소가 꼭 필요하면 만들 때 형식을 지정하면 됩니다.

3.0 이후 SHA-1 새 저장소가 필요할 때

# Git 3.0 이후에도 SHA-1 새 저장소가 꼭 필요할 때
git init --object-format=sha1 my-repo

제 판단으로는 지금 손볼 만한 건 하나뿐입니다. 사내 CI나 배포 스크립트에 "해시는 40자"라는 가정이 들어 있다면, 언젠가 깨질 자리라고 메모해 두세요.

Q. Git 3.0은 언제 나오나요?

Git 공식 문서에는 정해진 출시일이 없습니다. Kernel Recipes 발표를 전한 LWN에 따르면 2027년 4월 2.99 장기지원판과 함께 3.0을 내는 계획입니다.

Q. 기존 SHA-1 저장소도 바꿔야 하나요?

아닙니다. 기본값 변경은 새로 만드는 저장소에만 해당하고, 공식 문서는 SHA-1 형식을 폐기할 계획이 없다고 밝혔습니다.

Q. 지금 SHA-256 저장소를 GitHub에 올릴 수 있나요?

샤콘의 글 기준으로는 아직 push할 수 없습니다. GitHub의 공식 지원 발표는 이 글을 쓰는 시점에 확인하지 못했습니다.

Q. 왜 반대하는 사람이 있나요?

충돌 공격은 현실적 위협이 낮은데 저장소가 두 형식으로 갈라지는 비용이 크다는 이유입니다. 반대로 공격 비용이 계속 떨어지니 미리 바꿔야 한다는 의견도 있습니다.

3줄 핵심 요약

1. Git 3.0에서 새 저장소 기본 해시가 SHA-256으로 바뀔 예정이지만, 공식 출시일은 없고 SHA-1 폐기 계획도 없다.
2. 2027년 4월 3.0 출시는 LWN이 전한 계획으로, 공식 문서에는 아직 없다. 바뀌면 push·서브모듈·40자 해시 도구가 걸릴 수 있다.
3. 지금 할 일은 없다. git init --object-format=sha256으로 시험해 보고, 40자 가정 스크립트만 메모해 두자.

마치며

큰 버전 번호가 붙은 변화일수록 소문이 먼저 달립니다. 지금은 내 CI 스크립트에서 해시 길이를 40으로 박아 둔 곳이 있는지 한 번 검색해 보는 것으로 충분합니다.

NEXT READ

이어서 읽어 볼 글

01  받은 저장소를 AI 에이전트로 열기 전에 · Git 설정 보안

02  코딩 에이전트에게 권한을 얼마나 줄까 · 개발 도구 안전

#Git,#Git3,#SHA256,#깃,#GitHub,#버전관리,#reftable,#개발도구,#보안,#코드노트