WWDC 2026은 왜
iOS CI 빌드를 더 느리게 했나?

6월 9일(월요일) 아침, iOS 담당자들의 Slack에 거의 동시에 세 가지 메시지가 올라왔습니다. "어젯밤 main Archive가 11분에서 34분으로 뛰었어요", "macos-latest가 18분째 대기 중인데 아직도 안 돌아요", "Xcode 26 beta 설치했더니 DerivedData가 사라졌어요" — 이는 특정 리포지토리의 설정 문제가 아닙니다. WWDC 시즌은 매년 CI 지진을 일으킵니다. 2026년은 메모리 공급 부족·신형 데스크톱 Mac 부재·Apple Intelligence로 인한 SDK 비대화가 겹쳐 진도가 더 큽니다. 하드웨어 부재 배경은 M5 Mac mini가 WWDC 26에 없었던 이유를 참고하세요. 이 글이 답하는 것은 하나입니다: 왜 파이프라인이 갑자기 느려졌는지, 그리고 지금 무엇을 바꿔야 하는지.

1) WWDC 이후 CI가 느려지는 「세 가지 전형적 증상」

Actions 로그를 열어 아래 중 두 가지 이상에 해당하면, WWDC 충격파가 원인이지 본인 코드 문제가 아닙니다:

• bootstrap 단계 급증: pod install, SPM resolve, iOS 27 Simulator runtime 다운로드가 각각 수 분씩 차지 — 호스티드 Runner는 매 job을 빈 상태에서 시작하므로 이 단계가 가장 크게 타격받습니다.
• 빌드가 「풀 컴파일」로 퇴행: Xcode 메이저 버전 업 이후 ModuleCache와 DerivedData 형식이 구버전과 호환되지 않아 증분 컴파일이 무력화되고, xcodebuild 소요 시간이 콜드 스타트에 가까워집니다.
• 대기 시간 장기화: WWDC 후 72시간 이내 수많은 팀이 동시에 beta를 테스트하는 workflow를 업데이트하여, 호스티드 macOS 분 공유 풀이 혼잡해지고 대기 시간이 빌드 자체를 초과하는 경우도 생깁니다.

2) Xcode 26 beta: 강제 「캐시 초기화 시즌」

Apple은 WWDC 당일 Xcode 26 beta와 iOS 27 SDK를 공개했습니다. 로컬 개발자에게 업그레이드는 인덱스 재구성과 잠깐의 기다림이지만, CI 인프라에게는 디스크 위 모든 상태가 무효화되는 것을 의미합니다:

• DerivedData 경로 및 인덱스 형식 변경 — 기존 캐시 재사용 불가. 업그레이드 후 첫 Archive는 반드시 풀 빌드입니다.
• Swift 컴파일러 버전 전환 — .swiftmodule 바이너리가 비호환되어 모든 타깃을 처음부터 컴파일합니다.
• CocoaPods / SPM 잠금 파일 흔들림 — iOS 27 미지원 Pod가 있으면 pod install이 반복 resolve하거나 전체 repo-update를 유발합니다.
• 새 Simulator runtime — 런타임 하나당 수 GB. 호스티드 Runner는 매 job마다 재다운로드하여 bootstrap에 +5~15분이 추가됩니다.

더 큰 조직적 위험은 압박에 의한 beta 도입입니다. keynote 다음날 어디서나 "Siri AI 지원하나요?"라는 질문이 날아오고, 팀은 준비도 되기 전에 Xcode 26을 main에 올려버립니다. workflow 한 줄이 바뀌면 전사 CI가 콜드 스타트 모드로 진입합니다. 올바른 접근법은 파이프라인 분리: 프로덕션 release는 안정판 Xcode 16에 고정하고, ios-27-beta 브랜치 또는 전용 beta Runner에서만 적응 작업을 수행하세요. Xcode 지원 매트릭스를 확인하세요.

