Xcode Cloud에서 의존성을 매번 다시 설치하는 이유는 무엇인가요?

Xcode Cloud는 빌드마다 임시 환경을 사용하므로 작업 공간에 남아 있던 파일을 다음 실행에서 그대로 기대할 수 없습니다. 잠금 파일과 저장소 권한을 먼저 확인하고, post-clone 스크립트에서 매번 내려받는 도구를 줄여야 합니다. 캐시가 필요한 항목과 재현성을 위해 새로 준비해야 하는 항목도 분리해야 합니다.

Xcode Cloud 빌드 시간은 어디에서 확인할 수 있나요?

Xcode와 App Store Connect의 Xcode Cloud 빌드 보고서에서 작업별 로그를 확인할 수 있습니다. 전체 소요 시간만 기록하지 말고 대기, 환경 준비, 컴파일, 테스트, 보관에 걸린 시간을 같은 제출물 기준으로 남겨야 합니다. 사용 데이터도 함께 확인하면 계산 사용량이 어느 작업에서 늘었는지 비교하기 쉽습니다.

테스트가 느릴 때 기기 수를 줄여야 하나요, 워크플로를 나눠야 하나요?

먼저 풀 리퀘스트 검증과 주 브랜치 회귀 테스트가 같은 범위를 실행하는지 확인해야 합니다. 기기 조합이 중복되면 빠른 검증에서는 기기 수를 줄이고, 전체 회귀는 별도 워크플로로 분리하는 편이 낫습니다. 기기 상태와 테스트 자산을 직접 유지해야 한다면 원격 Mac 테스트 노드가 더 적합할 수 있습니다.

어떤 상황에서 Xcode Cloud 작업을 원격 Mac으로 옮겨야 하나요?

반복되는 느린 구간이 임시 환경의 의존성 초기화에서 생기거나, 사설망과 상주 서비스 또는 호스트 수준 권한이 필요하면 이전 후보입니다. 다만 한 번의 실패만으로 전체 파이프라인을 옮기면 안 됩니다. 같은 Scheme과 테스트 범위로 재현한 뒤 빌드 성공, 로그 보존, 재시작 복구, 관리 부담을 함께 확인해야 합니다.

Xcode Cloud 빌드가 너무 느릴 때 어떻게 해야 할까? 2026 원격 Mac 이전 판단

빌드 전체 시간은 비슷한데 어떤 실행은 의존성 준비에서, 다른 실행은 테스트에서 멈춰 있습니까?

Xcode Cloud 빌드가 너무 느릴 때는 즉시 원격 Mac으로 옮기지 말고, 먼저 빌드 보고서에서 대기·준비·컴파일·테스트·보관 시간을 분리해 기록해야 합니다. 반복되는 병목이 임시 환경 초기화, 상주 서비스, 호스트 권한 부족에서 확인될 때만 해당 작업을 원격 Mac으로 옮기고, 표준 빌드와 배포 확인은 Xcode Cloud에 남기는 방식이 안전합니다.

이 글은 Xcode Cloud의 느린 구간을 아직 특정하지 못한 Apple 플랫폼 개발자를 위한 내용입니다. 복잡한 의존성, 캐시, 사설망, 상주 서비스를 다루는 CI 엔지니어와 계산 사용량을 통제하려는 연구개발 책임자도 대상입니다.

먼저 나눠야 할 빌드 단계

Xcode Cloud 빌드 시간은 하나의 숫자가 아닙니다. 큐에서 기다린 시간, 환경을 준비한 시간, 실제 컴파일 시간, 테스트 시간, 보관 또는 업로드 시간이 섞여 있습니다. 전체 실행 시간이 길다는 이유만으로 컴파일러나 원격 Mac을 의심하면 잘못된 결론에 도달하기 쉽습니다.

Apple은 Xcode Cloud 작업 흐름에서 빌드 동작과 실행 결과를 확인할 수 있도록 구성합니다. Apple의 작업 흐름 동작 문서를 기준으로 같은 제출물, 같은 Scheme, 같은 테스트 범위를 골라 비교하십시오.

