DevOps 지식 허브
DevOps 지식 허브

느린 Git 작업 문제 해결: 일반적인 함정과 해결책

느린 Git 명령어로 어려움을 겪고 계신가요? 이 포괄적인 가이드가 느린 Git 작업을 진단하고 수정하는 데 도움이 될 것입니다. 대규모 리포지토리, 오래된 Git 버전, 비효율적인 구성과 같은 일반적인 함정을 식별하는 방법을 알아보세요. Git LFS, 얕은 클론, `git gc`, 구성 조정, 바이러스 백신 제외와 같은 실용적인 솔루션을 발견하세요. 최적의 Git 성능을 유지하기 위한 실행 가능한 단계와 모범 사례를 통해 생산성을 향상시키세요.

33 조회수

느린 Git 작업 문제 해결: 일반적인 함정과 해결책

Git은 전 세계 개발자들에게 효율적인 협업과 강력한 버전 관리를 가능하게 하는 필수 도구가 되었습니다. 하지만 리포지토리의 크기, 복잡성 또는 연식이 증가함에 따라 개발자들은 종종 좌절스러운 속도 저하를 경험합니다. 느린 git status, git pull, git push, 또는 git clone 명령어는 생산성을 크게 저해하고 이상적이지 않은 개발 경험으로 이어질 수 있습니다.

이 포괄적인 가이드는 Git 워크플로우에서 일반적인 성능 병목 현상을 진단하고 해결하는 데 도움을 주기 위해 마련되었습니다. 대규모 리포지토리와 비효율적인 구성부터 네트워크 문제 및 오래된 Git 버전까지 다양한 원인을 살펴보고, Git 작업을 다시 원활하게 실행하기 위한 실용적이고 실행 가능한 해결책을 제공할 것입니다. 이러한 함정을 이해하고 권장되는 수정 사항을 적용함으로써 시간을 되찾고 효율적인 개발 환경을 유지할 수 있습니다.

느린 Git 작업 진단: 문제점 찾기

해결책을 자세히 살펴보기 전에 실제로 느린 것이 무엇인지 식별하는 것이 중요합니다. "Git이 느리다"와 같은 일반적인 불만 사항은 문제 해결이 어렵습니다. 특정 명령어 또는 시나리오를 정확히 찾아내는 것이 첫 번째 단계입니다.

1. Git 명령어 시간 측정

Git 명령어의 지속 시간을 측정하는 가장 간단한 방법은 대부분의 Unix 계열 시스템(Linux, macOS)에서 사용할 수 있는 time 유틸리티를 앞에 붙이는 것입니다. 이는 명령어가 얼마나 걸리는지 명확하게 알려줍니다.

time git status
time git pull
time git clone <repository_url>

Windows에서는 PowerShell에서 Measure-Command를 사용할 수 있습니다:

Measure-Command { git status }

2. 상세 출력을 위한 GIT_TRACE 사용

Git이 내부적으로 무엇을 하고 있는지에 대한 보다 세부적인 통찰력을 얻으려면 GIT_TRACE 환경 변수를 사용할 수 있습니다. 이는 파일 시스템 액세스, 명령어 호출 및 네트워크 작업을 포함하여 Git 실행의 상세 추적을 출력합니다.

GIT_TRACE=1 git pull
GIT_TRACE_PACKET=1 GIT_TRACE=1 git push # 네트워크 프로토콜 세부 정보의 경우

상세하긴 하지만, 이 출력은 때때로 과도한 파일 시스템 스캔이나 외부 도구의 반복적인 호출과 같은 특정 병목 현상을 드러낼 수 있습니다.

일반적인 성능 병목 현상 및 해결책

느려지는 지점이 어디인지 대략적으로 파악했다면, 목표 지향적인 해결책을 적용할 수 있습니다.

1. 대용량 리포지토리 및 바이너리 파일

문제: 길고 풍부한 히스토리, 수천 개의 파일 또는 매우 큰 바이너리 파일(이미지, 비디오, 컴파일된 실행 파일, .zip 아카이브)이 있는 리포지토리는 리포지토리 크기를 크게 부풀리고 작업을 느리게 만들 수 있습니다.

