Thunderbolt 5 병렬 클러스터 실측: 여러 대 Mac mini 네트워킹으로 얼마나 빨라질까?

단일 머신으로 충분한데, 왜 TB5 병렬 이야기를 하는가

많은 팀이 처음 빌린 클라우드 Mac 한 대로 일상 iOS 빌드를 이미 커버한다. M4·16 GB 메모리면 전체 Archive도 3~4분이면 끝난다. 병목은 단일 CPU보다 병렬도에 쏠리기 쉽다—— App target 6개, Extension 3개, Widget 2개인데 CI 스크립트는 한 대에서 직렬 대기; 또는 monorepo의 Swift Package 의존이 거대해 clean build가 15분을 넘고, 각 Runner가 수십 GB DerivedData와 소스 스냅샷을 동기화해야 하는 상황이다.

흔한 대응은 「클라우드 Mac을 몇 대 더 빌려 작업을 나눈다」다. 논리적으로는 맞다. 그러나 각 머신이 독립 1 Gbps 공인 포트만으로 빌드 캐시를 주고받으면, 40 GB 워크스페이스 동기화에 6~8분이 걸려 병렬화 이익을 잡아먹는다. Thunderbolt 5 병렬이 푸는 것은 동일 랙 안 머신 간 데이터 플레인이다. PixVPS는 동일 노드의 여러 Mac mini를 TB5 물리 케이블로 연결해 공인 80 Gbps 대역을 확보한다. 컴파일 팜 노드가 아티팩트를 동기화하거나 작업을 배분할 때 공인망 출구를 빼앗지 않는다.

오해를 먼저 짚자. TB5는 한 대의 CPU 코어 수를 늘리지 않으며, M4 세 대를 「30코어 한 대」로 합성하지도 않는다. 가속하는 것은 멀티 머신 협업 시 데이터 전송과 스케줄링 효율이다. 고통이 「한 대 컴파일이 느리다」면 TB5 추가 효과는 제한적이다. 「머신 간 캐시 복사가 느리다」「야간 배치 총 시간이 안 줄어든다」면 TB5가 맞는 처방이다.

80 Gbps 물리 연결 vs 1 Gbps 공인망: 무엇이 다른가

각 PixVPS Mac mini에는 독립 공인 IPv4와 1 Gbps 포트가 있어 SSH·VNC·TestFlight 업로드 같은 「대외」 트래픽에 적합하다. 반면 머신 A가 30 GB DerivedData를 머신 B에 보내 증분 빌드를 시키려면, 공인망 경유 시 데이터가 랙 밖으로 나갔다 들어온다. 이론 상한은 약 125 MB/s이나 TCP 윈도와 디스크 쓰기 영향으로 실측은 108~112 MB/s에 안정했고, 30 GB 전송에 약 4분 30초가 걸렸다.

TB5 병렬은 랙 내 전용 데이터 채널을 만든다. 시스템 정보에서 상호 연결 포트는 Thunderbolt 5 브리지 네트워크(bridge0 또는 전용 en* 인터페이스)로 보이고 공인 en0과 분리된다. 노드 1과 2 사이에서 iperf3로 60초 TCP 처리량을 측정한 결과, 단방향 평균 58.4 Gbps(약 7.3 GB/s), 양방향 합계 약 94 Gbps. rsync로 30 GB 혼합 크기 파일(DerivedData 구조 모사) 전송 시간은 42초로, 공인 직송의 약 6.4배였다.

58 Gbps가 공인 80 Gbps보다 낮은 것은 정상이다. 프로토콜 오버헤드, CPU 소프트 인터럽트, NVMe 지속 쓰기(단일 디스크 약 2.8 GB/s 순차 쓰기)가 겹치기 때문이다. 컴파일 팜에서는 병목이 「네트워크」에서 「디스크 I/O」나 「링커 단일 스레드」로 옮기기 쉬워, 뒤에서 Xcode 병렬 테스트 가속비가 선형 3배에 못 미치는 이유도 여기 있다.

병렬 활성화 후 인수 테스트: 시스템에 무엇이 보여야 하는가

주문 구성 페이지에서 「Thunderbolt 5 멀티 머신 병렬」 옵션을 체크(일 $1.9, 월 $9.5)하고, 동일 노드·동일 주문 배치의 여러 인스턴스 모두에 같은 옵션을 켠다. PixVPS가 랙 측에서 물리 배선을 마친다. 각 머신에 로그인한 뒤 아래로 상호 연결 준비를 확인한다.

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

   각 머신에서 networksetup -listallhardwareports 실행 시 Thunderbolt Bridge 또는 전용 TB 인터페이스가 보여야 한다. ifconfig로 상호 연결 세그먼트 IP(보통 169.254.x.x 또는 DC 내부망, 실제 할당 따름)를 찾는다.

