Thunderbolt 5 병렬 클러스터 실측: 여러 대 Mac mini 네트워크 구성 시 얼마나 빨라질까?

한 대로 충분한데, 왜 여러 대를 병렬로?

Mac mini M4(10코어, 16 GB 통합 메모리)로 중형 SwiftUI 프로젝트 전체 Archive를 돌리면 대략 4분 전후—— 개인 개발자나 「하루 몇 번 push」 수준의 소규모 팀에는 보통 충분합니다. 「머신이 부족하다」고 느끼는 경우는 주로 세 가지입니다.

첫째, 다중 scheme / 다중 App 매트릭스: 하나의 monorepo에서 메인 App, Watch, Widget, Debug/Release 변형을 동시에 빌드해야 하고, 한 대에서는 직렬 대기로 실제 소요 시간이 target 수에 비례해 늘어납니다. 둘째, 공유 컴파일 캐시: 한 대의 DerivedData나 SPM 캐시를 다른 Runner에 밀어 넣을 때, 공인망 1 Gbps 전용 대역으로는 수 GB 동기화만 1분 단위가 걸립니다. 셋째, 분산 추론·렌더링 샤딩: 여러 대가 중간 산출물을 자주 주고받으며, 이더넷 지연과 대역이 CPU보다 먼저 한계에 닿습니다.

이 글은 「클라우드 Mac을 빌려야 하나」(요금·주문 페이지 이야기)가 아니라 한 가지에 집중합니다: 동일 노드 Mac mini를 Thunderbolt 5로 병렬 연결했을 때, 머신 간 데이터 경로는 얼마나 빨라지며 병렬 빌드 실시간에 무엇을 의미하는가.

Thunderbolt 5 병렬이 실제로 연결하는 것

흔한 오해를 먼저 짚습니다. TB5 병렬은 세 대 CPU를 하나의 「슈퍼 Mac」으로 합치는 것이 아닙니다. 투명한 분산 컴파일러가 자동으로 켜지는 것도 아닙니다. 제공되는 것은 동일 노드 내 머신 간 고속 물리 상호 연결—— 공칭 80 Gbps로, 각 호스트의 1 Gbps 전용 공인망 포트를 크게 상회합니다.

ZovCloud에서는 병렬이 동일 데이터센터 노드 내 인스턴스에만 적용됩니다. 싱가포르와 도쿄 머신을 TB5로 이을 수는 없습니다. 개통 후 데이터센터에서 Thunderbolt 케이블과 브리지를 구성하면 macOS에 Thunderbolt Bridge / 고속 브리지 인터페이스가 나타나고, 그 위에서 TCP, SMB/NFS 마운트, 객체 캐시를 구성합니다.

가치 모델은 분명합니다: CPU는 대별로 독립 스케줄되고, 머신 간 데이터 이동 비용만 크게 줄어듭니다. 파이프라인이 대용량 산출물 상호 동기화를 애초에 요구하지 않으면, 단일 직렬이나 「각자 빌드 후 공인망 업로드」로 충분——병렬 옵션은 불필요합니다.

토폴로지와 준비 상태: 링크가 진짜 올라왔는지 확인

구성은 「컨트롤러 + Worker 2대」 삼각형: node-a가 스케줄·산출물 집계, node-b / node-c가 병렬 빌드. TB5 옵션 결제 후(실행 중 인스턴스 콘솔에서 추가 가능) 수 분 내 세 대 모두 Thunderbolt 브리지가 표시되었습니다. 처리량 측정 전 아래 3단계를 고정으로 수행해, 일반 이더넷만 재는 실수를 막습니다.

1. 01
   브리지 인터페이스 존재 확인

   각 호스트에서 ifconfig 또는 「시스템 설정 → 네트워크」. Thunderbolt Bridge(또는 DC 측 고속 브리지 이름)와 동일 서브넷 사설 IP가 있어야 합니다.

2. 02
   양방향 ping 및 MTU 확인

   3대 상호 ping -c 20. RTT는 서브 밀리초~약 1 ms. 수 ms로 지터가 크면 공인망 경로일 가능성——라우팅 테이블 확인.

