apple/container의 Container Machine — macOS에서 Linux 환경을 macOS처럼 쓰는 법

apple/container의 Container Machine

apple/container의 Container Machine — macOS에서 Linux 환경을 macOS처럼 쓰는 법

WWDC26에서 공개된 새 기능

애플이 WWDC26에서 apple/container 저장소에 Container Machine이라는 새 하위 명령을 추가해 맥에서 리눅스 컨테이너를 가볍게 돌릴 수 있는 길을 넓혔다. 기존에는 단순한 애플리케이션 단위 컨테이너만 지원했는데, 이번 업데이트로 리눅스 환경 전체를 모델링할 수 있게 됐고, WSL2의 맥 버전이라고 보면 가장 직관적이다. 도커 데스크톱의 무거운 VM 없이도 리눅스 서비스를 띄우고 빌드와 디버깅까지 가능한 만큼, 맥북을 메인으로 쓰면서 리눅스 환경이 필요한 개발자에게 분명한 희소식이다. 이번 WWDC26에서 공개된 Container Machine은 컨테이너의 사용성과 속도에 가상 머신의 지속성을 결합하는 데 초점을 맞췄으며, 통합 기능을 통해 리눅스 환경이 macOS의 확장처럼 느껴지게 만드는 것이 핵심 설계 목표다.

Container Machine이 기존과 다른 점

기존 애플리케이션 단위 컨테이너는 단일 프로세스를 격리해 실행하기 때문에 systemctl start postgresql 같은 명령은 당연히 안 먹히고, 컨테이너 안에 init 시스템 자체가 없다. Container Machine은 정반대로 이미지의 init 시스템을 그대로 실행하므로 systemd가 깔린 이미지라면 systemctl 명령이 그대로 동작한다. postgresql 같은 장기 실행 서비스를 등록하거나 프로세스 관리자 아래에서 애플리케이션을 테스트하는 것도 가능하며, 기존 워크플로에 자연스럽게 통합되도록 설계된 만큼 기존 도구와 충돌 없이 바로 끼워 넣을 수 있다는 점도 강점이다.

또 하나 큰 차이는 영속성과 파일 시스템 공유다. 맥의 $HOME 디렉터리가 컨테이너 내부 /Users/에 자동으로 마운트되어 dotfile과 저장소가 맥과 리눅스 양쪽에서 그대로 보인다. 맥에서 VS Code로 코드를 편집하고 컨테이너 안에서 빌드와 테스트를 돌리는 식이며, 빌드 결과물을 다시 호스트로 복사할 필요가 없다. 프로파일러와 브라우저, GUI 디버거 같은 macOS 네이티브 도구가 같은 파일을 그대로 인식하니 빌드와 검사 사이의 불필요한 복사 단계가 완전히 사라진다. OCI 호환 이미지를 그대로 쓸 수 있다는 점도 중요해 도커 허브 같은 표준 레지스트리에서 pull과 push가 가능하고 다른 OCI 호환 런타임에서도 그 이미지를 그대로 실행할 수 있다. 저수준 컨테이너·이미지·프로세스 관리는 Containerization Swift 패키지에 위임하므로 애플이 직접 관리하는 안정성 위에 빌드된다는 것도 매력적이다.

빠른 시작 — 실전 명령어

설치 후 바로 써볼 수 있는 명령어 묶음이다. 먼저 alpine 이미지로 dev라는 이름의 머신을 만들고 그 안에 들어가서 whoami를 찍어보면 root가 아닌 호스트 사용자명이 나오는 걸 확인할 수 있고, pwd를 치면 /Users/이 표시되어 맥 홈이 그대로 마운트됐음을 알 수 있다. 대화형 셸이 필요할 때는 container machine run -n dev 한 줄이면 충분하며, 워크플로에 자연스럽게 녹아드는 사용감이 이 도구의 핵심 매력이다.

container machine create alpine:latest --name devcontainer machine run -n dev whoamicontainer machine run -n dev pwdcontainer machine run -n devcontainer machine lscontainer machine inspect devcontainer machine stop devcontainer machine rm devcontainer machine set -n dev cpus=4 memory=8Gcontainer machine stop devcontainer machine run -n dev -- nproc