해결책 1: Git LFS (Large File Storage)

Git LFS는 리포지토리 내의 큰 파일을 작은 포인터 파일로 대체하고 실제 파일 내용은 원격 LFS 서버에 저장합니다. 이렇게 하면 기본 Git 리포지토리가 가볍고 빠르게 유지됩니다.

실행 단계:

  1. Git LFS 설치: git-lfs.github.com에서 다운로드하거나 패키지 관리자를 통해 설치합니다.
  2. 리포지토리에서 LFS 초기화:
    bash git lfs install
  3. 대용량 파일 추적: Git LFS에 추적할 파일 유형을 알려줍니다 (예: *.psd, *.mp4, *.zip).
    bash git lfs track "*.psd" git lfs track "*.mp4"
    이 작업은 .gitattributes 파일을 생성하거나 업데이트합니다. 커밋해야 합니다.
  4. 파일 추가 및 커밋: 이제 패턴과 일치하는 파일을 추가하면 Git LFS가 이를 처리합니다.
    bash git add .gitattributes git add my_large_image.psd git commit -m "Add large image with LFS"

팁: 프로젝트 수명 주기 초기에 LFS를 구현하세요. 히스토리 깊숙한 곳에 있는 기존 대용량 파일을 LFS로 마이그레이션하는 것은 복잡할 수 있습니다.

해결책 2: 얕은 클론 (Shallow Clones)

CI/CD 파이프라인이나 리포지토리의 최신 상태만 필요한 경우(예: 서비스 배포), 얕은 클론은 히스토리에서 지정된 수의 커밋만 다운로드하여 클론 시간과 디스크 공간을 대폭 줄여줍니다.

실행 단계:

git clone --depth 1 <repository_url> # 최신 커밋만 클론
git clone --depth 50 <repository_url> # 최신 50개 커밋 클론

해결책 3: 희소 체크아웃 (Sparse Checkout)

모노레포에서 작업하지만 몇 개의 하위 디렉토리만 필요한 경우, 희소 체크아웃을 사용하면 전체 리포지토리는 다운로드하지만 파일/폴더의 하위 집합만 체크아웃(보이도록)할 수 있습니다.

실행 단계:

  1. 희소 체크아웃 초기화:
    bash git sparse-checkout init --cone
    (--cone 모드는 단순성을 위해 일반적으로 권장되며, 전체 디렉토리 포함만 허용합니다).
  2. 체크아웃할 디렉토리 정의:
    bash git sparse-checkout set path/to/project1 path/to/shared_library
  3. 작업 디렉토리 업데이트:
    bash git checkout # 이는 희소 체크아웃 패턴을 반영하도록 작업 디렉토리를 업데이트합니다

2. 리포지토리 비대화 및 최적화되지 않은 객체

문제: 시간이 지남에 따라 Git 리포지토리는 참조되지 않은 객체, 느슨한 객체 및 최적화되지 않은 팩 파일이 쌓여 디스크 사용량이 증가하고 작업 속도가 느려질 수 있습니다.

해결책: Git 가비지 컬렉션 (git gc)

git gc는 불필요한 파일을 정리하고 리포지토리 데이터베이스를 압축하여 효율성을 향상시킵니다. Git은 gc를 자동으로 실행하지만, 때로는 수동 개입이 유용할 수 있습니다.

실행 단계:

git gc --prune=now # 즉시 도달 불가능한 모든 객체 정리
  • 인수 없이 git gc를 실행하면 "자동" 모드로 실행되어 정리가 필요하다고 판단될 때만 정리(예: 느슨한 객체가 너무 많을 때)를 수행합니다.
  • --prune=now는 모든 브랜치나 태그에서 참조되지 않는 객체를 즉시 정리하도록 강제합니다.

팁: 정기적으로(예: 매월) git gc를 실행하면 건강한 리포지토리를 유지하는 데 도움이 될 수 있습니다.

해결책: 오래된 원격 참조 정리

