2026 Mac 클라우드 빌드 큐: 동시성·DerivedData·디스크 여유로 안정적인 xcodebuild

iOS/macOS CI를 Mac 클라우드로 옮긴 팀은 보통 서명과 프로비저닝을 먼저 Runbook에 적지만, 병렬 잡·비대해진 DerivedData·가득 찬 디스크 때문에 코드 서명 전에 빌드가 흔들립니다. 본문은 Xcode 26 파이프라인을 전제로 리소스 계열 실패 세 가지, 동시성·메모리 판단표, 복사해 쓸 디스크 임계 스크립트를 포함한 다섯 단계 이상 운영 절차, FAQ까지 담아 큐와 디스크 정책을 인증서와 같은 수준의 가시성으로 올립니다.

1. 큐와 디스크를 서명과 같은 Runbook에 둘 이유

Linux VPS에선 CPU와 큐 깊이를 봅니다. macOS 빌더에선 Xcode와 Swift가 DerivedData·모듈 캐시·SourcePackages에 거대한 중간 산출물을 쓰고, 디스크 처리량·여유 공간이 CPU와 같은 병목이 됩니다. 헤드리스 서명 체크리스트와 CI/CD 연동 가이드까지 마쳤다면 다음은 리소스 경합입니다. 정책을 문서화하지 않으면 “재실행하면 초록” 같은 파이프라인 불신이 남습니다.

병렬 archive는 RAM과 링커 임시 공간을 뺏습니다: 여러 xcodebuild archive가 잡당 추정을 넘는 메모리를 쓰고, 링크는 /tmp에 수 GB 임시 파일을 뿌립니다. 볼륨이 차면 clang/ld는 “디스크 가득”이라고 분명히 쓰지 않습니다.
DerivedData는 단조 증가: 기본 ~/Library/Developer/Xcode/DerivedData는 브랜치·스킴이 바뀔 때마다 커집니다. 잡 단위 정리가 없으면 몇 달 뒤 시스템 볼륨이 5% 미만으로 떨어져 macOS 정리 작업과 빌드 시간 변동을 부릅니다.
디스크 지표가 없으면 “네트워크 문제”로 오인: Swift Package 재시도 로그는 CDN 이슈처럼 보이지만, 캐시 디렉터리 쓰기 불가도 비슷한 로그를 냅니다. df와 DerivedData 크기를 큐 지연과 같은 대시보드에 올리세요.

2026년 권장: 서명 규칙·최대 병렬도·잡별 DerivedData 루트·빌드 전후 디스크 임계값을 하나의 파이프라인 템플릿에 선언합니다. 아래 표는 거친 동시성 가이드이며 xcodebuild -showBuildSettings와 CI 메트릭으로 반드시 조정하십시오.

2. 노드당 동시성과 RAM/CPU

전형적인 M4 / M4 Pro 클라우드 SKU를 가정한 표입니다. 원칙: 링커 피크를 재지 않았다면 동시 archive는 1~2로 제한. 컴파일/테스트는 더 높게 잡을 수 있습니다. 로그·스냅샷용으로 여유 공간 약 15%는 남기세요.

SKU(예)	권장 병렬 archive	컴파일/테스트 상한(참고)	DerivedData 전략	여유 디스크 목표
16GB RAM / 10코어 이하	1	2(프로젝트 의존)	잡별 하위 디렉터리 또는 야간 전체 삭제	여유≥20%
24~36GB RAM	1~2	3~4	브랜치 네임스페이스+주간 딥 클린	여유≥15%
48GB+ UMA	2~3(링커 실측 필수)	4~6	계층 캐시: 최근 N커밋 유지	여유≥15%, 데이터 볼륨 분리 권장

Jenkins 라벨이나 셀프호스트 러너에서는 한 로그인에서 두 archive가 같은 DERIVED_DATA_PATH를 공유하지 않도록 잠금을 걸어야 합니다. 모듈 캐시 잠금은 간헐적 “파일 변경” 오류를 만듭니다. 플릿 확장 시 메모리·구성 가이드와 대조하세요.

3. DerivedData·SPM 캐시·디스크 임계값(5단계 이상)

다음을 Linux에서 Mac으로 이전하는 플레이북에서 설명한 SSH 진입점과 같은 위치에 스크립트화합니다.

