최종 업데이트: 2026-06-29

Git 저장소 클론 크기

git 저장소의 클론 크기는 워킹 트리와 팩 히스토리 두 부분의 합입니다. 워킹 트리는 현재 HEAD에서 추적되는 파일 전체이고, 팩 히스토리는 .git/objects 디렉터리에 저장된 모든 커밋과 변경 이력입니다. CI/CD 파이프라인 최적화, 대역폭 계획, 모노레포 관리에서 이 두 구성 요소를 구분하는 것이 중요합니다.

추정 공식

여기서 $N$은 커밋 수, $C$는 커밋당 평균 변경량(바이트), $r$은 팩 압축률(0~1), $W$는 워킹 트리 크기, $H$는 팩 히스토리 크기, $T$는 전체 클론 크기입니다.

계산 예시. 워킹 트리 100 MB, 커밋 1,000개, 커밋당 평균 변경량 50 kB, 압축률 30 %인 저장소:

이 경우 히스토리가 전체 클론 크기의 약 13 %를 차지하며, 이는 비교적 젊은 저장소의 전형적인 비율입니다.

git 팩파일 구조

git은 객체를 느슨한(loose) 형태로 먼저 저장한 뒤, 주기적으로 git gc를 실행해 팩파일(.pack)로 묶습니다. 팩파일 안에서 git은 비슷한 내용을 가진 객체 사이에 델타 인코딩을 적용해 중복을 제거합니다. 예를 들어 1,000줄짜리 파일에서 한 줄만 바꾼 커밋은 전체 파일을 다시 저장하는 대신 이전 객체에 대한 변경 부분만 저장합니다. 이 과정에 zlib 압축이 추가로 적용되므로, 최종 팩파일 크기는 원시 변경량의 합보다 훨씬 작아집니다.

압축률은 저장소 특성에 따라 크게 달라집니다.

바이너리 파일(PNG, 컴파일된 아티팩트, 동영상)은 이미 압축되어 있어 git의 델타 인코딩이 거의 효과를 발휘하지 못합니다. 이런 파일은 Git LFS(대용량 파일 저장소)로 분리 관리하는 것이 일반적입니다.

워킹 트리와 .git 디렉터리 크기 측정

실제 값을 계산기에 입력하려면 아래 명령을 사용합니다.

# 워킹 트리 크기 (.git 제외)
du -sh --exclude=.git .

# 히스토리 포함 전체 .git 크기
du -sh .git

# 객체별 상세 정보
git count-objects -vH

# 커밋 수
git rev-list --count HEAD

git count-objects -vH의 출력에서 size-pack 항목이 팩파일의 실제 디스크 사용량입니다. 이 값을 히스토리 크기 추정값과 비교하면 모델의 정확도를 검증할 수 있습니다.

저장소 크기가 커지는 주요 원인

히스토리 크기는 커밋 수에 비례하지 않을 때가 있습니다. 크기를 불균형하게 키우는 주요 원인은 다음과 같습니다.

• 대용량 파일을 실수로 커밋한 경우. 컴파일된 바이너리, 데이터셋, 미디어 파일이 히스토리에 남아 있으면 해당 커밋부터 저장소 전체가 비대해집니다. git filter-repo로 히스토리를 다시 작성해야 완전히 제거됩니다.
• 빈번한 바이너리 변경. 로고나 다이어그램처럼 규칙적으로 갱신되는 바이너리 파일은 매 커밋마다 새 객체를 생성합니다.
• 머지 커밋과 리베이스. 리베이스가 많은 워크플로에서는 커밋이 새 해시로 재작성되므로, 중복 객체가 생기기 전에 git gc가 실행되지 않으면 일시적으로 크기가 늘어납니다.
• 장수 저장소. 기여자 수와 수명이 늘어날수록 워킹 트리 크기에 비해 히스토리가 훨씬 빠르게 불어납니다.

클론 크기 최소화 전략

얕은 클론 활용. git clone --depth N은 최신 N개 커밋만 내려받습니다. CI 빌드처럼 전체 히스토리가 필요 없는 환경에서는 --depth 1만으로 클론 크기를 워킹 트리에 가깝게 줄일 수 있습니다.

부분 클론(--filter=blob:none). git clone --filter=blob:none은 커밋 그래프는 모두 받지만 파일 내용(blob)을 필요할 때만 내려받습니다. 대규모 모노레포에서 일부 패키지만 작업할 때 유용합니다.

Git LFS 도입. 대용량 바이너리 파일을 외부 저장소로 분리하면 메인 저장소의 팩파일에서 해당 파일의 이진 내용이 사라집니다. 이미 히스토리에 들어간 파일은 git lfs migrate import로 소급 적용할 수 있습니다.

정기적인 git gc. 느슨한 객체를 팩파일로 묶고 도달 불가능한 객체를 정리합니다. 서버 측에서는 자동으로 실행되지만, 로컬에서 크기를 점검할 때는 수동으로 실행하는 것이 좋습니다.

관련 계산기

클론 후 저장소를 배포하는 상황이라면 데이터 전송 시간 계산기를 사용해 전송 시간을 추정해 보십시오. 팩파일에 적용되는 압축 원리를 더 자세히 알고 싶다면 압축률 계산를 참고하십시오. Base64 인코딩이 저장소 크기에 미치는 영향을 확인하려면 Base64 인코딩 오버헤드 계산를 활용하십시오.