Namespace, macOS 가상 머신 이미지를 서버 간 P2P로 배포

본문

Namespace 블로그에 글을 쓴 Kirill Nikolaev는 MacBook을 데이터센터 호스트로 삼아 macOS 가상 머신을 제공하는 과정을 설명했습니다. 고객은 Mac에서만 실행되는 iOS 시뮬레이터와 Xcode를 이용해 앱을 빌드하고 시험합니다. 이 환경을 빠르게 준비하기 위해 Namespace는 큰 VM 이미지를 빈 디스크 구간과 공통 데이터 블록을 공유하는 형식으로 저장하고, 피어투피어 방식으로 각 서버의 SSD에 배포합니다.

데이터센터에 MacBook을 둔 배경

고객이 iOS 앱을 빌드·시험하려면 Mac이 필요하고, iOS 시뮬레이터도 Mac에서 실행됩니다. App Store에 앱을 출시할 때는 최근 버전의 Xcode를 써야 합니다. Nikolaev는 데이터센터에는 Mac mini가 더 적합하지만, 수백 대를 주문하고 받는 데 2026년 1월부터 7월까지 걸렸다고 적었습니다. Apple이 새 칩을 모든 Mac 제품군에 동시에 적용하지 않는 점도 조달을 어렵게 했습니다.

MacBook을 랙에서 관리하려면 덮개를 닫은 상태에서도 화면을 보고 조작할 방법이 필요합니다. Namespace는 각 MacBook에 IP KVM을 연결해 펌웨어 관리 화면 같은 GUI를 원격으로 다루고, 외장 10Gb 이더넷 장치와 전원을 연결합니다. 열이 모이는 곳의 열을 빼내고 뜨거운 공기가 이웃 기기로 향하지 않게 맞춤형 거치대도 제작했습니다. 이 장치들은 고객이 사용하는 VM이 아니라 물리 Mac 호스트를 운영하기 위한 구성입니다.

물리 Mac에서 VM과 네트워크까지

각 인스턴스는 물리 Mac 자체가 아니라 그 위에서 실행되는 macOS 가상 머신입니다. Namespace는 Apple Virtualization framework로 VM과 가상 주변 장치를 구성합니다. 더 낮은 수준의 Hypervisor framework는 격리된 환경에서 CPU 명령을 실행하는 기반을 제공하지만, 기계 구조와 주변 장치 대부분을 애플리케이션이 구현해야 합니다. macOS에는 Apple의 독점 환경도 필요해 Hypervisor framework만으로 실행할 수 없다고 Nikolaev는 설명합니다.

Apple Virtualization에는 물리 Mac 한 대에서 실행할 수 있는 macOS VM이 두 대까지라는 제약이 있습니다. 각 게스트의 가상 CPU를 실행하는 VMM 프로세스는 Namespace의 VM 호스트 프로세스와 분리되어 있습니다. 이 구조에서 VM 동작에 개입하거나 가상 장치를 다루려면 두 프로세스 사이에 IPC(프로세스 간 통신)가 오갑니다. Namespace는 호스트 관리에 쓸 CPU 자원을 남기고 나머지를 게스트에 배정합니다.

네트워크에도 별도의 처리 경로를 둡니다. 브리지나 NAT 모드에서는 VM 트래픽이 VMM 프로세스에서 호스트 네트워크 인터페이스로 바로 전달됩니다. Namespace 인스턴스는 신뢰할 수 없는 코드를 실행하므로, 회사는 VM에 들어오고 나가는 모든 패킷을 사용자 공간의 gVisor TCP/IP 스택으로 처리합니다. 이를 통해 인스턴스별 게이트웨이와 방화벽 정책을 적용하고, 게스트가 제어하는 패킷이 호스트 운영체제에 그대로 닿는 범위를 줄입니다.

패킷은 VMM 프로세스에서 VM 호스트 프로세스로 넘어간 뒤 네트워크 인터페이스로 전달되므로 처리 과정에 IPC가 들어갑니다. Namespace는 가능한 경우 패킷을 묶어 IPC 왕복 횟수를 줄입니다. Nikolaev는 이 경로가 Fast.com 기준 업스트림 대역폭 4Gbps에 이른다고 설명했으며, 회선 속도에는 미치지 않아 IPC를 피하는 방안도 검토 중이라고 적었습니다.

