프로젝트가 성장하고 팀원이 늘어날수록 개발자가 가장 먼저 느끼는 불편함은 아이러니하게도 도구의 무거움입니다. 처음 프로젝트를 시작했을 때는 git status나 git fetch가 순식간에 끝났지만, 어느 순간부터 명령어를 입력하고 커피 한 잔을 마시고 와야 결과가 나오는 상황을 경험하곤 합니다. 많은 개발자가 이를 단순히 ‘컴퓨터 사양 문제’나 ‘네트워크 탓’으로 돌리지만, 사실 이는 Git의 내부 동작 방식과 데이터 구조가 거대해짐에 따라 발생하는 전형적인 성능 저하 현상입니다.

Git은 분산 버전 관리 시스템으로서 모든 히스토리를 로컬에 저장하는 강력한 장점이 있지만, 파일 수가 수십만 개로 늘어나고 바이너리 파일이 쌓이기 시작하면 이 장점은 곧 치명적인 단점이 됩니다. 인덱스 파일이 비대해지고, 객체 그래프를 탐색하는 시간이 기하급수적으로 증가하며, 결국 개발자의 집중력을 흐트러뜨리는 ‘도구의 병목 현상’이 발생합니다. 이제는 단순히 Git을 사용하는 단계를 넘어, 어떻게 하면 Git을 ‘고성능’으로 유지하며 대규모 프로젝트를 운영할 수 있을지 고민해야 할 때입니다.

Git 성능 저하의 근본적인 원인: 왜 느려지는가?

Git의 성능 저하를 이해하려면 Git이 데이터를 어떻게 관리하는지 알아야 합니다. Git은 기본적으로 스냅샷 기반의 시스템입니다. 파일의 변경 사항을 저장할 때 델타 압축을 사용하지만, 파일의 개수가 너무 많아지면 Git이 현재 작업 디렉토리의 상태를 확인하기 위해 모든 파일을 스캔하는 과정에서 엄청난 I/O 부하가 발생합니다.

특히 다음과 같은 상황에서 성능 저하가 가속화됩니다.

• 거대한 바이너리 파일의 누적: 이미지, PDF, 컴파일된 라이브러리 등 텍스트가 아닌 파일은 Git의 델타 압축 효율을 떨어뜨리고 레포지토리 크기를 폭발적으로 증가시킵니다.
• 깊은 커밋 히스토리: 수만 개의 커밋이 쌓이면 브랜치 병합이나 로그 탐색 시 그래프 계산 비용이 증가합니다.
• 과도한 추적 파일: .gitignore 설정이 미흡하여 빌드 결과물이나 임시 파일이 인덱스에 포함될 경우, Git은 불필요한 변경 사항을 계속해서 계산해야 합니다.

성능을 극대화하는 기술적 구현 전략

고성능 Git 환경을 구축하기 위해서는 단순히 설정을 바꾸는 것을 넘어, Git이 데이터를 처리하는 방식을 최적화하는 전략적 접근이 필요합니다. 가장 먼저 고려해야 할 것은 ‘불필요한 데이터의 제거’와 ‘탐색 범위의 축소’입니다.

1. Sparse Checkout과 Shallow Clone의 활용

모든 개발자가 프로젝트의 모든 폴더와 모든 히스토리를 가질 필요는 없습니다. git clone --depth 1을 사용하는 얕은 복제(Shallow Clone)는 최신 커밋만 가져오므로 초기 클론 속도를 획기적으로 줄여줍니다. 또한 git sparse-checkout 기능을 사용하면 전체 레포지토리 중 자신이 작업하는 특정 디렉토리만 워킹 트리에 체크아웃하여, Git이 추적해야 할 파일 수를 물리적으로 줄일 수 있습니다.

2. Git LFS (Large File Storage) 도입

바이너리 파일은 Git 레포지토리 내부에 직접 저장하는 대신, 포인터 파일만 남기고 실제 데이터는 외부 서버에 저장하는 Git LFS를 반드시 도입해야 합니다. 이를 통해 git clone 시 모든 버전의 바이너리를 다운로드하는 낭비를 막고, 필요한 시점에만 해당 파일을 가져오게 함으로써 네트워크와 디스크 I/O를 최적화할 수 있습니다.

3. 파일 시스템 모니터링 (FSMonitor) 활성화

최신 Git 버전에서는 core.fsmonitor 설정을 통해 운영체제의 파일 시스템 변경 알림을 활용할 수 있습니다. 기존에는 git status를 실행할 때마다 모든 파일을 스캔했지만, FSMonitor를 활성화하면 변경된 파일 목록만 즉시 받아오므로 대규모 레포지토리에서 상태 확인 속도가 수십 배 빨라집니다.

최적화 기법의 장단점 분석

모든 최적화에는 트레이드오프가 존재합니다. 무조건적인 적용보다는 팀의 상황에 맞는 선택이 중요합니다.

