💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

들어가며 — 왜 지금 다시 화제인가

macOS에서 컨테이너를 돌리는 일은 오랫동안 "리눅스 VM을 하나 띄우고 그 안에서 도커를 돌리는 것"과 동의어였습니다. Docker Desktop, Lima, Colima, OrbStack 모두 구현 디테일은 다르지만 큰 그림은 같았습니다. 그런데 Apple이 WWDC25에서 오픈소스로 공개한 apple/container는 이 전제를 뒤집었습니다. 컨테이너 하나당 경량 VM 하나를 1:1로 붙이는 모델을 들고 나온 것입니다.

그리고 2026년 6월, WWDC26에서 공개된 Container Machine 기능이 GeekNews와 Hacker News를 다시 달궜습니다. 홈 디렉토리와 저장소를 자동으로 마운트해주는 범용 리눅스 머신 모드가 추가되면서, "이제 Lima나 WSL 같은 개발용 리눅스 환경까지 Apple 순정 도구로 해결되는 것 아니냐"는 반응이 쏟아졌습니다. GeekNews 댓글란에서는 Docker Desktop 라이선스 비용에 지친 기업 사용자들의 환영과, "compose 생태계 없이는 못 갈아탄다"는 현실론이 부딪혔습니다.

마침 AI 코딩 에이전트가 보편화되면서 격리된 실행 환경의 수요도 폭발했습니다. Claude Code 같은 에이전트가 수 시간씩 자율적으로 코드를 빌드하고 테스트하는 시대에, 에이전트마다 강하게 격리된 샌드박스를 빠르게 만들고 부수는 능력은 단순한 편의가 아니라 보안 요구사항이 됐습니다. 2026년 6월 npm 공급망 공격이 Red Hat Cloud Services까지 침투한 사건 이후로는 더욱 그렇습니다.

이 글에서는 Docker Desktop의 macOS 구조가 가진 근본 한계부터 apple/container의 아키텍처, Container Machine, 실전 사용법, 그리고 갈아탈 때 점검해야 할 체크리스트까지 차례로 살펴보겠습니다.

배경 — macOS에서 컨테이너가 어려운 이유

먼저 전제를 명확히 해두겠습니다. 우리가 흔히 말하는 컨테이너(OCI 컨테이너)는 리눅스 커널 기능의 조합입니다. namespace로 프로세스, 네트워크, 파일시스템 뷰를 격리하고, cgroup으로 자원을 제한하며, OverlayFS로 이미지 레이어를 합칩니다. 전부 리눅스 커널에만 있는 기능입니다.

macOS의 XNU 커널에는 이런 기능이 없습니다. 따라서 macOS에서 리눅스 컨테이너를 돌리려면 반드시 어딘가에 리눅스 커널이 있어야 하고, 그 말은 곧 가상 머신이 필요하다는 뜻입니다. 모든 macOS 컨테이너 도구의 차이는 결국 "VM을 어떻게, 몇 개나, 얼마나 가볍게 띄우느냐"의 차이입니다.

Docker Desktop의 구조 — 단일 거대 VM의 명암

Docker Desktop은 macOS에서 리눅스 VM을 하나 띄우고, 그 안에서 dockerd(도커 데몬)를 실행합니다. 모든 컨테이너는 이 단일 VM 안에서 형제 프로세스로 동작합니다.

+---------------------------------------------------------------+

| macOS Host |

| |

| docker CLI ----(API)----> +--------------------------------+ |

| | Linux VM (single, shared) | |

| Docker Desktop GUI | | |

| | dockerd + containerd | |

| | +-----------+ +-----------+ | |

| | | A | | B | | |

| | +-----------+ +-----------+ | |

| | | C | | D | | |

| | +-----------+ +-----------+ | |

| +--------------------------------+ |

+---------------------------------------------------------------+

이 구조의 장점은 명확합니다. 리눅스 서버에서 도커를 쓰던 경험이 거의 그대로 이식되고, VM이 하나라서 이미지 캐시와 네트워크를 모든 컨테이너가 공유합니다. compose로 여러 컨테이너를 묶어도 같은 VM 안이라 통신이 빠릅니다.

