Apple Container vs Docker — 맥에서 컨테이너를 다시 생각하다

들어가며 — Apple이 직접 컨테이너 도구를 냈다

apple/container가 6월 9일 1.0.0을 찍었다. GitHub 스타는 38,000개를 넘겼다(작성 시점 38,232). Apple이 직접, Swift로, Apple Silicon에 최적화해서 만든 “맥에서 리눅스 컨테이너를 돌리는 도구”다. 라이선스는 Apache-2.0, 완전 오픈소스다.

먼저 솔직하게 밝힌다. 나는 맥이 없다. 평소 윈도우에서 개발하고, 리눅스 컨테이너가 필요하면 Docker Desktop이나 WSL2를 쓴다. 그래서 이 글은 직접 벤치마크를 돌린 후기가 아니라, 공식 문서와 커뮤니티 반응을 근거로 한 아키텍처 비교다. “써 봤더니 빠르더라” 같은 체감담은 못 적는다. 대신 “왜 구조가 다른가, 그 구조가 무엇을 사고 무엇을 포기하는가”를 정리한다.

결론부터 말하면 — Apple Silicon 맥을 쓴다면 한 번 깔아 볼 만하다. 다만 Docker를 당장 버릴 도구는 아니다. 왜 그런지 보자.

Apple Container가 뭔가

한 줄 정의는 이렇다.

맥에서 리눅스 컨테이너를, 컨테이너마다 경량 VM(lightweight VM)을 띄워서 실행하는 CLI 도구.

핵심 사실부터 못 박는다.

OCI 호환이라는 점이 중요하다. 즉 이미지 포맷이 Docker와 같다. docker pull로 받던 이미지를 그대로 받아 돌릴 수 있다. 새 이미지 생태계를 만든 게 아니라, 실행 방식만 다르게 가져간 것이다.

핵심 차이는 “VM을 몇 개 띄우느냐”

맥에는 리눅스 커널이 없다. 그래서 맥에서 리눅스 컨테이너를 돌리려면 어딘가에 리눅스 커널이 있어야 한다. Docker와 Apple Container는 바로 이 지점에서 갈린다.

Docker Desktop (맥) 은 리눅스 VM을 하나 띄운다. 그 안에 리눅스 커널이 돌고, 우리가 만드는 컨테이너는 전부 그 한 VM 안에서 커널을 공유한다.

[ Docker Desktop on macOS ]

  macOS
   └── LinuxKit VM (단 하나)
        ├── 리눅스 커널 (공유)
        ├── container A
        ├── container B
        └── container C

Apple Container 는 반대다. 컨테이너 하나당 경량 VM을 하나씩 띄운다.

[ Apple Container on macOS ]

  macOS
   ├── VM ── 커널 ── container A
   ├── VM ── 커널 ── container B
   └── VM ── 커널 ── container C

이 한 줄짜리 차이가 장단점을 전부 만든다.

• 격리(isolation): Apple Container에서는 컨테이너 하나하나가 “완전한 VM 수준의 격리”를 갖는다. 커널을 공유하지 않으니, 한 컨테이너에서 커널 익스플로잇이 터져도 다른 컨테이너로 번지지 않는다. Docker의 네임스페이스/cgroup 격리보다 경계가 두껍다.
• 네트워크: vmnet 프레임워크를 통해 컨테이너마다 자기 IP를 받는다(macOS 26 기준). macOS 15에서는 컨테이너끼리 서로 격리돼 통신이 제한된다.
• 프라이버시: 컨테이너마다 필요한 데이터만 마운트한다.

정리하면 Apple Container의 설계 철학은 “컨테이너를 가벼운 VM처럼 다룬다”이다. Docker가 “VM 하나 안에서 프로세스를 격리한다”였다면, Apple은 한 단계 더 들어가 컨테이너 자체를 VM 경계로 감쌌다.

한눈에 보는 비교표

표에서 색이 가장 분명하게 갈리는 칸은 플랫폼과 생태계 성숙도다. 여기서 두 도구의 용도가 나뉜다.

