87GB → 20GB, 드롭박스가 Git 저장소를 77% 줄인 방법 🗂️
개발자의 속도를 갉아먹는 '보이지 않는 적'
개발팀 생산성 이야기를 할 때 사람들은 대부분 코드 품질, 팀 협업, 배포 자동화를 먼저 꼽습니다. 그런데 실무에서 개발자들이 하루에도 수십 번 마주치는 병목이 하나 있어요.
바로 코드 저장소의 크기입니다.
드롭박스(Dropbox)가 최근 공식 기술 블로그를 통해 서버 모노레포를 87GB에서 20GB로 줄인 경험을 공개했는데요. 무려 77% 감소예요. 단순히 파일 몇 개 지운 이야기가 아닙니다. 깃(Git)의 내부 동작 원리와 저장소 구조 사이의 미묘한 불일치가 조용히 문제를 키우고 있었어요.
오늘은 이 사례를 통해 모노레포가 무엇인지, 왜 저장소 크기가 개발 속도에 직결되는지, 그리고 드롭박스가 어떻게 이 문제를 풀었는지 함께 살펴볼게요.
모노레포, 처음 들어보셨다면
모노레포(Monorepo)는 '단일 저장소'를 뜻합니다. 여러 서비스나 라이브러리를 하나의 깃 저장소에 모아서 관리하는 방식이에요.
반대 개념인 멀티레포(Multirepo)는 서비스마다 별도 저장소를 두는 방식입니다. 쉽게 비유하면, 멀티레포는 직원마다 개인 캐비닛이 따로 있는 구조이고, 모노레포는 모두가 하나의 큰 공용 서류함을 함께 쓰는 구조예요.
구글, 메타, 마이크로소프트 같은 대형 기업들도 모노레포를 씁니다. 국내에서는 토스, 쏘카, 한컴테크 등이 도입한 상태예요. 토스 프론트엔드 챕터는 하나의 모노레포에서 200개가 넘는 서비스를 관리하고 있을 정도입니다.
모노레포의 장점은 명확해요. 코드 재사용이 쉽고, 일관된 개발 환경을 유지할 수 있으며, CI/CD 설정을 통일할 수 있습니다. 여러 서비스 간 변경 사항을 한 번에 반영할 수 있다는 것도 큰 이점이에요.
그런데, 모노레포가 커지면 무슨 일이 생길까요
드롭박스의 서버 모노레포는 87GB까지 불어났습니다. 이 저장소를 처음 복사(클론)하는 데 걸리는 시간이 1시간 이상이었어요.
신규 입사자가 개발 환경을 셋업하면 첫날부터 기다리는 데만 한 시간을 써야 하는 셈이죠. 더 큰 문제는 CI 파이프라인이었어요. 코드 변경이 생길 때마다 저장소를 새로 복사해서 빌드를 시작하는 방식이었거든요. 87GB를 매번 클론하면 시간도 오래 걸리지만 타임아웃 오류도 잦아집니다.
국내에서도 비슷한 경험이 있었어요. 토스의 모노레포는 40GB를 훌쩍 넘기면서 CI 체크아웃 자체가 불가능한 수준에 이르렀다고 합니다. 이를 해결하기 위해 저장소 콘텐츠를 미리 도커 이미지로 구워두고, 변경된 부분만 새로 내려받는 방식을 도입했다고 해요.
저장소 크기가 커질수록 개발자들의 실제 코딩 시간보다 기다리는 시간이 길어집니다. 이건 단순한 불편함이 아니에요. 집중력이 끊기고 컨텍스트 스위칭 비용이 발생한다는 의미예요. 업무 흐름이 한 번 끊기면 다시 집중 상태로 돌아오는 데 평균 23분이 걸린다는 연구 결과도 있을 정도입니다.
범인은 예상치 못한 곳에 있었다
드롭박스 팀은 저장소 비대화의 원인을 찾기 시작했어요. 처음엔 용의자가 뻔해 보였습니다. 대용량 바이너리 파일, 실수로 커밋된 의존성 파일, 버전 관리할 필요 없는 생성 파일들이 쌓인 게 아닐까 의심했죠.
그런데 아니었어요.
진짜 원인은 깃의 압축 방식, 델타 압축(delta compression)에 있었습니다. 깃은 파일을 저장할 때 모든 버전을 통째로 저장하지 않고, 이전 버전과의 차이(diff)만 저장해서 공간을 아끼는 방식을 써요. 보통은 이 방식이 잘 작동합니다.
문제는 깃이 어떤 파일끼리 비교할지를 결정하는 기준에 있었어요. 깃은 기본적으로 파일 경로의 마지막 16글자를 기준으로 비슷한 파일을 묶어서 비교합니다.
드롭박스의 다국어 번역 파일(i18n) 구조가 여기서 문제를 일으켰어요. 파일 경로 중간에 언어 코드가 들어가 있어서, 경로 끝 16글자만 보면 한국어 파일과 일본어 파일이 같아 보이게 되는 거예요. 깃 입장에서는 전혀 다른 언어의 파일끼리 델타를 뽑으려고 하는 셈이죠.
당연히 한국어 파일과 일본어 파일 사이의 차이는 어마어마할 수밖에 없습니다. 번역 업데이트가 있을 때마다 비효율적인 대용량 팩 파일이 쌓여갔고, 저장소가 하루에 20~60MB씩, 때로는 150MB 이상씩 불어났던 거예요.
코드 자체에는 아무 문제가 없었어요. 저장소 디렉토리 구조와 깃의 내부 알고리즘 사이의 미묘한 불일치가 조용히 문제를 키워가고 있었던 겁니다.
해결 과정은 예상보다 복잡했다
원인을 파악한 팀은 해결책을 찾아 나섰습니다.
처음엔 --path-walk라는 실험적 깃 플래그를 시험했어요. 경로 끝 16글자가 아니라 디렉토리 전체 구조를 기준으로 파일을 묶는 방식입니다. 로컬에서 이 방식으로 저장소를 재압축(리팩)해봤더니 80GB대에서 20GB대로 줄었어요. 가설이 맞았다는 게 확인된 거죠.
그런데 여기서 또 문제가 생겼습니다.
깃허브(GitHub)가 서버 인프라 최적화를 위해 이 플래그를 지원하지 않는다는 거예요. 로컬에서 완벽하게 최적화한 저장소를 깃허브에 올려도, 실제 클론 시에는 깃허브 서버가 자기 방식대로 다시 패키징해서 전송하기 때문에 로컬 최적화가 의미가 없어집니다.
결국 드롭박스 팀은 깃허브 지원팀과 협력해서 해결책을 찾았어요. window와 depth 파라미터를 높게 설정해서 깃허브 서버에서 직접 저장소를 재압축하는 방법이었습니다. 이 두 파라미터는 깃이 파일 유사성을 얼마나 깊이 탐색하고, 델타를 몇 겹까지 허용할지를 결정해요.
저장소 복사본으로 테스트해봤더니 리팩에 약 9시간이 걸렸고, 결과는 84GB에서 20GB로 줄었습니다.
배포는 인프라 변경처럼 신중하게
저장소 리팩은 코드 내용에 영향을 미치지 않아요. 하지만 저장소의 물리적 구조가 바뀌기 때문에 모든 클론, 패치, 푸시 작업에 영향을 줄 수 있습니다.
드롭박스 팀은 이 작업을 마치 운영 인프라 변경처럼 다뤘어요. 먼저 테스트 복사본에서 리팩을 수행하고, 패치 시간과 푸시 성공률, API 응답 속도를 측정했습니다. 복사본은 78GB에서 18GB로 줄었고, 지연 시간 지표도 허용 범위 안에 들어왔어요.
실제 운영 저장소에는 깃허브가 일주일에 걸쳐 하루에 복사본 하나씩 순차적으로 적용했습니다. 문제가 생기면 롤백할 여유를 둔 채로요.
최종 결과는 명확했습니다. 저장소 크기 87GB에서 20GB로 감소, 클론 시간 1시간 이상에서 15분 이내로 단축, 깃허브 100GB 한도에서 안전한 여유까지 확보했어요.
국내 기업들은 어떻게 대응하고 있을까
모노레포 크기 문제는 드롭박스만의 이야기가 아닙니다.
토스는 저장소가 40GB를 넘어서면서 CI 체크아웃이 불가능한 상황에 이르렀고, 저장소 콘텐츠를 미리 도커 이미지로 구워두는 방식으로 해결했습니다. 변경된 부분만 새로 내려받도록 한 거예요.
한컴테크는 Turborepo를 도입한 후 빌드 시간이 획기적으로 단축되는 효과를 봤다고 합니다. flex 팀은 4년간 모노레포를 운영하다가 복잡한 패키지 의존관계로 인해 개발 속도와 제품 안정성이 위협받자, 아예 하나의 모노레포를 14개의 개별 레포지토리로 분리하는 대규모 전환을 1년에 걸쳐 진행했을 정도예요.
2025년 FEConf에서도 이 사례가 발표될 만큼 모노레포 규모 관리는 국내 개발 조직에서도 뜨거운 주제입니다. 모노레포가 항상 정답이 아니라는 점, 규모와 팀 특성에 따라 유연하게 전략을 바꿔야 한다는 점이 현장에서 계속 확인되고 있어요.
이 사례에서 우리가 배울 수 있는 것
드롭박스 사례는 개발 인프라를 운영할 때 세 가지 교훈을 줍니다.
첫째, 성장 원인이 항상 눈에 보이는 곳에 있지 않습니다. 대용량 파일이나 불필요한 의존성이 문제가 아닐 수 있어요. 저장소 디렉토리 구조와 도구의 내부 알고리즘 사이의 불일치가 원인일 수 있습니다. 도구는 항상 자체 가정을 내포하고 있고, 우리의 사용 패턴이 그 가정에서 벗어날 때 문제가 생겨요.
둘째, 일부 해결책은 플랫폼 제공자와 함께 풀어야 합니다. 로컬에서 원인을 파악하고 수정도 할 수 있었지만, 실제 클론과 패치는 깃허브 서버에서 이루어지기 때문에 서버 측 최적화 없이는 효과가 없었어요. 플랫폼 경계에서 생기는 문제는 협력 없이 혼자 해결하기 어렵습니다.
셋째, 저장소를 운영 인프라처럼 관리해야 합니다. 저장소는 단순한 파일 보관소가 아니에요. 개발자 생산성과 CI 신뢰성에 직결된 핵심 인프라입니다. 드롭박스는 이번 작업 이후 저장소 크기, 클론 시간, 성장 추이를 실시간으로 모니터링하는 내부 대시보드를 구축했어요.
저장소 건강 상태를 꾸준히 모니터링하고 이상을 조기에 발견하는 것. 빠르게 성장하는 개발 조직이 속도를 지키는 방법입니다.
마무리
모노레포 저장소 크기는 단순한 디스크 용량 문제가 아닙니다. 클론 시간, CI 신뢰성, 신규 개발자 온보딩, 반복 작업 속도 모두에 영향을 미치는 핵심 인프라 지표예요.
드롭박스 사례처럼 원인이 예상치 못한 곳에 있을 수 있고, 해결도 플랫폼 제공자와의 협력이 필요한 복잡한 문제일 수 있습니다. 저장소를 코드 보관 창고가 아니라 개발 조직의 핵심 인프라로 바라보는 시각이 필요한 시점입니다.