거대한 모노레포에서 git이 느려질 때, Ted Nyman의 고성능 Git 가이드

git이 느려질 수 있다는 걸 처음 깨달은 날

많은 분들이 git을 "빠른 도구"라고 생각하고 계실 거예요. 실제로 작은 프로젝트에서는 git status도, git log도 거의 즉시 떨어지니까요. 그런데 회사 코드베이스가 점점 커져서 파일 수십만 개, 커밋 수백만 개가 되면 이야기가 달라집니다. git status 하나에 30초씩 걸리고, git fetch는 커피 한 잔 마실 시간이 되거든요. Ted Nyman의 gitperf.com은 바로 이런 "거대한 git 저장소를 어떻게 빠르게 다룰 것인가"를 정리한 가이드예요.

Ted Nyman은 GitHub 출신으로 git 내부 동작에 깊이 관여한 사람이라 이 주제에서 신뢰할 만한 출처입니다. 가이드의 톤은 "아무거나 다 켜라"가 아니라 "네 저장소에 맞는 옵션을 골라 켜라"에 가까워요.

git이 왜 느려지는지부터

속도 이야기 전에 왜 느려지는지를 알아야 해요. git은 워킹 디렉터리의 변경을 감지할 때 기본적으로 모든 추적 파일의 메타데이터(stat)를 훑어요. 파일이 5천 개면 별 문제 없지만 50만 개면 그 자체로 디스크 I/O 폭탄이 되거든요. 또 git log나 git blame은 커밋 그래프를 따라가며 객체를 하나씩 풀어보는데, 커밋이 백만 개를 넘어가면 그래프 탐색 비용이 무시 못 할 수준이 됩니다. 마지막으로 git clone이나 git fetch는 네트워크로 객체를 받아오는데, 히스토리가 길수록 받을 게 많아져요.

핵심 옵션들

가이드에서 다루는 대표적인 가속 옵션 몇 가지를 풀어볼게요.

첫 번째는 fsmonitor입니다. 이게 뭐냐면, OS가 제공하는 파일 변경 감지 기능(macOS의 FSEvents, 리눅스의 inotify, 윈도우의 ReadDirectoryChangesW)을 git이 빌려 쓰는 거예요. 매번 모든 파일을 stat 하는 대신 "마지막으로 본 이후 바뀐 파일이 뭐냐"만 OS에 물어보는 거죠. git config core.fsmonitor true 한 줄이면 켜지는데, 큰 저장소에서는 git status가 30초에서 1초 미만으로 줄어드는 경험을 할 수 있어요.

두 번째는 commit-graph 파일이에요. git은 원래 커밋의 부모 관계를 객체에서 그때그때 읽는데, commit-graph는 이 관계를 미리 계산해서 한 파일에 캐시해둬요. git config fetch.writeCommitGraph true와 git commit-graph write --reachable을 걸어두면 git log --graph나 git merge-base 같은 명령이 훨씬 빨라집니다. bloom filter까지 같이 켜면 git log -- path/처럼 경로 필터가 들어간 명령에서도 큰 차이가 나요. bloom filter는 "이 커밋이 이 경로를 건드렸을 가능성이 있냐?"를 빠르게 가려내는 자료구조거든요.

세 번째는 partial clone과 sparse checkout이에요. git clone --filter=blob:none을 쓰면 처음 클론할 때 파일 내용(blob)을 안 받고 필요할 때만 가져옵니다. 거기에 sparse checkout으로 "내가 작업할 디렉터리만 워킹 디렉터리에 풀어라"라고 하면 디스크에 깔리는 파일 수 자체가 확 줄어들어요. 모노레포 환경에서 특히 효과가 큽니다.

네 번째는 maintenance예요. git maintenance start를 한 번 실행해두면 백그라운드에서 주기적으로 prefetch, repack, commit-graph 갱신을 알아서 해줘요. 즉 여러분이 git fetch를 칠 때 이미 객체 대부분이 받아져 있는 상태가 되니까 체감 속도가 빨라집니다.

Microsoft·GitHub의 기여

이 분야의 기술 대부분은 사실 Microsoft Windows 저장소(약 300GB, 파일 350만 개)와 Google·Meta의 거대 모노레포 사례에서 나왔어요. 처음엔 Microsoft가 VFS for Git, Scalar 같은 별도 도구로 만들었다가 점차 git 본체에 흡수됐죠. 그래서 최신 git을 쓰면(2.38 이상 권장) 이 가속 기능들을 표준으로 누릴 수 있어요. Meta는 다른 길로 가서 Sapling이라는 자체 VCS를 오픈소스로 풀었는데, git과 호환되면서도 거대 저장소에 더 친화적입니다. Google은 내부적으로 Piper라는 별도 시스템을 쓰고요.

한국 개발자에게 주는 시사점

팀의 저장소가 그렇게 안 크다면 이 옵션들을 다 켤 필요는 없어요. 하지만 다음 신호가 보인다면 가이드를 정독해볼 가치가 있습니다. git status가 1초를 넘기 시작했을 때, CI 빌드의 체크아웃 단계가 1분 이상 차지할 때, 새 멤버가 첫 클론에 30분씩 쓰고 있을 때예요. 특히 iOS·안드로이드 앱처럼 리소스 파일이 많은 프로젝트, AI 프로젝트처럼 모델 가중치를 git에 넣어둔 경우, 그리고 여러 서비스를 모노레포로 묶은 백엔드에서 효과가 즉각적입니다.

실무 적용 순서는 이렇게 추천드려요. 먼저 git을 최신 버전으로 올리고, fsmonitor와 commit-graph를 켜보세요. 이 두 가지만으로도 일상 명령의 체감이 달라집니다. 그 다음에 CI 환경에 partial clone을 적용해서 빌드 시간을 줄이고, 모노레포라면 개발자별로 sparse checkout 프로필을 정의해보는 거예요. 큰 바이너리는 git이 잘 못 다루는 영역이라 Git LFS로 분리하는 것도 같이 고려해야 합니다.

마무리

git은 충분히 빠르지만, 저장소가 커지면 "기본값"으로는 한계가 있어요. fsmonitor·commit-graph·partial clone 같은 옵션은 이미 표준에 들어와 있고, 켜는 데 몇 분이면 됩니다. 여러분 팀 저장소에서 가장 느린 git 명령은 뭔가요? 그걸 댓글로 공유해주시면 가속할 만한 옵션을 같이 골라봐요.