잡마다 DerivedData 경로 분리: export DERIVED_DATA_PATH="$WORK/DerivedData/$BUILD_ID"처럼 설정하고 xcodebuild에 -derivedDataPath를 항상 전달합니다.
디스크 부족은 즉시 실패: 30분 컴파일 전 아래 스니펫으로 조기 종료합니다.
SPM 캐시 정책을 버전 관리: ~/Library/Caches/org.swift.swiftpm를 예측 가능하게 유지하고, Xcode 메이저 업 후 전체 퍼지를 계획해 바이너리 불일치 루프를 피합니다.
성공/실패 후 회수: 최근 K개 DerivedData는 증분용으로 남기고, 실패 잡 디렉터리는 즉시 삭제합니다. 야간에 7일 초과 폴더를 정리합니다.
순수 CI에서는 COMPILER_INDEX_STORE_ENABLE=NO: IDE 인덱싱이 불필요하면 IO를 크게 줄입니다. 분석 전용 파이프라인만 켭니다.
(추가) 메트릭 전송: df -h와 du -sh를 로그로. 큰 .ipa/.xcarchive는 객체 스토리지로 보낸 뒤 로컬 삭제.

# 빌드 전: 여유 공간이 12% 미만이면 비정상 종료(마운트는 환경에 맞게)
AVAIL=$(df -h / | awk 'NR==2 {gsub(/%/,"",$5); print 100-$5}')
THRESH=12
if [ "${AVAIL%%.*}" -lt "$THRESH" ]; then
  echo "여유 디스크 ${THRESH}% 미만 — DerivedData 정리 또는 볼륨 확장"; exit 1
fi

                팁: 같은 macOS 사용자로 대화형 Xcode와 헤드리스 CI를 섞으면 기본 DerivedData가 충돌합니다. 서명과 같이 CI 전용 계정이나 별도 클라우드 노드를 권장합니다.
            

4. 인용 가능한 기술 사실과 파라미터

내부 감사 메모: ① 병렬 분리의 1차 스위치는 xcodebuild -derivedDataPath. ② SPM 네트워크 재시도 로그는 실제로는 캐시 쓰기 불가일 수 있음. ③ APFS에서 여유 5~10% 미만은 로컬 스냅샷과 긴 꼬리 빌드를 유발할 수 있음. ④ ObjC/Swift 혼합은 링크 시 컴파일 피크의 약 2배 RAM이 필요할 수 있음—코어가 많다고 병렬 archive가 늘지는 않음. ⑤ 산출물을 데이터 볼륨에 두면 시스템 볼륨 마모와 보존 정책이 단순해짐.

5. 임시 Mac에서 확장 가능한 빌드 기반으로

작은 개인 Mac에서 archive를 네 개 돌리는 것은 “돌아간다”까지입니다. 디스크는 조용히 차고, 실패는 재현하기 어렵고, 정전 한 번이 릴리스를 막습니다. 원격 데스크톱만 쓰는 운영은 큐 정책을 버전 관리하기 어렵고 API로 노드를 뽑는 구성과도 맞지 않습니다.

반면 RAM/디스크 단계가 읽기 쉽고 SSH 자동화와 빌더 교체 여지가 있는 탄력적 Mac 클라우드에 큐를 고정하면 Linux 러너처럼 캐시 수명을 관리하면서 전체 Xcode 툴체인을 유지합니다. Xcode 26 표준화·DerivedData 억제·디스크 이상 시 노드 교체를 중시하는 팀에게 VPSMAC M4 Mac 클라우드를 임대하는 편이 한 대의 취약한 머신을 계속 짜내는 것보다 예측 가능한 경우가 많습니다. 병렬도와 정리를 코드로 박고, 플랫폼이 연산·스토리지 기준선을 제공하면 “금요일 미스터리 디스크 풀”로 릴리스 열이 멈출 확률이 줄어듭니다.

6. 자주 묻는 질문

증분 속도를 위해 DerivedData를 공유해도 되나요

같은 브랜치의 직렬 잡은 가능합니다. 병렬 archive는 별도 디렉터리를 권장합니다. 잠금 경합과 캐시 오염을 피합니다. 필요하면 자체 원격 캐시로 심볼릭 링크.

DerivedData를 적극 지우면 매번 느려지지 않나요

콜드 빌드는 길어지지만 계획 가능하며, 가득 찬 디스크의 무작위 실패보다 낫습니다. 바이너리 캐시나 최근 몇 개 유지로 완화.

클라우드 Mac과 온프레 Mac mini 군은

온프레는 전원·랙·디스크 교체 부담. 클라우드는 버스트 병렬이 쉽습니다. 임대 대 구매 ROI 글을 참고하세요.