하지만 한계도 구조에서 나옵니다.

첫째, 자원 선점 문제입니다. VM 하나에 CPU 코어와 메모리를 미리 크게 할당해둬야 하는데, 컨테이너를 하나도 안 돌려도 그 자원은 잡혀 있습니다. 8GB를 할당한 VM은 유휴 상태에서도 macOS 메모리 압박에 기여합니다.

둘째, 격리 약화 문제입니다. 모든 컨테이너가 같은 커널을 공유하므로, 컨테이너 탈출 취약점 하나가 터지면 같은 VM의 다른 모든 컨테이너가 영향권에 들어갑니다. 신뢰할 수 없는 코드(예: AI 에이전트가 생성한 코드, 외부 PR의 CI 빌드)를 돌리기에는 불안한 구조입니다.

셋째, 파일 공유 성능입니다. macOS 디렉토리를 VM 안으로 바인드 마운트하려면 VirtioFS나 gRPC FUSE 같은 파일시스템 브리지를 거쳐야 하는데, 이는 오랫동안 Docker Desktop 성능 불만의 단골 소재였습니다.

넷째, 라이선스 비용입니다. Docker Desktop은 일정 규모 이상 기업에서 유료 구독이 필요합니다. 이것이 Colima와 OrbStack이 성장한 직접적 배경이기도 합니다.

apple/container의 접근 — 컨테이너 = 경량 VM

apple/container는 발상을 바꿨습니다. 컨테이너를 공유 VM 안의 프로세스로 만드는 대신, 컨테이너 하나마다 전용 경량 VM을 띄웁니다.

+---------------------------------------------------------------+

| macOS Host |

| |

| container CLI (Swift) |

| | |

| | Virtualization.framework / Containerization package |

| v |

| +-------------+ +-------------+ +-------------+ |

| | | | | | | |

| +-------------+ +-------------+ +-------------+ |

| |

| VM 개수 = 실행 중인 컨테이너 개수 (1:1) |

+---------------------------------------------------------------+

핵심 구성 요소를 하나씩 보겠습니다.

Virtualization.framework

Apple이 macOS Big Sur부터 제공하는 고수준 가상화 프레임워크입니다. Hypervisor.framework 위에 구축되어 있고, virtio 기반의 디스크, 네트워크, 메모리 벌룬 장치를 제공합니다. Apple Silicon에 최적화되어 있어 VM 생성과 부팅이 매우 빠릅니다. Lima나 UTM 같은 기존 도구들도 이미 이 프레임워크를 백엔드로 사용해왔지만, apple/container는 이것을 컨테이너 단위 격리에 직접 사용한다는 점이 다릅니다.

Containerization 스위프트 패키지

apple/container의 기반이 되는 라이브러리로, 역시 오픈소스입니다. OCI 이미지 풀과 언팩, 경량 리눅스 루트 파일시스템 구성, VM 부팅, 컨테이너 프로세스 실행까지를 Swift API로 제공합니다. 부팅 시간을 줄이기 위해 최소화된 리눅스 커널 구성을 사용하고, init 시스템으로는 Swift로 작성된 vminitd를 사용합니다. vminitd는 systemd 같은 범용 init이 아니라 컨테이너 프로세스 하나를 기동하는 데 필요한 최소 기능만 갖춘 전용 init입니다. 그 결과 컨테이너(즉 VM) 기동이 1초 미만 수준으로 내려옵니다.

데몬리스 설계

도커의 dockerd 같은 상시 실행 루트 데몬이 없습니다. container CLI가 필요할 때 헬퍼 프로세스를 띄우는 구조라서 공격 표면이 줄고, 유휴 상태에서 자원을 잡아먹지 않습니다. VM 자체도 컨테이너가 종료되면 함께 사라지므로, "안 쓰는데 8GB를 점유하는 VM" 문제가 구조적으로 없습니다.

WWDC26 — Container Machine 기능

