Cursor changelog 03-25-26 기준
Team 플랜 이상 필수
Cursor 자체 호스팅 클라우드 에이전트 — 팀 플랜 아니면 안 됩니다
2026년 3월 25일, Cursor가 Self-hosted Cloud Agents를 정식 출시했습니다. “코드를 외부로 절대 보내지 않는다”는 문구가 눈에 띄지만, 공식 문서를 펼쳐보면 예외 조건이 하나 있습니다. 그리고 이 기능을 쓰려면 Team 플랜($40/user/월) 이상이 반드시 필요합니다.
Self-hosted Cloud Agents가 뭔가요?
Cursor의 Cloud Agents는 AI가 개발자의 컴퓨터 밖, 격리된 가상 머신(VM)에서 코드를 짜고 테스트까지 돌리는 기능입니다. 기존 클라우드 에이전트는 Cursor 서버에서 VM이 돌았는데, 이번에 나온 Self-hosted 버전은 팀 자체 서버나 노트북에서 워커(worker)를 직접 띄워 쓰는 방식입니다.
워커는 터미널, 파일 시스템, 브라우저를 갖춘 실행 환경입니다. Cursor 공식 블로그(2026.03.25)에는 이렇게 나옵니다. “코드베이스, 도구 실행, 빌드 아티팩트가 환경 밖으로 절대 반출되지 않습니다.” 금융·규제 업종처럼 코드가 외부로 나가면 안 되는 팀을 겨냥한 발표입니다.
작동 흐름은 단순합니다. 워커가 Cursor 클라우드에 아웃바운드 HTTPS(포트 443)로 연결을 열고, Cursor가 에이전트 루프를 돌리면서 “이 파일 열어”, “이 명령 실행해” 같은 도구 호출(tool call)을 워커에게 전달합니다. 실행은 워커, 즉 내 네트워크 안에서만 일어납니다. (출처: Cursor 공식 문서 cursor.com/docs/cloud-agent/self-hosted, 2026.03.25)
코드가 “절대” 안 나간다는 말의 예외
💡 공식 보안 문서와 실제 데이터 흐름을 같이 놓고 보니 이런 차이가 보였습니다
“코드가 네트워크 밖으로 나가지 않는다”는 표현은 정확하지만, 추론 단계에서 모델이 읽는 파일 청크는 Cursor 클라우드를 탄다는 사실이 공식 문서에 명시돼 있습니다.
공식 보안 섹션(cursor.com/docs/cloud-agent/self-hosted#security, 2026.03.25)에는 이렇게 나옵니다. “Only the file chunks the model reads during inference leave your network.” — 모델이 추론할 때 읽는 파일 청크만 네트워크를 빠져나간다는 뜻입니다. 빌드 산출물, 시크릿, 전체 레포지터리는 내부에 남지만, LLM이 참조하는 코드 조각은 Cursor 클라우드로 올라갑니다.
추론 루프 자체가 Cursor 클라우드에서 돌기 때문에 이건 구조적으로 피할 수 없습니다. 워커는 도구 실행만 담당하고, “어떤 파일을 읽을지”, “다음에 뭘 할지”는 Cursor 서버가 결정합니다. 코드 전체가 나가는 건 아니지만, 모델이 컨텍스트로 잡는 파일 청크는 네트워크를 탄다는 점에서 “코드가 절대 안 나간다”는 표현을 그대로 믿으면 곤란합니다.
Privacy Mode를 켜면 모든 모델 제공사에서 데이터 보존이 0이 됩니다. (출처: cursor.com/data-use) 하지만 추론 중 전송 자체를 막는 건 현재 구조상 불가능합니다. 규제 업종에서 도입하기 전에 이 부분을 법무·보안팀과 먼저 검토해야 합니다.
시작 조건 — Team 플랜과 세 가지 전제
공식 문서 Prerequisites 섹션에 조건 세 가지가 명시돼 있습니다. (출처: cursor.com/docs/cloud-agent/self-hosted#prerequisites, 2026.03.25)
| 조건 | 내용 | 비고 |
|---|---|---|
| 플랜 | Cursor Team 플랜 이상 | $40/user/월 — Pro로 불가 |
| 대시보드 설정 | 팀 어드민이 “Allow Self-Hosted Agents” 활성화 필요 | cursor.com/dashboard/cloud-agents |
| 레포지터리 | git 저장소 필수 (GitHub, GitLab, Bitbucket, 자체 호스팅 모두 가능) | 워커 시작 시 git remote URL 읽음 |
Pro 플랜($20/월)이나 무료 플랜으로는 아예 활성화 버튼 자체가 나오지 않습니다. 10인 팀이라면 최소 월 $400(약 58만원)이 기본 진입 비용입니다. 개인 개발자가 혼자 써보려고 시도하다가 막히는 지점이 바로 여기입니다.
CLI 설치 후 워커를 시작하는 명령어는 agent worker start 하나입니다. 네트워크 쪽에서 필요한 건 포트 443 아웃바운드뿐이고, 인바운드 포트 개방이나 방화벽 변경은 없어도 됩니다. 프록시 환경이라면 HTTPS_PROXY 환경변수만 잡아주면 워커가 그걸 그대로 씁니다.
지금 당장 안 되는 기능 4가지
💡 “동일한 기능”이라는 표현 뒤에 붙은 단서를 공식 문서에서 직접 확인했습니다
공식 발표에는 “Cursor 호스팅 클라우드 Agent와 동일한 기능을 제공한다”고 나오지만, 문서 하단 Coming soon 섹션에는 자체 호스팅 버전에서 아직 작동하지 않는 기능 목록이 따로 있습니다.
공식 문서 “Coming soon” 섹션(cursor.com/docs/cloud-agent/self-hosted#coming-soon, 2026.03.25)에 다음 네 가지가 명시돼 있습니다.
Automations
Slack·GitHub 연동 자동 트리거 불가
Computer use
에이전트가 GUI 직접 조작 불가
Artifacts
작업 결과 동영상·스크린샷 생성 불가
Multi-repo support
여러 레포지터리 동시 작업 불가
이 중 가장 아쉬운 건 Automations 미지원입니다. Cursor 클라우드 에이전트의 핵심 활용 사례가 “Slack에서 명령하면 PR을 자동으로 만들어 주는 것”인데, 자체 호스팅 버전에서는 지금 시점에 이 워크플로우를 구성할 수 없습니다. Money Forward가 슬랙 연동 워크플로우를 구축 중이라고 발표문에서 언급했지만, 이는 Cursor 호스팅 에이전트 기준입니다.
Computer use 미지원도 중요합니다. 2026년 2월 24일에 발표된 클라우드 에이전트의 핵심 기능이 GUI 조작 기능이었는데(출처: cursor.com/ko/changelog/02-24-26), 자체 호스팅에서는 이 기능이 아직 없습니다. 동일한 기능이라는 표현을 곧이곧대로 받아들이면 안 됩니다.
Brex·Money Forward·Notion은 왜 골랐나
Cursor 공식 발표문에 세 곳의 실사용 인용이 담겨 있습니다. 규제 금융사 Brex, 일본 금융 서비스 Money Forward, 그리고 대규모 코드베이스를 운영하는 Notion입니다. 세 곳의 공통점이 있습니다. 내부 인프라에 접근이 필요한 팀이라는 것입니다.
Brex의 그레이엄 풀러는 이렇게 말했습니다. “Cursor 클라우드 에이전트가 코드베이스 맥락을 이해한 상태에서 코드를 쓰는 데 매우 뛰어나다. 이제 자체 호스팅으로 테스트 스위트를 돌리고 내부 도구로 변경 사항을 검증하는 데 필요한 인프라 접근 권한을 줄 수 있게 됐다.” (출처: cursor.com/ko/blog/self-hosted-cloud-agents, 2026.03.25)
Money Forward의 SRE 부관리자는 “거의 1,000명의 엔지니어가 작업할 수 있게 된다”고 밝혔습니다. 이게 중요한 이유는 따로 있습니다. 1,000명 × $40 = 월 $40,000(약 5,800만원)입니다. 자체 호스팅의 진짜 목적이 비용 절감이 아니라 규정 준수(compliance)임을 보여주는 숫자입니다.
Notion의 벤 크래프트는 “자체 클라우드 환경에서 에이전트 워크로드를 실행함으로써 에이전트가 더 많은 도구에 더 안전하게 접근할 수 있고, 여러 스택을 직접 유지 관리해야 하는 부담도 줄 수 있다”고 했습니다. 핵심 가치는 보안이 아니라 인프라 접근성입니다. 캐시, 의존성, 내부 네트워크 엔드포인트에 자유롭게 닿을 수 있다는 점이 더 큰 이유입니다.
Kubernetes 없이도 쓸 수 있는 조건
발표 자료를 보면 Helm chart와 Kubernetes operator 얘기가 나와서 “우리는 K8s 없으니 못 쓰겠네”라는 반응이 자연스럽게 나옵니다. 하지만 공식 문서에 따르면 Kubernetes는 수천 개의 워커로 확장하는 조직을 위한 옵션이지, 필수 조건이 아닙니다.
K8s 없는 환경에서는 Fleet management API로 워커 가동 현황을 모니터링하고 오토스케일링을 직접 구성할 수 있습니다. 단순하게는 개발자 노트북이나 devbox 위에서 agent worker start 한 줄만 실행해도 그 자체가 하나의 워커가 됩니다. (출처: cursor.com/docs/cloud-agent/self-hosted#running-a-worker, 2026.03.25)
워커는 두 가지 모드로 운용할 수 있습니다. Long-lived 모드는 워커를 켜 두고 계속 세션을 받는 방식으로 devbox나 팀 전용 머신에 적합합니다. Ephemeral 모드는 --single-use 플래그로 세션 하나 처리 후 자동 종료합니다. K8s에서 클린 환경을 유지할 때 쓰는 패턴이지만, 작은 팀에서도 오염되지 않은 환경이 필요할 때 유용합니다.
Prometheus 메트릭 엔드포인트(GET /metrics)도 제공합니다. 워커가 현재 세션을 처리 중인지(cursor_self_hosted_worker_session_active), 클라우드와 연결돼 있는지(cursor_self_hosted_worker_connected)를 게이지로 확인할 수 있어서, 기존 모니터링 스택에 붙이기 어렵지 않습니다.
자주 묻는 것들
마치며
Cursor Self-hosted Cloud Agents는 금융·규제 업종 팀에게 실질적인 의미가 있는 기능입니다. 내부 캐시·의존성·네트워크 엔드포인트에 에이전트가 닿을 수 있다는 점, 그리고 인프라 자체를 팀이 통제한다는 점이 핵심 가치입니다.
다만 “코드가 절대 안 나간다”는 문구를 완전한 데이터 격리로 받아들이면 곤란합니다. 추론 단계에서 파일 청크는 여전히 Cursor 클라우드를 탑니다. 이 부분은 규제 검토 전에 반드시 짚어야 합니다. Automations, Computer use, Artifacts, Multi-repo 네 가지 미지원 기능도 도입 전에 확인해야 할 체크포인트입니다.
개인 개발자나 소규모 팀에게는 $40/user/월이라는 Team 플랜 장벽이 현실적인 걸림돌입니다. Kubernetes 없이도 노트북이나 devbox에서 바로 시작할 수 있다는 점은 장점이지만, 비용과 미지원 기능을 함께 따져봐야 합니다. 기능이 완성되는 시점을 보고 판단해도 늦지 않습니다.
📎 본 포스팅 참고 자료
- Cursor 공식 블로그 — Self-hosted Cloud Agents 발표 (2026.03.25)
https://cursor.com/ko/blog/self-hosted-cloud-agents - Cursor 공식 문서 — Self-Hosted Cloud Agents (2026.03.25)
https://cursor.com/docs/cloud-agent/self-hosted - Cursor Changelog 03-25-26
https://cursor.com/changelog/03-25-26 - Cursor Cloud Agents — Computer Use 발표 (2026.02.24)
https://cursor.com/ko/changelog/02-24-26 - Cursor 데이터 사용 및 Privacy Mode 정책
https://cursor.com/data-use
본 포스팅은 2026년 3월 27일 기준 Cursor 공식 문서·블로그·changelog를 토대로 작성됐습니다. 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. Cursor는 빠른 속도로 업데이트가 이루어지는 서비스이므로, 요금제·지원 기능·보안 정책은 반드시 공식 문서에서 재확인하세요.
댓글 남기기