2026년 iOS 팀에서 가장 많이 나오는 말 중 하나가 "GitHub Actions가 느리다"입니다. 실제 원인은 Actions 자체보다 공유 macOS runner에 무거운 공정을 몰아넣은 구조에 있는 경우가 많습니다. 맥락 설명부터 보고 싶다면 iOS CI 대기 입문 글을 먼저 보세요.
어디서 막히는가: 자주 보이는 4가지 병목
- 공유 macOS 풀: 릴리스 직전 queue가 build 시간을 역전
- 캐시 비지속: DerivedData / SPM / Pods가 반복 냉시작
- 서명 환경 불안정: 키체인·프로파일 관리가 흔들림
- 부하 배치 오류: PR 경량 작업까지 Mac에서 처리
핵심은 간단합니다. iOS에서 Mac이 꼭 필요한 공정만 전용화하면 대기와 실패가 함께 줄어듭니다.
2026년 설계: 오케스트레이션과 실행층을 분리
| 레이어 | 실행 위치 | 역할 |
|---|---|---|
| Fast Check | ubuntu-latest | lint·unit test·정적 분석 |
| Release Build | self-hosted macOS | archive·codesign·notarization·배포 |
| Orchestration | GitHub Actions | 트리거·승인·알림·artifact 제어 |
IDE 쪽 Agent 진화(예: Xcode 27 Agent)는 개발 경험을 높이지만, 릴리스 인프라는 별도 설계가 필요합니다.
패턴 1: 혼합 파이프라인 (Linux 먼저, Mac은 핵심만)
가장 빠르게 성과가 나는 시작점입니다. PR마다 macOS를 태우지 않고 main/tag만 Mac으로 보냅니다.
pull_request는 Linux: lint + test + diff gatemain/tag는 Mac: archive + signing + upload- 야간 prewarm 잡으로 의존성 예열
Windows/Linux 주력팀 분업은 원격 Mac build 섬 FAQ가 실전적입니다.
패턴 2: Mac 빌드 섬 + self-hosted Runner
두 번째 단계는 필수 Mac 공정을 전용 노드에 고정하는 것입니다. 운영 디테일은 Runner 캐시/디스크 FAQ를 그대로 가져오면 됩니다.
- 서명 노드와 beta Xcode 실험 노드 분리
- cache key에 Xcode major 포함
- 병렬 잡은 DerivedData 경로를 잡 단위로 분리
조달 판단은 구매 vs 임대 매트릭스, 전체 그림은 기업 Mac CI 자원 풀 글이 좋습니다.
패턴 3: 릴리스 주에만 burst 증설
부하가 파형이라면 상시 증설은 낭비입니다. Cloud Mac을 단기 추가하고 release 잡만 burst 라벨로 분기합니다.
- 평시 1~2대 상시
- 릴리스 주만 1~3대 추가
runs-on: [self-hosted, macos, burst]를 release 잡에만 적용- 행사 종료 후 즉시 축소
선택법: 셋 중 하나가 아니라 셋의 조합
| 상황 | 우선 도입 |
|---|---|
| 대기부터 줄이고 싶다 | 혼합 파이프라인 |
| archive가 많고 환경이 흔들린다 | Mac 빌드 섬 |
| 릴리스 전만 급증한다 | burst 증설 |
실무에서는 "혼합 + 상시 섬 + burst" 조합이 가장 재현성이 좋습니다. OpenClaw 자동화까지 연결하려면 통합 운영 가이드가 직결됩니다.
최소 Runbook: 이번 주에 바로 적용하려면
- PR 잡에서 macOS 필수 작업이 아닌 것을 Linux로 이동
- self-hosted macOS Runner 1대로 archive 이관
- cache key에 Xcode major + lockfile hash 도입
- 다음 릴리스 주에 burst 노드 단기 추가
이 단계만 해도 CI는 "계속 기다리는 파이프라인"에서 "예측 가능한 파이프라인"으로 바뀝니다.
FAQ
GitHub Actions를 버려야 하나요?
대부분 그렇지 않습니다. 실행층 분리가 도입 비용과 효과의 균형이 가장 좋습니다.
처음부터 구매할까요?
먼저 임대로 실측하고 상시 고가동이 확인되면 구매를 판단하는 흐름이 안전합니다.
Xcode 27 Agent가 나오면 CI Mac은 불필요한가요?
아직 아닙니다. 개발 보조는 좋아지지만 서명·배포는 여전히 Mac 노드 설계가 핵심입니다.
정리
2026년 iOS CI의 승부처는 "어떤 CI를 쓰느냐"보다 "어디서 무엇을 돌리느냐"입니다. GitHub Actions를 유지한 채 macOS 실행층만 분리해도 대기 시간과 재시도 비용이 크게 줄어듭니다.