Cursor가 9월 2일 '셀프호스트 머신(Self-Hosted Machines)' 기능을 확장했어요. 클라우드 에이전트가 실제로 코드를 만지고 명령을 실행하는 부분을, 커서 서버가 아니라 팀이 직접 관리하는 인프라 안에서 돌릴 수 있게 한 겁니다.
지금까지 Cursor의 클라우드 에이전트는 커서가 관리하는 샌드박스 위에서 작업을 실행했어요. 코드, 빌드 결과물, 시크릿 키 같은 것들이 잠깐이라도 회사 네트워크 밖으로 나간다는 뜻이었죠. 보안·컴플라이언스가 까다로운 금융·의료·공공 쪽 팀들에게는 이게 꽤 큰 장벽이었습니다.
뭐가 달라지나
개인용으로는 노트북이나 VM 한 대를 계정에 연결해 쓰는 'My Machines'가 있고, 팀 단위로는 여러 워커를 묶은 'Team Pools'를 만들 수 있어요. 요청이 몰리면 자동으로 늘어나고 워커 연결이 끊기면 줄어드는 오토스케일링도 붙었고, 쓰지 않는 머신은 잠들었다가 다음 요청이 오면 다시 깨어나는 하이버네이션도 지원합니다. AWS Lambda, Cloudflare, Modal, Vercel, E2B, Daytona, Namespace, Coder 등 이미 쓰고 있는 인프라 위에서 바로 돌릴 수 있고요. 리눅스·맥에서의 컴퓨터 유즈(화면 제어)도 셀프호스트 워커에서 지원하기 시작했습니다.
바이브코더 입장에서 제일 크게 와닿는 건, 이제 "에이전트는 쓰고 싶은데 코드는 절대 밖으로 못 내보낸다"는 팀도 Cursor 클라우드 에이전트를 정식으로 쓸 수 있는 길이 열렸다는 점이에요. 개인 개발자도 굳이 커서의 공용 클라우드 샌드박스 대신 자기 컴퓨터나 개인 VM에서 실행되게 붙여둘 수 있고요.
한계도 있어요. 실제로 로컬에서 도는 건 '실행(execution)' 부분뿐이고, 에이전트의 계획을 세우고 추론하는 부분은 여전히 Cursor 클라우드에서 처리됩니다. 즉 프롬프트나 작업 계획 자체는 외부로 나가는 구조라, 완전한 에어갭 솔루션은 아니에요.
댓글 0
첫 댓글을 남겨보세요!