Xcode Clean Build 비교: 로컬 MacBook vs 클라우드 M4 물리 서버 실측

증분 컴파일이 아닌 Clean Build를 봐야 하는 이유

평소 개발에서는 Swift 파일을 몇 개 고치면 Xcode가 변경된 모듈만 다시 컴파일합니다. 증분 빌드라면 1분 안팎이면 끝나는 경우가 많죠. 그런데 이 방식은 DerivedData 캐시에 크게 의존하기 때문에, 한 대의 Mac에서 쌓아 둔 캐시가 다른 머신으로 옮겨지지 않습니다. iOS CI/CD 환경이나 Mac mini 클라우드 렌탈을 검토할 때는 아래처럼 캐시 없이 처음부터 돌아가는 상황을 기준으로 봐야 합니다.

• CI/CD Job마다 DerivedData를 비우고 클린 상태에서 시작하는 경우
• Xcode·macOS 업그레이드 후 기존 파생 데이터가 더 이상 유효하지 않을 때
• 개발 Mac을 교체하거나 신규 머신에 빌드 히스토리가 없을 때
• xcodebuild clean build 또는 xcodebuild archive로 Release 패키징을 수행할 때

결국 Xcode Clean Build 소요 시간이 "이 하드웨어가 iOS 빌드 파이프라인을 버틸 수 있는가"를 가장 솔직하게 보여 줍니다. 증분 컴파일 속도는 코딩 패턴과 수정 빈도의 영향을 더 많이 받고, CPU·메모리·냉각 같은 빌드 성능 상한은 덜 드러납니다. 본문의 모든 수치는 전체 Clean Build 기준이며, 세 대의 머신이 동일한 출발선에서 측정되도록 맞춰 두었습니다.

실측 환경 및 테스트 프로젝트 설명

비교가 의미 있으려면 동일 프로젝트·동일 Xcode 버전·비슷한 실내 온도에서 각 머신을 3회씩 독립 실행하고, 중앙값을 결과로 썼습니다. 매 회차 전에 rm -rf ~/Library/Developer/Xcode/DerivedData를 실행해 로컬 파생 데이터를 완전히 지우고, 제로 상태 컴파일을 보장했습니다.

MacBook Air M2는 시장에서 가장 흔한 8코어 구성을 골랐고, 10코어 최상위 모델은 아닙니다. MacBook Pro M1 Pro와 VPSRox Mac mini M4는 모두 10코어 CPU라서, 코어 수는 비슷한데 칩 세대(M1 Pro 대 Apple M4)와 냉각 방식이 장시간 빌드에 어떤 차이를 만드는지 비교하기 좋은 조합입니다.

Clean Build 전체 컴파일 타이밍 결과

아래 표는 3회 Clean Build의 중앙값 wall-clock time과 피크 메모리 압력, Xcode가 보고한 CPU 사용률 최고치를 정리한 것입니다. 메모리 피크는 빌드 중 memory_pressure와 Activity Monitor 샘플링으로 교차 확인했습니다.

특히 눈여겨볼 열은 "3회차 vs 1회차 편차"입니다. MacBook Air M2는 3번째 Clean Build가 1번째보다 38초 느렸는데, 팬이 없는 수동 냉각 구조 때문에 연속 빌드 후 칩이 온도 제한에 걸려 다운클럭된 탓입니다. MacBook Pro M1 Pro는 능동 냉각 덕에 편차가 14초로 줄었지만, 여전히 존재합니다. 데이터센터 랙에 있는 VPSRox Mac mini M4는 3회 간 겨우 2초 차이로, 사실상 측정 오차 수준이었습니다.

Archive 파이프라인 소요 시간 비교

Xcode Archive는 일반 Clean Build보다 프로덕션에 더 가깝습니다. 컴파일 외에도 코드 서명, bitcode 처리(활성화 시), dSYM 생성과 심볼 테이블 패키징이 추가로 들어갑니다. 같은 프로젝트에서 Archive는 Clean Build보다 보통 1.2–1.4배 정도 더 걸립니다.

