개발 속도 향상을 위한 모노레포 크기 줄이기 (새 탭에서 열림)
Dropbox는 87GB에 달하던 서버 모노레포 크기를 20GB로 약 77% 줄여 개발자 속도와 CI 효율성을 획기적으로 개선했습니다. 이 과정에서 Git의 기본 델타 압축 알고리즘이 특정 디렉토리 구조에서 비효율적으로 작동한다는 점을 발견했으며, GitHub 팀과 협력하여 최적화된 리팩(Repack) 설정을 적용해 저장소 용량 한계 문제를 해결했습니다. 결과적으로 1시간 이상 걸리던 클론 시간을 15분 미만으로 단축하며 운영상의 리스크를 제거했습니다. ### 대규모 모노레포 성장이 유발하는 운영 병목 - 저장소 크기가 87GB를 넘어서면서 초기 개발 환경 구축을 위한 클론 시간이 1시간을 초과했고, 이는 매번 신규 클론을 수행하는 CI(지속적 통합) 파이프라인의 성능 저하로 이어졌습니다. - 코드 데이터는 매일 20~60MB씩 증가하며 GitHub Enterprise Cloud의 하드 리밋인 100GB에 근접해 가고 있었으며, 이는 단순한 코드 양의 증가라기보다 저장 방식의 구조적 결함에 의한 현상이었습니다. - 내부 동기화 시스템의 타임아웃 발생 빈도가 높아지는 등 저장소 크기 자체가 엔지니어링 루프 전체를 느리게 만드는 핵심 원인이 되었습니다. ### Git 델타 압축 알고리즘과 디렉토리 구조의 충돌 - Git은 파일 간의 차이점(Delta)만 저장하여 용량을 줄이는데, 비교 대상 파일을 선정할 때 파일 경로의 '마지막 16자'만을 참조하는 휴리스틱 방식을 사용합니다. - Dropbox의 다국어(i18n) 파일 구조는 `i18n/[언어코드]/LC_MESSAGES/[파일명].po` 형태였는데, 언어 코드가 경로 중간에 있어 Git은 서로 다른 언어의 동일 파일명을 가진 파일들을 비교 대상으로 묶었습니다. - 내용이 전혀 다른 언어 간의 파일을 비교하다 보니 압축 효율이 극도로 낮아졌고, 아주 작은 번역 수정에도 불필요하게 큰 팩(Pack) 파일이 생성되는 결과로 이어졌습니다. ### GitHub 서버 측 리팩 최적화를 통한 문제 해결 - 실험적 플래그인 `--path-walk`를 사용하면 파일 경로 전체를 탐색해 압축 효율을 극대화할 수 있음을 로컬 테스트로 확인했으나, 이는 GitHub 서버의 비트맵 및 델타 아일랜드 최적화 기능과 호환되지 않았습니다. - 로컬에서 최적화하여 푸시하더라도 GitHub 서버가 전송 시 자체 설정으로 다시 팩을 구성하기 때문에, GitHub 지원팀과 협력하여 서버 측 리팩 설정을 조정하는 방식을 택했습니다. - Git이 더 넓고 깊게 유사성을 검색할 수 있도록 `window`와 `depth` 매개변수를 각각 250으로 상향 조정한 공격적인 리팩을 수행하여, 데이터 손실 없이 저장소 크기를 20GB 수준으로 압축하는 데 성공했습니다. ### 대규모 저장소 관리를 위한 제언 - 모노레포의 크기가 비정상적으로 급증한다면 단순한 바이너리 파일 유입뿐만 아니라, Git의 델타 압축 메커니즘과 현재의 디렉토리 구조가 상충하고 있지는 않은지 점검해야 합니다. - 저장소 최적화는 클라이언트 단의 노력만으로는 한계가 있으며, 호스팅 서비스(GitHub 등)의 서버 측 리팩 설정과 인프라 호환성을 반드시 고려하여 전략을 수립해야 합니다.