WWDC26에서 모두가 놓친 발표, 이제 Mac이 진짜 Linux 개발 머신이 된다

WWDC26 세션 목록을 훑다가 389번에서 손이 멈췄습니다. 기사 제목은 죄다 Apple Intelligence, 새로운 Siri, Xcode의 AI Agent, Vision Pro였습니다. 그 사이에 11분짜리 세션 하나가 아무 홍보도 없이 올라와 있었습니다.

제목은 짧습니다.

Discover container machines

Apple 엔지니어 Michael이 나와서 화려한 그래픽도 없이 터미널을 엽니다. 친 명령은 세 줄입니다.

container machine create --name demo --set-default alpine
container machine run uname
container machine run

그러자 Mac 안에 Linux 환경이 뜹니다.

그런데 기존에 쓰던 컨테이너와 느낌이 다릅니다. 파일이 유지됩니다. Mac의 사용자 계정과 연결됩니다. 지금 작업 중인 디렉터리가 그대로 보입니다. OCI 이미지를 그대로 씁니다. 그리고 이 Linux 환경 하나가 자기 자신의 경량 VM 안에서 돕니다.

Apple은 이걸 Container Machine이라고 부릅니다.

저는 WWDC26에서 인프라·백엔드 하는 사람에게 제일 재미있는 발표가 이거였다고 생각합니다. 이유는 간단합니다. Apple이 Docker Desktop과 붙는 컨테이너 도구를 만드는 수준을 넘어서, Mac과 Linux 사이의 개발 경계를 줄이려 들고 있어서입니다.

시작은 WWDC25였다

Container Machine을 이해하려면 1년 전으로 돌아가야 합니다.

2025년 WWDC25에서 Apple은 Containerization이라는 프로젝트를 공개했습니다. Swift로 짠 오픈소스 프레임워크입니다. 역할은 명확합니다. Mac에서 Linux Container를 돌리는 것.

Containerization은 이미지 관리, 컨테이너 실행, 네트워크, 스토리지, Linux init system, VM 기반 격리까지 담습니다. 여기에 개발자가 직접 손대는 CLI가 붙었습니다. 이름도 짧습니다. container

이 도구는 OCI 호환 이미지를 가져와 실행하기 때문에 기존 Container Registry 생태계와 그대로 이어집니다.

그런데 여기서 설계 하나가 눈에 걸립니다.

Apple은 컨테이너 하나마다 VM을 만든다

macOS에서 Linux Container를 돌리려면 Linux Kernel이 있어야 합니다. macOS Kernel은 Darwin/XNU거든요. 그래서 Docker Desktop 같은 도구도 안쪽에 Linux VM을 하나 띄웁니다.

일반적인 구조를 거칠게 그리면 이렇습니다.

Mac
 │
 └─ Linux VM
      │
      ├─ Container A
      ├─ Container B
      ├─ Container C
      └─ Container D

Apple Containerization은 다릅니다.

Mac
 │
 ├─ Lightweight VM
 │      └─ Container A
 │
 ├─ Lightweight VM
 │      └─ Container B
 │
 └─ Lightweight VM
        └─ Container C

컨테이너마다 독립된 경량 VM을 씁니다. Apple은 이를 VM-based isolation이라고 설명합니다.

VM이라는 단어를 보면 바로 이 생각이 듭니다.

"그럼 느린 것 아닌가?"

저도 그랬습니다. Apple은 WWDC25 때부터 이 경량 VM의 sub-second startup, 1초 미만 시작 시간을 강조해 왔습니다. 기존 VM과 컨테이너의 중간 지점을 노린 셈입니다.

왜 굳이 컨테이너마다 VM을 만들까

격리(Isolation) 때문입니다.

컨테이너 기술의 전제는 Kernel 공유입니다. 일반적인 Linux 환경에서는 여러 Container가 Host Kernel을 나눠 씁니다.

Container A ─┐
Container B ─┼─ Linux Kernel
Container C ─┘

그래서 Container는 VM보다 가볍습니다. 반면 VM은 각자 Kernel을 하나씩 띄웁니다. Apple은 Apple Silicon의 가상화 성능을 밀어붙여 그 경계를 컨테이너 수준까지 내려버렸습니다. 하나의 Container 환경이 망가져도 옆 Container와의 격리 경계가 흐려지지 않습니다.

여기가 Apple Containerization에서 제일 독특한 대목입니다.

그런데 WWDC26에서 한 단계 더 나갔다

