2026 Cursor Agent 팀 샌드박스는 어떻게 구성할까? Apple Container 역할별 방안

Apple의 공식 자료는 Apple Silicon과 macOS 26에서 Apple Container가 리눅스 작업 부하를 실행할 수 있다고 설명합니다. Apple Container 공식 안내와 WWDC 소개 자료를 기준으로 보면, 이번 주에는 전 직원에게 같은 설정을 배포하지 말고 역할별 권한표부터 확정해야 합니다. 일반 개발은 Cursor 기본 샌드박스, 의존성 설치와 위험한 저장소 스크립트는 Apple Container, 서명과 배포는 사람의 승인과 독립 맥 환경으로 분리하는 방식이 안전합니다.

이 글은 Cursor Agent에 터미널 실행을 허용하는 개발 책임자, 저장소 관리자, 빌드 담당자, 배포 담당자를 위한 글입니다. 개인 개발자에게는 최소 권한 기준을, 보안 담당자에게는 예외 승인과 회수 기준을 제공합니다.

이번 주 적용 순서

역할 이름보다 중요한 기준은 작업 위험도입니다. 같은 개발자라도 일반 코드 작성과 배포 서명은 전혀 다른 실행 경계에서 처리해야 합니다.

개인 개발자의 최소 권한 기준

개인 개발자도 승인 없는 전역 실행을 기본값으로 두면 안 됩니다. Cursor의 Run Modes와 실행 보호 기능은 명령 실행 모드와 승인 흐름을 나누며, 터미널 보호 동작은 위험한 명령을 별도로 다루는 기준을 제공합니다.

일상적인 코드 생성, 정적 검사, 단위 테스트에는 현재 작업 저장소의 읽기와 쓰기만 허용합니다. 네트워크는 패키지 저장소처럼 필요한 대상만 열고, 셸 명령은 승인 후 실행하도록 둡니다. 홈 폴더, SSH 키, 클라우드 자격 증명, 운영 설정 파일은 읽기 대상에서도 제외해야 합니다.

작업 폴더에 쓸 수 있다는 사실은 데이터가 안전하다는 뜻이 아닙니다. 에이전트가 저장소 안의 설정 파일을 덮어쓰거나, 무시 파일에 가려진 파일을 변경할 수 있기 때문입니다. 작업 시작 전 복구 가능한 브랜치나 별도 복사본을 만들고, 자동 실행은 그 복사본에서만 허용합니다.

기능 개발자의 저장소 경계

팀 구성원이 같은 sandbox.json을 써야 하는지는 사용자 설정과 프로젝트 설정의 책임을 나누어 판단해야 합니다. 사용자 설정은 개인 장비의 기본 차단선을 담당하고, 프로젝트 설정은 저장소에 필요한 읽기, 쓰기, 네트워크 범위를 정의합니다. Cursor 샌드박스 설정 문서는 필드와 설정 병합 규칙을 확인하는 기준으로 사용해야 합니다.

권장 정책은 다음과 같습니다.

• 읽기: 현재 저장소와 팀이 승인한 읽기 전용 공유 경로만 허용합니다.
• 쓰기: 현재 저장소의 작업 영역과 임시 빌드 폴더로 제한합니다.
• 네트워크: 의존성 저장소와 사내 테스트 서비스의 도메인만 등록합니다.
• 차단: 홈 폴더, 일반 자격 증명 폴더, 브라우저 데이터, 개인 문서 경로를 제외합니다.
• 승인: 저장소 바깥으로 복사하거나 새 설치 스크립트를 실행할 때 사람이 확인합니다.

주 사용자 설정과 프로젝트 설정이 충돌할 때 어느 쪽이 우선하는지는 팀이 임의로 추측하면 안 됩니다. 배포하는 Cursor 버전의 공식 병합 규칙을 확인하고, 실제 테스트 저장소에서 읽기와 쓰기 결과를 검증해야 합니다. 전 직원에게 한 파일을 복사하는 방식은 역할별 제한을 무너뜨립니다.

기능 개발용 설정 예시

아래 예시는 실제 비밀값이나 운영 주소를 넣지 않은 프로젝트 정책의 뼈대입니다. 필드 이름은 배포 중인 Cursor 문서와 대조한 뒤 저장소 정책에 맞춰 사용합니다.

