Xcode 빌드 속도 실측: 로컬 MacBook vs 클라우드 M4 독점 노드

왜 이 비교를 했는가?

iOS 개발 커뮤니티에서 「빌드가 느리다」는 말은 거의 공통된 불만입니다. Swift 프론트엔드 의미 분석, 모듈 의존성 그래프 구성, 대형 바이너리 링크—어느 단계든 CPU와 메모리를 많이 씁니다. 개인 개발자에게 가장 흔한 개발기는 MacBook Air입니다. 가볍고 배터리도 좋지만, 8 GB 메모리와 패시브 냉각은 Xcode 전체 빌드 앞에서 자주 한계에 부딪힙니다.

클라우드 Mac 임대 자체는 새로운 개념이 아닙니다. 다만 시장에는 가상화 인스턴스나 공유 호스트가 많아, 실제 빌드 체감이 스펙 시트와 어긋나는 경우가 적지 않습니다. ZilCloud가 제공하는 것은 물리 Mac mini M4 독점입니다. 가상화 계층도 없고 오버커밋도 없으며, 공식 스펙과 동일합니다. 10코어 CPU(성능 4 + 효율 6), 16 GB 통합 메모리, 256 GB NVMe SSD, 1 Gbps 독점 공인 대역폭.

이번 테스트가 답하려는 질문은 구체적입니다. 로컬 PC를 바꾸지 않고 빌드 작업만 클라우드 M4 노드로 옮기면 얼마나 빨라질까? 일상 개발 루프는 더 매끄러워질까? 비용 대비 체감 가치는 있는가? 아래 데이터는 동일 테스트 머신·동일 스크립트·동일 Xcode 버전으로 재현 가능합니다.

테스트 프로젝트와 방법론

테스트 대상은 실제 상용 SwiftUI 앱(이하 RetailApp)이며, 규모는 다음과 같습니다.

약 186개 Swift 모듈(로컬 Swift Package 3개, CocoaPods 의존성 2개 포함), 1,240개 이상 소스 파일, Release 설정 링크 산출물 약 84 MB. Swift 6 엄격 동시성 검사, SwiftLint·SwiftFormat 빌드 단계 스크립트를 사용합니다. 독립 개발자 기준으로는 이미 「중대형」에 해당하며, 8 GB 머신에서 클린 빌드 시 눈에 띄는 메모리 압박이 발생합니다.

통일된 빌드 명령

GUI 조작 차이를 피하기 위해 모든 시간 측정은 CLI xcodebuild로 수행했으며, /usr/bin/time -l로 벽시계 시간과 피크 메모리를 기록했습니다.

# Clean build folder first
xcodebuild -project RetailApp.xcodeproj \
  -scheme RetailApp \
  -configuration Release \
  -destination 'generic/platform=iOS' \
  clean build \
  CODE_SIGNING_ALLOWED=NO \
  | tee /tmp/xcodebuild.log

# Wall-clock timing wrapper
/usr/bin/time -l xcodebuild -project RetailApp.xcodeproj \
  -scheme RetailApp \
  -configuration Release \
  -destination 'generic/platform=iOS' \
  build CODE_SIGNING_ALLOWED=NO

각 머신은 테스트 전 sudo purge로 파일 캐시를 비운 뒤, 클린 빌드를 3회 연속 실행해 중앙값을 취했습니다. 증분 빌드는 단일 View 파일(약 120줄 SwiftUI) 수정 후 build(clean 없음)를 3회 중앙값으로 측정했습니다. 테스트 중 Spotlight 인덱싱과 기타 백그라운드 앱을 종료했고, 로컬에서는 저전력 모드 OFF, powermetrics로 팬 곡선을 샘플링했습니다.

원격 빌드 워크플로우

클라우드 노드에는 git clone으로 코드를 가져왔습니다(저장소 약 380 MB). 의존성은 pod install과 swift package resolve를 클라우드에서 실행해 양쪽 빌드 환경을 맞췄습니다. 로컬 개발 시 SSH로 클라우드에서 직접 xcodebuild를 돌리거나, MacBook의 VS Code Remote SSH로 코드를 편집하고 빌드 명령만 원격에서 실행하는 방식도 가능합니다. 로컬은 코딩과 로그 확인에 집중할 수 있습니다.

