2026 Apple Container가 데스크톱 AI Agent를 격리할 수 있나요? 답은 이중 샌드박스입니다

애플 공식 구조 문서에 따르면 Apple Container는 지원되는 Apple silicon 맥과 macOS 26에서 리눅스 작업 부하를 실행하며, 각 컨테이너에 가벼운 가상 머신 경계를 제공합니다. 공식 구조 설명에서 확인되는 이 경계는 중요한 결론으로 이어집니다.

증상 → 가장 빠른 해결책

맥 앱까지 제어하는 데스크톱 AI Agent를 Apple Container 하나에 넣으려 하면 격리가 완성되지 않습니다. 리눅스 명령과 신뢰하지 않는 코드는 Apple Container에 넣고, 원어민 맥 조작은 호스트 샌드박스로 제한하는 이중 샌드박스를 선택해야 합니다. 고객 코드나 다중 사용자를 처리한다면 실행 계층을 원격 Firecracker 마이크로브이엠으로 분리해야 합니다.

이 글은 데스크톱 AI Agent의 권한 경계를 설계하는 맥 개발자를 위한 글입니다. 내부 Agent 플랫폼에서 어떤 도구를 맥에 남길지 결정하는 엔지니어에게도 유용합니다. 고객 저장소와 알 수 없는 바이너리를 다루는 보안 담당자는 마지막의 위험도 분류부터 확인하시기 바랍니다.

마지막 업데이트: 2026년 8월 24일. Apple Container, DeepSeek Harness, Firecracker의 공식 문서를 기준으로 내용을 다시 확인했습니다.

실행 위치부터 나누는 격리 경계

데스크톱 Agent의 기능을 다음 세 영역으로 나누면 판단이 빨라집니다.

• 리눅스 명령: 셸, 패키지 설치, 테스트, 저장소 분석, 빌드
• 호스트 파일: 맥의 작업 폴더, 설정 파일, 인증서, 개인 문서
• 맥 앱 제어: Finder, Xcode, 브라우저, 자동화 대상 앱

Apple Container는 첫 번째 영역에 적합합니다. 그러나 맥 앱은 리눅스 게스트 안에서 실행되지 않습니다. Finder나 Xcode를 조작하려면 호스트의 프로세스와 시스템 권한이 필요합니다. Apple Events 권한도 앱 자동화를 위한 별도 권한입니다. 애플의 자동화 권한 설명은 이 권한이 컨테이너 사용 여부와 별개의 문제임을 보여줍니다.

Apple Container로 맥 앱을 제어하는 AI Agent까지 격리할 수 있습니까?

단독으로는 어렵습니다. 컨테이너 안의 Agent가 맥 앱을 직접 조작하는 구조가 아니라, 호스트의 조정기가 승인된 명령을 받아 앱을 제어하는 구조이기 때문입니다. 따라서 컨테이너 경계와 호스트 권한 경계를 따로 설계해야 합니다.

“컨테이너를 썼다”는 사실만으로 안전성을 판단하면 안 됩니다. 호스트 폴더를 넓게 마운트했는지, 인증서와 환경 변수를 넘겼는지, 네트워크를 열었는지, 호스트 조정기가 어떤 앱 권한을 가졌는지가 실제 위험을 결정합니다.

리눅스 작업과 코드 실행

의존성 설치, 테스트 실행, 저장소 분석처럼 리눅스 도구만 필요한 작업은 Apple Container 안에 배치하는 편이 명확합니다. 컨테이너의 리눅스 실행 계층과 맥 호스트 앱 계층을 분리할 수 있기 때문입니다.

다만 가상 머신 경계가 있다고 해서 마운트한 호스트 데이터까지 보호되는 것은 아닙니다. Apple Container의 볼륨 문서는 호스트 경로를 실행 환경에 제공하는 방법을 설명합니다. 마운트는 편의 기능이면서 데이터 통로입니다.

다음 기준으로 제한하시기 바랍니다.

