日本語版 (Japanese version): Apple containerの不可解な設計、実は"AIエージェント用の箱"を作ってるだけ説

계속해서 벤치마크에서 뒤처지는 디자인

제가 Apple의 container 런타임(runtime)을 측정했을 때, 솔직한 수치는 처참했습니다. 모든 컨테이너는 약 270–400 MB의 자체 VM(Virtual Machine)을 할당받고, 일회성 컨테이너는 Docker보다 4–10배 더 느리게 시작되며, 이름이 지정된 볼륨(named volume)은 한 번에 하나의 실행 중인 컨테이너에만 연결할 수 있습니다. Docker Compose의 대체재로 판단한다면, Apple이 의도적으로 패배할 수밖에 없는 디자인을 선택한 것처럼 보입니다.

그리고 그것이 수수께끼입니다. Apple은 Docker Desktop의 공유 VM(shared-VM) 모델이 밀도(density) 측면에서 어떻게 승리하는지 분명히 알고 있습니다. 그 디자인은 10년 동안 최적화되어 왔습니다. 그들은 그것을 살펴보고도 그냥 지나쳤습니다. 왜일까요?

이 포스트에서 탐구할 가설은 다음과 같습니다: Apple은 여러분의 개발 스택을 위한 상자를 만들고 있는 것이 아닙니다. Apple은 여러분이 신뢰하지 않는 코드를 위한 상자를 만들고 있습니다. 그리고 2026년, 가장 중요한 신뢰할 수 없는 코드는 바로 AI 코딩 에이전트(AI coding agent)입니다. 그 관점으로 디자인을 바라보면 모든 "결함"이 하나의 결정처럼 보이기 시작합니다.

이 글은 해석에 기반한 글이지만, 아래의 모든 주장은 제 컴퓨터에서 측정되었거나 공개적으로 출시된 데이터에 근거하고 있습니다. 마지막에는 이 전체 해석을 거짓으로 증명할 수 있는 예측들을 나열하겠습니다.

증거 1: 부품 목록이 수상하다

지난 1년 동안 Apple이 출시한 것들을 기능이 아닌 부품으로서 나열해 보겠습니다.

VM별 격리(Per-VM isolation). 각 컨테이너는 자체 커널을 가진 경량 VM(Virtual Machine)을 할당받습니다. "저렴하게 많은 컨테이너를 실행하기"에는 최악의 선택이지만, "하나의 신뢰할 수 없는 대상을 강력하게 격리하기"에는 최선의 선택입니다.

대조를 위해 살펴보자면: Microsoft는 바로 같은 달에 정반대의 길을 택했습니다. WSL 컨테이너 (퍼블릭 프리뷰, 2026년 6월)는 네임스페이스 격리 (namespace isolation)를 갖춘 하나의 공유 유틸리티 VM에서 실행됩니다. 이는 Docker가 위치한

모델은 호스트에, 도구는 박스 안에. Apple container는 GPU/ANE 패스스루 (passthrough)를 지원하지 않습니다. 추론 (Inference)은 애초에 컨테이너 내부에서 실행되도록 설계되지 않았습니다. 파운데이션 모델 (Foundation Models)은 Neural Engine에서 호스트 측에서 실행되며, 컨테이너는 도구들을 보유합니다.

컨테이너 머신 (Container machines). WWDC26은 또한 지속적인 Linux VM을 선보였습니다. 이는 container run의 일회성 VM에 대응하는 장기 실행 (long-lived) 모델입니다.

도처에 경계와 게이트가 존재합니다. 이는 "Docker 대체재"라고 하기에는 너무 많은 구성 요소입니다.

전시물 2: 이것이 Apple이 항상 안전을 다뤄온 방식입니다

여기에는 계보가 있습니다. Private Cloud Compute의 설계 원칙은 "운영자를 신뢰하지 마라 — 구조적으로 증명하라"였습니다. iOS 샌드박스 (sandbox)도 같은 형태를 띱니다. 앱은 샌드박스 내부에서 자유롭게 실행되지만, 연락처, 카메라, 위치와 같은 경계를 넘을 때만 체크포인트 (checkpoint)에 도달합니다. 이 체크포인트는 권한 확인 (entitlement check)이거나 여러분이 수천 번은 눌렀을 그 권한 승인 대화상자입니다. 이를 게이트 (gate)라고 부릅시다.

경계 내부에서는 자유로움 → 교차 지점에서 하나의 게이트

이제 이를 오늘날의 코딩 에이전트 (coding agents)가 안전을 유지하는 방식과 비교해 보십시오. 모든 동작에 대한 승인 프롬프트, 각 단계마다 개입하는 인간 (human in the loop). Apple의 패턴은 그 반대입니다. 내부에서는 완전한 자유를, 가장자리에서는 하나의 게이트를 둡니다. VM 단위의 컨테이너가 경계이며, mcpbridge + ACP가 게이트입니다. 구성 요소들이 철학과 일치합니다.

