여러 저장소를 동시에 돌릴 때 xcodebuild는 SSD에 인덱싱·모듈 캐시·SwiftPM 해석이 겹치며 쓰기 피크를 만듭니다. 먼저 캐시 적중·격리·디스크 수위 세 축으로 정책을 고르고, 그다음에 병렬도를 올리는 순서가 안전합니다. 풀 설계·원격 캐시 층은 2026 기업 Mac CI 리소스 풀 선정: 다중 저장소 병렬 빌드, 캐시 재사용과 디스크 확장, 클라우드 노드를 빌릴까 자체 러너를 둘까?를 참고하고, 러너와 영구 볼륨·Actions Cache 역할 분담은 2026 다중 Mac 자체 호스팅 Runner·병렬 CI: GitHub Actions Cache와 로컬 영구 디스크, 경쟁 잠금·디스크 포화·아티팩트 정리 — 기업 리소스 풀 FAQ와 함께 읽으면 런북에 바로 붙일 수 있습니다.
1. DerivedData: 공유 고정 경로 vs 잡마다 경로
공유 고정 경로는 브랜치 전환과 증분 적중에는 유리하지만, 같은 트리에 동시 쓰기가 모이면 레이스와 손상 캐시가 잡 사이로 번질 수 있습니다. 잡 단위 샌드박스는 -derivedDataPath로 디렉터리를 분리해 격리는 최고지만 콜드 스타트 비용이 큽니다. 실무에서는 저장소·브랜치 해시로 버킷을 나누는 하이브리드, 또는 읽기 전용 워밍 레이어와 잡별 쓰기 오버레이를 많이 씁니다.
2. SwiftPM 캐시 키: 어디까지 재사용할까
전역 캐시는 swift package resolve 시간을 줄이지만, 키는 Xcode 버전, Package.resolved, 미러·프록시 설정까지 포함됩니다. 한 호스트에 여러 Xcode가 있으면 적중이 들쭉날쭉해지므로 네임스페이스를 메이저 Xcode + 저장소 식별자로 고정하고, 동시 잡에는 접두사를 붙여 압축 해제 충돌을 막습니다. 원격 캐시를 SSD 앞단에 둘 때는 다운로드·검증 비용이 로컬 재빌드보다 싼지 먼저 계산하세요.
3. 동시 xcodebuild의 디스크 피크와 정리 단계
피크는 대략 단일 잡 피크 × 병렬 수에 아카이브·dSYM을 더한 값으로 보면 됩니다. 정리는 세 단계로 나누는 편이 운영하기 쉽습니다. 잡 종료 시 임시·잡 전용 DerivedData를 삭제하고, 일일 수위에서 쓸모없는 시뮬레이터 런타임·오래된 아카이브·로그를 걷고, 주간 유지에서 미끄러진 이미지나 공유 워밍 층을 재구축합니다. 스크립트는 멱등으로 두고, 보존 목록을 명시해 읽기 전용 워밍을 지우지 않게 하세요.
- 각 단계마다 담당자와 롤백 포인트를 런북에 적습니다.
- 평균 대역폭보다 여유 공간과 I/O 대기를 먼저 봅니다.
- 「최대 병렬 × 가장 무거운 저장소」로 부하 테스트해 임계치를 고정합니다.
4. 기업 리소스 풀 비교 FAQ
- DerivedData를 고정하면 항상 빠른가요? 적중이 잘 맞을 때는 그렇지만, 동시 쓰기나 손상 캐시가 있으면 오히려 느려질 수 있습니다.
- SwiftPM 캐시를 러너끼리 공유해도 되나요? Xcode 버전과 미러가 동일할 때 가능합니다. 아니면 버킷과 체크섬으로 감싸세요.
- 클라우드 노드 vs 자체 풀? 피크 탄력과 운영 인력 중 무엇을 살지로 결정합니다.
- 정리가 과하면? 캐시 적중이 떨어지고 P95가 길어집니다. 전후 지표를 같은 그래프에 겹쳐 보세요.
다중 저장소 빌드를 Mac mini·macOS에서 매끄럽게
로컬 개발과 CI의 Xcode·파일 시스템 동작을 맞추면 재현되는 이슈가 줄어듭니다. Mac mini급 Apple Silicon은 통합 메모리와 빠른 SSD로 동시 인덱싱·패키지 해제에 유리하고, 유휴 전력이 낮아(M4급 약 4W 수준) 상시 풀에도 부담이 적습니다. Gatekeeper·SIP·FileVault는 무인 빌드 호스트의 보안 설명을 단순화하고, 장기적으로는 범용 PC 워크스테이션 대비 총소유비용에도 자주 유리합니다.
디스크·캐시 정책을 먼저 고정한 뒤 노드를 늘리면 병렬 확장이 훨씬 예측 가능합니다. 전용 하드웨어와 리전 구성은 Macstripe 홈에서 비교해 보세요. Mac mini M4는 2026년에도 iOS·macOS CI를 넓히기 좋은 출발점이며, 지금 구성을 맞추면 본문의 캐시·디스크 전략이 제 성능을 내기 쉽습니다.