Archive 단계에서는 Apple M4의 dSYM 생성·심볼 테이블 처리 속도 우위가 더 뚜렷하게 나타났습니다. M1 Pro 대비 약 19% 단축된 수치는, 코어 주파수만 올린 것 이상의 체감입니다. M4의 메모리 대역폭 개선과 Neural Engine 보조 처리 아키텍처와도 맞물려 보입니다.

Fastlane을 쓰는 팀이라면 fastlane gym 한 번이 사실상 Archive + 내보내기 1회입니다. Mac mini M4 원격 Mac 노드에서는 두 단계 합계가 약 5분 30초, 같은 구성의 MacBook Air M2에서는 약 10분이 걸렸습니다. 하루에 dev·staging·production 브랜치를 여러 번 돌려야 한다면, 이 격차가 릴리스 리듬에 직접적인 영향을 줍니다.

발열 스로틀링과 메모리 압력: 로컬 Mac의 숨은 변수

많은 Xcode 빌드 성능 벤치는 콜드 스타트 1회만 보고, 열이 쌓이는(thermal accumulation) 변수는 놓치기 쉽습니다. Apple Silicon은 기체 온도가 임계값을 넘으면 CPU·GPU 주파수를 낮춘 채 유지하는데, 팬 없는 MacBook Air에서 특히 두드러집니다. iOS CI/CD에서 연속 빌드를 돌릴 때는 이 요인을 반드시 같이 봐야 합니다.

MacBook Air M2 발열 스로틀링 관측

테스트 중 MacBook Air M2 하판은 2번째 Clean Build가 끝날 무렵(약 11분 후) 눈에 띄게 뜨거워졌습니다. pmset -g thermlog로 확인한 CPU 전력 제한(CPU_Speed_Limit)은 100에서 약 78까지 떨어졌고, 3번째 빌드는 1번째보다 30초 이상 느려졌습니다. MacBook Air에서 CI를 연속 실행하면 콜드 상태 대비 실제 소요가 15%–30% 높아지는 패턴이 반복되며, 예측하기도 어렵습니다.

MacBook Pro M1 Pro의 능동 냉각 한계

MacBook Pro의 능동 방열 덕분에 상황은 훨씬 나아지지만, 완전히 면역은 아닙니다. 실내 온도가 28°C를 넘거나 Simulator 인스턴스를 여러 개 동시에 띄우면 가끔 경미한 열 스로틀링이 보입니다. 14초 편차는 주로 실내 온도가 조금 높았던 3회차 테스트에서 나왔고, 22°C로 통제한 환경에서는 약 8초로 줄었습니다.

데이터센터 환경의 열 안정성

VPSRox Mac mini 클라우드 렌탈 노드는 데이터센터 상온 랙(보통 18–22°C)에서 돌아가며, M4 Mac mini에도 능동 냉각 팬이 있습니다. 이 두 조건이 겹치면 노트북보다 빌드 시간 일관성이 훨씬 높아집니다. 3회 테스트에서 1회차와 3회차 차이는 2초에 불과했습니다. CI 파이프라인에서 빌드 창을 예측해야 한다면, 이런 안정성 자체가 큰 가치입니다. p99 시간 기준으로 일정을 잡을 수 있고, 예기치 않은 타임아웃 걱정도 줄어듭니다.

메모리 피크와 Swap 쓰기가 속도에 미치는 영향

16 GB 통합 메모리 Mac에서 대형 iOS 프로젝트를 컴파일할 때, 메모리 압력은 빌드 성능을 좌우하는 실질적인 변수입니다. Xcode는 링크·코드 서명 단계에서 여러 도구 프로세스를 동시에 띄우고, Swift 컴파일러도 메모리를 많이 씁니다. vm_stat과 memory_pressure로 피크 사용량을 교차 검증했습니다.

MacBook Air M2는 Clean Build 중 메모리 피크가 약 11.8 GB였고, Extension Target 2개를 병렬로 돌리는 구간에 짧은 swap 쓰기(약 200–400 MB)가 발생했습니다. 이때 SSD 속도가 컴파일 진행에 직접 영향을 줍니다. MacBook Pro M1 Pro는 피크 약 10.9 GB로 3회 모두 swap 없이 끝났고, M1 Pro의 메모리 스케줄링 효율 덕분으로 보입니다. VPSRox Mac mini M4는 피크 약 9.4 GB로, M4의 메모리 사용 최적화가 반영된 수치입니다. 같은 컴파일 작업이라도 M4에서는 중간 객체와 메모리 복사본이 더 적게 필요했습니다.

