애플 컨테이너 에이전트 샌드박스 구축법

파일을 잘못 지우거나 에이전트가 맥의 인증키를 읽는 상황이 걱정된다면, 일반 컨테이너만으로는 부족합니다.
이번 주에는 애플 실리콘과 맥오에스 26에서 애플 컨테이너로 에이전트마다 가상 머신 경계를 만들고, 네트워크·키·파일 쓰기 권한을 별도로 제한하는 방식으로 시작하는 것이 가장 안전합니다.

마지막 업데이트: 2026년 8월 17일. 애플 공식 저장소, 공식 변경 기록, 파이어크래커 공식 문서와 공개 에이전트 실행 자료를 기준으로 확인했습니다. 버전과 지원 범위는 이후 변경될 수 있으므로 배포 직전에 다시 확인해야 합니다. (github.com)

이 글은 개인 맥에서 코딩 에이전트를 시험하는 개발자, 같은 실행 환경을 원격 맥으로 옮기려는 플랫폼 엔지니어, 코드 실행 격리 기준을 정하는 보안 담당자를 위한 글입니다. 단순히 명령어를 실행하는 방법보다, 어디까지 격리되며 어떤 통제가 여전히 필요한지에 초점을 둡니다.

애플 컨테이너의 적용 범위

애플 컨테이너는 애플 실리콘 맥에서 리눅스 컨테이너를 가벼운 가상 머신 안에서 실행하는 도구입니다. 애플 공식 저장소는 맥오에스 26을 지원 환경으로 설명하며, 이전 맥오에스에서 발생한 문제는 일반적으로 지원 대상이 아니라고 명시합니다. 표준 이미지 저장소에서 사용하는 오씨아이 이미지도 가져올 수 있습니다. (github.com)

따라서 다음과 같은 에이전트에는 적합합니다.

• 리눅스 명령어를 실행하는 코딩 에이전트
• 테스트 저장소 안에서 의존성을 설치하는 자동화 에이전트
• 프로젝트 파일을 수정하고 결과물을 별도 폴더로 내보내는 작업
• 개인 맥 또는 원격 맥에서 반복 실행해야 하는 개발 작업

반대로 애플 컨테이너 하나만으로 다음 위험이 사라지는 것은 아닙니다.

1. 허용하지 않은 인터넷 주소로 외부 연결을 시도하는 위험
2. 환경 변수나 마운트된 폴더를 통해 비밀값을 읽는 위험
3. 작업 폴더 밖으로 결과를 쓰거나 삭제하는 위험
4. 무한 프로세스와 대용량 파일로 호스트 자원을 소모하는 위험
5. 승인 없이 배포, 결제, 데이터 삭제 같은 고위험 작업을 실행하는 위험

OpenAI의 에이전트 실행 환경도 격리된 파일 시스템, 제한된 네트워크, 입력과 출력의 분리를 별도 통제로 다룹니다. 즉, 가상 머신 경계는 첫 번째 방어선이지 전체 보안 설계가 아닙니다. (openai.com)

배포 전 확인 목록

가장 먼저 실제 호스트와 복구 경로를 확인합니다. 애플 공식 프로젝트는 현재 개발이 진행 중이며, 같은 주요 버전 안에서도 패치 버전 사이의 안정성을 보장하는 방식이라고 설명합니다. 운영용으로 고정하기 전에 공식 변경 기록과 보안 공지를 검토해야 합니다. (github.com)

파이어크래커는 리눅스 케이브이엠을 요구하고, 공식 문서도 호스트에서 /dev/kvm 읽기·쓰기 권한을 확인하도록 안내합니다. 그러므로 애플 실리콘 맥에서 애플 컨테이너를 쓰던 환경을 그대로 파이어크래커로 바꿀 수 있다고 보면 안 됩니다. 이미지와 작업 인터페이스는 재사용할 수 있지만, 실행 호스트와 운영 계층은 달라집니다. (github.com)

배포 전에는 다음을 기록합니다.