클린 빌드(Clean Build) 실측 데이터

클린 빌드는 격차가 가장 크게 드러나는 시나리오입니다. Derived Data 캐시가 없어 Swift 프론트엔드, Clang 백엔드, 링커가 전부 돌아갑니다. 아래는 중앙값 결과이며, 로컬 대조군으로 동료의 MacBook Pro M3 Pro 18 GB(「본체 업그레이드」 참고용)도 포함했습니다.

클라우드 M4는 MacBook Air M2보다 약 2.18배 빠르며, M3 Pro 18 GB MacBook Pro보다도 약 20% 빠릅니다. 격차는 칩 세대만의 문제가 아닙니다. Air의 8 GB 메모리는 빌드 피크에서 4.2 GB 스왑을 유발했고, powermetrics 기준 성능 코어는 빌드 6분 후 열 벽으로 3.4 GHz에서 약 2.6 GHz로 떨어졌습니다. Mac mini M4는 데이터센터 냉각 환경에서 고클럭을 유지했고, 10코어 활용률이 거의 최대에 가깝게 올라갔으며 16 GB 통합 메모리 전 구간에서 swap이 없었습니다.

체감 차이도 큽니다. 로컬 Air에서 클린 빌드를 돌리면 2분 안에 팬이 최고 속도에 달하고 키보드 영역이 뜨겁습니다. 그동안 편하게 코딩하기 어렵습니다. 클라우드 빌드는 전부 원격에서 진행되므로 로컬 노트북은 조용하고 서늘한 상태를 유지하며 문서를 보거나 화상 회의를 병행할 수 있습니다.

증분 빌드와 일상 개발 루프

일상 개발에서는 증분 빌드 빈도가 클린 빌드보다 훨씬 높습니다. SwiftUI View 파일 하나를 수정한 뒤 다시 build하는 시간이 「개발 루프가 매끄러운지」를 가늠하는 더 현실적인 지표입니다.

증분 빌드 격차는 클린 빌드보다 작지만, 클라우드 M4가 모든 시나리오에서 앞섰습니다. 특히 Bridging Header 수정처럼 한 곳을 바꿔도 연쇄 재빌드가 일어나는 경우 Air는 거의 13분, 클라우드는 5분 19초입니다. Objective-C 브리지 레이어를 자주 손대는 레거시 마이그레이션 프로젝트에서 체감 이득이 큽니다.

발열, 소음, 안정성

빌드 성능은 「몇 초 빠르다」만의 문제가 아닙니다. 장시간 안정적으로 출력을 유지할 수 있는지도 중요합니다. 2시간 동안 15분 간격으로 클린 빌드를 반복(총 8회)하며 안정성을 측정했습니다.

MacBook Air는 지속 빌드 부하에서 뚜렷한 열 감쇠가 나타났습니다. 8회차가 1회차보다 21% 느렸고, swap 사용량은 4.2 GB에서 6.1 GB로 증가했습니다. 클라우드 Mac mini M4는 8회 변동이 2% 이내였으며, ZilCloud가 공표한 99.9% SLA 기대와 부합합니다. 장시간 CI나 대량 Archive 작업에서는 안정성 자체가 생산성입니다.

시뮬레이터와 Archive 패키징

일반 build 외에 개발자가 자주 쓰는 두 시나리오도 측정했습니다.

iOS 시뮬레이터 기동 + 설치: 클라우드 M4에서 iPhone 16 Pro 시뮬레이터를 띄우고 RetailApp Release 패키지를 설치할 때, xcrun simctl boot부터 앱 첫 화면 렌더링까지 약 38초였습니다. Air M2에서는 약 52초이며, 시뮬레이터 메모리 점유로 전체 시스템이 더 빡빡해집니다. 브라우저 VNC로 시뮬레이터 화면을 바로 볼 수 있어 빠른 UI 검수에 적합하고, 더 높은 프레임이 필요하면 서드파티 VNC 클라이언트를 쓰면 됩니다.

