Cursor 셀프 호스팅: AI 에이전트 툴 실행을 사내망에 두는 구조

2026년 9월 2일 Cursor가 공개한 Cursor 셀프 호스팅 방식은 보안 경계와 인프라 비용을 함께 옮깁니다. 이제 팀은 에이전트의 툴 실행을 직접 통제하는 머신에 둘 수 있지만, 해당 워커의 운영도 직접 책임져야 합니다. 모델, 계획 수립, 에이전트 루프는 여전히 Cursor 클라우드에서 작동합니다.

Cursor 셀프 호스팅의 핵심은 런타임 분리입니다

Cursor Cloud Agent는 두 부분으로 나뉩니다. 에이전트 루프는 다음 작업을 판단하고 모델을 호출합니다. 툴 실행은 파일을 수정하고, 터미널 명령을 실행하고, 브라우저를 열고, 로컬 MCP 서버와 통신하며, 내부 서비스에 접근하는 부분입니다.

Cursor Self-Hosted Machines는 이 두 부분을 분리합니다. 루프, 추론, 계획 수립, 인터페이스, 세션 오케스트레이션은 Cursor가 계속 담당하고, 직접 관리하는 워커가 툴을 실행합니다.

워커로는 노트북, VM, Mac, Kubernetes 파드 또는 통합 파트너의 샌드박스를 사용할 수 있습니다. 워커는 Cursor에 아웃바운드 HTTPS 연결을 열고, 툴 호출을 받아 로컬에서 실행한 뒤 결과를 반환합니다. 워커에 인바운드 포트나 공인 IP를 둘 필요는 없습니다.

운영 주체를 나누면 다음과 같습니다.

Cursor는 두 가지 워커 구성을 제공합니다. My Machines는 한 사람의 계정에 머신을 연결하며, 개발용 머신이나 범위가 좁은 개인 워크플로에 적합합니다. Team Pools는 Enterprise 팀을 위한 이름이 지정된 대기열입니다. 요청은 사용 가능한 워커가 가져갈 때까지 풀에서 대기하며, 각 풀 워커는 한 번에 Cloud Agent 세션 하나만 처리합니다.

이는 Cursor 모델을 온프레미스로 운영하는 기능이 아닙니다. 고객이 실행 영역을 소유하는 분리형 런타임입니다. 이 차이를 이해해야 해당 기능이 조직의 정책을 충족하는지 판단할 수 있습니다.

내부에 남는 데이터와 외부로 나가는 데이터

전체 체크아웃, 빌드 캐시, 머신 로컬 자격 증명은 워커에 남습니다. 명령, 저장소 작업, 빌드, 내부 서비스 호출도 그곳에서 실행됩니다. 따라서 저장소 전체를 벤더가 관리하는 실행 VM으로 복사할 필요를 없앨 수 있습니다.

다만 에이전트가 판단하려면 여전히 컨텍스트가 필요합니다. 실행 중 워커는 에이전트에 필요한 파일 내용, 터미널 출력, diff, 스크린샷, 로컬 MCP 결과, 라우팅 메타데이터를 Cursor로 보냅니다. 스크린샷, 동영상, 로그 참조 역시 Cursor 관리형 아티팩트 스토리지에 업로드되어 풀 리퀘스트와 대시보드에 표시될 수 있습니다.

아티팩트 호스트를 차단해도 에이전트는 계속 작동하지만, 해당 아티팩트는 풀 리퀘스트와 대시보드에서 사라집니다. Privacy Mode도 적용되므로 워커에서 전송된 코드는 Cursor나 모델 제공업체의 학습에 사용되지 않습니다. 그렇다고 세션이 오프라인으로 바뀌는 것은 아닙니다.

첫 번째 사업적 함의는 명확합니다. 이제 보안 검토에서 실행 위치와 모델 처리를 따로 승인할 수 있지만, 결국 두 영역 모두 승인을 받아야 합니다.

어떤 팀에 적합하며 무엇이 달라지나

내부 서비스를 사용하는 엔터프라이즈 백엔드 팀

