Xcode 호스팅 빌드와 직접 관리 Cloud Mac 선택법

팀에 이미 정상적으로 작동하는 iOS 파이프라인이 있어도 의존성을 추가하거나 Xcode를 전환하고 코드 서명 설정을 조정할 때마다 같은 논쟁이 반복됩니다. 호스팅 빌드를 계속 사용할지, 아니면 작업을 직접 관리하는 Cloud Mac으로 옮길지에 관한 문제입니다. 먼저 개별 빌드가 몇 초 더 빨라지는지를 비교해서는 안 됩니다. 장기 비용을 실제로 좌우하는 요소는 환경 재현 가능성, 캐시 통제력, 실패 당시 상태의 보존 여부, 그리고 엔지니어가 부담해야 할 운영 업무의 양입니다.

먼저 워크로드를 세 가지로 분류하기

감으로 플랫폼을 선택하지 말고 최근 2주 동안 실행된 작업부터 집계해야 합니다. 병합 검사, 아카이브 및 배포, 임시 진단의 세 가지 유형으로 나누어 기록하는 것이 좋습니다. 병합 검사는 일반적으로 수명 주기가 짧고 입력이 명확하며 실패해도 다시 실행할 수 있습니다. 아카이브 및 배포에는 서명 자료, 산출물 보관, 엄격한 버전 고정이 필요합니다. 임시 진단에서는 엔지니어가 동일한 환경에 접속해 문제를 재현할 수 있어야 합니다.

최소한 다음 데이터를 기록해야 합니다.

한 번 성공했다고 해서 프로세스가 안정적인 것은 아닙니다. 동일한 커밋으로 최소 세 번 연속 실행한 다음, 의존성은 변경하지 않고 애플리케이션 소스 코드만 수정한 커밋으로 캐시 동작을 다시 검증해야 합니다.

통일된 환경 지문 만들기

두 방식 모두 동일한 환경 검사 스크립트를 사용해야 합니다. xcodebuild -version만 출력하지 말고 시스템 버전, 현재 개발자 디렉터리, SDK, Ruby 및 패키지 관리자 상태도 기록해야 합니다. 환경 지문 파일은 매 작업의 일반 산출물로 보관하고, 실패가 발생하면 애플리케이션 코드를 확인하기 전에 먼저 이 파일을 비교해야 합니다.

#!/bin/zsh
set -euo pipefail

mkdir -p artifacts
{
  sw_vers
  uname -m
  xcodebuild -version
  xcode-select -p
  xcrun --sdk iphoneos --show-sdk-version
  ruby --version
  git --version
} > artifacts/environment.txt

export DEVELOPER_DIR="/Applications/Xcode.app/Contents/Developer"
xcodebuild \
  -workspace App.xcworkspace \
  -scheme App \
  -configuration Release \
  -derivedDataPath "$PWD/.build/DerivedData" \
  -resultBundlePath "$PWD/artifacts/App.xcresult" \
  build

DEVELOPER_DIR가 검증하지 않은 경로를 가리켜서는 안 됩니다. 직접 관리 환경에는 여러 Xcode 버전을 유지할 수 있지만 파이프라인에서 사용할 버전을 명시적으로 선택해야 합니다. 호스팅 환경에서는 작업 시작 시 실제 버전을 확인하고, 일치하지 않으면 가능한 한 빨리 종료해야 합니다. 그래야 작업이 아카이브 단계에 도달한 뒤에야 SDK 차이가 드러나는 상황을 피할 수 있습니다.

캐시, 서명, 동시 실행을 각각 검증하기

전체 디렉터리를 캐시로 옮기지 않기

캐시 키에는 최소한 Xcode 주 버전, 아키텍처, 의존성 잠금 파일의 해시가 포함되어야 합니다. SwiftPM, CocoaPods, 빌드 중간 디렉터리는 무효화 조건이 서로 다르므로 별도로 관리해야 합니다. 사용자 디렉터리 전체를 묶어서 복원하면 기존 권한, 임시 파일, 숨겨진 설정까지 새 작업에 유입되므로 피해야 합니다.

직접 관리 Cloud Mac은 대용량 의존성 캐시를 계속 유지해야 하는 파이프라인에 적합합니다. 단, 저장소마다 독립된 작업 디렉터리를 사용하고 캐시를 삭제한 뒤에도 전체 빌드가 가능한지 정기적으로 검증해야 합니다. 호스팅 빌드의 캐시 수명 주기는 일반적으로 플랫폼이 관리합니다. 따라서 캐시는 성공의 전제 조건이 아니라 최적화 수단으로 다뤄야 합니다.