에이전트에게 있어 이 차이는 근본적입니다. 동작마다 승인을 받는 것은 인간의 주의력을 지속적으로 소모합니다. 경계 모델 (boundary model)은 --dangerously-skip-permissions를 구조적으로 정당화합니다. 무슨 일이 일어나든, 그것은 박스 안에서 일어나는 일이기 때문입니다. 에이전트의 전체 가치는 자율적이고 지속적인 운영에 있으므로, 저는 에이전트 플랫폼들이 경계 모델로 수렴할 것이라고 확신합니다. 이 확신이 이 글의 핵심입니다.

전시물 3: 여러분은 이미 compose 파일로 박스를 구축할 수 있습니다

제가 가장 공유하고 싶은 관찰 내용이 있습니다. 오늘날 Mac에서 경계 모델(boundary model)을 실행하려면 에이전트가 무엇을 얻는지 선언할 수 있는 방법이 필요합니다. iOS는 이를 위해 엔타이틀먼트(entitlements)를 가지고 있습니다. 그런데 컨테이너 세계에는 이미 이에 대한 어휘, 즉 compose 파일이 존재한다는 것입니다:

• volumes: (바인드 마운트): 에이전트가 볼 수 있는 파일들
• environment: + .env: 에이전트가 보유하는 비밀 정보(secrets)
• ports: / 호스트 게이트웨이: 호스트로의 접근 범위
• networks: / network_mode:: 얼마나 멀리 외부와 연결되는지

저는 이것을 이론으로만 남기고 싶지 않아 직접 구현해 보았습니다. (Apple의 container는 자체적으로 compose 파일을 읽지는 못합니다. 저는 제가 작업 중인, compose와 호환되는 오케스트레이터인 opossum을 번역기로 사용했습니다. 하지만 여기서 핵심은 도구가 아니라 compose라는 어휘력입니다.)

name: agent-sandbox

services:
...

다르게 읽으면, 이 파일은 역량 명세서(capability manifest)가 됩니다. 이 에이전트는 ./work만 보고, 다른 것은 아무것도 보지 못하며, 이 토큰 하나를 보유하고, 4GB의 메모리를 얻습니다. 새로운 장치가 필요한 것이 아닙니다. 10년 된 compose 어휘력을 다시 읽어내는 것일 뿐입니다.

실제로 작동할까요? 제 컴퓨터(macOS 26, container 1.1.0)에서: 저는 가상 머신(in-VM)의 Claude Code에게 한 줄만 지시했습니다.

세 번째 행이 우리가 알아야 할 핵심입니다. 내부 네트워크(internal network)에서는 인터넷 경로가 물리적으로 사라지므로, 유일한 탈출구는 호스트에서 실행 중인 프록시(proxy)뿐입니다. http_proxy를 무시하고 직접 연결을 시도하는 에이전트는 아무런 데이터도 받지 못하게 됩니다. 허용 목록(allowlist)은 권고 사항이 아니라 _강제(enforced)_됩니다. (참고로, 게스트 내부의 iptables 허용 목록 방식은 제 테스트에서 작동하지 않았습니다. 허용된 목적지까지 차단되었습니다. 프록시 방식이 올바른 접근법입니다.)

"왜 그냥 Docker Sandbox를 사용하지 않나요?"

타당한 질문입니다. 저 역시 스스로에게 던졌던 질문이기에, 직접 성능을 테스트해 보았습니다 (Docker Desktop 4.78, docker sandbox v0.12):

docker sandbox create shell .        # 현재 디렉토리를 작업 공간(workspace)으로 하는 박스 생성
docker sandbox exec <box> uname -a   # → Linux ... 6.12.67-linuxkit aarch64

테스트 결과는 다음과 같습니다:

• 실제 마이크로VM(microVM)입니다: 에이전트당 하나씩 할당되는 linuxkit-커널 기반의 Linux이며, 이는 Apple의 VM당 하나씩 할당하는 방식과 동일한 개념입니다.
• 작업 공간(workspace)이 호스트와 동일한 경로에 마운트됩니다.
• Apple에 부족한 네이티브 도메인 허용 목록(domain allowlist) 기능을 갖추고 있습니다:

docker sandbox network proxy <box> --policy deny --allow-host example.com

이렇게 설정하면, 박스 내부에서 example.com은 200 응답을 받지만 그 외의 모든 요청은 403 응답을 받습니다. 더 중요한 점은, 프록시 환경 변수를 완전히 우회하더라도(curl --noproxy '*') 허용된 호스트에 대해서조차 실패한다는 것입니다. 외부로 나가는 직접적인 경로가 없으며, 중간자(MITM) 프록시만이 유일한 출구이기 때문입니다. 이는 위에서 언급한 내부 네트워크 설정과 동일한 강제성을 가집니다. 심지어 박스 내부에 docker CLI가 포함되어 있어, VM 내부의 컨테이너(containers-in-VM) 구동도 즉시 가능합니다.

솔직히 말해서, 현재 에이전트용 박스로서는 Docker Sandboxes가 가장 완벽한 옵션입니다. 네이티브 허용 목록, 다중 에이전트 지원, 스냅샷을 위한 save, 그리고 몇 초 만에 수행되는 reset 기능까지 갖추고 있습니다.

