Apple Silicon 맥에서 VM 2개 제한 깨는 법 — 하이퍼바이저의 숨겨진 구조

무슨 일이 있었나

Apple Silicon(M1, M2, M3, M4) 맥을 쓰면서 가상 머신(VM)을 돌려본 분들이라면 한 번쯤 부딪혀봤을 제한이 있어요. 동시에 실행할 수 있는 VM이 사실상 2개로 제한된다는 거예요. 개발 환경으로 Linux VM 하나 띄우고, 테스트용으로 하나 더 띄우면 끝이에요. 세 번째 VM을 올리려고 하면 에러가 나거나 성능이 급격히 떨어지죠.

개발자 Mykola Grymalyuk(Khronokernel이라는 닉네임으로 유명한)이 이 제한의 실체를 파헤치고, 실제로 이 제한을 우회해서 더 많은 VM을 동시에 실행하는 방법을 공개했어요. 단순한 팁이 아니라, Apple Silicon의 하이퍼바이저가 내부적으로 어떻게 동작하는지를 깊이 분석한 기술 글인데요, VM을 많이 다루는 분들에게는 꽤 유용한 내용이에요.

핵심 내용: 2개 제한의 진짜 이유

먼저 "가상 머신"이 뭔지 간단히 짚고 넘어갈게요. VM은 컴퓨터 안에 또 다른 컴퓨터를 소프트웨어로 만드는 기술이에요. 맥 위에서 리눅스를 돌리거나, 윈도우를 돌리거나 할 수 있게 해주는 거죠. 이걸 가능하게 해주는 중간 계층을 하이퍼바이저(hypervisor)라고 부르는데, Apple Silicon에서는 Apple이 직접 만든 Hypervisor.framework를 씀으로써 VM을 구동해요.

그런데 이 2개 제한은 Apple이 의도적으로 "VM은 2개까지만"이라고 정한 게 아니에요. 진짜 원인은 하드웨어 수준에 있는 Stage 2 페이지 테이블의 구조 때문이에요.

이게 뭐냐면, ARM 프로세서(Apple Silicon이 ARM 기반이에요)에서는 메모리를 관리할 때 두 단계의 주소 변환을 거쳐요. 1단계는 일반적인 가상 메모리 변환이고, 2단계는 하이퍼바이저가 VM의 메모리를 실제 물리 메모리에 매핑하는 과정이에요. 이 2단계 페이지 테이블을 관리하는 하드웨어 레지스터(VTTBR_EL2)가 사용할 수 있는 VMID(Virtual Machine Identifier) 수에 제한이 있거든요.

Apple Silicon의 초기 구현에서 VMID가 제한적으로 할당되면서, Hypervisor.framework가 동시에 활성화할 수 있는 VM 수가 사실상 제한됐어요. 이건 소프트웨어 정책이 아니라 하드웨어 리소스 관리 방식에서 오는 제약이에요.

우회 방법: 어떻게 제한을 넘는가

Khronokernel이 제시한 접근법의 핵심은 VMID 재활용과 시분할(time-sharing) 전략이에요. 모든 VM이 동시에 VMID를 점유하는 대신, 실제로 CPU 시간을 쓰고 있는 VM에만 VMID를 할당하고, 유휴 상태인 VM의 VMID는 회수해서 다른 VM에 넘겨주는 방식이에요.

쉽게 비유하면 이래요. 주차장에 자리가 2개뿐인데 차가 5대 있다고 해봐요. 모든 차가 동시에 달리는 건 아니니까, 실제로 달리는 차 2대만 주차장(VMID)을 쓰고, 나머지는 대기 상태로 두는 거예요. 차가 멈추면 자리를 비워주고 다른 차가 쓰게 하는 식이죠.

구체적으로는 UTM이나 QEMU 같은 VM 관리 도구의 설정을 조정해서, VM의 CPU 코어 할당 방식과 메모리 매핑 전략을 바꿔주는 방식이에요. 글에서는 특정 entitlement 설정과 Hypervisor.framework API 호출 방식을 변경하는 방법을 상세히 다루고 있어요.

다만 주의할 점도 있어요. 이 방법은 VM 간 전환 시 약간의 오버헤드가 생길 수 있고, 모든 VM이 동시에 높은 CPU 부하를 걸면 성능이 떨어질 수 있어요. 또한 Apple이 향후 macOS 업데이트에서 하이퍼바이저 구현을 바꾸면 동작하지 않을 수도 있고요.

업계 맥락: Apple Silicon VM 생태계

이 이야기가 더 흥미로운 건, Apple Silicon으로 넘어오면서 VM 생태계 전체가 크게 바뀌었기 때문이에요. Intel 맥 시절에는 VMware Fusion, Parallels, VirtualBox 같은 검증된 도구들이 잘 돌아갔는데, ARM 전환 이후에는 상황이 복잡해졌거든요.

Parallels는 Apple Silicon을 빠르게 지원했지만 유료예요. UTM은 무료 오픈소스로 QEMU 기반인데, 기능이 제한적인 부분이 있어요. Docker Desktop도 내부적으로 경량 Linux VM을 쓰는데, 이것도 하이퍼바이저 리소스를 차지하죠. 그래서 Docker 돌리면서 동시에 다른 VM을 쓰려면 금방 2개 제한에 걸리는 거예요.

최근 Apple이 macOS에 Virtualization.framework를 강화하면서 상황이 좀 나아지긴 했어요. 이건 Hypervisor.framework 위에 더 고수준의 API를 제공하는 건데, Apple이 직접 VM 리소스 관리를 최적화해주기 때문에 일부 제한이 완화됐어요. 하지만 근본적인 VMID 제한은 여전히 존재하고요.

한국 개발자에게 주는 시사점

이 내용이 한국 개발자들에게 실질적으로 와닿는 시나리오가 몇 가지 있어요.

첫째, 마이크로서비스 개발 환경이에요. 여러 서비스를 로컬에서 동시에 띄워야 하는 경우, Docker Desktop(VM 1개) + 테스트용 Linux VM을 쓰면 바로 한계에 닿아요. 이 글의 우회법을 적용하면 추가 VM을 띄울 수 있어요.

둘째, iOS/macOS 개발자가 크로스 플랫폼 테스트를 할 때예요. Xcode로 시뮬레이터를 돌리면서 동시에 Linux 환경에서 서버 사이드를 테스트하고, 또 다른 환경에서 CI를 로컬로 재현해보고 싶은 경우가 있잖아요.

셋째, 보안/인프라 학습이에요. 쿠버네티스 클러스터를 로컬에서 다중 노드로 구성하거나, 네트워크 보안 실습을 위해 여러 OS 환경을 동시에 띄워야 할 때 유용해요.

당장 적용하고 싶다면 UTM의 최신 버전을 설치하고, 글에서 설명하는 CPU 코어 핀닝 설정부터 시도해보시는 걸 추천드려요.

정리

Apple Silicon의 VM 2개 제한은 소프트웨어 정책이 아니라 하드웨어 리소스 관리 방식 때문이고, VMID 시분할 전략으로 우회할 수 있어요. ARM 하이퍼바이저의 내부 구조를 이해하면 보이는 해법이죠.

여러분은 Apple Silicon 맥에서 VM을 몇 개나 동시에 돌리시나요? Docker 포함해서 VM 관리 때문에 불편했던 경험이 있다면 이야기해주세요.