Cursor Self-Hosted Machines 개인정보 보호 검토 (2026)

방화벽 뒤에 워커를 둔다고 해서 소스 코드 일부, 터미널 출력, diff, 스크린샷까지 모두 내부에 남는 것은 아닙니다. Cursor Self-Hosted Machines는 실행 환경을 직접 운영하는 기능이지, 에이전트 전체를 셀프 호스팅하거나 Cursor를 에어갭 환경에 배포하는 기능이 아닙니다.

이 글에서는 무엇이 경계를 넘어가고 각 제어 기능이 실제로 무엇을 바꾸는지 살펴봅니다. 기준 자료는 Cursor의 2026년 9월 2일 발표, Self-Hosted Machines 문서, 그리고 데이터 이용 정책입니다.

데이터 경계를 한눈에 보는 표

Cursor는 Cloud Agent 작업을 자사가 운영하는 클라우드와 사용자가 관리하는 워커로 나눕니다. 여기서 ‘Self-Hosted’는 실행 위치를 가리킬 뿐, 모든 시스템과 데이터 경로가 사용자 환경에 있다는 뜻은 아닙니다.

핵심은 간단합니다. 전체 저장소를 사용자 머신에 그대로 둘 수는 있지만, 추론에 필요한 일부 컨텍스트는 네트워크를 통해 오갈 수 있습니다. 즉, 실행 위치에 대한 통제는 강화되지만 외부 전송이 전혀 없는 구조는 아닙니다.

Cursor가 실제로 사용자 인프라로 옮기는 것

Self-Hosted Machines는 도구 실행을 고객이 제어하는 머신으로 옮깁니다. 워커는 파일을 수정하고, 명령을 실행하고, 내부 서비스에 접근하고, 브라우저를 조작하고, 로컬 MCP 서버에 연결할 수 있습니다. 반면 에이전트 루프, 추론, 계획 수립, 세션 오케스트레이션은 Cursor 클라우드에 남습니다.

워커는 Cursor CLI 명령인 agent worker start로 시작합니다. 이후 Cursor와 장시간 유지되는 아웃바운드 HTTPS 연결을 엽니다. Cursor에 따르면 연결은 워커에서 외부로 나가는 방식이며, 인바운드 포트나 공인 IP 주소, VPN 터널은 필요하지 않습니다.

문서에 설명된 세션 흐름은 다음과 같습니다.

1. Cursor 인터페이스에서 Cloud Agent 세션이 시작됩니다.
2. Cursor의 클라우드 에이전트 루프가 다음 작업을 계획합니다.
3. Cursor가 워커 연결을 통해 도구 호출을 보냅니다.
4. 워커가 명령, 편집, 브라우저 작업 또는 MCP 작업을 실행합니다.
5. 워커가 다음 추론 단계에 필요한 결과를 반환합니다.

워커는 여전히 api2.cursor.sh와 api2direct.cursor.sh에 대한 아웃바운드 접근이 필요합니다. CLI 업데이트와 일부 컴퓨터 사용 설정에는 downloads.cursor.com도 필요할 수 있습니다. 아웃바운드 전용 설계 덕분에 사용자 네트워크로 들어오는 접근은 피할 수 있지만, 그렇다고 워커가 오프라인 모델 런타임이 되는 것은 아닙니다.

Cursor는 이 구조가 비공개 저장소나 호스팅 워커에서 접근할 수 없는 서비스, GPU나 Mac 같은 특수 하드웨어, 맞춤형 운영체제와 빌드 이미지에 적합하다고 설명합니다. 요구사항이 단순히 비공개 연결이라면 Cursor의 런타임 선택 가이드는 먼저 allowlist를 적용한 관리형 Cloud Agents, Tailscale과 유사한 네트워킹, AWS PrivateLink 또는 Cloudflare Tunnel을 검토하라고 안내합니다.

워커 밖으로 나갈 수 있는 데이터와 Privacy Mode의 역할

Cursor 문서에는 워커가 전송할 수 있는 데이터로 파일 내용, 터미널 출력, diff, 스크린샷, 로컬 MCP 결과, 라우팅 메타데이터가 명시돼 있습니다. 개인정보 보호를 검토할 때는 세 가지를 나눠 봐야 합니다. 무엇이 전송되는지, 학습에 사용되는지, 얼마나 오래 보관되는지입니다.

Privacy Mode는 학습 제어 기능이지 외부 전송 차단 스위치가 아니다

2026년 8월 28일 업데이트된 Cursor의 Data Use & Privacy Overview에 따르면 Privacy Mode는 Customer Data가 Cursor의 모델 학습에 사용되지 않도록 합니다. 또한 Cursor는 제공업체와 데이터 보관 기간을 0으로 하는 계약을 유지한다고 설명합니다. 다만 같은 페이지에는 예외도 적혀 있습니다. 위험 분류기는 조사 목적으로 프롬프트나 대화를 보관할 수 있고, 지연 시간과 네트워크 효율을 위해 파일이 일시적으로 캐시될 수 있습니다.

