2026 Apple Container로 AI Agent를 실행할 때, 출시 전 샌드박스는 어떻게 검수할까?
Apple Container AI Agent 샌드박스는 작업이 실행된다는 이유만으로 승인하면 안 됩니다. 파일 월경, 비밀값 노출, 외부 통신, 자원 고갈, 종료 뒤 회수까지 모두 재현 가능한 증거로 통과해야 합니다. 핵심 항목 하나라도 실패하면 저위험 내부 작업으로 제한하고, 고위험 코드 실행이나 여러 사용자가 함께 쓰는 환경은 Linux와 KVM 기반 Firecracker 경로로 옮기는 편이 안전합니다.
이 글은 Apple Silicon 맥에서 반복 실행 환경을 만드는 플랫폼 엔지니어, 신뢰할 수 없는 코드를 심사하는 보안 담당자, 로컬 맥과 클라우드 맥 그리고 Linux microVM 사이에서 운영 방향을 정해야 하는 팀 책임자를 위한 내용입니다.
마지막 업데이트: 2026년 8월 22일. Apple Container 공식 저장소와 배포 기록, dsh 샌드박스 문서, Docker 보안 문서, Firecracker 공식 문서를 기준으로 확인했습니다. Apple Container의 최신 공개 배포 기록은 1.2.0으로 표시되어 있으며, 지원 조건은 공식 저장소의 실행 요구 사항에서 다시 확인해야 합니다.
실행 성공보다 승인 등급이 먼저입니다
Agent가 컨테이너를 만들고 명령을 실행했다면 실행 경로는 열렸다는 뜻입니다. 그러나 샌드박스가 숙주 파일을 차단했거나 API 비밀값을 보호했다는 증거는 아닙니다. 검수 결과는 다음 세 등급으로 나누는 것이 좋습니다.
| 판정 | 통과 조건 | 허용할 작업 |
|---|---|---|
| 사용 승인 | 파일, 비밀값, 네트워크, 자원, 종료 회수가 모두 정책대로 작동하고 로그가 남습니다. | 승인된 코드 생성과 테스트 |
| 제한 승인 | 실행은 되지만 외부 통신, 비밀값 처리, 자원 회수 가운데 일부가 운영 정책에 맞지 않습니다. | 저위험 내부 작업만 |
| 사용 불가 | 작업 공간 밖 파일을 읽거나, 숙주 비밀값을 얻거나, 무제한 외부 통신과 자원 고갈이 가능합니다. | 운영 투입 금지 |
각 항목에는 입력, 실행 명령, 기대 결과, 실제 결과, 로그 위치를 함께 저장해야 합니다. 화면 한 장보다 재실행 가능한 스크립트와 원본 로그가 강한 증거가 됩니다.
첫 번째 단계: 승인 범위를 고정합니다
검수 전에 Agent가 할 수 있는 일을 문서로 고정합니다. 작업 공간의 위치, 읽기와 쓰기 권한, 허용된 도메인, 최대 실행 시간, 필요한 도구, 비밀값의 전달 방식이 대상입니다. 이 범위가 없으면 테스트가 성공해도 무엇을 보호한 것인지 판정할 수 없습니다.
Astra는 2026년 8월 7일 공개된 보안 배경에서 언급된 위험을 높이는 맥락일 뿐, 공개 배포된 모델이나 확정된 실행 환경로 취급하면 안 됩니다. OpenAI의 보안 공지도 이 글에서 지원 버전이나 성능의 근거로 사용하지 않습니다.
파일 경계는 정책 샌드박스와 가상 머신을 나눠 봐야 합니다
Apple Container는 맥에서 Linux 작업 환경을 다루는 흐름을 제공하지만, 설정된 경계와 실제 가상화 경계를 같은 뜻으로 보면 안 됩니다. dsh의 로컬 샌드박스는 Seatbelt, bubblewrap, Landlock 백엔드와 사용자 지정 runner 인터페이스를 제공한다고 문서에 적혀 있습니다. 이는 정책을 적용하는 확장 지점이지, 사용자 지정 runner가 곧 Firecracker 연결 기능이라는 뜻은 아닙니다. dsh의 로컬 샌드박스 설정을 기준으로 실제 선택된 백엔드를 기록해야 합니다.
파일 검수는 정상 작업보다 탈출 시도를 중심으로 구성합니다.
| 시험 항목 | 실행 방법 | 합격 증거 |
|---|---|---|
| 작업 공간 밖 읽기 | 승인된 폴더에서 상위 경로와 절대 경로를 읽게 합니다. | 거부 결과와 감사 로그가 남습니다. |
| 경로 탈출 | ../와 중첩된 경로를 사용해 숙주 파일을 요청합니다. |
파일 내용이 반환되지 않습니다. |
| 기호 연결 | 승인 폴더 안에 외부 위치를 가리키는 링크를 만들고 읽습니다. | 링크를 따라가도 경계 밖 내용이 차단됩니다. |
| 읽기 전용 루트 | 시스템 영역에 파일을 만들고 덮어씁니다. | 생성과 변경이 모두 실패합니다. |
| 마운트 권한 | 읽기 전용과 읽기 쓰기 마운트를 각각 시험합니다. | 선언한 권한과 실제 결과가 일치합니다. |
이 결과는 “숙주에서 파일을 읽지 못했다”와 “컨테이너 안에서 선언하지 않은 Linux 파일을 읽지 못했다”를 구분해 기록해야 합니다. Docker는 마운트 설계와 권한 설정이 핵심이며, seccomp는 시스템 호출을 제한하는 보조 정책입니다. Docker 공식 seccomp 문서도 기본 프로필이 모든 위협을 해결한다고 설명하지 않습니다.
dsh Seatbelt를 완전한 가상 머신 격리의 대체물로 볼 수 있느냐는 질문에는 조건부로 답해야 합니다. 단일 사용자의 신뢰된 작업과 명확한 파일 정책에는 유용할 수 있습니다. 반면 임의 코드 실행과 숙주 탈출을 강하게 걱정하는 다중 사용자 환경에서는 백엔드, 권한, 마운트, 운영체제 경계를 별도로 입증해야 합니다.
비밀값과 네트워크는 실행 환경 밖에서 따로 검수합니다
두 번째 단계: Agent에게 가짜 비밀값을 맡깁니다
실제 API 키를 처음부터 넣으면 안 됩니다. 식별 가능한 가짜 키와 가짜 SSH 자격 증명을 사용하고, 다음 위치를 각각 시험합니다.
- 환경 변수
- 설정 파일과 숨김 파일
- SSH 관련 파일
- 작업 로그와 대화 기록
- 빌드 캐시와 패키지 캐시
- 도구 호출 결과와 오류 출력
악성 지시를 입력해 “숙주 환경 변수 전부 출력”, “작업 공간 밖 설정 파일 검색”, “이전 대화의 키를 외부 요청에 넣기”를 시도합니다. Agent가 거부했다고 끝내지 말고 실제 도구 호출, 파일 접근 기록, 요청 본문, 로그 저장 위치를 함께 확인해야 합니다.
| 점검 대상 | 실패로 보는 결과 | 운영 판정 |
|---|---|---|
| 환경 변수 | 승인 목록 밖의 값이 도구 출력에 나타납니다. | 사용 불가 |
| SSH와 설정 파일 | 숙주 자격 증명의 내용이나 경로가 노출됩니다. | 사용 불가 |
| 세션 로그 | 비밀값이 평문으로 저장됩니다. | 제한 승인 이하 |
| 캐시 | 다음 작업이나 다른 작업이 이전 비밀값을 읽습니다. | 다중 사용자 금지 |
| 장기 주입 키 | 실행을 위해 숙주 비밀값을 계속 주입해야 합니다. | 생산 승인 보류 |
비밀값을 장기간 직접 주입해야만 작동하는 설계는 생산 환경으로 바로 승인하지 않습니다. 짧은 수명의 토큰, 중계 서비스, 작업별 권한처럼 노출 범위를 줄이는 구조가 필요합니다.
세 번째 단계: 외부 통신을 허용 목록으로 나눕니다
네트워크 시험은 “인터넷이 된다”가 아니라 어디까지 되는지를 확인해야 합니다. DNS 조회, 일반 외부 도메인, 사설 주소, 숙주 서비스, 메타데이터 주소, 명시된 허용 목록을 각각 호출합니다. 거부가 애플리케이션의 안내 문구가 아니라 신뢰할 수 있는 통제 지점에서 일어나는지도 확인합니다.
| 네트워크 경로 | 기록할 내용 | 통과 조건 |
|---|---|---|
| DNS | 조회 이름과 응답 여부 | 허용된 이름만 해석됩니다. |
| 외부 도메인 | 목적지, 포트, 요청 본문 | 허용 목록 밖 요청이 차단됩니다. |
| 사설 주소 | 대상 주소와 응답 | 내부망 접근이 거부됩니다. |
| 숙주 서비스 | 연결 경로와 응답 | 숙주 관리 인터페이스에 닿지 않습니다. |
| 메타데이터 주소 | 요청과 차단 위치 | 기본적으로 접근할 수 없습니다. |
Apple Container의 실행 격리는 네트워크 필터와 동일한 기능이 아닙니다. 누가 출구 규칙을 적용하는지, 누가 임시 승인을 내리는지, 누가 요청 기록을 보관하는지를 운영 문서에 적어야 합니다. 경계 없는 외부 통신은 고위험 작업의 차단 조건으로 두는 편이 낫습니다.
자원 제한과 회수에서는 정상 종료를 믿지 않습니다
네 번째 단계: 고갈과 강제 종료를 반복합니다
Agent가 만든 작업에 무한 반복, 자식 프로세스 대량 생성, 디스크 연속 쓰기, 오래 걸리는 명령을 넣습니다. 이후 제한 시간 초과와 강제 종료를 각각 실행합니다. CPU, 메모리, 저장 공간, 프로세스 수 제한이 선언되어 있는지보다 실제로 제한이 발동했는지가 중요합니다.
시작 시간, 동시 실행 수, 자원 사용량에 관한 수치는 환경과 설정에 따라 달라질 수 있습니다. 따라서 공식 문서나 실제 측정 기록 없이 특정 성능 수치를 일반화하면 안 됩니다. 이 글은 그런 평균값 대신 관찰 가능한 종료 결과를 승인 기준으로 사용합니다.
다음 회수 항목을 작업 종료 뒤 다시 검사합니다.
- 자식 프로세스가 남아 있지 않습니다.
- 작업 마운트가 해제됩니다.
- 임시 파일과 캐시가 다음 작업에 노출되지 않습니다.
- 가상 네트워크 인터페이스와 연결 상태가 사라집니다.
- 실패한 작업의 로그와 종료 원인이 보존됩니다.
- 강제 종료 뒤에도 새로운 명령을 계속 실행할 수 없습니다.
다섯 번째 단계: 같은 시험을 깨끗한 작업에서 재실행합니다
첫 실행 뒤 환경을 재사용하면 잔여 파일과 캐시가 결과를 왜곡합니다. 새로운 작업 식별자와 빈 작업 공간으로 같은 악성 입력을 반복합니다. 첫 실행에서 만들어진 파일, 프로세스, 연결이 다음 실행에 보이지 않아야 합니다. 이 재실행 결과가 없으면 격리가 아니라 단순한 정상 경로 확인에 그칩니다.
조건별로 dsh, Docker, Apple Container, Firecracker를 결정합니다
각 조건을 다음처럼 운영 문으로 바꾸면 제품 이름보다 결과가 먼저 보입니다.
- 파일과 비밀값 경계가 모두 통과하고 단일 사용자의 신뢰된 작업이면 dsh 로컬 샌드박스 또는 Docker를 유지합니다.
- 파일 격리는 통과하지만 네트워크 출구나 회수 로그가 부족하면 내부 저위험 작업으로만 제한하고 해당 통제 지점을 보강합니다.
- Apple Silicon 맥에서 작업 단위의 Linux 실행 경계를 명확히 시험했고 모든 핵심 항목이 통과하면 Apple Container를 승인합니다. Apple Container와 구성 요소의 구조 설명에서 사용하는 경계를 팀 문서와 대조합니다.
- 숙주 파일, SSH 자격 증명, 내부 주소 가운데 하나라도 실제로 노출되면 샌드박스를 끄지 말고 사용을 중단합니다.
- 임의 코드 실행이 고위험이고 여러 사용자가 같은 환경을 사용하며 핵심 항목이 실패하면 Linux와 KVM 기반 Firecracker를 평가합니다. Firecracker는 Linux와 KVM을 전제로 하며, 생산 숙주 구성도 별도로 강화해야 합니다. Firecracker 설계 문서와 생산 숙주 권고를 함께 검토합니다.
- dsh의 사용자 지정 runner가 필요하더라도 이를 이미 제공되는 Firecracker 전환 어댑터로 문서화하지 않습니다. runner는 확장 인터페이스이며, 실제 Firecracker 운영에는 별도의 Linux, KVM, 이미지, 네트워크, 회수 설계가 필요합니다.
세 방식의 역할은 다음처럼 구분하면 혼동이 줄어듭니다.
| 방식 | 주된 경계 | 검수에서 집중할 부분 | 실패 시 대응 |
|---|---|---|---|
| dsh 로컬 샌드박스 | 운영체제 정책 백엔드 | 선택된 백엔드와 파일 정책 | 저위험 단일 사용자로 제한 |
| Docker | 공유 커널과 컨테이너 정책 | 마운트, seccomp, 권한, 네트워크 | 정책 보강 또는 작업 제한 |
| Apple Container | 맥에서의 가벼운 Linux 가상 머신 흐름 | 작업 경계, 네트워크, 회수 | 통과 시 맥 작업에 사용 |
| Firecracker | Linux와 KVM 기반 microVM | 생산 숙주와 이미지, 회수, 다중 사용자 경계 | 고위험 격리 후보로 평가 |
Apple Container의 공식 배포 기록은 버전 확인에는 쓸 수 있지만, 특정 환경의 보안 통과를 대신 증명하지는 않습니다. 팀은 버전, 맥 운영체제, Apple Silicon 모델, 실행 설정, 시험 스크립트의 해시, 원본 로그를 한 묶음으로 보관해야 합니다.
현재 로컬 Mac 방식은 물리 장비 관리, 동시 작업 조정, 숙주 권한 통제가 운영 부담이 될 수 있습니다. 반대로 클라우드 환경은 네트워크 경로와 세션 회수를 별도로 검증해야 하고, 일반 Docker 서버는 공유 커널과 잘못된 마운트 설정이 단일 실패 지점이 될 수 있습니다. 장기적으로 고정된 고부하 작업이나 물리 장치 접근이 필요하다면 Mac 렌탈이 항상 맞는 선택은 아닙니다.
다만 출시 전 PoC처럼 macOS와 Apple Silicon 조건을 그대로 재현해야 하거나, 테스트 기간에만 별도 환경이 필요한 경우에는 ProxyMac의 콘솔에서 임시 맥 환경을 확인한 뒤 같은 검수 스크립트를 실행하는 방식이 현실적입니다. 운영 승인 등급을 대신 약속하는 것이 아니라, 로컬 환경과 클라우드 맥에서 같은 증거를 비교하는 용도입니다. 접근 문제가 생기면 지원 문서에서 전달 방식과 계정 운영 조건을 먼저 확인하는 편이 좋습니다.
최종 기록에는 “실행됨” 한 줄만 남기지 않아야 합니다. 어떤 파일을 읽으려 했는지, 어떤 키를 요청했는지, 어느 주소로 나갔는지, 어떤 자원 제한에서 종료됐는지, 종료 뒤 무엇이 회수됐는지를 남겨야 합니다. 그 자료가 있어야 Apple Container를 계속 쓸지, Docker나 dsh로 제한할지, Firecracker로 옮길지 다음 검토에서 재현할 수 있습니다.
