2024년 말, Apple이 이례적인 일을 했다. 키노트도, 보도자료도, Apple 플랫폼 기능에 통상적으로 수반되는 어떤 팡파르도 없이, macOS에 네이티브 Linux 컨테이너 지원을 출시한 것이다. 프로젝트는 "container"라는 이름으로 GitHub에 오픈소스로 공개되었다 — 소문자, 브랜딩 없음, 마케팅 없음. Apple Silicon에서 거의 네이티브 성능으로 OCI 호환 Linux 컨테이너를 실행하는 Swift 바이너리일 뿐이다.
대부분의 개발자는 눈치채지 못했다. Docker Desktop이 여전히 macOS 컨테이너 시장을 지배하고 있었고, 눈치챈 소수도 외부로 유출된 내부 도구라고 생각했다. 하지만 macOS에서 가볍고 안전한 격리가 필요한 소프트웨어를 만드는 사람에게 Apple Container는 조용히 혁명적이었다 — 그리고 NanoClaw는 이를 기반으로 구축한 최초의 프로젝트 중 하나였다.
Docker가 충분하지 않았던 이유
Apple Container가 AI 에이전트에 왜 중요한지 이해하려면, Docker가 macOS에서 실제로 무엇을 하는지 알아야 한다. Docker Desktop은 컨테이너를 네이티브로 실행하지 않는다 — Linux 가상 머신을 실행하고, 그 VM 안에서 컨테이너를 실행한다. Mac의 모든 Docker 컨테이너는 실제로 Docker Desktop이 관리하는 숨겨진 Linux VM 안에서 실행된다. 작동은 하지만 오버헤드가 따른다: VM에 RAM이 필요하고(기본 2-4GB), 모든 컨테이너 작업에 지연이 추가되며, Docker Desktop이 백그라운드 서비스로 실행되어야 한다.
가끔 Postgres 컨테이너를 띄우는 웹 개발자에게 이 오버헤드는 보이지 않는다. 모든 대화 턴마다 새 컨테이너를 생성하고 응답이 완료되면 해체하는 NanoClaw에게는 이 오버헤드가 병목이다. VM 오버헤드로 시작에 2초 걸리는 컨테이너는 민첩한 AI 어시스턴트를 느릿한 것으로 만든다. WhatsApp 메시지가 3초 더 걸리면 사용자는 알아챈다.
Apple Container는 VM 계층을 완전히 제거한다. Apple의 Virtualization.framework를 사용하여 하드웨어에서 직접 경량 Linux 커널을 실행하며, 컨테이너들이 각자 VM을 실행하는 대신 그 커널을 공유한다. 결과는 초 단위가 아닌 밀리초 단위의 컨테이너 시작 시간, 기가바이트가 아닌 메가바이트 단위의 메모리 오버헤드, 네이티브에 가까운 I/O 성능이다.
NanoClaw가 사용하는 방법
NanoClaw의 컨테이너 모델은 단순하지만 의도적이다. WhatsApp에 메시지가 도착하면, NanoClaw는 특정 마운트 세트를 가진 컨테이너를 생성한다: 프로젝트 소스 코드(읽기 전용), 그룹의 CLAUDE.md 메모리 파일(읽기-쓰기), 해당 그룹에 범위가 지정된 쓰기 가능 작업 공간. API 키는 JSON 페이로드로 stdin을 통해 전달된다 — 컨테이너 내부의 파일시스템이나 환경 변수에 절대 닿지 않는다.
macOS에서 NanoClaw는 Apple Container를 감지하고 기본으로 사용한다. Linux에서는 Docker로 폴백한다. 컨테이너 안의 에이전트 코드는 어느 쪽이든 동일하다 — 호스트 OS와 관계없이 Linux 환경에서 실행되는 Agent SDK를 사용한 Claude Code 세션이다. 컨테이너 이미지에는 웹 접근을 위한 Chromium과 agent-browser가 포함되어, 호스트에서 브라우저를 실행하지 않고도 에이전트가 웹을 검색하고 페이지를 탐색할 수 있다.
macOS에서의 실질적인 차이는 속도다. Apple Container의 컨테이너 생성 시간은 대략 200-400ms — 사용자가 일반적인 AI 응답 시간 외에 지연을 느끼지 못할 만큼 빠르다. Docker Desktop으로는 같은 작업이 1.5-3초 걸리며, 이는 체감된다. 하루에 수십 개의 메시지에 걸쳐 그 차이는 의미 있게 다른 사용자 경험으로 누적된다.
보안 모델
Apple Container는 Docker Desktop이 할 수 없는 방식으로 macOS의 보안 프리미티브를 상속한다. 컨테이너는 Apple의 샌드박스 프레임워크 하에서 실행되며, 이는 다른 샌드박스된 macOS 애플리케이션과 동일한 보안 정책의 적용을 받는다는 뜻이다. 명시적으로 마운트된 경로 외부의 파일 접근은 컨테이너 런타임이 아닌 운영체제 자체에 의해 거부된다.
이것이 AI 에이전트에 특히 중요한 이유는 프롬프트 인젝션 때문이다. 악성 프롬프트가 에이전트를 속여 ~/.ssh/id_rsa나 ~/Documents/tax-returns.pdf를 읽으려 하면, 시도는 애플리케이션 수준이 아닌 OS 수준에서 실패한다. NanoClaw의 마운트 검증 코드에 제한을 우회할 수 있는 버그가 있을 수 없다 — 제한이 NanoClaw가 아닌 macOS 커널에 의해 시행되기 때문이다.
네트워크 격리도 마찬가지로 중요하다. 각 컨테이너는 자체 네트워크 네임스페이스를 가지며, 이는 에이전트가 로컬 네트워크를 스캔하거나, localhost에서 실행 중인 다른 서비스에 접근하거나, 다른 에이전트 컨테이너와 통신할 수 없다는 뜻이다. 유일한 네트워크 접근은 AI 제공업체와 에이전트가 탐색하는 웹사이트로의 아웃바운드 HTTPS다. 이는 손상된 에이전트가 같은 머신의 다른 서비스로 피벗하려는 공격 유형에 대한 의미 있는 방어다.
Mac 사용자에게 의미하는 것
Mac에서 NanoClaw를 실행한다면 — 개인 용도로 가장 흔한 배포 방식 — Apple Container는 Docker Desktop 없이 Docker 수준의 격리를 제공한다. 2-4GB RAM을 먹는 백그라운드 VM도 없다. 관리할 Docker Desktop 라이선스도 없다. NanoClaw가 시작되기 전에 실행되어야 하는 Docker 데몬도 없다.
설정은 최소한이다. NanoClaw의 부트스트랩 스크립트가 macOS를 감지하고, Apple Container를 확인하고, 자동으로 설정한다. Apple Container가 설치되어 있지 않으면 Docker로 폴백한다. 둘 다 없으면 컨테이너 격리 없이 실행된다(경고와 함께). 목표는 컨테이너 격리가 추가 설정이 필요한 옵트인 기능이 아닌 기본값이 되는 것이다.
macOS와 Linux 머신이 혼합된 환경에서 NanoClaw 배포를 평가하는 팀에게, 컨테이너 추상화는 같은 설정이 어디서나 작동한다는 뜻이다. Apple Container든 Docker든 격리를 제공하는 것과 관계없이 에이전트 동작은 동일하다. 유일한 차이는 성능이며 — 그 지표에서 Apple Silicon의 Apple Container는 따라잡기 어렵다.
Apple이 AI 에이전트를 위해 Container를 만든 건 아니다. 자체 내부 도구와 macOS에서 경량 Linux 환경이 필요한 개발자를 위해 만들었다. 하지만 그 용도에 좋은 속성들 — 빠른 시작, 낮은 오버헤드, 강력한 격리, 네이티브 성능 — 이 정확히 AI 에이전트 샌드박싱에 필요한 속성이다. 때로는 어떤 일에 가장 좋은 도구가 완전히 다른 일을 위해 만들어진 도구일 때가 있다.