Xcode Cloud와 원격 Mac CI 비교: 2026 선택법

표준적인 빌드와 TestFlight 배포가 중심이면 Xcode Cloud를 먼저 선택하고, 사설망·지속 캐시·특수 도구·전체 호스트 권한이 필요하면 원격 Mac CI로 분리하는 것이 맞습니다. 대부분의 중형 팀은 Xcode Cloud로 일반 검증을 처리하고 원격 Mac으로 맞춤 빌드와 배포를 맡기는 이중 운영이 가장 안전합니다.

이 글은 다음 독자를 위한 판단 가이드입니다.

• 독립 개발자: CI 운영은 줄이고 싶지만 현재 배포 흐름이 Xcode Cloud에 맞는지 확인하려는 경우
• 모바일 개발 책임자: 전달 속도, 계산 사용량, 도구 제어권 사이에서 선택해야 하는 경우
• DevOps·배포 엔지니어: 사설 의존성, 서명 자산, 지속 캐시, 여러 운영체제의 파이프라인을 다루는 경우

Xcode Cloud와 원격 Mac CI의 첫 분기

처음부터 기능 목록을 길게 비교하지 마십시오. 아래 네 가지 질문으로 작업을 나누면 선택이 빨라집니다.

1. 소스 저장소가 Apple 플랫폼용 공개 저장소인가, 사내 네트워크 안에 있는가
2. 빌드가 매번 깨끗한 임시 환경에서 실행되어도 되는가
3. 특정 버전의 명령줄 도구, 백그라운드 서비스, 관리자 권한이 필요한가
4. 단발성 작업인가, 계속 켜 둬야 하는 실행 노드인가

Apple은 Xcode Cloud를 Xcode, TestFlight, App Store Connect와 연결된 CI/CD 서비스로 설명합니다. 워크플로에는 빌드, 분석, 테스트, 아카이브라는 네 가지 기본 작업이 있고, Apple Developer Program에는 월 25시간의 계산 사용량이 포함됩니다. 최신 사용량 정책은 Apple의 Xcode Cloud 안내에서 확인해야 합니다.

이 표에서 중요한 것은 어느 쪽이 더 빠르다는 순위가 아닙니다. 같은 프로젝트라도 테스트 작업은 Xcode Cloud에 두고, 사내 패키지와 특수 서명 작업은 원격 Mac으로 보내는 식의 분리가 가능한지 확인하는 것이 핵심입니다.

독립 개발과 표준 배포 흐름

작은 팀의 프로젝트가 단일 앱 또는 소수의 Apple 플랫폼 앱으로 구성되고, 표준 Xcode 프로젝트와 TestFlight 배포를 사용한다면 Xcode Cloud를 우선 검증하십시오. 저장소 연결, 워크플로 생성, 빌드 결과 확인이 Xcode 생태계 안에서 이어지므로 별도 실행 노드를 유지할 이유가 적습니다. Xcode Cloud는 빌드가 끝난 뒤 임시 환경을 폐기하는 구조이므로, 호스트에 파일을 남겨 두는 방식은 기대하기 어렵습니다. (developer.apple.com)

Xcode Cloud와 자가 운영 Mac CI 중 작은 팀에 더 맞는 쪽은 무엇입니까?

관리할 저장소가 적고 특별한 도구가 없다면 Xcode Cloud가 먼저입니다. 반대로 매 빌드마다 내부 서버에 접속하거나, 같은 호스트에 설치된 특정 도구와 캐시를 계속 사용해야 한다면 원격 Mac CI를 검증해야 합니다. 작은 팀이라도 운영 환경의 제약이 크면 관리형 서비스가 반드시 단순한 선택은 아닙니다.

Apple의 공식 문서상 사용자 정의 스크립트는 가능하지만, Xcode Cloud는 관리자 권한을 얻기 위해 sudo를 사용할 수 없다고 명시합니다. 또한 사용자 정의 스크립트가 만든 파일은 다른 사용자 정의 스크립트에서 계속 사용할 수 없고, 빌드가 끝나면 삭제됩니다. 따라서 단순한 도구 설치나 산출물 업로드는 가능해도, 호스트를 장기간 구성하는 방식의 자동화에는 경계가 있습니다. (developer.apple.com)

주의: 서명 키와 배포 토큰을 스크립트 출력에 그대로 남기지 마십시오. Apple은 비밀 환경 변수 사용과 로그 비공개 처리를 안내하고 있으므로, 실패 로그를 재현하는 절차와 비밀값 보호 절차를 분리해야 합니다.

