Container Machine: Mac에서 동작하는 영속적인 Linux 환경

Q: 무엇이 필요한가요?

macOS 26을 실행하는 Apple silicon Mac이며, 이는 container 도구 전반의 요구 사항과 동일합니다.5 이 도구는 Swift로 작성된 오픈소스로 GitHub에 있습니다.5

Q: 1.0으로 업그레이드하면 깨지는 것이 있나요?

한 가지 있습니다. 시스템 구성이 UserDefaults 기반 속성에서 ~/.config/container/config.toml의 TOML 파일로 이동하고, container system property get/set 하위 명령이 제거됩니다.2 1.0 릴리스 노트는 마이그레이션 튜토리얼을 링크합니다.2 버전 0 XPC API 호환성도 제거되는데, 이는 그 API에 맞춰 클라이언트를 만들었다면 중요한 사항입니다.2 container machine은 이번 WWDC가 줄곧 들려준 같은 이야기에 맞물립니다. 크로스플랫폼 및 에이전트 기반 개발의 진지한 보금자리로서의 Mac이라는 이야기죠. MLX로 Mac에서 에이전트 기반 AI 실행하기는 그 이야기의 모델 서빙 절반을 다루고, Swift의 새로운 기능 (2026)은 Swift-on-Linux를 일급 대상으로 만드는 언어 작업을 다룹니다. 전체 시리즈 허브는 Apple Ecosystem 시리즈입니다.

8분 소요

Apple의 container 도구가 WWDC 주간에 1.0에 도달했고, 그 핵심 기능은 Mac 개발자들이 수년간 우회책으로 버텨 온 빈틈을 메웁니다. 바로 macOS의 일부처럼 동작하는 영속적인 Linux 환경, container machine입니다.² 이를 소개한 WWDC 세션은 그 요점을 한 문장으로 압축합니다. “Container machine은 container처럼 빠르고 가벼우면서, 가상 머신처럼 영속적입니다.”¹ 저장소와 dotfiles를 양쪽에서 모두 사용할 수 있고, 로그인 사용자는 Mac 계정과 일치하며, 머신은 세션 사이에도 파일시스템을 유지합니다. 그래서 화요일에 설정해 둔 Linux 툴체인이 금요일에도 그대로 남아 있습니다.³

Watch on Apple Developer ↗

세션 389, “Discover container machines.”

한눈에 보기

container machine은 WWDC 주간에 GitHub에 공개된 container 1.0.0에 포함되어 있습니다. Apple이 WWDC 2025에서 오픈소스로 공개한 Containerization 프레임워크 위에서 “긴밀한 호스트 통합을 갖춘 수명이 긴 Linux 환경”을 제공합니다.²
container가 “애플리케이션을 모델로 삼는” 반면, container machine은 “Linux 환경을 모델로 삼습니다.” 이미지 자체의 init 시스템을 실행하고, 파일시스템 변경을 영속화하며, 표준 OCI 이미지로부터 생성됩니다.³
차별점은 호스트 통합입니다. Linux 로그인 사용자는 비밀번호 없는 sudo 권한과 함께 Mac 계정과 일치하고, 홈 디렉터리는 머신 내부에 마운트되며,⁴ 대화형 셸에 진입하면 macOS에서 작업하던 그 디렉터리에 그대로 들어가게 됩니다.¹
전체 하위 명령 집합은 create, run, list, inspect, set, set-default, logs, stop, delete이며, 짧은 별칭으로 m을 사용합니다.⁴
1.0 릴리스는 업그레이드 전에 알아 둘 만한 호환성 깨짐 변경 하나도 포함합니다. ~/.config/container/config.toml에 위치한 TOML 구성 파일이 기존의 UserDefaults 기반 시스템 속성을 대체하며, container system property 하위 명령은 사라졌습니다.²

애플리케이션 샌드박스가 아니라 Linux 환경