{
  "filesystem": {
    "read": ["./", "/Users/team/shared-readonly"],
    "write": ["./", "/tmp/cursor-work"],
    "denyRead": [
      "~/.ssh",
      "~/.aws",
      "~/.config",
      "~/Library/Keychains"
    ]
  },
  "network": {
    "allowedDomains": [
      "패키지-저장소-주소",
      "테스트-서비스-주소"
    ]
  }
}

이 설정에서 공유 경로를 쓰기 목록에 넣지 않는 것이 핵심입니다. 프로젝트 파일을 읽을 수 있어도 개인 인증 폴더 전체를 마운트해서는 안 됩니다. 팀 정책은 저장소에 버전 관리하고, 사용자가 자신의 전역 설정으로 허용 범위를 넓히지 못하도록 검토 절차를 둡니다.

저장소 유지보수자의 임시 실행 영역

마이그레이션, 코드 자동 생성, 대량 수정, 외부 설치 스크립트는 작업 저장소만 제한해도 위험이 남습니다. 스크립트가 패키지 관리자 설정을 바꾸거나, 숨겨진 사용자 설정을 읽거나, 네트워크에서 추가 파일을 내려받을 수 있기 때문입니다.

이 작업은 원본 저장소가 아닌 임시 복사본을 Apple Container 안에 넣습니다. Apple Container는 맥 앱을 격리하는 도구가 아니라 리눅스 작업 부하를 실행하는 컨테이너 기술입니다. 공식 구조 설명도 이 실행 경계를 기준으로 설명합니다.

간단한 임시 영역 생성 예시는 다음과 같습니다.

#!/bin/sh
set -eu

SOURCE="${1:-.}"
WORK="$(mktemp -d "${TMPDIR:-/tmp}/agent-work.XXXXXX")"

git clone --local "$SOURCE" "$WORK/repo"

container run --rm \
  --mount "type=bind,source=$WORK/repo,target=/work" \
  --workdir /work \
  "승인된-리눅스-이미지" \
  sh -lc 'git status --short && ./scripts/run-approved-task.sh'

rm -rf "$WORK"

실제 실행 전에는 승인한 이미지와 명령을 저장소 정책에 기록해야 합니다. 마운트 구문과 읽기 전용 옵션은 Apple Container 볼륨 문서에서 확인합니다. 네트워크가 필요하면 전체 인터넷을 열지 말고 공식 네트워크 설정 문서의 방식으로 제한합니다.

이 방식은 리눅스 기반 빌드와 스크립트에는 적합하지만, Xcode, 맥용 SDK, 시뮬레이터, 키체인, 맥 전용 서명 도구를 대신하지 못합니다. 그런 단계는 컨테이너 안에서 억지로 해결하지 말고 별도의 통제된 맥 환경으로 승격합니다.

빌드와 테스트 담당자의 예외 관리

빌드 담당자는 패키지 저장소, 이미지 저장소, 테스트 서비스, 공유 캐시를 요구합니다. 그렇다고 전체 네트워크와 홈 폴더를 허용하면 편의성 때문에 격리의 의미가 사라집니다.

예외는 다음 네 항목으로 기록합니다.

• 허용 도메인: 패키지와 이미지 다운로드에 필요한 도메인만 등록합니다.
• 읽기 전용 경로: 사전 검증된 도구 모음과 공용 설정만 연결합니다.
• 쓰기 캐시: 작업 전용 캐시 폴더를 만들고 자격 증명 파일과 분리합니다.
• 만료 조건: 특정 작업이나 검증 기간이 끝나면 예외를 회수합니다.

캐시가 없거나 네트워크가 차단된 경우의 하향 경로도 정해야 합니다. 먼저 사전에 검증한 의존성 묶음으로 테스트하고, 그것도 불가능하면 격리된 빌드 환경에서 실패 로그만 수집합니다. 빌드 성공을 이유로 모든 외부 연결을 영구 허용해서는 안 됩니다.

배포와 서명의 독립 경계

코드 준비와 빌드 검증은 Cursor 샌드박스 또는 Apple Container에서 처리할 수 있습니다. 그러나 코드 서명, 키체인 접근, 배포 토큰 사용, 운영 환경 변경은 일반 Agent 대화에 포함하지 않는 편이 안전합니다.