병렬 테스트와 여러 브랜치

커밋이 잦고 여러 브랜치를 동시에 검증한다면 대기 시간만 보지 말고 작업의 성격을 나누어야 합니다. Xcode Cloud는 여러 기기 유형에 대한 병렬 테스트를 지원하지만, 모든 브랜치 변경마다 무거운 UI 테스트를 실행하면 계산 사용량과 대기열이 함께 늘어날 수 있습니다. Apple도 워크플로 시작 조건을 조정해 지나치게 자주 실행되는 테스트를 제한하는 방식을 설명합니다. (developer.apple.com)

다음 조건이면 Xcode Cloud의 사용량을 늘리는 쪽이 합리적입니다.

• 대부분의 작업이 빌드, 단위 테스트, 아카이브, TestFlight 배포에 해당함
• 빌드마다 깨끗한 환경이 오히려 장점임
• 내부 서비스에 대한 직접 연결이 필요하지 않음
• 실패한 작업을 같은 호스트 상태에서 재현할 필요가 없음

다음 조건이면 원격 Mac 노드를 추가하는 편이 낫습니다.

• 여러 브랜치가 같은 고정 도구 체인과 캐시를 공유해야 함
• 특정 작업만 전용 장비나 특정 네트워크를 요구함
• 대기열이 길어져도 작업을 분리할 독립 실행 노드가 필요함
• CI 외에 야간 작업, 예약 작업, 산출물 후처리가 계속 실행됨

GitHub Actions를 사용하는 팀이라면 자가 운영 러너에 운영체제와 아키텍처 라벨을 지정해 작업을 특정 노드로 보낼 수 있습니다. 다만 온라인 상태의 유휴 러너가 없으면 작업은 대기열에 남고, 24시간을 초과해 대기하면 실패합니다. 따라서 노드 수를 줄이는 것이 항상 비용 절감으로 이어지지는 않습니다. (docs.github.com)

사설 의존성과 맞춤 도구 체인

Xcode Cloud가 회사 사설망과 내부 의존성에 접근할 수 있습니까?

가능 여부를 단정하지 말고 연결 경로를 먼저 검증해야 합니다. Xcode Cloud는 임시 빌드 환경에서 실행되고 HTTP 프록시 관련 환경 변수를 제공합니다. 내부 패키지 저장소, 사내 API, 자체 인증 서버가 이 환경에서 허용되는지, 허용 목록과 인증 방식이 맞는지는 조직 네트워크 정책에 달려 있습니다. (developer.apple.com)

다음 항목 중 하나라도 실패하면 해당 작업을 원격 Mac CI로 옮기는 편이 안전합니다.

• 저장소 또는 패키지 저장소가 외부 실행 환경의 주소를 허용하지 않음
• 고정 출발지 주소나 사설 터널이 필요함
• 내부 인증서 또는 특수 DNS 구성이 필요함
• 빌드 중 접근해야 할 서비스가 외부 노출을 허용하지 않음

GitHub도 호스팅 러너에서 사설 패키지 저장소와 내부 서비스를 연결할 수 있는 별도 네트워크 구성이 필요하다고 안내합니다. 내부 네트워크가 중요한 팀은 CI 도구의 이름보다 네트워크 경로, 비밀값 전달, 산출물 회수 여부를 먼저 확인해야 합니다. (docs.github.com)

Apple이 지원하는 Xcode Cloud 사용자 정의 스크립트는 세 가지입니다. 저장소를 내려받은 뒤 실행하는 ci_post_clone.sh, xcodebuild 전에 실행하는 ci_pre_xcodebuild.sh, 빌드 뒤 산출물을 처리하는 ci_post_xcodebuild.sh입니다. 이 세 단계로 해결되는 작업은 Xcode Cloud에 남길 수 있지만, 호스트 전체의 서비스 구성이나 관리자 권한이 필요한 작업은 원격 Mac이 더 적합합니다.

지속 실행과 다중 운영체제 파이프라인

원격 Mac CI는 맞춤 빌드 스크립트를 장기간 실행하는 데 적합합니까?

전용 호스트를 계속 켜 두고 상태를 직접 관리해야 한다면 적합합니다. 다만 CI 작업과 상시 프로세스를 같은 실행 노드에 무작정 넣으면 보안과 장애 범위가 커집니다. 빌드 러너, 캐시 저장소, 예약 작업, 배포 후처리를 분리하고 각각의 재시작 정책을 정해야 합니다.