Cursor는 캐시된 파일이 클라이언트가 생성한 키로 암호화되며, 요청이 처리되는 동안 해당 키를 자사 서버에 보관한다고 설명합니다. 이는 Cursor가 제시하는 보관 및 보호 방식에 대한 설명이지, 요청이 Cursor 서버에 도달하지 않는다는 근거는 아닙니다.

API 키 사용 방식도 중요합니다. Cursor는 사용자가 직접 발급받은 제공업체 API 키를 사용하더라도 요청이 최종 프롬프트 구성을 위해 Cursor를 거치므로 백엔드를 우회하지 않는다고 밝힙니다. BYOK는 모델 사용을 누가 승인하는지를 바꿀 수 있지만, 클라이언트에서 제공업체로 직접 연결되는 개인정보 보호 경로로 이해해서는 안 됩니다.

한 사용자가 이 기능을 검토하면서 같은 아키텍처상의 차이를 짚었습니다.

“중요한 경계는 이렇습니다. Cursor의 셀프 호스팅 머신은 에이전트 전체가 아니라 실행 환경을 옮깁니다. Cursor에 따르면 추론과 계획 수립은 클라우드에 남고, 코드가 포함될 수 있는 도구 출력은 다시 전송됩니다. 보안 검토에서는 이를 셀프 호스팅 에이전트가 아니라 셀프 호스팅 실행 환경으로 봐야 합니다.” — @ham_zax, X

아티팩트 차단 설정은 데이터 에어갭이 아니다

Cursor는 아티팩트 업로드를 막는 제한적인 방법으로 cloud-agent-artifacts.s3.us-east-1.amazonaws.com에 대한 아웃바운드 HTTPS 트래픽 차단을 안내합니다. 도구 호출과 도구 결과는 계속 작동하지만, 스크린샷과 동영상, 로그 참조는 풀 리퀘스트나 Cursor 대시보드에 표시되지 않습니다.

시각적 아티팩트가 필요하지 않은 조직이라면 유용한 설정입니다. 하지만 완전한 개인정보 보호 대책은 아닙니다. 추론 과정에서 사용된 파일 내용, 터미널 출력, diff, 스크린샷, MCP 결과는 여전히 에이전트 세션 연결을 통해 반환될 수 있기 때문입니다.

MCP 전송 방식도 별도로 살펴봐야 합니다. Cursor의 Team Pools 문서에 따르면 명령 기반, 즉 stdio 방식의 MCP 서버는 워커에서 실행되며 비공개 네트워크에 접근할 수 있습니다. 반면 HTTP/SSE MCP 서버는 OAuth, 세션 캐싱, 인증을 위해 Cursor 백엔드에서 처리됩니다. 따라서 비공개 MCP 엔드포인트는 호스트 위치만이 아니라 전송 방식을 함께 검토해야 합니다.

라벨이 아니라 실제 제약 조건으로 런타임을 선택하라

Cursor는 세 가지 런타임 선택지를 제공합니다. 실행 경계, 하드웨어, 환경이 단순한 선호가 아니라 문서화된 요구사항일 때 Self-Hosted Machines가 가장 잘 맞습니다.

요구사항이 비공개 접근뿐이라면 관리형 Cloud Agents를 선택하라

조직의 경계를 저장소 권한, 네트워크 allowlist, Tailscale과 유사한 클라이언트, 지원되는 비공개 연결 방식으로 정의할 수 있다면 관리형 Cloud Agents로 충분할 수 있습니다. Cursor의 런타임 가이드는 대부분의 팀에 관리형 인프라를 권장하며, 운영 부담이 낮은 경로로 설명합니다.

이 방식을 사용하면 워커 풀을 직접 운영하지 않으면서 Cursor가 관리하는 VM 수명 주기와 탄력적인 동시성을 활용할 수 있습니다. 다만 관리형 에이전트가 데이터를 전혀 다루지 않는다는 뜻은 아닙니다. 실행 환경을 팀이 아니라 Cursor가 운영한다는 의미입니다.

한 명의 사용자와 하나의 통제된 환경이라면 My Machines

My Machines는 개인 머신을 개별 Cursor 계정에 연결합니다. 이미 필요한 의존성과 네트워크 접근 권한을 갖춘 Mac, devbox, 원격 VM이 있고 이를 다른 환경에 다시 구성하기 번거롭다면 실용적인 선택입니다.

