Apple의 새로운 컨테이너 시스템을 Docker와 비교하면, 마치 고장 난 것처럼 보입니다. 각 인스턴스는 유용한 작업을 수행하기도 전에 270400MB의 RAM을 소모합니다. 시작 속도는 Linux 컨테이너보다 410배 느립니다. 여러 컨테이너 간에 볼륨을 공유하려고 하면 한계에 부딪힙니다. 하나의 어태치먼트에는 하나의 박스만 허용됩니다. 더 가벼운 마이크로서비스 실행 방식을 찾는 사람들에게 이 수치들은 결정적인 결함처럼 느껴질 것입니다.
하지만 Apple은 여러분의 개발 스택을 대체하려는 것이 아닙니다. 신뢰할 수 없는 코드를 위한 감옥을 만들고 있는 것입니다.
이러한 관점의 전환은 모든 불만을 의도적인 트레이드오프(trade-off)로 바꿉니다.
잘못된 벤치마크
지난 10년 동안 업계는 밀도를 높이기 위해 컨테이너를 압축하는 데 집중해 왔습니다. 우리는 수십 개의 앱이 단일 커널 위에서 실행되며, 메모리 페이지를 공유하고, 동일한 볼륨을 마운트하며, 밀리초 단위로 부팅되기를 원했습니다. Docker는 이 문제를 훌륭하게 해결했습니다. 핵심은 소프트웨어와 하드웨어 사이의 추상화 계층을 최대한 얇게 만드는 것이었습니다.
Apple의 설계는 정반대입니다. 분리를 위해 밀도를 희생합니다. 공유 자원을 엄격한 벽과 맞바꿉니다. Kubernetes 클러스터용 인프라로 본다면 이 계산은 터무니없습니다. 모든 컨테이너가 0.25GB의 오버헤드와 자체 커널을 갖는 노드 군단을 구축하는 일은 결코 없을 것입니다. 경제성이 전혀 맞지 않기 때문입니다.
여러분이 방금 노트북에 초대하기 시작한 AI 에이전트가 아니라면 말이죠.
변화된 테넌트
2026년, 여러분의 기기에서 실행되는 가장 위험한 코드는 오염된 npm 패키지나 수상한 브라우저 확장 프로그램이 아닙니다. 바로 자율 코딩 에이전트입니다. 이러한 도구들은 코드베이스를 읽고, 함수를 재작성하며, 셸 명령을 실행하고, 외부 API를 호출합니다. 이들은 SSH 키, 환경 설정 파일, 브라우저 쿠키가 저장된 동일한 디렉토리 트리 내부에서 분당 수천 번의 결정을 내립니다.
전통적인 권한 모델은 이러한 속도 앞에서 무너집니다. 사람이 모든 파일 읽기, 모든 서브프로세스 생성, 모든 네트워크 요청을 승인할 수는 없습니다. 그런 승인 절차는 5분이면 끝날 리팩토링 작업을 한 시간 동안의 감시 작업으로 바꿔버립니다. 그렇다고 에이전트에게 홈 디렉토리에 대한 포괄적인 접근 권한을 주는 것은 노트북을 낯선 사람에게 건네주는 것만큼이나 안전하지 않습니다.
유일하게 합리적인 시작점은 에이전트를 기본적으로 적대적인 존재로 간주하고, 막연한 기대보다는 구조를 통해 안전성을 증명하는 것입니다.
Apple의 컨테이너 시스템은 정확히 그러한 사고방식을 위해 설계되었습니다.
격리가 목적이 될 때
각 Apple 컨테이너는 자체 커널을 가진 경량 VM 내부에서 실행됩니다. Docker의 세계에서 이는 이단과도 같습니다. 메모리 중복 제거(deduplication) 기능을 잃게 됩니다. 공유 커널의 속도를 잃게 됩니다. 단일 호스트에 수백 개의 워크로드를 채워 넣는 능력을 잃게 됩니다.
하지만 신뢰할 수 없는 에이전트 하나에게는 프라이빗 커널이 요새와 같습니다. 에이전트가 사용자 공간(user space)을 탈출하더라도, 호스트 커널이 아닌 경계에 부딪히게 됩니다. 이것은 낭비가 아닙니다. 그것이 바로 여러분이 그 추가적인 메가바이트를 지불하며 얻는 기능입니다.
Apple은 mcpbridge를 통해 이 경계를 확장합니다. 많은 코딩 에이전트들이 Model Context Protocol(MCP)을 사용하여 도구와 통신합니다. Apple은 이러한 명령을 가로채서 macOS와 iOS 전반에서 세밀한 권한을 강제하는 동일한 프로세스 간 프레임워크인 XPC로 변환합니다. 에이전트는 단순히 파일 시스템이나 네트워크를 건드릴 수 없습니다. 모든 도구 호출은 반드시 Apple의 엄격한 권한 모델을 먼저 통과해야 합니다.
그리고 컴퓨팅의 분리가 있습니다. 무거운 AI 모델 자체는 호스트 Mac의 Neural Engine에서 실행됩니다. 컨테이너는 모델 가중치나 추론 엔진을 위해 RAM을 낭비하지 않습니다. 컨테이너는 에이전트의 도구와 임시 작업 공간(scratch space)만을 수용합니다. 비용이 많이 드는 작업은 하드웨어가 가장 강력한 곳에서 이루어지고, 위험한 작업은 케이지(cage) 안에서 이루어집니다.
이 아키텍처는 Apple의 Private Cloud Compute 이니셔티브 뒤에 숨겨진 철학을 반영합니다. 사용자에게 맹목적인 신뢰를 요구하지 마십시오. 시스템 자체의 구조를 통해 경계를 증명하십시오.