2. 02
   노드 간 ping 및 대역 빠른 테스트

   노드 A에서: ping -c 10 <노드B TB 내부 IP>, 지연은 < 1 ms가 목표. brew install iperf3 후 B에서 iperf3 -s, A에서 iperf3 -c <B TB IP> -t 30, 수십 Gbps급 처리량을 확인한다.

3. 03
   SSH 상호 신뢰(TB 내부망만)

   ~/.ssh/config에 클러스터 노드 Host 별칭을 쓰고 Hostname에 TB 내부 IP를 넣어 대용량 동기화가 공인망을 우회하게 한다. 예: Host m4-node2 → Hostname 10.20.0.12(IP는 콘솔 「클러스터 상호 연결 정보」 기준).

4. 04
   공유 아티팩트 디렉터리 마운트(선택)

   간단한 방법은 rsync --delete로 DerivedData를 주기 동기화. 고급은 NFS over TB나 sshfs로 읽기 전용 캐시 마운트. 이번 테스트는 「마스터 노드 빌드 + rsync 증분 푸시」 방식으로 스크립트 비용이 최소였다.

테스트 1: 야간 다중 App 매트릭스 병렬 Archive

첫 시나리오는 「독립 App 4개를 가진 팀이 30분 안에 전체 Release Archive를 끝내고 싶다」는 경우다. 단일 직렬: 4 scheme을 순서대로 xcodebuild archive, 각 clean build 평균 3분 48초, 합계 15분 12초(Export·업로드 미포함).

3대 병렬 전략: GitHub Actions workflow matrix로 4 scheme을 3 Runner에 배분(2+1+1). 각 머신이 독립적으로 코드 체크아웃과 서명 환경을 갖고 DerivedData는 공유하지 않는다. 벽시계 시간은 가장 느린 한 대에 달린다: 4분 05초(가장 느린 scheme은 Swift Package 해석으로 17초 더 걸림). 직렬 대비 대기 시간 약 73% 절감.

이 시나리오에서는 TB5 대역을 거의 쓰지 않는다——각 머신 빌드는 대용량 재전송이 없다. 병렬 가치는 「동일 주문 배치·동일 랙·저지연 스케줄링」에 있다. App 2개·월 1회 릴리스면 3대 + TB5는 과함. target 5개 이상·매일 야간 배치 빌드면 매트릭스 병렬이 타당하다.

테스트 2: monorepo 공유 DerivedData 증분 동기화

두 번째 시나리오는 TB5 대역 이점에 가깝다. 마스터 노드가 첫 전체 빌드 후 28 GB DerivedData를 두 슬레이브에 동기화하고, 각 슬레이브는 담당 framework target만 증분 컴파일한다.

흐름: 노드 1에서 clean archive(3분 52초) → rsync -avz --progress -e ssh ~/Library/Developer/Xcode/DerivedData/MyMonorepo-* m4-node2:~/cache/ → 노드 2·3이 병렬로 각자 framework target 증분 archive.

TB5 경로는 공인 동기화보다 약 3분 40초 단축, 총 흐름은 단일 직렬보다 약 5분 빠르다. DerivedData가 50 GB를 넘거나 PR마다 캐시를 푸시하는 운영이면 격차가 더 벌어진다. 「멀티 머신 협업 + 빌드 캐시 공유」 팀이 TB5를 우선 검토해야 하는 이유다.

테스트 3: distcc 시험과 현실의 간극

M4 세 대를 distcc로 분산 C/Swift 컴파일에 쓰는 시험도 했다. 마스터가 전처리된 컴파일 단위를 배포하고 슬레이브가 .o를 반환한다. 이론상 3대면 약 3배인데 clean build는 3분 52초에서 2분 34초(약 1.5배)에 그쳤고 선형 가속과는 멀었다.

이유는 단순하다. Xcode 신규 빌드 시스템은 Swift 명시적 모듈과 높은 병렬을 기본 켜고, 단일 M4가 이미 10코어를 꽉 쓴다. distcc의 원격 스케줄링, 헤더 동기화, 링크의 마스터 회귀가 이익을 상쇄한다. Swift 컴파일 단위에는 모듈 의존 순서가 있어 순수 C 프로젝트처럼 자유롭게 쪼개기 어렵다.