• 애플 실리콘 여부
• 맥오에스 26 지원 여부
• 설치할 애플 컨테이너 버전과 이전 버전
• 사용할 이미지와 이미지의 프로세서 구조
• 테스트 저장소의 복사본 위치
• 필요한 모델 연결 주소와 패키지 저장소
• 중지, 삭제, 정리, 재설치 명령

공식 설치 안내의 최신 변경 기록은 애플 컨테이너 공식 저장소와 변경 기록에서 확인합니다. 실험용 맥에는 실제 사용자 홈 폴더나 운영 저장소를 처음부터 연결하지 않는 것이 좋습니다.

첫 실행과 일회성 작업

서비스를 시작한 뒤 상태를 확인합니다.

container system start
container system status
container list --all

애플 공식 문서에 따르면 container system start는 컨테이너 서비스를 시작하고 필요한 기본 커널 설치를 안내합니다. container run은 이미지에서 컨테이너를 실행하며, --rm을 사용하면 종료 뒤 컨테이너를 자동으로 제거할 수 있습니다. (github.com)

첫 실행은 다음처럼 삭제 가능한 테스트 이미지와 저장소로 제한합니다.

container run --name agent-test --rm \
  --mount type=bind,source="$PWD/test-repo",target=/workspace \
  agent-image:trial

실제 명령은 사용하는 이미지의 시작 명령과 마운트 정책에 맞게 조정해야 합니다. 핵심은 세 가지입니다.

• /workspace에는 테스트 복사본만 연결합니다.
• 사용자 홈 폴더 전체를 연결하지 않습니다.
• .ssh, 키체인 관련 파일, 운영 환경 파일을 연결하지 않습니다.

애플 컨테이너가 맥 호스트 파일 접근을 완전히 막아 주나요?

마운트하지 않은 호스트 경로를 기본 작업 공간처럼 직접 제공하는 방식은 피할 수 있지만, 이것이 모든 공격 경로를 자동으로 제거한다는 뜻은 아닙니다. 호스트 쪽 공유 폴더, 환경 변수, 네트워크 서비스, 에이전트 실행기를 통해 정보가 다시 전달될 수 있습니다. 따라서 파일 경계는 마운트 설정과 실행기 권한을 함께 점검해야 합니다.

첫 작업은 다음 순서로 검수합니다.

1. 에이전트가 /workspace 안의 파일을 읽을 수 있는지 확인합니다.
2. 의존성 설치와 단위 테스트를 실행합니다.
3. 변경된 파일 목록을 호스트에서 확인합니다.
4. /workspace 밖에 쓰기를 시도하는 작업을 차단하거나 기록합니다.
5. 컨테이너를 중지하고 목록에서 사라지는지 확인합니다.
6. 이미지, 볼륨, 네트워크 잔여물이 남는지 확인합니다.

container system df
container prune
container image prune

container system df는 이미지·컨테이너·볼륨의 사용량과 정리 가능 항목을 표시합니다. 테스트 종료 후 이 결과를 저장하면 “작업이 끝났다”는 판단을 실행 프로세스 종료만으로 내리지 않게 됩니다. (github.com)

네트워크와 비밀값 경계

에이전트가 패키지를 내려받고 모델 응용 프로그래밍 인터페이스를 호출해야 한다면, 네트워크를 무조건 열거나 무조건 닫는 대신 목적별로 분리합니다.

• 모델 연결 주소
• 승인한 패키지 저장소
• 필요한 코드 저장소
• 내부 기록 수집 주소

그 외의 외부 연결은 기본 차단을 목표로 합니다. 특히 테스트 중인 에이전트에 일반 웹 접근을 제공하면, 악성 의존성 설치나 인증 정보 전송을 탐지하기 어려워집니다. OpenAI도 실행 환경에서 제한된 네트워크와 승인 정책을 함께 사용한다고 설명합니다.

애플 컨테이너에서 에이전트 네트워크와 키를 어떻게 제한해야 하나요?

