빌드가 오래도록 대기 상태에 머물러도 실패로 단정할 수는 없습니다.
먼저 빌드 상태와 워크플로 트리거를 확인하고, 애플 서비스 상태까지 점검한 뒤에도 원인을 찾지 못하면 별도 맥 빌드 경로로 프로젝트를 검증합니다.
이 글은 Xcode Cloud 빌드가 시작되지 않아 원인을 좁히려는 독립 개발자를 위한 안내입니다.
워크플로 설정을 살펴보는 CI 엔지니어와, 임시 빌드 경로가 필요한 출시 담당자에게도 유용합니다.
Xcode Cloud 대기 상태는 어떻게 분류해야 할까요?
첫 단계는 오류 원인을 추측하는 것이 아니라, 빌드가 어느 단계에 있는지 확인하는 것입니다. 빌드가 아직 시작되지 않은 대기와 실행 중인 빌드, 취소 또는 건너뜀, 오류가 난 빌드는 서로 다른 상황입니다. 화면에 보이는 단일 문구만으로 원인을 확정하지 마세요.
App Store Connect의 빌드 기록이나 Xcode에서 해당 실행을 열어 상태와 작업 기록을 확인합니다. Apple 문서는 진행 상황을 나타내는 CIExecutionProgress와 실행 완료 결과를 나타내는 CICompletionStatus를 별도 항목으로 정의합니다. 즉, 현재 진행 단계와 최종 결과는 같은 의미가 아닙니다. 진행 상태 항목 정의와 완료 상태 정의를 기준으로 기록을 해석합니다.
대기 상태가 계속될 때 무엇부터 확인해야 하나요?
최근 실행과 문제가 된 커밋을 나란히 비교합니다. 해당 커밋의 빌드 기록이 아예 없다면 트리거가 발생하지 않았을 가능성을 먼저 확인합니다. 실행 기록은 있지만 시작되지 않았다면 대기 상태로 분류하고, 작업 로그가 시작됐다면 단순 대기 문제로만 다루지 않습니다. 빌드 실행 기록에 포함되는 정보도 함께 살펴보세요.
새 빌드가 없다면 워크플로 조건을 확인합니다
빌드 기록이 없다면 프로젝트 컴파일보다 워크플로가 실행 조건을 충족했는지 먼저 살핍니다. Xcode Cloud의 워크플로는 저장소 이벤트와 설정한 조건에 따라 실행됩니다. 브랜치나 풀 리퀘스트 조건이 현재 변경 사항과 맞는지, 워크플로가 활성화되어 있는지 확인하세요. 앱과 구성표가 워크플로 설정 대상에 포함되어 있는지도 점검해야 합니다.
확인 순서는 다음과 같습니다.
- 문제가 된 커밋의 브랜치와 변경 이벤트를 기록합니다.
- 워크플로 설정에서 해당 브랜치 또는 풀 리퀘스트가 실행 조건에 포함되는지 확인합니다.
- 워크플로가 활성화되어 있는지, 올바른 앱과 구성표를 대상으로 하는지 살펴봅니다.
- 같은 저장소에서 마지막으로 성공한 실행과 현재 커밋의 조건 차이를 비교합니다.
- 조건이 일치하는데도 새 실행 기록이 없다면 서비스 상태를 확인하고, 관련 기록을 보존합니다.
워크플로의 이벤트 조건과 구성을 확인할 때는 Xcode Cloud 워크플로 참고 자료와 첫 워크플로 설정 안내를 기준으로 삼으세요.
취소나 건너뜀은 컴파일 오류와 다릅니다
연속으로 변경 사항을 올린 뒤 특정 빌드가 취소되거나 건너뛰었다면 자동 취소 설정을 점검합니다. 워크플로의 Auto-cancel Builds 설정과 이후 빌드가 기존 실행에 미친 영향을 확인하세요. 후속 빌드가 앞선 실행을 대체한 경우라면, 해당 실행의 취소 또는 건너뜀을 프로젝트 컴파일 실패와 동일하게 볼 수 없습니다.
자동 취소나 건너뜀 여부는 어떻게 확인하나요?
해당 실행의 상태와 완료 결과를 App Store Connect 또는 Xcode의 기록에서 확인하고, 같은 시점에 제출한 후속 커밋이 있는지 대조합니다. 설정값만 보고 실제 실행의 결과를 추정하지 말고, 각 기록에 표시된 상태를 공식 정의와 맞춰 판단하세요. 빌드 완료 상태 설명과 워크플로 참고 자료를 함께 확인하면 설정과 실행 결과를 구분하는 데 도움이 됩니다.
실행이 시작됐거나 오류가 났다면 로그로 이동합니다
상태가 실행 중으로 바뀌었거나 오류 결과가 나왔다면, 문제의 초점은 대기열이 아닙니다. 실패한 작업 단계의 로그를 열고 도구 체인, 의존성, 서명 관련 설정, 워크플로 구성을 차례로 확인하세요. Xcode Cloud에서만 재현된다면 로컬에서 같은 커밋을 빌드해 차이를 좁힙니다.
- 실패한 작업 단계와 오류 메시지를 보존합니다.
- 같은 커밋을 로컬 환경에서 빌드해 결과를 비교합니다.
- 의존성을 워크플로 환경에서 사용할 수 있는지 확인합니다.
- 설정이나 코드 변경 없이 여러 실행에서 같은 문제가 반복되는지 기록합니다.
Apple은 일반적인 구성 및 빌드 문제 해결 안내와 Xcode Cloud에서 의존성을 사용할 수 있도록 구성하는 방법을 제공합니다. 의존성 문제는 서비스 대기와 별개의 프로젝트 구성 원인일 수 있으므로, 로그에서 확인한 증거를 바탕으로 분류해야 합니다.
워크플로가 맞는데도 시작되지 않으면 서비스 상태를 확인합니다
트리거 조건이 맞고 오류 로그도 없는데 새 실행이 시작되지 않는다면 Apple Developer System Status에서 관련 서비스의 상태를 확인합니다. 페이지에 이상이 표시되면 확인 시각과 영향을 받은 워크플로, 커밋, 상태 변화를 기록합니다.
상태 페이지에 문제가 없으면 서비스 문제는 아닌가요?
그렇게 단정할 수 없습니다. 상태 페이지에 이상이 없다는 사실만으로 계정이나 서비스 측 문제를 배제할 수는 없습니다. 확인한 조건, 빌드 기록, 발생 시각을 정리해 공식 지원 경로로 문의하세요. 커뮤니티의 대기 사례는 개별 사용자 보고일 뿐, 같은 원인이 모든 대기 상태를 설명한다고 볼 근거가 되지는 않습니다.
다음 순서로 점검하면 대기와 실패를 섞지 않고 대응할 수 있습니다.
- 상태 확인: App Store Connect 또는 Xcode에서 현재 진행 단계와 완료 결과를 확인합니다.
- 기록 비교: 최근 성공 실행과 문제가 된 커밋의 실행 기록을 비교합니다.
- 트리거 점검: 브랜치, 풀 리퀘스트, 워크플로 활성화, 앱과 구성표를 살펴봅니다.
- 취소 확인: 자동 취소 설정과 후속 커밋, 실제 완료 상태를 대조합니다.
- 오류 분리: 실행이 시작됐다면 작업 로그와 의존성, 로컬 재현 결과를 확인합니다.
- 서비스 확인: 시스템 상태를 점검하고, 설명되지 않는 상황은 기록과 함께 지원 경로로 전달합니다.
이 점검 뒤에도 납기상 빌드가 필요하다면, 대체 경로가 현재 프로젝트와 도구 체인에서 실제로 동작하는지 먼저 확인하세요. 자체 관리 맥은 별도의 빌드 경로를 제공하지만 Xcode Cloud의 서비스 측 대기 시간을 없애지는 않습니다.
| 선택지 | 확인할 점 | 적합한 경우 |
|---|---|---|
| Xcode Cloud를 계속 사용 | 대기 상태와 트리거 조건, 서비스 상태를 기록합니다. | 실행이 시작되기 전이며 일정상 기다릴 여지가 있을 때 |
| 보유한 맥에서 별도 빌드 | 같은 커밋과 빌드 설정으로 결과를 비교합니다. | 프로젝트에 이미 검증된 로컬 빌드 환경이 있을 때 |
| 원격 맥을 대체 경로로 검증 | 실제 프로젝트에서 빌드와 테스트, 결과 전달을 확인합니다. | 임시 맥 환경이 필요하고 별도 경로를 인수 검증할 수 있을 때 |
원격 맥을 고려한다면 원격 맥 개발 환경과 사용 안내를 먼저 살펴보고, 프로젝트를 실제로 검증할 임시 환경이 필요할 때는 한국에서 사용할 수 있는 맥 환경을 확인할 수 있습니다. 클라우드 대기만으로 곧바로 다른 환경으로 옮기기보다, 기존 경로는 플랫폼 상태 확인이 늦어질 수 있고 로컬 맥은 담당자의 장비와 설정에 묶이며 리눅스 환경은 Xcode 빌드를 대신하지 못한다는 차이를 고려하세요. 제출 일정이 우선이고 프로젝트 검증이 가능하다면 맥 임대가 임시 대안이 될 수 있습니다. 다만 장기간 고정된 빌드 운영이나 물리 장비 연결이 필요하다면 보유 장비나 별도 운영 환경이 더 적합할 수 있습니다.