증상 → 기본 브랜치 업데이트와 PR 업데이트가 겹쳐 빌드가 반복됩니다. PR 검증, 기본 브랜치 검증, 예약 작업을 목적별 워크플로로 나누고 각 시작 조건을 좁히세요. 자동 취소는 새 빌드가 이전 결과를 대체해도 되는 조건에서만 유지합니다.
이 글은 PR 검증이 중복 실행되는 독립 개발자, PR·릴리스·예약 워크플로를 나누려는 CI 엔지니어, 검증 기록을 보존하면서 불필요한 빌드를 줄이려는 플랫폼 운영자를 위한 안내입니다.
기본 브랜치 변경 뒤 PR 검증까지 실행된다면 무엇을 확인해야 하나요?
먼저 워크플로가 어떤 시작 조건으로 실행됐는지 기록에서 확인하세요. Xcode Cloud는 브랜치 변경, PR 변경, 태그 변경, 예약 실행이라는 네 가지 시작 조건을 지원합니다. Apple의 Xcode Cloud 시작 조건 설명과 워크플로 참조를 나란히 확인하면, 조건 설정과 실제 트리거 출처를 구별할 수 있습니다.
기본 브랜치에 새 변경이 들어왔을 때의 검증과 PR 변경을 병합 전에 확인하는 일은 목적이 다릅니다. 기본 제안 조건을 그대로 사용하고 있다면, 각 조건이 어떤 변경을 감지하는지 살펴보세요. 두 경로가 같은 워크플로를 시작하도록 설정되어 있다면 빌드가 겹칠 수 있지만, 기록을 확인하기 전에는 이를 실제 원인이라고 단정하지 마세요.
Apple은 첫 워크플로 설정 안내에서 시작 조건을 설정하는 흐름을 설명합니다. 팀에 필요한 검증 목적이 다르면 조건을 분리하거나 워크플로를 나누세요. Xcode Cloud 워크플로 전략 설명도 역할에 맞는 워크플로 설계를 다룹니다.
첫 번째 단계: 대상이 아닌 브랜치에서도 빌드된다면 범위를 좁히세요
모든 브랜치에 적용되는 조건을 쓰고 있다면 임시 브랜치나 릴리스 브랜치의 변경도 실행 대상이 될 수 있습니다. 이때는 워크플로의 목적부터 정리하세요. PR 검증인지, 기본 브랜치 통합 검증인지, 릴리스 검증인지에 따라 대상 브랜치와 시작 조건이 달라져야 합니다.
- [ ] 워크플로 기록에서 실제 트리거 출처를 확인합니다.
- [ ] 해당 워크플로가 검증할 브랜치와 변경 종류를 적습니다.
- [ ] 대상이 아닌 임시·릴리스 브랜치가 조건에 포함되는지 살펴봅니다.
- [ ] 예상한 브랜치만 포함하도록 조건을 조정합니다.
- [ ] 조정 뒤 대상 브랜치에서 시험 실행하고, 실행 기록과 비교합니다.
Apple의 브랜치 시작 조건 설명을 참고해 조건 범위를 검토하세요. 변경 후에는 관련 브랜치에서 시험해 결과를 확인해야 합니다. 설정 화면만 보고 실제로 불필요한 경로가 제거됐다고 판단하지 마세요.
PR 업데이트에 필요한 검사가 빠지거나 대상이 맞지 않나요?
PR 전용 워크플로에서 PR 변경 조건을 선택했는지 확인하세요. 이어서 대상 브랜치 방향이 팀의 병합 정책과 맞는지 살핍니다. PR이 바뀌어도 검사가 시작되지 않는다면 조건 설정과 기록에 표시된 트리거 출처를 함께 확인하세요. 기대한 조건이 실제로 시작한 것이 확인된 뒤에만 그 조건에 맞는 환경 변수를 이용해 스크립트 분기를 구성합니다.
Apple의 환경 변수 참조는 변수마다 사용할 수 있는 조건을 안내합니다. PR 전용 정보가 모든 실행에서 제공된다고 가정하면 안 됩니다. 스크립트가 변수를 읽는 경로와 해당 실행의 시작 조건을 맞춰야 합니다.
PR 검사가 병합 판단에 쓰인다면, 검사 실행 여부만 보지 말고 병합 게이트와 연결됐는지도 확인하세요. PR 병합 요구 사항 설정 안내를 기준으로 어떤 검증 결과가 병합 조건으로 요구되는지 정리할 수 있습니다.
새 커밋이 이전 빌드를 취소한다면 자동 취소를 조건별로 판단하세요
빠르게 연속해서 업데이트하는 PR에서는 새 빌드가 이전 결과를 대체할 수 있습니다. 하지만 릴리스 검증처럼 각 커밋의 기록이 필요한 작업이라면 이전 실행을 취소하는 것이 맞지 않을 수 있습니다. Apple 문서에 따르면 자동 취소는 시작 조건별 설정이며, 기본적으로 각 시작 조건에서 켜져 있습니다. 시작 조건 설정 안내에서 조건별 동작을 확인하세요.
| 시작 조건의 목적 | 자동 취소 판단 | 확인할 내용 |
|---|---|---|
| 최신 PR 변경에 대한 빠른 확인 | 새 결과가 이전 결과를 대체해도 되는지 판단합니다. | 연속 업데이트 후 취소 상태와 최종 결과를 확인합니다. |
| 커밋별로 보존해야 하는 검증 | 각 실행 기록이 필요하다면 끄는 방안을 검토합니다. | 이전 실행이 유지되는지, 병합 판단에 필요한 기록이 남는지 확인합니다. |
| 릴리스 또는 배포 전 확인 | 작업의 순서와 증거 보존 요건에 따라 결정합니다. | 해당 조건에서만 설정을 바꿔 결과를 대조합니다. |
자동 취소 설정을 바꾼 뒤에는 같은 시작 조건에서 연속 업데이트를 시험하세요. 실행 기록에 나타난 시작 출처와 취소 상태를 함께 남기면, 취소가 의도한 조건에만 적용되는지 확인할 수 있습니다.
야간 UI 테스트가 매번 커밋에 반응한다면 실행 경로를 분리하세요
여러 시뮬레이터를 대상으로 하는 UI 테스트처럼 PR의 빠른 피드백과 목적이 다른 작업은 별도 워크플로로 설계하는 편이 관리하기 쉽습니다. PR 워크플로에는 병합 판단에 필요한 검사를 두고, 야간 테스트는 예약 시작 조건에 연결하세요. 실제 예약 주기나 예상 실행 시간은 프로젝트 설정과 작업에 따라 다르므로 임의로 가정하지 않습니다.
| 검증 작업 | 알맞은 시작 경로 | 분리 후 확인 |
|---|---|---|
| PR 변경에 대한 병합 전 검사 | PR 변경 조건 | 대상 브랜치 방향과 PR 업데이트 때의 실행 출처 |
| 기본 브랜치 통합 확인 | 브랜치 변경 조건 | 지정한 브랜치 변경에서만 실행되는지 |
| 야간 UI 검사 | 예약 조건 | 예약 실행과 PR 업데이트가 각각 별도 경로로 기록되는지 |
예약 실행 한 번과 PR 업데이트 한 번을 각각 시험하세요. 두 실행 기록의 워크플로 이름과 트리거 출처가 다르게 나타나는지 확인하면, 설정 의도와 실제 경로가 일치하는지 점검할 수 있습니다. 워크플로 동작 설정 안내도 시작 조건과 실행 동작을 구분해 검토하는 데 참고할 수 있습니다.
실행 횟수나 취소 결과를 설명하기 어렵다면 기록을 대조하세요
한 워크플로의 실행 기록만으로는 반복 실행의 원인을 놓칠 수 있습니다. 같은 변경이 여러 조건을 만족했는지, 별도 워크플로도 실행됐는지, 이전 빌드가 자동 취소됐는지를 각각 확인하세요. 다음 정보를 한 묶음으로 남기면 설정 변경 전후를 비교하기 쉽습니다.
- 워크플로 이름과 시작 조건
- 기록에 표시된 트리거 출처와 대상 브랜치
- 실행 상태와 취소 여부
- 바꾼 조건 및 조정 뒤 수행한 시험 결과
Apple의 Xcode Cloud 작업 흐름 설명을 기준으로 조건과 결과를 한 항목씩 대조하세요. 원인이 확인되지 않았다면 먼저 실행 기록을 더 모으고, 추측으로 조건을 추가하거나 자동 취소를 전부 끄지 마세요. 문제의 원인이 트리거 조건인지 실행 환경인지를 분리해야 불필요한 환경 변경도 피할 수 있습니다.
자주 묻는 질문
PR이 바뀔 때만 빌드하려면 어떻게 설정하나요?
PR 검증용 워크플로의 시작 조건을 PR 변경으로 제한하고, 대상 브랜치가 병합 정책과 맞는지 확인하세요. 기본 브랜치 변경이나 예약 조건을 같은 경로에 섞지 않는 편이 실행 기록을 읽기 쉽습니다. 설정을 바꾼 다음 실제 PR 업데이트로 트리거 출처를 확인하세요.
기본 브랜치 변경 뒤 PR 빌드까지 반복되는 이유는 무엇인가요?
브랜치 변경 조건과 PR 변경 조건이 같은 워크플로를 시작하는지 확인하세요. 두 변경 경로가 모두 실행 원인일 수 있지만, 설정만으로 확정하지 말고 기록의 트리거 출처와 비교해야 합니다. 목적이 다르면 워크플로 또는 시작 조건을 분리하세요.
자동 취소를 꺼야 하나요?
새 커밋이 이전 빌드를 대체해도 되는 빠른 PR 검사라면 자동 취소를 유지할 수 있습니다. 각 커밋의 결과를 보존해야 하는 작업이라면 해당 조건에서 끄는 방안을 시험하세요. 조건별 설정을 바꾸고 연속 업데이트로 취소 결과를 확인해야 합니다.
PR 검사와 야간 UI 테스트를 분리하려면 어떻게 하나요?
PR 검사는 PR 변경 조건에, 야간 UI 테스트는 예약 조건에 각각 연결하는 방식으로 역할을 나누세요. 두 경로가 같은 브랜치나 PR 이벤트에서 함께 실행되지 않는지 점검합니다. 예약 실행과 PR 업데이트를 별도로 시험해 기록을 비교하세요.
PR, 기본 브랜치, 예약 작업을 나누고 조건별 기록으로 결과를 확인했는데도 도구 체인이나 실행 환경을 지속적으로 관리해야 한다면, 그때 실행 호스트를 따로 검토하세요. 기존 클라우드 빌드만으로는 지속 사용 가능한 호스트나 직접 통제하는 macOS 환경이 필요한 작업을 모두 충족하지 못할 수 있습니다. 반면 그런 요구가 없다면 원격 맥을 추가할 필요는 없습니다. 자체 환경이 필요한 경우 원격 맥 활용 사례를 먼저 살펴보고, 실제로 임시 또는 지속 사용 환경이 필요한지 판단한 뒤 KVMFLUX의 이용 안내를 확인하세요.
더 읽어보기
반복되는 빌드에는 전용 맥미니를 준비해 보세요
KVMFLUX에서 실물 맥미니 M4 한 대를 전용 빌드 장비로 대여해 보세요. 원격 접속으로 자동 빌드와 테스트를 실행하고, 필요할 때는 맥 화면을 직접 사용할 수 있습니다. 장비 구매나 공유 장비 대기 없이 애플 실리콘의 성능을 온전히 활용할 수 있습니다. 하루부터 분기까지 필요한 기간만 선택해 원격 맥 개발 환경을 마련해 보세요.