2026년 단주기 피크 빌드: GitHub Actions 자체 호스팅 macOS Runner는 클라우드 Mac 탄력 풀과 상주 노드 중 무엇을 쓸까? 지연·캐시·대기열 결정 매트릭스(실행 가능한 파라미터 목록)

iOS·macOS 팀이 짧은 주기로 배포할 때 CI 곡선은 평탄하지 않습니다. 같은 시간대에 워크플로가 겹치는 짧은 피크가 생기고, GitHub 호스팅 macOS 분은 빠르게 소진됩니다. 그래서 Apple 하드웨어 위에 자체 호스팅 Runner를 올리는데, 다음 갈림길은 탄력 풀(수요에 맞춰 늘었다 줄었다 하는 클라우드 Mac)과 상주 노드(항상 따뜻한 머신)입니다. 답은 벤더 슬로건이 아니라 대기열 형태, 허용 가능한 지연, 캐시가 어디에 사는지입니다.

용량을 사기 전에 피크 모양부터 그리기

탄력 풀은 평균 가동은 낮은데 동시성 스파이크가 높은 패턴에서 이깁니다. 상주 노드는 야간 빌드·PR 매트릭스처럼 작업이 끊기지 않는 조직에 맞습니다. Actions 로그에서 대기 깊이 중앙값, queued→in_progress p95, 같은 호스트의 서명 경합 빈도를 그리세요. p95 대기가 이미 버거우면 탄력 확장은 추가 머신이 백로그보다 빨리 준비될 때만 의미가 있고, 아니면 콜드 스타트 비용만 얹습니다.

App Store 주간 압박의 구매·임대 매트릭스는 여기서 이어집니다: 2026년 돌발 빌드와 긴급 App Store 제출: Mac 구매 vs 일·주 단위 클라우드 Mac 임대

지연은 숫자 세 개, 한 줄 카피가 아니다

컨트롤 플레인(잡 픽업), 데이터 플레인(fetch·캐시·업로드), 도구 지연(Xcode)을 분리하세요. 탄력 풀은 라벨로 경합을 줄이기 쉽지만, 신선한 VM이 부트스트랩을 매번 반복하면 벽시계는 잘 안 움직입니다. 상주 Runner는 비용을 많은 잡에 분산시키고, 대신 유휴 전력·드리프트 위험을 집니다.

Git·원격 캐시까지 RTT와 처리량을 재세요. 먼 리전 TLS는 “Xcode가 느리다”로 보이기 쉽습니다. launchd 상주 패턴은 2026 클라우드 Mac에서 OpenClaw 배포: Linux VPS와 다른 macOS 검증, launchd 상주, 재현 가능한 FAQ와 함께 보세요.

캐시: 스티키 디스크 vs 공유 객체 스토어

Apple 빌드는 DerivedData·Pods·SwiftPM이 복원 시간을 지배합니다. 디스크를 버리는 탄력 노드는 캐시를 원격으로 밀고 키를 툴체인+lockfile에 묶고, 상주 노드는 로컬 SSD에 두되 결정적 eviction으로 교차 오염을 막습니다. 캐시 미스는 SLO 예산의 일부로 다루세요.

한눈에 보는 결정 매트릭스

표는 1차 필터입니다. 이어서 아래 파라미터 체크리스트로 검증하세요.

실행 가능한 파라미터 체크리스트(런북에 복붙)

YAML·Terraform·위키 표에 그대로 적는 운영 손잡이입니다. 이름은 바꿔도 의도는 같게 유지하세요.

# 워크플로 동시성(시끄러운 경로 직렬화)
concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

# 매트릭스 팬아웃 상한(캐시 스탬피드 방지)
strategy:
  max-parallel: 4

# Runner 플릿(운영 저장소에 문서화, UI만 쓰지 말 것)
baseline_always_on_runners: 2   # 최소 따뜻한 용량
burst_elastic_runners_max: 8    # 공급자가 허용하는 상한
idle_shutdown_minutes: 45       # 탄력 전용; 스래싱 방지

# 캐시 키(툴체인+lockfile 필수 포함)
cache_key_prefix: xcode-16_2-spm-${{ hashFiles('**/Package.resolved') }}

# SLO 목표(초과 시 알림)
queue_pickup_p95_seconds: 60
cache_restore_p95_seconds: 120

매주 Runner 시간과 머지 PR 수를 비교하세요. 비용만 오르면 동시성·캐시 키를 먼저 조입니다.