Archive 및 IPA export: 클라우드에서 xcodebuild archive + -exportArchive 총 14분 22초(코드 서명 포함), Air M2는 28분 51초였습니다. 서명 인증서는 Keychain에서 export한 뒤 클라우드 노드로 가져오면 로컬과 동일한 흐름입니다. IPA는 scp로 로컬에 받거나 TestFlight에 직접 업로드할 수 있으며, 서울 노드에서 Apple 서버까지 지연은 약 45 ms, 84 MB IPA 업로드는 약 2분 40초가 걸렸습니다.

비용과 사용 전략

성능 수치만으로는 장기 사용 여부를 결정하기 어렵습니다. ZilCloud는 일 단위 과금이며, 표준 Mac mini M4 노드는 $20.9/일, 월 $103.9/월, 계약 묶임 없음. 이번 실측을 바탕으로 한 전형적 전략은 다음과 같습니다.

전략 A — 빌드 전용 노드(일 단위): 클린 빌드, 패키징, 통합 테스트가 필요한 날만 임대. 예를 들어 주 2일 집중 빌드면 월 약 $20.9 × 8 ≈ $167로, 클린 빌드마다 11분 이상을 절약하고 로컬 Air는 빌드에 묶이지 않습니다.

전략 B — 상시 CI 노드(월 단위): Git 저장소 Webhook에 연결해 push마다 클라우드 xcodebuild test를 실행. 월 $103.9이며, GitHub Actions macOS runner 분당 과금(약 $0.08/분, 20분 클린 빌드 한 번에 $1.6)과 비교하면 빈번한 팀은 일주일 안에 회수 가능합니다.

전략 C — 단기 스프린트(주 단위): 출시 전 2주 $55.9/주로 임대해 대규모 리팩터링·마이그레이션·TestFlight 제출을 몰아친 뒤 반납. 유휴 비용이 없습니다.

로컬에 M3 Pro 이상·메모리 18 GB 이상 MacBook Pro가 있다면 클라우드 이점은 절대 속도보다 「본체 자원 해방」과 CI 병렬에 더 가깝습니다. 하지만 8 GB / 16 GB MacBook Air 사용자에게 클라우드 M4는 가성비 좋은 가속 경로입니다. M4 Mac mini를 새로 사도 $599부터이고, 모니터·운영 부담은 별도입니다.

GitHub Actions와 자체 CI 비교

많은 팀이 이미 GitHub Actions macos-latest runner를 씁니다. 동일 프로젝트를 비공개 저장소에 push해 표준 workflow로 비교했습니다.

jobs:
  build:
    runs-on: macos-14
    steps:
      - uses: actions/checkout@v4
      - name: Install deps
        run: pod install --repo-update
      - name: Build
        run: xcodebuild ... clean build

GitHub Actions 클린 빌드 총 시간(대기 + 의존성 설치 + 컴파일)은 약 34분 20초였습니다. 대기 8분, pod install 6분, 실제 컴파일 20분대. ZilCloud 노드는 Derived Data와 CocoaPods 캐시를 로컬 디스크에 유지할 수 있어 두 번째부터 유사 파이프라인을 12분 이내로 줄일 수 있고, 대기도 없습니다.

Actions의 강점은 GitHub 통합과 무운영입니다. 약점은 공유 runner 성능 편차, 느린 콜드 스타트, 제한적인 캐시 전략, 피크 시간대 대기입니다. 둘은 배타적이지 않습니다. lint·단위 테스트 게이트는 GitHub Actions, Release Archive는 ZilCloud 독점 노드—이렇게 나누는 팀이 많습니다.

원격 개발 체험과 시행착오

빌드를 클라우드로 옮기면 워크플로우가 바뀝니다. 실측에서 정리한 경험과 함정입니다.

SSH 편집 + 클라우드 빌드(권장): 로컬 VS Code / Cursor에서 Remote SSH로 클라우드에 접속하면 코드 보완과 LSP가 원격에서 돌아갑니다. 저장 후 터미널에서 xcodebuild를 실행하면 됩니다. 서울 노드 기준 서울 KT 회선 ping 약 8 ms, 부산 약 18 ms로 타이핑 체감은 거의 없습니다. 대용량 git push는 git-lfs 사용을 권장합니다.