백엔드 팀이 비공개 패키지 레지스트리, 스테이징 데이터베이스, 관리형 VM에서 접근할 수 없는 서비스 엔드포인트를 사용해야 할 수 있습니다. Team Pool을 같은 통제 네트워크에 두면 Cursor에서 들어오는 인바운드 경로를 열지 않고도 빌드를 실행할 수 있습니다.

핵심 이점은 접근 제어이지, 프라이버시가 자동으로 보장된다는 뜻은 아닙니다. 플랫폼 팀은 기존 네트워크 정책과 시크릿 저장소를 그대로 활용하고, 보안 팀은 어떤 결과가 아웃바운드 연결을 통해 넘어가는지 정확히 검토할 수 있습니다.

Mac 환경이 필수인 iOS 팀

Cursor 관리형 Cloud Agents는 Ubuntu VM에서 실행됩니다. iOS 작업에 Mac 하드웨어가 필요한 팀이라면 Mac을 워커로 등록하고 필요한 컴퓨터 사용 권한을 부여해, 에이전트가 해당 머신에서 클릭과 입력, 스크린샷 촬영, 브라우저 조작을 수행하도록 할 수 있습니다.

원격 에이전트가 빌드와 같은 종류의 하드웨어를 쓸 수 있다는 점이 이점입니다. 반면 Mac 빌드 팜을 운영해 본 팀이라면 익숙한 이미지 편차, 권한, 가동 시간, 정리, 교체 문제는 그대로 직접 책임져야 합니다.

에이전트 수요가 급증하는 플랫폼 팀

플랫폼 팀은 Team Pool 뒤에 Cloudflare Containers를 배치할 수 있습니다. 참조 템플릿은 가져온 세션마다 격리된 컨테이너 하나를 시작하고, Durable Object가 해당 컨테이너를 소유하도록 하며, 저장소 스냅샷을 R2에 캐시할 수 있습니다.

연결된 워커가 없어도 풀은 유지되므로 용량을 0까지 줄일 수 있습니다. 작업이 다시 들어오면 컨트롤러가 요청을 가져가 컨테이너를 시작합니다. 상시 가동하는 워커 팜 대신 실제 사용량에 맞춰 컴퓨팅 자원을 운용할 수 있다는 점이 이점입니다.

상태를 유지하는 개발용 머신을 쓰는 개인 개발자

My Machines는 다시 구성하기 번거로운 로컬 툴이나 상태에 프로젝트가 의존하는 개발자에게 적합합니다. 여러 에이전트가 같은 머신을 공유할 수 있어 개인용 머신에서는 편리하지만, 민감한 작업에는 주의가 필요합니다.

빠르게 환경을 준비할 수 있다는 것이 이점입니다. 반면 세션 사이에 잔여 상태가 남을 수 있습니다. Cursor가 매 세션마다 노트북을 초기화하고 다시 구축해 주는 것은 아니기 때문입니다. 작업 디렉터리, 자격 증명, 프로세스 정리, 머신 상태는 모두 직접 관리해야 합니다.

실제로 실행할 수 있는 Cloudflare 구성

Cloudflare 방식은 새롭게 바뀐 운영 책임의 경계를 분명히 보여준다는 점에서 유용합니다. Cursor Enterprise, 에이전트 범위 권한이 있는 팀 서비스 계정 키, Containers와 R2를 사용할 수 있는 Cloudflare Workers Paid 계정, Node.js 20 이상, Docker가 필요합니다.

1. 1

   Team Pool 등록

   Cursor CLI를 설치하고 정상 실행되는지 확인한 다음, 임시 로컬 워커를 연결해 Cursor에 풀이 나타나도록 합니다.

   curl https://cursor.com/install -fsS | bash
   agent --version
   export CURSOR_API_KEY="<team service-account API key>"
   CURSOR_API_KEY="$CURSOR_API_KEY" agent worker --pool cloudflare-test start

   풀이 표시되면 Ctrl+C로 해당 워커를 중지하고 unset CURSOR_API_KEY를 실행합니다. Cloudflare를 테스트하는 동안에는 로컬 워커를 중지해 두어야 요청을 먼저 가져가지 않습니다.