원격 서버에 더 이상 존재하지 않는 원격 브랜치가 많은 경우, 로컬 리포지토리가 여전히 이를 추적하여 가져오기(fetch) 및 상태 확인 속도를 늦출 수 있습니다.

실행 단계:

git fetch --prune # 또는 git fetch -p

이 명령어는 원격 리포지토리에 더 이상 존재하지 않는 모든 원격 추적 브랜치를 제거합니다.

3. 오래된 Git 버전

문제: 이전 Git 버전은 속도를 향상시키는 성능 최적화, 버그 수정 및 새로운 기능을 누락하는 경우가 많습니다. Git 개발자들은 지속적으로 성능 개선 작업을 하고 있습니다.

해결책: Git 정기적으로 업데이트

Git 클라이언트를 최신 상태로 유지하면 최신 성능 향상 기능을 활용할 수 있습니다.

실행 단계:

  • macOS (Homebrew): brew upgrade git
  • Linux (apt): sudo apt update && sudo apt install git
  • Windows (Git Bash): git-scm.com에서 최신 설치 관리자를 다운로드하거나 winget install Git.Git 사용

4. 비효율적인 Git 구성

문제: 특정 Git 구성 설정은 특히 특정 운영 체제 또는 특정 워크플로우에서 성능에 영향을 줄 수 있습니다.

해결책 1: core.autocrlf (Windows 전용)

Windows에서 core.autocrlf는 줄 끝 변환을 자동으로 처리하려고 시도합니다. 크로스 플랫폼 호환성에는 편리하지만, 특히 대용량 리포지토리나 git status 중에는 오버헤드를 발생시킬 수 있습니다.

실행 단계:

단일 OS 내에서 일관되게 작업하거나 특정 파일에 대해 .gitattributes 파일을 사용하는 경우 input(커밋 시 CR LF를 LF로 변환) 또는 false(변환 없음)로 설정하는 것을 고려해 보세요.

git config --global core.autocrlf input # 주로 Windows에서 작업하지만 Unix로 배포하는 경우 권장
# 또는 변환 없음:
git config --global core.autocrlf false

해결책 2: core.fscache (Windows/macOS)

이 설정은 Git에게 파일 시스템 정보를 캐시하도록 지시하며, 이는 중복되는 시스템 호출을 줄여 대용량 리포지토리에서 git status와 같은 작업을 가속화할 수 있습니다.

실행 단계:

git config --global core.fscache true

해결책 3: core.preloadIndex

true일 경우, Git은 인덱스를 메모리에 일찍 로드하려고 시도합니다. 이는 특히 SSD와 같은 빠른 파일 시스템에서 인덱스를 읽는 후속 작업을 가속화할 수 있습니다.

실행 단계:

git config --global core.preloadIndex true

해결책 4: core.deltaBaseCacheLimit

이 설정은 객체 압축 시 델타 베이스를 캐시하기 위해 Git이 사용하는 최대 메모리를 제어합니다. 이 값을 늘리면 메모리 사용량은 증가하는 대신 무거운 델타 압축(예: git repack, git gc)이 포함된 작업 속도가 빨라질 수 있습니다.

실행 단계:

git config --global core.deltaBaseCacheLimit 200m # 200MB로 설정, 필요에 따라 조정

5. 안티바이러스 간섭

문제: 실시간 검사는 안티바이러스 소프트웨어에서 Git 작업(특히 디스크 I/O가 많은 작업)을 크게 늦출 수 있습니다. 이는 안티바이러스가 .git 디렉토리 내의 모든 파일 액세스를 검사하기 때문입니다.

해결책: .git 디렉토리를 스캔에서 제외

안티바이러스 소프트웨어를 구성하여 .git 디렉토리(및 잠재적으로 전체 개발 작업 공간)를 실시간 스캔에서 제외하십시오. 이는 특히 Windows 사용자에게 가장 큰 영향을 미치는 해결책일 수 있습니다.

경고: 개발 환경과 소스 코드를 신뢰하는 경우에만 이 작업을 수행하십시오. 신뢰할 수 없는 코드로 작업하는 경우 주의하십시오.

6. 네트워크 지연 및 대역폭

