2026 Cursor Agent 파일을 잘못 지울까? Apple Container로 격리 샌드박스 만들기

파일을 지우거나 설정 파일을 덮어쓴 뒤, Cursor Agent가 어떤 경로를 건드렸는지 확인하기 어렵습니다.
가장 빠른 해법은 원본이 아닌 복구 가능한 코드 복사본 + Apple Container의 제한된 실행을 함께 사용하는 것입니다.

이 글은 Cursor Agent로 의존성 설치, 테스트, 빌드, 여러 파일 수정을 자동화하는 개인 개발자와 소규모 팀을 위한 실행 안내서입니다. 팀의 공통 실행 경계를 정하거나, 로컬 샌드박스와 원격 맥 개발 환경을 비교하는 담당자도 대상입니다.

먼저 구분할 것: Cursor의 보호 기능과 파일 시스템 경계

Apple Container는 Apple Silicon 맥에서 리눅스 컨테이너를 가벼운 가상 머신 방식으로 실행합니다. 전체 macOS를 컨테이너 안에 넣는 기능이 아닙니다. 따라서 리눅스 도구 체인, 의존성 설치, 코드 생성, 빌드, 단위 테스트, 스크립트 실행에는 적합하지만 Xcode GUI, 네이티브 서명, 완전한 macOS 빌드 흐름은 호스트나 별도 맥 환경에 남겨야 합니다. 자세한 요구 조건은 Apple Container 공식 저장소의 설치 안내에서 설치 직전에 다시 확인해야 합니다.

Cursor의 승인, 실행 모드, 규칙 파일은 보조 장치입니다. 공식 문서도 실행 모드와 자동 검토를 완전한 보안 경계가 아닌 최선의 보호 장치로 설명합니다. .cursorignore 역시 터미널과 외부 도구가 파일을 읽는 것을 막는 장치가 아닙니다. 그러므로 위험한 명령 목록만 믿지 말고, 애초에 Agent가 볼 수 있는 호스트 경로를 줄여야 합니다. (Cursor 보안 안내, 무시 파일의 한계)

Cursor Agent가 터미널 명령을 실행할 때 호스트 파일을 지키려면 어떻게 해야 하나요?
유일한 저장소를 열지 말고 임시 복사본이나 Git worktree를 여세요. 그 복사본만 읽기와 쓰기가 가능한 마운트로 연결하고, 홈 디렉터리와 비밀 키는 연결하지 않아야 합니다. 명령 차단 목록은 실수 방지용일 뿐입니다.

준비 단계: 복구 지점을 먼저 만든 뒤 환경을 확인합니다

Apple Container는 Apple Silicon 맥이 필요합니다. 공식 저장소는 macOS 26을 기준으로 지원하며, 이전 macOS에서는 기능과 네트워크 동작에 제한이 있을 수 있다고 안내합니다. 설치 전에는 다음 세 가지를 확인하세요.

1. Apple 메뉴의 시스템 정보에서 칩이 Apple Silicon인지 확인합니다.
2. macOS 26과 Apple Container의 현재 안정 출시 태그를 공식 출시 페이지에서 확인합니다.
3. 터미널에서 container system start를 실행한 뒤 상태와 기본 이미지 실행을 점검합니다.

작업 공간은 다음 중 하나로 만듭니다.

git worktree add ../agent-worktree HEAD

또는 저장소를 별도 임시 경로에 복제합니다.

git clone /원본/저장소/경로 ../agent-copy

원본 저장소와 작업 복사본을 혼동하지 않도록 이름을 분리하세요. 아직 커밋하지 않은 변경 사항이 있다면 먼저 패치나 별도 복사본으로 보관합니다. agent-canary.txt 같은 유인 파일도 작업 복사본과 원본 양쪽에 서로 다른 내용으로 만들어 두면, 뒤에서 삭제 범위를 확인하기 쉽습니다.

구성 비교: 원본 마운트보다 폐기 가능한 복사본이 안전합니다

세 번째 구성이 이 글의 기본값입니다. 다만 쓰기 마운트는 안전한 마법이 아닙니다. 컨테이너가 그 경로에 rm을 실행하면 호스트의 작업 복사본 파일도 삭제될 수 있습니다. 그래서 원본이 아닌 복사본이어야 합니다.

