직접 관리하는 머신에서 클라우드 에이전트 실행하기
TMTCursor 클라우드 에이전트를 이제 사내 네트워크 안에서 동적으로 스케줄링되는 머신 풀에서 실행할 수 있습니다. 기반 인프라는 팀이 직접 관리하고, 에이전트를 시작하고 관리하는 일은 그대로 Cursor에서 합니다.
이렇게 하면 팀은 에이전트가 어디에서 실행되고 어떤 인프라를 쓰는지를 한층 더 세밀하게 통제할 수 있습니다. 에이전트는 내부 서비스와 소스 관리 시스템 바로 옆에서 작업하거나, 맞춤 하드웨어에서 돌아가거나, Cloud Agent 빌드로 묶어내기 어려운 운영체제와 빌드 파이프라인을 그대로 쓸 수 있습니다.
지금 저희가 내부에서 머지하는 풀 리퀘스트 가운데 60퍼센트 이상은 클라우드 에이전트가 만듭니다. 저희와 함께 일하는 대기업 여러 곳에서도 에이전트가 맡는 소프트웨어 작업의 비중이 계속 커지고 있습니다. 에이전트의 역할이 넓어지면서 에이전트가 돌아가는 머신도 그만큼 더 중요해졌습니다. 이번에 추가된 기능 덕분에 팀은 그 인프라를 대규모로 제공하고 관리하는 일을 현실적으로 해낼 수 있습니다.
Cursor Cloud Agent의 컴퓨팅 계층으로 Lambda MicroVM을 쓰면, 개발자는 자기 AWS 계정 안에서 AI 코딩 에이전트를 돌릴 수 있습니다. 머신은 스냅샷에서 거의 즉시 켜지고, 쓰지 않을 때는 멈췄다가 상태를 온전히 유지한 채 다시 깨어납니다. 코딩 에이전트는 Lambda의 빠른 시작 속도와 견고한 격리, 머신을 따로 관리할 필요가 없다는 이점을 누리고, 작업 조율은 Cursor가 맡습니다.
에이전트가 실행되는 곳을 직접 정하세요
클라우드 에이전트의 기본값은 여전히 Cursor가 호스팅하는 환경입니다. 세션마다 Cursor 클라우드 안의 전용 VM에서 실행되고, 필요한 의존성이 설치되어 있으며 세션별로 네트워크 제어가 적용됩니다. 에이전트별 격리와 비밀정보 마스킹, 이그레스 제어, 서명된 커밋으로 대부분의 팀이 요구하는 보안 조건을 충족합니다.
팀이 셀프 호스팅 머신(Self-Hosted Machines)을 쓰는 경우는 보통 다음과 같습니다.
- 에이전트의 도구 실행이 사내 네트워크 안에서 이뤄져야 하고, 소스 관리 시스템과 내부 서비스, 코드 저장소에 직접 접근해야 하는 경우입니다.
- 에이전트가 GPU나 iOS 개발용 Mac 같은 맞춤 하드웨어, 또는 Kubernetes나 샌드박스, 관리형 VM 같은 인프라를 써야 하는 경우입니다.
- 팀의 운영체제나 빌드 파이프라인을 Cloud Agent 빌드로 묶어내기 어려운 경우입니다.
셀프 호스팅 머신을 쓰면 실행 환경만 옮겨 가고, 에이전트 루프와 추론, 계획 수립은 그대로 Cursor 클라우드에 남습니다. 도구 실행 결과는 추론을 위해 Cursor로 되돌아오는데 여기에 코드가 담길 수 있고, 에이전트의 작업 기록도 Cursor가 처리하고 저장할 수 있습니다. 클라우드 에이전트는 이전과 마찬가지로 데스크톱 앱과 cursor.com, 모바일, Slack, GitHub, Linear에서 쓸 수 있습니다.
셀프 호스팅 머신과 Cursor 호스팅 클라우드 에이전트 중 무엇을 쓸지 판단하는 안내도
워커가 사내 인프라를 Cursor 에이전트 루프에 연결합니다
셀프 호스팅 머신을 쓰면 도구 실행이 Cursor가 호스팅하는 VM에서 팀의 환경에 있는 머신으로 옮겨 갑니다. 그 머신이 저장소의 작업 사본을 들고 있으면서 파일을 수정하고 명령을 실행합니다. 이 머신을 에이전트 시스템의 나머지 부분과 이어 주는 것이 워커입니다.
머신을 등록하려면 Cursor CLI를 설치하고 agent worker start를 실행해 워커를 띄웁니다. 그러면 Cursor 클라우드로 나가는 장기 HTTPS 연결이 열립니다. 세션이 시작되면 Cursor의 에이전트 하네스가 추론과 계획 수립을 맡고, 도구 호출은 전용 워커로 보내 실행하게 합니다. 워커는 그 결과를 돌려보내 다음 추론에 쓰이게 합니다. Cursor가 사내 네트워크 안으로 먼저 연결을 걸어오는 일은 결코 없습니다.
클라우드에서 돌아가는 Cursor 에이전트 루프와 사내 네트워크의 워커에서 이뤄지는 도구 실행을 보여 주는 구조도
클라우드 에이전트를 배치하는 방식: Cursor가 호스팅하는 머신, 또는 자체 서버와 퍼블릭 클라우드에 띄운 워커
워커는 두 가지 방식으로 구성할 수 있습니다.
- 내 머신(My Machines). 노트북이나 VM 한 대를 계정에 연결하는 구성이고, 개인 작업 흐름에 가장 잘 맞습니다.
- 풀(Pools). 풀은 이름이 붙은 워커 대기열로, 팀이나 전사 단위의 작업을 처리할 수 있습니다. 요청이 들어오면 용량이 늘고 워커가 연결을 끊으면 줄어들기 때문에, 이미 쓰고 있는 클라우드 인프라가 개발자의 수요에 맞춰 규모를 조절합니다.
개발자는 자신의 작업 흐름을 가장 잘 뒷받침하는 플랫폼에서 코딩 에이전트를 돌릴 수 있어야 합니다. 그리고 기업은 에이전트가 어디에서 돌아가고 무엇에 접근할 수 있는지에 대한 통제권을 양보하지 않아도 되어야 합니다. 개발의 미래는 안전하게 격리된 환경에서 돌아가는 강력한 에이전트 위에 세워질 것입니다.
Meagan Gamache, Cloudflare 개발자 플랫폼 프로덕트 매니지먼트 디렉터
클라우드 에이전트가 사내 인프라에 맞춰 움직입니다
이제 워커 풀은 대기 중인 요청에 반응해 규모를 조절하고, 어떤 저장소에서 온 작업이든 처리합니다. 여러 샌드박스 제공업체를 지원하는 기능과, Mac에 이어 Linux에서도 쓸 수 있는 컴퓨터 사용(computer use) 기능도 추가했습니다.
풀은 수요에 따라 규모가 늘고 줄며, 어떤 저장소의 작업이든 처리합니다
클라우드 에이전트 수요는 한꺼번에 몰려오는 경우가 많은데, 셀프 호스팅 머신 풀은 그런 급증에 자동으로 맞춥니다. 컨트롤러가 요청 대기열을 지켜보다가, 팀이 제공한 생성 스크립트로 필요한 만큼 머신을 띄우는 방식입니다.
풀에 여유 워커가 있으면 그 워커가 요청을 가져갑니다. 없으면 용량이 더 확보될 때까지 요청이 기다리므로, 팀이 머신을 몇 대나 켜 둘지 미리 정해 둘 필요가 없습니다.
워커 연결마다 유휴 제한 시간을 설정할 수 있습니다. 제한 시간이 지나면 머신을 초기화해 다시 풀에 넣을 수 있습니다. 에이전트에 후속 요청이 올 것에 대비해 작업 공간을 그대로 남겨 둘 수도 있습니다.
셀프 호스팅 머신은 Cursor 에이전트가 어디에서 돌아갈지를 팀이 정하게 해 주고, Vercel Sandbox는 그 일을 손쉽게 만들어 줍니다. 작업마다 필요한 때에 격리된 샌드박스가 하나씩 생기고, 머신을 따로 관리할 필요도 없고, 놀고 있는 자원도 없습니다.
Allen Zhou, Vercel 테크니컬 스태프
에이전트가 놀고 있는 동안에도 머신을 켜 두면 비용이 많이 들 수 있습니다. 그렇다고 머신을 반납해 버리면, 후속 요청이 왔을 때 에이전트가 작업 공간을 다시 만드는 데 몇 분이 걸릴 수 있습니다. 최대 절전(hibernation) 기능을 쓰면 유휴 머신을 스냅샷으로 떠 두고 멈춰 세울 수 있습니다. 재연결 허용 시간 안에 후속 요청이 오면 스냅샷을 복원해 같은 ID로 워커를 다시 띄웁니다. 그 시간이 지났으면 요청을 새 머신으로 넘길 수 있습니다.
풀은 개별 저장소에 묶여 있지 않습니다. 요청은 어느 풀인지만 지정하면 되고, 여유가 있는 워커라면 어느 것이든 그 요청을 가져갈 수 있습니다. 그래서 풀 하나로 여러 저장소의 작업을 처리할 수 있습니다.
워커는 지원되는 샌드박스 제공업체 어디서든 돌아갑니다
셀프 호스팅 머신을 쓰려고 샌드박스 계층을 처음부터 직접 만들 필요는 없습니다. 저희는 AWS Lambda, Cloudflare, Coder, Daytona, E2B, Modal, Namespace, Vercel과 협력하고 있습니다. 그래서 팀이 이미 샌드박스를 돌리고 있는 곳에서 그대로 워커를 띄우고 조율할 수 있습니다.
Modal에서 Cursor 셀프 호스팅 머신을 쓰면 Cloud Agent 세션마다 Modal 샌드박스가 하나씩 주어집니다. 그래서 각 작업에 딱 맞게 준비한 머신을 에이전트에 넘겨줄 수 있습니다.
Adam Azzam, Modal 프로덕트 스태프
에이전트가 Linux와 Mac에서 브라우저를 조작합니다
이제 Mac에 이어 Linux 워커에서도 컴퓨터 사용을 지원합니다. Chrome이나 Chromium을 포함해 컴퓨터 사용에 필요한 의존성을 설치해 두면, 에이전트가 클릭하고 스크린샷을 찍고 브라우저를 조작할 수 있습니다. 에이전트의 데스크톱 화면을 지켜보거나 Cursor에서 바로 조작권을 가져올 수도 있습니다.
Mac 없이는 iOS나 macOS 앱을 빌드할 수 없습니다. Namespace Devbox는 Cursor Cloud Agent마다 실제 Mac을 하나씩 띄워 주고, 이제 에이전트가 Apple 실리콘에서 그 작업을 해낼 수 있습니다.
Hugo Santos, Namespace CEO
클라우드 에이전트를 여러분의 환경으로 들여오세요
팀들은 저마다 소프트웨어를 만드는 방식에 맞춰 인프라를 다듬는 데 여러 해를 써 왔습니다. 셀프 호스팅 머신은 클라우드 에이전트가 그 인프라에 더 자연스럽게 들어맞게 해 줍니다. 팀들이 이 기능을 어디까지 밀고 나갈지 저희도 기대가 큽니다.
머신을 연결하거나 풀을 구성하려면 문서에서 시작하세요.