"3바이트 고쳤는데 17KB 늘어남"… 깃(Git) 커밋 1개의 실제 용량 실험

요약 개발자들이 매일 습관처럼 누르는 깃(Git) 커밋 명령어 한 번이 실제로 디스크 용량을 얼마나 차지할지 직접 실험해 본 결과가 개발자 커뮤니티에서 눈길을 끌었습니다. 글쓴이는 팩파일(packfile)로 묶이지 않은 순수 '루즈 오브젝트(loose objects)' 상태에서 다양한 조건의 커밋 용량을 측정했습니다. 우선 아무것도 없는 빈 저장소를 생성(`git init`)했을 때 이미 기본 설정과 디렉터리 구조 등으로 인해 약 64KB의 용량을 차지했습니다. 여기에 5개 디렉터리에 걸쳐 총 250개의 아주 작은 텍스트 파일을 추가하고 최초 커밋을 하자 디스크 사용량이 약 47KB 늘어났습니다. 흥미로운 점은 그 이후 단 3바이트짜리 수정 사항('foo'를 'bar'로 변경)을 반영해 커밋했을 때 발생했습니다. 실제 코드 변경량은 3바이트에 불과했지만, `.git` 디렉터리의 용량은 무려 약 17KB나 증가했습니다. 내부 오브젝트를 조사해 보니 변경된 파일 내용 자체뿐만 아니라 수정된 커밋 객체, 해당 디렉터리의 트리(하위 파일 50개 목록 포함), 루트 디렉터리의 트리 등 총 4개의 새로운 오브젝트가 생성되었기 때문이었습니다. 반면 단 하나의 파일만 존재하는 단순한 저장소에서는 동일한 3바이트 수정 커밋이 약 8.7KB만 늘어났습니다. 반대로 대용량 파일을 다룰 때는 zlib 압축 덕분에 커밋 효율이 극대화되었습니다. 580KB 크기의 바이너리 파일(`librewolf`)을 커밋했을 때는 약 298KB만 증가했고, 리눅스 커널 소스에서 가져온 약 16.4MB 크기의 거대한 텍스트 헤더 파일은 커밋 시 저장소 용량이 단 1.6MB밖에 늘어나지 않았습니다. 아주 미세한 변경 사항에는 트리 구조 관리 등으로 인한 수 KB 수준의 고정 오버헤드가 발생하지만, 파일 크기가 커질수록 원본의 10~50% 수준으로 압축 저장되어 깃의 데이터 관리 효율이 매우 뛰어나다는 점을 잘 보여줍니다.