같은 워크플로에 새 빌드가 대기하면, 자동 취소 설정에 따라 진행 중인 빌드가 취소될 수 있습니다. Apple의 Xcode Cloud 워크플로 설명에서 밝힌 동작입니다. 따라서 새 커밋이 이전 검증을 대체하는 분기 작업은 자동 취소를 검토하고, 출시 결과가 필요한 작업은 끄거나 별도 워크플로로 분리하세요. 설정 후에는 실제 취소 대상과 최종 출시 결과를 따로 확인해야 합니다.

Xcode Cloud 워크플로를 관리하는 IT·플랫폼 책임자는 트리거와 취소 기준을 정할 때 참고하세요.
UI 테스트와 회귀 검증을 맡는 담당자는 어떤 작업을 합치거나 보존할지 판단할 수 있습니다.
출시 아카이브와 TestFlight 흐름을 운영하는 팀은 취소가 전달을 중단하지 않는지 점검하세요.

먼저 작업 결과가 대체 가능한지 판별합니다

자동 취소는 대기열을 무조건 비우는 정리 기능이 아닙니다. 핵심 질문은 “새 빌드가 생겼을 때, 이전 실행의 결과가 여전히 필요합니까?”입니다. 안전하게 다시 실행할 수 있고 최신 커밋의 검증만 병합 판단에 쓰는 작업이라면 자동 취소가 맞을 수 있습니다. 반대로 이전 실행도 진단·감사·출시 근거로 남겨야 한다면 취소를 피해야 합니다.

설정 전에 워크플로별로 다음 항목을 확인하세요.

  • 새 커밋이 이전 결과를 실제로 대체하는지 확인합니다.
  • 실행이 취소돼도 필요한 로그와 진단 결과를 잃지 않는지 살펴봅니다.
  • 서명, 아카이브, 업로드 등 전달 결과가 작업에 포함되는지 확인합니다.
  • 실패나 취소가 병합 게이트에서 성공으로 오인되지 않도록 상태 판정 기준을 확인합니다.

장점: 오래된 분기 검증이 계속 실행되는 일을 줄이고, 최신 변경을 중심으로 결과를 확인할 수 있습니다.
주의점: 취소된 실행에는 완료된 검증 결과가 없습니다. 자동 취소를 켰다는 이유로 테스트 통과를 간주하면 안 됩니다.

분기 검증은 시작 조건과 취소 대상을 함께 좁힙니다

분기 업데이트마다 실행되는 검증 워크플로는 새 커밋이 이전 커밋의 결과를 대체하는 대표적인 후보입니다. 다만 브랜치 변경, 요청 기반 이벤트 등 시작 조건이 서로 다른 작업을 한 워크플로에 섞으면 어떤 실행이 시작됐고 무엇이 대체됐는지 판단하기 어려워집니다. Apple의 워크플로 시작 조건과 설정 설명을 확인하고, 팀에서 필요한 이벤트만 남기세요.

다음 순서로 테스트합니다.

  • 워크플로 설정에서 시작 조건과 연결된 브랜치를 확인합니다.
  • 실행 기록에서 빌드의 트리거 출처와 커밋 식별 정보를 확인합니다.
  • 자동 취소 설정을 검토하고, 테스트용 변경을 만들어 새 실행을 발생시킵니다.
  • 이전 실행이 취소됐는지, 취소된 대상이 의도한 워크플로인지 기록에서 확인합니다.
  • 새 실행의 빌드·테스트 결과가 팀의 병합 기준을 만족하는지 확인합니다.

이 절차에서 기준은 절약한 시간이나 실행량이 아닙니다. 실제로 대체된 실행, 남은 검증 결과, 병합 판단이 일치하는지가 기준입니다. Apple의 워크플로 전략 안내는 팀의 빌드 목적에 맞춰 워크플로를 설계하는 참고 자료입니다.

빠른 연속 커밋과 UI 회귀는 같은 정책으로 묶지 않습니다

개발자가 연달아 커밋을 올리는 분기 검증에서는 마지막 변경의 결과만 병합 판단에 필요할 수 있습니다. 이 경우 같은 워크플로에서 새 빌드가 이전 실행을 대체하도록 구성할 수 있습니다. 하지만 각 커밋이 장애 분석이나 변경 추적의 증거라면 실행을 모두 보존해야 합니다. “가장 최신 커밋인가”만 보지 말고 결과를 각각 보관해야 하는 이유를 먼저 정리하세요.

UI 회귀 검증은 별도로 판단합니다. 다수의 시뮬레이터나 긴 시나리오를 포함한다면, 모든 분기 변화마다 시작되도록 할 필요가 있는지 병합 게이트와 연결해 검토하세요. 더 제한적인 트리거를 쓰거나 UI 검증을 독립 워크플로로 나누면, 빠른 분기 검증과 회귀 결과의 목적을 분리할 수 있습니다. Apple의 테스트 실행 및 결과 해석 안내를 기준으로 결과 상태를 확인하세요. 취소는 통과가 아니며, 필요한 테스트가 끝난 뒤에만 게이트가 통과해야 합니다.

자주 묻는 질문

새 빌드가 시작되면 이미 실행 중인 빌드도 취소되나요?
자동 취소 설정을 켜면 같은 워크플로에 새 빌드가 대기할 때 진행 중인 빌드가 취소될 수 있습니다. 모든 워크플로나 모든 실행이 일괄 취소된다는 뜻은 아닙니다. 설정을 바꾼 뒤 테스트용 커밋으로 새 빌드를 발생시키고, 실행 기록에서 취소된 대상과 새 빌드의 결과를 각각 확인하세요.