결론: 전형적 iOS/Swift 공정에서는 「각 머신이 독립 job」이 「단일 distcc 분할」보다 현실적이다. TB5 가치는 각 머신이 일관된 소스와 캐시를 빨리 얻는 데 있지, 한 번의 xcodebuild를 억지로 여러 CPU에 나누는 데 있지 않다. 주력이 C/C++이고 Makefile이 성숙했다면 distcc도 시도할 만하지만, SwiftUI 대형 공정에서 3배를 기대하긴 어렵다.

시행착오: 배선은 정상인데 속도가 공인망 수준일 때

테스트 중 「병렬된 것처럼 보이는데 속도가 공인망 같다」는 경우가 있었다. 장애 대응용으로 정리한다.

rsync가 공인 IP를 탄다. SSH config Host 별칭이 공인 주소면 30 GB 동기화가 다시 4분급이 된다. ssh -v m4-node2로 실제 연결 대상 IP가 TB 내부 세그먼트인지 확인한다.

디스크 쓰기가 병목. 세 대가 동시에 NVMe에 rsync 쓰기하면 단일 디스크 지속 쓰기가 1.5 GB/s까지 떨어질 수 있어 iperf3는 높은 대역을 보여도 rsync 엔드투엔드는 느려진다. 동기화를 어긋나게 하거나 증분 디렉터리만(--link-dest) 동기화한다.

방화벽이나 Little Snitch가 TB 인터페이스를 막는다. 드물게 보안 소프트웨어가 브리지 네트워크를 기본 차단한다. 일시 해제하거나 Thunderbolt Bridge를 허용한 뒤 iperf3를 재측정한다.

클러스터 노드가 동일 주문 배치가 아니다. TB5 병렬은 동일 노드·동일 배치에서 병렬 서비스를 켠 인스턴스 조합에만 적용된다. 노드를 넘기면(예: 싱가포르 1대 + 도쿄 1대) TB 물리 연결 불가·공인망만 가능. 이때 TB5 추가는 불필요하다.

TB5 병렬 서비스를 추가할 가치가 있는 시점

제목 질문으로 돌아가자——여러 대 Mac mini를 네트워킹하면 얼마나 빨라지나? 세 가지 테스트에서 답은 워크플로 형태에 달렸다. 순수 매트릭스 병렬(각 App 독립 빌드)이면 머신 수에 가까운 벽시계 단축을 기대할 수 있다. 캐시 공유 monorepo는 TB5로 동기화를 분 단위에서 초 단위로 압축한다. distcc로 한 번의 컴파일을 여러 대에 나누는 방식은 Swift 공정에서 이득이 제한적이다.

일상 CI에 클라우드 Mac 한 대면 충분하면 표준 M4($21.1/일, 16 GB 메모리, 1 Gbps 전용 대역)로 족하고 TB5 추가 요금은 필요 없다. 아래 조합이 맞을 때 TB5($1.9/일 / $9.5/월) 추가가 합리적이다: 동일 노드에 2대 이상, 야간 배치 총 시간 30분 초과, 또는 노드 간 10 GB 이상 DerivedData/SPM 캐시를 자주 동기화해야 할 때.

PixVPS는 싱가포르, 일본(도쿄), 한국(서울), 홍콩, 미국 동부 다섯 노드에서 동일 하드웨어와 병렬 옵션을 제공한다. 결제 후 1~5분 안에 단일 인스턴스가 열리고, 클러스터 배치 TB 배선은 데이터센터에서 진행된다. 주문 구성 페이지에서 TB5 병렬을 체크하면 여러 머신이 같은 상호 연결 도메인에 들어간다. 가동 중 인스턴스에도 나중에 추가 가능(도움말 센터 참고). 7×24 실제 담당자 지원, 티켓 1시간 이내 응답. 클러스터 토폴로지와 내부 IP는 콘솔 「클러스터 상호 연결 정보」에서 확인한다.

컴파일 팜 경제학은 단순하다. 병렬도 × 단일 속도 − 협업 오버헤드 = 실제 이익. Thunderbolt 5 병렬이 깎는 것은 협업 비용 중 가장 큰 덩어리——대용량 동기화 대기 시간이다. 워크플로를 독립 job으로 쪼갠 뒤 TB5로 캐시 배포를 가속하는 편이 머신만 늘리는 것보다 벽시계 시간을 더 줄이기 쉽다.