이번 주에는 다음 기록부터 남기면 됩니다.

정상적으로 끝난 실행 하나를 기준 샘플로 보관합니다.
문제가 발생한 실행의 빌드 식별자와 커밋을 함께 적습니다.
큐 대기, 환경 준비, 의존성 설치, 컴파일, 테스트, 보관 로그를 따로 표시합니다.
사용 데이터에서 특정 워크플로의 계산 사용량이 늘었는지 확인합니다.
한 번 느린 실행과 반복되는 병목을 구분합니다.

Apple의 Xcode Cloud 사용 데이터 확인 방법도 함께 확인해야 합니다. 사용량이 늘었다고 해서 모든 작업이 느려졌다는 뜻은 아닙니다. 테스트 기기 조합이나 보관 작업이 추가되었을 수도 있습니다.

의존성 준비와 임시 환경

Xcode Cloud는 다음 실행에서도 이전 호스트의 상태가 그대로 남아 있다고 가정하는 방식과 맞지 않습니다. Swift Package, CocoaPods, Carthage, 사설 저장소 인증을 post-clone 스크립트에서 반복하면 실제 컴파일보다 준비 단계가 더 길어질 수 있습니다.

먼저 다음 항목을 확인하십시오.

잠금 파일이 커밋되어 같은 의존성 버전을 받는지 확인합니다.
매 실행마다 설치하는 전역 도구가 실제 빌드에 필요한지 검토합니다.
사설 저장소 토큰과 인증 경로가 불필요한 재시도를 일으키지 않는지 확인합니다.
다운로드 실패를 숨기는 명령어와 긴 재시도 구간을 찾습니다.
생성 파일과 내려받은 패키지를 같은 종류의 캐시로 취급하지 않습니다.

Apple의 Xcode Cloud 의존성 준비 문서는 저장소 접근과 의존성 준비 방식을 점검하는 출발점입니다. 잠금 파일과 권한이 정리되어도 매번 큰 도구 체인을 설치해야 한다면, 해당 단계는 원격 Mac 이전 후보가 됩니다.

특히 다음 조건이면 최적화를 멈추고 비교 실행으로 넘어가십시오.

빌드마다 같은 대형 도구를 다시 설치해야 합니다.
사내망이나 특정 호스트 서비스에 연결해야 합니다.
초기화한 뒤 계속 실행되는 프로세스가 필요합니다.
빌드 사이에 보존해야 하는 테스트 자산이 있습니다.
관리자 권한이나 호스트 수준 설정이 필요합니다.

반대로 프로젝트 잠금 파일과 스크립트만 정리하면 준비 시간이 안정되는 표준 앱이라면 Xcode Cloud를 유지하는 편이 관리 부담이 작습니다.

캐시와 클린 빌드의 판별

캐시가 없다고 단정하기 전에 세 종류의 상태를 분리해야 합니다. Derived Data는 컴파일 산출물과 관련된 상태입니다. 의존성 캐시는 내려받은 패키지와 관련됩니다. 사용자 스크립트가 만든 파일은 프로젝트 규칙에 따라 다시 생성해야 하는 별도 상태입니다.

불필요한 Clean Build가 모든 실행에 들어가면 증분 빌드의 이점을 확인할 수 없습니다. 반대로 캐시 잔여물에 의존하면 오래된 생성 파일 때문에 재현성이 흔들릴 수 있습니다.

다음 순서로 확인하십시오.

새 환경에 가까운 실행과 캐시가 재사용되는 실행을 구분합니다.
코드만 바꾼 실행에서 컴파일 단계가 어떻게 달라지는지 봅니다.
의존성 파일을 바꾼 실행에서 실제로 다시 받아야 하는 항목을 확인합니다.
사용자 스크립트가 만든 파일의 생성 위치와 삭제 조건을 기록합니다.
속도가 빨라졌지만 다른 커밋에서 실패하는지 재현 테스트를 합니다.