짧은 시간에 커밋을 여러 번 올리면 마지막 결과만 남길 수 있나요?
분기 검증처럼 새 커밋이 이전 결과를 대체하는 작업이라면 같은 워크플로의 자동 취소와 필요한 시작 조건을 함께 검토할 수 있습니다. 다만 각 커밋의 진단 결과나 감사 기록이 독립적으로 필요하다면 이전 실행을 보존해야 합니다. 최신 커밋이라는 이유만으로 취소 대상을 정하지 말고, 결과의 보존 목적부터 구분하세요.

출시 아카이브 워크플로에도 자동 취소를 켜도 되나요?
아카이브나 TestFlight 업로드처럼 결과가 전달이나 출시 판단에 쓰이는 워크플로는 자동 취소를 먼저 켜지 않는 편이 안전합니다. 실행이 취소되면 필요한 아카이브나 업로드가 완료되지 않을 수 있습니다. 자동 취소를 끄거나 검증 워크플로와 출시 워크플로를 분리하고, 빌드 상태와 분배 상태까지 따로 확인하세요.

UI 테스트를 모든 커밋에서 실행해야 하나요?
UI 테스트의 실행 여부는 팀의 병합 게이트와 테스트 결과가 필요한 시점으로 정해야 합니다. 모든 분기 변경에 무거운 회귀 검증을 연결하는 대신, 더 제한적인 시작 조건이나 별도 워크플로를 검토할 수 있습니다. 단, 자동 취소된 실행은 통과 결과가 아닙니다. 필요한 검증이 완료됐는지 병합 기준에서 확인하세요.

출시 아카이브는 검증용 빌드와 분리해 보호합니다

TestFlight 분배, 공식 아카이브, 서명된 전달 산출물이 걸린 워크플로는 분기 검증과 같은 자동 취소 정책을 그대로 적용하지 마세요. 새 커밋이 들어왔다는 사실만으로 이전 출시 실행의 결과가 불필요해지는 것은 아닙니다. 취소로 필요한 산출물을 잃을 수 있다면 자동 취소를 끄거나, 취소 가능한 검증과 출시 작업을 독립 워크플로로 나누세요.

Apple의 배포용 빌드 워크플로 안내는 배포 작업을 구성할 때 참고할 수 있습니다. 운영 중에는 워크플로가 시작되거나 종료됐다는 사실만으로 출시 완료를 판정하지 마세요.

  • 빌드 기록에서 의도한 커밋과 빌드 상태를 확인합니다. App Store Connect의 빌드 상태 설명을 함께 참고하세요.
  • 배포 대상에 필요한 아카이브가 만들어졌는지 확인합니다.
  • 업로드가 작업에 포함됐다면 업로드 결과를 별도로 확인합니다. 빌드 업로드 안내에서 업로드 절차와 결과를 점검하세요.
  • 팀의 출시 승인 기준에 결과 기록이 남았는지 확인한 뒤 완료로 처리합니다.

혼합 CI는 실행 경계와 인수 기준부터 정합니다

Xcode Cloud에서 처리할 작업과 팀이 관리하는 Mac 실행 노드에서 처리할 작업은 환경과 통제 요건으로 나누세요. Xcode Cloud 워크플로에는 작업별 환경과 동작 설정이 있습니다. 환경 변수와 실행 맥락은 Apple의 환경 변수 참고 문서에서 확인할 수 있습니다. 고정된 실행 환경이나 사내 관리 조건이 필요한 작업은 실제 제약을 확인한 뒤 별도 노드로 넘길지 판단하세요. 비용이나 성능을 검증하지 않고 이전하는 근거로 삼지는 마세요.

선택 적합한 작업 운영상 확인할 점
Xcode Cloud에 유지 분기 변경을 검증하고, 관리형 워크플로 결과로 병합을 판단하는 작업 시작 조건, 커밋 식별 정보, 취소 상태, 테스트 결과를 기록에서 확인합니다.
자동 취소를 끄거나 워크플로 분리 아카이브, 업로드, 진단 보존처럼 이전 실행 결과도 필요한 작업 취소 가능 여부와 산출물 완료 여부를 분리해 검증합니다.
관리형 Mac 노드로 분리 검토 고정 환경, 자체 통제 실행, 별도 인수 절차가 필요한 작업 실행 시작점, 산출물 전달, 로그와 완료 상태를 두 시스템에서 맞춰 봅니다.

전환을 검토할 때는 작업의 입력 커밋, 실행 환경, 산출물 위치, 승인 책임자를 문서로 정리하세요. Xcode Cloud 기록과 Mac 노드의 실행 기록을 비교해 동일한 변경이 올바른 결과로 이어지는지 확인합니다. 분기 검증은 최신 결과가 병합 판단에 쓰이는지, 출시 작업은 아카이브와 분배까지 완료됐는지 각각 확인해야 합니다.

팀이 Xcode Cloud와 자체 Mac 실행 노드 사이에서 작업을 나누려면 맥 미니 주문 및 이용 안내를 살펴보고, 원격 Mac의 접속과 운영 방식은 MACCOME 안내에서 확인할 수 있습니다.

현재 Xcode Cloud만으로 운영하면 실행 환경과 작업 흐름을 직접 통제해야 하는 요구를 모두 충족하지 못할 수 있고, 트리거와 출시 검증을 분리하지 않으면 취소 상태를 배포 완료로 오해할 위험도 있습니다. 반면 사내 Mac을 직접 구매하면 장비 조달과 유지 관리가 필요합니다. 물리 장비를 이미 보유하고 안정적인 상시 부하를 처리한다면 직접 운영이 더 맞을 수 있습니다. 임시 검증선이나 별도 CI 실행 노드가 필요하다면 MACCOME의 원격 Mac 접속 방식을 확인해 보세요. 먼저 테스트 워크플로로 인수 기준을 검증한 뒤 운영 작업을 옮기는 편이 안전합니다.