Git을 데이터베이스로 사용하는 패키지 관리자들, 결국 실패한다

• 여러 패키지 관리자들이 버전 관리와 협업의 편리함 때문에 Git을 데이터베이스처럼 사용했지만, 규모가 커질수록 성능과 유지보수 문제에 부딪힘
• Cargo, Homebrew, CocoaPods 등은 Git 인덱스의 크기 증가와 느린 업데이트 속도, CI 환경의 비효율로 인해 결국 HTTP 기반 인덱스나 CDN으로 전환
• vcpkg는 여전히 Git 트리 해시를 기반으로 동작하며, 얕은 클론(shallow clone) 환경에서 빌드 실패와 복잡한 우회 방법이 발생
• Go 모듈 시스템은 GOPROXY와 체크섬 데이터베이스(sumdb) 를 도입해 Git 의존성을 제거하고 보안성과 속도를 개선
• Git은 코드 협업에는 탁월하지만, 패키지 메타데이터 질의나 대규모 레지스트리 관리에는 부적합하다는 점이 반복적으로 드러남

Git을 데이터베이스로 사용하는 시도의 반복적 실패

• Git은 버전 이력, 분산 구조, 무료 호스팅 등의 장점으로 매력적이지만, 데이터베이스로 사용하면 확장성 한계에 부딪힘
• 여러 패키지 관리자가 Git을 인덱스로 채택했으나, 시간이 지나며 성능 저하와 인프라 부담이 심화됨

Cargo

• crates.io 인덱스는 Git 저장소로 시작했으며, 모든 클라이언트가 전체 복제(clone)를 수행
  • 저장소가 커지면서 delta resolution 단계에서 libgit2의 성능 병목이 발생
  • CI 환경에서는 매 빌드마다 전체 인덱스를 다운로드해 낭비 심각
• RFC 2789를 통해 sparse HTTP 프로토콜이 도입되어 필요한 메타데이터만 HTTPS로 가져오도록 개선
  • 2025년 4월 기준, 요청의 99%가 sparse 모드 사용
  • Git 인덱스는 여전히 존재하지만 대부분의 사용자는 접근하지 않음

Homebrew

• GitHub은 Homebrew에 얕은 클론 사용 중단을 요청, 업데이트가 “매우 비싼 연산”으로 지적됨
  • homebrew-core의 .git 폴더는 1GB에 육박, 업데이트 시 delta resolution으로 지연 발생
• 2023년 2월 Homebrew 4.0.0에서 tap 업데이트를 JSON 다운로드 방식으로 전환
  • Git fetch 제거로 업데이트 속도 향상, 자동 업데이트 주기도 5분에서 24시간으로 변경

CocoaPods

• iOS/macOS용 패키지 관리자 CocoaPods는 수십만 개의 podspec으로 구성된 Specs 저장소가 지나치게 커짐
  • 클론 및 업데이트에 수분 소요, CI 시간 대부분이 Git 연산에 소비
• GitHub은 CPU rate limit을 적용, shallow clone이 서버 부하의 원인으로 지목
• 팀은 자동 fetch 중단, 풀 클론 전환, 저장소 샤딩 등 임시 조치 시행
• 1.8 버전부터 CDN 기반 HTTP 배포로 전환, 사용자 디스크 공간 약 1GB 절약, 설치 속도 대폭 향상

Nixpkgs

• Nix는 클라이언트 측에서 이미 tarball 기반 채널을 사용해 Git 복제를 피함
  • 패키지 표현식은 S3와 CDN에서 HTTP로 제공
• 그러나 GitHub의 인프라가 83GB 규모의 저장소와 20,000개 포크로 인해 부담
  • 2025년 11월, GitHub은 복제 간 합의 실패 및 유지보수 작업 오류를 보고
  • 로컬 클론은 2.5GB지만, 포크 네트워크 전체가 GitHub 저장 공간을 압박

vcpkg

• Microsoft의 C++ 패키지 관리자 vcpkg는 Git 트리 해시로 버전 관리
  • builtin-baseline을 통해 특정 커밋 시점의 포트를 재현하려면 전체 히스토리가 필요
• 얕은 클론 환경(GitHub Actions, DevContainers) 에서는 빌드 실패 발생
  • 해결책으로 fetch-depth: 0 설정 필요, 전체 히스토리 다운로드 요구
• Git 트리 해시 구조상 커밋 추적 불가, 구조적 한계로 인한 수정 불가능
• 여전히 Git 저장소 기반 레지스트리만 지원, HTTP나 CDN 대안 없음

Go 모듈 시스템

• Grab 엔지니어링 팀은 모듈 프록시 도입 후 go get 시간이 18분 → 12초로 단축
• 기존 방식은 각 의존성의 저장소 전체를 클론해야 go.mod를 읽을 수 있었음
• Go 팀은 VCS 도구 의존성과 보안 취약점을 우려
• Go 1.13부터 GOPROXY가 기본, 모듈 소스와 go.mod를 HTTP로 제공
  • sumdb(체크섬 데이터베이스) 로 모듈 무결성과 영속성 보장

Git을 데이터베이스로 사용할 때의 일반적 문제

• Git 기반 위키(Gollum) 는 대규모 저장소에서 디렉터리 탐색과 페이지 로딩이 느려짐
  • GitLab은 Gollum 사용 중단 계획
• Git 기반 CMS(Decap) 는 GitHub API 요청 한도(5,000회)에 걸림
  • 약 10,000개 항목 이상에서 성능 저하, 빈 캐시 상태의 신규 사용자는 요청 폭주
• GitOps 도구(ArgoCD) 는 저장소 클론 시 디스크 공간 초과 문제 발생
  • 단일 커밋이 전체 캐시를 무효화, 대형 모노레포는 별도 스케일링 필요

Git이 데이터베이스로 부적합한 구조적 이유

• 디렉터리 한계: 파일 수가 많아질수록 느려짐
  • CocoaPods는 16,000개 디렉터리로 인해 거대한 트리 객체 생성, 해시 기반 샤딩으로 해결
• 대소문자 구분 문제: Git은 구분하지만 macOS·Windows는 비구분
  • Azure DevOps는 충돌 방지를 위해 서버 측 차단 기능 추가
• 경로 길이 제한: Windows의 260자 제한으로 git status 오류 발생
• 데이터베이스 기능 부재:
  • CHECK/UNIQUE 제약, 잠금, 인덱스, 마이그레이션 기능 모두 없음
  • 각 패키지 관리자가 자체 검증·색인 시스템을 구축해야 함

결론

• Git은 소스 코드 협업에는 탁월하지만, 패키지 메타데이터 질의나 대규모 레지스트리 관리에는 부적합
• 대부분의 패키지 관리자는 결국 HTTP 기반 인덱스나 데이터베이스로 전환
• Git의 장점(버전 이력, PR 워크플로)은 매력적이지만, 데이터베이스 대체로는 실패
• 새로운 패키지 관리자를 설계할 때 Git 인덱스가 매력적으로 보이더라도, Cargo·Homebrew·CocoaPods·vcpkg·Go의 사례처럼 동일한 한계에 도달함