WWDC25의 apple/container가 "컨테이너 실행"에 집중했다면, WWDC26에서 추가된 Container Machine은 범용 리눅스 개발 환경으로 영역을 넓혔습니다. GeekNews에서 화제가 된 핵심 포인트는 다음과 같습니다.

첫째, 홈 디렉토리 자동 마운트입니다. 머신을 만들면 macOS의 홈 디렉토리가 리눅스 머신 안에 자동으로 마운트되어, 별도 설정 없이 호스트 파일을 그대로 다룰 수 있습니다. Lima에서 마운트 설정을 YAML로 손보던 경험과 비교하면 진입 장벽이 크게 낮아졌습니다.

둘째, 저장소 자동 구성입니다. 머신 전용 디스크 이미지가 자동으로 만들어지고 관리되므로, 사용자가 디스크 크기나 포맷을 미리 고민할 필요가 없습니다.

셋째, WSL과 유사한 사용성입니다. 명령 한 줄로 리눅스 셸에 들어가고, 호스트와 파일을 자연스럽게 공유하는 흐름은 Windows의 WSL 사용 경험과 닮았습니다. "macOS의 WSL 순간이 왔다"는 댓글이 많았던 이유입니다.

이로써 apple/container는 두 가지 모드를 갖게 됐습니다. 짧게 살고 강하게 격리되는 컨테이너 모드와, 오래 살며 호스트와 긴밀히 통합되는 머신 모드입니다. AI 코딩 에이전트의 샌드박스로는 전자를, 일상 개발 환경으로는 후자를 쓰는 그림이 자연스럽습니다.

아키텍처 비교 — 네 가지 도구

macOS 컨테이너 도구 4종의 구조를 한 장으로 비교하면 다음과 같습니다.

[Docker Desktop] [Lima / Colima]

macOS macOS

| |

+-- 단일 공유 VM +-- 단일 공유 VM (QEMU 또는 VZ)

| |

+-- dockerd +-- containerd / dockerd

+-- 컨테이너 N개 +-- 컨테이너 N개

[OrbStack] [apple/container]

macOS macOS

| |

+-- 단일 공유 VM (자체 최적화) +-- micro VM 1 -- 컨테이너 1

| +-- micro VM 2 -- 컨테이너 2

+-- 컨테이너 N개 +-- micro VM N -- 컨테이너 N

(공유 커널 없음, VM:컨테이너 = 1:1)

주요 특성을 표로 정리하면 다음과 같습니다. 사양상 표 안에 특수문자를 쓸 수 없어 수치는 말로 풀었습니다.

| --- | --- | --- | --- | --- |

실전 사용법

설치

Apple Silicon Mac과 macOS 15 이상이 필요하며, 네트워킹 기능을 온전히 쓰려면 macOS 26 이상이 권장됩니다. GitHub 릴리스에서 서명된 설치 패키지를 받거나 Homebrew로 설치합니다.

Homebrew로 설치

brew install --cask container

API 서비스(헬퍼) 시작 — 최초 1회

container system start

상태 확인

container system status

이미지 풀과 컨테이너 실행

도커 사용자라면 명령 체계가 익숙할 것입니다.

이미지 풀 (Docker Hub의 OCI 이미지 그대로 사용)

container image pull alpine:latest

대화형 컨테이너 실행 — 이 한 줄이 전용 VM을 부팅한다

container run -it alpine:latest sh

백그라운드 실행과 포트 공개

container run -d --name web -p 8080:80 nginx:latest

실행 중인 컨테이너 확인

container list

로그와 종료

container logs web

container stop web

container delete web

체감상 가장 인상적인 부분은 기동 속도입니다. container run 명령이 커널 부팅을 포함하는데도 1초 미만에 셸이 떨어집니다. "VM이라서 느릴 것"이라는 직관이 깨지는 지점입니다.

이미지 빌드

Dockerfile을 그대로 사용합니다. 빌드는 BuildKit을 실행하는 전용 빌더 VM에서 수행됩니다.