Apple Container의 장점

① 보안 격리가 한 단계 강하다. 컨테이너마다 VM 경계가 있으니, 신뢰할 수 없는 코드를 돌리거나 멀티테넌트 환경을 흉내 낼 때 안심된다. Docker로 같은 수준을 내려면 gVisor나 Kata Containers 같은 별도 런타임을 얹어야 한다. Apple Container는 그게 기본값이다.

② 맥에 네이티브하다. Apple Silicon과 Virtualization.framework에 맞춰 Swift로 짰다. 외부 가상화 계층을 거치지 않고 OS 기능을 직접 쓴다. 이론적으로 같은 하드웨어에서 오버헤드가 적게 설계돼 있다(직접 측정은 못 했다, 어디까지나 설계 근거다).

③ 완전 오픈소스에 무료다. Apache-2.0이다. Docker Desktop은 일정 규모 이상 기업에서 유료 구독이 필요하다. Apple Container는 그런 라이선스 부담이 없다. 기반인 Containerization 패키지도 따로 공개돼 있어, 자기 도구에 컨테이너 실행 기능을 박아 넣을 수도 있다.

④ 표준 이미지를 그대로 쓴다. OCI 호환이라 Docker Hub 이미지를 그대로 pull 한다. 새 레지스트리를 배울 필요가 없다. docker build로 만든 이미지가 그대로 돌아간다.

내가 의심하는 지점 / 한계

여기가 이 글의 핵심이다. 스타 38,000개에 Apple 이름값이 붙어도, 냉정하게 보면 약점이 뚜렷하다.

① macOS 26 이상 + Apple Silicon 전용이다. 이게 가장 큰 벽이다. Intel 맥은 아예 안 된다. macOS 15에서는 컨테이너 간 네트워크가 막히는 등 반쪽이다. 유지보수자들이 “macOS 26 미만에서 재현되는 이슈는 보통 다루지 않는다”고 못 박았을 정도다. 팀원 중 한 명이라도 Intel 맥이거나 OS가 낮으면 공통 도구로 못 쓴다.

② 메모리를 호스트에 잘 돌려주지 않는다. 문서가 직접 인정하는 한계다 — 컨테이너 안에서 해제된 메모리 페이지가 호스트로 반환되지 않는다(memory ballooning이 부분적으로만 지원). 컨테이너마다 VM이 뜨는 구조상, 여러 개를 띄우면 메모리 압박이 누적될 수 있다. 커뮤니티에서도 기본 CPU/RAM 할당이 너무 보수적이라는 지적, 호스트 볼륨 마운트 시 파일 I/O 성능 저하 얘기가 나온다.

③ 생태계가 이제 막 1.0이다. Docker는 10년 넘게 쌓인 Compose, BuildKit, 레지스트리 도구, CI 인티그레이션, 수많은 튜토리얼과 Stack Overflow 답변을 가지고 있다. Apple Container는 그 대부분이 아직 없거나 미성숙하다. docker-compose.yml 하나로 멀티 서비스를 띄우던 경험을 그대로 옮기긴 어렵다.

④ GUI가 없다. CLI 전용이다. Docker Desktop의 대시보드로 컨테이너·로그·볼륨을 눈으로 보던 사람에겐 진입 장벽이다.

⑤ Mac 밖으로 안 나간다. 가장 본질적인 제약이다. 컨테이너의 매력 절반은 “내 노트북에서 돌던 게 CI에서도, 리눅스 서버에서도 똑같이 돈다”는 이식성이다. Apple Container는 맥 전용이라, 빌드·배포 파이프라인은 결국 Docker(또는 OCI 표준 런타임)로 가야 한다. 즉 개발 단계 일부를 대체할 순 있어도, 컨테이너 워크플로 전체를 대체하진 못한다.