서명 자료는 작업 중에만 노출하기

서명 자료는 작업 시작 시 통제된 저장소에서 주입하고, 완료되는 즉시 임시 사본을 제거해야 합니다. 로그에 암호, 키 내용 또는 전체 파일 경로를 출력해서는 안 됩니다. 어떤 방식을 사용하든 성공 경로뿐만 아니라 실패 경로에서도 정리 작업이 실행되는지 확인해야 합니다.

동시 실행 테스트는 두 개의 작업부터 시작해 DerivedData, 시뮬레이터, Keychain 또는 고정 포트를 공유하는지 살펴봐야 합니다. 공유되는 쓰기 가능 상태가 하나라도 있으면 동시 실행 수가 증가할 때 간헐적 장애가 확대될 수 있습니다.

장애 훈련으로 복구 가능성 검증하기

실제 배포가 실패한 뒤에야 복구 절차를 검증해서는 안 됩니다. 존재하지 않는 scheme을 의도적으로 지정하기, 의존성 캐시 하나 삭제하기, 테스트 케이스가 실패를 반환하게 만들기, 아카이브 전에 작업 종료하기 등 네 가지 비파괴 훈련을 설계할 수 있습니다. 각 훈련에서 종료 코드, 로그 마지막 부분, result bundle, 임시 서명 자료, 작업 디렉터리 상태를 모두 확인해야 합니다.

호스팅 빌드에서는 로그만으로 실패 원인을 충분히 설명할 수 있는지, 환경을 다시 재현할 수 있는지, 재실행할 때 입력이 완전히 동일한지를 중점적으로 확인해야 합니다. 직접 관리 Cloud Mac에서는 남아 있는 프로세스, 마운트 디렉터리, 포트가 다음 작업을 오염시키지 않는지도 확인해야 합니다. 작업마다 고유한 디렉터리를 사용하고 종료 훅으로 자식 프로세스를 회수하는 것이 좋습니다.

workdir="$(mktemp -d "$PWD/.job.XXXXXX")"
cleanup() {
  jobs -p | xargs -r kill 2>/dev/null || true
  rm -rf "$workdir"
}
trap cleanup EXIT INT TERM

정리 스크립트는 먼저 테스트 디렉터리에서 검증해 광범위한 와일드카드가 다른 작업에 영향을 주지 않도록 해야 합니다. 보존할 로그와 빌드 산출물은 독립된 artifacts 디렉터리로 먼저 복사한 다음 정리 작업을 실행해야 합니다.

구호가 아닌 통제권을 기준으로 결정하기

프로젝트가 일반적인 의존성을 사용하고 작업 시간이 짧으며, 실패 후 바로 다시 실행할 수 있고, 팀이 머신 상태를 유지·관리하고 싶지 않다면 호스팅 빌드가 대체로 더 적합합니다. 여러 Xcode 버전을 고정하거나 캐시를 장기간 재사용해야 하고, 특수 도구를 실행하거나 현장에 접속해 진단해야 하며, 장시간 작업을 계속 실행해야 한다면 직접 관리 Cloud Mac이 명확한 경계를 세우기 더 쉽습니다.

두 방식을 나누어 사용할 수도 있습니다. 병합 요청에서는 가벼운 테스트를 실행하고, 안정 브랜치에서는 직접 관리 환경을 이용해 아카이브와 심층 진단을 수행하는 방식입니다. 중요한 점은 양쪽에서 동일한 환경 지문, 잠금 파일, 빌드 진입점, 산출물 명명 규칙을 사용해 서로 호환되지 않는 두 개의 파이프라인이 생기지 않도록 하는 것입니다.

최종 검증에서는 가장 빠른 한 번의 결과가 아니라 반복 실행 성공률, 환경 차이의 수, 캐시 삭제 후 복구 가능성, 실패 증거의 완전성, 수동 개입 단계 수를 평가해야 합니다. 이 결과를 저장소의 의사결정 기록에 남기고 Xcode 주 버전, 의존성 체계 또는 작업 규모가 바뀔 때 다시 평가하기로 정해야 합니다. 그래야 선택한 방식이 영구적인 가정으로 굳어지지 않습니다.

자주 묻는 질문