특히 다음 자료는 공용 컨테이너에 마운트하지 않습니다.

• 서명 인증서와 개인 키
• 맥 키체인 데이터
• 배포 토큰과 운영용 환경 변수
• 운영 서버 접속 정보
• 앱 배포 계정의 장기 자격 증명

서명과 배포가 필요한 경우에는 검증된 빌드 산출물을 통제된 맥 환경으로 전달하고, 사람이 변경 내용을 확인한 뒤 짧은 작업 세션에서 승인합니다. 리눅스 컨테이너는 맥 전용 서명과 일부 배포 도구의 실행 단계를 대체하지 않습니다. 이 경계를 흐리면 Agent가 작성한 코드의 문제와 자격 증명 노출 문제가 한 번에 결합됩니다.

팀 운영자의 권한 매트릭스

다음 조건으로 팀 정책을 결정하면 도구 이름만 보고 권한을 나누는 실수를 줄일 수 있습니다.

• 현재 저장소 안에서 코드 생성, 정적 검사, 단위 테스트만 수행하면 Cursor 기본 샌드박스를 선택합니다.
• 패키지 설치, 외부 스크립트, 대량 변경이 필요하고 리눅스 실행으로 충분하면 임시 저장소 복사본과 Apple Container를 함께 선택합니다.
• 맥 전용 빌드나 시뮬레이터가 필요하면 컨테이너 대신 통제된 맥 빌드 환경으로 이동합니다.
• 인증서, 키체인, 운영 토큰이 필요하면 자동 실행을 거부하고 사람의 승인 단계로 넘깁니다.
• 여러 사람이 민감한 저장소에서 동시에 작업하거나 호스트 접근을 완전히 분리해야 하면 독립 클라우드 맥 환경을 검토합니다.
• 장기간 반복되는 고정 부하가 주 업무이고 물리적인 맥 도구 접근이 필요하면 임대보다 전용 장비가 적합할 수 있습니다.

정책에는 버전, 예외 승인자, 만료일, 파괴적 테스트 담당자, 복구 책임자를 함께 적습니다. 매번 권한을 추가하기만 하면 팀의 샌드박스는 넓어지고 회수되지 않습니다. 주기적으로 사용하지 않는 도메인과 경로를 삭제하고, 원본 저장소를 복구할 수 있는지 확인해야 합니다.

팀이 로컬 맥, Apple Container, 클라우드 맥 중 무엇을 선택할지 더 넓게 비교하려면 AI Agent 개발 환경 선택 기준을 먼저 확인하는 편이 좋습니다. 서명과 운영 자격 증명을 외부 환경으로 옮길 때는 전달 방식과 회수 조건을 별도로 검토해야 하며, 팀 단위 맥 환경의 비용을 산정할 때는 JexMac 이용 요금 안내에서 현재 제공 조건을 확인해야 합니다.

현재 방식과 독립 맥 환경의 선택

직원 맥에서 모든 작업을 처리하는 방식은 시작이 빠르지만, 권한이 개인 파일과 섞이고, 여러 Agent 작업이 같은 캐시와 자격 증명을 바라보며, 배포 승인 기록을 남기기 어렵다는 단점이 있습니다. Apple Container만으로 통일하는 방식도 맥 전용 도구와 키체인을 처리하지 못하고, 팀이 이미지와 마운트 정책을 계속 관리해야 한다는 한계가 있습니다.

따라서 민감한 저장소, 서명 배포, 여러 작업자의 병렬 실행이 함께 발생한다면 일상 장비와 분리된 맥 환경이 더 관리하기 쉬울 수 있습니다. 이때는 먼저 이 글의 역할 권한표를 채우고, 실제로 컨테이너에서 처리할 작업과 독립 환경으로 넘길 작업을 나누어야 합니다. 임시 산출물 검증이나 팀 공용 테스트처럼 짧게 필요한 맥 실행면은 JexMac의 맥 환경 안내에서 전달 방식과 이용 조건을 확인한 뒤 비교하면 됩니다. 반대로 장기간 고정 부하나 물리 장치 연결이 핵심이면 직접 장비를 운영하는 편이 더 합리적일 수 있습니다.