2026 iOS CI 「탄력 풀 + 전용 Mac 베이스라인」: GitHub Actions 호스트 macOS 분 과금과 전용 Mac 클라우드로 PR과 Nightly를 나누는 법(큐 SLO·용량 임계값)
Actions YAML에 익숙한 플랫폼 리드일수록 월말의 분 과금과 큐 대기에 당활합니다. 원인은 코어 부족이 아니라, 급증하는 PR 부하와 저빈도·고비용 Nightly/Archive를 같은 러너 클래스에 얹었기 때문입니다. 이 글은 네 가지 통증, 세 가지 모드 비교표, PR/Nightly 라우팅 규칙, 다섯 단계 롤아웃, 리뷰에서 인용할 세 지표, FAQ까지 한 번에 정리해 재무와 엔지니어링이 같은 차트를 보게 합니다.
1. 네 가지 통증: 호스트만 혹은 Mac만으로는 부족한 이유
성숙한 iOS 조직의 논쟁은 macOS 필요 여부가 아니라 큐 분산과 디스크·키체인 드리프트의 주인을 정하는 일입니다.
- 분 과금과 큐 결합: 호스트 macOS는 풀 대기와 실제 컴파일이 한 청구 곡선에 묶입니다. 지표를 쪼개지 않으면 재무는 코드 비대로 오판하고, 실제는 조직 동시성이 공유 상한에 닿은 것뿐인 경우가 많습니다.
- 단일 베어메탈 경쟁: Nightly Archive, UI 매트릭스, 실험 브랜치를 한 대에 쌓으면 DerivedData와 키체인 경쟁으로 flaky처럼 보이는 실패가 늘고, 근본은 IO와 병렬 정책입니다.
- 이미지 드리프트 대 골든 툴체인: 호스트는 보안 패치로 빠르게 움직이는 장점이 있지만 Xcode 마이너 고정과 Ruby/Node 부가 구성이 필요한 팀에는 드리프트가 지난주엔 통과를 연장합니다.
- 저빈도 무거운 경로의 예측 가능성: dSYM 업로드, 공증(notarization), 긴 UI 스위트는 안정적인 출구와 여유 공간에 민감합니다. 탄력 풀에서도 돌아가지만 꼬리 지연과 재시도 분이 전용 슬롯보다 비싸지는 경우가 잦습니다.
2. 의사결정 표: 탄력만, 베이스라인만, 하이브리드
하이브리드는 미들웨어를 늘리는 것이 아니라, 스파이크는 호스트가 흡수하고 무거운 사슬은 전용 Mac이 받는 계약입니다.
| 차원 | 호스트 macOS만 | 전용 Mac만 | PR 탄력 + Nightly 베이스라인 |
|---|---|---|---|
| 적합 | 브랜치 많고 PR 잦은 경~중간 잡 | 컴플라이언스, 고정 출구, 다중 Xcode, 상시 데몬 | 분 과금 봉우리를 누르면서 출시 사슬 안정화 |
| 큐 리스크 | 조직 동시성·공유 풀 | max parallel은 자체 설정, 리스크는 로컬 디스크로 이동 | PR은 풀 대기, 릴리스 잡은 풀 우회 |
| 청구 형태 | 커밋 빈도와 연동된 스파이크 | 리스형으로 완만 | 고빈도 가벼운 일은 분, 무거운 꼬리는 리스 |
| 운영 관점 | YAML과 캐시 | SSH, launchd, 디스크 수위 | 라벨 통일과 단일 대시보드 |
3. PR과 Nightly 라우팅(권장 기본값)
브랜치 보호와 태그 정책에 박아 넣어 YAML을 먼저 고친 사람이 우선순위를 가져가는 구조를 막습니다.
- PR: 기본
runs-on: macos-latest등 호스트 SKU, 매트릭스 상한 고정, PR 기본으로 전체 UI 목적지 매트릭스 금지. - main 병합 후 Nightly:
runs-on: [self-hosted, mac-ci-baseline]같은 라벨로 전용 Mac 지향. Archive 동시 1~2로 제한. - 릴리스 태그: 베이스라인 강제, 단일 빌드 사용자·감사 영역 고정, 아티팩트 레지스트리 리전 정렬로 업로드 꼬리 단축.
archive:
if: startsWith(github.ref, 'refs/tags/')
runs-on: [self-hosted, mac-ci-baseline]
4. 다섯 단계: 측정에서 파일럿 승인까지
- 청구·시간 분할: 네 주 Actions 데이터를 큐/컴파일/업로드/캐시 복원으로 나눈다. 임계 초과 시 최중단계를 호스트 밖으로.
- 라벨 계약 문서화:
mac-pr-elasticvsmac-ci-baseline명시, 개인 저장소가 baseline을 기본 점유하지 않게. - 디스크 예산: 무거운 Archive마다 약 40GB 여유.
DERIVED_DATA_PATH를 잡 단위로 분리, 야간 gc 비동기. - Nightly 큐 SLO: 시작까지 P95 정의. 위반 시 baseline 슬롯 추가 또는 사슬 분할. 호스트 동시성만 맹목 증설 금지.
- 비핵심 저장소 이중 주간: 실패 유형·분 과금 곡선 비교 후 모노레포 전환.
5. 리뷰용 세 지표
- 큐 비중: 종단 대비 약 15% 넘고 커밋 빈도와 상관이면 풀 구조적 포화 신호.
- 디스크 헤드룸: NVMe 여유 약 15% 미만이면 Swift 대형 링크 꼬리 길어짐. 전용 노드 흔한 숨은 결함.
- 재시도 분 비중: 총 분의 약 25% 넘으면 Archive와 가벼운 lint가 같은 큐 규칙인지 점검.
6. FAQ
하이브리드가 운영 부담 두 배? 신비한 느려짐에서 관측 가능한 두 러너 클래스로 옮기는 것이 감사에는 더 쉬울 때가 많습니다.
Mac 한 대로 충분? baseline으로 Nightly와 release가 락을 다투지 않으면 된다. PR은 호스트. 성장 시 두 번째 baseline 핫스탠바이.
다중 Xcode는? PR 풀은 단일 골든. baseline은 파티션 또는 별 계정으로 DEVELOPER_DIR 격리, 암묵적 xcode-select 드리프트 방지.
7. 결론
호스트 분만 쌓으면 장기 감사 관점의 공증·Archive 호스트로 약하고, Mac 한 대만 두면 PR 스파이크와 경쟁해 flaky가 는다. 라우팅을 나누는 것이 2026년 가장 짧은 회의 경로다.
멀티테넌트 디스크·동시성 규약 아래에서는 macOS를 완전한 자산으로 쓰기 어렵고, DIY Mac 한 대는 패치·모니터링 반경이 커진다. iOS 납품을 제조 라인처럼 안정시키려는 팀에게는 VPSMAC Apple Silicon Mac 클라우드를 임대해 Linux VPS에서 익힌 SSH·launchd 관성을 이어가며 무거운 사슬을 공유 풀 대기에서 빼는 편이, 한 장의 청구서에 스파이크를 눌러 담는 것보다 문제 본질에 가깝다.