▲

Git의 다음 10년을 위한 진화

 (lwn.net)
2P by GN⁺ 12시간전 | ★ favorite | 댓글 1개
  • 전 세계 개발자들이 사용하는 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 현대화와 사용성 향상이 진행 중임을 강조함
▲
GN⁺ 12시간전  [-]
Hacker News 의견들

  • Git은 정말 아름다운 소프트웨어이지만, 프로그래머 중심의 복잡함을 그대로 드러내는 면이 있음
    비개발 직군에게 Git을 가르쳐본 적이 있는데, 그들이 기능의 미묘한 강력함을 완전히 활용하지는 못했음
    Learn Git Branching 같은 사이트는 훌륭한 학습 리소스임. 이런 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
답변달기