대신 운영 부담은 사용자가 집니다. 활성 세션 동안 머신이 온라인 상태여야 하며, 정리 작업, 체크아웃의 최신 상태, 디스크 상태, 자격 증명, 의존성 복구도 사용자가 관리해야 합니다. Cursor의 셀프 호스팅 문서는 한 머신에서 여러 에이전트를 실행할 수 있다고 설명하지만, 이는 중앙화된 팀 워커 풀 모델과는 다릅니다.

운영 부담을 감수할 가치가 있을 때만 Team Pools를 선택하라

Team Pools는 Enterprise 팀을 대상으로 합니다. 서비스 계정 인증, 공유 워커 용량, 라벨, 컨트롤러 기반 확장을 사용합니다. gpu 풀은 GPU 머신으로 작업을 보낼 수 있고, ios 풀은 Mac으로 라우팅할 수 있습니다. Cursor는 사용자당 최대 200개 워커, 팀당 1,000개 워커를 문서화하고 있으며, 그보다 큰 배포에는 별도의 확장 논의가 필요하다고 안내합니다.

풀은 0개까지 축소할 수 있고, 영구 워커, 컨테이너, Kubernetes, 파트너 호스팅 워커를 사용할 수 있습니다. Cursor는 해제된 워크스페이스를 복원하는 데 몇 분이 걸릴 수 있다고 설명합니다. 변동이 큰 작업에는 유연하지만, 이미지 관리, 워커 초기화, 용량 계획, 비밀 정보 교체, 모니터링은 고객의 책임으로 넘어옵니다.

비용은 인프라 비용과 모델 사용량을 함께 봐야 한다

Self-Hosted Machines 문서와 Cursor Models & Pricing 페이지는 모델, 요금제, 인프라에 대한 책임을 설명하지만 Self-Hosted Machines에 별도로 부과되는 워커당 요금은 명시하지 않습니다. 문서에 제시된 비용 구조는 Cursor를 통해 선택한 모델 사용료를 계속 지불하면서, 추가로 직접 운영하는 머신, 컨테이너, 클러스터, 스토리지, 네트워크, 모니터링, 운영 비용을 부담하는 방식입니다.

따라서 특별한 네트워크나 하드웨어 요구사항이 없다면 셀프 호스팅을 비용 절감 수단으로 내세우기는 어렵습니다. 동적 풀과 최대 절전은 유휴 컴퓨팅 비용을 줄일 수 있지만, 손익분기점은 작업 형태, 시작 시간, 재구축해야 하는 상태의 규모에 따라 달라집니다. Cursor는 모든 환경에 적용할 수 있는 단일 수치를 공개하지 않습니다.

활성화 전에 확인할 보안 검토 체크리스트

‘셀프 호스팅’이라는 단어 자체를 승인 신호로 보지 말고, 보안·플랫폼·컴플라이언스 담당자와 함께 다음 항목을 확인하세요.

1. 경계 요구사항을 구체적으로 작성하세요. 전체 체크아웃, 도구 실행, 자격 증명, 추론 요청, 아티팩트 중 무엇을 또는 전부를 경계 내부에 남겨야 하는지 결정해야 합니다. Self-Hosted Machines가 사용자 통제 아래 두는 것은 실행 워커와 로컬 전체 상태입니다.
2. 반환되는 컨텍스트를 분류하세요. 파일 내용, diff, 터미널 출력, 스크린샷, MCP 결과가 Cursor로 전송될 수 있습니다. 이런 출력에 소스 코드, 고객 데이터, 토큰, 내부 URL, 운영 환경 응답이 포함될 수 있는지 테스트해야 합니다.
3. Privacy Mode를 의도적으로 활성화하세요. Cursor가 설명하는 학습 이용 및 제공업체 보관 정책을 바꾸지만, 요청 처리, 임시 캐싱, 위험 탐지 처리를 막지는 않습니다.
4. BYOK를 정확히 이해하세요. Cursor의 데이터 이용 페이지에 따르면 API 키를 사용해도 요청 경로에서 Cursor 백엔드가 빠지지 않습니다.
5. 아티팩트 외부 전송은 별도로 결정하세요. 풀 리퀘스트와 대시보드에 표시되는 스크린샷, 동영상, 로그 참조를 허용할지에 따라 cloud-agent-artifacts.s3.us-east-1.amazonaws.com을 허용하거나 차단하세요. 방화벽이 지원한다면 정확한 호스트 규칙을 사용하는 편이 좋습니다.
6. 아웃바운드 전용 allowlist를 사용하세요. 문서에 나온 Cursor 엔드포인트와 의도적으로 활성화한 업데이트 또는 컴퓨터 사용 호스트만 허용하세요. 워커에 인바운드 포트나 공인 IP가 필요해서는 안 됩니다.
7. MCP 전송 방식을 검토하세요. 비공개 서비스에 접근해야 하는 서버라면 워커 측 stdio MCP를 사용하고, 반환되는 결과까지 평가하세요. HTTP/SSE MCP 엔드포인트는 서비스가 비공개라는 이유만으로 네트워크 내부에 남는다고 가정해서는 안 됩니다.
8. 워커를 격리하고 초기화하세요. Team Pools에서는 에이전트 간 머신을 어떻게 삭제하거나 재생성할지, 자격 증명을 어떻게 주입할지, 로그를 어떻게 모니터링할지 정해야 합니다. Cursor의 가이드와 템플릿은 참고 아키텍처이지, 완전히 관리되는 프로덕션 워커 풀은 아닙니다.
9. 장애 상황을 테스트하세요. Cursor 엔드포인트, 아티팩트 저장소, 워커, 비공개 레지스트리, MCP 서버 중 하나를 사용할 수 없을 때 어떤 일이 발생하는지 확인하세요. 아티팩트 호스트 차단을 에이전트 세션 차단과 혼동해서는 안 됩니다.
10. 에어갭 워크로드에는 사용하지 마세요. 모델 컨텍스트를 외부로 전송하지 않거나 서드파티 클라우드 추론을 사용하지 않아야 한다면 이 아키텍처는 요구사항을 충족하지 못합니다. 에이전트 루프는 여전히 Cursor 클라우드에 있습니다.

