blobless 클론과 partial clone의 차이는 무엇인가요?

Blobless clone은 --filter=blob:none를 씁니다. 커밋과 트리는 로컬에 있지만 파일 blob은 Git이 필요할 때 내려받습니다. --filter=tree:0 partial clone은 트리도 필요할 때까지 생략해 초기 fetch를 더 줄이지만, 작업 집합이 넓으면 온디맨드 promisor fetch가 늘어납니다. 둘 다 선행 대역폭을 줄이는 대신 checkout·빌드 시점의 지연 스파이크를 바꿉니다.

blob:none를 쓰면 CI 빌드 재현성이 깨지나요?

체크아웃하는 커밋 SHA는 바뀌지 않습니다. 리스크는 운영상입니다. 빌드 중에 네트워크나 promisor 원격을 쓸 수 없으면 누락된 blob fetch가 실패합니다. 원격을 고정하고, 워밍된 장기 Runner 캐시를 쓰거나, git fetch --refetch나 필요 시 명시적 git lfs pull로 미리 채우세요.

Git LFS는 blobless·partial clone과 어떻게 맞추나요?

LFS는 별개입니다. 클론 시 GIT_LFS_SKIP_SMUDGE=1로 메타데이터만 받고, 컴파일 전에 경로 필터로 git lfs pull 하세요. partial clone과 함께 쓸 때는 리전별 lfs pull p95를 측정하세요.

물리 Mac에서는 언제 전체(full) clone이 여전히 맞나요?

에어갭·불안정 링크 Runner, 한 번에 많은 blob을 읽는 작업(대형 모노레포 grep·코드젠), 법규·보안상 완전한 로컬 객체 저장소가 필요할 때, 전용 서명·릴리스 머신에 주기적 git maintenance와 함께 쓰기 좋습니다.

DevOps 2026-04-14 · 약 14 분

2026년 국경 간 팀 CI의 Git 체크아웃은 어떻게 골라야 하나? partial clone、blobless와 전체 clone—다중 리전 물리 Mac에서의 checkout 꼬리 지연과 일관성 리스크 의사결정 매트릭스(복사 가능한 git 매개변수 + FAQ)

플랫폼·모바일 릴리스 팀이 여러 국가의 물리 Mac 풀에서 CI를 돌릴 때 디스크를 아끼려 blobless나 partial 클론을 쓰다가, 컴파일 도중 blob이 내려오며 잡이 흔들리는 경우가 많습니다. 이 글은 체크아웃 전략 매트릭스, 7단계 런북, 복사해 쓸 git 명령, 인용 가능한 임계값, FAQ를 담습니다. Runner 풀 설계는 GitHub Actions 셀프 호스티드 vs 에페메럴 Mac CI(2026)와, 아티팩트 라우팅은 XCTest 분할·다중 리전 물리 Mac과 함께 보세요.

1. 도입

셀프 호스티드 macOS Runner에서 「클론」은 한 줄 비용이 아니라 fetch 시간, checkout IO, 서브모듈 재귀, LFS smudge, partial·blobless 저장소의 온디맨드 promisor fetch까지 묶인 문제입니다. 국경 간 팀에는 객체가 있는 곳과 빌드가 도는 곳 사이 RTT, 피어링 편차, 컴플라이언스 경계가 더해집니다.

이 가이드는 전체 clone, blobless(--filter=blob:none), 트리 수준 partial(--filter=tree:0), 얕은 clone, sparse checkout을 두 축으로 비교합니다: checkout 꼬리 지연(p95/p99 잡 시간)과 일관성 리스크(blob fetch 실패, 잘못된 LFS 상태, 서브모듈 드리프트).

2. 왜 아픈가