Apple의 문서는 그 경계를 정확하게 긋습니다. “container는 보통 애플리케이션을 모델로 삼습니다. container machine은 Linux 환경을 모델로 삼습니다.”³ 이 차이는 세 가지 동작에서 드러납니다. container machine은 systemd나 openrc 같은 이미지 자체의 init 시스템을 실행하므로, 수명이 긴 서비스를 등록하고 실제 프로세스 관리자 아래에서 애플리케이션을 테스트할 수 있습니다. systemctl start postgresql이 Linux 머신에서와 똑같이 동작합니다.³ 또한 변경 사항을 영속화하므로, 설치한 도구들이 프로세스와 함께 사라지지 않고 시간이 지나며 차곡차곡 쌓입니다.¹ 그리고 container가 사용하는 것과 동일한 OCI 이미지로 부팅하므로, container build로 빌드한 이미지가 곧 머신의 출발점이 됩니다.¹

이 기능을 도입한 풀 리퀘스트는 그 동기를 솔직하게 밝힙니다. container는 각 워크로드를 일회성 VM에서 실행하므로, 1.0 이전에는 로그인해서 작업할 수 있는 영속적인 Linux 환경을 유지할 내장 수단이 없었습니다.⁴ 내부적으로는 각 container machine도 여전히 Containerization 처리를 받습니다. 즉 VM 기반 격리를 갖춘 자체 경량 가상 머신과, 이 프레임워크가 중심으로 삼아 만들어진 1초 미만의 시작 시간을 갖습니다.¹

세션은 설계 목표를 워크플로 관점에서 설명합니다. macOS와 Linux를 오가는 일은 쉬워야 하고, 환경은 빠르게 만들 수 있어야 하며, “빠른 생성 덕분에 여러 프로젝트가 의존성이나 툴체인 충돌을 걱정하지 않고 각자 전용 환경을 가질 수 있습니다.”¹ 대상 배포판마다 머신 하나씩 두는 것이 의도된 패턴이며, 각 머신은 Mac의 동일한 홈 디렉터리와 dotfiles를 봅니다.³

루프: Mac에서 편집하고, Linux 안에서 빌드한다

세션 데모는 Vapor 웹 서버이며, 데모가 보여주는 워크플로 그 자체가 핵심입니다.¹ 프로젝트는 macOS의 Xcode에서 편집됩니다. 빌드와 실행은 Swift 툴체인이 설치된 container machine 안에서 일어납니다. Mac의 Safari는 IP 주소와 포트로 실행 중인 서버를 로드합니다. 발표자가 Mac의 Icon Composer에서 앱 아이콘을 다시 내보내 파일을 덮어쓰면, 브라우저를 새로 고침했을 때 복사 단계 없이 새 에셋이 나타납니다. 머신과 Mac이 동일한 파일을 공유하기 때문입니다.¹

Apple의 문서는 이 패턴을 일반화합니다. 저장소는 macOS의 $HOME에 있고 머신 내부에 마운트되므로, macOS 네이티브 도구(프로파일러, 브라우저, GUI 디버거)는 Linux 환경이 보는 것과 동일한 파일을 봅니다. 문서의 표현을 빌리면, “빌드했다”와 “검사하고 있다” 사이에 복사 단계가 없습니다.³

호스트 통합은 공유 마운트보다 더 깊이 들어갑니다. 머신은 Mac 사용자 이름과 일치하는 Linux 사용자를 자동으로 생성하고, 비밀번호 없는 sudo 권한을 부여하며, 현재 작업 디렉터리를 그대로 반영합니다. 그래서 whoami와 pwd는 안과 밖에서 동일하게 답합니다.¹ 답이 달라지는 단 하나의 명령은 uname입니다. Mac에서는 Darwin, 머신에서는 Linux입니다.¹

부딪히기 전에 알아 둘 만한 첫날의 마찰 하나가 있습니다. container machine은 격리된 네트워크를 가지며, 세션은 Mac의 브라우저가 머신 내부 서버에 도달하려면 그 서버가 외부 인터페이스에서 수신 대기해야 한다는 점을 분명히 밝힙니다.¹ 데모는 여러분이 하게 될 방식 그대로 이를 처리합니다. container machine list는 각 머신의 IP 주소를 이름과 리소스와 함께 표시하고, 서버 구성은 그 주소에 바인딩하며, Safari는 머신의 IP와 포트로 앱에 도달합니다.¹ 머신에서 트래픽을 내보내는 워크플로라면 어느 경우든 이 IP 주소 단계를 미리 계획해 두세요.