3. 03
   동기화 대상 IP를 TB 세그먼트에 고정

   빌드 스크립트 동기화 주소를 공인 IPv4가 아닌 TB 망 IP로. rsync / SMB가 1 Gbps 출구로 돌아가지 않게 합니다.

처리량 실측: TB5 vs 1 Gbps 공인망

1차는 iperf3로 TCP 단방향 처리량. 기준선: 각 머신 공인 IPv4 상호 통신(랙 내 스위치지만 1 Gbps 전용 포트 상한). 테스트 경로: Thunderbolt Bridge 사설 세그먼트. 각 60초 × 3회, 중앙값 보고.

사용자 공간 TCP로 이론 80 Gbps를 채우기 어렵습니다——프로토콜 오버헤드와 단일 스트림 스케줄링 때문이며, 이번에는 메모리 간(디스크 비의존) 측정이었습니다. 실무에서는 「1 Gbps보다 1~2자릿수 빠르다」만으로도 동기화 전략을 바꿀 수 있습니다: 예전에 델타·압축하던 수 GB 캐시를 통째로 밀 수 있어 스크립트가 오히려 단순해집니다.

대용량 파일과 공유 캐시: 실시간 차이는 어디서

처리량 숫자가 좋아도 파이프라인이 반드시 빨라지는 것은 아닙니다——큰 블롭을 실제로 옮기는지가 핵심입니다. 8.4 GB DerivedData 스냅샷(Module Cache·중간 산출물)을 SMB로 동기화하고, 2.1 GB .xcarchive를 컨트롤러로 회수했습니다.

결론은 직설적입니다: 「머신 간 GB급 산출물 이동」 단계는 TB5가 동기화 시간을 거의 무시할 수준으로 줄입니다. 각 머신이 git clone, 의존성 다운로드, 객체 스토리지 업로드를 독립적으로 하고 상호 접근이 거의 없다면, 체감 가속은 0에 가깝고 병렬 옵션 비용은 낭비입니다.

병렬 Archive: 3대로 실시간을 얼마나 줄일 수 있나

2차는 CI에 가깝습니다: 동일 commit, 3 scheme(메인 App Release, Widget Release, Watch Release)을 3 Worker에서 병렬 xcodebuild archive; 대조는 한 대에서 3 Archive 직렬. 컨트롤러가 소스 스냅샷 배포(TB5), 산출물 수집·간단 검증. 각 3회 중앙값.

병렬 실시간 4분 18초는 가장 느린 scheme 단일 시간(메인 App Archive 약 4분 05초)에 가깝고, 소스/캐시 배포·산출물 회수 약 9초 추가——1 Gbps면 동기화만 1분 이상 늘어 3대 병렬 이점의 대부분이 네트워크에 잡아먹힙니다.

강조합니다: 단축 비율은 선형 「3대면 3배」가 아닙니다. scheme별 시간 차, 인증서 잠금 해제, SPM 해석 경합으로 실시간은 가장 느린 다리에서 멈춥니다. TB5의 역할은 「배포·집계」를 분 단위에서 초 단위로 압축해 병렬 스케줄링 자체를 의미 있게 만드는 것; CPU 측 가속은 여러 물리 머신이 동시에 계산하기 때문이지, 케이블이 단일 코어 Swift 컴파일을 마법처럼 빠르게 하지는 않습니다.

시행착오: 실제로 막혔던 네 가지

1. 동기화 스크립트 NIC 지정 오류. 첫 iperf가 「900 Mbps뿐」——조사 결과 공인 IP 사용. 브리지 세그먼트로 바꾸자 즉시 50 Gbps+. CI 환경 변수에 CLUSTER_IFACE, PEER_TB_IP 명시 권장.

2. SMB 기본 서명이 처리량을 제한. macOS 기본 SMB는 고속 링크에서 CPU가 먼저 포화. 단기 벤치는 서명 정책 조정; 운영은 보안·속도 트레이드오프, 또는 TB IP에 바인딩한 rsync over SSH로 캐시 디렉터리 동기화.

