Xcode Cloud 빌드가 너무 느림: 2026 Xcode 27 프로젝트는 어떻게 빠르게 할까?

작업 흐름이 끝난 시각만 보면 원인을 잘못 짚기 쉽습니다. 공식 로그에서 다음 단계를 따로 기록합니다.

• 대기
• 소스 내려받기
• Swift Package와 CocoaPods를 포함한 의존성 준비
• 빌드
• 테스트
• Release Archive 생성
• 서명, 업로드, App Store Connect의 후속 처리

이 구분은 계산 시간과 대기 시간을 분리합니다. 개발자가 느끼는 피드백 지연도 별도입니다. 예를 들어 대기만 길다면 빌드 설정을 바꿔도 해결되지 않습니다. 의존성 설치가 길다면 컴파일러를 탓할 이유가 없습니다.

같은 커밋, 같은 작업 흐름, 같은 Xcode 버전의 기록만 비교합니다. 로그에서 처음으로 지속적인 시간을 차지하는 단계를 병목 후보로 표시합니다. 실제 시간과 개선 비율을 임의로 정하지 않습니다. Apple의 Xcode Cloud 작업 흐름 전략도 작업 목적에 따른 흐름 분리를 전제로 설명합니다.

병목 확인 체크리스트

• [ ] 같은 커밋의 실행 기록을 골랐습니다.
• [ ] 같은 Xcode 버전과 같은 작업 흐름을 비교했습니다.
• [ ] 대기와 실제 계산 실행을 분리했습니다.
• [ ] 소스 내려받기와 의존성 준비 시간을 따로 기록했습니다.
• [ ] 빌드, 테스트, 보관, 업로드를 각각 확인했습니다.
• [ ] 가장 먼저 오래 지속된 단계를 병목 후보로 표시했습니다.
• [ ] 개발자가 체감한 피드백 시간과 플랫폼 계산 시간을 따로 적었습니다.

이 체크리스트에서 확인되지 않은 단계는 최적화 대상이 아닙니다. 원인이 확인되기 전에 실행 환경을 교체하면 비용만 늘고 재현 가능한 근거는 남지 않습니다.

풀 리퀘스트 확인

변경 확인은 새 커밋을 빠르게 평가하는 용도입니다. 기본 동작에는 다음 정도만 남깁니다.

• 필요한 소스 빌드
• 핵심 단위 테스트
• 대표 시뮬레이터의 시작 확인
• 결과 묶음과 실패 로그 저장

여기에 전체 기기 조합, 사용자 인터페이스 자동화, Release Archive, TestFlight 업로드까지 넣으면 작은 변경도 배포 작업처럼 변합니다. 각 커밋이 이전 커밋을 대체하는 구조라면 Auto-cancel Builds 규칙을 확인해 오래된 실행을 취소합니다.

자동 취소는 실패한 작업을 숨기는 기능이 아닙니다. 새 커밋이 들어왔을 때 더 이상 의미가 없는 실행을 정리하는 기능입니다. 취소 조건과 실행 시작 조건은 실제 저장소 흐름에 맞춰 검증해야 합니다.

시뮬레이터 테스트

모든 시뮬레이터 검사를 같은 빈도로 돌릴 필요는 없습니다.

• 단일 시뮬레이터 건강 확인: 변경 확인에 배치합니다.
• 기기와 화면 크기 호환성: 정기 실행으로 옮길 수 있는지 검토합니다.
• 사용자 인터페이스 자동화: 변경 위험이 높은 흐름에 집중합니다.
• 전체 회귀 검사: 배포 후보를 만들 때 실행합니다.

검사를 줄이기 전에는 결과 묶음, 실패 화면, 실제 결함 발견 기록을 확인합니다. 삭제한 검사가 실제 문제를 잡고 있었는지 확인하지 않으면 계산 시간만 줄고 품질 신호도 사라집니다.

주의: 테스트를 줄였다는 사실만으로 성공한 최적화라고 판단하지 않습니다. 줄인 검사에서 잡던 결함이 다른 단계에서 계속 발견되는지 확인해야 합니다.

Xcode Cloud는 임시 환경에서 작업합니다. 따라서 로컬 맥에서 이미 준비된 의존성이 원격 실행에서는 다시 준비될 수 있습니다. 의존성을 준비하는 공식 규칙에 따라 잠금 파일, 저장소 인증, 패키지 출처를 먼저 확인합니다.

다음 항목은 각각 로그에서 따로 확인합니다.

• Swift Package 내려받기
• CocoaPods 준비
• 외부 도구 설치
• 사용자 정의 스크립트
• 인증과 환경 변수 읽기

모든 동작에서 같은 설치 스크립트를 실행하지 않습니다. 변경 확인, 테스트, 보관처럼 실행 목적이 다르면 필요한 준비도 달라질 수 있습니다. 사용자 정의 빌드 스크립트 규칙과 환경 변수 참고 자료를 기준으로 실행 조건을 나눕니다.

스크립트에는 작업 흐름, 실행 원인, 빌드 동작에 따른 조건을 둡니다. 저장소 인증 정보는 로그에 남기지 않습니다. 저장소 이름, 프로젝트 이름, 구성표, 묶음 식별자, 팀 식별자, API 키, 경로는 모두 검토용 예시에서 가립니다.

Release Archive는 일반 빌드와 다른 작업입니다. 서명, 업로드, App Store Connect의 처리까지 이어지기 때문입니다. 업로드가 끝나도 처리가 끝났다는 뜻은 아닙니다. 빌드 업로드와 처리 과정과 업로드 상태 설명을 따로 확인합니다.