큰 VM 이미지를 만들고 서버에 배포하기

macOS와 Xcode, 여러 iOS 시뮬레이터 런타임을 한 이미지에 넣으면 디스크 이미지가 500GB까지 커질 수 있다고 Nikolaev는 사례를 들었습니다. 베타 Xcode를 설치하면 CoreDevice와 CoreSimulator의 전역 버전도 바뀌어, 베타 시뮬레이터의 문제가 안정 버전 Xcode를 사용할 때 나타날 수 있습니다. 그래서 베타 Xcode가 포함된 이미지와 그렇지 않은 이미지를 따로 유지할 필요가 생깁니다.

Namespace는 사람이 설치·설정하는 과정을 자동화해 새 이미지를 만듭니다. 작업 순서는 YAML로 작성하며, 셸 명령 실행, VM 재부팅, VNC를 통한 설정 화면 조작 등을 포함할 수 있습니다. 일반 사용자의 환경과 다른 동작이 생기는 일을 줄이기 위해 가능한 한 Apple이 마련한 제어 수단으로 VM을 설정한다고 Nikolaev는 설명합니다. 그는 이 반복 가능한 과정으로 Apple이 Xcode를 출시한 뒤 몇 시간 안에 새 버전을 제공한다고 소개했습니다.

완성한 이미지는 Linux·Windows 이미지에도 쓰는 Namespace 내부 OCI 레지스트리에 저장합니다. 컨테이너 이미지는 파일 묶음으로 저장되지만 VM 디스크는 바이트가 이어진 배열로 저장됩니다. 사용 가능한 디스크 공간 중에는 실제 데이터가 없는 구간이 많고, 서로 다른 Xcode 이미지끼리도 같은 블록을 상당수 공유합니다. Namespace의 저장 형식은 할당되지 않은 구간을 몇 바이트로 나타내고, 공통 부분은 기본 계층으로 공유하며 달라진 블록만 추가 계층에 담습니다.

이미지를 실행할 때는 레지스트리의 디스크를 그대로 사용할 수 없어 호스트 SSD에 이미지 파일을 두거나, NBD(Network Block Device)로 원격 디스크 입출력을 제공해야 합니다. NBD 방식은 필요한 블록을 로컬 캐시에 두면서 장치의 저장 공간을 아낄 수 있지만, 입출력마다 IPC 왕복과 버퍼 복사, 문맥 전환이 발생할 수 있습니다. Namespace는 성능을 위해 이미지를 각 호스트의 SSD에 미리 준비하는 방식을 택했습니다.

수백 대의 서버가 중앙 레지스트리에서 각각 같은 대형 이미지를 내려받으면 전송량이 급증합니다. Namespace의 피어투피어 방식에서는 먼저 이미지를 받은 서버가 가까운 다른 서버에 블록을 전달하고, 그 서버가 다시 주변 서버로 확산합니다. 이미지가 호스트에 도착한 뒤에는 APFS의 희소 파일 기능으로 빈 구간을 저장하지 않고, 파일 복제 기능으로 여러 이미지에 공통인 블록을 공유합니다.

사용자는 준비된 이미지를 골라 앱 작업을 시작합니다. Namespace 문서에 따르면 CLI에서 macOS 버전과 Xcode가 포함된 이미지 선택자를 지정할 수 있고, SDK/API 요청에는 실행할 애플리케이션과 명령을 담아 인스턴스를 만들 수 있습니다. 인스턴스가 준비되면 빌드나 시험을 실행하며, 화면을 봐야 하는 디버깅에는 VNC 원격 표시를 이용합니다. 물리 Mac은 VM을 실행하고 이미지 저장소와 서버 간 전송은 큰 개발 환경을 각 호스트에 준비해, 사용자가 앱 작업을 시작할 수 있게 합니다.

자료: Namespace / 정리·해설: Trawling