Thunderbolt 5 병렬이란 무엇인가?
ZilCloud 주문 페이지의 추가 옵션 중 하나가 바로 「Thunderbolt 5 병렬 서비스」입니다. 일 단위로 $1.4, 월 단위로 $8.9만 추가하면 됩니다. 처음 봤을 때 저도 이런 생각이 들었습니다. 「이걸 왜 쓰는 거지?」
간단히 말하면, Thunderbolt 5(이하 TB5)는 Apple이 Mac mini M4에 도입한 새 인터페이스 표준으로, 이론 대역폭은 120 Gbps(PCIe 채널)이며 장치 간 연결 시 80 Gbps 양방향 대역폭을 제공합니다. 초당 약 10 GB의 데이터 전송이 가능하며, 이전 세대 TB4(40 Gbps)의 두 배에 해당합니다. ZilCloud의 TB5 병렬 서비스는 클라우드에 있는 Mac mini M4 노드 여러 대를 물리 TB5 케이블로 직접 연결해, 운영체제 입장에서는 투명한 고속 LAN을 만드는 것입니다.
엔지니어링 관점에서 보면 이는 단순히 두 대의 머신을 이더넷으로 이어 놓는 것과는 다릅니다. TB5 병렬은 PCIe 채널을 사용하므로 이더넷보다 지연이 훨씬 낮고, 이론적으로는 Remote Direct Memory Access(RDMA)를 통해 로컬 NVMe 수준에 가까운 크로스 머신 메모리 매핑도 가능합니다. 컴파일 클러스터, AI 추론 클러스터, 영상 렌더링 풀 모두에 실질적인 이점이 있습니다.
이번 테스트에서는 ZilCloud 싱가포르 노드의 Mac mini M4 2대(각 16 GB 통합 메모리 + 256 GB SSD, 1 Gbps 독점 공인 IP)를 임대하고 Thunderbolt 5 병렬 서비스를 활성화했습니다. 물리 배선과 시스템 인식 확인은 ZilCloud 측에서 완료한 뒤 인스턴스를 전달받았습니다.
환경 구성: 개통 및 TB5 포트 인식
ZilCloud 콘솔에서 노드 2대를 선택하고 TB5 병렬 추가 옵션을 켠 뒤, 약 3분 만에 두 머신 모두 「준비 완료」 상태가 되었습니다. SSH로 첫 번째 머신에 접속한 다음 아래 명령으로 TB5 포트 인식 여부를 확인했습니다.
system_profiler SPThunderboltDataType출력 결과에서 TB5 포트 2개가 모두 인식되었고, 「Connected」 상태에서 상대 장치(두 번째 Mac mini)가 감지되었습니다. macOS 네트워크 설정에서는 TB5 링크가 자동으로 「Thunderbolt Bridge」 인터페이스로 나타나 169.254.x.x 링크 로컬 주소가 할당되었으며, 별도 수동 설정 없이도 통신이 가능했습니다.
정적 IP 수동 구성(권장)
APIPA 주소만으로도 동작하지만, 이후 빌드 작업과 스크립트 안정성을 위해 정적 IP 설정을 권장합니다. 두 머신의 Thunderbolt Bridge 인터페이스에 각각 다음과 같이 지정했습니다.
# 노드 A
sudo networksetup -setmanual "Thunderbolt Bridge" 192.168.100.1 255.255.255.0
# 노드 B
sudo networksetup -setmanual "Thunderbolt Bridge" 192.168.100.2 255.255.255.0설정 후 ping -c 4 192.168.100.2로 연결을 확인했을 때 평균 RTT는 약 0.08 ms였습니다. 같은 데이터센터의 10GbE 이더넷보다도 낮은 수치입니다.
대역폭 실측: iperf3 및 fio 데이터
기본 네트워크가 준비되면 가장 먼저 iperf3로 대역폭을 측정하는 것이 일반적입니다.
iperf3 TCP 테스트
# 노드 B를 서버로 실행
iperf3 -s
# 노드 A를 클라이언트로, 8개 동시 스트림
iperf3 -c 192.168.100.2 -P 8 -t 30측정 결과는 다음과 같습니다.
| 테스트 시나리오 | 프로토콜 | 동시 스트림 | 실측 처리량 | 이론 상한 대비 |
|---|---|---|---|---|
| 단방향 TCP | TCP | 1 스트림 | 38.2 Gbps | 48% |
| 다중 스트림 TCP | TCP | 8 스트림 | 72.4 Gbps | 90% |
| 단방향 UDP | UDP | 1 스트림 | 79.1 Gbps | 99% |
| 양방향 동시 | TCP | 4+4 스트림 | 61.8 + 59.3 Gbps | ~76% |
UDP 단일 스트림은 79.1 Gbps까지 도달해 80 Gbps 명시값에 매우 근접했습니다. TCP 8스트림에서는 72.4 Gbps를 기록했으며, 실제 워크로드 기준으로도 충분히 여유 있는 대역폭입니다. 양방향 동시 전송 시 각 방향 모두 60 Gbps 이상을 유지해 합계 120 Gbps를 넘었고, 이는 TB5 PCIe 채널 이론값과 잘 맞아떨어집니다.
fio 크로스 머신 파일 전송 테스트
iperf3는 네트워크 계층만 측정합니다. 실사용에서는 파일 시스템 수준 전송 속도가 더 중요합니다. macOS 기본 SMB 공유와 NFS 마운트로 각각 테스트했습니다.
| 프로토콜 | 읽기 속도 | 쓰기 속도 | 소형 파일 IOPS (4K) |
|---|---|---|---|
| SMB(macOS 기본) | 4.8 GB/s | 3.9 GB/s | 42,000 |
| NFS v4.2 | 6.2 GB/s | 5.7 GB/s | 67,000 |
| rsync(압축 비활성) | 5.1 GB/s | — | — |
NFS v4.2 순차 읽기는 6.2 GB/s에 도달해 단일 NVMe SSD 로컬 읽기 속도를 넘어섰습니다. M4의 메모리 대역폭이 높아 TB5를 통해 원격 머신의 통합 메모리 버퍼에 직접 접근할 때, 로컬 SSD보다 빠른 경우도 있다는 뜻입니다.
대용량 파일이나 고빈도 소형 파일 공유에는 SMB보다 NFS v4.2를 권장합니다. IOPS는 약 59% 향상되고 지연도 더 낮습니다. Xcode 시뮬레이터 상태 동기화처럼 지연에 극도로 민감한 경우에는 SSH + FUSE 마운트도 고려해 볼 만합니다.
Xcode 분산 컴파일 실측
iOS·macOS 개발자에게 가장 직접적인 질문은 이것입니다. TB5 클러스터가 Xcode 빌드를 얼마나 빠르게 만들어 줄까?
테스트에는 실제 iOS 프로젝트(약 180개 모듈의 대형 SwiftUI 앱, 클린 빌드 약 14분)를 사용했습니다. distcc와 pump mode로 컴파일 작업을 두 머신에 분산했습니다.
# distcc 설치
brew install distcc
# 노드 B를 컴파일 데몬 서버로 실행
distccd --allow 192.168.100.0/24 --log-stderr --verbose
# 노드 A에서 distcc 호스트 목록 설정
export DISTCC_HOSTS="192.168.100.2/8 localhost/4"
# pump 모드로 빌드 실행
pump xcodebuild -project MyApp.xcodeproj -scheme MyApp -configuration Release build| 빌드 방식 | 총 소요 시간 | CPU 피크 사용률 | 가속 비율 |
|---|---|---|---|
| 단일 머신(노드 A 로컬) | 14분 12초 | 87% | 기준 |
| 단일 머신(노드 B 로컬) | 14분 08초 | 89% | 기준 |
| 2대 TB5 분산(distcc) | 8분 47초 | 91% × 2 | ×1.62 |
| 2대 TB5(증분 빌드) | 1분 38초 | 76% × 2 | ×2.3+ |
클린 빌드는 14분에서 8분 47초로 줄어 약 1.62배 가속되었습니다. 이상적인 2배에는 못 미쳤는데, Swift 프론트엔드 컴파일(의미 분석 단계)은 아직 분산을 지원하지 않아 로컬에서만 실행되기 때문이며 전체 빌드 시간의 약 35%를 차지합니다. 순수 C/C++/Obj-C 코드만 분산할 때는 약 1.9배까지 측정되었습니다.
증분 빌드 효과는 더 뚜렷했습니다. 중간 산출물의 크로스 머신 공유가 매우 빠르기 때문에(TB5 전송 속도가 네트워크 I/O 대기를 압도) 전체 증분 빌드가 약 3분 46초에서 1분 38초로 단축되어, 일상적인 개발 루프에서 체감되는 시간 절약이 큽니다.
대규모 언어 모델 추론: llama.cpp 다중 머신 가속
컴파일 외에도 TB5 클러스터는 AI 추론에 큰 가치가 있습니다. M4의 Apple Neural Engine은 38 TOPS 연산력을 제공해 단일 머신 추론만으로도 충분한 경우가 많습니다. 다만 동시 요청이 많은 AI 서버 환경에서는 두 대 병렬이 처리량을 효과적으로 끌어올립니다.
llama.cpp RPC 백엔드(build 0.1.x부터 다중 머신 로드 밸런싱 지원)로 Llama 3.1 8B(Q4_K_M 양자화) 추론 처리량을 측정했습니다.
# 노드 B에서 llama-rpc-server 실행
./llama-rpc-server --host 192.168.100.2 --port 50052 -ngl 99
# 노드 A를 메인으로 두 머신 지정
./llama-cli \
--rpc 192.168.100.2:50052 \
-m ./Llama-3.1-8B-Q4_K_M.gguf \
-ngl 99 --parallel 8 -p "Write a detailed technical analysis of..."| 시나리오 | tokens/s(추론) | 동시 요청 수 | 메모리 사용량 |
|---|---|---|---|
| 단일 머신(노드 A) | 48.2 tok/s | 4 동시 | 12.3 GB |
| 2대 TB5 RPC | 89.7 tok/s | 8 동시 | 11.8 GB × 2 |
| 2대 TB5(Llama 3.1 70B Q4) | 22.4 tok/s | 2 동시 | ~30 GB 분산 |
8B 모델 추론 처리량은 단일 머신 48.2 tok/s에서 두 대 병렬 89.7 tok/s로 거의 선형에 가깝게 확장되었습니다. TB5의 초저지연 덕분에 다중 머신 간 KV-Cache 동기화 오버헤드가 사실상 무시할 수준입니다. 일반 이더넷 방식으로는 달성하기 어려운 부분입니다.
두 대 병렬은 단일 머신으로는 불가능한 작업도 열어 줍니다. Llama 3.1 70B Q4 양자화 버전은 약 40 GB 메모리가 필요해 16 GB 단일 머신으로는 로드할 수 없습니다. TB5 RPC로 모델 레이어를 두 머신에 분산하면 로컬 추론이 가능하며, 처리량은 약 22 tok/s로 GPU 없이도 실용적인 수준입니다.
llama.cpp RPC 백엔드에서 Apple Neural Engine(Metal 가속)을 사용할 때, 크로스 머신 레이어 분할 중 메모리 정렬 문제로 추론이 멈추는 경우가 가끔 발생했습니다(약 2% 확률). 임시 해결책은 RPC 모드에서 -ngl 값을 80으로 낮춰 일부 레이어를 CPU로 되돌리는 것이며, 이 방법으로 문제를 제거할 수 있었습니다. 공식 이슈에 PR이 머지 대기 중이며 다음 버전에서 수정될 예정입니다.
지연 및 안정성: 72시간 연속 부하 테스트
성능 수치만 좋다고 프로덕션에 쓸 수 있는 것은 아닙니다. 클라우드 노드의 안정성이 핵심입니다. 두 머신에 72시간 연속 고부하 테스트를 진행했으며, Xcode 증분 빌드 루프(5분 간격) + llama.cpp 동시 추론 + 크로스 머신 대용량 파일 순환 읽기·쓰기를 동시에 실행했습니다.
| 지표 | 72시간 평균 | 최악값 | 비고 |
|---|---|---|---|
| TB5 링크 지연(RTT) | 0.09 ms | 0.21 ms | 피크는 고부하 전환 순간 |
| TB5 대역폭(지속 전송) | 69.8 Gbps | 61.2 Gbps | 열 스로틀링 시 일시 하락 |
| 노드 연결 끊김 횟수 | 0회 | — | 72시간 무중단 |
| SSH 가용성 | 100% | — | 수동 개입 불필요 |
| 기기 온도(상단 외함) | 38.2°C | 41.7°C | M4 패시브 냉각 안정적 |
72시간 동안 TB5 링크는 한 번도 끊기지 않았고, 두 노드 모두 SSH 접속이 유지되었습니다. 피크 부하 시 M4 열 스로틀링으로 대역폭이 소폭 떨어지기도 했지만 평균 69.8 Gbps를 유지해 워크로드에 미치는 영향은 미미했습니다. 프로덕션 CI/CD 노드나 상시 AI 서비스에도 충분히 쓸 만한 안정성입니다.
적합한 사용 시나리오 정리
위 테스트를 바탕으로 TB5 병렬 클러스터에 특히 잘 맞는 수요는 다음과 같습니다.
1. 분산 iOS·macOS 컴파일(Xcode + distcc): 클린 빌드 약 1.6배, 증분 빌드 2배 이상 가속. CI 파이프라인 전체 빌드 시간을 크게 줄일 수 있습니다.
2. 대규모 모델 로컬 추론(llama.cpp RPC): 단일 머신 메모리 한계를 넘어 두 대 합산 32 GB 통합 메모리로 70B급 양자화 모델 실행 가능. 동시 추론 처리량도 거의 선형 확장됩니다.
3. 대규모 영상 렌더링·미디어 처리: 크로스 머신 파일 읽기(NFS over TB5) 최대 6.2 GB/s로 일반 LAN을 크게 앞섭니다. Final Cut Pro 클러스터 렌더링 프로토콜과 결합하면 렌더 시간을 이론상 절반까지 줄일 수 있습니다.
4. 실시간 데이터 파이프라인: 80 Gbps 대역폭과 0.08 ms 지연으로 크로스 머신 메모리 매핑이 현실적입니다. 저지연 노드 간 통신이 필요한 퀀트 백테스트, 실시간 스트림 집계 등에 적합합니다.
피할 수 없는 질문: 왜 일반 클라우드 서버 클러스터를 쓰지 않나?
여기까지 읽었다면 이런 생각이 들 수 있습니다. 비슷한 클러스터 요구라면 AWS나 네이버 클라우드, 카카오 i 클라우드의 GPU·HPC 인스턴스로도 가능하지 않나? 100 Gbps 이더넷이나 HPC 클러스터 네트워크를 제공하는 경우도 많으니까요.
이 질문은 충분히 타당하며, 몇 가지 본질적인 차이를 짚어 볼 가치가 있습니다.
첫째, macOS 환경의 대체 불가성입니다. Xcode 빌드, iOS 코드 서명, TestFlight 배포, Apple Neural Engine 추론 같은 워크로드는 Linux나 Windows 인스턴스에서 법적·기술적으로 실행할 수 없습니다. AWS Graviton은 ARM이지만 macOS를 돌릴 수 없고, AWS Mac 인스턴스는 Apple 전용 하드웨어이지만 시간당 약 $1.08(최소 24시간 약 $25.9/일)로 ZilCloud의 $20.9/일보다 비싸며 TB5 병렬도 지원하지 않습니다.
둘째, 공유·오버커밋 문제입니다. 대형 클라우드는 대부분 가상화 오버커밋 위에 구축됩니다. 100개 vCPU 인스턴스 뒤에 물리 코어 60개가 공유되는 식이고, 「10 Gbps 대역폭」은 보장 대역이 아닌 버스트인 경우가 많습니다. 이웃 테넌트의 noisy neighbor 현상이 피크 시간대 컴파일 속도와 추론 지연에 직접 영향을 줍니다. ZilCloud는 물리 머신 독점입니다. 가상화 계층도 없고 오버커밋도 없으며, 10코어 CPU는 그대로 10코어입니다.
셋째, 네트워크 상호 연결 품질의 차이입니다. AWS Cluster Placement Group은 저지연 네트워크를 제공하지만 노드 간 RTT는 보통 0.5–2 ms 범위입니다. EFA 같은 HPC 네트워크도 마이크로초 단위 지연인 반면, TB5의 0.08 ms RTT는 물리 계층 직결로 중간 라우팅 스택이 없습니다. KV-Cache 분할 추론처럼 프로세스 간 대량 상태를 공유하는 워크로드에서는 이 차이가 결정적입니다.
물론 일반 클라우드에도 장점이 있습니다. 초 단위 과금 유연성, GPU 모델 다양성, 성숙한 오토스케일링 등입니다. 순수 Linux GPU 학습이 주 목적이라면 기존 방식이 여전히 적합합니다. 하지만 macOS 네이티브 환경 + 고성능 클러스터 상호 연결 + 일 단위 유연 임대라는 조합은 현재 시장에서 ZilCloud TB5 병렬 서비스만이 실질적으로 제공합니다. 최저 $20.9/일 기본 요금에 TB5 추가 $1.4/일을 더한 $22.3/일이면 80 Gbps 클러스터에 참여하는 Mac mini M4 물리 노드 한 대를 받을 수 있습니다. 2주짜리 프로젝트라면 두 대를 임시로 빌려 작업 후 바로 반납하면 되고, 유휴 자원에 대한 추가 비용을 낼 필요가 없습니다.
나만의 Mac mini TB5 클러스터를 구성하세요
Mac mini M4를 일 단위로 임대하고, 언제든 두 번째 대를 추가해 Thunderbolt 5 병렬을 켜면 이 글에서 검증한 80 Gbps 고속 상호 연결 클러스터를 바로 사용할 수 있습니다. 장기 계약 없이 필요할 때만 켜고, 물리 서버 독점·직결 연결로 오버커밋과 이웃 간섭이 없습니다.