2. 2

   Cursor 참조 템플릿 배포

   템플릿을 복제해 설치하고 Cloudflare에 로그인한 뒤, 선택 사항인 스냅샷 버킷을 만듭니다.

   git clone https://github.com/anysphere/cloudflare-workers.git
   cd cloudflare-workers
   npm install
   npx wrangler login
   npx wrangler r2 bucket create cursor-pool-worker-snapshots

3. 3

   자격 증명 저장

   Cursor 서비스 계정 키를 Worker 시크릿에 저장합니다. 컨테이너가 비공개 저장소에 접근해야 할 때만 Git 자격 증명을 추가합니다.

   npx wrangler secret put CURSOR_API_KEY
   npx wrangler secret put GIT_USERNAME
   npx wrangler secret put GIT_TOKEN

   개인용 Cursor API 키는 Team Pool에서 작동하지 않습니다. 컨트롤러가 401을 반환하므로 인프라 장애로 오인하기 가장 쉬운 설정 오류입니다.

4. 4

   풀과 용량 설정

   wrangler.jsonc에서 CURSOR_POOL을 cloudflare-test로 변경합니다. containers[].max_instances는 팀의 개발자 수가 아니라 동시에 실행할 세션의 최대치로 설정합니다.

   참조 파일의 기본값은 max_instances 10이며, standard-1 컨테이너는 0.5 vCPU, 메모리 4 GiB, 디스크 8 GB를 제공합니다. 실제 빌드에는 더 큰 구성이 필요할 수 있습니다.

5. 5

   배포 후 첫 실행 확인

   배포한 뒤 Cloud Agent를 시작하고 셀프 호스팅 풀을 선택하는 동안 컨트롤러와 컨테이너 화면을 계속 열어 둡니다.

   npx wrangler deploy
   npx wrangler tail
   npx wrangler containers list

   처음 예약된 컨트롤러 실행이 시작되기까지 최대 5분이 걸릴 수 있습니다. 가져간 세션이 시작되지 않는다면 대개 컨테이너 용량, 저장소 복제 또는 Git 자격 증명 문제입니다.

비용은 사라진 것이 아니라 이동했습니다

Cursor 관리형 Cloud Agents에는 실행 인프라가 포함됩니다. Self-Hosted Machines도 선택한 모델에 대해 Cursor 요금을 지불하며, 여기에 자체 워커 비용이 추가됩니다. Team Pools에는 가격이 별도 협의되는 Enterprise 계약도 필요합니다.

Cloudflare 사례를 보면 추가 비용 항목이 어떻게 계산되는지 알 수 있습니다. Containers 제품은 월 $5의 Workers Paid 플랜에서 제공됩니다. 여기에는 메모리 25 GiB-hours, CPU 375 vCPU-minutes, 디스크 200 GB-hours가 포함됩니다. 포함량을 넘으면 메모리는 GiB-second당 $0.0000025, 활성 CPU는 vCPU-second당 $0.000020, 프로비저닝된 디스크는 GB-second당 $0.00000007입니다.

참조 템플릿의 standard-1 구성을 기준으로 각각 한 시간 동안 작동하고, 활성 상태에서 가용 CPU를 모두 사용한 다음, 템플릿의 5분 유휴 구간을 거치는 세션 100개를 가정해 보겠습니다. 포함 사용량을 제외한 컨테이너 비용은 월 약 $12입니다.

$5 plan + $3.15 CPU + $3.675 memory + $0.168 disk = $11.993

이는 인프라 비용을 보여주기 위한 예시일 뿐, Cursor 전체 청구액은 아닙니다. Worker와 Durable Object 사용량, 로그, 이그레스, R2, Enterprise 계약, 모델 사용량, 워커 팜을 유지하는 인력 비용은 포함하지 않습니다. 또한 가장 작은 템플릿 구성이 충분하다고 가정합니다. 컴파일 작업이 많은 저장소라면 더 큰 컨테이너가 필요할 수 있습니다.