특히 Linux 서비스, 여러 저장소의 조정 작업, 예약된 캐시 예열, 배포 뒤 자동화가 한 파이프라인에 묶여 있다면 원격 Mac은 Apple 플랫폼 작업 전용 노드로 두는 편이 좋습니다. Linux 쪽의 데이터베이스나 컨테이너 작업까지 Mac 노드에 억지로 모으면 유지보수 범위가 커지고 장애 원인도 흐려집니다.

원격 Mac을 선택할 때는 다음 운영 항목을 문서로 남기십시오.

• macOS와 Xcode 업데이트 승인 절차
• 노드 재부팅 뒤 러너 자동 시작 여부
• 서명 자산의 저장 위치와 접근 권한
• 캐시 손상 시 삭제와 재생성 방법
• 빌드 실패 뒤 로그와 산출물 보존 기간
• 노드 장애 시 Xcode Cloud로 되돌리는 경로

MacDate의 실물 Mac과 가상화 Mac의 차이를 함께 검토하면, 장기 실행 노드에서 호스트 제어권이 왜 중요한지 판단하는 데 도움이 됩니다. 실제 노드를 선택할 때는 MacDate의 현재 Mac 구성과 주문 방식을 확인한 뒤 대표 빌드로 검증해야 합니다.

이중 운영 검증 절차

한 번에 모든 파이프라인을 옮기지 말고, 다음 순서로 작은 검증을 진행하십시오.

1. 대표 작업을 고릅니다.
   일반 빌드, 단위 테스트, UI 테스트, 서명 아카이브, TestFlight 업로드를 각각 하나씩 선정합니다.

2. 입력 조건을 고정합니다.
   같은 커밋, 같은 의존성 잠금 파일, 같은 Xcode 설정, 같은 빌드 인자를 사용합니다.

3. 환경 의존성을 기록합니다.
   내부 저장소 접근, 인증서, 비밀값, 외부 도구, 캐시 경로, 고정 주소 요구 여부를 목록화합니다.

4. 두 경로에서 반복합니다.
   단일 성공 로그만 보지 말고 성공 여부, 대기 시간, 실행 사용량, 수동 개입 횟수, 실패 복구 과정을 기록합니다.

5. 캐시와 재시작을 따로 시험합니다.
   첫 실행과 캐시가 있는 실행을 나누고, 원격 Mac은 재부팅 뒤 러너가 정상적으로 작업을 받는지 확인합니다. Xcode Cloud의 캐시 사용과 깨끗한 빌드 동작은 워크플로 환경 설정에서 별도로 관리됩니다. (developer.apple.com)

6. 보류와 회귀 조건을 정합니다.
   내부 의존성 연결이 반복해서 실패하거나, 수동 복구가 누적되면 해당 작업을 원격 Mac으로 이동합니다. 반대로 원격 노드의 업데이트와 장애 복구가 표준 작업보다 더 많은 시간을 요구하면 Xcode Cloud로 되돌립니다.

판정은 아래처럼 단순하게 할 수 있습니다.

• 표준 작업 비중이 높고 사설 의존성이 적으면 Xcode Cloud 중심
• 맞춤 작업과 지속 실행 작업이 많으면 원격 Mac CI 중심
• 일반 검증과 특수 배포가 섞여 있으면 이중 운영

이 방식은 “어느 쪽이 더 빠른가”가 아니라 “어느 작업을 어느 환경에 두어야 실패했을 때 복구 가능한가”를 기준으로 결정하게 해 줍니다.

현재 방식과 Mac 노드의 운영 차이

현재 Linux 서버나 공유형 CI만 사용하고 있다면 Apple 전용 도구 체인 부재, 사설망 연결 제약, 지속 캐시 부족, 서명 작업의 분리 문제가 반복될 수 있습니다. 반대로 원격 Mac CI는 이런 제약을 줄여 주지만, 업데이트 승인과 접근 통제, 러너 격리, 장애 복구를 직접 책임져야 합니다.

따라서 전체 파이프라인을 무조건 원격 Mac으로 옮기기보다, Xcode Cloud에서 처리할 표준 작업과 Mac 노드에서 처리할 맞춤 작업을 먼저 나누는 것이 좋습니다. 임시로 테스트하거나 특정 기간에만 Mac 계산 자원이 필요한 경우에는 MacDate의 Mac 임대 기간과 사용 가능한 노드 확인 후 대표적인 Xcode 작업으로 직접 검증하는 접근이 현실적입니다. 고정된 컴파일 속도나 모든 팀에 맞는 단일 해법을 전제로 하지 않는 것이 안전합니다.