Xcode Cloud와 병행 가능한가요?

가능합니다. 표준 릴리스는 Cloud, 무거운 서명·사내 요구는 셀프호스팅으로 브랜치 정책을 나눕니다.

셀프호스팅 최대 비용은?

무인 서명·키체인, 디스크, 병렬 경합입니다. 라벨·상한·정리 정책으로 관리합니다.

두 번째 노드는 언제?

대기열이 SLA 초과, 디스크·메모리 경고, DR·근접 빌드가 필요할 때.

2026 Xcode Cloud vs 셀프호스팅 Mac CI/CD: 인증서, 동시성, 과금, 커스터마이징 의사결정 매트릭스

2026년에도 플랫폼 팀은 같은 질문을 합니다. Xcode Cloud만으로 충분한가, 아니면 Mac 클라우드에서 GitHub Actions·Jenkins·GitLab을 직접 돌려야 하는가. 이 글은 Apple 네이티브 파이프라인에 맞는 팀과 macOS를 프로그래밍 가능한 인프라로 쓰는 팀을 구분하고, 서명·대기열·과금·커스터마이징 경계를 정리합니다. 의사결정 표, 5단계 PoC, 감사용 지표, FAQ 스키마를 포함합니다.

1. 요약: 배포 경로와 툴체인

App Store Connect가 유일하고 서명·테스트·배포를 Apple에 맡기고 싶다면 Xcode Cloud가 마찰을 줄입니다. MDM, 사내 인증서, 비공개 CocoaPods/SwiftPM, Android·Web과 동일한 Jenkins 템플릿이 필요하면 SSH 가능한 Mac 클라우드에서 셀프호스팅 Runner가 현실적입니다. 외부 기여자는 호스트 Runner, 릴리스 브랜치는 전용 Mac — 하이브리드도 흔합니다. 2026년 Xcode Cloud는 Xcode·App Store Connect와의 통합을 강화하지만, 깊은 셸 스크립트·멀티 레포 오케스트레이션에는 제약이 남습니다. Mac 클라우드는 몇 분 안에 SSH 자격증명을 주고 Linux VPS에 가까운 운영을 제공합니다. 주의: GitHub 호스트 macOS Runner는 호스트 분과 대기열을 해결하지만 Xcode Cloud 대체재가 아닙니다. 많은 팀이 Xcode Cloud, 호스트 macOS, 셀프호스팅 Mac의 삼각 비교가 필요합니다.

2. 쟁점: 서명·동시성·과금·유연성

리뷰에서 충돌이 잦은 네 가지 축입니다. (1) 서명: Xcode Cloud는 Apple 관리 흐름에 쉽게 올라가 키체인 동기화 부담을 줄입니다. 셀프호스팅은 match, API 키, 무인 세션, 사내 PKI 정렬이 필요합니다. (2) 동시성: Cloud는 구독 한도와 조직 쿼터. 셀프호스팅은 코어와 executor 정책에 따라 야간 전체 회귀·병렬 Archive에 유리합니다. (3) 과금: Cloud는 Apple 분 단위. Mac 클라우드는 시간·월 고정 + egress로 장시간 CPU 빌드 예측이 쉽습니다. (4) 커스터마이징: Cloud는 Xcode 스킴·테스트 플랜과 강하게 결합. Mac 클라우드는 임의 셸, 여러 Xcode 공존, 상시 에이전트까지 가능합니다.

3. 매트릭스: Xcode Cloud vs 셀프호스팅 vs 하이브리드

차원	Xcode Cloud	셀프호스팅 Mac CI	하이브리드
서명	Apple 통합 높음	match/API 키로 완전 통제	스토어는 Cloud, 사내는 셀프
툴체인	Apple 이미지 페이스	여러 Xcode/Ruby/Node	브랜치로 분리
과금	Cloud 사용량	호스트+트래픽	코스트 태그
대기열	구독에 따름	executor가 결정	키체인/디스크 공유 주의
컴플라이언스	Apple 약관 매핑	엔터프라이즈 기준 강화	감사 경계 조기 정의

4. PoC에서 운영까지 다섯 단계

성공 지표: 메인 25분 이내, TestFlight 업로드 성공, 야간 두 브랜치 병렬 등.
SSH Mac 클라우드 기준화: xcodebuild -version, 여유 40GB+, 프록시/DNS.
서명 전략 분리: match 저장소, ASC API 키 범위, 빌드 전용·업로드 전용 사용자.
Runner 연결 및 병렬 상한: self-hosted 라벨에서도 호스트당 job 수 제한, DerivedData 충돌 방지.
관측과 롤백: 디스크, 빌드 시간, 서명 실패율. 필요 시 가벼운 Xcode Cloud 워크플로로 복귀 Runbook.

on:
  push:
    branches: [ release/* ]
jobs:
  heavy:
    runs-on: [self-hosted, macOS, ARM64, ci-heavy]
    steps:
      - uses: actions/checkout@v4
      - run: sudo xcode-select -s /Applications/Xcode_16.3.app

팁: 어떤 브랜치가 Xcode Cloud인지 셀프호스팅인지 README에 적고, Xcode 패치 대응표를 유지하세요.

5. 하드 지표

디스크: DerivedData는 며칠 만에 수십 GB. 여유 10GB 미만이면 링크 단계가 불안정해질 수 있음.
메모리: Apple Silicon 단일 Archive는 12~18GB 피크가 흔함. 병렬 수 추정에 활용.
RTT: git fetch와 바이너리 가져오기가 먼 리전에서 병목. PoC에서 p95 기록.
로테이션: PAT/GitHub App, ASC API 키, match를 90일 주기로.
재현성: xcodebuild -showBuildSettings로 툴체인 고정, SwiftPM 해결 결과를 메타데이터화.
실패 분류: 서명/프로필, 의존성, OOM, ASC 업로드로 라벨링해 Cloud 할당량인지 Mac 병렬·디스크인지 구분.

6. 하이브리드와 확장

Cloud만으로는 사내 의존성·크로스플랫폼 통합에서 한계가 오고, 사무실 Mac만으로는 정전·온콜 부담이 남습니다. 표준 릴리스는 Apple 네이티브, 무거운 제어·감사는 Mac 클라우드 — 이 조합이 잘 확장됩니다. 대기열이 SLA를 넘고, 디스크·메모리 경고가 잦고, 두 번째 리전 DR·근접 빌드가 필요하면 노드 추가. 자체 랙보다 임대 Mac 클라우드는 몇 시간 내에 띄우고 Linux VPS SSH와 유사한 경험을 줍니다. GitHub 호스트 macOS에서 셀프호스팅으로 옮겨도 Xcode Cloud를 버릴 필요는 없습니다. 전자는 Git CI, 후자는 Apple 릴리스 통합입니다. API 스타일 빠른 개통과 CI/CD 연결은 사이트의 90초 API 글을 참고하세요. 장기적으로는 전용 Mac 클라우드로 옮겨 안정적인 Apple 툴체인과 예측 가능한 비용을 동시에 노리는 것이 현실적입니다. Docker나 Windows만으로는 Apple 툴체인과 장기 안정성에서 타협이 생기기 쉽고, 생산 목적이면 VPSMAC Mac 노드 임대가 더 나은 균형을 줍니다.