키는 이미지에 넣지 말고, 작업 시작 직전에 짧은 유효기간과 최소 권한으로 주입합니다. 가능하면 읽기 전용 토큰을 사용하고, 코드 저장소 토큰과 모델 연결 키를 같은 환경 변수 묶음에 넣지 않습니다.

다음 정책을 권장합니다.

• 이미지와 저장소에 비밀값을 기록하지 않습니다.
• 공유 환경 파일에 장기 키를 저장하지 않습니다.
• 작업마다 새 키를 발급하고 종료 뒤 폐기합니다.
• 코드 저장소에는 읽기 전용 권한부터 적용합니다.
• 네트워크 기록에 키와 인증 헤더가 남지 않도록 합니다.
• 배포와 삭제 명령은 사람의 확인 뒤 실행합니다.

비밀값이 컨테이너 로그에 남지 않는지 별도로 확인해야 합니다. 공식 명령 참조에는 환경 변수 전달 방식과 로그·실행 명령이 분리되어 있지만, 실제 에이전트 실행기와 셸 스크립트가 값을 출력할 가능성은 남아 있습니다. (github.com)

로컬에서 원격 맥으로 옮기는 방식

로컬 시험이 끝났다면 호스트의 개인 상태를 복사하지 말고, 다음 네 가지를 다시 생성할 수 있게 만듭니다.

1. 이미지 빌드 파일
2. 컨테이너 시작 인자
3. 마운트와 네트워크 정책
4. 로그와 삭제 절차

원격 맥에서는 접속 제어와 실행 제어를 분리합니다. 원격 셸에 로그인한 사용자에게 호스트 전체 권한을 주면 애플 컨테이너의 경계가 약해질 수 있습니다. 세션 만료, 동시 작업별 저장소, 작업 중단 시 강제 삭제, 실행 로그 보존을 운영 계층에서 추가해야 합니다.

원격 맥에서 처음 실행할 때는 다음 방식이 안전합니다.

• 동일한 이미지 요약값을 확인합니다.
• 동일한 테스트 저장소 복사본을 사용합니다.
• 로컬과 같은 네트워크 허용 목록을 적용합니다.
• 작업 종료 뒤 컨테이너와 임시 폴더를 삭제합니다.
• 중단 신호를 보낸 뒤 프로세스와 파일 잔여물을 확인합니다.
• 실패 로그와 삭제 결과를 하나의 작업 번호로 묶습니다.

원격 맥 임대 환경이 필요하다면 JexMac의 원격 맥 운영 안내에서 접속과 관리 절차를 먼저 확인하고, 장시간 실행 전에 소규모 테스트 작업으로 검증하는 편이 비용 통제에 유리합니다. 장기 작업의 비용 구조를 검토할 때는 JexMac의 이용 요금 안내도 함께 확인할 수 있습니다.

로컬 애플 컨테이너 샌드박스를 원격 맥으로 옮길 때 무엇을 복사해야 하나요?

호스트의 컨테이너 데이터나 사용자 홈 폴더를 통째로 복사하지 않습니다. 이미지, 시작 인자, 권한 정책, 테스트 저장소 생성 절차를 코드로 남기고 원격 호스트에서 새 작업을 만듭니다. 이렇게 해야 로컬에서 우연히 남아 있던 키, 캐시, 네트워크 경로가 원격 환경에 따라가지 않습니다.

파괴적 작업 중심의 첫 주 검수

정상적인 코딩 작업만 성공하면 샌드박스가 안전하다고 판단하기 쉽습니다. 첫 주에는 오히려 실패를 의도적으로 만들어야 합니다.

파일 경계

테스트 저장소 밖의 경로를 읽고 쓰는 작업을 실행합니다. 호스트의 문서 폴더, 셸 설정, 에스에스에이치 폴더를 직접 연결하지 않았는지 확인합니다.

비밀값 노출