제약: 디스크 예산 vs 실제 작업 트리. 에페메럴 CI는 작은 디스크를 원하고, iOS·macOS 모노레포는 큰 히스토리를 원합니다. Blobless·sparse는 선행 바이트를 줄이지만 부담을 뒤로 미룹니다—종종 꼬리 지연에 최악입니다.
숨은 비용: 온디맨드 blob·트리 fetch. 콜드 xcodebuild나 코드젠이 수천 경로를 건드리면 blob:none·tree:0 상태에서 빌드 중에도 원격과 통신할 수 있습니다. 미리 채우지 않으면 그대로입니다.
안정성·일관성: LFS, 서브모듈, 얕은 graft. GIT_LFS_SKIP_SMUDGE=1은 클론은 빠르지만 컴파일이 자산을 가정하면 발을 쏩니다. 얕은 clone은 describe·merge-base에 깨질 수 있습니다. 다중 리전 풀에는 동일한 레시피가 필요합니다.

3. 클론 모드 의사결정 매트릭스

지리와 무관하게 전략을 비교하는 표입니다. 리전 효과는 4절에서 덧씌웁니다.

모드	선행 fetch	Checkout·빌드 꼬리	일관성 메모
전체 clone	디스크·네트워크 최대	깜짝 최소—blob 대부분 로컬	에어갭·전체 트리 도구·워밍된 장기 Runner에 적합
Blobless `blob:none`	초기 팩 작음	누락 blob을 부하 아래 fetch할 때 꼬리 리스크	커밋 동일성은 유지—운영 리스크만 증가
Partial `tree:0`	메타 fetch 최소	작업 집합이 넓으면 온디맨드 트리/blob 트래픽 최대	sparse·공격적 prefetch와 짝
얕은 clone `--depth`	선형 이력에 빠름	일부 머지·버전 스크립트 깨짐	전체 그래프·깊이 너머 태그가 필요하면 피함
Sparse + blobless	거대 저장소에 작은 트리	cone 경로가 빌드와 맞으면 바이트 최소	잡 유형별 경로 목록 유지—드리프트가 주 리스크

4. 다중 리전 물리 Mac 오버레이

US / EU / APAC 물리 Mac 풀의 업링크는 같지 않습니다. 객체 다운로드를 미루는 전략일수록 국경 간 RTT와 손실이 증폭기가 됩니다.

신호	유리한 선택	주의
origin까지 RTT 큼	리전별 bare Git 미러, 워밍된 장기 클론, 로컬 SSD 전체 clone	미러 없는 채 raw `tree:0`—promisor 지연이 최악 링크를 탐
잡마다 에페메럴 Runner	Blobless + 명시적 prefetch, 또는 얕은 작업 트리 tarball 캐시	컴파일이 누락 blob을 안 건드린다 가정
엄격한 변경 감사	불변 아티팩트 + 리전 간 동일 SHA(XCTest 글 참고)	리전마다 다른 `git fetch` depth

5. 복사 가능한 git 블록

5.1 Blobless clone(promisor 객체)

git clone --filter=blob:none --no-checkout https://github.com/org/repo.git "$WORK"
git -C "$WORK" checkout --force "$SHA"

5.2 Partial tree:0 + cone sparse checkout(모노레포)

git clone --filter=tree:0 https://github.com/org/monorepo.git "$WORK"
git -C "$WORK" sparse-checkout init --cone
git -C "$WORK" sparse-checkout set apps/ios Tools/Scripts
git -C "$WORK" checkout "$SHA"

5.3 장기 상주 Runner: 클론 후 prefetch

git -C "$WORK" fetch --tags origin "$SHA"
git -C "$WORK" lfs install --local
GIT_LFS_SKIP_SMUDGE=0 git -C "$WORK" lfs pull --include="*.png,*.a,*.zip"

include는 자산 유형에 맞게 조정하세요. 메타만 필요하면 GIT_LFS_SKIP_SMUDGE=1 후 나중에 대상 git lfs pull을 씁니다.

6. 7단계 런북(물리 Mac CI)

