Git의 얕은 복제(Shallow Clones): 사용 시점과 방법

Git의 강력함은 분산형 특성에 있으며, 이를 통해 모든 개발자가 리포지토리 기록 전체를 가질 수 있습니다. 하지만 매우 큰 리포지토리나 대역폭 또는 시간이 제한적인 환경에서는 전체 기록을 확인(checkout)하는 것이 상당한 병목 현상이 될 수 있습니다. 이때 얕은 복제(shallow clones)가 유용하게 사용됩니다. 복제 과정 중에 가져오는 기록의 양을 제한함으로써, 얕은 복제는 초기 체크아웃 속도를 극적으로 높일 수 있으며 특정 시나리오에서 성능 최적화를 위한 가치 있는 도구가 됩니다.

이 문서는 얕은 복제가 무엇인지, 장점과 단점, 그리고 정확히 어떻게 구현하고 관리하는지에 대해 안내할 것입니다. 얕은 복제를 생성하는 데 필요한 명령어를 살펴보고, 워크플로우에 예상치 못한 복잡성을 유발하지 않으면서 이 기능을 효과적으로 활용하기 위한 모범 사례에 대해 논의할 것입니다.

얕은 복제란 무엇인가?

A 표준 Git 복제 작업은 리포지토리의 첫 번째 커밋부터 최신 커밋까지 전체 커밋 기록을 가져옵니다. 즉, 로컬 리포지토리에 지금까지 이루어진 모든 변경 사항이 포함됩니다. 반면에 얕은 복제는 지정된 수의 최신 커밋만 가져와 리포지토리 기록의 "얕은(shallow)" 버전을 효과적으로 생성합니다.

전체 계보를 다운로드하는 대신, 얕은 복제는 특정 지점에서 기록을 잘라냅니다. 이는 전송 및 로컬에 저장되는 데이터의 양을 크게 줄여 훨씬 빠른 복제 시간을 제공합니다. 얕은 복제의 깊이는 복제 과정 중에 지정하는 매개변수에 의해 결정됩니다.

얕은 복제 사용의 이점

얕은 복제를 사용하는 주요 이점은 성능입니다. 이 이점은 여러 가지 방식으로 나타납니다:

더 빠른 초기 체크아웃: 기록이 긴 매우 큰 리포지토리의 경우, 전체 리포지토리를 복제하는 데 상당한 시간이 걸릴 수 있으며, 특히 느린 네트워크 연결에서는 더욱 그렇습니다. 얕은 복제는 이 시간을 몇 분 또는 몇 시간에서 몇 초 또는 몇 분으로 단축할 수 있습니다.
디스크 공간 감소: 기록의 일부만 저장하므로 얕은 복제는 로컬에서 더 적은 디스크 공간을 차지합니다. 이는 빌드 에이전트가 일시적이며 디스크 공간이 제한적일 수 있는 CI/CD 파이프라인에서 매우 중요할 수 있습니다.
대역폭 절약: 다운로드해야 하는 데이터가 적어지므로, 요금이 부과되거나 비싼 네트워크 액세스가 있는 환경에서 특히 유용합니다.

얕은 복제의 단점 및 제한 사항

속도 면에서 유용하지만, 얕은 복제에는 이해해야 할 몇 가지 제한 사항이 따릅니다:

제한된 기록: 가장 큰 단점은 전체 기록이 없다는 것입니다. 오래된 코드에 대한 git blame 또는 얕은 깊이 밖에 있는 특정 과거 태그를 체크아웃하는 등 오래된 커밋에 의존하는 작업은 예상대로 작동하지 않거나 더 많은 기록을 가져와야 할 수 있습니다.
워크플로우 복잡성 가능성: 전체 기록이 필요한 작업(예: 복잡한 리베이스, 깊은 기록 분석)을 수행해야 하는 경우 리포지토리를 "언셸로(unshallow)" 만들거나 전체 복제를 수행해야 할 수 있습니다.
git fetch 동작: 기본적으로 얕은 복제에 대한 git fetch는 기존 얕은 기록을 확장하는 최신 커밋만 가져옵니다. 전체 기록을 가져오려면(언셸로), 특정 명령어를 사용해야 합니다.

얕은 복제를 만드는 방법

얕은 복제를 만드는 것은 --depth 옵션을 사용하여 git clone 명령어를 사용하면 간단합니다. 이 옵션은 기록에 포함할 커밋 수를 지정합니다.

특정 깊이로 복제하기

얕은 복제를 만드는 가장 일반적인 방법은 원하는 깊이를 지정하는 것입니다.

git clone --depth <숫자> <repository_url>

예를 들어, 리포지토리를 복제하고 최신 커밋 10개만 가져오려면 다음을 사용합니다.

git clone --depth 10 https://github.com/example/large-repo.git

이 명령은 리포지토리를 복제하지만, 로컬 기록에는 가장 최근의 커밋 10개만 포함됩니다. HEAD는 최신 커밋을 가리키며, HEAD에서 10번째 커밋보다 더 이전으로는 이동할 수 없습니다.

깊이 1로 복제하기 (가장 얕은 복제)

얕은 복제의 일반적인 사용 사례는 CI/CD 파이프라인입니다. 여기서는 빌드 및 테스트를 위해 최신 코드가 필요한 경우가 많습니다. 이를 위해 깊이 1이 이상적입니다.

git clone --depth 1 https://github.com/example/project.git

이렇게 하면 매우 최신 커밋 하나만 가져와 복제 시간이 대폭 단축됩니다.

특정 브랜치에 대한 얕은 복제

--depth는 전체 리포지토리 기록에 영향을 주지만, -b와 결합하여 브랜치를 지정할 수도 있습니다.

git clone --depth 1 -b develop https://github.com/example/project.git

