M4 클라우드 노드에서의 컴파일과 패키징: 파이프라인을 이전했습니다

VPSSpark의 주력 모델은 Mac mini M4입니다. Xcode 실행과 Docker, 스크립트를 함께 쓰는 프로젝트에서 CPU와 메모리의 차이는 「컴파일 대기」와 「코드 작성 계속」의 차이로 직결됩니다. 레거시 프로젝트의 전체 빌드를 M4 노드로 옮긴 뒤 클린 컴파일 시간이 약 절반으로 줄었습니다——절약되는 것은 시간만이 아니라 중단된 몰입감이기도 합니다. 원격 데스크톱에서는 특히 두드러집니다.

클라우드 Mac이 어울리는 빌드 시나리오는?

이전 전에 주요 시나리오를 불편 정도별로 정리했습니다:

「컴파일된다」에서 「본류 개발도 클라우드로」까지

클라우드 Mac을 단순 원격 화면으로만 보지 않습니다. 클린 빌드 시간이 크게 줄면, 팀은 단위 테스트·정적 분석·산출물 서명 검증을 모두 같은 고정 환경에서 실행해 「내 머신에서는 통과하는데 동료 환경에서 안 된다」는 소통을 줄입니다.

Apple Silicon에서는 링커와 Swift 컴파일러가 메모리 대역폭에 더 민감합니다. Swift Package, 혼합 모듈, 대형 Asset Catalog가 많다면 컴파일 피크 시 swap이 CPU 이점을 갉아먹지 않도록 로컬 여유보다 조금 큰 RAM을 클라우드에 확보하세요. 내부에서는 같은 프로젝트를 여러 노드에서 반복 측정해 wall time과 꼬리 지연의 중앙값을 비교합니다.

캐시 세 가지: DerivedData · CocoaPods · SPM

캐시는 빌드 속도에 가장 직접적인 레버입니다. 다음 세 디렉토리는 이미지 베이스라인에 구워 버전 태그를 붙이길 권장합니다:

~/Library/Developer/Xcode/DerivedData/   # Xcode 증분 컴파일 캐시
~/Library/Caches/CocoaPods/              # CocoaPods 다운로드 캐시
~/.spm-cache/ (or ~/.swiftpm/)           # Swift Package Manager 캐시

# 일상 반복: 이 세션에 필요한 차분만 동기화
# 진짜 콜드 스타트는 이미지 대규모 업그레이드 시 일괄 처리

일상 반복 시에는 해당 세션에 필요한 차분만 동기화하고, 진짜 콜드 스타트는 이미지 대규모 업그레이드 때 일괄 처리하면 속도를 유지하면서 이그레스 대역폭 낭비를 줄일 수 있습니다.

관측, 롤백, 그리고 새벽에 전화 받을 사람

클라우드 빌드는 wall time만이 아니라 장애 발생 시 빠른 원인 규명도 중요합니다. 전형적인 장애를 네 가지로 분류하고 각각 독립된 알림 임계값과 온콜 런북을 작성해 둡니다:

• 이미지 드리프트 — Xcode 버전 또는 CLT 자동 업데이트
• 의존성 해결 타임아웃 — SPM / CocoaPods 페치 타임아웃
• 서명 인증서 만료 — 배포 인증서 또는 Provisioning Profile 만료
• Git 원격 도달 불가 — 서브모듈 DNS 지연이 빌드 지연으로 오해

팀이 여러 지역에서 협업한다면, 「마지막으로 성공한 야간 빌드 산출물 해시」와 「실패 로그 일부」를 읽기 전용 채널에 자동 동기화해 아침 인수인계 비용을 줄이세요. 누군가 자리를 비워도 환경 문제인지 코드 회귀인지 판단할 수 있는 사람이 남아 있습니다.

롤백은 전체 디스크 백업만이 답이 아닙니다——많은 팀에게 「직전까지 동작했던 Xcode + CLT + CocoaPods 조합」을 담은 경량 이미지가 전체 사용자 홈을 복원하는 것보다 빠릅니다. 빌드 이력에 연결된 이미지 태그를 콘솔에서 제안하는 기능을 순차적으로 도입할 예정입니다.

야간 파이프라인에서 서브모듈 페치 시간을 별도 지표로 측정하세요: 서브모듈 호스트 DNS가 느리면 컴파일이 느린 것처럼 보일 수 있습니다. DNS와 Git 핸드셰이크 시간을 컴파일 단계에서 분리하면 이미지 내 resolver 설정을 바꿔야 할지 서브모듈을 내부에 미러할지 판단하기 쉽고, M4 노드 CPU 사용률과 함께 추세를 보면 증설 필요인지 네트워크 문제인지도 드러납니다.