명령어

빠른 시작은 네 줄입니다.³

container machine create alpine:latest --name dev
container machine run -n dev whoami       # your host username, not root
container machine run -n dev pwd          # your Mac home directory, mounted in
container machine run -n dev              # interactive shell

container machine run은 두 가지 역할을 합니다. 명령이 주어지면 한 번 실행하고 종료하며, 없으면 대화형 셸을 열고, 머신이 중지된 상태라면 먼저 부팅합니다.³ 기본 머신을 지정하면 모든 호출에서 -n 플래그를 생략할 수 있습니다.

container machine set-default dev
container machine run                     # operates on dev

관리는 익숙한 동사들로 이루어집니다. ls, inspect, logs, stop, rm이며, 머신을 삭제하면 그 영속 저장소도 함께 제거됩니다.³ 리소스는 생성 후에도 container machine set -n dev cpus=4 memory=8G로 조정할 수 있으며, 다음 중지 및 시작 시점에 적용됩니다. 메모리는 기본값이 호스트 메모리의 절반이고, 홈 마운트는 rw(기본값), ro, none 중에서 고를 수 있습니다.³ 모든 명령은 별칭 m도 받으므로 m run과 m ls가 동작합니다.⁴

직접 만든 머신 이미지 가져오기

/sbin/init을 포함한 Linux 이미지라면 무엇이든 container machine으로 동작합니다.³ Apple의 문서는 ubuntu:24.04를 systemd, OpenSSH, 일반적인 명령줄 도구를 갖춘 머신 이미지로 바꾼 다음, 경량 VM 안에서 의미가 없는 systemd 유닛을 마스킹하는 완성된 Dockerfile을 제공합니다.³ container build로 빌드한 뒤 그 태그를 container machine create에 전달하면 됩니다.

프로비저닝에는 탈출구가 있습니다. 기본적으로 container는 첫 부팅 시 내장 설정 스크립트를 실행해 일치하는 사용자를 생성합니다. 이미지 안의 /etc/machine/create-user.sh 실행 파일이 그 스크립트를 대체합니다. 이 파일은 첫 부팅 시 root 권한으로 한 번 실행되며, CONTAINER_USER, CONTAINER_UID, CONTAINER_GID, CONTAINER_HOME, CONTAINER_MACHINE_ID가 설정된 채로 실행됩니다. 따라서 조직은 공유 베이스 이미지에 자체 사용자 설정을 담아 둘 수 있습니다.³

호환성 깨짐 변경을 포함한 1.0의 나머지

머신 기능이 이번 릴리스의 헤드라인이지만, 1.0에는 기존 사용자에게 영향을 주는 변경들이 담겨 있습니다.²

호환성이 깨지는 변경은 구성입니다. TOML 파일이 UserDefaults 기반 시스템 속성을 대체하고, container system property get과 set 하위 명령은 제거되었습니다.² 서비스는 시작 시 ~/.config/container/config.toml을 먼저 일치하는 항목이 우선하는 방식(사용자 파일, 그다음 패키지 설치 시 함께 제공되는 선택적 파일, 그다음 하드코딩된 기본값)으로 읽으며, 변경 사항을 적용하려면 서비스를 재시작해야 합니다.⁶

생활 편의성 추가 사항으로는 파일 복사를 위한 container cp 명령, container run의 --stop-signal 옵션, 그리고 container, 이미지, 네트워크, 볼륨 전반에 걸친 ls와 inspect 명령의 정돈된 구조화 출력(JSON, YAML, TOML)이 있습니다.² 네트워킹에는 IP 주소 누수를 막기 위해 XPC 연결을 리스(lease)로 사용하는 정확성 수정이 들어갔습니다.² 버전 0 XPC API와의 호환성은 제거되었으며, 버전이 지정된 API는 이후 릴리스에서 제공하기로 약속되었습니다.²