배포용 보관은 다음 조건 중 하나에 연결하는 편이 안전합니다.

• 명시적인 배포 브랜치
• 태그 생성
• 담당자의 수동 실행
• 후보 버전 검증

일상적인 변경 확인에서는 보관과 TestFlight 업로드를 실행하지 않습니다. 대신 실제 후보 버전으로 한 번 검증합니다. 서명 실패, 업로드 실패, App Store Connect 처리 지연, 재실행 절차가 모두 기록되어야 합니다. 보관 파일의 생성과 결과 확인 방식은 Xcode Cloud 작업 흐름과 산출물 안내에서 확인할 수 있습니다.

다음 조건 목록으로 결론을 나눕니다. 각 항목은 같은 실제 프로젝트에서 확인해야 합니다.

• 다음 조건을 모두 만족하면 Xcode Cloud를 계속 최적화합니다.
• [ ] 의존성이 임시 환경에서 반복적으로 재현됩니다.
• [ ] 변경 확인과 전체 검증의 실행 빈도를 나눌 수 있습니다.
• [ ] 오래된 커밋의 실행을 자동 취소할 수 있습니다.

• [ ] 배포용 보관을 태그, 배포 브랜치 또는 수동 실행에 연결할 수 있습니다.

• 다음 조건이 일부만 해당하면 Xcode Cloud와 원격 맥을 이중 운영합니다.

• [ ] 변경 확인은 가볍지만 Release Archive는 자주 실행합니다.
• [ ] 고정된 Xcode 버전이나 도구 구성이 필요합니다.
• [ ] 배경에서 실행되는 서비스 또는 지속적인 의존성 준비가 있습니다.

• [ ] 빠른 확인과 고정 환경의 배포 작업을 분리할 수 있습니다.

• 다음 조건이 지속되면 무거운 작업을 원격 맥으로 옮깁니다.

• [ ] 임시 환경에서 의존성을 매번 다시 준비해야 합니다.
• [ ] 캐시와 고정 도구가 없으면 작업을 재현하기 어렵습니다.
• [ ] 보관과 서명을 자주 실행해야 합니다.
• [ ] 실행 중인 호스트에 접속해 로그와 상태를 즉시 확인해야 합니다.
• [ ] 배경 서비스가 실행 중이어야 합니다.

첫 번째 묶음이면 요금제보다 작업 흐름 수정이 우선입니다. 두 번째 묶음이면 빠른 검사는 Xcode Cloud에 남기고 무거운 보관과 배포만 원격 맥에 둡니다. 세 번째 묶음이면 실제 Release Archive 한 건으로 이전 범위를 확인합니다. 모든 작업을 한 번에 옮기지는 않습니다.

원격 맥의 구성과 부하를 점검해야 한다면 Xcode 27용 원격 맥 구성과 부하 확인 안내를 기준으로 필요한 환경을 먼저 정리합니다. 맥 미니 대여 비용을 비교할 때도 장비 가격만 보지 말고 고정 도구, 상시 실행, 접속 방식, 유지 관리 시간을 함께 계산해야 합니다. 관련 조건은 맥 미니 대여 가격 안내에서 확인할 수 있습니다.

커밋마다 실행 시간이 긴 원인

전체 테스트, 여러 시뮬레이터, 의존성 설치, 보관이 한 흐름에 묶였을 가능성이 큽니다. 대기와 계산 실행을 먼저 나누고, 새 커밋으로 대체된 실행을 자동 취소합니다.

시뮬레이터 검사 줄이기

대표 시뮬레이터의 핵심 검사는 변경 확인에 남깁니다. 기기 호환성과 전체 회귀는 정기 실행 또는 배포 전으로 옮깁니다. 삭제한 검사의 결함 발견 기록을 확인한 뒤 확정합니다.

느린 의존성 설치

패키지 내려받기, 도구 설치, 인증, 사용자 정의 스크립트를 각각 측정합니다. 잠금 파일을 고정하고 같은 설치 작업이 여러 동작에서 반복되지 않게 조건을 나눕니다.

계산 시간 부족과 요금제 변경

중복 실행과 불필요한 보관을 제거한 뒤에도 무거운 작업이 계속되면 요금제 변경을 검토할 수 있습니다. 다만 고정 환경이 필요한 경우에는 원격 맥 운영 비용과 함께 비교해야 합니다.

원격 맥에 적합한 작업

고정된 Xcode 버전, 지속적인 의존성, 상시 서비스, 잦은 보관, 즉시 접속해 로그를 확인해야 하는 작업이 적합합니다. 재현 가능한 빠른 검사는 Xcode Cloud에 남기는 편이 낫습니다.

이번 점검에서 Xcode Cloud 빌드가 너무 느림의 원인이 대기나 중복 실행으로 확인됐다면 기존 환경을 유지하면 됩니다. 반대로 임시 환경에서 의존성을 매번 다시 준비하고, 상시 서비스와 고정 도구가 필요하며, Release Archive를 자주 만들어야 한다면 Xcode Cloud만으로는 운영 비용이 커집니다. 이때는 빠른 검사는 Xcode Cloud에 남기고 무거운 보관과 배포를 원격 맥으로 옮기는 편이 현실적입니다. 실제 후보 버전 하나를 보관한 뒤에도 같은 병목이 남는지 확인하고, 필요하면 원격 맥 대여 환경에서 고정 구성과 대여 기간을 비교해 보시기 바랍니다.