직접 관리하는 머신에서 클라우드 Agent 실행하기
Cursor 클라우드 Agent를 사내 네트워크 안에서 동적으로 스케줄링되는 머신 풀에서 실행할 수 있습니다. 기반 인프라는 직접 관리하면서도, 에이전트의 시작과 관리는 그대로 Cursor에서 이루어집니다.
이를 통해 팀은 에이전트가 어디에서 실행되고 어떤 인프라를 사용할지 더 세밀하게 제어할 수 있습니다. 에이전트는 내부 서비스나 소스 컨트롤 바로 옆에서 작업하고, 맞춤형 하드웨어에서 실행되며, 클라우드 Agent 빌드로 패키징하기 어려운 운영체제나 빌드 파이프라인도 사용할 수 있습니다.
현재 Cursor 내부에서 병합하는 풀 리퀘스트의 60% 이상을 클라우드 Agent가 만들고 있으며, 저희와 함께하는 대규모 기업들에서도 에이전트가 맡는 소프트웨어 작업의 비중이 꾸준히 커지고 있습니다. 에이전트의 역할이 커질수록 이들이 실행되는 머신 역시 그만큼 중요해집니다. 이번에 추가된 기능은 팀이 그러한 인프라를 대규모로 제공하고 관리하는 일을 현실적으로 가능하게 해줍니다.
Lambda MicroVM을 Cursor 클라우드 Agent의 컴퓨트 계층으로 사용하면, 개발자는 자신의 AWS 계정에서 AI 기반 코딩 에이전트를 실행할 수 있습니다. 각 머신은 스냅샷에서 거의 즉시 시작되고, 유휴 상태에서는 일시 중단되며, 전체 상태를 그대로 유지한 채 재개됩니다. 코딩 에이전트는 Lambda의 빠른 시작 속도, 강력한 격리, 군 관리 부담이 전혀 없다는 이점을 누리고, 작업의 오케스트레이션은 Cursor가 담당합니다.
에이전트 실행 위치 제어하기
클라우드 Agent의 기본값은 여전히 Cursor 호스팅 환경입니다. 각 세션은 Cursor 클라우드 내 전용 VM에서 실행되며, 의존성이 설치된 상태로 자체 네트워크 제어를 갖습니다. 에이전트별 격리, 시크릿 마스킹, 이그레스 제어, 서명된 커밋은 대부분의 팀이 요구하는 보안 요건을 충족합니다.
팀이 일반적으로 Self-Hosted Machines를 사용하는 경우는 다음과 같습니다:
- 에이전트의 도구 실행이 자사 네트워크 내부에서 이루어져야 하고, 소스 컨트롤, 내부 서비스, 코드 리포지토리에 직접 접근해야 하는 경우.
- 에이전트에 GPU나 iOS 개발용 Mac 같은 맞춤형 하드웨어, 또는 Kubernetes, 샌드박스, 관리형 VM 같은 인프라가 필요한 경우.
- 운영 체제나 빌드 파이프라인을 Cloud Agent 빌드로 패키징하기 어려운 경우.
Self-Hosted Machines에서는 실행 환경만 옮겨갈 뿐, 에이전트 루프와 추론, 계획은 그대로 Cursor 클라우드에 남습니다. 도구 출력은 추론을 위해 Cursor로 다시 전달되며 코드가 포함될 수 있고, 에이전트 트랜스크립트는 Cursor에서 처리 및 저장될 수 있습니다. 팀은 데스크톱 앱, cursor.com, 모바일, Slack, GitHub, Linear에서 계속 클라우드 Agent를 이용할 수 있습니다.
워커가 여러분의 인프라를 Cursor 에이전트 루프에 연결합니다
Self-Hosted Machines를 사용하면 도구 실행이 Cursor가 호스팅하는 VM에서 여러분 환경의 머신으로 옮겨집니다. 이 머신이 리포지토리의 작업 사본을 보관하고, 파일을 수정하며, 명령을 실행합니다. 워커는 이 머신을 나머지 에이전트 시스템과 이어주는 역할을 합니다.
머신을 등록하려면 Cursor CLI를 설치하고 agent worker start를 실행해 워커를 띄우면 됩니다. 그러면 Cursor 클라우드로 향하는 장기 유지 아웃바운드 HTTPS 연결이 열립니다. 세션이 시작되면 Cursor의 agent harness가 추론과 계획을 처리한 뒤, 실행을 위해 전용 워커로 tool call을 보냅니다. 워커는 다음 추론에 쓰일 결과를 돌려줍니다. Cursor가 여러분의 네트워크로 먼저 연결을 시도하는 일은 없습니다.
워커는 두 가지 방식으로 설정할 수 있습니다.
- My Machines. 노트북이나 VM 한 대를 여러분의 계정에 연결하는 방식으로, 개인 워크플로우에 가장 적합합니다.
- Pools. 풀은 팀이나 기업 단위로 사용할 수 있는, 이름이 지정된 워커 큐입니다. 요청이 들어오면 역량이 늘어나고 워커가 연결을 끊으면 줄어들기 때문에, 기존 클라우드 인프라를 개발자 수요에 맞춰 확장할 수 있습니다.
개발자는 자신의 워크플로우를 가장 잘 뒷받침하는 플랫폼에서 코딩 에이전트를 실행할 수 있는 유연성을 가져야 하고, 기업은 에이전트가 어디에서 실행되고 무엇에 접근할 수 있는지에 대한 통제권을 양보할 필요가 없어야 합니다. 개발의 미래는 안전하고 격리된 환경에서 실행되는 강력한 에이전트 위에 세워질 것입니다.
인프라에 맞춰 적응하는 클라우드 Agent
이제 워커 풀이 대기 중인 요청에 따라 확장되고, 어떤 리포지토리의 작업이든 처리할 수 있습니다. 또한 여러 샌드박스 provider와 함께 Mac에 이어 Linux에서의 computer use도 지원합니다.
풀은 수요에 따라 확장되며 모든 리포지토리를 지원합니다
클라우드 Agent 수요는 한꺼번에 몰리는 경우가 많은데, Self-Hosted Machines 풀은 이러한 급증에 자동으로 대응합니다. 요청 큐를 감시하다가 팀이 제공한 spawn 스크립트로 필요한 만큼 머신을 시작하는 컨트롤러가 이를 처리합니다.
풀에 사용 가능한 워커가 있으면 해당 워커가 요청을 가져갑니다. 없으면 요청은 여유 역량이 생길 때까지 대기하므로, 팀이 머신을 몇 대나 계속 실행해 둘지 고민할 필요가 없습니다.
팀은 워커 연결마다 유휴 시간 초과를 설정할 수 있습니다. 시간이 만료되면 머신은 초기화되어 다시 풀로 돌아갑니다. 에이전트가 후속 요청을 받을 경우에 대비해 워크스페이스를 그대로 보존할 수도 있습니다.
Self-Hosted Machines 덕분에 팀이 Cursor 에이전트를 어디서 실행할지 직접 통제할 수 있고, Vercel Sandbox는 이를 손쉽게 만들어 줍니다. 모든 작업이 필요할 때마다 격리된 샌드박스를 받으니, 관리할 군도 없고 유휴 상태로 놀고 있는 자원도 없습니다.
에이전트가 유휴 상태인 동안 머신을 계속 실행해 두면 비용 부담이 커집니다. 그렇다고 머신을 해제하면 후속 요청이 도착했을 때 에이전트가 워크스페이스를 다시 구성하는 데 몇 분이 걸릴 수 있습니다. 하이버네이션을 사용하면 유휴 머신을 스냅샷으로 저장한 뒤 중지할 수 있습니다. 재연결 시간 내에 후속 요청이 도착하면 스냅샷이 복원되고 동일한 ID로 워커가 시작됩니다. 그렇지 않으면 요청은 새 머신으로 넘어갑니다.
풀은 개별 리포지토리에 묶여 있지 않습니다. 요청은 풀만 식별하면 되고, 사용 가능한 워커라면 어떤 워커든 이를 가져갈 수 있습니다. 덕분에 풀 하나로 여러 리포지토리를 지원할 수 있습니다.
워커는 지원되는 샌드박스 provider 전반에서 실행됩니다
Self-Hosted Machines는 맞춤형 샌드박스 계층을 처음부터 만들 필요가 없습니다. Cursor는 AWS Lambda, Cloudflare, Coder, Daytona, E2B, Modal, Namespace, Vercel과 협력하고 있어, 팀의 샌드박스가 이미 실행 중인 환경이라면 어디서든 워커를 시작하고 오케스트레이션할 수 있습니다.
Modal에서 실행되는 Cursor Self-Hosted Machines는 각 클라우드 Agent 세션에 Modal Sandbox를 제공하므로, 작업에 딱 맞게 구성된 머신을 에이전트에 맡길 수 있습니다.
Agent가 Linux와 Mac에서 브라우저를 제어합니다
이제 Mac에 이어 Linux 워커에서도 computer use를 지원합니다. Chrome 또는 Chromium을 비롯해 필요한 computer use 의존성이 설치되어 있으면 에이전트가 클릭하고 스크린샷을 찍고 브라우저를 제어할 수 있습니다. Cursor에서 바로 에이전트의 데스크톱을 지켜보거나 제어권을 넘겨받을 수도 있습니다.
Mac 없이는 iOS나 macOS 앱을 만들 수 없습니다. Namespace Devboxes는 Cursor 클라우드 Agent마다 실제 Mac을 띄워주며, 이제 Apple silicon에서 그 작업을 수행할 수 있습니다.
클라우드 Agent를 여러분의 환경으로
여러 팀이 소프트웨어를 만드는 방식에 맞춰 인프라를 다듬는 데 수년을 쏟아왔습니다. Self-Hosted Machines를 사용하면 클라우드 Agent가 그 환경에 한층 자연스럽게 녹아들며, 팀들이 이를 어디까지 활용할지 기대됩니다.
머신을 연결하거나 풀을 설정하려면 문서에서 시작하기를 확인하세요.
