로컬 MacBook 빌드가 점점 느려지는 이유
인디 개발자나 소규모 팀의 일상 기기는 MacBook Air나 입문형 MacBook Pro인 경우가 많고,
메모리는 8 GB 또는 16 GB에 머무는 경우가 많습니다. Xcode, Simulator, Chrome 탭 여러 개, Slack, Preview를 동시에 켜 두면
swift-frontend와 ld에 남는 물리 메모리는 거의 없습니다.
macOS는 DerivedData와 인덱스 캐시를 SSD로 밀어 냅니다. 겉보기엔 「몇 분 더 기다리면 된다」지만,
실제로는 swap 때문에 메모리 대역폭이 잡아먹히는 상태이고, 이후 증분 빌드마다 조금씩 더 느려집니다.
자주 놓치는 요인이 열 스로틀링입니다. 노트북 방열 한계 때문에 전체 빌드가 8~15분 이어지면 CPU 클럭이 피크 대비 15~25% 떨어지고, 팬 소음은 화상 회의를 방해합니다. 데이터센터 랙의 Mac mini는 냉각이 안정적이어 「빌드 전용기」로 적합합니다. 손에 든 기기는 편집에 집중하고, 무거운 작업은 원격 베어메탈 노드에 맡기는 구성이 현실적입니다.
이 글이 답하는 질문은 분명합니다: 실제 프로젝트 규모에서 SpinMac 클라우드 M4 전용 노드로 빌드를 옮기면 얼마나 빨라질까? 비용은? 클라우드가 과한 경우는?
테스트 환경과 측정 방법
재현성을 위해 양쪽 모두 동일 Xcode 버전, 동일 DerivedData 삭제 절차를 사용했고,
xcodebuild와 /usr/bin/time -l로 시간을 재어 GUI 인덱싱·백그라운드 작업의 영향을 줄였습니다.
각 라운드 전 rm -rf ~/Library/Developer/Xcode/DerivedData/*를 실행하고 불필요한 앱은 종료했습니다.
로컬 A: MacBook Air M2 · 8코어 CPU · 8 GB 통합 메모리 · 256 GB SSD · macOS 15 Sequoia.
로컬 B(대조): MacBook Pro 14" M1 Pro · 10코어 CPU · 16 GB 통합 메모리 · 512 GB SSD · 동일 OS.
클라우드: SpinMac Mac mini M4 · 10코어 CPU · 16 GB 통합 메모리 · 256 GB NVMe SSD · 1 Gbps 전용 대역폭(싱가포르 노드).
툴체인: Xcode 16.4, Command Line Tools 버전 일치.
샘플링: memory_pressure로 swap, powermetrics 5초 간격 CPU 주파수, 팬 소음은 기기에서 30 cm 거리 피크 측정.
테스트 앱은 자체 SwiftUI 제품 「PulseTrack」: Swift 약 8.2만 줄, 메인 App·Share Extension·Widget Extension·Watch App 4개 target, Swift Package Manager 서드파티 6개(Alamofire, Kingfisher 등). App Store 기준 중형 규모. 거대 monorepo는 아니지만 8 GB 기기에는 충분히 빡빡한 크기입니다.
세 가지 빌드 시나리오와 명령
일상 개발부터 스토어 제출까지, 개발자가 매일 마주치는 세 패턴을 골랐습니다.
시나리오 1: 전체 클린 빌드(Debug)
CI 최초 checkout이나 브랜치 전환 후 콜드 스타트를 가정합니다:
xcodebuild -scheme PulseTrack -configuration Debug -destination 'platform=iOS Simulator,name=iPhone 16 Pro' clean build CODE_SIGNING_ALLOWED=NO
서명을 끄면 키체인 차이를 배제하고 컴파일만 비교합니다. 기기별 3회 실행 후 중앙값을 사용했습니다.
시나리오 2: 단일 파일 증분 빌드
Swift 소스 한 파일(UI 로직 약 40줄)만 수정한 뒤 clean 없이 build. 빈도는 가장 높고, 여유 메모리와 인덱스 상태에 매우 민감합니다.
시나리오 3: Release Archive
Distribution 인증서로 전체 Archive, 컴파일러 최적화(-O)와 bitcode 제거 활성화.
CPU 점유 시간이 가장 길고, 노트북에서 스로틀이 나기 쉬운 시나리오입니다.
로컬 B(M1 Pro 16 GB)는 「이미 고사양 노트북을 가진 경우」 대조군으로,
클라우드 M4 우위가 칩 세대 때문인지 빌드 전용·다른 앱과 메모리 경쟁 없음 때문인지 가릅니다.
클라우드 측정은 SSH에서 수행했고, 네트워크 지연은 wall-clock에 포함하지 않았습니다(소스는 사전 rsync 완료).
소요 시간 비교: 핵심 수치
아래 표는 3라운드 중앙값입니다. 클라우드 M4는 세 시나리오 모두 앞섰고, 차이가 가장 큰 것은 Archive. 최적화 단계는 오래 풀로드가 지속되므로 랙 냉각의 안정성이 효과를 냅니다.
| 시나리오 | MacBook Air M2 · 8 GB | MacBook Pro M1 Pro · 16 GB | SpinMac M4 · 16 GB |
|---|---|---|---|
| 전체 클린 빌드(Debug) | 11′42″ | 7′08″ | 5′18″ |
| 단일 파일 증분 빌드 | 48″ | 26″ | 17″ |
| Release Archive | 18′35″ | 11′20″ | 8′12″ |
| 피크 swap 사용량 | 2.8 GB | 0.4 GB | 0 GB |
| 빌드 중 팬 소음 피크 | 46 dB | 41 dB | (데이터센터·해당 없음) |
MacBook Air M2는 클린 빌드 6분쯤에 뚜렷한 swap이 발생했습니다(memory_pressure에서
system-wide memory free percentage가 4%까지 하락).
이후 swift-frontend 평균 CPU 사용률은 680%(멀티코어 합산)에서 약 420%로 떨어집니다.
Xcode가 느려진 게 아니라 커널이 페이징 중입니다.
클라우드 M4는 물리 메모리가 충분해 10코어가 피크 시 85~92%를 유지했고, 스로틀 기록은 없었습니다.
참고로 M1 Pro 16 GB 로컬 클린 빌드는 클라우드 M4보다 약 34%만 느립니다. Air 8 GB의 2.2배 격차보다 훨씬 작습니다. 메모리 용량이 칩 세대보다 먼저 병목이 되는 전형입니다. 이미 16 GB 이상 로컬 기기가 있다면 클라우드 가치는 「절대 속도」보다 「빌드 전용·일상 작업 방해 없음」 쪽으로 이동합니다.
병행 부하: Simulator 켠 채 빌드
위 표는 「깨끗한 환경」의 이상값입니다. 현실에서는 Simulator로 UI를 보면서 전체 리빌드를 돌리는 경우가 많습니다. Build Configuration 전환이나 DerivedData 삭제 후 재빌드 등이 해당합니다.
이 조합 부하에서 Air M2 Simulator는 20 fps 미만으로 떨어지기도 하고, 클린 빌드는 11′42″에서 14′28″로 늘었습니다. M1 Pro는 8′45″로 쓸 만했습니다. 클라우드 M4는 VNC로 Simulator를 원격 미리보기하면서 빌드해도 약 40초만 증가(5′58″)했습니다. Simulator와 컴파일이 각각 여유 메모리·CPU를 갖고 8 GB 풀을 서로 잡아먹지 않기 때문입니다.
클린 빌드 3회 후 Air의 DerivedData는 4.7 GB. 256 GB SSD에서는 감당 가능하지만 8 GB RAM과 인덱스 캐시·빌드 산출물이 경쟁합니다. 클라우드 노드는 +1 TB SSD 확장(일 $2.5부터)을 지원해 여러 브랜치 캐시를 유지하려는 팀에 유용합니다.
비교를 망치는 함정
아래가 맞지 않으면 결과가 30% 이상 어긋날 수 있습니다:
-
01
인덱싱 끝나기 전 빌드
첫 실행 시 백그라운드 인덱싱이 2~4 GB를 쓸 수 있습니다. 진행이 끝날 때까지 기다리거나
xcodebuild로 GUI 노이즈를 피하세요. -
02
Build System 설정 불일치
양쪽 모두 New Build System과 동일한
COMPILER_INDEX_STORE_ENABLE이어야 증분 빌드 시간을 비교할 수 있습니다. -
03
클라우드 소스 동기화 방식
rsync --delete로 작업 트리를 맞추세요. FUSE 클라우드 드라이브에서 컴파일하면 네트워크 I/O가 숨은 병목이 됩니다. -
04
시뮬레이터 아키텍처 차이
Apple Silicon 시뮬레이터는 기본 arm64. 한쪽만 x86_64를 빌드하면 시간이 거의 두 배가 될 수 있습니다.
일부 VPS 업체의 「macOS 클라우드」는 가상화 또는 공유 호스트로, 완전한 Xcode 툴체인·안정 CPU 할당이 보장되지 않습니다. 본 테스트는 과매도 영향을 제거하려 SpinMac 베어메탈 Mac mini M4 전용 노드를 사용했습니다. 가상 환경 클린 빌드는 실행마다 40~60% 흔들리기 쉬워 기준선으로 부적합합니다.
원격 빌드 워크플로: 로컬 편집, 클라우드 빌드
8 GB 기기이거나 회의와 개발을 병행하는 16 GB 노트북을 써도 Mac Studio로 갈아탈 필요는 없습니다. 현실적인 분업은 Xcode 컴파일과 Simulator 무거운 부하를 클라우드로 옮기고, 손에는 에디터와 Git만 남기는 것입니다.
흔한 상황: 오후 데모 직전에 전체 빌드가 필요한 브랜치가 push되고, Air 팬이 최대로 돌아 Zoom이 끊깁니다. 실력 문제가 아니라 연산이 빌드에 빼앗긴 겁니다. 클라우드 M4는 일 $21.2부터. 릴리스 주에만 켜고 평소엔 끄면. 하드웨어 업그레이드보다 저렴한 경우가 많습니다.
-
01
SpinMac 노드 개통
가까운 리전 선택(싱가포르 / 일본(도쿄) / 한국(서울) / 중국 홍콩 / 미국 동부). 결제 후 1~5분 내 SSH·VNC 수령. 도움말 센터 참고.
-
02
코드·의존성 동기화
최초
rsync -avz --exclude DerivedData ./ user@host:~/PulseTrack/로 저장소 전송. SPM은 클라우드에서xcodebuild -resolvePackageDependencies실행. -
03
로컬 편집·원격 빌드
VS Code Remote SSH나 Cursor Remote로 원격 트리 편집, 빌드 명령은 SSH 세션에서 실행. UI 확인은 브라우저 VNC + Simulator.
-
04
CI Runner 연결(선택)
팀 자동 빌드는 동일 노드를 GitHub Actions self-hosted runner로 등록. 클라우드 Mac Xcode CI/CD 실전 가이드 참고.
5개 리전 모두 1 Gbps 전용 대역폭과 독립 공인 IPv4를 제공합니다.
서울 사무실 네트워크에서 한국(서울) 노드로 rsync 증분 동기(약 120개 변경 파일) 시 2~4초. 증분 빌드 흐름에 거의 영향 없습니다.
국내 사용자 대상 앱이라면 서울 노드가 지연·대역폭 균형에 유리하고, APAC 전반이라면 싱가포르도 좋은 선택입니다.
비용과 선택: 클라우드가 맞는 때
| 상황 | 권장 | 클라우드 역할 |
|---|---|---|
| MacBook Air 8 GB, swap에 시달림 | 컴파일·Simulator를 클라우드 M4로 | 일 단위 임대, 릴리스 집중 주 |
| 16 GB 로컬, 속도는 되나 팬 소음이 회의 방해 | 전체/Archive는 클라우드, 증분은 로컬 | 하이브리드로 방해 감소 |
| 3~10인 팀, 공유 빌드기 1대 | 상시 클라우드 M4 + CI Runner | 월 $106.1, 전용 베어메탈 서버·대기 없음 |
| Mac Studio 64 GB, 병목 없음 | 클라우드 필수 아님 | 병렬 Archive는 TB5 클러스터 검토 |
대략 계산: 클린 빌드를 12분에서 5분으로 줄이고 하루 6번 빌드하면 약 42분 절약. 엔지니어 시급으로 환산하면 반나절이면 일 $21.2 노드 비용을 회수할 수 있습니다. 팬 소음, 회의 품질, 배터리 손실은 아직 미포함입니다. 클라우드는 로컬 개발기 대체가 아니라, 컴파일에 아무도 방해하지 않는 전용 베어메탈 서버를 주는 선택입니다.
빌드 파이프라인 자동화를 계획 중이라면 GitHub Actions와 Jenkins 실전 가이드를, 여러 대 병렬 Archive는 Thunderbolt 5 클러스터 실측을 참고하세요.