Cursor 클라우드 에이전트를 사내 머신에서 실행하기: agent worker start 설정과 네트워크·보안 점검

Cursor 클라우드 에이전트를 쓰고 싶지만 사내 Git 서버, 내부 패키지 레지스트리, 사설망의 테스트 DB에 접근해야 해서 Cursor가 관리하는 VM으로는 작업이 끝나지 않는 팀을 위한 글이다. Cursor는 2026년 9월 2일 클라우드 에이전트의 도구 실행을 사용자가 관리하는 머신에서 돌리는 Self-Hosted Machines를 발표했다(Cursor Blog). 이 글을 따라가면 워커 머신을 준비하고 등록하는 명령, 방화벽에서 열어야 할 도메인, 개인 머신과 팀 풀의 차이, 데이터가 어디서 처리되는지까지 확인할 수 있다.

무엇이 사내로 오고 무엇이 Cursor에 남나

이 기능을 검토할 때 가장 먼저 정확히 해야 할 것은 경계다. 공식 문서와 발표 글에 따르면 바뀌는 것은 실행 환경뿐이다.

즉 소스 코드가 외부로 나가지 않는다는 보장이 아니다. 에이전트가 읽은 파일 내용과 명령 출력은 추론을 위해 Cursor 클라우드로 전달된다. 사내 보안 검토에서는 "실행 위치를 사내로 옮겨 내부 자원에 접근할 수 있게 하는 기능"으로 설명하는 것이 정확하다. 발표 글은 에이전트별 격리, 비밀값 마스킹(redaction), 이그레스 제어가 유지된다고 밝히고 있다.

개인 머신과 팀 풀 중 고르기

먼저 개인 머신으로 동작을 확인하고, 팀 단위로 넓힐 때 풀로 옮기는 순서가 문제 원인을 좁히기 쉽다.

워커 머신 준비와 등록 순서

1. Cursor CLI를 설치한다 — 워커로 쓸 머신마다 설치한다.
2. 인증한다 — 개인 머신은 agent login, 팀 풀은 서비스 계정 키를 환경 변수로 넣는다. 개인 계정 키를 공용 서버에 넣지 않는다.
3. 아웃바운드 연결을 확인한다 — 아래 도메인으로 HTTPS가 나가는지 먼저 시험한다.
4. 워커를 시작한다 — agent worker start를 실행하면 Cursor 백엔드로 장시간 유지되는 아웃바운드 HTTPS 연결이 열리고 머신이 등록된다.
5. 대시보드에서 실행 대상을 고른다 — 클라우드 에이전트를 시작할 때 등록된 머신이나 풀을 선택한다.

# 1) 설치
curl https://cursor.com/install -fsS | bash

# 2-a) 개인 머신
agent login

# 2-b) 팀 풀 워커
export CURSOR_API_KEY="<team service-account API key>"

# 3) 연결 확인 (사내 프록시가 있다면 HTTPS_PROXY 설정 후)
curl -sS -o /dev/null -w "%{http_code}\n" https://api2.cursor.sh

# 4) 워커 시작
agent worker start

curl ... | bash 형태의 설치 스크립트는 실행 전에 내용을 내려받아 확인하고, 사내 정책상 허용되는 설치 경로인지 보안 담당자와 확인한다.

방화벽과 프록시에서 열어야 할 것

문서에 따르면 인바운드 포트, 공인 IP, VPN 터널은 필요 없다. Cursor는 사내망으로 연결을 먼저 걸지 않고, 워커가 바깥으로 연결을 유지한다. 열어야 하는 아웃바운드 HTTPS 목적지는 다음과 같다.

사내 프록시를 거쳐야 한다면 HTTPS_PROXY 또는 https_proxy 환경 변수를 설정한다. 에이전트가 실제 작업에서 접근할 사내 Git 서버, 패키지 레지스트리, 테스트 DB는 워커 머신의 기존 네트워크 권한을 그대로 쓰므로, 워커 머신이 필요한 내부 자원에만 닿도록 서브넷과 보안 그룹을 따로 두는 것이 안전하다. 운영 DB에 닿는 머신을 워커로 쓰지 않는다.

풀 워커 옵션으로 작업 환경 맞추기

팀 풀 워커는 시작 옵션으로 저장소 체크아웃, 비밀값 동기화, 시작 명령을 정한다.

export CURSOR_API_KEY="<team service-account API key>"
export HTTPS_PROXY="http://proxy.internal:3128"
agent worker start \
  --clone-git-repos \
  --sync-dashboard-secrets \
  --on-session-start "./scripts/agent-bootstrap.sh"

위 예의 agent-bootstrap.sh는 각 팀이 만드는 스크립트다. 에이전트가 시작될 때 런타임 버전, 필수 도구, 접근 가능한 내부 호스트를 점검하고 실패하면 바로 종료하게 만들면, 환경 문제로 에이전트가 엉뚱한 수정을 시도하는 일을 줄일 수 있다. 이런 자가 점검 스크립트와 환경 파일 표준화는 클라우드 코딩 에이전트 실행 환경 만들기에서 자세히 다뤘다. 비밀값을 동기화할 때는 테스트용 최소 권한 자격 증명만 등록한다. 에이전트에게 넘길 비밀값 범위를 정하는 기준은 시크릿이 AI 코딩 도구 컨텍스트에 들어가지 않게 막는 설정을 참고한다.

화면 조작(computer use)까지 쓰려면

에이전트가 브라우저로 화면을 확인하게 하려면 워커에 Chrome 또는 Chromium이 있어야 하고 OS별 추가 조건이 있다(computer use 문서).

# Linux 워커에 필요한 패키지 (Debian/Ubuntu 패키지 이름 기준)
sudo apt-get install -y dbus-x11 ffmpeg tigervnc-standalone-server \
  x11-utils x11-xserver-utils xdotool xfce4

macOS 워커는 로그인된 데스크톱 세션이 있어야 하고, 손쉬운 사용(Accessibility)과 화면 기록(Screen Recording) 권한을 허용해야 한다. 화면 기록 권한이 있는 머신은 그 화면에 보이는 모든 것이 에이전트 입력이 될 수 있으므로, 개인 업무용 맥 대신 전용 머신을 쓰는 것이 바람직하다.

운영 전에 정해 둘 규칙

워커는 장시간 연결을 유지하는 프로세스이므로 서비스로 등록해 재시작 정책을 두고, 워커를 내릴 때는 진행 중인 세션이 없는지 대시보드에서 확인한다. 같은 저장소를 여러 에이전트가 동시에 고치는 상황에 대비해 작업 디렉터리를 세션별로 분리하는 것이 안전하다. 로컬에서 같은 문제를 다루는 방법은 Git Worktree로 AI 에이전트 작업 격리하기에 정리했다. Cursor 호스팅 VM 대신 AWS Lambda, Cloudflare, Coder, Daytona, E2B, Modal, Namespace, Vercel 같은 샌드박스 제공자를 실행 환경으로 연결하는 선택지도 발표 글에 소개돼 있으므로, 사내 머신 관리 부담이 크다면 함께 비교한다.