빌더 시작 (최초 1회, 자원 지정 가능)

container builder start --cpus 4 --memory 8g

Dockerfile 기반 빌드

container build --tag myapp:dev --file Dockerfile .

멀티 아키텍처 빌드 (arm64 + amd64)

container build --arch arm64 --arch amd64 --tag myapp:multi .

레지스트리에 푸시

container registry login ghcr.io

container image push ghcr.io/myorg/myapp:dev

평범한 Dockerfile이 그대로 동작한다

FROM golang:1.24-alpine AS build

WORKDIR /src

COPY . .

RUN go build -o /out/server ./cmd/server

FROM alpine:3.21

COPY --from=build /out/server /usr/local/bin/server

EXPOSE 8080

ENTRYPOINT ["server"]

볼륨과 파일 공유

호스트 디렉토리는 virtio 기반 공유로 VM 안에 마운트됩니다.

현재 디렉토리를 컨테이너의 /work 로 마운트

container run -it --volume "$PWD:/work" --workdir /work alpine:latest sh

명명된 볼륨 생성과 사용

container volume create pgdata

container run -d --name db --volume pgdata:/var/lib/postgresql/data postgres:17

네트워킹

macOS 26 이상에서는 컨테이너마다 전용 IP 주소가 부여됩니다. 같은 VM 안에서 포트를 나눠 쓰는 도커 데스크톱 모델과 달리, 컨테이너 간 통신이 실제 네트워크 토폴로지에 가깝게 동작합니다.

컨테이너 IP 확인

container list --format json

사용자 정의 네트워크 생성 (macOS 26 이상)

container network create devnet

container run -d --network devnet --name api myapp:dev

container run -d --network devnet --name cache redis:7

devnet 안에서는 이름으로 서로 찾을 수 있다

Rosetta로 amd64 이미지 실행

Apple Silicon에서 amd64(x86_64) 전용 이미지를 돌려야 할 때는 Rosetta 2 번역을 사용합니다. Virtualization.framework는 리눅스 VM 안의 x86_64 바이너리를 Rosetta로 실행하는 기능을 제공하며, apple/container는 이를 그대로 활용합니다. QEMU 에뮬레이션 대비 체감 속도가 크게 빠릅니다.

amd64 이미지를 명시적으로 지정해 실행

container run --arch amd64 -it amazonlinux:2023 bash

멀티 아치 매니페스트가 있으면 기본은 arm64를 선택한다

container image pull --arch amd64 mysql:8.4

다만 Rosetta 번역에도 한계는 있습니다. AVX512 같은 일부 명령어 확장은 지원되지 않고, JIT를 많이 쓰는 워크로드에서는 네이티브 arm64 대비 성능 차이가 벌어질 수 있습니다. 가능하면 멀티 아치 이미지를 빌드하는 쪽이 정석입니다.

OCI 호환성 — 생태계는 그대로

apple/container가 도커를 대체할 수 있는 결정적 이유는 OCI 표준 준수입니다. 이미지 포맷은 OCI Image Spec, 레지스트리 통신은 OCI Distribution Spec을 따르므로 Docker Hub, GitHub Container Registry, Amazon ECR 등 기존 레지스트리를 그대로 사용합니다. Dockerfile로 빌드한 이미지는 리눅스 서버의 도커, Kubernetes, 클라우드 런타임 어디서든 동일하게 동작합니다.

즉 "로컬 개발은 apple/container, 배포는 기존 파이프라인 그대로"라는 점진적 도입이 가능합니다. 이미지가 호환되므로 팀 전체가 한 번에 갈아탈 필요도 없습니다.

성능과 보안 트레이드오프

컨테이너당 VM 모델의 손익계산서를 정리해보겠습니다.

| 관점 | 단일 공유 VM 방식 | 컨테이너당 VM 방식 |

| --- | --- | --- |

| 격리 강도 | 커널 공유로 약함 | 하드웨어 가상화로 강함 |

| 커널 취약점 영향 | 전체 컨테이너로 전파 | 해당 VM 하나로 국한 |