Cursor Self-Hosted Machines 개인정보 보호 FAQ

Cursor Self-Hosted Machines는 완전히 셀프 호스팅되나요?

아닙니다. 에이전트 루프, 추론, 계획 수립, 오케스트레이션은 Cursor 클라우드에 남습니다. 사용자 머신은 도구 실행과 로컬 작업 상태를 호스팅합니다.

소스 코드가 셀프 호스팅 머신 밖으로 나가나요?

선택된 파일 내용, diff, 터미널 출력, 스크린샷, 로컬 MCP 결과는 에이전트의 입력이나 도구 결과로 워커 밖으로 나갈 수 있습니다. Cursor는 전체 체크아웃과 빌드 캐시는 워커에 남는다고 설명하므로, 경계는 전부 또는 전무가 아니라 부분적입니다.

Privacy Mode가 네트워크를 통한 데이터 전송을 막나요?

아닙니다. Privacy Mode는 Cursor가 설명한 보관 정책에 따라 Cursor와 모델 제공업체의 학습 이용을 막는 기능입니다. 추론에 필요한 컨텍스트를 워커가 전송하는 것까지 차단하지는 않습니다.

BYOK로 Cursor를 우회할 수 있나요?

아닙니다. Cursor의 데이터 이용 페이지에 따르면 API 키 요청도 최종 프롬프트 구성을 위해 Cursor 백엔드를 거칩니다. BYOK를 워커에서 모델 제공업체로 직접 연결하는 방식으로 봐서는 안 됩니다.

스크린샷과 동영상 업로드를 막을 수 있나요?

cloud-agent-artifacts.s3.us-east-1.amazonaws.com에 대한 아웃바운드 접근을 차단할 수 있습니다. 도구 실행은 계속되지만 아티팩트는 풀 리퀘스트나 Cursor 대시보드에 표시되지 않습니다. 다른 에이전트 세션 데이터는 여전히 Cursor로 반환될 수 있습니다.

워커에 인바운드 방화벽 규칙이나 VPN이 필요한가요?

Cursor는 아웃바운드 HTTPS 모델을 문서화하고 있습니다. 인바운드 포트, 공인 IP, VPN 터널은 필요하지 않다고 설명하지만, 워커는 문서에 나온 Cursor 엔드포인트와 필요한 서비스에 대한 아웃바운드 접근 권한을 확보해야 합니다.

개인 요금제나 하위 요금제에서 Team Pools를 사용할 수 있나요?

Cursor 문서는 Team Pools를 Enterprise용으로 설명하며 서비스 계정 API 키를 요구합니다. 개인 워커에는 My Machines가 해당합니다. 개인 API 키로 Team Pool 워커를 시작할 수 있다고 가정해서는 안 됩니다.

Cursor Self-Hosted Machines를 완전히 오프라인으로 실행할 수 있나요?

아닙니다. 에이전트 루프와 추론은 Cursor 클라우드에 남고, 워커에는 아웃바운드 연결이 필요합니다. 오프라인 또는 에어갭 요구사항에는 오케스트레이션과 모델 추론을 로컬에서 호스팅하는 다른 아키텍처가 필요합니다.

고객이 통제하는 실행 환경, 비공개 네트워크 접근, 맞춤형 하드웨어, 지속적인 환경이 필요하다면 Cursor Self-Hosted Machines를 고려할 만합니다. 하지만 AI 트래픽 자체가 클라우드 밖으로 나가서는 안 된다면 다른 설계를 선택해야 합니다. 이 기능이 바꾸는 것은 명령이 실행되는 위치이지, 에이전트가 생각하는 위치가 아니기 때문입니다.