3) SDK 비대화: 컴파일 부담 증가, 연산력은 그대로

WWDC 26의 소프트웨어 화두는 Siri AI와 Apple Intelligence 확장이었습니다(MacRumors WWDC 26 요약). 앱 엔지니어에게 이는 실제 빌드 비용 증가로 이어집니다:

• 새 프레임워크 의존성(App Intents, 비전/음성 파이프라인 추상화) — 링커 그래프에 모듈이 추가됩니다.
• Swift 6 동시성 검사 강화 — 동일한 소스 코드라도 컴파일러 처리량이 늘어납니다.
• Asset Catalog 및 로컬라이제이션 리소스 비대화 — Copy Bundle Resources 단계가 눈에 띄게 길어집니다.

웜 캐시가 있는 로컬 M4 MacBook에서는 「2분 더 걸리는」 수준으로 느껴질 수 있습니다. 하지만 영속 캐시가 없는 호스티드 Runner에서는 콜드 스타트 패널티와 겹쳐 「느림」이 「허용 불가」로 바뀝니다. Apple은 AI 기능을 출시하고, 청구서를 받는 것은 CI 대기열에 줄 선 개발자들입니다.

4) 신형 Mac 없음: 연산력 업그레이드 경로 차단

과거 WWDC 사이클에서는 적어도 "발표 후 CI용 Mac mini를 구입하자"는 위안이 있었습니다. 2026년은 하드웨어 발표가 전무하고, M5 Mac mini는 가을 출시 예정이며, 글로벌 메모리 공급 부족으로 24 GB / 32 GB SKU는 출시 후에도 구하기 어려울 수 있습니다. 실질적인 영향:

• 「새 기기 구입으로 느린 빌드를 해결하려」던 팀 — 구매 결정이 3~4개월 동결.
• M2/M3 16 GB Runner를 운영 중인 팀 — SDK 업그레이드 후 메모리가 더 빠듯해져, swift-frontend와 Simulator가 병렬 실행되면 스왑이 발생하고 빌드 시간이 비선형으로 악화됩니다.
• 두 번째 Runner를 추가해 병렬도를 높이려는 팀 — 하드웨어 납기가 beta 적응 마감일을 맞출 수 없습니다.

M4가 부족하다는 말이 아닙니다 — 대부분의 iOS CI에서 M4 16 GB는 충분합니다. 핵심은 WWDC 이후 느려진 주 원인이 칩 성능이 아니라 실행 모델(ephemeral vs. 영속 디스크)이라는 것입니다. M5를 기다리는 것은 하드웨어 서사로 공학적 문제를 덮는 행위입니다.

5) 호스티드 Runner의 「WWDC 대탈출」

매년 6월 GitHub 호스티드 macOS 풀은 수요 피크를 맞습니다. 2026년의 특수성은 AI 서사가 iOS 네이티브가 아닌 팀들까지 macOS job으로 끌어당겼다는 점입니다 — Core ML 변환 실행, Apple Intelligence 샘플 프로젝트 테스트가 진짜 앱 릴리스 파이프라인과 같은 풀을 놓고 경쟁합니다.

호스티드 Runner의 세 가지 구조적 약점이 WWDC 시즌에 증폭됩니다:

macos-15나 macos-latest 레이블 전환은 해결책이 아닙니다 — 레이블은 OS 이미지를 바꿀 뿐, "내일도 DerivedData가 남아있는" 게 아닙니다. GitHub Actions iOS CI 속도 분석에서 중간 규모 Swift 프로젝트의 호스티드 P50은 약 28분이며, 그 중 큐 + bootstrap이 절반 이상을 차지하는 경우가 많습니다. WWDC 이후 bootstrap이 단독으로 +40% 증가하는 것도 드문 일이 아닙니다.

6) WWDC 전후: 동일 리포지토리의 전형적 소요 시간 변화(샘플)