제가 흥미를 느끼는 지점은 어느 쪽이 더 나은가가 아니라, 두 접근 방식이 박스의 권한을 표현하는 방식이 다르다는 점입니다. Docker Sandboxes는 명령형 (imperative)입니다. 즉, 박스를 구성하기 위해 명령어를 실행해야 합니다. 반면 compose 방식은 선언형 (declarative)입니다. 마운트 (mounts), 환경 변수 (env), 네트워크 (networks)가 하나의 파일에 담겨 있습니다. 명령형은 이해되기 위해 절차 (procedure)가 실행되어야 하지만, 선언형은 인간이나 다른 에이전트에 의해 그저 '읽힐' 수 있습니다. 에이전트들이 서로의 박스를 구축하고 감사 (audit)하는 세상에서는, 읽기 가능한 형태가 승리할 것이라고 예상합니다. 하지만 이는 예측일 뿐 확정된 결과는 아닙니다. 오늘날 우리가 관찰할 수 있는 것은 동일한 VM 기반 박스를 위해 명령형과 선언형이라는 두 가지 어휘가 병렬적으로 등장하고 있다는 사실입니다.

Exhibit 4: 동일한 원칙의 세 가지 발명

"내부는 자유롭게, 경계는 문을 두드려라"는 Apple만의 패턴은 아닙니다. 플레이어들은 경계를 무엇으로 만드느냐에 따라 차이를 보입니다:

• 공간 계층 (The spatial layer) — 물리적 벽. VM: 에이전트가 물리적으로 도달할 수 없는 장소
• 의미 계층 (The semantic layer) — 동작의 의미를 판단. "이 force push가 위험한가?" 벽 대신 체크포인트 담당자(checkpoint officer)를 두는 방식
• 리소스 계층 (The resource layer) — 애초에 넘겨주는 것 자체를 축소. 마운트 (mounts) 및 환경 변수 (env): 보유하지 않은 것은 유출될 수 없음

"주요 (Main)"라고 표현한 이유는 아무도 하나의 계층에만 머물지 않기 때문입니다. Anthropic 또한 프로세스 수준의 공간 계층을 제공합니다 (macOS의 Seatbelt, Linux의 bubblewrap, 그리고 프록시로 강제되는 도메인 허용 목록(allowlist)을 포함하며, 이는 위에서 언급한 egress 설정과 놀라울 정도로 유사합니다). 하지만 이는 OS 프로세스 수준의 벽입니다. VM 단위의 커널 벽은 더 단단한 재질이며, 그것이 바로 Apple의 영역입니다.

시맨틱 레이어 (semantic layer)에 대해서도 언급할 가치가 있습니다. Claude Code의 auto-mode는 모든 도구 호출 (tool call)을 분류기 (classifier)를 통해 라우팅하며, 되돌릴 수 없거나 파괴적이거나 환경을 벗어나는 동작만을 차단합니다. 그 경계는 산문 (prose) 형태(예: "소스 제어: github.example.com/acme-corp")로 선언되며, 그 우선순위는 명시적인 사용자 의도에 따라 종료됩니다. 즉, "이 브랜치를 강제 푸시(force push)해줘"라고 말하면 소프트 블록 (soft block)이 해제됩니다. 대화 문맥 (conversational context)이 권한 부여 (authorization)의 일부가 되는 것인데, 이는 원칙적으로 VM이나 권한 (entitlement)이 할 수 없는 일입니다. 반대로, 확률적 분류기 (probabilistic classifier)는 임의의 코드 실행 (arbitrary code execution)이 미치는 폭발 반경 (blast radius)을 엄격하게 제한할 수 없습니다. 오직 공간 레이어 (spatial layer)만이 이를 할 수 있습니다.

따라서 "역량 매니페스트 (capability manifest)"는 세 가지 형태—권한 (entitlements), 산문 (prose), compose.yaml—로 세 번 발명되었으며, 이 세 가지는 서로 경쟁하지 않습니다. 이들은 심층 방어 (defense in depth)처럼 층을 이룹니다. 이들은 이미 한 구체적인 지점에서 맞물려 있습니다. auto-mode의 내장 규칙(claude auto-mode defaults로 확인 가능)은 에이전트 루프가 "샌드박스 격리 (sandbox isolation) 없이 그리고 작업별 승인/모니터링 게이트 없이" 실행될 때만 감독되지 않는 에이전트 루프의 실행을 차단합니다. 공간 레이어를 선언하면, 시맨틱 레이어는 한 걸음 물러납니다. 전시물 3의 샌드박스는 compose 파일을 통해 정확히 그 조건을 충족합니다.

판결 (Verdict)

구성 요소들은 존재하고, 철학은 일치하며, 이 상자(box)는 입증 가능한 방식으로 작동합니다. 부족한 것은 Apple이 이를 말해주는 것입니다. 도처에 정황 증거가 가득하지만, 용의자는 침묵을 지키고 있습니다.

이제 예측을 내놓겠습니다. 나중에 이 글의 정확도를 평가할 수 있도록 확신도 순으로 나열합니다. 만약 이 예측들이 틀린다면, 제목은 그저 제 상상이었을 뿐입니다.