# apple/container, Container Machine 기능 추가 > Clean Markdown view of GeekNews topic #30346. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=30346](https://news.hada.io/topic?id=30346) - GeekNews Markdown: [https://news.hada.io/topic/30346.md](https://news.hada.io/topic/30346.md) - Type: news - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-06-10T10:40:02+09:00 - Updated: 2026-06-10T10:40:02+09:00 - Original source: [github.com/apple](https://github.com/apple/container) - Points: 6 - Comments: 3 ## Topic Body - Mac에서 Linux 컨테이너를 **경량 가상 머신** 형태로 생성·실행하는 도구 - WWDC26에서 새로 추가된 **[Container Machine](https://github.com/apple/container/blob/main/docs/container-machine.md)** 은 홈 디렉토리와 저장소가 **자동으로 마운트**된 **빠르고 경량이며 영속적인 Linux 환경**을 실행 가능 - 기존 애플리케이션 단위 컨테이너와 달리 **Linux 환경 전체를 모델링** (WSL2와 비슷) - 이미지의 **init 시스템**을 실행해 장기 실행 서비스 등록 또는 프로세스 관리자 하에서 애플리케이션 테스트 가능 - `systemd`가 설치된 이미지에서 `systemctl start postgresql` 같은 실제 Linux 서비스 실행 가능 - **사용자명과 홈 디렉터리를 자동 매핑**해 저장소·dotfile을 macOS·Linux 양쪽에서 공유함 - 저장소가 macOS `$HOME`에 위치하며 내부 `/Users/<username>`에 마운트, macOS 에디터·IDE로 편집하면서 내부에서 빌드·실행 - 프로파일러·브라우저·GUI 디버거 등 **macOS 네이티브 도구**가 동일 파일 인식, 빌드와 검사 사이 복사 단계가 필요없음 - `alpine`, `ubuntu`, `debian` 등 **대상 배포판 수만큼** Container Machine 생성 가능, 각각 동일한 `$HOME`·dotfile 공유로 여러 배포판에서 빠른 테스트 - `/sbin/init`을 포함하는 모든 Linux 이미지를 직접 Container Machine 이미지로 사용 가능 - **OCI 호환 컨테이너 이미지**를 소비·생성하므로 표준 컨테이너 레지스트리에서 도커 이미지도 pull·push 가능 - 다른 OCI 호환 애플리케이션에서도 해당 이미지 실행 가능 - 저수준 컨테이너·이미지·프로세스 관리는 **Containerization Swift 패키지**에 의존 - 실행에 **Apple silicon** 탑재 Mac 필요, **macOS 26**에서 지원 - macOS 26의 가상화·네트워킹 신규 기능 및 개선 사항 활용, 이전 버전 macOS는 미지원 - Apache-2.0 라이선스 ### 동작 명령들 ```bash container machine create alpine:latest --name dev container machine run -n dev whoami # your host username, not root container machine run -n dev pwd # /home/<you> — your Mac home dir, mounted in container machine run -n dev # interactive shell; cd into your repos in $HOME container machine ls # list all container machines container machine inspect dev # JSON detail for one container machine stop dev # stop the container machine container machine rm dev # delete, including its persistent storage container machine set -n dev cpus=4 memory=8G container machine stop dev container machine run -n dev -- nproc ``` ### WWDC26의 소개 동영상 - [컨테이너 머신 살펴보기](https://www.youtube.com/watch?v=Q2xD6zkDz-s) - Containerization은 WWDC 25에서 오픈소스로 공개된 Swift 프레임워크로, macOS에서 Linux 컨테이너를 실행하기 위한 기반임 - 각 컨테이너에 가상 머신 기반 격리를 제공하도록 설계됐으며, 경량 가상 머신이라 빠른 성능과 1초 미만의 시작 시간을 제공 - **Container machine**은 Containerization 위에 구축된 새 기능으로, 컨테이너의 사용성과 속도에 가상 머신의 지속성을 결합하고, 통합 기능을 통해 Linux 환경이 macOS의 확장처럼 느껴지게 함 - # 설계 원칙 - Container machine은 기존 워크플로에 통합될 수 있도록 빠르고 가벼워야 함 - macOS와 Linux 사이를 쉽게 전환할 수 있어야 함 - 사용자가 새 환경을 빠르게 만들고 커스터마이즈할 수 있어야 하며, 이를 통해 여러 프로젝트가 의존성이나 툴체인 충돌 걱정 없이 전용 환경을 가질 수 있음 - 개발 생명주기 동안 필요한 도구와 의존성이 달라질 수 있으므로, 지속적인 환경에서 도구를 추가하고 시간이 지나도 다시 사용할 수 있어야 함 - 여러 플랫폼을 대상으로 개발할 때 큰 문맥 전환이나 새 도구 학습이 필요하지 않아야 함 ## Comments ### Comment 59348 - Author: recast7838 - Created: 2026-06-10T16:18:43+09:00 - Points: 1 충분한 성능이 나올까요? ### Comment 59327 - Author: click - Created: 2026-06-10T12:37:08+09:00 - Points: 1 아무리봐도 wsl2 맥판인데 호스트 볼륨 매핑할 때 IO 성능 확 떨어지는 건 없으려나요 지금도 limactl 가지고 vm 위에서 컨테이너 돌리는데 크게 다르지 않는 느낌도 들고요 ### Comment 59326 - Author: neo - Created: 2026-06-10T12:35:09+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48469658) - 여기서 몇 가지를 명확히 하면, 이건 **OCI 컨테이너**만을 뜻하는 게 아님 Container Machines는 영속성과 파일시스템 마운트를 지원해서, macOS를 쓰는 개발자에게 훌륭한 **가벼운 Linux 환경**이 됨 자세한 내용은 여기: [https://developer.apple.com/videos/play/wwdc2026/389]() - 아, Linux용 **Darwin/BSD 서브시스템**이군 - **OrbStack**은 내게 아주 잘 맞음 성능 면에서 이것과 비교하면 어떨지 궁금함 - OrbStack 개발자임 Virtualization.framework 대신, 파일시스템 공유 같은 기능을 위해 커스텀 장치와 프로토콜을 갖춘 **Rust 기반 가상화 스택**을 직접 사용함 Linux 머신과 컨테이너 실행에 특화해 고도로 최적화한 수직 통합 스택임 가장 큰 성능/자원 이득은 **동적 메모리**인데, 사용하지 않는 메모리를 macOS로 돌려줘서 메모리 사용량을 크게 줄임 Containerization을 포함해 다른 것은 이걸 지원하지 않음 Container Machines를 써 보니 OrbStack 머신보다는 기본 바인드 마운트가 붙은 OCI 컨테이너에 훨씬 가까워 보임 통합 기능이 적고 systemd나 일반적인 init 시스템을 돌리지 않아서 서비스를 실행하기 어렵다 - OrbStack은 개념적으로 마음에 들지만, 오픈소스이면서 무료인 대안이 많은데 **연 96달러 라이선스**를 정당화하기는 어렵다고 봄 지금은 차라리 Podman이나 Colima를 쓰겠음 - [https://tart.run/]()와의 비교도 보고 싶음 내가 보기엔 꽤 비슷함 - 완전한 Docker 환경은 아니고, 빌드 용도로 겨냥해 만든 것임 선택적으로 dockerd도 실행할 수 있고, [https://github.com/cpuguy83/crucible]()은 Containerization 프레임워크로 buildkitd나 dockerd를 실행한 뒤 docker/buildx CLI 또는 원하는 클라이언트 도구와 연결함 Containerization 프레임워크는 Virtualization 프레임워크 위에 얹힌 라이브러리라서, **각 컨테이너가 자체 VM**임 Machine은 Containerization 프레임워크 위에서 VM 안의 컨테이너에 여러 작업을 실행하는 도구임 - OrbStack을 정말 좋아하고, 지금 시점에서 왜 **Container Machines**를 대신 써야 하는지는 아직 잘 모르겠음 - 이 컨테이너들은 **공통 커널**을 공유하나? 아니면 각각 별도 VM에서 실행되나? 수정: 컨테이너마다 VM 하나임 [https://github.com/apple/container/blob/main/docs/technical-...]() - Apple 컨테이너는 **AI 코딩 에이전트**에 샌드박스를 제공하기에 좋음 모든 코딩 에이전트가 쉽게 발견할 수 있도록 MCP로 만들어 둠 [https://github.com/instavm/coderunner]() - 컨테이너 볼륨을 예를 들어 **외장 드라이브**로 바꿀 수 있는지 궁금했음 지금은 QMEU와 qcow2 이미지를 써서 그렇게 하고 있고, 그럭저럭 잘 작동함 - macOS가 왜 **WSL1 방식**을 시도하지 않는지 궁금함 Windows에서 그게 완전히 성공하지 못한 이유는 이해하지만, macOS는 또 다른 *nix라서 Windows에서 어려웠던 많은 부분이 Mac에서는 쉬울 것 같음 새 API를 조금만 추가하면 대부분의 Linux 애플리케이션을 macOS에서 네이티브로 실행할 수 있어 보임 BSD에는 실제로 이미 이런 게 있음 - Apple이 어차피 필요로 하는 **VM 인프라**보다 어떤 장점이 있을까? Linux 커널에 비해 ABI가 훨씬 단순하고 안정적인데 - 이게 Docker Desktop류를 대체해서, 옆에서 돌아가는 **비싼 Linux VM**을 없앨 수 있을까? - 나도 처음 든 생각이 그거였음 Docker Desktop 오버헤드는 꽤 심해서, 이게 DD에 네이티브로 들어오면 좋겠음 Docker가 역사적으로 성능 개선을 시도하다가 플랫폼 한계를 빠르게 받아들여야 했던 걸 보면 가능성은 있어 보이고, DD를 컨테이너 쪽으로 옮기는 건 자연스러워 보임 - 대형 공유 백그라운드 VM을 대부분 없애고, 더 작고 더 격리된 **Apple 네이티브 VM**들로 바꾸는 형태임 내 Podman 작업 부하를 Apple container로 옮기는 실험을 해 봤음: [https://gist.github.com/jmonster/39e14585e107dbf990a90966c0f...]() 요약하면 RAM/스토리지 사용량이 줄고, 존재감이 최소화됨 - 여기서도 다른 사람들이 언급했는데, 나는 최근 **Colima**로 갈아탔음 Docker Desktop을 우회하며 일하는 고통이 큼 - 그러면 정말 좋겠음 나는 며칠에 한 번씩 `rm -rf ~/.colima`를 하는 것 같음 - Apple이 이걸 할 만큼 신경 썼다는 게 놀라움 그래도 나는 여전히 Linux를 쓰고 싶지만, **MacBook의 가치**는 굉장함 - 나도 언제나 Linux를 쓰고 싶지만, 가끔 회사가 MacBook을 줌 이 도구는 쓸지도 모르겠음 - Apple이 Linux 컨테이너를 과시하는 걸 볼 때마다 **패배 인정** 말고는 달리 보기 어려움 아직 역량이 있었다면 Darwin으로도 충분히 할 수 있었을 텐데 - Apple은 macOS를 독점 코드로 만들기로 한 순간부터 **서버와 개발자 시장**에서 패배하도록 스스로 판을 깔았음 진지한 개발자가 디버그하고 수정할 수 없는 폐쇄 소스 코드를 왜 쓰겠나? 특히 프로덕션 서버에서? 진지한 개발자나 해커가 macOS를 쓰지 않는 이유도 같음 개발자라는 것의 핵심 중 하나는 어떤 계층의 코드든 파고들어 디버그하고 고칠 수 있는 능력이기 때문임 - 인터넷 역사 30년만 바꾸면 됨 - 대안이 뭘까? Apple은 10년 전에 서버 시장을 포기했고, 그전에도 실제 지원은 거의 없었음 Darwin 컨테이너를 지원한다고 해도 무슨 의미가 있을까? 말 그대로 아무도 그걸 대상으로 빌드하지 않을 것이고, **Linux가 이겼음** - 이게 새 기능인가? 이미 있던 걸로 생각했음 내가 테스트했을 때는, 작은 파일을 많이 `stat`하는 Node/Rust 개발 환경에서 **파일시스템 성능**이 쓸 만한 수준이 아니었음 업데이트: 새로워진 건 `container machine` 하위 명령임 테스트해 보려 했지만 내 환경에서는 container가 아예 실행되지 않았음: [https://github.com/apple/container/issues/1681]() - OrbStack을 써 봤는지 궁금함 아직 할 일은 더 있지만, 테스트할 작업 부하는 환영함 OrbStack의 커스텀 파일시스템 공유 프로토콜에서 작은 파일과 흔한 개발자 작업 부하를 최적화하는 데 많은 노력을 들였음 표준 virtiofs는 아님 - 참고로 **Podman**은 macOS에서도 됨 이미 있는 container 프레임워크를 사용해 머신을 실행함 루트 권한 방식도, 루트리스 방식도 가능함