개발 속도 향상을 위해 모노레포 크기 줄이기

Dropbox의 서버 monorepo가 87GB까지 커지면서 초기 clone은 1시간 넘게 걸렸고, CI와 동기화 시스템도 같은 비용을 반복해서 치렀다. 결국 GitHub의 100GB 제한이 현실적인 위험이 되자, 저장량이 아니라 Git delta compression의 동작 방식이 문제라는 점을 찾아냈다.

원인은 i18n 파일 경로 구조였다. Git은 기본적으로 경로의 마지막 16자를 기준으로 유사 파일을 묶는데, Dropbox의 경로는 언어 코드가 앞쪽에 있어 서로 다른 언어 파일끼리 델타를 계산하는 경우가 많았고, 그 결과 translation 업데이트가 과도하게 큰 pack file을 만들었다.

로컬에서는 --path-walk 실험 플래그로 repack했을 때 저장소가 84GB → 20GB로 줄었지만, 이 방식은 GitHub의 서버 측 최적화와 호환되지 않았다. 대신 GitHub Support와 협업해 더 공격적인 window/depth 설정으로 서버에서 repack를 수행했고, 약 9시간에 걸쳐 동일한 수준의 압축 효과를 얻었다.

롤아웃은 프로덕션 인프라 변경처럼 다뤘다. 테스트 mirror에서 먼저 검증한 뒤, fetch latency, push success rate, API latency를 관찰했고, 이후 1주일에 걸쳐 replica를 하루 하나씩 점진적으로 적용했다. 최종적으로 저장소는 87GB → 20GB로 줄었고, clone 시간은 1시간 이상에서 15분 미만으로 단축됐다.

이 작업은 재발 방지 체계도 남겼다.

• i18n workflow를 Git의 packing 방식에 더 맞게 조정해 병적인 delta pairing을 줄였다.
• 저장소 크기, 성장 속도, fresh clone 시간, 저장공간 분포를 추적하는 recurring stats job을 만들었다.
• repo health를 서비스처럼 관리하는 기준을 세워, 성장 이상을 초기에 포착할 수 있게 했다.