최근 Simon Willison이 공개한 작은 도구 하나가 눈길을 끌었습니다. GitHub 웹 화면에서는 잘 보이지 않던 저장소 크기를 손쉽게 확인하게 해주는 GitHub Repo Size입니다.1 겉보기엔 단순한 기능이지만, 사실 GitHub Repo Size는 개발 속도와 CI 비용, 협업 효율까지 연결되는 꽤 중요한 신호입니다.
저장소가 얼마나 큰지 모르면 느려지는 이유도 파악하기 어렵습니다. 이번 글에서는 GitHub Repo Size를 확인하는 방법부터, 저장소가 커질 때 실제로 어떤 문제가 생기는지, 그리고 어떻게 관리해야 하는지 쉽게 정리해보겠습니다.
GitHub Repo Size를 왜 확인해야 할까
많은 개발자가 별생각 없이 git clone을 합니다. 그런데 저장소가 커지면 첫 복제부터 시간이 확 늘어납니다. 신규 팀원 온보딩은 느려지고, CI는 매번 새로 내려받느라 시간을 씁니다.
Dropbox 사례는 이 문제를 아주 현실적으로 보여줍니다. 그들의 모노레포는 한때 87GB까지 커졌고, 전체 클론에 1시간 이상 걸렸습니다. 이후 최적화를 거쳐 20GB 수준으로 줄였고, 클론 시간도 15분 이하로 단축됐습니다.2 저장소 크기 하나가 개발자 체감 속도를 바꿔버린 셈입니다.
즉, GitHub Repo Size는 단순한 숫자가 아니라 "이 저장소, 건강한가?"를 보여주는 체온계에 가깝습니다.
GitHub Repo Size 확인하는 가장 쉬운 방법
GitHub 기본 UI에서는 저장소 크기가 눈에 잘 드러나지 않습니다. 그래서 Simon Willison의 도구가 유용합니다. 저장소 주소나 owner/repo 형식을 넣으면 GitHub API에서 크기를 가져와 KB, MB, GB 단위로 보여줍니다.1
이 도구가 좋은 이유는 간단합니다. 설치가 필요 없고, 결과를 URL에 담아 다시 보거나 공유하기 쉽습니다.1 팀에서 "우리 레포 얼마나 커?"라는 질문이 나왔을 때 바로 확인하기 좋습니다.
조금 더 기술적으로 보면, GitHub의 API에는 저장소 크기 정보가 포함됩니다. 즉, 화면에 안 보일 뿐 데이터는 이미 있습니다. 이 점이 재미있습니다. 중요한 정보인데, 기본 화면보다 외부 도구가 더 친절하게 꺼내 보여주는 셈이니까요.
저장소가 커지는 이유는 생각보다 단순하지 않다
보통은 대용량 바이너리, 실수로 올린 의존성 폴더, 생성 파일을 원인으로 떠올립니다. 맞는 말이지만, 문제는 그보다 더 교묘할 때도 있습니다.
Dropbox는 저장소 증가 원인이 단순 파일 개수보다 Git의 압축 방식에 있었다고 설명했습니다.2 Git은 비슷한 파일끼리 차이점만 저장해 용량을 줄이는데, 특정 디렉터리 구조에서는 이 비교가 비효율적으로 이뤄질 수 있습니다. 즉, 파일이 "많아서"가 아니라 "압축이 비효율적이어서" 저장소가 커질 수도 있다는 뜻입니다.
여기에 GitHub 권장 기준도 함께 봐야 합니다. 일반적으로 저장소는 1GB 이하를 권장하고, 5GB를 넘기면 관리 부담이 커질 수 있으며, 개별 파일은 50MB부터 경고, 100MB 초과는 업로드가 차단됩니다.3 한마디로 GitHub는 코드 협업 도구이지, 대용량 파일 창고가 아닙니다.
GitHub 저장소 용량 줄이는 현실적인 방법
가장 먼저 해야 할 일은 큰 파일을 코드 저장소와 분리하는 것입니다. 미디어, 데이터셋, 빌드 산출물은 객체 스토리지나 별도 저장소가 더 잘 맞습니다.3
정말 버전 관리가 필요한 대용량 파일이라면 Git LFS를 검토할 만합니다. 실제 파일 대신 포인터를 관리하므로 메인 저장소를 덜 무겁게 만들 수 있습니다.3 또한 작업 목적에 따라 얕은 클론이나 단일 브랜치 클론을 쓰면 불필요한 이력까지 모두 내려받지 않아도 됩니다.4
운영 측면에서는 주기적으로 저장소 크기를 확인하고, 갑자기 증가하는 시점을 체크하는 습관이 중요합니다. Repo Size는 "문제가 생긴 뒤" 보는 지표가 아니라, "문제가 커지기 전" 보는 지표에 더 가깝습니다.
시사점
GitHub Repo Size는 작은 편의 기능처럼 보여도, 실제로는 개발 생산성과 저장소 운영 상태를 보여주는 핵심 지표입니다. 특히 모노레포, CI 사용량이 많은 팀, 바이너리 파일이 자주 섞이는 프로젝트라면 더 그렇습니다.
실무적으로는 아주 간단합니다. 먼저 저장소 크기를 확인하세요. 그리고 크기보다 더 중요한 "왜 커졌는지"를 보세요. 큰 파일, 잘못된 저장 방식, 불필요한 히스토리, 압축 비효율까지 함께 봐야 진짜 원인이 보입니다. 저장소는 코드를 담는 상자이지만, 너무 무거워지면 팀의 발목을 잡습니다.
참고
2Reducing our monorepo size to improve developer velocity
3Optimizing GitHub Storage: Beyond Code for Enhanced Git Repo Analytics
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.