apple/container, Container Machine 기능 추가

• Mac에서 Linux 컨테이너를 경량 가상 머신 형태로 생성·실행하는 도구
• WWDC26에서 새로 추가된 Container Machine 은 홈 디렉토리와 저장소가 자동으로 마운트된 빠르고 경량이며 영속적인 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 라이선스

동작 명령들

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의 소개 동영상 - 컨테이너 머신 살펴보기

• Containerization은 WWDC 25에서 오픈소스로 공개된 Swift 프레임워크로, macOS에서 Linux 컨테이너를 실행하기 위한 기반임
• 각 컨테이너에 가상 머신 기반 격리를 제공하도록 설계됐으며, 경량 가상 머신이라 빠른 성능과 1초 미만의 시작 시간을 제공
• Container machine은 Containerization 위에 구축된 새 기능으로, 컨테이너의 사용성과 속도에 가상 머신의 지속성을 결합하고, 통합 기능을 통해 Linux 환경이 macOS의 확장처럼 느껴지게 함

• 설계 원칙

  • Container machine은 기존 워크플로에 통합될 수 있도록 빠르고 가벼워야 함
  • macOS와 Linux 사이를 쉽게 전환할 수 있어야 함
  • 사용자가 새 환경을 빠르게 만들고 커스터마이즈할 수 있어야 하며, 이를 통해 여러 프로젝트가 의존성이나 툴체인 충돌 걱정 없이 전용 환경을 가질 수 있음
  • 개발 생명주기 동안 필요한 도구와 의존성이 달라질 수 있으므로, 지속적인 환경에서 도구를 추가하고 시간이 지나도 다시 사용할 수 있어야 함
  • 여러 플랫폼을 대상으로 개발할 때 큰 문맥 전환이나 새 도구 학습이 필요하지 않아야 함

[click]

아무리봐도 wsl2 맥판인데 호스트 볼륨 매핑할 때 IO 성능 확 떨어지는 건 없으려나요
지금도 limactl 가지고 vm 위에서 컨테이너 돌리는데 크게 다르지 않는 느낌도 들고요

[GN⁺]

Hacker News 의견들

• 여기서 몇 가지를 명확히 하면, 이건 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 프레임워크를 사용해 머신을 실행함
    루트 권한 방식도, 루트리스 방식도 가능함