브라우저 VNC: ZilCloud 콘솔에서 원클릭 웹 VNC로 Xcode GUI나 시뮬레이터가 필요한 작업을 처리할 수 있습니다. 정적 UI 검수에는 기본 프레임으로 충분하고, 애니메이션 디버깅은 RealVNC 같은 클라이언트가 낫습니다.

함정 1 — Keychain 인증서 동기화: 클라우드 첫 서명 시 .p12와 provisioning profile을 가져와야 합니다. Keychain에서 codesign이 개인키에 접근하도록 설정하지 않으면 errSecInternalComponent가 납니다.

함정 2 — Xcode 명령줄 도구 경로: 신규 개통 노드는 sudo xcode-select -s /Applications/Xcode.app가 필요할 때가 있습니다. 그렇지 않으면 xcodebuild가 Command Line Tools를 가리켜 SDK를 찾지 못합니다.

함정 3 — 타임존과 로그: 클라우드 기본은 UTC입니다. CI 로그 정렬을 위해 sudo systemsetup -settimezone Asia/Seoul로 팀과 맞추는 것을 권장합니다.

로컬 MacBook만으로 충분한가? 클라우드 노드가 필요한 이유

데이터를 읽고 나면 자연스럽게 이런 질문이 생깁니다. 하드웨어를 업그레이드하거나 프로젝트를 최적화하면 굳이 클라우드가 필요 없지 않나?

예산이 넉넉하다면 MacBook Pro M4 Pro 36 GB로 올리면 메모리·냉각 문제는 근본적으로 완화됩니다. 다만 본체 가격이 보통 $2,499부터이고, 전체 빌드 중에는 여전히 본체가 묶입니다. Figma, Slack, Zoom을 동시에 쓰기 어렵습니다. 독립 개발자나 소규모 팀에게 일시불 부담은 작지 않습니다.

AWS EC2 Mac 인스턴스도 대안으로 자주 거론됩니다. Apple 공식 하드웨어이지만 시간당 약 $1.083, 최소 24시간(약 $26/일)이라 ZilCloud $20.9/일보다 비싸고 일 단위 유연 기동·Thunderbolt 5 병렬 확장도 지원하지 않습니다. 게다가 전용 호스트 임대 모델이라 개통·할당 절차가 무겁고, 임시 프로젝트에는 ZilCloud 결제 후 1–5분 자동 개통이 더 맞습니다.

네이버 클라우드·카카오 i 클라우드 같은 국내 퍼블릭 클라우드는 Linux·GPU 워크로드에 강하지만, Xcode 빌드·iOS 코드 서명·TestFlight·Apple Neural Engine 추론은 macOS 네이티브 환경이 필수라 대체할 수 없습니다. macOS VM을 우회 제공하는 서비스도 있으나 Apple 라이선스·안정성 리스크가 따릅니다.

GitHub Actions, Bitrise 등 공유 CI는 표준화된 파이프라인에 적합하지만, 클린 빌드 시간·캐시 지속성·시뮬레이터 상호작용에서는 독점 물리 노드만큼 통제하기 어렵습니다. 출시일 피크에 10–20분 대기는 흔하고, 그 시간이 곧 일정 리스크입니다.

클라우드 Mac mini M4의 포지션은 분명합니다. 로컬 PC를 바꾸지 않고, 항상 풀 파워로 돌아가는 빌드 전용 머신을 필요할 때만 쓴다는 것입니다. 10코어 CPU 독점, 16 GB 통합 메모리, 1 Gbps 독점 대역폭, 싱가포르·도쿄·서울·홍콩·미국 동부 등 5개 노드 선택, 일 $20.9부터, 오버커밋·이웃 간섭 없음. 스프린트 주간만 쓰다 반납하거나, 상시 CI 노드로 두는 것도 가능합니다. 새 Mac 구매나 장기 클라우드 계약이 주지 못하는 유연성입니다.

글 초반의 장면으로 돌아가면, MacBook Air가 iOS 개발을 못 하는 것은 아닙니다. 다만 프로젝트가 커지면 빌드는 클라우드 M4에, 조용함과 배터리는 로컬에 남기는 분업이 현재로서는 가장 합리적인 선택일 수 있습니다.