apple/container, Container Machine 기능 추가

 (github.com/apple)
12P by xguru | ★ favorite | 댓글 4개
  • 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 사이를 쉽게 전환할 수 있어야 함
    • 사용자가 새 환경을 빠르게 만들고 커스터마이즈할 수 있어야 하며, 이를 통해 여러 프로젝트가 의존성이나 툴체인 충돌 걱정 없이 전용 환경을 가질 수 있음
    • 개발 생명주기 동안 필요한 도구와 의존성이 달라질 수 있으므로, 지속적인 환경에서 도구를 추가하고 시간이 지나도 다시 사용할 수 있어야 함
    • 여러 플랫폼을 대상으로 개발할 때 큰 문맥 전환이나 새 도구 학습이 필요하지 않아야 함

함께 보면 좋은 글 β

GN⁺   [-]
Lobste.rs 의견들
  • 아직 비교가 안 나온 것 같은데, 이건 Lima와 가장 비슷해 보임
    => https://lima-vm.io/
    • 맞음, lima/colima와 꽤 비슷해서 갈아타야 하나 고민될 정도임
  • "vibecoding" tag disclosure: LLM이 “도운” 커밋 몇 개[0] 말고도, .gitignore에 Claude Code 상태 디렉터리[1]가 들어 있고 기여 정책에서도 “AI” 도구 사용을 권장함[2]
    [0] https://github.com/search/…
    [1] https://github.com/apple/container/…
    [2] https://github.com/apple/containerization/…
    • AI 기여 정책이 있는 소프트웨어 프로젝트를 전부 vibecoding으로 태그하는 건, 그 태그 사용 논쟁에서 나올 수 있는 최악의 결론임
  • 한동안 써봤는데, CPU와 RAM 기본값을 좀 더 합리적으로 잡아줬으면 함
    처음엔 느리다고만 느꼈고, 그다음엔 임의 작업이 크래시 나는 걸 봤고, 나중에야 기본적으로 컨테이너에 RAM의 5% 미만과 코어의 절반도 안 되는 양만 쓰고 있다는 걸 알게 됨
  • 아주 좋음. 이제야 Mac에서도 컨테이너를 제대로 쓸 만한 흐름이 생긴 듯함
  • 1.0.0 버전이 릴리스됨
  • 왜 이걸 podman 대신 써야 하는지 아는 사람 있음?
    • 컨테이너마다 VM을 하나씩 만들기 때문에 격리성이 더 좋음, 보안과 성능 측면에서 유리함
      그 외에는 꽤 비슷함
답변달기
recast7838   [-]

충분한 성능이 나올까요?

답변달기
click   [-]

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