그리고 잊지 말 것 — 같은 자리를 노리는 도구가 이미 있다. Lima/Colima, OrbStack 같은 맥용 컨테이너/VM 도구다. OrbStack 개발자는 Apple의 접근이 동적 메모리·완전한 systemd 통합 면에서 아직 부족하다고 짚기도 했다. “Apple이 만들었으니까”가 곧 “제일 낫다”는 아니다.

그럼 Docker는 왜 여전히 기본인가

Docker의 강점은 정확히 Apple Container의 약점이다.

• 어디서나 돈다. 맥·윈도우·리눅스, 그리고 거의 모든 CI/CD와 클라우드가 Docker(OCI) 기반이다. 한 번 배우면 모든 환경에서 통한다.
• 생태계가 압도적이다. Compose로 멀티 서비스, BuildKit으로 빌드 캐시, Swarm/Kubernetes로 오케스트레이션. 막히면 검색 한 번에 답이 나온다.
• 팀 표준으로 안전하다. 신입이 와도 docker compose up 한 줄이면 환경이 뜬다. 도구가 사람을 가리지 않는다.

윈도우 개발자인 내 입장에서 이 비교는 묘하게 익숙하다. Apple Container ↔ Docker 관계는, WSL2 ↔ Docker Desktop 관계와 결이 비슷하다. OS 벤더가 “리눅스를 1급으로 품겠다”고 네이티브 통합을 내놓는 흐름이다. 실제로 Apple은 한발 더 나아가, 홈 디렉터리를 자동 마운트하고 systemd까지 띄우는 영속 리눅스 VM(“Container Machine”) 기능도 함께 밀고 있다 — WSL2의 맥 버전에 가깝다. 결국 Apple도 Microsoft도 “맥/윈도우 위에서 리눅스로 개발한다”를 공식 지원하는 방향으로 가고 있다.

언제 써볼 만한가

직접 못 써 봤으니 단정은 피하고, 조건으로 정리한다.

Apple Container를 깔아 볼 만한 경우

• macOS 26 이상 + Apple Silicon 맥을 쓴다.
• 신뢰할 수 없는 코드를 돌려야 해서 VM 수준 격리가 필요하다.
• Docker Desktop 라이선스 비용이나 백그라운드 무게가 부담스럽다.
• 로컬에서 이미지 하나를 빠르게 띄워 보는, 가벼운 개발/실험 용도.

그래도 Docker를 유지해야 하는 경우

• 팀에 Intel 맥·윈도우·리눅스 사용자가 섞여 있다.
• docker-compose로 묶인 멀티 서비스 스택을 돌린다.
• CI/CD와 프로덕션 배포까지 같은 이미지로 가야 한다(거의 모든 실무).
• GUI 대시보드나 풍부한 튜토리얼에 의존한다.

현실적인 결론은 “둘 중 하나”가 아니라 “역할 분담”이다. 이미지가 OCI 표준으로 호환되니, 로컬 개발은 Apple Container로 가볍게 가고 빌드·배포는 기존 Docker/OCI 파이프라인을 그대로 쓰는 조합이 가능하다. 어차피 이미지는 같으니까.

마치며

Apple Container는 “Docker를 죽이러 온 도구”라기보다, 맥이라는 특정 환경에서 컨테이너를 더 맥답게 돌리는 방법에 가깝다. 컨테이너마다 VM을 띄우는 선택은 보안 격리를 사고 호스트 호환성과 생태계를 포기한 트레이드오프다. 그 거래가 이득인지는 결국 환경에 달렸다.

맥이 없는 나는 직접 체감하진 못했지만, Apple Silicon 맥을 쓰는 사람이라면 1.0이 나온 지금 한 번 깔아 보고 손맛을 비교해 볼 가치는 충분하다. 그리고 후기가 궁금하다 — 맥 쓰는 분들, 실제로 Docker보다 가벼운지 알려주면 좋겠다.

Apple Container는 컨테이너마다 VM을 띄워 격리를 사고 이식성을 내준 도구다 — Apple Silicon 맥이라면 시도해 볼 만하지만, 컨테이너 워크플로 전체를 대체하진 못한다.