ls로 전체 머신 목록을 보고 inspect로 JSON 상세 정보를 확인할 수 있다. 정지는 stop, 삭제는 rm이며, rm은 영구 저장소까지 같이 삭제하니 신중하게 사용해야 한다. 리소스 조정은 set 명령으로 cpus와 memory를 지정할 수 있고, 변경 후에는 stop 후 다시 run해야 적용된다. alpine, ubuntu, debian 등 배포판마다 별도 머신을 만들 수 있어 같은 $HOME과 dotfile을 공유하면서도 여러 배포판을 동시에 테스트할 수 있다는 점이 큰 장점이다.

실무에서 바로 써먹는 시나리오

멀티 배포판 테스트

한 프로젝트가 alpine과 ubuntu 양쪽에서 돌아야 한다면 머신 두 개를 띄워서 동시에 검증할 수 있다. 기존에는 도커 컴포즈로 컨테이너 두 개를 띄우고 호스트 볼륨을 따로 마운트하는 식이었지만, Container Machine은 container machine create 한 줄이면 끝이다. 각 머신이 동일한 dotfile을 공유하므로 에디터 설정을 한 번만 해두면 모든 배포판에 그대로 적용되며, 의존성이나 툴체인 충돌 걱정 없이 전용 환경을 가질 수 있다는 점이 큰 장점이다.

systemd가 필요한 서비스 개발

마이크로서비스를 개발할 때 postgresql, redis 같은 서비스를 로컬에서 띄워야 한다면 이 도구가 정답이다. 컨테이너 안에서 systemctl이 그대로 동작하니까, 운영 환경과 동일한 셋업으로 개발할 수 있다. WSL2를 맥에서 쓰던 개발자라면 익숙한 사용감이 그대로다. /sbin/init을 포함한 모든 리눅스 이미지를 직접 머신 이미지로 쓸 수 있으니, 기존에 쓰던 Dockerfile이 있다면 그대로 활용할 수 있다. 개발 생명주기 동안 도구와 의존성이 달라져도, 머신을 추가로 생성해 격리된 환경을 유지할 수 있다.

AI 코딩 에이전트 샌드박스

애플이 직접 시사한 사용 사례다. MCP로 노출되어 있어서, AI 에이전트가 안전하게 코드를 실행할 수 있는 샌드박스로 활용할 수 있다. 격리가 VM 단위로 이뤄지니까, 에이전트가 호스트에 무슨 짓을 해도 안전하다. 인스타의 coderunner 같은 프로젝트가 이미 이 방식을 채택하고 있다. 도커 데스크톱보다 가볍고, OrbStack보다 무료라는 점이 매력적이다. AI 에이전트가 늘어나는 시대에 가벼운 샌드박스 수요는 계속 커질 것으로 보인다.

지금 당장 알아둘 주의사항

• Apple silicon 맥에서만 동작한다. 인텔 맥은 미지원이다.

• macOS 26 이상에서만 동작한다. 이전 버전은 가상화·네트워킹 신규 기능을 활용하지 못한다.

• 파일 시스템 성능은 작은 파일을 많이 stat하는 워크로드에서 아쉽다는 보고가 있다. Node, Rust 개발 환경처럼 import가 많은 프로젝트라면 직접 테스트해보길 권장한다.

• 컨테이너마다 VM이 따로 뜬다. 메모리 여유를 충분히 확보해두는 편이 낫다.

• 표준 virtiofs가 아니라 애플이 자체 구현한 파일 시스템 공유 프로토콜을 쓴다. IO가 떨어지는 건 어쩌면 이 때문이다.

• 1초 미만의 빠른 시작 시간을 제공하지만, 영구 저장소 크기만큼 디스크를 미리 잡아둬야 한다.

그래서 우리도 따라 할 수 있는가

도커 데스크톱의 무거운 VM에 질렸거나, OrbStack의 연 96달러가 부담이라면 Container Machine은 매력적인 대안이다. 무료이고 오픈소스(Apache-2.0)다. 맥 실리콘 + macOS 26 사용자라면 한 번쯤 시도해볼 만하다. 다만 파일 시스템 IO가 병목이 될 수 있는 워크로드는 미리 검증하고 넘어가는 게 안전하다. 영속성과 systemd 지원이 필요한 순간이 오면, 그때 가서도 늦지 않다. 컨테이너의 속도에 VM의 지속성을 합친 이 도구는, 개발자 워크플로에 자연스럽게 녹아들 가능성이 높다. 단기간의 실험용 머신은 부담 없이 만들고 지울 수 있으니, 가볍게 한 번 써보길 권장한다.