답변달기
GN⁺   [-]
Hacker News 의견들

  • 여기서 몇 가지를 명확히 하자면, 이건 OCI 컨테이너만의 이야기가 아님
    Container Machines는 영속성과 파일시스템 마운트를 지원해서, macOS를 쓰는 개발자에게 훌륭한 가벼운 Linux 환경이 될 수 있음
    자세한 내용은 여기: https://developer.apple.com/videos/play/wwdc2026/389

    • container는 컨테이너를 다르게 실행함
      오픈소스 Containerization 패키지를 사용해 생성하는 컨테이너마다 가벼운 가상 머신을 실행하며, 그래서 보안은 전체 가상 머신 수준의 격리를 얻고, 프라이버시는 필요한 호스트 데이터만 각 가상 머신에 마운트하며, 성능은 전체 가상 머신보다 메모리를 덜 쓰고 공유 가상 머신에서 도는 컨테이너와 비슷한 부팅 시간을 제공함
      기술적 제한을 포함한 자세한 내용은 여기 있고, 버그 리포트와 기여를 찾고 있음: “Container: Technical Overview” https://github.com/apple/container/blob/main/docs/technical-overview.md
    • “Mac에서 매끄럽게 동작하는 고도로 통합된 Linux 환경”이라면, 어떤 커널이 돌고 있으며 UTM이 qemu 모드가 아닐 때처럼 Hypervisor.framework 위에서 호스팅되는 건지 궁금함
    • 파일시스템 마운트가 바인드 마운트와 어떻게 다른지 궁금함
    • 아, Darwin/BSD Subsystem for Linux인 셈이군
    • OrbStack 같은 것과 비교하면 어떤지 궁금함

  • macOS를 좋아하지만 가끔 Linux 머신이나 BSD, Raspberry Pi도 쓰는 드문 기회주의적 취미 개발자 부류에 속함
    Docker Compose로 Docker 이미지를 만들거나 Colima 같은 걸 쓸 수 있는데, 이것도 그쪽에 가까워 보이고 Docker 대비 장점도 있을 듯함
    다만 W^X 페이지 보호를 우회하려던 기대는 실현되지 않았음
    저장소가 이런 Container Machines를 맥락 속에 놓고 설명하지 않는 게 의아함
    Colima와 가까워 보이는데 Docker, Colima, Container Machines 중 언제 무엇을 써야 하는지 궁금함

  • 다 좋은데 Apple, 네이티브 Darwin Jails는 어디 있음?
    여러 macOS 컨테이너를 허용하면 사람들이 방 하나를 Mac Mini로 채워버릴까 봐 아직도 겁나는 건가? 머신당 두 개 정도의 무거운 가상 머신만 허용하지 말고

    • Darwin 네임스페이스가 훨씬 더 흥미롭고, 현재 보안 환경에서는 정말 절실함
      Apple의 Containerization에 왜 이렇게 열광하는지 잘 모르겠음
      수많은 컨테이너 런타임 중 하나일 뿐이고, OrbStack보다 나은 것도 아니며 사실은 더 나쁨
    • Darwin 위에 Foundation, AppKit 같은 계층, 즉 전체 macOS를 구동하는 구성요소들이 필요할 것 같음
      그래도 전체 아이디어는 좋음
    • 샌드박스 프로파일을 말하는 건가?

  • OrbStack은 나에게 정말 잘 동작함
    이것과 성능 면에서 어떻게 비교되는지 궁금함

    • OrbStack 개발자임
      우리는 Virtualization.framework 대신 파일시스템 공유 같은 기능을 위한 커스텀 장치와 프로토콜을 갖춘 Rust 가상화 스택을 사용함
      Linux 머신과 컨테이너 실행에 특화해 고도로 최적화한 수직 통합 스택임
      가장 큰 성능·자원 이득은 동적 메모리로, 사용하지 않는 메모리를 macOS에 돌려줘 메모리 사용량을 크게 줄임
      Containerization을 포함해 다른 것은 이걸 지원하지 않음
      Container Machines를 써보니 OrbStack 머신보다는 기본 바인드 마운트를 가진 OCI 컨테이너에 훨씬 가까워 보였고, 통합 기능이 적으며 systemd나 일반적인 init 시스템을 실행하지 않아서 서비스 실행이 어렵다
    • https://tart.run/와의 비교도 보고 싶음
      내가 보기엔 꽤 비슷함
    • OrbStack은 이론적으로 마음에 들지만, 오픈소스이면서 무료인 대안이 많은데 연 $96 라이선스 비용을 정당화하기 어렵다고 느낌
      지금이라면 Podman이나 Colima를 쓰는 편이 낫겠음
    • OrbStack을 정말 좋아하고, 현재로서는 왜 OrbStack 대신 Container Machines를 써야 하는지 잘 모르겠음
    • 완전한 Docker 환경은 아니고, 빌드를 목표로 만들었지만 옵션으로 dockerd도 실행할 수 있음
      https://github.com/cpuguy83/crucible는 Containerization 프레임워크를 사용해 buildkitd나 dockerd를 실행하고 docker/buildx CLI 또는 원하는 클라이언트 도구에 연결함
      Containerization 프레임워크는 Virtualization.framework 위에 놓이는 라이브러리라서 각 컨테이너가 자체 가상 머신임
      Machine은 이 프레임워크 위에서 가상 머신 안의 컨테이너에 여러 작업을 실행하기 위한 도구임

  • 이걸 Michael Crosby가 썼음
    그는 Docker, containerd 등의 오랜 유지보수자이고, Docker에서 처음으로 “Distinguished Engineer” 직함을 받은 사람이라 이 이름이 붙은 건 꽤 의미가 큼

  • 이 컨테이너들이 공통 커널을 공유하는지, 아니면 각각 별도 가상 머신에서 실행되는지 궁금함
    수정: 컨테이너마다 가상 머신 하나임 https://github.com/apple/container/blob/main/docs/technical-overview.md

    • 낭비 아닌가? “작은” 가상 머신이라고 해도 여전히 가상 머신임

  • 왜 이런 도구들은 항상 컨테이너 안에 $HOME 마운트를 홍보하는지 이해가 안 됨
    완전한 격리가 더 낫지 않나? 이런 걸 쓰는 이유가 그거 아닌가?

    • 컨테이너가 이렇게 인기를 얻은 건 개발자가 개발·배포를 쉽게 하려는 도구였기 때문임
      보안 계층으로 쓰려면 완전히 다른 목표이고, 매우 위험한 함정이 많음 [1]
      지난주에도 AI 에이전트가 Docker를 사용해 시스템에서 sudo를 우회했다는 글을 보고 사람들이 충격을 받았는데, Docker를 설치한 대부분에게도 일어날 수 있을 것 같음
      쉬운 개발 외의 용도로 컨테이너를 쓰려면 평균 사용자보다 훨씬 더 능숙해야 하고, 그런 경우 $HOME을 노출하지 않는 건 설정할 일 목록의 작은 항목일 뿐임
      [1] https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html
    • 내가 이걸 쓰는 이유는 예전의 -v $HOME:$HOME 컨테이너처럼, Homebrew 대신 Debian에서 익숙한 모든 명령줄 도구 환경을 얻기 위해서임
      대체로 이 환경이 내 홈 디렉터리에 접근하는 걸 신뢰하고, 필요하면 쉽게 버리고 다시 만들 수 있는 것도 장점임
      호스트에 설치하기 불편한 것, 예를 들어 npm 같은 건 여전히 덜 허용적인 컨테이너를 쓸 것임
    • 그렇지 않음. 머신의 핵심은 결국 외부 인터페이스임
      인터페이스가 없는 Linux 가상 머신은 계산만 하며 전기를 낭비하는 닫힌 상자일 뿐임
      Apple은 WSL의 교훈을 고려해야 함
      파일시스템 공유 접근은 정말 최소한이고, 그다음은 네트워킹이며 WSL에서 이건 깊은 토끼굴임
      사람들은 USB 장치 접근, X 전달, GPU 패스스루도 원하게 될 것임
    • 이런 걸 쓰는 목적은 완전 격리가 아니라 Linux 작업 부하를 실행하는 것임
      최근 Containerization으로 tup 테스트 스위트의 추적 로그를 생성해서 macOS에서 상대적 동등성을 맞추는 데 썼음
      완전히 격리되어 있었다면 수정한 소스 코드를 컨테이너에 넣기도 어렵고, 추적 로그를 다시 꺼내기도 어려웠을 것임
      바인드 마운트 같은 걸로 덮어쓸 수는 있겠지만 귀찮음

  • Docker 관점에서도 흥미롭지만, 나는 AI 에이전트와 신뢰할 수 없는 코드 실행을 위한 샌드박스로서 더 관심이 감
    그 관점에서 여기 글을 썼음: https://igorstechnoclub.com/sandbox-exec/
    가상 머신 수준 격리를 가진 sandbox-exec의 정신적 후계자처럼 느껴짐

    • 맞음, 그 글도 제한 사항 아래에서 이렇게 말함: “지원 중단 상태: 동작은 하지만 Apple은 개발자가 직접 사용하기보다 App Sandbox를 쓰길 권장한다”

  • 이게 Docker Desktop과 동등한 것들을 대체해서, 옆에서 도는 비싼 Linux 가상 머신을 없앨 수 있을까?

    • 큰 공유 백그라운드 가상 머신을 대부분 없애고, 더 작고 더 격리된 Apple 네이티브 가상 머신들로 대체함
      내 Podman 작업 부하를 Apple의 container로 옮겨보는 실험을 했음: https://gist.github.com/jmonster/39e14585e107dbf990a90966c0f84427
      요약하면 RAM·스토리지 사용량을 줄이고 존재감을 최소화함
    • 나도 첫 생각이 그거였음
      Docker Desktop 오버헤드가 꽤 심해서, 이게 DD에 네이티브로 들어오면 정말 좋겠음
      Docker가 역사적으로 성능 개선을 시도하다가 플랫폼 한계를 받아들여야 했던 걸 보면 가능성은 있어 보이고, DD를 컨테이너 쪽으로 옮기는 건 자연스러워 보임
    • 이건 명시적으로 Linux 가상 머신을 제공하며, Linux 가상 머신 없이 그걸 하기는 어려워 보임
      원하는 것, 즉 macOS에서 Linux 가상 머신 없이 Linux 컨테이너를 실행하는 것과는 실제 사용 사례가 반대임
      macOS의 Linux 기반 컨테이너 구현을 사용해, 컨테이너라기보다 가상 머신에 더 가까워 보이는 장기 실행 Linux 가상 머신을 제공함
    • Linux 가상 머신이 꼭 비쌀 필요는 없음
    • 여기서도 언급되지만, 나는 최근 Colima로 갈아탔음
      Docker Desktop을 우회하며 일하는 고통이 꽤 큼

  • 이제 macOS와 Windows 모두 그 위에서 Linux로 개발하는 걸 강하게 지원하는 셈임
    이 분야에서는 Linux를 당해낼 수 없다는 걸 더 노골적으로 인정할 수는 없나 봄
    Linux가 광고를 했다면 꽤 영리한 광고 소재가 됐을 것임

    • 둘 다 많은 애플리케이션의 실행 대상이 Linux 서버라는 점을 인정하는 것에 가깝다고 봄
      개발 대상이 Linux라는 뜻은 아님
    • Linux도 데스크톱에서는 macOS/Windows를 당해낼 수 없다는 걸 공개적으로 인정하지 못함
      그래서 macOS/Windows 데스크톱에서 Linux 가상 머신을 돌리는 이런 하이브리드 상황이 생김
    • 기업들은 실제 Linux 배포판을 쓰는 것만 빼고, Linux에서 개발하기 위해 뭐든 할 것임
    • 이건 오히려 Linux 데스크톱의 해가 완전히 패배했다는 뜻에 가까움
      Linux 게임은 콘텐츠 공급원으로 Windows 생태계에 의존함
      Linux가 컨테이너로 잘 포장되면 macOS와 Windows는 합산 90% 시장 점유율을 유지하고, 사전 설치 Linux 데스크톱과 노트북을 파는 OEM 시장을 지원하려는 사람은 거의 없어짐
      소비자가 쓰는 다른 “배포판”은 Android, webOS, 그리고 Chromebook의 진화형인 Googlebooks가 될 것임
      결국 일반 대중이 Apple Linux, Microsoft Linux, Google Linux, Asus Linux, LG Linux에만 관심을 갖는 피로스의 승리가 되고, IT 부서가 Linux 노트북을 지원할 유인이 사라짐
    • 많은 개발자가 Linux를 써야 하지만 여전히 Mac에서는 가상 머신으로, Windows에서는 WSL 같은 에뮬레이션류로만 씀
      한심함
답변달기