| 메모리 오버헤드 | VM 1개 고정 선점 | 컨테이너마다 커널과 init 비용 추가 |

| 기동 속도 | VM은 이미 떠 있음 | 커널 부팅 포함 1초 미만 |

| 유휴 비용 | 항상 VM 할당량 점유 | 컨테이너 없으면 거의 0 |

| 컨테이너 간 통신 | 같은 커널 안에서 빠름 | 가상 네트워크 경유 |

| 다수 컨테이너 실행 | 자원 공유로 유리 | VM 수만큼 오버헤드 누적 |

격리 강화는 분명한 이득입니다. 커널을 공유하지 않으므로 컨테이너 탈출 취약점의 폭발 반경이 VM 하나로 제한됩니다. AWS가 Lambda를 Firecracker microVM 위에 올린 것과 같은 논리이며, 신뢰 경계가 불분명한 코드(외부 기여 CI, AI 에이전트 산출물)를 다루는 환경에서 특히 중요합니다.

반면 메모리 오버헤드는 실재합니다. VM마다 게스트 커널과 페이지 테이블, vminitd가 올라가므로 컨테이너당 수십 MB 수준의 고정 비용이 추가됩니다. 컨테이너 2~3개를 띄우는 일반적 개발 시나리오에서는 오히려 단일 거대 VM보다 총 점유가 작지만, 마이크로서비스 20개를 동시에 띄우는 시나리오에서는 누적 오버헤드를 계산해봐야 합니다. 메모리 벌루닝이 유휴 VM의 메모리를 회수해주지만 만능은 아닙니다.

실전 시나리오 — AI 코딩 에이전트 샌드박스 만들기

격리 강화가 가장 빛나는 실전 사례를 하나 만들어보겠습니다. AI 코딩 에이전트에게 외부 저장소의 코드를 빌드하고 테스트시키는 작업입니다. 에이전트가 무엇을 실행할지 미리 알 수 없으므로, 작업 단위로 1회용 VM을 만들고 끝나면 흔적 없이 폐기하는 패턴이 적합합니다.

#!/bin/bash

agent-sandbox.sh — 에이전트 작업마다 1회용 격리 컨테이너를 만든다

set -euo pipefail

TASK_ID="$1"

REPO_URL="$2"

SANDBOX_NAME="agent-${TASK_ID}"

1. 작업 전용 볼륨 생성 (산출물 회수용)

container volume create "${SANDBOX_NAME}-out"

2. 네트워크 제한이 걸린 1회용 컨테이너 실행

- 호스트 디렉토리는 마운트하지 않는다 (홈 디렉토리 접근 차단)

- 산출물 볼륨만 쓰기 가능으로 연결

container run --rm \

--name "${SANDBOX_NAME}" \

--cpus 2 --memory 4g \

--volume "${SANDBOX_NAME}-out:/out" \

ubuntu:24.04 \

bash -c "git clone ${REPO_URL} /src && cd /src && make test 2>&1 | tee /out/test.log"

3. 결과만 회수하고 볼륨 정리

container run --rm --volume "${SANDBOX_NAME}-out:/out" alpine:latest cat /out/test.log

container volume delete "${SANDBOX_NAME}-out"

이 패턴의 핵심은 세 가지입니다. 첫째, 에이전트 코드가 컨테이너를 탈출하더라도 도달하는 곳은 최소 구성의 1회용 게스트 커널일 뿐, 다른 작업이나 호스트가 아닙니다. 둘째, 호스트 파일시스템을 아예 마운트하지 않음으로써 비밀 정보 유출 경로를 차단합니다. 셋째, run 명령의 rm 옵션으로 작업 종료와 동시에 VM과 컨테이너가 함께 소멸하므로 잔여 상태가 누적되지 않습니다. 단일 공유 VM 모델에서는 첫 번째 보장을 만들 수 없다는 점이 결정적 차이입니다.

운영 팁과 트러블슈팅

몇 달간 써보면 마주치게 되는 운영 이슈와 해법을 정리합니다.