Xcode Cloud 작업 흐름 참고 문서를 기준으로 캐시 설정과 작업 흐름 옵션을 확인할 수 있습니다. 빠른 한 번의 실행보다, 동일한 커밋을 다시 실행했을 때 결과와 로그가 설명 가능한지가 더 중요합니다.

테스트 범위와 실행 조건

테스트가 느린 팀은 기기 수만 줄이기보다 실행 목적부터 분리해야 합니다. 풀 리퀘스트에서는 빠른 컴파일과 핵심 단위 테스트가 필요하고, 주 브랜치에서는 회귀 테스트와 보관 검증이 필요합니다. 모든 실행에서 UI 테스트, 여러 기기 조합, Archive를 동시에 수행하면 계산 사용량과 대기 시간이 함께 늘어납니다.

다음 기준으로 작업을 나누십시오.

빠른 변경 검증

핵심 단위 테스트만 실행합니다.
중복되는 기기 조합을 줄입니다.
보관과 배포 업로드를 포함하지 않습니다.
이전 커밋이 아직 의미가 없다면 자동 취소 조건을 검토합니다.

주 브랜치 회귀

지원해야 하는 기기 조합을 유지합니다.
UI 테스트와 보관 검증을 별도 단계로 분리합니다.
실패 로그가 어느 테스트 묶음에서 발생했는지 남깁니다.

정기 전체 검증

전체 테스트와 배포 전 검증을 정해진 실행 조건에 둡니다.
외부 서비스 상태와 테스트 자산을 별도로 점검합니다.
결과를 빠른 변경 검증 시간과 섞어 판단하지 않습니다.

Apple은 Xcode Cloud에서 워크플로 실행 조건과 자동 취소 같은 기능을 제공합니다. Xcode Cloud 작업 흐름 참고 문서에서 현재 설정을 확인하십시오. 테스트 자산을 여러 작업에서 공유해야 하거나 특정 시뮬레이터 상태를 계속 유지해야 한다면, 단순히 기기 수를 줄이는 대신 원격 Mac 테스트 풀을 설계하는 편이 낫습니다.

스크립트와 네트워크의 긴 꼬리

짧은 로그만 보면 다운로드가 멈춘 것처럼 보여도 실제 원인은 재시도나 외부 API 응답 대기일 수 있습니다. 사용자 스크립트에는 명확한 종료 코드와 단계별 로그가 필요합니다. 실패를 무시하고 다음 명령을 실행하는 구조는 전체 시간을 늘리고 원인도 숨깁니다.

점검 순서는 다음과 같습니다.

다운로드, 압축 해제, 인증, 업로드 단계를 각각 로그로 남깁니다.
실패했을 때 반환 코드가 실제 워크플로 실패로 이어지는지 확인합니다.
재시도 대상과 즉시 실패해야 하는 오류를 구분합니다.
네트워크 프록시 환경 변수를 읽는지 점검합니다.
토큰과 비밀 키가 로그에 출력되지 않는지 확인합니다.
오래 실행되는 백그라운드 프로세스가 다음 단계의 종료를 막지 않는지 봅니다.

Apple의 사용자 스크립트 문서와 환경 변수 참고 문서를 함께 확인하십시오. 사내망 연결, 상주 프로세스, 호스트에 남겨야 하는 파일이 핵심이라면 임시 환경 안에서 재시도 횟수만 늘리는 방식은 한계가 분명합니다.

자주 확인하는 질문

Xcode Cloud에서 의존성이 매번 다시 설치되는 이유

Xcode Cloud는 빌드마다 임시 환경을 사용하므로 이전 작업 공간에 남은 파일을 다음 실행의 전제로 삼기 어렵습니다. 잠금 파일, 저장소 권한, post-clone 스크립트를 먼저 확인해야 합니다. 매번 내려받는 전역 도구를 줄이고, 캐시로 보존할 상태와 새로 생성해야 할 상태를 분리해야 재현성과 속도를 함께 판단할 수 있습니다.

빌드 시간의 확인 위치