문제: 느리거나 불안정한 네트워크 연결은 git clone, git fetch, git pull, git push 작업에 심각한 영향을 미칠 수 있습니다.

해결책: 네트워크 및 구성 확인

  • 네트워크 속도 확인: ping 및 traceroute 도구를 사용하여 Git 호스트까지의 네트워크 지연을 진단하십시오.
  • http.postBuffer 최적화: HTTP/S를 통한 매우 큰 푸시의 경우, post 버퍼 크기를 늘리면 오류나 속도 저하를 방지하는 데 도움이 될 수 있습니다.
    bash git config --global http.postBuffer 524288000 # 500 MB
  • 로컬 미러/프록시 고려: 다른 지리적 위치의 팀의 경우, 로컬 Git 미러 또는 프록시는 개발자에게 더 가까운 곳에서 공통 리포지토리 콘텐츠를 제공하여 지연 시간을 줄일 수 있습니다.

7. 사용자 지정 훅 오버헤드

문제: 사용자 지정 Git 훅(예: pre-commit, post-merge)을 사용하는 경우, 훅 내의 비효율적이거나 오래 실행되는 스크립트는 상당한 지연을 유발할 수 있습니다.

해결책: 훅 스크립트 검토 및 최적화

  • 훅 프로파일링: 훅 스크립트 내에 타이밍 문( time 명령어)을 추가하여 느린 부분을 식별하십시오.
  • 스크립트 로직 최적화: 스크립트가 효율적인지 확인하고 필요한 작업만 수행하도록 하십시오.
  • 외부 호출 최소화: 실행하는 데 느릴 수 있는 외부 명령에 대한 의존도를 줄이십시오.

8. 디스크 I/O 병목 현상

문제: 저장 장치의 속도는 중요한 역할을 합니다. 기존 하드 디스크 드라이브(HDD)에서 Git을 실행하는 것은 특히 대용량 리포지토리의 경우 솔리드 스테이트 드라이브(SSD)에서 실행하는 것보다 눈에 띄게 느릴 수 있습니다.

해결책: SSD로 업그레이드하고 충분한 여유 공간 확보

  • SSD 사용: 가능하다면 개발 머신이 SSD를 사용하도록 하십시오. I/O 성능 차이가 상당히 큽니다.
  • 디스크 공간 모니터링: 드라이브가 심각하게 가득 차지 않았는지 확인하십시오. 드라이브가 가득 차면 디스크 I/O를 포함한 전체 시스템 성능이 저하될 수 있습니다.

사전 예방적 성능 유지 관리

향후 속도 저하를 방지하려면 다음 사항을 정기적인 워크플로우에 통합하십시오.

  • 정기적인 git gc: 로컬 리포지토리에서 정기적으로 git gc --prune=now를 실행하십시오.
  • 최신 상태 유지: Git 클라이언트와 운영 체제를 최신 상태로 유지하십시오.
  • 팀 교육: 모든 팀원이 대용량 파일의 영향과 Git LFS를 올바르게 사용하는 방법을 이해하도록 하십시오.
  • 리포지토리 크기 모니터링: 리포지토리 크기를 주시하십시오. 예기치 않게 커지는 경우, 대용량 파일이나 추적되지 않은 파일에 대해 최근 커밋을 조사하십시오.

결론

느린 Git 작업은 불만의 주요 원인이 될 수 있지만, 올바른 진단 도구와 체계적인 접근 방식을 사용하면 대부분의 성능 문제를 효과적으로 해결할 수 있습니다. 대용량 리포지토리 및 오래된 클라이언트부터 비효율적인 구성 및 외부 간섭에 이르기까지 일반적인 병목 현상을 이해함으로써 목표 지향적인 솔루션을 적용하여 Git 경험을 최적화할 수 있습니다. 정기적인 유지 관리 및 사전 예방 조치를 통해 버전 관리 시스템을 개발 무기고에서 강력하고 빠르며 신뢰할 수 있는 도구로 유지할 수 있습니다.

이러한 팁을 활용하여 Git 워크플로우를 원활하게 유지하고, 생산성을 높이고, 즐거운 개발 경험을 누리시기 바랍니다.