다음은 Nuvcloud 고객 중 Runner 모델을 변경하지 않고 main에서 Xcode 26 beta로만 전환한 Swift/UIKit 프로젝트(CocoaPods, 단일 scheme) P50 비교입니다. SLA가 아닙니다. 자신의 리포지토리로 검증하세요:

동일 리포지토리를 self-hosted Mac mini M4에서, 프로덕션 job은 Xcode 16에 고정하고 beta Runner만 Xcode 26으로 업데이트한 경우, 프로덕션 P50은 WWDC 이전 수준을 유지합니다. beta 라인은 첫 주에 20분 이상의 풀 컴파일이 예상되지만, main에는 영향이 없습니다. 이것이 Runner 분리의 가치입니다.

7) 지금 해야 할 것: 실행 모델을 고치고 M5를 기다리지 마세요

WWDC 이후 48시간 안에 우선순위에 따라 실행하세요:

1. 프로덕션 release의 Xcode 버전 고정 — workflow에 xcode-select 또는 DEVELOPER_DIR을 하드코딩하여 main이 자동으로 beta를 따르지 않도록 합니다.
2. beta 적응은 전용 브랜치 + 전용 Runner 레이블 — 예: runs-on: [self-hosted, macos, xcode26-beta], 프로덕션 ios-ci와 완전 분리.
3. 영속 디스크를 갖춘 self-hosted Runner 도입 — DerivedData, Pods, SPM 캐시가 job을 넘어 유지되어 두 번째 beta 빌드부터 증분 시간으로 돌아옵니다. 설정 방법은 GitHub self-hosted runner 문서를 참조하세요.
4. Simulator runtime은 한 번만 설치 — Runner 이미지에 iOS 27 runtime을 미리 구워 넣고, workflow 내에서 xcodebuild -downloadPlatform을 실행하지 마세요.
5. 48시간 일 단위 렌탈로 검증 — 월 단위 플랜 전에 클라우드 Mac mini를 이틀 빌려 빌드를 검증하세요. 노드 선정은 6개 리전 Runner TCO 비교를 참고하세요.

8) 자주 묻는 질문

WWDC 직후에 Xcode 26으로 바로 업그레이드해야 하나요? 그럴 필요 없습니다. App Store 제출에는 여전히 안정판 Xcode가 필요합니다. beta는 iOS 27 API 선행 적응에만 사용하고, 전용 파이프라인에서 격리하세요.

가을에 M5 Mac mini가 나오면 해결되나요? 구조적으로는 아닙니다. 새 칩이 풀 컴파일에서 10~15% 단축 효과가 있을 수 있지만, 매 job의 콜드 스타트는 고쳐지지 않습니다. 메모리 공급 부족으로 M5 대용량 SKU는 비쌀 수 있으니 출시 서사에 휩쓸리기 전에 TCO를 계산하세요.

DerivedData를 actions/cache로 캐싱하는 것으로는 부족한가요? WWDC 시즌에는 보통 부족합니다. Xcode 메이저 업데이트 후 cache key가 무효화되고, 수 GB의 DerivedData를 업로드/다운로드하는 네트워크 시간은 영속 로컬 디스크보다 비용이 더 클 수 있습니다.

beta가 불안정해서 CI가 전부 빨간불이면 어떻게 하나요? 예상된 상황입니다. beta Runner는 main 머지를 막아서는 안 됩니다. beta 파이프라인을 optional status check로 설정하거나, nightly 실행으로만 스케줄하세요.

작년 WWDC와 비교해 2026년이 특히 다른 점은 무엇인가요? 세 가지가 겹쳤습니다: AI 주도 SDK 비대화, 데스크톱 Mac 부재, 메모리 공급망 압박. 각각은 대처 가능하지만 세 가지가 동시에 발생하면 느림이 "기기 문제"로 오진되어 잘못된 하드웨어 구매나 맹목적인 호스티드 분 추가 구매로 이어집니다.