Xcode와 App Store Connect의 Xcode Cloud 빌드 보고서에서 작업별 로그를 확인하십시오. 전체 시간만 복사하지 말고 큐 대기, 환경 준비, 컴파일, 테스트, 보관을 나눠 같은 커밋 기준으로 기록해야 합니다. 사용 데이터까지 대조하면 느린 실행이 실제 실행 시간 때문인지, 추가된 테스트나 보관 작업 때문인지 구별할 수 있습니다.

테스트가 느릴 때 기기 수와 워크플로를 조정하는 방법

풀 리퀘스트 검증과 주 브랜치 회귀가 같은 테스트를 반복하는지 먼저 확인하십시오. 빠른 확인에서는 중복 기기를 줄이고, 전체 기기 조합과 UI 테스트는 별도 워크플로로 분리하는 방식이 일반적으로 더 설명하기 쉽습니다. 다만 테스트 상태나 자산을 직접 보존해야 한다면 원격 Mac 테스트 노드가 더 적합할 수 있습니다.

원격 Mac 이전을 결정하는 조건

한 번의 느린 실행만으로 이전하지 마십시오. 같은 Scheme과 테스트 범위에서 반복적으로 의존성 초기화가 길어지거나, 사설망과 상주 서비스 또는 호스트 권한이 필요할 때 이전을 검토해야 합니다. 이전 뒤에는 빌드 재현, 로그 보존, 재시작 복구, 키 관리, 운영 담당자의 유지 비용을 확인해야 합니다.

이전 여부를 가르는 점검 목록

다음 항목을 실행 로그와 운영 기록에 대조해 보십시오. 확인 표시가 한쪽에만 몰리지 않는다면 전체 파이프라인을 옮기지 말고 해당 작업만 다시 비교해야 합니다.

Xcode Cloud 유지 조건

[ ] 같은 커밋과 Scheme에서 컴파일과 테스트 결과가 반복 재현됩니다.
[ ] 의존성 설치가 잠금 파일과 저장소 권한만으로 안정적으로 끝납니다.
[ ] 사설망, 상주 프로세스, 호스트 수준 권한이 필요하지 않습니다.
[ ] 캐시를 사용해도 오래된 산출물에 의존하지 않습니다.
[ ] 풀 리퀘스트와 주 브랜치의 테스트 범위를 분리할 수 있습니다.

위 조건을 대부분 확인했다면 Xcode Cloud를 유지하고, 워크플로 조건과 캐시 구성을 먼저 다듬으십시오.

원격 Mac 이전 조건

[ ] 같은 도구와 의존성을 매번 다시 설치하는 시간이 반복됩니다.
[ ] 빌드가 사내망, 특정 호스트 서비스 또는 고정된 파일 상태를 요구합니다.
[ ] 관리자 권한이나 실제 Mac 호스트 설정이 필요합니다.
[ ] 테스트 자산과 시뮬레이터 상태를 작업 사이에 보존해야 합니다.
[ ] 재시작 뒤 환경을 복구하고 검증할 운영 절차가 있습니다.

이 조건이 반복되면 가장 느린 작업만 원격 Mac에서 먼저 실행하십시오. 빌드 성공만 보지 말고 로그 보존, 키 관리, 재시작 복구, 정리 작업까지 확인해야 합니다.

두 환경을 함께 사용하는 조건

[ ] Xcode Cloud의 표준 빌드와 배포 확인은 안정적입니다.
[ ] 복잡한 테스트나 사설망 작업만 호스트 제어를 요구합니다.
[ ] 두 환경에서 같은 Scheme과 테스트 범위를 실행할 수 있습니다.
[ ] Xcode 버전, 서명 자산, 환경 변수, 의존성 버전을 문서화할 수 있습니다.
[ ] 원격 Mac 장애 때 Xcode Cloud로 되돌릴 절차가 있습니다.

이 목록을 충족하면 표준 작업은 Xcode Cloud에 남기고, 환경 제어가 필요한 작업만 원격 Mac으로 분리하는 이중 운영이 적합합니다.

