Apple Container ?, Mac에서 Docker 없이 컨테이너를 돌릴 수 있을까
조용히 시작된 프로젝트가 1.0을 찍었다
작년 WWDC 2025에서 애플이 'Container'라는 오픈소스 프로젝트를 슬쩍 공개했을 때, 솔직히 큰 기대는 안 했습니다. 당시 버전이 0.1.0이었고, 문서에도 "패치 버전에서만 안정성이 보장되며 마이너 버전에는 호환성을 깨는 변경이 포함될 수 있다"고 못 박아 둔 상태였거든요. 이런 문장이 붙어 있으면 보통 '아직 실험 단계니까 프로덕션에 쓸 생각 말라'는 뜻입니다.
그런데 1년이 지났습니다. 닷새 전인 2026년 6월 9일, apple/container가 드디어 1.0.0을 찍었습니다. GitHub 별 3만 개 이상, 포크 840개 이상, 기여자 91명. 숫자만 봐도 이게 그냥 사내 토이 프로젝트 수준이 아니라는 건 알 수 있습니다.
0.x에서 1.0으로 넘어가는 건 단순한 숫자 변화가 아닙니다. 버전 체계를 진지하게 쓰는 프로젝트에서 메이저 1은 "이제 API와 동작을 책임지겠다"는 선언이거든요. 호환성을 깨는 변경을 함부로 못 넣겠다는 약속이기도 하고요. 애플이 이 시점에 1.0을 붙였다는 건, 적어도 자기들 기준에서는 '쓸 만하다'고 판단했다는 신호입니다.
Container는 한 줄로 정리하면 애플이 직접 만든 macOS용 공식 컨테이너 도구입니다. Mac에서 Linux 컨테이너를 만들고 실행할 수 있고, Swift로 작성됐으며 Apple Silicon에 최적화돼 있습니다. 그리고 중요한 건 OCI 표준 이미지와 호환된다는 점입니다. 즉 Docker Hub에서 이미지를 그대로 끌어올 수 있고, 빌드한 이미지를 OCI 호환 레지스트리에 푸시할 수도 있습니다. 표준을 따랐다는 건 생태계와 단절되지 않겠다는 뜻이라, 이 선택은 꽤 영리합니다.
Docker Desktop과 구조적으로 무엇이 다른가
표면만 보면 'Mac에서 컨테이너 돌리는 또 하나의 도구'입니다. 하지만 안을 들여다보면 접근 방식 자체가 다릅니다. 여기가 핵심이라 좀 자세히 보겠습니다.
Docker Desktop의 방식은 이렇습니다. Mac 위에 큼직한 Linux 가상 머신을 하나 띄우고, 모든 컨테이너를 그 안에 몰아넣습니다. 컨테이너들이 하나의 커널을 공유하는 구조죠. macOS는 리눅스 컨테이너를 네이티브로 못 돌리니까, 어쩔 수 없이 중간에 리눅스 VM을 끼워 넣는 겁니다.
Container의 방식은 다릅니다. 컨테이너 하나하나가 각자의 경량 가상 머신 안에서 돕니다. 공유 커널이 아니라 컨테이너마다 독립된 VM을 갖는 구조입니다.
구조가 다르면 결과도 달라집니다. 정리하면 이렇습니다.
| 구분 | Docker Desktop | Apple Container |
|---|---|---|
| VM 구조 | 큰 VM 1개 공유 | 컨테이너마다 경량 VM |
| 커널 | 모든 컨테이너가 공유 | 컨테이너별 독립 |
| 격리 수준 | 컨테이너 수준 | VM 수준 |
| 데이터 노출 | 공유 VM에 저장 | 필요한 데이터만 마운트 |
| 작성 언어 | Go 등 | Swift |
이 구조에서 나오는 장점은 명확합니다.
첫째, 보안입니다. 각 컨테이너가 VM 수준으로 완전히 격리되니 공격 표면이 줄어듭니다. 한 컨테이너가 뚫려도 옆 컨테이너로 번지기 어렵다는 뜻이죠. 공유 커널 구조에서는 커널 취약점 하나가 전체에 영향을 주는데, 여기서는 그 고리가 끊깁니다.
둘째, 프라이버시입니다. 모든 데이터를 공유 VM에 쌓아두는 대신, 각 컨테이너에 필요한 데이터만 마운트합니다. 데이터가 한 곳에 모이지 않으니 노출 범위도 자연스럽게 줄어듭니다.
셋째, 리소스 유연성입니다. 'VM마다 하나씩이면 무겁지 않나?' 싶은데, 실제로는 전체 VM 하나보다 메모리를 덜 쓰면서도 시작 속도는 공유 VM 안의 컨테이너와 비슷합니다. 실제로 container run 명령으로 컨테이너를 띄워보면 몇 초밖에 안 걸리고, Docker와 체감 차이가 거의 없습니다. '격리를 강화했으니 느리겠지'라는 예상이 빗나가는 지점이라 인상적입니다.
여기서 짚고 넘어갈 부분. 컨테이너마다 VM을 띄우는 발상 자체는 새로운 게 아닙니다. Kata Containers 같은 프로젝트가 이미 비슷한 방향을 갔죠. 다만 애플은 그걸 macOS의 가상화 프레임워크 위에서 OS 차원으로 최적화했다는 점이 다릅니다. 같은 아이디어도 누가 어느 레이어에서 구현하느냐에 따라 완성도가 달라지는데, OS를 가진 회사가 직접 했다는 게 결정적입니다.
1.0의 진짜 무기, 컨테이너 머신
0.x 시절의 Container는 솔직히 'Docker의 기본 기능을 흉내 낸 대체재' 정도였습니다. 컨테이너 돌리고 이미지 빌드하는 건 되는데, 그것만으로는 굳이 갈아탈 이유가 없었죠. 그런데 1.0에서 도입된 컨테이너 머신(container machine) 기능이 이 도구에 독자적인 정체성을 만들어줬습니다.
컨테이너 머신을 한마디로 하면 영구적인 리눅스 환경입니다. 컨테이너처럼 가볍지만, 가상 머신처럼 상태를 유지합니다. 컨테이너의 휘발성과 VM의 지속성, 그 중간 지점에 자리를 잡은 거죠.
사용법은 직관적입니다.
# dev라는 이름의 머신 생성
container machine create dev
# 머신 시작
container machine start dev
# 풀 기능 리눅스 셸 실행
container machine exec dev bash
이거 어디서 본 것 같지 않나요? 네, WSL(Windows Subsystem for Linux) 과 결이 비슷합니다. Mac에서 장기간 쓸 수 있는 리눅스 개발 환경이라고 생각하면 됩니다. 프로그램을 닫았다 다시 열어도 설치했던 소프트웨어와 설정이 그대로 남아 있습니다.
이게 왜 의미가 있냐면, 그동안 Mac 사용자가 리눅스 개발 환경을 제대로 쓰려면 선택지가 애매했거든요. Docker 컨테이너는 휘발성이 강해서 '내 개발 머신'처럼 쓰기엔 불편하고, 풀 VM은 무겁고 관리가 번거롭습니다. 그 틈을 컨테이너 머신이 메웁니다. WSL이 윈도우 개발 경험을 바꿔놓은 걸 생각하면, 이 기능의 잠재력이 어느 정도인지 짐작이 갑니다.
WWDC 2026에서는 컨테이너 머신을 다루는 전용 세션 '컨테이너 머신 알아보기'도 따로 마련됐습니다. 애플이 이 기능을 단순한 부가 기능이 아니라 핵심 메시지로 밀고 있다는 방증이죠. 단순히 'Docker 대체'를 넘어 'Mac을 리눅스 개발 머신으로 쓰는 공식 방법'을 제시하려는 의도가 보입니다.
설치와 첫 실행, 생각보다 간단하다
써보고 싶다면 먼저 조건부터 확인해야 합니다. Apple Silicon Mac + macOS 26이 필수입니다. Intel Mac은 아예 지원하지 않고, 이전 macOS 버전에서도 안 돕니다. Container가 macOS 26의 새 가상화·네트워킹 기능을 적극적으로 끌어 쓰기 때문입니다. 이 의존성은 뒤에서 다시 얘기하겠지만, 양날의 검입니다.
설치 자체는 단순합니다.
- GitHub Releases로 가서 최신
pkg설치 파일을 받습니다 - 두 번 클릭해서 설치합니다
- 설치 후 시스템 서비스를 시작합니다
- 처음 실행하면 리눅스 커널을 설치하라는 메시지가 뜨는데, 계속 '예'를 선택하면 됩니다
그러고 나면 Docker 쓰던 것과 거의 똑같이 작업할 수 있습니다.
# 이미지 받아서 실행
container run -it --rm alpine:latest sh
# Dockerfile로 빌드
container build --tag my-app --file Dockerfile .
# 이미지 푸시
container image push registry.example.com/my-app:latest
# 실행 중인 컨테이너 보기
container ls
명령어 체계가 Docker와 굉장히 비슷합니다. 약어까지 지원하는데, container ls는 container list고 container rm은 container delete입니다. Docker를 만져본 사람이라면 학습 곡선이 사실상 제로에 가깝습니다.
이건 우연이 아니라 의도된 설계입니다. 새 도구를 보급할 때 가장 큰 장벽이 '익숙한 걸 버리고 새로 배워야 한다'는 부담인데, 명령어를 Docker와 맞춰버리면 그 장벽이 사라집니다. 사용자 입장에서 마이그레이션 비용을 거의 0으로 만들어 놓은 거죠. 표준(OCI)을 따른 것과 같은 맥락의 전략입니다. 호환성으로 진입 장벽을 낮추고, 구조적 차별점(VM 격리, 컨테이너 머신)으로 차별화한다는 그림입니다.
프로젝트에는 웹 서버 이미지를 처음부터 빌드해서 레지스트리에 푸시하는 과정을 단계별로 안내하는 시작 튜토리얼도 함께 제공됩니다. 처음 접하는 사람도 따라 하기 좋게 정리돼 있더라고요.
실무에서 챙겨볼 만한 디테일
명령어만 비슷한 게 아니라, 실무에서 쓸 때 손이 가는 기능들도 꽤 신경 써서 넣었습니다. 몇 가지만 짚어보겠습니다.
SSH 포워딩 — --ssh 옵션을 주면 macOS의 SSH 에이전트 소켓이 컨테이너에 자동으로 마운트됩니다. 볼륨을 수동으로 잡아줄 필요가 없고, 컨테이너를 재시작해도 연결이 유지됩니다. Docker에서 이거 설정하느라 고생해본 사람은 이 한 줄이 얼마나 편한지 압니다.
로컬 도메인 — 컨테이너에 my-web-server.test 같은 로컬 DNS 도메인을 붙일 수 있습니다. 브라우저에서 도메인으로 바로 접근하니까 IP 주소를 외울 필요가 없습니다. 여러 개 띄워놓고 작업할 때 특히 체감이 큽니다.
포트 포워딩 — Docker의 -p 옵션과 비슷하게 동작하고, IPv4와 IPv6 루프백을 모두 지원합니다.
크로스 아키텍처 빌드 — 단일 명령으로 arm64와 amd64를 모두 지원하는 이미지를 빌드할 수 있습니다.
container build --arch arm64 --arch amd64 --tag my-image .
Apple Silicon에서 작업하면서 amd64 서버용 이미지도 같이 뽑아야 하는 상황이 흔한데, 이걸 한 번에 처리해주니 워크플로가 단순해집니다.
리소스 제어 — Docker처럼 --cpus, --memory 제한을 걸 수 있습니다. 빌드할 때 빌더에 할당할 리소스 쿼터도 따로 설정 가능합니다. 로컬 머신 자원을 컨테이너가 다 잡아먹는 사고를 막을 수 있죠.
이런 디테일들을 보면 '일단 만들어 놓고 본' 게 아니라, 실제로 개발자가 어떻게 쓸지 고민한 흔적이 보입니다. OS의 네트워킹·인증 기능을 그대로 끌어다 쓸 수 있는 위치에 있으니, 외부 도구가 흉내 내기 어려운 매끄러움이 나옵니다.
그래서 Docker를 버려도 될까, 아직은 아니다
여기까지 보면 꽤 그럴듯해 보이지만, 냉정하게 말하면 1.0은 아직 Docker Desktop을 완전히 대체하지 못합니다. 빠진 부분이 분명히 있습니다.
첫째, docker-compose에 해당하는 기본 기능이 없습니다. 여러 컨테이너를 하나로 묶어 구성하려면 직접 방법을 만들어야 합니다. 실무에서 멀티 컨테이너 구성은 거의 기본인데, 이게 빠져 있다는 건 꽤 큰 공백입니다. 사실상 많은 개발 환경이 compose 기반으로 돌아가거든요.
둘째, 생태계가 아직 뒤처져 있습니다. 서드파티 도구와 CI/CD 통합이 Docker에 비하면 한참 덜 성숙했습니다. Docker는 십수 년간 쌓인 생태계가 있는데, 1년 된 프로젝트가 이걸 단번에 따라잡을 수는 없습니다.
셋째, macOS 26에 영구적으로 종속됩니다. Apple Silicon + macOS 26이 아니면 아예 못 씁니다. Intel Mac 사용자, 구버전 macOS 사용자는 통째로 배제됩니다. 가상화 프레임워크와 깊게 결합한 대가입니다. 이건 성능과 통합의 대가로 치른 비용인데, 환경이 안 맞으면 선택지에서 그냥 빠지는 셈이라 무시할 수 없는 제약입니다.
넷째, 아직 새롭습니다. 커뮤니티가 이제 막 움직이기 시작했고 플러그인 생태계도 형태를 갖춰가는 중입니다.
그런데 이걸 단점으로만 보긴 어렵습니다. 이 프로젝트는 이제 겨우 1년 됐거든요. Apache 2.0 라이선스 기반 오픈소스고, 애플 팀이 적극적으로 유지보수하고 있으며, 참여 장벽도 낮습니다. 문서에 버그 수정과 신규 기능 추가에 누구나 참여할 수 있다고 명시해 뒀습니다. 1년 만에 별 3만 개에 1.0까지 온 속도를 생각하면, 빠진 기능들이 채워지는 것도 시간문제일 가능성이 높습니다.
이 프로젝트가 의미하는 것
이 흐름을 조금 떨어져서 보면 시장 구도가 보입니다. Docker Desktop은 유료 모델로 전환하면서 한동안 논란을 겪었고, 그 빈틈을 Colima와 OrbStack 같은 도구들이 각자의 방식으로 메워왔습니다. 그런데 이번엔 OS를 가진 회사가 직접 이 영역에 들어왔습니다.
이게 결정적인 차이입니다. Colima나 OrbStack은 아무리 잘 만들어도 결국 macOS 위에 얹힌 서드파티입니다. 반면 Container의 핵심 Swift 패키지인 '컨테이너화(Containerization)'는 macOS의 가상화 프레임워크, vmnet 네트워킹, 키체인 자격 증명 관리, launchd 서비스 관리, 심지어 통합 로깅 시스템까지 OS 깊숙이 통합돼 있습니다. '기초부터 지붕까지 전부 자체적으로 쌓아 올린' 구조죠. 이런 수직 통합은 서드파티가 따라 하기 거의 불가능합니다. OS의 내부 API에 접근할 수 있는 회사만 만들 수 있는 물건입니다.
그래서 이건 단순히 도구 하나가 추가된 게 아닙니다. Mac에서 리눅스 컨테이너를 돌리는, 네이티브로 완전히 통합된 첫 번째 공식 솔루션이 등장했다는 의미입니다. 방향을 제시한 거죠.
물론 당장 내일 Docker를 갈아치울 도구는 아닙니다. compose도 없고 생태계도 어리니까요. 하지만 구조와 통합 수준, 그리고 애플이라는 주체를 함께 놓고 보면, 이게 장기적으로 어디로 갈지는 어렵지 않게 그려집니다. 지금은 작아 보여도 OS 차원의 통합은 시간이 갈수록 복리로 쌓입니다.
Apple Silicon Mac에서 macOS 26을 쓰고 있다면 한 번쯤 깔아볼 가치는 충분합니다. 적어도 누군가 "Mac에서 Docker 말고 컨테이너 돌릴 다른 방법 없나요?"라고 물었을 때, 이제는 다른 답을 내놓을 수 있게 됐으니까요.
도구는 결국 표준과 통합 둘 중 하나로 살아남습니다. Container는 OCI 표준을 따라 호환성을 챙기면서, OS 통합으로 차별점을 만들었습니다. 이 조합이 1년 뒤 어떤 그림을 그릴지, 다음 WWDC가 기다려지는 이유입니다.