Swift 코드 20만 줄 이상이거나 Swift Package 의존이 더 많은 프로젝트라면, MacBook Air 16 GB에서 메모리 병목이 더 쉽게 옵니다. 더 큰 저장 공간이 필요하면 VPSRox SSD 확장(+1TB 일 $2.6, +2TB 일 $5.2)을 선택할 수 있지만, 16 GB를 넘는 메모리 사양은 아직 제공하지 않으므로 Mac mini 클라우드 렌탈을 검토할 때 미리 염두에 두세요.

로컬 MacBook으로도 충분한 경우

모든 iOS 팀에 원격 Mac이나 클라우드 노드가 필요한 것은 아닙니다. 아래에 해당한다면 손에 든 MacBook만으로도 충분할 수 있습니다.

• 프로젝트 규모가 작음(< 3만 줄 Swift): Clean Build가 Apple Silicon MacBook 어디서든 2분 안에 끝나면 성능 병목은 거의 없습니다.
• CI 빈도가 낮음(하루 < 5회 빌드): Clean Build마다 7–8분이 걸려도 하루 총 빌드 시간은 40분 이내로, 허용 범위에 들어갑니다.
• 개인 독립 개발자, 로컬 디버깅 중심: 증분 컴파일이 대부분이고 Clean Build는 릴리스 때만 필요하다면 MacBook Pro M1 Pro 이상이면 충분합니다.
• MacBook Pro M3/M4 보유: Apple 최신 MacBook Pro(M4 Max)의 냉각·성능은 Mac mini M4와 거의 비슷하며, 차이는 단회 속도보다 지속 빌드 안정성 쪽에 있습니다.

반대로 Mac mini 클라우드 렌탈을 진지하게 검토해야 하는 경우도 분명합니다. CI/CD 파이프라인에서 하루 20회 이상 빌드를 돌리거나, 팀 전체가 동일한 빌드 환경을 공유해야 할 때("내 Mac에선 됐는데"를 줄이려면), MacBook Air를 쓰면서 프로젝트가 계속 커지거나, 여러 독립 프로젝트의 빌드를 격리해 동시에 유지해야 할 때입니다.

종합 판단: 비용과 이득 계산

원격 Mac으로 전환하는 데는 분명한 비용이 따릅니다. VPSRox 전용 Mac mini M4는 일 $21.8, 한 달 내내 쓰면 약 $109.1/월입니다. 신규 MacBook Pro보다는 저렴하지만, 지속적인 지출은 필요합니다. 다만 다른 각도에서 보면, 무엇을 절약하는지도 함께 따져 봐야 합니다.

5명 iOS 팀을 예로 들면, 하루 평균 30회 Clean Build·Xcode Archive를 돌린다고 가정해 보겠습니다. MacBook Air M2에서 평균 8분(가벼운 스로틀링 포함)이면 총 240분입니다. 같은 작업량을 VPSRox Mac mini M4에서 처리하면 약 123분. 하루 약 117분의 머신 시간을 절약하는 셈입니다. CI에서 여러 브랜치를 병렬로 돌리는 팀이라면, 이 차이가 더 빠른 코드 리뷰 피드백과 릴리스 창으로 이어집니다.

자주 간과하는 숨은 비용은 빌드 대기 중의 주의력 전환입니다. 5분 이내 대기는 진행률을 지켜보는 경우가 많지만, 8분을 넘기면 다른 일로 넘어갔다가 돌아오는 걸 잊기 쉽습니다. flow state 연구에 따르면 능동적 방해 1회당 약 20분 후에야 효율적인 작업 상태로 복귀합니다. 월 $109.1 노드 비용은 순수 서버 렌탈가만이 아니라 "집중을 유지하는 도구 비용"에 더 가깝게 읽을 수 있습니다.