# macOS VM은 얼마나 빠르고, 얼마나 작아질 수 있을까?

> Clean Markdown view of GeekNews topic #29112. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=29112](https://news.hada.io/topic?id=29112)
- GeekNews Markdown: [https://news.hada.io/topic/29112.md](https://news.hada.io/topic/29112.md)
- Type: GN+
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2026-05-03T10:25:19+09:00
- Updated: 2026-05-03T10:25:19+09:00
- Original source: [eclecticlight.co](https://eclecticlight.co/2026/05/02/how-fast-is-a-macos-vm-and-how-small-could-it-be/)
- Points: 1
- Comments: 1

## Topic Body

- **Mac mini M4 Pro**에서 macOS 26.4.1 VM을 다시 측정한 결과, 5개 가상 코어와 16GB vRAM 구성에서도 CPU 단일 코어와 GPU 성능이 호스트에 근접함
- [Geekbench](https://www.geekbench.com/) 6.7.1 기준 **단일 코어 CPU**는 VM 3,855 / 호스트 3,948, **GPU Metal**은 VM 106,896 / 호스트 111,970으로 각각 호스트의 약 98%, 95% 수준을 보임
- 멀티 코어 CPU는 VM 13,222 / 호스트 23,342였으며, 호스트가 14코어(10 P + 4 E)이고 VM은 5개 가상 코어라 직접 비교는 어렵지만 VM 성능은 꽤 양호함
- 가장 약한 부분은 **가상 Neural Engine**으로, CoreML 반정밀도와 양자화 테스트에서 호스트보다 크게 느렸고 VM에서는 AI 작업이 CPU와 GPU로 처리되기를 기대할 수 있음
- 최소 구성 테스트에서 **2개 가상 코어와 4GB 메모리**만으로도 Safari와 설정의 저장 공간 분석 같은 가벼운 작업을 정상 처리했으며, macOS 업데이트를 고려하면 VM 저장 공간은 최소 60GB가 적절함

---

### 테스트 배경
- Apple silicon에서의 [macOS 가상화 검토](https://eclecticlight.co/2026/04/29/virtualisation-on-apple-silicon-macs-is-different/)에 쓰인 성능 수치는 이전 측정값이었고, 사용할 만한 VM의 최소 사양은 다루지 않았음
- MacBook Neo에서 VM을 실행하는 데 관심이 커진 상황에서, macOS Tahoe 기준 성능과 최소 구성을 다시 확인함

### 성능 측정과 해석
- 테스트 호스트는 **Mac mini M4 Pro**이며, macOS 26.4.1, 14코어(10 P + 4 E), 48GB RAM, 2TB 내장 SSD 구성임
- 게스트 VM에는 **5개 가상 코어**와 16GB 가상 RAM을 할당함
- [Geekbench](https://www.geekbench.com/) 6.7.1 점수는 호스트와 VM 모두 이전보다 약간 빨라짐
- 측정 결과는 다음과 같음
  - 단일 코어 CPU: VM 3,855, 호스트 3,948
  - 멀티 코어 CPU: VM 13,222, 호스트 23,342
  - GPU Metal: VM 106,896, 호스트 111,970
  - Neural Engine CoreML: VM 5,291 / 8,577 / 6,877, 호스트 5,973 / 41,251 / 56,616
- Neural Engine CoreML의 세 수치는 순서대로 **단정밀도**, **반정밀도**, **양자화** 테스트 결과임
- 멀티 코어 CPU 결과는 호스트가 VM보다 두 배 넘는 코어 수를 갖고 있고 그중 4개가 E 코어라 직접 비교가 어려움
- GPU 성능 비교는 호스트가 GPU를 함께 경쟁적으로 쓰지 않는 조건에서의 결과임
- VM에서 실행할 때 macOS가 AI 작업을 Neural Engine 대신 CPU와 GPU로 처리하기를 기대할 수 있음

### 최소 구성 테스트
- MacBook Neo 등장 이후 해당 기기에서 VM을 실행할 수 있을지에 대한 관심이 있었음
- Linux 호스트 용도로는 괜찮을 것으로 보였지만, macOS VM으로 유용한 작업이 가능할지는 의심됐으나 실제 테스트에서는 가능했음
- 최소 구성을 확인하기 위해 같은 macOS 26.4.1 VM을 **Viable**에서 점차 더 작은 CPU 코어와 메모리 할당으로 실행함
- VM 표시 창은 표준 **1600 × 1000**으로 설정함
- Safari를 여러 방식으로 사용하고, 설정의 저장 공간 분석을 포함한 가벼운 일상 작업을 수행함
- 구성별 결과는 다음과 같음
  - 4개 가상 코어와 8GB vRAM에서는 VM이 완전히 경쾌하게 동작했고, 메모리는 약 5GB 사용됨
  - 3개 코어와 6GB에서는 메모리 사용량이 3.9GB로 줄었고 모든 작업이 잘 동작함
  - 2개 코어와 4GB 메모리에서는 3.1GB만 사용됐으며, 가벼운 작업을 계속 정상적으로 처리함
- 2개 가상 코어와 4GB 메모리만 할당한 macOS VM도 MacBook Neo에서 가능할 것으로 보이며, 일상 작업을 충분히 수행할 수 있음
- 이런 VM은 LLM을 실행해볼 장소는 아니지만, 가벼운 macOS 작업에는 충분히 사용할 만함

### 저장 공간과 업데이트 제약
- 내장 SSD가 작은 Mac에서 VM을 만들 때는 VM 크기를 주의해야 함
- **50GB보다 훨씬 작은 macOS VM**은 macOS 업데이트를 수행할 수 없게 됨
- 여유와 안전성을 위해 최소 **60GB**를 목표로 잡는 것이 좋음
- APFS에서는 VM이 **희소 파일**로 저장되므로, 기본 100GB VM도 실제 디스크에서는 약 54GB만 필요함
- 이런 구성은 512GB SSD를 갖춘 MacBook Neo에서 더 적절하게 수용될 수 있음

## Comments



### Comment 56730

- Author: neo
- Created: 2026-05-03T10:25:20+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47984852) 
- 코어마다 묶이는 메모리가 어느 정도 있다는 좋은 reminder임. 아마 주로 **페이지 캐시**나 동시성 처리 같은 쪽일 가능성이 큼
  - 귀무가설 쪽에 걸겠음. 코어 수를 고정하고 **VM 메모리 크기**만 조정해도 같은 메모리 사용량 변화가 나타났을 것 같음
  - 일반적으로 컴퓨터에 장착한 **물리 메모리 용량**도 CPU가 제공하는 하드웨어 스레드 수에 비례해야 함  
    운영체제가 스레드마다 일부 메모리를 할당할 수 있을 뿐 아니라, 큰 소프트웨어 프로젝트 컴파일처럼 모든 스레드를 쓰는 멀티스레드 앱은 작업 스레드 수에 비례해 작업 메모리를 잡는 경우가 많음  
    스레드당 최대 2GB 정도가 있어야 잘 도는 멀티스레드 앱도 많이 봤고, Ryzen 9 9950X처럼 32스레드 데스크톱 CPU라면 64GB가 맞아떨어짐  
    Chrome/Chromium 계열 같은 프로젝트를 컴파일할 때 16코어/32스레드 CPU에 32GB만 있으면, `make -j` 같은 적절한 파라미터로 동시 컴파일 수를 줄여 일부 코어를 놀려야 함. 아니면 **메모리 부족 오류**를 만날 수 있음
  - 코어당 오버헤드가 있는 건 맞지만, 이 사용량 감소는 사용 가능한 메모리가 줄어들면서 **커널의 메모리 할당 방식**이 바뀐 영향일 가능성이 더 커 보임  
    메모리가 많으면 커널은 읽기 캐시를 더 오래 유지하고, 디스크 스왑보다 메모리 압축을 선호하며, 회수 가능한 메모리 정리를 덜 자주 함. 내부 버퍼 크기와 vnode 테이블도 총 메모리에 따라 조정됨  
    사용 가능한 자원을 동적으로 최대한 활용한다는 점에서는 좋은데, 실제 동작에 필요한 최소 기준선을 보기 어렵게 만드는 대가가 있음  
    확인해보면 재미있는 명령은 `vm_stat`이고, free/active/inactive/wired/purgeable 페이지, compressor, pagein/pageout, swapin/swapout 같은 값을 볼 수 있음. 편집: 코드 펜스 Markdown 지원이 안 되는 건지, 내가 뭔가 잘못한 건지 모르겠음

- 최근 **M5 Air**를 샀고 macOS는 처음이라 이 부분을 파악하는 중인데, `pytorch`, GPU 가속, VM/컨테이너 수준 격리를 동시에 얻는 건 사실상 불가능해 보임  
  `virtio-gpu` 계층이 가장 가까워 보이지만, 계산용 GPU가 아니라 그래픽 GPU만 넘겨주는 듯해서 `pytorch`는 안 됨
  - 나도 이게 필요해서 1년 전 꽤 많이 찾아봤음. 최근의 **Docker Model Runner**(`vllm-metal`)나 `podman libkrun` 쪽 변화는 아직 확인할 시간이 없었는데, 둘 다 안 됐나?
  - Cirruslabs Tart 인스턴스에서 `torch`를 실행하는 데 성공했음

- macOS에서 VM을 써본 건 **colima+docker**뿐인데, 비교적 고통스럽고 비효율적임. 그래도 쓸 수는 있음
  - Apple의 **container CLI**를 써보면 좋음. 몇 주 전 주말 동안 내 프로젝트 하나를 `colima+docker`에서 꽤 쉽게 옮겼음  
    [https://github.com/apple/container](<https://github.com/apple/container>)
  - 로컬 CI 용도로 Mac Mini를 샀고 Forgejo Actions와 함께 쓰려고 생태계를 넓게 훑어봤지만, 결국 **호스트에서 빌드**하는 쪽으로 갔음  
    서명과 공증 설정을 호스트로부터 격리하는 일은 에이전트를 써도 감당하기 어려워 보였음. 그래도 이제 macOS 빌드는 정말 빠르고, 서명/공증도 Bash 약 200줄이면 됨
  - **OrbStack**은 꽤 좋음. 딱히 비효율적이라고 느끼지 않음

- [https://github.com/trycua/cua/tree/main/libs/lume](<https://github.com/trycua/cua/tree/main/libs/lume>)가 이 문제에 대해 흥미로운 접근을 보여줬음

- VM 시작 시 5GB만 쓴다고 해도, VM 안에서 앱을 실행하면 시작 때 쓰는 5GB가 아니라 할당한 **8GB 전체**를 원하게 되는 것 아닌가?
  - macOS 가상화가 **메모리 벌루닝**을 지원할 만큼 고급이라고 생각하지 않았는데, 그 얘기가 아닌가?  
    편집: 내가 틀렸음

- 내가 가장 작은 걸 갖고 있는 것 같음. `docker.io/gotson/crossbuild latest d96ea9b7054b 3 years ago 6.71 GB`이고, **Darwin 크로스 빌드**에 쓰고 있음

- 솔직히 macOS는 VM에 꼭 필요하지 않은 것들을 끄면 그보다 훨씬 낮게도 내려갈 수 있을 것 같음  
  첫 iPhone은 RAM이 128MiB뿐이었고, 잘라낸 macOS Tiger 버전을 돌렸던 것으로 알고 있음. 지금까지는 RAM이 꽤 넉넉해서 줄일 이유가 없었을 뿐, 분명 가능하고 아마 그렇게 어렵지도 않을 것임. 다시 시도하기만 하면 됨
  - 초기 iPhone에는 **앱 멀티태스킹**이 없었으니 차이가 꽤 큼. 앱은 닫히면 종료됐음

- PC에서 **macOS를 실행**할 수 있나? 아니면 최소한 PC에서 Mac용 개발을 어떤 식으로든 할 수 있나?
  - QEMU로 macOS 부팅은 가능하지만, **하드웨어 가속 그래픽**이나 몇몇 기능은 쓸 수 없음

- 좀 뜬금없는 질문이지만, macOS VM을 개인 기기로 **Intune 등록**하는 게 가능할까?

- 왜 아무도 macOS 전용 에이전트 환경을 만들지 않는지 궁금함. 에이전트가 Mac 환경에서 spawn되는 식이면 좋을 텐데