여기까지면 "Apple이 Docker 대체제를 만들었구나" 정도로 끝났을 겁니다. WWDC26에서 기능 하나가 더 붙었습니다.

Container Machine.

Apple의 표현을 줄이면 이렇습니다. 컨테이너처럼 빠르고 가볍지만 VM처럼 Persistent한 Linux 환경.

일반적인 Container는 일회성이 전제입니다. Container를 지우면 내부 변경도 같이 사라집니다. 그래서 데이터가 필요하면 Volume을 붙입니다.

Container Machine은 상태가 남습니다.

오늘 Linux 안에서 apt install nginx로 패키지를 깔아뒀다면 내일 다시 켜도 그대로 있습니다.

성격을 한 줄로 적으면 이렇습니다. Container의 빠른 생성 + VM의 Persistence + macOS와의 Host Integration. Apple이 Container와 VM 사이에 개발자 경험을 하나 새로 낸 겁니다.

실제로 만들어보자

공식 문서 기준으로 사용법은 꽤 단순합니다.

우선 Apple Silicon Mac이 필요합니다. container 프로젝트는 Apple Silicon에 맞춰 만들어졌고, 현재 공식 지원 환경은 macOS 26입니다. 설치는 GitHub Releases에서 Signed Installer Package를 받는 방식입니다.

설치가 끝나면 시스템 서비스를 올립니다.

container system start

그리고 Alpine 기반 Container Machine 하나를 만들어봅니다.

container machine create alpine:latest --name dev

기본 Machine으로 잡고 싶다면

container machine set-default dev

만들면서 바로 잡아도 됩니다.

container machine create \
  --name dev \
  --set-default \
  alpine

WWDC26 데모에서도 거의 같은 명령이 나옵니다.

Linux인지 확인해보자

Mac Terminal에서 uname을 치면 Darwin이 나옵니다. container machine run uname을 치면 Linux가 나옵니다.

같은 Terminal인데 명령 하나를 앞에 붙였을 뿐입니다. 돌아가는 Kernel이 바뀝니다. 이 차이가 생각보다 큽니다.

명령을 지정하지 않으면 Interactive Shell이 그냥 열립니다.

container machine run

여기서 Apple이 신경 쓴 티가 납니다. Mac 계정 이름이 taewook이라면 Container Machine 안에서도 같은 사용자로 작업합니다. Home Directory도 이어집니다. Mac에서 cd ~/projects/api-server 상태였다면 Container Machine 안에서도 같은 프로젝트가 그대로 보입니다. 공식 문서는 이걸 Automatic User Creation, Filesystem Sharing, Consistent Working Directory로 설명합니다.

개발자 입장에서 이게 꽤 큰 변화입니다.

기존 Container 개발의 귀찮은 부분

예전에는 머릿속에서 대략 이런 회로가 돌았습니다.

내 소스코드는 Mac에 있음 → Container에서는 어디에 Mount하지? → -v ./src:/app/src → Container 내부 Working Directory는? → /app → 파일 권한은? → UID/GID 확인 → 서비스 접근하려면? → -p 8080:8080

솔직히 저는 이 회로를 몇 년째 돌리면서도 -v 왼쪽이 호스트인지 오른쪽이 호스트인지 아직도 한 번씩 헷갈립니다. 인정합니다.

Container Machine이 줄이려는 게 이 Context Switching입니다. 경로도 같고 사용자도 같습니다. Kernel만 Linux로 갈아끼우고 작업하는 감각에 가까워집니다.

Container Machine에는 IP도 있다

container machine list를 치면 Machine 목록과 IP, 리소스 정보가 나옵니다.

WWDC26 데모에서는 Linux에서 Vapor Web Server를 띄운 다음 Container Machine의 IP를 Safari 주소창에 그냥 입력합니다. 로컬 개발에서 매번 Docker식 -p 8080:8080 포트 매핑을 머리에 얹을 필요가 줄어듭니다. Machine마다 독립적인 네트워크 환경이라서 그렇습니다.

여기서 systemd까지 들어온다

Container Machine의 또 하나 재미있는 점은 실제 Linux Machine에 가까운 환경을 만든다는 것입니다.

공식 문서에는 Ubuntu 24.04 기반 예제가 있습니다.

FROM ubuntu:24.04
ENV container container
RUN apt-get update && \
    apt-get install -y \
    dbus \
    systemd \
    openssh-server \
    curl \
    wget \
    vim \
    sudo
RUN systemctl set-default multi-user.target

빌드합니다.

container build -t local/ubuntu-machine:latest .

그리고 Machine으로 만듭니다.