• 기본 이미지는 직접 검토한 최소 이미지로 고정합니다.
• 비밀 값은 이미지나 환경 변수에 굽지 않습니다.
• 저장소 전체가 아니라 필요한 작업 폴더만 읽기 전용으로 제공합니다.
• 결과물은 별도의 출력 폴더로만 돌려받습니다.
• 공개 네트워크가 필요하지 않은 테스트는 네트워크를 닫습니다.
• 패키지 설치가 필요하면 허용 대상과 시점을 기록합니다.

Apple Container 시작 안내는 컨테이너 생성과 실행의 기본 흐름을 제공합니다. 여기서 중요한 점은 명령을 실행하는 법보다 어떤 경로를 제공할지 먼저 정하는 것입니다.

macOS AI Agent가 본체 파일을 수정할 때 Seatbelt만 쓰면 충분합니까?

충분하지 않을 수 있습니다. Seatbelt 또는 sandbox-exec 기반 로컬 샌드박스는 같은 호스트 안에서 파일 효과 범위를 제한하는 수단입니다. DeepSeek Harness의 샌드박스 구현 기록도 이를 파일 접근 효과를 제한하는 로컬 기능으로 설명합니다.

따라서 Seatbelt을 완전한 네트워크 격리나 가상 머신 경계로 확대 해석하면 안 됩니다. 맥 앱 자동화 권한, 로그인 세션, 이미 허용된 폴더, 조정기 프로세스의 권한은 별도로 점검해야 합니다.

호스트 쪽에는 다음을 조합합니다.

• 작업 영역 밖 쓰기를 거부하는 호스트 샌드박스
• 최소 권한의 전용 사용자 계정
• 매번 새로 만드는 임시 작업 폴더
• 승인된 앱과 명령만 통과시키는 조정기
• 변경 전후의 파일 목록과 자동화 기록

맥 조작과 리눅스 도구의 혼합 실행

혼합 작업에서는 이중 샌드박스가 기본값입니다. 호스트 조정기는 Finder나 Xcode 같은 원어민 기능만 담당합니다. 셸, 컴파일러, 패키지 관리자, 신뢰하지 않는 스크립트는 Apple Container 안에서 실행합니다.

이때 셸 도구와 파일 도구의 작업 영역 의미를 일치시켜야 합니다. 셸은 컨테이너 안의 /workspace를 쓰는데 파일 도구가 호스트의 사용자 폴더를 직접 수정하면 경계가 무너집니다. 두 도구 모두 승인된 입력 경로와 출력 경로만 보도록 구성해야 합니다.

권장 흐름은 다음과 같습니다.

1. 호스트에서 작업을 위한 일회성 디렉터리를 생성합니다.
2. 입력 파일은 컨테이너에 읽기 전용으로 제공합니다.
3. 셸과 파일 조작 도구를 모두 컨테이너의 같은 작업 영역에 연결합니다.
4. 결과물은 지정된 출력 경로로만 내보냅니다.
5. 호스트 조정기는 결과를 검사한 뒤에만 맥 앱에 전달합니다.
6. 작업이 끝나면 임시 디렉터리와 컨테이너를 함께 폐기합니다.

이 구조에서는 원어민 맥 자동화와 리눅스 코드 실행의 데이터면을 분리할 수 있습니다. 특히 Agent가 “파일을 수정했다”고 보고해도 실제 반영은 승인된 결과 회수 단계에서만 일어나게 만들 수 있습니다.

주의: 입력 폴더를 읽기 전용으로 만들었더라도 출력 폴더를 넓게 잡으면 위험은 그대로 남습니다. 보호해야 할 것은 컨테이너의 이름이 아니라 호스트로 돌아오는 결과 경로입니다.

고객 코드와 다중 사용자의 위험 분리

고객 저장소, 공개 인터넷에서 받은 코드, 알 수 없는 바이너리, 동시 실행되는 여러 사용자의 작업은 로컬 프로세스 샌드박스에만 맡기기 어렵습니다. 넓은 디렉터리 마운트와 오래 살아 있는 맥 세션이 결합되면 한 작업의 실패가 다른 작업의 파일과 인증 정보에 영향을 줄 수 있습니다.

