2026년 Mac Cloud CI 빌드 풀: 후회 없이 용량을 구매하는 방법 — 기준 노드, 버스트 병렬성 및 호스팅된 분당 청구 하이브리드 매트릭스

Finance에서는 GitHub 통화 시간과 Xcode Cloud 시트를 구매한 후에도 Mac 호스트 전체를 임대하는 이유를 계속 묻고 있습니다. 이 글은 이미 VPS 계약 및 러너 라벨을 사용하고 있는 플랫폼 리더를 위한 것입니다. 대기열 위험과 유휴 금속 비용을 누가 지불해야 하는지 명확히 하고, 워크로드를 기본 병합, 릴리스 주간 버스트 및 롱테일 공증 작업으로 분할하고, 전용 기본 용량, 풀 내부 버스트 병렬 처리 및 호스팅된 분당 지출을 정렬하는 단일 매트릭스를 제공합니다. 큐 깊이, 동시성 한도, 디스크 워터마크, 지역별 RTT, 확장 트리거 등 런북에서 바로 사용할 수 있는 5가지 매개변수와 2026년 아키텍처 검토에 붙여넣을 수 있는 FAQ 구조 데이터를 살펴보겠습니다.

Mac 클라우드 빌드 풀 용량 계획 및 하이브리드 청구에 대한 2026년 다이어그램

In this article

1. 요약: 코어 수가 아닌 대기열 및 유휴 시간을 최적화합니다.

Mac 클라우드를 빌드 풀로 보면 조달의 초점은 코어 수가 아니라 독점 동시 실행과 디스크 대역의 예측 가능성이다. 상시 베이스라인은 야간 머지·회귀 안정, 버스트는 릴리스 주 단일 호스트 병렬, 호스티드 분은 가벼운 PR 공유 풀의 세 열이며 서로 대체가 아니다. 잘못 배선하면 대기가 릴리스 창을 잠식하거나 링커 플레이크·「분은 줄었는데 벽시계는 그대로」 착시가 난다. 다음에서 통증·표·다섯 단계를 정리한다(어휘는 이 사이트의 iOS CI 삼원 비교 글과 같이 읽을 것).

2. 문제점: 기준 사각지대, 폭발적인 오용, 이중 계산

2026년 용량 리뷰에서 자주 부딪치는 패턴.

  1. 베이스라인 과소: 일일 빌드만 보고 야간 롱테일·의존성 사전 컴파일을 빼먹어 낮에는 정상·한밤중에만 큐가 겹쳐 보인다.
  2. 버스트 오용: 한 대에 아카이브 병렬을 쌓아 호스티드 분을 줄이지만 p95·메모리 경합으로 운영 공수가 되돌아온다.
  3. 이중 계상: 대기율·독점 사용률을 나누지 않고 청구와 분만 보면 ‘장비를 줄이라’는 잘못된 지시가 나온다.

3. 결정 매트릭스: 기준, 버스트, 호스팅 시간(분)

표는 세 열 비교이며 네 번째 연산 유형이 아니다.

DimensionBaseline dedicated Mac cloudBurst parallelism inside the poolHosted minute billing
Primary KPIStable queue depth and predictable p95Peak throughput for short windowsUnit cost for light jobs on standard images
Billing shapeLease plus traffic, favors sustained CPULease unchanged, risk becomes contentionPer-execution minutes and plan tiers
Main riskIdle capacity and toolchain driftMemory and disk contention, thermal limitsShared pool queues and customization ceilings
Typical workloadsMainline merges, nightly suites, colocated agentsRelease-week multi-scheme archivesPR compile smoke and narrow simulator matrices
Observability must-havesDisk watermarks, concurrency groups, launchd restartsParallel caps, queue pause hooksQueue fraction, minute splits by job type
솔기 원칙: 문서·작은 PR은 호스티드 분으로, main·release/* 아카이브·notarytool·긴 UI 스위트는 전용 풀로. 피크 주에는 단일 호스트 병렬을 늘리지 말고 라벨 복제로 수평 확장한다.

4. 워크로드 프로파일링에서 확장까지 5단계

단계는 내부 Runbook에 적고 동결 전후로 리허설한다.

  1. 3-버킷 계측: 4주 로그를 평일·릴리스 창·야간 롱테일로 자르고 대기·CPU 분·업로드 분을 분리한다.
  2. 열 할당: 베이스라인은 전용 독점, 버스트는 임시 노드나 병렬 상한, 롱테일 일부는 호스티드로 되돌려 리스를 상각한다.
  3. 라벨·병렬 상한: 리전·Xcode 부 버전을 라벨하고 아카이브와 전체 UI 매트릭스가 concurrency 그룹을 공유하지 않게 한다.
  4. 디스크: DerivedData 네임스페이스, 시스템 볼륨 여유 약 20% 미만 금지, 연속 여유 ~10GB 전후에서 큐 일시정지→청소→재개.
  5. 스케일 트리거: 병렬을 줄였는데도 이 주 연속 대기율 상승·디스크/메모리 경보 연속·제2 리전 필요 시 동일 골든 이미지로 수평 증설, 단일 호스트 병렬은 늘리지 않는다.

Use GitHub Actions concurrency so archives cannot preempt PR smoke tests:

concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: true jobs: pr-smoke: if: github.event_name == 'pull_request' runs-on: macos-14 timeout-minutes: 30 archive-prod: if: github.ref == 'refs/heads/main' runs-on: [self-hosted, macOS, ARM64, pool-baseline] concurrency: group: archive-main cancel-in-progress: false timeout-minutes: 120

5. 경고 및 검토에 대한 인용 가능 임계값

아래 항목은 용량 덱에 그대로 붙이고 수치는 계약·실측에 맞춘다. 주간으로 독점 CPU 사용률과 큐 깊이를 같이 보여 재무가 분과 대기를 동시에 읽게 한다.

실패는 서명·의존 fetch·OOM·업로드로 태깅해 열별 원인을 섞지 않는다.

6. 이것이 3개 소스 CI 기사와 결합되는 방식 및 두 번째 풀 노드를 추가하는 시기

어휘는 이 사이트의 삼원 CI 글로 맞춘 뒤 전용 열을 베이스라인 대 버스트로 쪼갠다. 분만 보면 릴리스 주 대기가 안 보인다. 유휴로 Mac만 늘려도 p95는 안 움직인다. 사무실 단일 장비는 다시 사람 손으로 돌아온다. 독점·고정 출구·예측 가능한 병렬이 필요하면 VPSMAC M4 Mac 클라우드로 NVMe 베이스라인을 고정하고 버스트는 수평 복제로. 90초 API 글로 표에서 라벨 Runner까지 닫는다.