실제로 비용을 크게 좌우하는 결정은 초당 단가가 아니라 상시 유지 용량 정책인 경우가 많습니다. Cursor의 일반 풀 워커는 재연결 대기 시간을 기본 3,600초로 두지만, Cloudflare 템플릿은 이를 300초로 줄입니다. 대기 시간이 길면 후속 프롬프트가 더 빨리 처리되는 대신 프로비저닝된 메모리와 디스크 요금이 계속 발생합니다. 짧게 설정하면 유휴 비용은 줄지만 콜드 스타트가 늘어납니다.

용량도 직접 책임져야 합니다. 템플릿의 기본 동시 실행 한도는 컨테이너 10개입니다. 설정한 용량이나 계정 한도에 도달했거나 기반 호스트를 사용할 수 없으면 다음 요청은 대기하거나 시작에 실패합니다. Cursor는 작업을 풀로 라우팅할 수 있지만, 사용자가 프로비저닝하지 않은 용량까지 만들어 주지는 못합니다.

격리도 같은 원칙을 따릅니다. Cloudflare 템플릿은 세션마다 전용 컨테이너 하나를 제공합니다. 개인용 머신에서는 여러 에이전트가 호스트 하나를 함께 쓸 수 있습니다. 정책상 실행할 때마다 새 VM, 초기화된 디스크, 테넌트 분리 또는 정리된 시크릿 경계가 필요하다면, 그 동작은 직접 구현하고 검증해야 합니다.

패치 역시 정기 운영 업무가 됩니다. 팀은 기본 이미지, Cursor CLI, 빌드 툴, 인증서, 종속성, 롤아웃을 책임집니다. Cloudflare에서 새 컨테이너 이미지를 배포하면 실행 중인 컨테이너가 중지되므로, 활성 세션이 끝날 때까지 업데이트를 미루거나 중단을 감수해야 합니다.

지금 무엇을 해야 하나

Cloud Agent에 커스텀 하드웨어, 커스텀 이미지 또는 관리형 네트워킹으로 제공할 수 없는 툴 접근 권한이 필요하다면 이번 주에 바로 검토할 만합니다. 범위가 좁은 풀과 위험도가 낮은 저장소로 시작하십시오. 실행 위치가 이동해도 모델 처리와 반환되는 툴 데이터는 남으므로 보안 검토에 반드시 포함해야 합니다.

필요한 것이 비공개 소스 제어나 내부 서비스 접근뿐이라면 도입을 서두르지 않는 편이 좋습니다. Cursor는 워커 팜을 직접 운영하기 전에 관리형 환경, 네트워크 제어, Tailscale, AWS PrivateLink 또는 Cloudflare Tunnel을 먼저 시도할 것을 권장합니다. 이 방법들은 호스트 수명 주기와 격리 책임을 Cursor에 그대로 둡니다.

관리형 Cloud Agents가 이미 정책을 통과하고 빌드도 재현한다면 영향을 받지 않습니다. 셀프 호스팅으로 새로운 모델 기능이 생기는 것은 아닙니다. 달라지는 것은 실행 위치와 운영 책임입니다.

바로 실행할 다음 단계는 구체적입니다. 대표 저장소 하나를 고르고 코드, 시크릿, 툴 출력, 아티팩트 중 어떤 항목이 경계를 넘어도 되는지 적습니다. 그런 다음 동일한 빌드를 관리형 에이전트와 용량을 엄격히 제한한 셀프 호스팅 풀에서 각각 실행합니다. 대기열 대기 시간, 컨테이너 사용 시간, 승인된 변경 사항, 정리 실패, 이미지 유지 관리에 든 시간을 기록하십시오. 통제 요건의 가치가 두 번째 비용 청구를 감수할 만큼 클 때만 워커 팜을 승인해야 합니다.

실무자를 위한 다음 AI 워크플로 분석을 뉴스레터로 받아보세요.