Docker Desktop 없이 Mac에서 컨테이너 돌리기 — apple/container Container Machine 아키텍처

Mac 개발자에게 Docker Desktop은 오랫동안 필수 도구였지만 동시에 불만의 원천이었다. 무거운 메모리 점유, 직원 250명 초과 조직 기준 월 9달러/사용자의 라이선스 비용, 느린 파일 시스템 동기화, Apple Silicon 전환 이후의 ARM/x86 이중 지원 복잡성. Apple은 이 문제를 애플리케이션 레이어가 아니라 운영체제 레이어에서 풀기로 했다. 2025년 WWDC에서 공개한 apple/container가 2026년 6월 9일 v1.0.0에 도달하면서, Container Machine이라는 핵심 기능이 전면에 나섰다.

컨테이너마다 VM을 하나씩 배정한다는 선택

기존 macOS 컨테이너 도구들은 리눅스 VM 하나를 띄우고 그 안에서 여러 컨테이너가 커널을 공유하는 방식을 썼다. apple/container는 반대로 갔다 — 컨테이너 하나당 독립된 경량 VM을 배정하는 '1 VM per Container' 아키텍처다. 컨테이너 간 커널 공유가 없으니 공유 커널을 노리는 공격 표면 자체가 사라진다. 대신 VM을 띄우는 오버헤드가 붙는데, Apple Silicon의 하드웨어 가상화 확장을 직접 활용해 컨테이너 시작 시간을 1초 미만으로 눌러놨다.

이 결정을 가능하게 하는 것이 macOS에 내장된 Virtualization.framework다. 별도 하이퍼바이저 소프트웨어 없이 하드웨어 가상화 확장에 직접 접근해 경량 VM을 만들 수 있다.

⤢✕

아키텍처는 세 계층으로 나뉜다. apple/containerization Swift 패키지는 VZVirtualMachine, VZVirtioSocketDevice, VZFileSystemDevice 같은 Virtualization.framework API를 Swift 네이티브로 감싸 컨테이너 스펙을 프로그래밍 방식으로 정의할 수 있게 하는 저수준 라이브러리다. 그 위에서 VM 내부 첫 프로세스(PID 1)로 도는 것이 vminitd인데, Swift로 작성된 경량 init 시스템으로 vsock 기반 gRPC API를 통해 네트워크 인터페이스 IP 할당, 파일시스템 마운트, 프로세스 감독을 담당한다.

Container Machine이 노리는 건 프로세스가 아니라 환경

Container Machine은 프로세스 하나를 실행하고 끝나는 기존 컨테이너 모델과 다르다. 이미지의 init 시스템을 직접 실행해서 장기 실행 서비스를 등록하거나, 프로세스 슈퍼바이저 아래에서 애플리케이션을 테스트할 수 있는 지속성 있는 Linux 개발 환경을 목표로 한다.

macOS의 사용자 이름과 홈 디렉토리는 Linux 환경으로 자동 매핑되어, 레포지토리와 dotfile이 양쪽 플랫폼에서 동시에 쓰인다. macOS에서 에디터와 도구를 쓰는 동안 Linux 환경 내부에서 빌드·실행이 동시에 가능하고, systemd 같은 init 시스템을 통해 데이터베이스·웹 서버 같은 서비스를 상시 실행 상태로 유지할 수 있다.

v1.0.0에서 눈에 띄는 변화 하나는 설정 방식이다. 기존 UserProperty 기반 시스템 설정이 TOML 설정 파일로 대체됐고, container system property get/set 서브커맨드는 제거됐다. 시스템 전반의 동작을 TOML로 선언적으로 관리하는 쪽으로 방향을 잡은 것이다.

OCI 표준과 Rosetta 2로 푸는 아키텍처 호환성

apple/container는 OCI(Open Container Initiative) 표준 이미지를 완전히 지원해서 Docker Hub, GHCR, ECR 같은 표준 레지스트리에서 그대로 pull해 실행할 수 있다. ARM/x86 교차 실행은 macOS의 Rosetta 2가 맡는다. Apple Silicon Mac에서 linux/amd64 이미지를 실행하면 Rosetta 2가 VM 내부에서 x86_64 바이너리를 ARM으로 번역하고, 단일 명령으로 linux/arm64와 linux/amd64 양쪽을 지원하는 멀티아키텍처 이미지 빌드도 가능하다.

⤢✕

Docker Desktop·Colima·Lima와 나란히 놓고 보면

macOS 컨테이너 도구를 실용적 기준으로 비교하면 이렇다.