요구 사항은 0.x 계열에서 그대로 유지됩니다. macOS 26을 실행하는 Apple silicon Mac입니다. 메인테이너들은 macOS 26에서 재현할 수 없는 이슈는 보통 다루지 않는다고 밝힙니다.⁵

에이전트 워크플로가 주목해야 하는 이유

제 자리에서 본 해석이지 Apple의 주장은 아닙니다. container machine은 코딩 에이전트가 원하는 환경의 형태입니다. Mac에서 동작하는 에이전트는 호스트를 건드리지 않고 빌드를 실행하고, 서버를 띄우고, 의존성을 설치할 어딘가가 필요합니다. 빠르게 만들 수 있고, 실제 VM 경계로 격리되며, 한 세션에서 설치한 툴체인이 다음 세션까지 살아남을 만큼 충분히 영속적인 곳 말입니다. 지금까지 Mac의 답은 Docker Desktop 방식의 VM(무겁고, 하나의 거대한 공유 환경)이거나 일회성 container(격리되지만 기억하지 못함)였습니다. 버전이 지정된 OCI 이미지로 만들고, 저장소가 마운트되고, 내부에 비밀번호 없는 sudo 권한을 갖춘 프로젝트별 머신은 Linux 호스트에서 에이전트 샌드박스가 이미 동작하는 방식과 맞아떨어집니다.

같은 속성이 평범한 크로스플랫폼 작업에도 도움이 됩니다. 서버 사이드 Swift가 가장 명백한 수혜자입니다. 세션 데모가 Vapor이고, Foundation Models 프레임워크가 올여름 Linux 지원과 함께 오픈소스로 공개되므로, “내 Swift 코드가 Ubuntu에서 동작하는가”를 확인할 테스트 환경은 이제 container machine create 한 번 거리에 있습니다. Windows를 써 본 사람이라면 누구나 떠올릴 비교 대상은 WSL이며, 통합의 방향도 같습니다. 셸 하나만 거치면 닿는 진짜 Linux 커널과, 양쪽에서 모두 보이는 여러분의 파일입니다. Apple의 버전은 이미지 기반 워크플로를 이미 갖춘 채로 등장합니다.

FAQ

container machine이란 무엇인가요?

container machine은 macOS에서 동작하는 영속적인 Linux 환경으로, Apple의 오픈소스 container 도구의 기능으로서 버전 1.0.0부터 제공됩니다.² Containerization 프레임워크를 통해 자체 경량 가상 머신에서 실행되고, 표준 OCI 이미지로 부팅하며, 이미지의 init 시스템을 실행하고, 세션 사이에 파일시스템 변경을 영속화합니다.¹ 호스트 통합은 홈 디렉터리를 내부에 마운트하고, Linux 사용자를 비밀번호 없는 sudo 권한과 함께 Mac 계정과 일치시키며, 경계 양쪽에서 작업 디렉터리를 일관되게 유지합니다.⁴

일반 container와 무엇이 다른가요?

Apple의 문서는 이를 한 줄로 정리합니다. container는 “애플리케이션을 모델로 삼고”, container machine은 “Linux 환경을 모델로 삼습니다.”³ 일반적인 container run 워크로드는 일회성이며 프로세스 중심입니다. 머신은 상태를 유지하고, systemd나 openrc를 실행하며, container 수준의 생성 속도를 갖춘 VM처럼 시간이 지나며 다시 찾아오도록 만들어졌습니다.¹

무엇이 필요한가요?

macOS 26을 실행하는 Apple silicon Mac이며, 이는 container 도구 전반의 요구 사항과 동일합니다.⁵ 이 도구는 Swift로 작성된 오픈소스로 GitHub에 있습니다.⁵

1.0으로 업그레이드하면 깨지는 것이 있나요?

한 가지 있습니다. 시스템 구성이 UserDefaults 기반 속성에서 ~/.config/container/config.toml의 TOML 파일로 이동하고, container system property get/set 하위 명령이 제거됩니다.² 1.0 릴리스 노트는 마이그레이션 튜토리얼을 링크합니다.² 버전 0 XPC API 호환성도 제거되는데, 이는 그 API에 맞춰 클라이언트를 만들었다면 중요한 사항입니다.²