이는 develop 브랜치의 최신 커밋만 복제합니다.

얕은 복제 관리하기

일단 얕은 복제를 생성한 후에는 초기 설정된 얕은 기록보다 더 많은 기록을 다뤄야 하는 상황에 직면할 수 있습니다.

기록 더 가져오기 (복제 깊게 만들기)

초기에 얕은 복제로 가져온 것보다 더 많은 기록이 필요하다고 판단되면 추가 커밋을 가져올 수 있습니다. 새롭고 더 큰 깊이를 지정하여 복제를 깊게 만들 수 있습니다.

git remote set-depth <새로운_깊이>
git fetch --depth=<새로운_깊이>

예를 들어, --depth 10으로 초기 복제한 경우 최신 커밋 50개를 가져오려면 다음과 같이 합니다.

# 복제된 리포지토리 내부에 있다고 가정
git remote set-depth origin 50
git fetch origin

또는 특정 커밋까지 전체를 가져오려면 다음을 사용합니다.

git fetch --deepen=<숫자>

이것은 현재 HEAD의 조상인 커밋들을 가져옵니다.

리포지토리 언셸로(Unshallowing) 만들기

얕은 복제를 전체 복제(즉, 모든 기록 가져오기)로 되돌리려면 깊이를 무한대로 설정할 수 있습니다.

git remote set-depth --recursive origin $(( (1 \u003c\u003c 60) )) # 사실상 무한대를 의미하는 매우 큰 숫자
git fetch --unshallow origin

또는 git fetch에 --unshallow 옵션을 더 직접적으로 사용할 수 있습니다.

git fetch --unshallow origin

이 명령은 원격 리포지토리에서 나머지 기록을 다운로드합니다.

얕은 복제에서 푸시하기

얕은 복제에서의 푸시는 일반적으로 기록과 관련하여 원격 저장소의 기록과 충돌하지 않는 한 문제없이 가능합니다. Git은 브랜치에 필요한 커밋을 업로드합니다. 하지만, 얕은 복제본에 존재하지 않는 기록이 필요한 방식으로 분기된 브랜치를 푸시하려고 하면 오류나 예기치 않은 동작이 발생할 수 있습니다.

팁: 기록과 관련된 푸시 문제가 발생하는 경우, 리포지토리를 언셸로 만들거나 광범위한 변경을 수행하기 전에 로컬 브랜치가 원격과 최신 상태인지 확인해 보세요.

얕은 복제를 사용해야 하는 경우

얕은 복제는 전체 커밋 기록이 당면한 작업에 중요하지 않고 속도가 우선시되는 시나리오에서 가장 유용합니다.

지속적 통합/지속적 배포(CI/CD) 파이프라인: 언급했듯이, CI/CD 에이전트는 빌드, 테스트 및 배포를 위해 최신 코드만 필요한 경우가 많습니다. 얕은 복제는 이러한 자동화된 환경에서 체크아웃 프로세스를 크게 가속화합니다.
대규모 리포지토리: 방대한 기록(예: 수십 년간의 개발, 시간이 지남에 따라 추가된 대용량 바이너리 에셋)을 가진 리포지토리에서 작업하는 경우, 얕은 복제는 초기 설정을 훨씬 더 관리하기 쉽게 만들 수 있습니다.
제한된 대역폭 또는 시간 제약: 인터넷 속도가 느리거나 작업 복사본을 설정할 시간이 거의 없을 때 얕은 복제는 좋은 선택입니다.
읽기 전용 작업: 최신 코드를 읽는 작업만 필요한 경우 얕은 복제가 완벽하게 적합합니다.

얕은 복제를 사용하면 안 되는 경우

워크플로우가 정기적으로 다음을 요구하는 경우 얕은 복제를 피해야 합니다.

광범위한 기록 분석: 깊은 기록 탐색을 포함하는 git log, 오래된 코드에 대한 git blame, 또는 많은 커밋에 걸친 과거 코드 품질 분석과 같은 작업.
복잡한 병합 및 리베이스: 종종 관리는 가능하지만, 복잡한 병합 또는 리베이스 작업은 얕은 깊이를 벗어나는 기록에 액세스해야 할 때 더 복잡해질 수 있습니다.
엄격한 기록 요구 사항이 있는 프로젝트에 기여: 일부 프로젝트에서는 모든 기여자에 대해 완전한 기록 유지를 요구하는 특정 지침이 있을 수 있습니다.
전체 기록이 필요한 오프라인 작업: 오프라인에서 광범위하게 작업해야 하며 전체 리포지토리 기록에 액세스해야 할 것으로 예상되는 경우.

결론

얕은 복제는 초기 체크아웃 속도와 디스크 공간 절약이 가장 중요한 시나리오에서 Git의 강력한 최적화 기술입니다. --depth 옵션을 사용하여 가져오는 기록을 제한함으로써, 개발자는 특히 대규모 리포지토리를 다루거나 자동화된 CI/CD 환경 내에서 워크플로우를 크게 가속화할 수 있습니다. 그러나 상충 관계를 인지하는 것이 중요합니다. 전체 기록이 없으면 특정 Git 작업에 영향을 줄 수 있습니다. 얕은 복제를 언제 어떻게 사용할지, 그리고 필요할 때 깊이를 조정하거나 언셸로 만들어서 관리하는 방법을 이해하면 필수 기능을 손상시키지 않으면서 이 기능을 효과적으로 활용하여 Git 성능을 향상할 수 있습니다.

적당한 크기의 리포지토리에서 대부분의 일상적인 개발 작업에는 전체 복제가 여전히 표준이며 종종 선호되는 접근 방식입니다. 그러나 명시된 특정 사용 사례의 경우, 얕은 복제는 Git 성능 최적화 도구 키트에서 없어서는 안 될 도구입니다.