워크로드 분류. 파이프라인마다 모노레포 경로·LFS 발자국·서브모듈 깊이·버전에 전체 이력이 필요한지 적습니다.
3절에서 클론 모드 선택. 많은 iOS 조직의 안전 기본값: 거대 저장소는 blobless + sparse, 작은 저장소·서명 호스트는 전체.
미러 배치. Mac 풀마다 읽기 전용 조직 미러를 두고 CI에서 url.*.insteadOf로 가장 가까운 미러를 가리킵니다.
fetch와 컴파일 분리. 시간을 재는 「구체화」 단계에 git fetch、submodule update --init、lfs pull을 넣고, Xcode 시작 전에 빠르게 실패하게 합니다.
꼬리 지연 계측. clone+checkout 초, LFS 바이트, promisor fetch 횟수를 메트릭으로 내보내고 region= 라벨로 나눕니다.
디스크 유지보수. 주간 git maintenance run --auto 또는 시간 제한 gc; APFS 여유 공간 모니터링—가득 찬 디스크에서 CI 실패가 급증합니다.
폴백 문서화. promisor·LFS 장애 시 전체 미러로 승격하는 원커맨드 스크립트를 유지합니다.

7. 인용 가능한 임계값

SLO에 맞게 조정하세요—아래는 출발점입니다.

Checkout SLO: 워밍된 장기 Runner에서 재료화(clone+checkout+잡용 LFS) p95 < 120초; 로컬 미러가 있는 콜드 에페메럴은 < 300초.
꼬리 알림: 한 리전에서 p99 checkout이 이틀 연속 p95의 2배 초과—미러 건강·promisor 폭풍 조사.
디스크 가드레일: CI 볼륨 여유 > 15%; blobless도 느슨한 객체가 쌓입니다.

8. FAQ

blobless와 partial clone의 차이는?

Blobless(blob:none)는 파일 blob을 필요할 때까지 생략합니다. tree:0는 트리까지 생략해 초기 fetch는 가장 작지만, 작업 집합이 넓으면 지연 트래픽이 가장 큽니다.

blob:none가 CI 재현성을 망치나요?

커밋 SHA는 같습니다. 리스크는 빌드 중 누락 blob fetch입니다. prefetch·미러·골드 마스터 빌드는 전체 clone로 폴백하세요.

Git LFS는 blobless와 어떻게 짝을 이루나요?

LFS는 두 번째 구체화 단계로 다루세요. 가능하면 smudge를 건너뛰고 컴파일 전에 명시적으로 pull해 국경 간 RTT를 한 번에 맞춥니다.

전체 clone이 맞는 경우는?

에어갭 Runner, 전체 트리 스캔 잡, 오프라인 정책이 엄한 릴리스·서명 호스트, promisor fetch를 신뢰할 수 없을 때입니다.

9. 무인 리전 CI에 Mac mini를 쓰는 이유

위 워크플로—빠른 SSD, 안정적인 APFS, 네이티브 Git·Xcode 도구체인, 낮은 대기 전력—는 Apple Silicon Mac mini 노드가 다중 리전 풀에서 자리 잡는 이유입니다. 노트북을 전용하지 않고 쓰는 것보다 데스크톱 Mac mini가 긴 git·컴파일 실행에 열 여유가 있고, 튜닝 시 대기 전력이 수 와트대에 가깝으며, macOS 패치 리듬이 Xcode 기대와 맞습니다.

보안: Gatekeeper·SIP·FileVault가 PC Runner 임시 구성보다 변조 위험을 줄입니다. TCO: 작은 폼팩터는 국경 너머 코로케이션·파트너 사이트 배치 비용을 낮춥니다.

checkout 꼬리를 예측 가능하게 두고 하드웨어를 덜 들여다보고 싶다면 Mac mini M4는 실용적인 기반입니다—미러와 이 매트릭스의 클론 정책을 짝지으세요.

전 세계 물리 Mac CI 노드를 표준화할 준비가 되었다면 ZoneMac Mac mini 옵션을 둘러보고 이 체크아웃 전략을 24/7 빌드에 맞는 하드웨어에서 돌려 보세요.

기간 한정

안정적인 다중 리전 Mac CI가 필요하신가요?

무인 Git·Xcode·자동화에 맞춘 물리 Mac mini 노드를 제공합니다. 계약 하나로 checkout 성능을 예측 가능하게.

종량제 즉시 활성화 안전·신뢰