container machine은 이번 WWDC가 줄곧 들려준 같은 이야기에 맞물립니다. 크로스플랫폼 및 에이전트 기반 개발의 진지한 보금자리로서의 Mac이라는 이야기죠. MLX로 Mac에서 에이전트 기반 AI 실행하기는 그 이야기의 모델 서빙 절반을 다루고, Swift의 새로운 기능 (2026)은 Swift-on-Linux를 일급 대상으로 만드는 언어 작업을 다룹니다. 전체 시리즈 허브는 Apple Ecosystem 시리즈입니다.

참고 문헌

Apple, WWDC 2026 session 389, Discover container machines. Official transcript. Source for the definition (“A Container machine is fast and lightweight, like a container, and persistent like a virtual machine”), the Containerization recap (Swift framework for Linux containers on macOS, VM-based isolation, sub-second start times, open-sourced at WWDC 2025 along with the container tool), the design principles (including “quick creation allows multiple projects to have their own, dedicated environment, without the worry of conflicting dependencies or toolchains”), the OCI image reuse, statefulness, automatic user mapping and working-directory mirroring, the uname Darwin/Linux demo, and the Vapor workflow demo (edit in Xcode on macOS, build and run inside the machine, load from Safari by machine IP, Icon Composer asset update visible without a copy step). ↩↩↩↩↩↩↩↩↩↩↩↩↩↩
Apple, container 1.0.0 release notes, GitHub. Source for the 1.0.0 release, the “long-lived Linux environments with tight host integration” description, the breaking TOML configuration change (replacing UserDefaults-backed system properties and removing the container system property get and set subcommands, with a linked migration tutorial), the container cp command, the --stop-signal option, the structured output cleanup for ls and inspect across containers, images, networks, and volumes, the XPC-connection-as-lease fix for IP address leaks, and the removal of version 0 XPC API compatibility with a versioned API promised in a subsequent release. ↩↩↩↩↩↩↩↩↩↩↩↩
Apple, Container machine documentation, apple/container repository. Source for the application-versus-environment framing (“Containers are typically modeled after an application. A container machine is modeled after a Linux environment”), the init-system behavior including the systemctl start postgresql example, the edit-on-Mac/build-inside workflow and the no-copy-step framing, the one-machine-per-distro pattern with shared $HOME and dotfiles, the quickstart commands, run booting a stopped machine, set-default, the management verbs with rm deleting persistent storage, set for cpus/memory taking effect after stop and start, the half-of-host-memory default, the rw/ro/none home-mount modes, the /sbin/init requirement for machine images, the Ubuntu 24.04 Dockerfile example, and the /etc/machine/create-user.sh first-boot hook with its CONTAINER_USER, CONTAINER_UID, CONTAINER_GID, CONTAINER_HOME, and CONTAINER_MACHINE_ID variables. ↩↩↩↩↩↩↩↩↩↩↩↩↩↩
Apple, pull request #1662: Add container machine for managing persistent Linux environments, apple/container repository, merged June 8, 2026. Source for the motivation (each workload runs in an ephemeral VM, with no built-in way to keep a persistent Linux environment to log into), the login user matching the host account with passwordless sudo, the home directory mount, the machine keeping its filesystem and running the image’s own init system such as systemd or openrc, the full subcommand list (create, run, list/ls, inspect, set, set-default, logs, stop, delete/rm), and the m alias. ↩↩↩↩↩
Apple, container README, GitHub. Source for the requirements (a Mac with Apple silicon; supported on macOS 26, with maintainers typically not addressing issues that cannot be reproduced on macOS 26) and the description of the tool as written in Swift and optimized for Apple silicon. ↩↩↩
Apple, container configuration tutorial, apple/container repository. Source for the configuration file location at ~/.config/container/config.toml, the first-match-wins precedence (user file, then an optional file shipped with the package install, then hardcoded defaults), and the service reading the file once at startup so changes require a restart. ↩