단주기(수 분 단위) 클라우드 Mac CI에서는 노드가 자주 바뀌고, 캐시를 어디에 두느냐가 wall time을 좌우합니다. DerivedData·CocoaPods·모듈 캐시·sccache를 원격 오브젝트 스토어나 공유 볼륨에 두면 재사용률은 올라가지만, 매 잡 시작 시 동기화 대역폭과 메타데이터 지연이 새 병목이 됩니다. 반대로 노드 로컬 NVMe에만 두면 콜드 스타트 때 캐시 미스 비용이 커집니다. 이 글은 두 극단 사이에서 숫자로 가르는 기준과, 런북에 그대로 붙여 넣을 파라미터를 정리합니다. 러너 풀·대기열 설계와 맞물리는 부분은 2026년 단주기 피크 빌드: GitHub Actions 자체 호스팅 macOS Runner는 클라우드 Mac 탄력 풀과 상주 노드 중 무엇을 쓸까? 지연·캐시·대기열 결정 매트릭스(실행 가능한 파라미터 목록)와 함께 읽는 것이 좋습니다.
콜드 스타트가 깨는 것
콜드 스타트는 단순히 디스크가 비어 있다는 뜻이 아니라, Xcode·CLT·Ruby 버전, Pods 해석 결과, Swift 모듈 캐시 키가 한 번에 맞지 않는 상태를 포함합니다. 이때 원격 캐시를 끌어오면 네트워크 RTT와 작은 파일 수가 컴파일 시간보다 길어지는 경우가 있습니다. 로컬 디스크에만 의존하면 첫 빌드는 길지만 이후 증분은 안정적입니다. 팀은 「첫 성공 빌드 이후 5회 중 몇 회가 같은 러너 풀에 붙는가」를 먼저 측정해 캐시 전략의 전제를 맞춰야 합니다.
원격 캐시 스택: DerivedData · Pods · sccache
DerivedData는 파일 수가 많고 메타데이터 민감도가 높습니다. 오브젝트 스토어에 tarball로 올리면 이그레스는 줄어도 풀 때 CPU·디스크가 들쭉날쭉해질 수 있습니다. CocoaPods는 Specs repo와 다운로드 캐시를 분리해 원격에 두면 재현성이 좋아지나, pod install이 네트워크 병렬성에 기대는지 확인해야 합니다. C/C++/Rust 계열은 sccache 원격 엔드포인트가 컴파일 단위 재사용에 유리하지만, 캐시 키에 절대 경로가 섞이면 적중률이 떨어집니다.
| 캐시 | 로컬 NVMe | 원격(객체/NFS) |
|---|---|---|
| DerivedData | 증분 빌드 최저 지연, 디스크 용량 압박 | 재사용↑, 풀/푸시 시 파일 수 병목 |
| CocoaPods | 빠른 페치, 노드마다 드리프트 위험 | 팀 단일 진실원, 스펙 업데이트 정책 필요 |
| sccache | 적중 시 최고 속도 | 빌드 팜 공유, 키 안정화·TLS 지연 관리 |
동기 대역폭과 병목
동기화는 평균 속도보다 꼬리 지연과 작은 파일 초당 건수가 중요합니다. 상향이 200Mbps 이하이고 저장소가 수백 킬로미터 떨어져 있다면, 매 잡마다 전체 DerivedData를 끌어오기보다 마지막 성공 해시 기준의 차분 tarball이 낫습니다. 반대로 상주 노드(스티키 러너) 비율이 높다면 로컬 디스크 캐시를 두껍게 두고 원격은 Pods·sccache만 공유하는 하이브리드가 흔히 이깁니다.
재사용 결정 매트릭스
다음은 내부에서 사용하는 단순화된 규칙입니다. (1) 같은 브랜치·같은 Xcode 빌드 번호로 주간 재빌드가 5회 이상이면 로컬 캐시 레이어를 두껍게, (2) PR마다 깨끗한 노드라면 원격 캐시+sccache 우선, (3) 릴리스 파이프라인은 서명 산출물과 캐시를 분리해 보존 정책을 다르게 둡니다. 심사 직전처럼 시간이 촉박한 경우에는 2026년 돌발 빌드와 긴급 App Store 제출: Mac 구매 vs 일·주 단위 클라우드 Mac 임대에서 다룬 것처럼, 캐시 전략보다 먼저 러너 가용성과 클린 빌드 SLO를 맞추는 편이 안전합니다.
| 신호 | 추천 |
|---|---|
| 재사용률 < 40% | 원격 전체 동기화 중단, 로컬 증분 또는 스티키 풀 |
| 풀 시간 > 클린 컴파일의 35% | 차분 동기화·단일 대형 아카이브·근거리 리전 |
| Pods 해석이 잡의 20% 이상 | Specs 미러 + 로컬 캐시, CDN 캐시 헤더 점검 |
실행 가능한 파라미터 체크리스트
아래 값은 팀 표준으로 고정해 파이프라인 변수에 넣기 쉽게 짧게 적었습니다. 실제 숫자는 레포 크기에 맞게 조정하세요.
# 원격 캐시 REMOTE_CACHE_MAX_GB=80 # 잡당 풀 상한 REMOTE_CACHE_TTL_DAYS=14 # 보존 기간 CACHE_SYNC_TIMEOUT_SEC=480 # 동기화 단독 타임아웃 SMALL_FILE_WARN_QPS=900 # 메타데이터 병목 경보 # sccache SCCACHE_IDLE_TIMEOUT_SEC=7200 SCCACHE_LOG=warn # CocoaPods COCOAPODS_DISABLE_STATS=true POD_INSTALL_JOBS=4
클라우드 Mac mini에서 이 흐름이 더 매끄럽게
캐시를 어디에 두든 결국 macOS와 Xcode가 안정적으로 돌아가야 의미가 있습니다. Apple Silicon Mac mini는 통합 메모리 대역폭 덕분에 대형 DerivedData 증분 빌드에서도 스왑 압박이 적고, 네이티브 Unix 툴체인과 Homebrew·SSH가 한 번에 맞물려 원격 캐시 동기화 이후 컴파일 단계가 길게 이어져도 체감 지연이 덜합니다. 약 4W 수준의 유휴 전력과 무팬 소형 설계로 상시 러너를 두어도 전기·소음 부담이 작아 CI 노드로 쓰기 좋습니다.
macOS의 Gatekeeper·SIP·FileVault 조합은 무인 빌드 머신에서도 표면 공격을 줄여 주고, 동급 Windows 워크스테이션 대비 크래시율이 낮아 야간 파이프라인을 맡기기 쉽습니다. 하드웨어와 OS가 한 제조사에서 최적화되어 있어 동일 스펙 숫자만으로는 설명되지 않는 IO 안정성이 빌드 꼬리 지연을 줄여 줍니다.
원격 캐시와 로컬 디스크를 나누는 설계를 실제 노드에서 검증하고 싶다면, VPSSpark 클라우드 Mac mini M4는 비용 대비 출발점이 가장 명확한 선택입니다——지금 바로 플랜 확인하고 단주기 CI의 wall time을 다시 재어 보세요.