디스크 사용량 관리

이미지와 빌더 캐시는 쌓입니다. 주기적으로 정리해주는 편이 좋습니다.

사용하지 않는 이미지 정리

container image prune

빌더 VM 중지와 재시작 (캐시 초기화 효과)

container builder stop

container builder delete

container builder start --cpus 4 --memory 8g

사설 레지스트리 인증 문제

기업 환경의 사설 레지스트리는 인증 토큰 만료가 잦습니다. 로그인 상태를 먼저 의심하세요.

인증 정보 갱신

container registry login registry.internal.example.com

풀이 실패하면 상세 로그로 원인 확인

container --debug image pull registry.internal.example.com/team/app:latest

시스템 서비스가 응답하지 않을 때

헬퍼 프로세스가 꼬였다면 시스템 서비스를 재시작합니다. 실행 중인 컨테이너는 종료되므로 주의가 필요합니다.

container system stop

container system start

container system logs # 문제가 반복되면 로그 확인

메모리 사용량 점검

컨테이너당 VM 모델에서는 총 메모리 점유를 가끔 확인하는 습관이 좋습니다. 컨테이너별 할당량을 명시하면 예측 가능성이 올라갑니다.

컨테이너별 자원 할당을 명시하는 습관

container run -d --name api --cpus 2 --memory 1g myapp:dev

실행 중 컨테이너와 상태 확인

container list --all

기존 도구에서 갈아탈 때 체크리스트

Docker Desktop이나 Colima에서 apple/container로 옮기기 전에 다음을 점검하시기 바랍니다.

1. compose 의존도 확인. docker-compose.yml로 다중 컨테이너 스택을 관리하고 있다면 현재로서는 직접 대응물이 없습니다. 컨테이너를 개별 실행하는 스크립트로 풀어내거나, compose가 필수인 프로젝트는 기존 도구를 병행해야 합니다.

2. Testcontainers 등 도커 API 의존 도구 확인. 도커 소켓 API를 직접 호출하는 테스트 라이브러리는 동작하지 않을 수 있습니다. 팀의 통합 테스트 구성을 먼저 점검하세요.

3. macOS 버전 확인. macOS 15에서는 일부 네트워킹 기능(컨테이너별 IP, 사용자 정의 네트워크)에 제약이 있습니다. 팀원 전체가 macOS 26 이상인지 확인하는 편이 좋습니다.

4. amd64 의존 이미지 목록화. Rosetta로 대부분 해결되지만, 커널 모듈이나 특수 명령어에 의존하는 이미지는 미리 테스트해야 합니다.

5. CI와의 정합성. 로컬은 apple/container, CI는 리눅스 도커라면 이미지 호환성은 문제없지만 네트워킹과 볼륨 동작 차이가 테스트 결과에 영향을 줄 수 있습니다.

6. Kubernetes 로컬 클러스터 필요 여부. kind나 minikube처럼 도커 위에 클러스터를 올리는 도구를 쓴다면 아직은 기존 환경 유지가 현실적입니다.

7. 점진 도입 전략 수립. 이미지가 OCI 호환이므로 빌드와 단일 컨테이너 실행부터 옮기고, 다중 컨테이너 개발 환경은 천천히 옮기는 2단계 전략이 안전합니다.

한계와 비판적 시각

균형을 위해 비판적 관점도 정리합니다.

리눅스 전용 기능의 부재. 단일 VM 도구들은 VM 안이 통째로 리눅스라서 특권 컨테이너, 커널 모듈 로드, eBPF 디버깅 같은 작업이 가능합니다. 컨테이너당 microVM 모델에서는 게스트 커널이 최소 구성이라 이런 고급 시나리오에 제약이 있습니다. Container Machine 모드가 일부를 메워주지만 컨테이너 모드와는 별개 흐름입니다.