container machine create local/ubuntu-machine:latest --name ubuntu

Apple 공식 문서도 /sbin/init을 포함한 이미지를 Container Machine으로 쓰는 방식을 안내하면서 Ubuntu + systemd 예제를 직접 제공합니다.

이러면 Container 안에서 Process 하나 띄우는 수준을 넘어, systemd 아래 PostgreSQL, Redis, nginx, Application이 함께 도는 환경까지 갑니다. 백엔드나 인프라 하는 사람에게는 이 지점이 제일 매력적입니다.

Production Linux와 점점 비슷해진다

Mac으로 서버 개발을 하다 보면 늘 작은 차이가 남습니다. 개발 환경은 macOS, 운영 환경은 Linux.

그래서 이런 순서로 사고가 터집니다.

Mac에서는 잘 됨 → CI에서 실패 → Linux Library 차이 → 권한 문제 → Filesystem 차이 → systemd 차이

Container Machine을 쓰면 Mac을 버리지 않고도 Linux 쪽 실행 환경을 훨씬 가까이 당겨옵니다.

배포판을 여러 개 동시에 물려도 됩니다. alpine-test와 ubuntu-dev Machine을 각각 만들어놓고 이렇게 씁니다.

container machine run -n alpine-test uname -a
container machine run -n ubuntu-dev uname -a

이렇게 나눠두면 하나의 Mac에서 Ubuntu, Alpine, Fedora 같은 서로 다른 Linux 환경을 프로젝트별로 갈라 쓰게 됩니다. Persistent 특성 덕분에 프로젝트별 Toolchain을 따로 유지하는 것도 됩니다. Project A는 Ubuntu + Java 25, Project B는 Alpine + Go, Project C는 Ubuntu + Rust. 환경 충돌은 피하면서 VM을 매번 따로 관리하는 부담은 덜어냅니다.

기본값은 생각보다 큽니다

공식 문서에 따르면 Container Machine의 기본 Memory는 Host Memory의 절반입니다. 여러 Machine을 굴린다면 리소스 크기는 손으로 잡아두는 편이 낫습니다.

container machine set -n dev cpus=4 memory=8G

바꾼 뒤에는 재시작합니다.

container machine stop dev
container machine run -n dev

16GB MacBook에서 아무 생각 없이 Machine을 늘리다 보면 어느 순간 Mac 쪽이 먼저 숨이 찹니다. 개발 환경별로 CPU와 Memory를 미리 그려두는 쪽을 권합니다.

Home Directory 전체 공유는 편한 만큼 위험합니다

Container Machine은 기본적으로 Mac의 Home Directory를 연결합니다. 편합니다. 그런데 개발용 이미지 안에서 신뢰 못 할 코드를 돌린다면 얘기가 달라집니다.

Home에는 보통 ~/.ssh, ~/.aws, ~/.kube, ~/.config, Git Credential, 소스코드, 개인 문서가 있습니다. 악성 npm 패키지나 Supply Chain 공격을 떠올리면, 모든 환경에 Home 전체를 Read/Write로 열어두는 건 저 같으면 안 합니다.

그래서 Apple은 Home Mount 모드를 둡니다. 기본값은 rw이지만, 읽기 전용으로 내리거나 아예 끊습니다.

container machine set -n dev home-mount=ro
container machine set -n dev home-mount=none

실무에서는 이 옵션이 꽤 중요합니다.

그렇다면 Docker Desktop은 끝난 것인가?

여기서 너무 멀리 가면 안 됩니다. 아직 아닙니다.

Container Machine이 흥미로운 기술인 건 맞지만, Docker Desktop이 쌓아둔 생태계까지 하루아침에 대체하는 건 다른 문제입니다. Docker Desktop에는 이미 손에 익은 Docker Compose, Kubernetes Integration, Extensions, BuildKit, Docker Context, 그리고 거대한 생태계가 붙어 있습니다.

Apple container는 OCI 호환 이미지를 쓰지만 Docker 생태계 전체와 같은 제품은 아닙니다. 특히 수십 개 서비스를 docker compose up 한 번으로 올리는 워크플로는 여전히 강력합니다.

지금 시점에 "Docker Desktop은 끝났다"라고 적는 건 과장입니다. 이렇게 보는 쪽이 정확합니다. Apple이 macOS에서 Linux 개발 환경을 제공하는 새로운 기본 레이어를 직접 만들기 시작했다.

더 재미있는 것은 Container Machine보다 아래 계층입니다

제가 더 보는 건 이 줄입니다.