3. 키체인·서명은 대별 준비. 병렬은 인증서 문제를 해결하지 않습니다. 3 Worker 모두 Distribution 인증서와 unlock 필요. 자동화 스크립트는 공유하되 키는 머신별 분리——공유 키체인 디렉터리 동시 쓰기 손상 방지.

4. 디스크가 네트워크보다 먼저 병목. 256 GB 시스템 디스크에서 3대 동시 DerivedData 쓰기 시 I/O wait이 가끔 상승. 거대 monorepo·야간 배치가 많으면 SSD +1TB / +2TB 확장을 먼저 검토한 뒤 병렬 노드 추가—— TB5가 빨라도 로컬 디스크가 못 따라가면 소용없습니다.

TB5를 켜야 할 때, 안 켜도 될 때

실측을 의사결정 표로 압축해 「80 Gbps 보고 무조건 개통」 실수를 막습니다:

요금: ZovCloud 기본 노드 일 $19.8, 주 $53.5, 월 $99.1, 분기 $269.6; Thunderbolt 5 병렬 옵션 일 $1.8, 주 $4.9, 월 $9.1, 분기 $24.8. 3대 월 상주 + 병렬은 동기화·직렬 대기가 큐를 명확히 막는 팀에 적합; 릴리스 주에 일 단위로 병렬을 켰다 끄는 것도 가능——데이터센터 구리선·스위치를 직접 사지 않아도 됩니다.

「빠르게 잰 것」에서 「일상 운영」으로: 클라우드 전용 클러스터

사무실에서 Mac mini 3대를 직접 병렬하면 비슷한 처리량이 나올 수 있지만, 랙·케이블·정전· 고정 공인 IP·인증서 로테이션·야간 무인 운영을 직접 감당합니다. 많은 모바일 팀에게 진짜 장벽은 운영 비용—— 「iperf3를 칠 수 있는가」가 아닙니다.

Linux VM 메시가 아무리 빨라도 Apple 도구체인 관문은 못 넘습니다: 완전한 macOS 없이는 정당한 xcodebuild / codesign / TestFlight 경로가 없습니다. 공유 macOS 클라우드에 오버셀링이 있으면 병렬 빌드 시 메모리·디스크 지터가 「이론적 병렬」을 무너뜨립니다.

ZovCloud는 각 호스트를 전용 물리 Mac mini M4(10코어, 16 GB, 1 Gbps 전용 대역, 전체 관리자 권한)로 유지하고, 머신 간 고속 경로가 필요할 때 동일 노드에서 Thunderbolt 5 병렬을 켜 80 Gbps 물리 채널을 사용합니다. 결제 후 1–5분 개통, 리전은 싱가포르, 일본(도쿄), 한국(서울), 홍콩, 미국 동부. 브라우저 VNC, SSH, 서드파티 VNC 모두 가능; Runner 부착 방식은 단일과 동일하고, 동기화용 Bridge IP만 추가됩니다.

1. 01
   병렬 분할 전략을 먼저 정하기

   App / scheme / 플랫폼으로 작업을 나누고, 각 머신에 독립 Archive target이 있는지 확인한 뒤 대수 결정.

2. 02
   동일 노드 다중 주문 후 TB5 선택

   주문 페이지에서 동일 리전 여러 인스턴스를 고르고 Thunderbolt 5 병렬 옵션 체크. 세부는 요금 페이지 참고.

3. 03
   Bridge IP 바인딩 후 Runner 부착

   준비 확인 후 캐시 동기화·산출물 회수를 TB 세그먼트로. 공인 포트는 git, 객체 스토리지, 릴리스용으로 유지.

Thunderbolt 5 병렬이 푸는 문제는 「여러 실제 Mac 사이에서 데이터를 충분히 빠르게 옮기는 방법」이지, 「한 대를 세 대처럼 보이게 하는 것」이 아닙니다. 매트릭스 빌드와 캐시 동기화가 이미 실시간을 잡아먹고 있다면, 동일 노드 전용 클러스터 + 80 Gbps 상호 연결이 단일 대기열을 늘리는 것보다 합리적인 경우가 많습니다; 단일 App·저빈도 릴리스 단계라면 안정적인 M4 전용 노드 1대에 예산을 두는 편이 현명합니다.