클라우드 CI·개발 환경을 제공하는 Namespace가 수백 대의 맥북 프로를 데이터센터 랙에 설치하는 과정을 공개했다. 처음 보면 노트북을 서버로 쓴다는 발상이 황당하게 느껴지지만, 그 배경을 알고 나면 나름의 합리성이 드러난다. 핵심 이유는 단순하다. 많은 고객이 iOS 앱을 빌드하고 테스트하는데, iOS 시뮬레이터는 맥에서만 돌아가고 앱스토어 배포에는 애플이 요구하는 최신 Xcode가 필요하다. xtool 같은 대안이 있지만 아직 실무용 대체재로는 부족하다. 결국 코딩 에이전트에게도 맥이 필요하다.
그렇다면 왜 맥 미니가 아니라 노트북인가. 데이터센터 입장에서는 맥 미니가 당연히 낫다. 그러나 Namespace가 수백 대를 주문해 보니 1월에 발주한 물량이 7월에야 도착했다. 공급망이 흐트러진 2026년의 현실이다. 게다가 애플은 모든 기기에 CPU 세대를 동시에 적용하지 않는다. 맥 미니는 10개월간 M5를 받지 못하다가 느닷없이 다른 모델보다 먼저 M6를 달고 나왔다. 늘 최신·최고를 약속한 회사로서는 재고가 풍부하고 즉시 조달 가능한 맥북으로 눈을 돌릴 수밖에 없었다.
노트북을 랙에 넣는다는 것
맥북 운영은 예상과 다른 곳에서 문제를 일으켰다. 각 노트북에는 원격 관리용 IP KVM이 연결된다. 미니와 달리 노트북 펌웨어는 화면을 전제로 설계돼 있어 일부 유지보수 작업은 GUI 버튼 클릭으로만 가능하기 때문이다. 여기에 외장 10G 이더넷 NIC와 전원이 더해져 노트북 한 대당 네 가닥, 선반 하나에 전원만 48가닥, 이더넷 12가닥에 KVM 배선까지 얽힌다. 발열은 핫스팟의 열을 빨아내 옆 기기로 가지 않도록 유도하는 맞춤 거치대로 다스린다.
의외로 맥세이프 커넥터는 우려와 달리 빠지는 사고가 거의 없었다. 정작 말썽은 두껍고 뻣뻣한 HDMI 케이블이었다. 선반을 건드릴 때마다 빠져서, 원하는 각도로 휘는 케이블을 찾아내 아마존 재고를 통째로 사들였다고 한다. 더 성가신 건 FileVault였다. 예기치 않게 재부팅되면 디스크 잠금 해제 암호를 묻는데, 그 화면이 닫힌 노트북 안에만 뜬다. KVM으로 보려 해도 5분 뒤 프롬프트가 사라지고, Tahoe가 도입한 SSH 원격 해제 역시 노트북에서는 5분이면 만료된다. 결국 물리 버튼을 눌러 재부팅하고 시간 안에 잠금을 푸는 수밖에 없다. 참고로 fdesetup authrestart를 쓰면 재부팅 후에도 디스크를 잠금 해제 상태로 유지할 수 있다. 외장 USB NIC이 전원이 끊긴 듯 링크가 죽는 버그는, 설정에서 네트워크 서비스를 지웠다가 다시 만들면 되살아난다.
곧 합류할 M5·M6 맥 미니와 스튜디오는 훨씬 다루기 쉽다. 10Gb 네트워크 카드가 내장돼 있고 전원 복구 후 자동 부팅되며 MDM으로 OS를 전부 자동 설정할 수 있다. 미니용으로도 공기 흐름 시뮬레이션으로 검증한 맞춤 선반을 설계해, 열 개씩 거치대에 꽂고 전원과 네트워크만 연결하면 이후는 자동화가 처리한다.
애플 가상화 프레임워크의 제약
Namespace 인스턴스는 가상머신으로 구동되며, macOS는 애플의 Virtualization 프레임워크 위에 올라간다. 시스템 구조상 Firecracker에 가장 가깝게, 일반적인 VM 동작과 주변장치를 통째로 구현해 주는 임베디드 엔진이다. 더 저수준인 Hypervisor 프레임워크는 리눅스 KVM에 해당하지만 애플 독자 환경을 요구해 macOS 자체를 돌리지 못한다. 그래서 경쟁 플랫폼 대부분이 같은 토대 위에 서 있고, 차이는 애플이 준 몇 안 되는 기본 요소를 어떻게 빠르고 안전하게 배치하느냐의 디테일에서 갈린다.
잘 알려진 제약은 물리 맥 한 대당 macOS VM을 두 개까지만 허용한다는 점이다. 24코어·192GB 맥 프로라도 게스트는 둘뿐이다. 이 한계는 제품에도 그대로 반영돼, 14코어 미니에서는 6코어와 12코어, 18코어 맥북에서는 8코어와 16코어로 자원을 절반씩만 쪼갠다(관리용으로 몇 코어는 남긴다). 또 가상 CPU를 실행하는 VMM 프로세스가 호스트 측 소프트웨어와 분리돼 있어, VM 동작을 가로채거나 커스텀 장치를 붙일 때마다 IPC 왕복이 발생한다는 점도 설계에서 감안해야 한다.
네트워크가 대표적이다. 신뢰할 수 있는 로컬 환경이면 브리지·NAT 모드로 충분하지만, Namespace는 신뢰할 수 없는 코드를 돌리고 고객이 정의한 접근 정책까지 강제해야 한다. 그래서 구글 gVisor의 유저스페이스 TCP/IP 스택을 기반으로 인스턴스용 IP 게이트웨이·방화벽을 만들어 모든 패킷을 소프트웨어로 처리한다. 다만 이 경로가 VMM과 호스트 프로세스 사이 IPC를 거치기 때문에 배치 처리로 왕복을 최대한 줄여야 하고, 그렇게 얻어낸 상향 대역폭이 Fast.com 기준 약 4Gbps다. 회선 속도에는 못 미치지만 IPC를 아예 우회하는 방식을 탐구 중이라고 밝혔다.
2TB 이미지를 함대 전체에 뿌리는 문제
첫 VM을 만드는 일 자체는 쉽다. macOS 설치용 XIP를 내려받아 UTM이나 Tart 같은 래퍼로 띄우고 Xcode를 깔면 끝이다. 문제는 그다음이다. 여러 iOS 런타임, 다가올 Xcode 베타와 신규 런타임을 얹다 보면 이미지가 500GB로 불어난다. 이전 macOS 버전 테스트용으로 또 500GB, 신규 개발자 프리뷰로 하나 더. 게다가 베타 Xcode가 CoreDevice·CoreSimulator의 전역 버전을 올려 정식 Xcode를 미묘하게 망가뜨리는 실제 사례 탓에, 프리릴리스 포함본과 미포함본을 따로 유지해야 한다. 그렇게 2TB짜리 이미지 더미가 생기는데, 이걸 고작 2TB 맥북 디스크에 담을 수는 없다.
그래서 이미지 빌드는 사람이 하듯 설치와 설정을 재현하는 스크립트로 자동화한다. 셸 명령 실행, 재부팅, VNC를 통한 설정 UI 조작 등을 YAML 워크플로로 표현하되, 가급적 애플이 설계한 제어 수단을 써서 일반 사용자와 다른 예기치 않은 동작을 피한다. 완성된 디스크 이미지는 리눅스·윈도우 이미지를 다루는 것과 같은 내부 이미지 레지스트리로 넘겨 저장·복제·배포한다. 파일 묶음인 OCI 레이어와 달리 디스크는 거대한 평면 바이트 배열이고 상당 부분이 사용자에게 여유 공간으로 보일 빈 영역이라는 점이, 수백 대 규모로 배포할 때 별도의 고민거리로 남는다.