이 경우 Firecracker가 적합한지는 “더 빠른가”가 아니라 경계를 어디에 둘 것인가로 판단해야 합니다. Firecracker 설계 문서는 가상 머신 기반의 별도 게스트 실행 모델을 설명합니다. 운영 호스트 권장 사항도 운영 환경에서 호스트 구성을 별도로 다뤄야 함을 전제로 합니다.

로컬 Apple Container는 맥에서 리눅스 작업을 가까이 실행하고, 원어민 앱과 연결해야 할 때 편리합니다. 원격 Firecracker 마이크로브이엠은 신뢰하지 않는 실행을 일상적인 맥 세션과 떼어 놓을 때 유리합니다. 반대로 원격 계층에서는 네트워크 경로, 이미지 배포, 로그, 폐기 정책을 새로 운영해야 합니다.

Docker를 이미 쓰고 있다면 Docker 공식 보안 문서의 권한과 데몬 경계를 먼저 검토해야 합니다. Docker를 Apple Container로 바꾸는 것만으로 데스크톱 자동화 권한 문제가 사라지지는 않습니다.

위험도별 선택 기준

아래 표는 런타임의 우열을 정하는 표가 아닙니다. Agent가 실제로 무엇을 만지는지에 따라 선택하는 표입니다.

AI Agent의 셸과 파일 도구는 같은 샌드박스에 둬야 합니까?

같은 작업 의미를 봐야 합니다. 두 도구가 모두 작업 결과를 만들고 수정한다면 같은 제한된 작업 영역에 두는 편이 안전합니다. 셸은 컨테이너에 두고 파일 도구만 호스트에 남기면 Agent가 실행 경계를 우회할 수 있습니다. 호스트 파일 도구가 꼭 필요하다면 허용된 입력과 출력, 변경 방식, 승인 단계를 별도로 고정해야 합니다.

실제 작업으로 확인하는 격리 절차

실행 전에 문서만 읽지 말고 거부 동작을 확인해야 합니다. 다음 순서로 테스트하면 됩니다.

1. 작업 영역 밖의 임의 경로에 파일을 쓰도록 명령합니다.
2. 승인하지 않은 인증 파일과 환경 변수의 읽기를 시도합니다.
3. 허용 목록에 없는 네트워크 주소에 접속을 시도합니다.
4. 마운트하지 않은 호스트 경로를 읽고 수정하도록 합니다.
5. 호스트 앱 자동화 권한이 없는 상태에서 Finder나 Xcode 조작을 시도합니다.
6. 작업을 종료하고 컨테이너와 임시 폴더를 삭제합니다.
7. 로그, 프로세스, 소켓, 파일 잔여물을 다시 검사합니다.

각 테스트에는 “거부되어야 함”이라는 예상 결과와 실제 결과를 함께 기록합니다. Apple Container에서는 마운트 경계와 컨테이너 내부 경계를 따로 확인합니다. 호스트 샌드박스에서는 작업 영역 밖 파일과 앱 권한을 따로 확인합니다. 원격 마이크로브이엠에서는 폐기 뒤 디스크와 작업 큐에 잔여물이 없는지 확인합니다.

MacHTML의 맥 원격 환경 사용 안내를 참고하면 실제 운영 전에 접근 방식과 관리 절차를 점검할 수 있습니다. 여러 작업을 반복해서 검증해야 한다면 MacHTML 콘솔에서 테스트용 맥 환경을 분리해 확인하는 방식도 고려할 수 있습니다.

현재 맥 한 대에서 원어민 앱 자동화와 고위험 코드 실행을 모두 처리하면 권한이 넓어지고, 작업 폴더와 인증 정보가 섞이며, 실패한 프로세스가 남는 문제가 생깁니다. 반대로 실행 계층을 모두 원격으로 옮기면 맥 앱 제어 지연과 운영 복잡성이 커질 수 있습니다. 그래서 일반적인 데스크톱 Agent에는 호스트 제한과 Apple Container의 이중 구성이 현실적입니다. 기존 맥이 이 경계를 동시에 만족하지 못한다면 MacHTML의 별도 맥 환경에서 원어민 자동화를 맡기고, 고위험 코드는 원격 마이크로브이엠으로 보내는 구성이 더 안전한 출발점입니다.