# Git의 다음 10년을 위한 진화

> Clean Markdown view of GeekNews topic #26734. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=26734](https://news.hada.io/topic?id=26734)
- GeekNews Markdown: [https://news.hada.io/topic/26734.md](https://news.hada.io/topic/26734.md)
- Type: GN+
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2026-02-16T20:10:59+09:00
- Updated: 2026-02-16T20:10:59+09:00
- Original source: [lwn.net](https://lwn.net/SubscriberLink/1057561/bddc1e61152fadf6/)
- Points: 21
- Comments: 1

## Summary

Git은 오랫동안 **“완성된 도구”처럼** 보였습니다. 그런데 내부를 들여다보면, SHA-1에서 SHA-256으로 **해시 알고리듬을 교체**하고, 참조 저장 방식을 통째로 바꿔 **Reftable**을 도입하며, 객체 데이터베이스까지 손보는 중입니다. 말 그대로 **날아가면서 엔진을 갈아끼우고 있는 셈**입니다.  
  
SHA-256 전환과 Reftable 도입은 단순한 기능 추가가 아니라, Git이 앞으로도 **대형 저장소와 현대적 워크플로를 감당하겠다**는 선언에 가깝습니다. 혁신이라기보다는 생존을 위한 진화입니다. 지난 10년을 지탱한 도구가, 다음 10년을 대비해 생태계를 깨지 않으면서도 조용히 미래를 준비하고 있습니다.

## Topic Body

- 전 세계 개발자들이 사용하는 **Git**이 향후 10년을 대비해 구조적 변화를 추진 중이며, **보안·확장성·사용성**을 중심으로 주요 개편이 진행되고 있음  
- 가장 눈에 띄는 변화는 **SHA-1에서 SHA-256으로의 전환**으로, 2030년까지 SHA-1 사용이 금지될 예정이지만 생태계 지원 부족으로 도입이 지연되고 있음  
- **Reftable** 도입을 통해 수백만 개의 참조를 효율적으로 관리하고, 파일시스템 제약과 동시성 문제를 해결하려는 시도가 진행 중임  
- 대용량 파일 처리 개선을 위해 **Large-object promisors**와 **플러그형 객체 데이터베이스**가 개발되고 있으며, Git 2.50 이후 버전에서 점진적으로 통합 중임  
- **Jujutsu**와 같은 신흥 버전관리 시스템의 영향을 받아, Git은 UI 단순화와 새로운 명령어 추가를 통해 현대적 워크플로를 지원하려 함  

---
### Git의 변화 필요성
- Git은 2005년 출시 이후 20년간 수백만 개의 저장소와 수많은 스크립트에 의존되는 핵심 도구로 자리함  
  - 그러나 **SHA-1 보안 취약성**, **대형 저장소 증가**, **CI 파이프라인 확산** 등 환경 변화로 구조적 한계가 드러남  
- SHA-1은 2017년 CWI와 Google의 **SHAttered 공격**으로 충돌 가능성이 입증됨  
  - GPU 연산력 증가로 인해 대형 조직이 해시 충돌을 계산할 수 있는 수준에 도달함  
- Git은 혁신적 재설계보다는 **점진적 진화**를 선택해야 하며, 기존 생태계와 호환성을 유지한 채 변화를 추진 중임  

### SHA-256 전환
- Git 2.29(2020년 10월)에서 **SHA-256 지원**이 추가되었으나, GitHub 등 주요 플랫폼이 미지원 상태  
  - Git, Dulwich, Forgejo는 완전 지원, GitLab·go-git·libgit2는 실험적 지원 단계  
- SHA-1은 단순 무결성 검증용으로 사용되지만, **서명·CI·스크립트** 등 생태계 전반이 충돌 저항성을 전제로 동작함  
- 정부 및 기업 규제에 따라 2030년까지 SHA-1 제거가 요구되며, **Git 3.0에서 SHA-256이 기본값**으로 전환 예정  
- 생태계 전환을 위해 사용자가 **도구 테스트 및 포지 지원 요청**을 통해 참여할 것을 권장함  

### Reftable 도입
- 기존 Git은 각 참조를 개별 파일로 저장하는 **loose reference 구조**를 사용  
  - 수천만 개의 참조를 가진 저장소에서는 비효율적이며, **파일시스템 대소문자 구분 문제**와 **동시성 불일치**가 발생  
- Reftable은 **이진 포맷 기반 테이블 구조**로, 원자적 업데이트와 효율적 참조 관리가 가능  
  - GitLab의 2천만 개 참조 저장소 사례에서 기존 packed-refs 파일은 2GB 재작성 필요  
- Git 3.0에서 Reftable이 기본 백엔드로 전환되며, **직접 파일 접근 대신 Git 명령어 사용**이 권장됨  

### 대용량 파일 처리 개선
- Git은 텍스트 파일 압축에는 효율적이지만, **바이너리 파일 수정 시 전체 객체 재생성**으로 비효율 발생  
  - GitLab 분석에 따르면 저장소 공간의 75%가 1MB 이상 바이너리 파일이 차지  
- **Large-object promisors** 기능은 대형 객체를 별도 원격 저장소에 보관해 CDN이나 S3 API로 전송 가능  
  - Git 2.50~2.52에서 프로토콜 구현 완료, 클라이언트 측 사용 가능 단계  
- **플러그형 객체 데이터베이스**는 바이너리 전용 저장 포맷을 도입해 증분 저장을 지원할 예정  
  - Git 2.53에서 통합 객체 데이터베이스 인터페이스 도입, 2.54에서 개념 증명(PoC) 예상  

### 사용자 인터페이스 개선
- Git 명령어는 복잡하고 일관성이 부족하다는 비판이 지속되어 왔으며, **Rust 기반 Jujutsu(JJ)** 가 대안으로 부상  
  - Jujutsu는 **히스토리 자동 재배치**, **충돌을 데이터로 처리**, **커밋을 초안처럼 다루는 방식**을 제공  
- Git은 기존 워크플로를 깨지 않으면서 Jujutsu의 장점을 일부 도입 중  
  - Git 2.54에서 **‘git history split’** , **‘git history reword’** 명령어 추가 예정  
  - 향후 더 많은 **히스토리 편집 서브커맨드**가 추가될 계획  
- Steinhardt는 Git이 경쟁을 통해 배우고 있으며, **UI 현대화와 사용성 향상**이 진행 중임을 강조함

## Comments



### Comment 51257

- Author: neo
- Created: 2026-02-16T20:10:59+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47018814) 
- Git은 정말 **아름다운 소프트웨어**이지만, 프로그래머 중심의 복잡함을 그대로 드러내는 면이 있음  
  비개발 직군에게 Git을 가르쳐본 적이 있는데, 그들이 기능의 **미묘한 강력함**을 완전히 활용하지는 못했음  
  [Learn Git Branching](https://learngitbranching.js.org/?locale=en_US) 같은 사이트는 훌륭한 학습 리소스임. 이런 UX가 Git의 기본 경험에 녹아 있으면 좋겠음 — 직관적인 기본값, 점진적 학습 흐름 같은 것들 말임  
  요즘은 Claude, Codex, OpenCode 같은 **에이전트 CLI**를 쓰면 이런 경험을 쉽게 제공할 수 있음. 하지만 Git 자체가 더 접근성 높은 추상화를 제공한다면 훨씬 쉬워질 것 같음
  - 문제는 Git이 복잡함을 드러내는 게 아니라, **잘못된 용어와 개념**, 그리고 엉망인 문서로 그 복잡함을 표현한다는 점임

- Git 3.0이 정말 기대되지만, 동시에 바로 **좌절할 준비**도 되어 있음 😅  
  `jj`는 Git 사용자들에게 큰 도움을 줬음. 더 **직관적인 VCS 프런트엔드**가 가능하다는 걸 보여줬기 때문임
  - 경쟁이 많을수록 생태계에는 **좋은 자극**이 생김

- GitLab에서 2GB짜리 packed-refs 파일을 몇 초마다 다시 쓰는 사례를 봤는데, “대체 왜 이런 일이 일어나는지” 이해가 안 됨  
  - 그리고 솔직히, 그런 상황을 Git이나 그 사람이 **신경 써야 할 이유**가 있는지도 모르겠음

- 대용량 파일을 외부에 저장하는 건 중앙집중형 모델로 가는 한 걸음처럼 보이지만, Git의 **초기 설계 철학**에는 어긋남  
  - 꼭 그렇진 않음. 그건 단지 **주소 지정 모델과 인터페이스**의 문제임. 중앙 저장소를 쓸 수도 있지만, IPFS 같은 분산 스토리지를 쓸 수도 있음  
  - 맞음. Git은 DVCS이지 범용 DVFS가 아님. 나는 문서 저장용으로 DVFS가 필요해서 직접 하나 만들었음. 간단하고 빠르며 목적에 맞게 잘 작동함

- SHA1에서 벗어나는 전환이 **너무 오래 걸리고 있음**  
  해시 함수는 처음부터 더 **모듈화된 구조**로 설계됐어야 했음

- Git은 커밋 단위로 **소프트웨어 라이선스 추적** 기능이 필요하다고 생각함  
  - 무슨 뜻인지는 완전히 이해 못했지만, 그건 Git이 할 일이 아님. Git은 **소스 코드 관리 시스템**일 뿐이고, 추가 기능은 git-annex 같은 **확장 도구**로 구현하는 게 맞음  
  - Git이 그런 기능을 가지면 오히려 나빠짐. 커밋에는 이미 임의의 데이터를 저장할 수 있으니, 필요한 메타데이터는 그냥 커밋에 넣고 별도 도구로 처리하면 됨  
  - LLM이 보조한 코드처럼 **트레일러**를 쓰면 됨  
    예: `Co-Authored-By: Whatever LLM`, `License: WTFPL`