가짜 키를 작업 환경에 넣고, 에이전트가 파일·환경 변수·로그·프로세스 목록을 통해 이를 읽을 수 있는지 확인합니다. 검수 결과에는 실제 비밀값 대신 식별용 가짜 값을 남깁니다.

허용하지 않은 외부 연결

허용 목록 밖의 주소에 연결을 시도하고, 차단 로그가 생성되는지 확인합니다. 패키지 저장소를 허용했다면 임의의 파일 업로드 주소와 구분되는지도 확인합니다.

자원 고갈

무한 반복 프로세스와 대용량 임시 파일 생성을 실행합니다. 호스트가 느려지는지, 작업이 제한 시간 안에 종료되는지, 종료 뒤 프로세스가 남지 않는지 기록합니다.

중단과 복구

컨테이너를 강제 중지하고 다시 시작합니다. 작업 결과가 부분적으로 남는 경우와 완전히 삭제되는 경우를 구분합니다. 복구해야 하는 결과물은 별도의 출력 폴더로 내보내고, 임시 작업 폴더는 삭제 대상으로 분리합니다.

이 기록에는 최소한 다음 항목이 있어야 합니다.

• 호스트 파일 변경 여부
• 키와 가짜 비밀값의 노출 여부
• 외부 연결 차단 여부
• 자원 고갈 시 호스트 영향
• 재시작 뒤 작업 상태
• 삭제 뒤 남은 이미지·볼륨·네트워크
• 로그만으로 작업을 재구성할 수 있는지

파이어크래커로 바꿀 시점

다음 조건이 충족되면 애플 컨테이너를 억지로 확장하지 않는 편이 낫습니다.

• 서로 신뢰하지 않는 여러 사용자가 동시에 실행합니다.
• 리눅스 서버와 케이브이엠 기반 자동 확장이 필요합니다.
• 노드 사이에서 작업을 예약해야 합니다.
• 고위험 코드 실행을 전용 호스트로 분리해야 합니다.
• 실행량과 자원 한도를 중앙에서 관리해야 합니다.

파이어크래커는 하드웨어 가상화 기반의 마이크로 가상 머신을 사용하며, 공식 설계 문서는 다중 테넌트 작업과 격리를 주요 목표로 설명합니다. 또한 기본 보안 설정으로 시스템 호출 필터를 사용하고, 운영 환경에서 이를 해제하지 말 것을 권고합니다. (github.com)

언제 애플 컨테이너에서 파이어크래커로 바꿔야 하나요?

개인 맥의 단일 에이전트 시험이라면 애플 컨테이너를 유지합니다. 반면 리눅스 다중 테넌트, 중앙 예약, 고위험 비신뢰 코드가 핵심이면 파이어크래커 실행 계층을 별도로 설계합니다. 이때 이미지와 작업 입력·출력 형식은 유지하되, 맥 전용 호스트 기능에 의존한 부분은 제거해야 합니다.

애플 컨테이너는 애플 실리콘 맥에서 빠르게 에이전트 개발 환경을 격리하기에 좋은 선택입니다. 그러나 공유 작업 폴더, 장기 키, 열린 네트워크, 무제한 원격 셸을 그대로 둔 현재 환경이라면 가상 머신 경계만 추가해도 위험은 남습니다. 로컬 맥은 단일 개발자 검증에 적합하고, 원격 맥은 반복 실행과 팀 접근 제어를 보완할 때 의미가 있습니다. 다중 테넌트 리눅스 운영이 목표라면 처음부터 파이어크래커 같은 전용 계층을 검토하는 편이 장기적으로 재작업 비용을 줄입니다.

이번 주에는 테스트 저장소 하나와 최소 권한 키 하나로 애플 컨테이너를 실행하고, 위의 파일·키·네트워크·자원 고갈 시험을 통과한 뒤 원격 맥으로 옮기면 됩니다. 임시 에이전트 실행 환경이 필요하다면 동일한 이미지와 검수 목록을 적용할 수 있는 JexMac의 원격 맥 시작 경로에서 작은 작업부터 검증하는 방식이 가장 현실적입니다.