세 가지 운영 선택지

Xcode Cloud를 계속 사용하는 경우

의존성 버전과 저장소 권한이 안정적입니다.
표준 빌드와 테스트가 임시 환경에서 재현됩니다.
캐시를 사용해도 결과를 검증할 수 있습니다.
사설망이나 상주 서비스가 필요하지 않습니다.
작업 흐름 조건을 나눠 계산 사용량을 관리할 수 있습니다.

장점은 Apple 생태계 안에서 빌드 보고서와 작업 흐름을 한곳에서 관리하기 쉽다는 점입니다. 단점은 호스트에 오래 남아야 하는 상태와 특수한 네트워크 조건을 직접 통제하기 어렵다는 점입니다.

두 환경을 함께 사용하는 경우

표준 빌드와 배포 확인은 Xcode Cloud가 안정적입니다.
복잡한 테스트나 사설망 작업만 호스트 제어가 필요합니다.
같은 Scheme과 테스트 범위로 두 환경의 결과를 비교할 수 있습니다.
실패 시 다른 환경으로 되돌릴 절차가 있습니다.

이 방식은 가장 유연하지만 두 환경의 Xcode 버전, 서명 자산, 환경 변수, 의존성 버전을 따로 관리해야 합니다. 차이가 문서화되지 않으면 속도보다 환경 불일치가 더 큰 장애가 됩니다.

이번 주 실행 순서

최근 정상 실행과 느린 실행을 같은 커밋 기준으로 선택합니다.
빌드 보고서에서 대기, 준비, 컴파일, 테스트, 보관 시간을 분리합니다.
post-clone 스크립트와 의존성 잠금 파일을 점검합니다.
Clean Build, 캐시 재사용, 증분 변경 결과를 각각 기록합니다.
풀 리퀘스트, 주 브랜치, 정기 전체 테스트의 범위를 나눕니다.
다운로드와 외부 API 호출에 단계별 로그와 종료 코드를 추가합니다.
상주 서비스나 호스트 권한이 필요한 작업만 원격 Mac 후보로 표시합니다.
후보 작업을 같은 Scheme과 테스트 범위로 비교 실행합니다.
빌드 성공뿐 아니라 로그 완전성, 재시작 복구, 키 관리, 유지 비용을 확인합니다.
표준 작업은 Xcode Cloud에 남기고, 이전 효과가 확인된 작업만 원격 Mac 또는 이중 운영으로 전환합니다.

현재 Xcode Cloud에서 전체 파이프라인을 통째로 옮기는 것은 좋은 첫 조치가 아닙니다. 임시 환경의 반복 초기화, 사설망 연결 실패, 상주 서비스 부재처럼 원인이 명확한 작업부터 분리해야 합니다.

만약 현재 방식이 매번 초기화 비용을 만들고, 호스트 상태를 보존할 수 없으며, 네트워크와 권한 문제까지 반복한다면 원격 Mac이 더 적합할 수 있습니다. 반대로 자체 Mac을 직접 구매하면 하드웨어 비용, 상시 전원, 장애 대응, Xcode 환경 관리가 따라옵니다. 일반 클라우드 서버는 macOS 전용 도구와 Apple 플랫폼 빌드를 대신할 수 없고, 가상 환경은 실제 호스트와 다른 제약을 만들 수 있습니다. 이때는 Mac mini 기반 원격 개발 환경을 짧은 주기로 대조해 보고, 재현성과 복구 능력이 확인된 뒤 장기 운영 여부를 결정하는 편이 안전합니다.

먼저 가장 느린 작업 하나만 원격 Mac에서 실행하십시오. 결과가 재현되고 관리 부담이 감당 가능하면 부분 이전을 진행하고, 표준 빌드와 배포 확인은 Xcode Cloud에 남겨 두는 구성이 현실적인 출발점입니다. 필요한 경우 VpsMesh의 원격 Mac 환경에서 테스트 범위와 운영 조건을 확인할 수 있습니다.