Apple Container가 다른 컨테이너 도구를 완전히 대신할 수 있나요?
리눅스 기반 작업을 맥에서 가볍게 실행하는 용도라면 선택지가 될 수 있습니다. 하지만 완전한 macOS 환경, Xcode GUI, 네이티브 서명, 팀별 중앙 정책이 필요하면 대체재가 아닙니다. Apple Container는 OCI 이미지와 Dockerfile 또는 Containerfile을 사용하지만, 호스트 macOS 격리와 개발 도구 전체를 제공하지는 않습니다.

첫 번째 실행: 최소 이미지와 일회성 컨테이너 만들기

프로젝트 루트에 Dockerfile을 만듭니다. Apple Container의 공식 명령 참고 문서는 container build가 Dockerfile 또는 Containerfile을 읽고 OCI 이미지를 만든다고 설명합니다. (공식 명령 참고)

FROM ubuntu:latest

RUN apt-get update \
    && DEBIAN_FRONTEND=noninteractive apt-get install -y \
       ca-certificates git curl build-essential python3 \
    && rm -rf /var/lib/apt/lists/*

WORKDIR /workspace
ENTRYPOINT ["/bin/bash", "-lc"]

이미지를 만듭니다.

container build --pull -t agent-sandbox:local .

다음으로 sandbox-run.sh를 만들고 실행 권한을 줍니다.

#!/bin/sh
set -eu

PROJECT_DIR=${1:?작업 복사본 경로가 필요합니다}
shift

PROJECT_DIR=$(cd "$PROJECT_DIR" && pwd)
HOST_UID=$(id -u)
HOST_GID=$(id -g)

exec container run --rm \
  --read-only \
  --network agent-internal \
  --no-dns \
  --uid "$HOST_UID" \
  --gid "$HOST_GID" \
  --cpus 2 \
  --memory 2G \
  --mount "type=bind,source=$PROJECT_DIR,target=/workspace" \
  --mount "type=tmpfs,target=/tmp,size=1G,mode=1777" \
  --workdir /workspace \
  agent-sandbox:local "$@"

chmod +x sandbox-run.sh

스크립트의 안전 장치는 네 가지입니다.

• --rm: 명령이 끝나면 컨테이너 인스턴스를 자동으로 제거합니다.
• --read-only: 컨테이너의 루트 파일 시스템을 읽기 전용으로 만듭니다.
• --mount: 지정한 작업 복사본만 /workspace로 연결합니다.
• --tmpfs: 캐시와 중간 파일을 컨테이너 메모리 영역에 두고 종료할 때 없앱니다.

읽기 전용 루트, 바인드 마운트, 임시 파일 시스템의 실제 옵션은 Apple Container 볼륨 문서에 설명되어 있습니다.

네트워크와 비밀 키: 연결하지 않는 것이 기본입니다

먼저 호스트 전용 네트워크를 만들 수 있습니다.

container network create --internal agent-internal

--internal 네트워크는 외부 연결이 필요한 일반 작업보다 호스트와 제한된 통신이 필요한 작업에 적합합니다. 의존성을 내려받아야 하는 초기 이미지 빌드는 별도로 수행하고, Agent가 실행하는 테스트 단계에서는 이 네트워크를 사용하세요. 네트워크 기능은 macOS 26에서 제공되는 명령이므로 다른 macOS에서는 동일한 명령이 동작한다고 가정하면 안 됩니다. (네트워크 공식 안내)

절대 자동으로 연결하지 말아야 할 항목은 다음과 같습니다.

• ~/.ssh
• 클라우드 자격 증명 디렉터리
• 키체인에서 내보낸 파일
• 개인용 .env
• 운영 환경 변수
• 홈 디렉터리 전체
• 원본 저장소

꼭 인증이 필요한 테스트라면 장기 키를 넘기지 말고, 짧은 만료 시간과 최소 권한을 가진 별도 자격 증명을 사용하세요. --ssh는 편리하지만 SSH 에이전트 소켓을 컨테이너에 전달하는 방식이므로, 민감한 저장소에서는 사용하지 않는 편이 낫습니다.

두 번째 연결: Cursor Agent가 포장 스크립트만 부르게 하기

Cursor에서 여는 폴더는 ../agent-worktree 같은 폐기 가능한 작업 공간이어야 합니다. 원본 경로를 열어 둔 상태에서 규칙만 추가하는 방식은 충분하지 않습니다.

프로젝트 규칙에는 다음처럼 명시합니다.

- 의존성 설치, 빌드, 테스트는 ./sandbox-run.sh . 명령으로 실행합니다.
- 호스트의 홈 디렉터리, 키체인, SSH 경로를 읽지 않습니다.
- 파일 삭제, 자격 증명 변경, 배포, 운영 설정 수정은 먼저 사람에게 확인합니다.
- Xcode GUI 작업과 네이티브 서명은 샌드박스 밖에서 수동으로 처리합니다.

허용할 자동 실행 범위는 git diff, 정적 분석, 단위 테스트, 임시 빌드, 코드 포맷과 같이 작업 복사본 안에서 끝나는 명령으로 좁히세요. 삭제, git reset --hard, 비밀 파일 검색, 배포 명령, 포트 공개, 호스트 설정 변경은 승인 대상으로 남겨야 합니다.

Cursor의 실행 모드는 승인과 자동 실행 범위를 조정하지만, 모든 명령을 완벽하게 가로채지는 않습니다. 따라서 Cursor 실행 모드 문서의 설정은 컨테이너 경계 위에 추가하는 보조선으로 사용하세요.

파괴적 검증: 정상 실행보다 실패 범위를 확인합니다

처음부터 실제 저장소를 맡기지 마세요. 다음 순서로 시험합니다.

• [ ] 원본 저장소와 작업 복사본의 경로를 터미널에서 각각 출력합니다.
• [ ] 양쪽에 서로 다른 유인 파일을 만듭니다.
• [ ] Apple Container가 Apple Silicon과 macOS 26 조건에서 실행되는지 확인합니다.
• [ ] container network create --internal agent-internal 실행 결과를 확인합니다.
• [ ] 이미지가 비 root 호스트 사용자 번호로 실행되는지 확인합니다.
• [ ] ./sandbox-run.sh ../agent-worktree "cat agent-canary.txt"로 파일 읽기를 시험합니다.
• [ ] 컨테이너 안에서 작업 복사본의 유인 파일만 삭제합니다.
• [ ] 원본 유인 파일이 남아 있는지 확인합니다.
• [ ] git diff --exit-code로 예상 밖 변경 범위를 검사합니다.
• [ ] 컨테이너 종료 후 container ls에 일회성 인스턴스가 남지 않았는지 확인합니다.
• [ ] 작업 로그에 키, 토큰, SSH 소켓 경로가 나타나지 않았는지 확인합니다.
• [ ] 네트워크가 필요한 작업과 필요하지 않은 작업의 연결 결과를 따로 기록합니다.

합격 기준은 단순합니다. 작업 복사본은 바뀌어도 원본과 홈 디렉터리는 바뀌지 않아야 합니다. 컨테이너가 종료된 뒤 임시 캐시가 남지 않아야 합니다. 하나라도 실패하면 Agent 작업을 중단하고 마운트와 네트워크 설정을 줄여야 합니다.

로컬 격리와 별도 맥 환경: 어디서 멈출지 결정합니다

혼자 짧은 테스트를 반복한다면 이 로컬 방식이 충분합니다. 반대로 원본 저장소를 직접 노출해야 하거나, 여러 사람이 같은 환경을 공유하거나, Agent가 개인 자격 증명에 접근해야 한다면 로컬 샌드박스의 장점이 빠르게 줄어듭니다. 그런 경우에는 맥 개발 환경 관리 화면과 원격 개발 환경 도움말을 확인해 재설정 가능한 별도 환경을 비교하세요.

현재 방식이 호스트 터미널 직접 실행이라면 세 가지 문제가 남습니다. 원본 경로를 잘못 열 수 있고, 개인 키와 환경 변수가 같은 사용자 권한 아래 섞이며, 여러 번 실패했을 때 동일한 상태로 되돌리기 어렵습니다. Apple Container는 이 문제를 리눅스 실행 단계에서 줄여 주지만, 쓰기 마운트로 연결한 데이터까지 보호하지는 않습니다. 원본을 분리하고, 키를 넣지 않고, 실행 후 폐기하는 운영이 어렵다면 MacHTML의 임시 맥 환경처럼 별도로 초기화할 수 있는 방식을 검토하는 편이 안전합니다. 특히 팀 테스트나 단기간의 고위험 Agent 작업이라면 먼저 MacHTML의 맥 환경 안내에서 원격 격리 방식을 비교해 보세요.