Container Machine → container CLI → Containerization → Apple Virtualization Framework → Apple Silicon

Apple은 GUI Docker 대체제 하나를 만든 게 아닙니다. 가상화부터 Container Runtime, Networking, Storage, CLI까지 Apple Silicon에 맞춰 수직으로 쌓고 있습니다. Apple이 늘 하던 방식입니다. 하드웨어부터 개발 도구까지 Stack 전체를 쥡니다.

그리고 이미 1.0을 넘어섰다

container 1.0.0은 2026년 6월 9일 공개됐습니다. 이 버전의 주요 기능 중 하나가 container machine이었습니다. 당시 Apple GitHub Release 설명도 long-lived Linux environments with tight host integration이라고 적었습니다.

2026년 8월 현재 GitHub Releases에는 1.2.x까지 올라와 있습니다. WWDC 데모로만 남은 연구 프로젝트가 아니라, 손이 계속 들어가고 있는 실제 오픈소스 도구입니다.

Apple이 노리는 자리

저는 여기서 의도가 꽤 또렷하게 보입니다.

지금 Mac을 쓰는 개발자 상당수의 최종 배포 환경은 Linux입니다.

Developer MacBook → Git → CI/CD → Container → Kubernetes → Linux Server

개발자는 Mac을 쓰지만 서비스는 Linux에서 돕니다. 이 사이의 틈을 Docker가 오랫동안 메워왔습니다. Apple은 그 연결 계층 일부를 자기 플랫폼 안으로 끌고 들어오려 합니다. Container Machine은 그 방향을 훨씬 대놓고 보여줍니다.

Mac과 Linux의 경계가 흐려지고 있다

Windows에는 오래전부터 WSL이 있습니다. Mac에서는 Docker Desktop, Colima, Lima, OrbStack 같은 도구들이 그 자리를 맡아왔습니다. 이제 Apple 자신이 뛰어들었습니다.

다만 접근이 조금 다릅니다. Apple이 원하는 경험은 아마 이런 그림입니다.

macOS
$ cd ~/projects/api
$ container machine run
Linux
$ make
$ cargo build
$ swift run

"지금 VM 안에 들어와 있나?", "볼륨을 어디에 Mount했지?", "UID가 왜 다르지?" 같은 생각을 덜 하게 만드는 것.

11분짜리 세션이 중요했던 이유

AI 발표는 화려합니다. 새로운 Siri도 눈에 잘 띕니다. Vision Pro 데모는 기사 제목 뽑기 좋습니다.

그런데 개발 플랫폼의 변화는 대개 이렇게 조용히 시작됩니다. 11분짜리 세션. 터미널 몇 줄. 그 아래에 OCI, Linux, Virtualization, Container Runtime, Networking, Storage, systemd, Apple Silicon이 전부 물려 있습니다.

그래서 저는 WWDC26의 Container Machine을 새 CLI 기능 하나로 보지 않습니다. Apple이 Mac을 Linux 서버 개발 머신 쪽으로 더 깊이 끌고 가기 시작한 신호에 가깝다고 봅니다.

Docker Desktop을 당장 지울 이유는 없습니다. OrbStack이나 Colima가 갑자기 쓸모없어지지도 않습니다. Compose 중심의 복잡한 개발환경이라면 당분간 기존 도구가 훨씬 편합니다.

그래도 방향은 재미있습니다. 예전이 "Mac 위에서 Linux VM을 실행한다"였다면, 지금 Apple이 만들려는 경험은 "Mac에서 그냥 Linux로 개발한다"에 가깝습니다.

그 경계를 지우는 명령어가 이겁니다.

container machine run

몇 년 뒤에는 Mac에서 Linux 개발환경을 만드는 방법 자체가 지금과 꽤 달라져 있을지도 모릅니다. 아니면 저는 여전히 Docker Desktop을 켜둔 채로 있을지도 모르고요. 저도 아직 Machine 하나 만들어둔 게 전부라 판단은 그다음입니다.

참고

• Apple WWDC26 — Discover container machines, Session 389. Apple은 Container Machine을 Container에 포함된 경량 Persistent Linux Environment로 설명합니다.
• Apple container 프로젝트는 OCI 호환 이미지를 사용하며 Apple Silicon에 맞춰 만들어졌습니다. 현재 공식 문서는 macOS 26을 지원 환경으로 안내합니다.
• container machine의 Home Mount, CPU/Memory 설정, Ubuntu/systemd 환경 구성은 Apple 공식 GitHub 문서에서 확인됩니다.