Apple은 빌드 실행을 App Store Connect API의 빌드 기록 리소스로 제공하며, 실행 상태와 관련 작업을 확인할 수 있습니다(빌드 실행 기록 문서). 따라서 Xcode Cloud 빌드 대기 문제는 먼저 기록의 현재 상태, 워크플로 트리거, 팀 사용량을 확인하고 나서 Apple 시스템 상태를 대조해야 합니다. 확인 없이 취소와 재실행을 반복하지 마세요. 핵심 작업이 계속 막히면, 옮길 수 있는 빌드·테스트만 별도 Mac CI로 분리하는 방안을 검토하되 Apple 서버 측 처리 문제와는 따로 판단해야 합니다.
이 글은 Xcode Cloud 상태와 워크플로 설정, 팀 사용량을 분리해야 하는 기업 IT·플랫폼 담당자를 위한 안내입니다.
출시 빌드가 시작되지 않아 대기와 재시도 중 무엇을 선택할지 고민하는 iOS 릴리스 담당자도 확인해 보세요.
개별 사례가 아니라 팀의 빌드 기록으로 적체와 대체 경로를 평가하려는 개발 효율·FinOps 담당자에게도 적합합니다.
SECTION 01 먼저 구분할 상태: 생성, 대기, 실행, 업로드 후 처리
빌드가 요청된 것처럼 보여도 실제로는 워크플로가 빌드를 만들지 않았을 수 있습니다. 빌드 기록이 있는지, 실행이 대기 중인지, 실제 작업이 시작됐는지부터 확인하세요. 실패한 실행과 완료된 빌드도 대기와는 다른 상태입니다. Apple의 빌드 실행 기록과 빌드 상태 설명을 대조하면 상태 판단의 기준을 세우는 데 도움이 됩니다.
업로드가 끝난 뒤 App Store Connect에서 처리 중인 상태도 빌드 실행이 대기하는 것과 같지 않습니다. 업로드 이후 처리 단계는 Apple의 빌드 업로드 안내를 기준으로 별도 확인하세요. 빌드 작업이 완료된 것과 배포 가능한 상태가 된 것을 하나의 완료로 취급하면, CI 문제를 잘못 분류할 수 있습니다.
Queued로 표시된 빌드는 어떻게 다뤄야 하나요?
먼저 해당 실행이 어떤 워크플로에서 생성됐는지 확인하고, 빌드 기록과 작업 상태를 함께 살펴보세요. 기록은 있지만 실행이 시작되지 않았다면 대기 문제로 조사하고, 기록 자체가 없다면 트리거 설정이나 실행 조건부터 점검합니다. 대기 상태만 보고 실패로 단정해 반복 실행하면 중복 작업이 생길 수 있습니다.
SECTION 02 첫 단계: 워크플로가 실제로 빌드를 만들었는지 확인
브랜치와 이벤트 조건이 예상한 변경 사항에 적용되는지, 워크플로가 활성화되어 있는지, 실행을 시작할 조건이 충족됐는지 확인하세요. Xcode Cloud의 동작 규칙은 워크플로 참고 문서와 첫 워크플로 설정 안내에 정리되어 있습니다.
한 번의 통제된 커밋이나 수동 실행을 기존 기록과 비교하면 트리거 문제와 처리 지연을 구분하기 쉽습니다. 설정을 검증하기 전에 같은 작업을 여러 번 다시 실행하지 마세요.
서비스 문제와 워크플로 설정 문제는 어떻게 구분하나요?
예상한 이벤트가 발생했는데 빌드 기록이 없다면 브랜치, 이벤트, 워크플로 활성화 여부를 먼저 확인하세요. 기록이 생성됐지만 실행이 시작되지 않았거나 관련 작업이 진행되지 않는다면, 해당 기록과 시각을 Apple 시스템 상태와 비교합니다. 시스템 상태 페이지가 정상이어도 특정 프로젝트의 문제나 확인되지 않은 서비스 측 이슈까지 모두 배제되는 것은 아닙니다.
SECTION 03 가운데 진단: 기록과 팀 사용량을 나란히 보기
여러 빌드가 겹쳤을 때는 단순히 대기 개수만 보지 말고, 어느 변경과 워크플로가 각각의 실행을 만들었는지 확인하세요. 중복 커밋, 겹치는 워크플로, 완료되지 않은 테스트가 누적되는지도 프로젝트 기록으로 판단해야 합니다. 공개 문서로 확인되지 않은 고정 동시 실행 한도나 보편적인 대기 시간은 전제로 두지 마세요.
| 관찰한 기록 | 먼저 확인할 항목 | 다음 판단 |
|---|---|---|
| 빌드 기록이 없음 | 브랜치, 이벤트, 워크플로 활성화와 실행 조건 | 트리거를 통제된 실행으로 확인 |
| 빌드 기록은 있으나 실행되지 않음 | 실행 상태, 관련 작업, 같은 시각의 다른 실행 | 대기 지속 여부를 기록하고 시스템 상태와 대조 |
| 실행이 실패로 끝남 | 실패한 작업과 해당 빌드의 진단 정보 | 실패 원인을 수정한 뒤 재실행 여부 결정 |
| 빌드 실행은 끝났으나 배포 화면에서 처리 중 | 업로드 후 처리 상태 | 실행 대기와 분리해 App Store Connect 안내 확인 |
팀 사용량은 계획 이름이나 단일 실패만으로 원인이라고 단정할 수 없습니다. Apple의 Xcode Cloud 사용량 데이터 안내에서 팀의 표시 정보를 확인하고, 문제가 생긴 빌드 기록과 시점을 대조하세요.
팀 사용량 때문에 빌드가 대기할 수 있나요?
사용량 정보는 팀에서 소비한 리소스를 살펴보는 자료입니다. 실제 대기의 원인인지는 해당 팀의 사용량 표시와 빌드 기록을 함께 확인해야 합니다. 계획이나 예산만 보고 사용량 제한에 도달했다고 추정하거나, 한 번의 실패로 사용량 문제라고 결론 내리지 마세요.
SECTION 04 기다릴지 재시도할지 정하는 확인 순서
아래 순서대로 확인하면 설정 오류를 그대로 둔 채 재시도하는 일을 줄일 수 있습니다.
- [ ] Xcode 또는 App Store Connect에서 해당 실행의 빌드 기록을 찾습니다.
- [ ] 기록이 없다면 브랜치, 이벤트 조건, 워크플로 활성화 상태를 점검합니다.
- [ ] 기록이 있다면 실행 상태와 관련 작업을 확인해 대기와 실패를 구분합니다.
- [ ] 같은 프로젝트의 동시 실행과 반복 트리거를 확인해 중복 작업 여부를 파악합니다.
- [ ] 팀 사용량 정보를 해당 빌드의 시점과 대조합니다.
- [ ] Apple 시스템 상태 페이지에서 관련 서비스 상태를 확인합니다.
- [ ] 설정이 맞는지 확인한 뒤에도 대기가 이어지면, 출시 위험을 기준으로 기다리거나 통제된 재시도를 한 번 진행합니다.
- [ ] 문제를 계속 조사해야 한다면 빌드 식별 정보, 관련 작업, 발생 시각, 워크플로 기록을 모아 Apple 지원에 전달합니다.
Apple 시스템 상태가 정상이라고 해서 모든 서비스 측 문제가 배제되는 것은 아닙니다. 반대로 다른 팀의 공개 사례만으로 보편적인 장애 원인을 확정해서도 안 됩니다. Apple은 빌드와 연결된 작업을 빌드 작업 API로 제공하므로, 지원 요청 전 해당 빌드의 작업 기록을 함께 정리하세요.
SECTION 05 마지막 판단: 무엇을 Mac CI로 옮길 수 있나요?
모든 Xcode Cloud 작업을 대체 CI로 옮길 필요는 없습니다. 프로젝트의 실제 워크플로를 기준으로 작업을 나누고, Apple 서비스에 의존하는 단계와 독립적으로 실행 가능한 빌드·테스트 단계를 구별하세요. 서명 권한, 인증 정보, 결과 회수 방식까지 확인한 다음 전환 조건을 정해야 합니다.
| 작업 유형 | 분리 검토 기준 | 전환 시 확인할 점 |
|---|---|---|
| 코드 빌드와 자동 테스트 | 필요한 소스, 의존성, Xcode 환경을 별도 노드에서 재현할 수 있는지 | 결과와 로그를 기존 배포 흐름으로 회수할 수 있는지 |
| 서명 및 패키징 | 인증서와 프로비저닝 자산을 제한된 권한으로 제공할 수 있는지 | 키 접근 권한, 보관, 감사 기록을 검증했는지 |
| 업로드와 App Store Connect 처리 | 단계가 Apple 서비스의 처리 결과에 의존하는지 | 별도 Mac으로 옮겨도 Apple 측 처리를 우회할 수 없음을 반영했는지 |
어떤 작업을 Mac CI로 분리하는 편이 적절한가요?
프로젝트 코드의 빌드와 테스트처럼 독립 Mac에서 재현하고 결과를 전달할 수 있는 작업은 후보가 될 수 있습니다. 반면 App Store Connect의 후속 처리처럼 Apple 서비스에서 진행되는 단계는 Mac 노드를 추가해도 해결되지 않습니다. 전환 전에는 같은 프로젝트의 워크플로, 서명 권한 경계, 실패 후 재실행 시 중복 업로드가 생기는지 검증하세요.
현재 Xcode Cloud만 사용하는 방식은 관리할 노드가 적다는 장점이 있지만, 핵심 작업의 대기 원인을 팀이 직접 통제하기 어렵고, 빌드와 Apple 측 후속 처리를 구분하지 않으면 장애 판단도 늦어질 수 있습니다. 반대로 Mac CI는 호스트 환경과 자격 증명 관리를 직접 맡아야 하며, Apple 서비스의 장애를 고치는 수단은 아닙니다. 반복되는 릴리스 위험을 줄이고 싶다면 팀의 워크플로로 대체 실행을 검증하고, VPSNIX의 Mac 대여 요금과 이용 조건을 확인해 필요한 기간에 맞는지 판단하세요. 접속과 운영 조건은 도움말 안내에서 확인할 수 있습니다. 장기적으로 상시 고정 부하를 직접 관리하거나 물리 인터페이스가 필요한 환경이라면 실물 장비 구매도 함께 비교하세요.