compose 생태계 공백. 현대 개발 워크플로에서 compose는 사실상 표준입니다. "db 하나, 캐시 하나, 앱 하나"를 선언적으로 띄우는 경험 없이 CLI 명령을 나열하는 것은 분명한 퇴보로 느껴질 수 있습니다. 커뮤니티에서 호환 레이어 시도가 진행 중이지만 공식 지원은 아직 없습니다.

Apple 생태계 종속. 이 도구는 Apple Silicon 전용이고 macOS 버전을 탑니다. 팀에 리눅스 데스크톱 사용자가 섞여 있다면 공통 도구가 될 수 없습니다. 또한 Apple의 오픈소스 프로젝트가 장기적으로 얼마나 활발히 유지될지에 대한 회의론도 Hacker News에서 반복적으로 제기됩니다.

성숙도. Docker Desktop에는 10년치 엣지 케이스 대응이 쌓여 있습니다. 신생 도구는 레지스트리 인증 방식, 프록시 환경, 기업 VPN 같은 현실 세계의 지저분한 조건에서 다듬어질 시간이 더 필요합니다.

전망

그럼에도 방향성은 분명해 보입니다. 첫째, 격리 강화는 시대의 요구입니다. 공급망 공격과 AI 에이전트 샌드박싱 수요가 커질수록 하드웨어 가상화 격리의 가치는 올라갑니다. 둘째, OS 벤더가 직접 컨테이너 런타임을 제공한다는 사실 자체가 게임 체인저입니다. Windows에 WSL이 들어가며 생긴 변화를 떠올려보면, Container Machine은 macOS 개발 환경의 기본값을 바꿀 잠재력이 있습니다. 셋째, Containerization이 라이브러리로 공개되어 있으므로, 서드파티 도구들이 이를 백엔드로 채택하는 생태계 재편도 가능합니다. 실제로 기존 도구들이 백엔드 옵션으로 검토 중이라는 논의가 커뮤니티에서 오가고 있습니다.

당분간은 "빌드와 격리 실행은 apple/container, compose 스택은 기존 도구"라는 하이브리드가 현실적 최적해일 것입니다. 그러나 compose 공백이 메워지는 순간, 무게 중심은 빠르게 이동할 수 있습니다.

마치며

apple/container는 "macOS에서 컨테이너는 결국 VM"이라는 오래된 사실을 숨기는 대신, VM을 컨테이너만큼 가볍게 만들어 정면 돌파한 프로젝트입니다. 컨테이너당 경량 VM이라는 설계는 격리와 유휴 비용에서 단일 VM 모델을 능가하고, Rosetta와 OCI 호환성으로 실용성도 챙겼습니다. WWDC26의 Container Machine은 여기에 일상 개발 환경이라는 영역까지 더했습니다.

물론 compose 생태계와 리눅스 고급 기능이라는 숙제가 남아 있습니다. 지금 당장 전면 전환을 권하기는 어렵지만, 단일 컨테이너 워크플로와 신뢰할 수 없는 코드의 샌드박싱부터는 충분히 실전 투입이 가능합니다. 도커 데스크톱 갱신 시즌이 오기 전에 한 번 설치해서 container run을 실행해보시기 바랍니다. 커널이 부팅되는 1초의 경험이 생각보다 많은 것을 말해줍니다.

참고 자료

- apple/container GitHub 저장소: https://github.com/apple/container

- apple/containerization GitHub 저장소: https://github.com/apple/containerization

- GeekNews 관련 토픽: https://news.hada.io/topic?id=30346

- Apple Virtualization.framework 공식 문서: https://developer.apple.com/documentation/virtualization

- apple/container 공식 튜토리얼: https://github.com/apple/container/blob/main/docs/tutorial.md

- OCI Image Format Specification: https://github.com/opencontainers/image-spec

- OCI Distribution Specification: https://github.com/opencontainers/distribution-spec

- Hacker News의 apple/container 공개 토론: https://news.ycombinator.com/item?id=44229348

- Lima 프로젝트: https://github.com/lima-vm/lima

- Colima 프로젝트: https://github.com/abiosoft/colima

- Firecracker microVM (격리 모델 비교 참고): https://firecracker-microvm.github.io/