최적화 기법	주요 장점	잠재적 단점 및 주의사항
Shallow Clone	클론 속도 극대화, 디스크 공간 절약	전체 히스토리 부재로 인한 로그 분석 제약
Git LFS	레포지토리 크기 감소, 푸시/풀 속도 향상	별도의 LFS 서버 관리 필요, 워크플로우 복잡성 증가
Sparse Checkout	작업 디렉토리 경량화, IDE 성능 향상	의존성 파일 누락 시 빌드 오류 가능성
FSMonitor	git status 속도 비약적 향상	OS별 지원 여부 확인 필요, 초기 설정 단계 필요

실무 적용 사례: 거대 모노레포지토리의 생존 전략

실제로 수백 명의 엔지니어가 하나의 레포지토리를 사용하는 글로벌 테크 기업들의 사례를 보면, 이들은 Git의 기본 기능을 넘어선 커스텀 전략을 사용합니다. 예를 들어, 일부 기업은 Scalar라는 도구를 도입하여 Git의 성능을 가속화합니다. Scalar는 Microsoft가 개발한 도구로, 내부적으로 Sparse Checkout과 FSMonitor를 자동 설정하고, 거대한 레포지토리를 효율적으로 관리할 수 있는 인터페이스를 제공합니다.

또 다른 사례로는 ‘레포지토리 분리(Split)’ 전략이 있습니다. 모든 것을 하나에 담는 모노레포(Monorepo)의 편리함이 성능 한계에 부딪혔을 때, 공통 라이브러리는 별도의 레포지토리로 분리하고 Git Submodule이나 패키지 매니저(npm, Maven, PyPI 등)를 통해 의존성을 관리함으로써 개별 레포지토리의 크기를 적정 수준으로 유지하는 방식입니다.

지금 당장 실행할 수 있는 고성능 Git 액션 가이드

이론적인 최적화보다 중요한 것은 실천입니다. 현재 프로젝트의 Git 속도가 느리다고 느껴진다면 다음 단계를 순서대로 적용해 보십시오.

• 1단계: 가비지 컬렉션 수행 – git gc --prune=now --aggressive 명령어를 통해 불필요한 객체를 정리하고 팩 파일을 최적화하십시오. 이것만으로도 상당한 속도 향상을 경험할 수 있습니다.
• 2단계: .gitignore 재검토 – 빌드 아티팩트, 로그 파일, IDE 설정 파일이 실수로 추적되고 있지 않은지 확인하고, 이미 추적 중인 불필요한 파일은 git rm --cached로 제거하십시오.
• 3단계: FSMonitor 활성화 – git config core.fsmonitor true 설정을 통해 파일 시스템 모니터링을 켜고 git status 속도를 측정해 보십시오.
• 4단계: LFS 마이그레이션 – 레포지토리 내에 10MB 이상의 바이너리 파일이 많다면, git lfs migrate import를 통해 과거 히스토리까지 LFS로 전환하는 것을 고려하십시오.

자주 묻는 질문 (FAQ)

Q: git gc를 자주 실행하면 위험하지 않나요?
A: git gc는 안전한 작업입니다. 다만 --aggressive 옵션은 CPU와 메모리를 많이 사용하므로, 서비스 중인 서버보다는 로컬 환경이나 빌드 서버의 유휴 시간에 실행하는 것을 권장합니다.

Q: Shallow Clone을 사용하면 나중에 전체 히스토리가 필요할 때 어떻게 하나요?
A: git fetch --unshallow 명령어를 사용하면 누락되었던 나머지 히스토리를 모두 가져올 수 있습니다.

Q: LFS를 도입하면 팀원 모두가 LFS를 설치해야 하나요?
A: 네, 그렇습니다. LFS로 관리되는 파일은 포인터로 저장되기 때문에, 실제 파일을 다운로드하고 관리하기 위해서는 모든 팀원의 로컬 환경에 Git LFS 클라이언트가 설치되어 있어야 합니다.

결론: 도구의 한계를 넘어 생산성으로

Git은 단순한 저장소가 아니라 개발자의 사고 흐름을 기록하는 타임머신과 같습니다. 하지만 이 타임머신이 너무 무거워져서 작동하는 데 시간이 오래 걸린다면, 그것은 더 이상 도구가 아니라 짐이 됩니다. 고성능 Git 환경을 구축하는 것은 단순히 몇 초의 시간을 아끼는 것이 아니라, 개발자가 코드에 집중할 수 있는 ‘몰입의 상태’를 유지하게 만드는 핵심적인 인프라 작업입니다.

지금 바로 여러분의 레포지토리 크기를 확인하고, 위에서 제시한 최적화 가이드를 적용해 보십시오. 작은 설정 변경 하나가 팀 전체의 배포 속도를 높이고, 개발 경험을 완전히 바꿀 수 있습니다.