항목	apple/container	Docker Desktop	Colima	Lima
라이선스	오픈소스(Apache 2.0)	유료(기업 기준)	MIT	MIT
아키텍처	1 VM per Container	공유 단일 VM	공유 VM(QEMU/vz)	공유 VM
초기화 시간	1초 미만	10-20초	10-15초	15-20초
유휴 메모리	거의 0(중지 시)	500MB+	~500MB	~300MB
GUI	없음 (CLI 전용)	있음	없음	없음
Docker API 호환	제한적	완전 호환	완전 호환	부분
Kubernetes	미지원(v1.0)	지원	k3s	제한적
macOS 요구사항	macOS 26 이상	macOS 12 이상	macOS 12 이상	macOS 12 이상
ARM 네이티브 최적화	최적화	지원	부분 지원	부분 지원

Colima는 Lima 위에 구축된 경량 런타임으로, Docker CLI와 완전 호환되는 게 최대 강점이다. 기존 Docker Compose 워크플로우를 그대로 쓰면서 Docker Desktop의 유료 라이선스만 피하려는 팀에 맞다. apple/container는 반대로 Docker API 호환성보다 네이티브 macOS 통합과 보안 격리를 우선한다. Lima는 apple/container와 Colima 모두의 기반이 되는 하이퍼바이저 추상화 레이어로, 직접 쓰기보다 다른 도구의 백엔드로 쓰이는 경우가 많다. 비교군에서 OrbStack도 빼놓을 수 없다 — 빠른 시작과 낮은 리소스 사용량, 네이티브 macOS UI를 결합해 Apple Silicon Mac 개발자 사이에서 인기가 높고, 유료지만 개인 개발자에게는 무료 티어로 충분하다.

Docker Desktop을 지금 걷어내도 되는가

apple/container로 Docker Desktop을 완전히 대체할 수 있느냐는 질문에 v1.0.0 기준 답은 "워크로드에 따라 다르다"다.

교체가 성립하는 시나리오는 단순 리눅스 CLI 도구 실행이나 빌드 환경 격리, macOS와 Linux를 동시에 쓰는 개발 워크플로우(Container Machine 활용), ARM64 네이티브 컨테이너 중심 작업, 그리고 보안 격리가 중요한 환경(1 VM per Container)이다. 반대로 Docker Compose 기반 복잡한 멀티 컨테이너 앱, Kubernetes 로컬 개발 환경, Docker API에 의존하는 CI/CD 에이전트 체인, macOS 26 미만 환경에서는 여전히 Docker Desktop이나 Colima가 필요하다.

로컬과 CI 환경의 컨테이너 동작 불일치는 오래된 골칫거리인데, apple/container의 OCI 표준 준수와 ARM64 네이티브 실행이 이 문제를 부분적으로 줄여준다. GitHub Actions의 macos-latest 러너가 Apple Silicon으로 전환되면서, 로컬에서 apple/container로 테스트한 ARM64 이미지가 CI에서도 동일하게 동작하는 환경이 갖춰지고 있다.

가상화 스펙트럼에서의 위치와 보안 트레이드오프

apple/container는 전통적인 하이퍼바이저 기반 가상화(Type-1, Type-2)와 컨테이너(OS 레벨 가상화)의 중간 지점에 있다. 컨테이너의 경량성과 VM의 강한 격리를 결합한 Micro-VM 패턴으로, Kata Containers·Firecracker와 철학이 겹친다. 공유 커널 방식과 하이퍼바이저 격리 방식의 보안 트레이드오프는 컨테이너 보안을 논할 때 항상 따라붙는 주제인데, apple/container의 1 VM per Container 모델은 이 트레이드오프를 VM 오버헤드 쪽으로 밀어 넣고 격리를 강화한 사례다. OCI Image Spec, Runtime Spec, Distribution Spec을 알아두면 apple/container가 왜 Docker 이미지와 그대로 호환되는지, 컨테이너 표준화가 벤더 종속을 어떻게 막는지가 명확해진다.

2026년 로드맵

v1.0.0 출시는 API 안정화 선언이다. Apple이 밝힌 방향은 macOS 26의 가상화·네트워킹 개선 사항을 적극 반영하는 macOS 26 통합 심화, 장기 실행 서비스 관리와 퍼시스턴트 볼륨 처리를 다듬는 Container Machine 성숙화, apple/containerization 패키지를 통한 서드파티 통합 확대 세 가지다.

흥미로운 지점은 Apple이 이 프로젝트를 단순 개발 도구가 아니라 iOS/macOS 앱 개발 파이프라인과 통합될 수 있는 기반 기술로 포지셔닝하고 있다는 것이다. WWDC25 세션 "Meet Containerization"에서 Apple은 컨테이너를 앱 빌드·테스트·배포 자동화의 핵심 레이어로 제시했다. Docker Desktop의 대안이라는 프레임을 넘어, Apple Silicon 생태계 전반에서 재현 가능한 빌드 환경을 보장하는 플랫폼 레이어로 발전할 가능성이 있다.