무엇이 달라졌나
Vercel은 Cursor Cloud Agents가 Cursor의 호스팅 머신 대신 Vercel Sandbox에서 실행될 수 있다고 발표했다. 핵심은 Cursor가 에이전트의 하니스와 추론 루프를 관리하되, 실제로 저장소를 복제하고 파일을 수정하며 명령과 테스트를 실행하는 환경은 사용자가 공급할 수 있다는 점이다.
이 흐름은 Cursor의 Self-Hosted Machines API를 전제로 한다. 원문 기준으로 이 기능은 Cursor Enterprise 플랜이 필요하다. 따라서 개인 개발자나 학생이 바로 켤 수 있는 일반 기능으로 보기보다는, 엔터프라이즈 환경에서 에이전트 실행 위치와 격리 방식을 통제하려는 팀이 먼저 검토할 소식에 가깝다.
Vercel Sandbox가 맡는 역할
Vercel Sandbox는 각 에이전트 요청마다 격리된 Firecracker microVM 실행 환경을 제공한다. 에이전트가 저장소를 클론하고, 코드를 편집하고, 테스트를 실행하는 공간이 요청 단위로 분리되는 구조다. 장기 실행 가상 머신을 유지하는 방식과 달리, 요청이 있을 때 워커를 만들고 작업이 끝나면 정리하는 구성을 목표로 한다.
제어 계층은 Vercel Functions와 Vercel Workflow가 구성한다. 원문에 따르면 이 조합은 대기 중인 에이전트 요청을 가져오고, 워커를 프로비저닝하며, 세션을 모니터링하고, 작업이 끝난 뒤 자동으로 정리하는 역할을 한다. 에이전트 실행을 단순히 “어딘가에서 돌린다”가 아니라, 요청 큐와 실행 세션, 실패 처리, 정리까지 하나의 흐름으로 묶는 접근이다.
개발자가 먼저 볼 부분
| 항목 | 확인할 질문 | 적용 기준 |
|---|---|---|
| 플랜 | Cursor Self-Hosted Machines API를 사용할 수 있는 계정인가? | 원문 기준 Cursor Enterprise 플랜이 필요하므로, 개인 계정이나 일반 팀 플랜에서는 먼저 사용 가능 여부를 확인해야 한다. |
| 실행 환경 | 에이전트가 어떤 저장소를 클론하고 어떤 명령을 실행하는가? | 코드 수정, 테스트 실행, 빌드 검증처럼 격리 실행의 가치가 큰 작업부터 검토하는 편이 현실적이다. |
| 보안 | 에이전트가 접근하는 자격 증명은 얼마나 짧게 유지되고, 어느 사용자 범위에 묶이는가? | 원문은 Sandbox 안에 짧은 수명의 사용자 범위 자격 증명을 둔다고 설명한다. 실제 권한 범위는 적용 전 문서와 계정 설정에서 확인해야 한다. |
| 비용 | Vercel Sandbox, Functions, Workflow 사용량이 어떤 과금 구조로 잡히는가? | 원문에는 가격 수치가 제시되지 않았다. 팀의 예상 요청 수, 테스트 시간, 실패 재시도 빈도를 기준으로 별도 확인이 필요하다. |
| 운영 | 세션 실패, 워커 실패, 재시도, 정리 실패를 어떻게 볼 수 있는가? | 원문은 durable retries를 언급한다. 실제 관측 지표와 로그 위치를 확인해야 운영에 넣을 수 있다. |
개인 사용자와 학생에게 의미 있는 경우
이 발표는 개인 사용자가 곧바로 비용 없이 쓸 수 있는 새 버튼이라기보다는, 클라우드 코딩 에이전트가 실행되는 방식의 선택지가 늘어난 사례로 보는 편이 맞다. 특히 원문에 Cursor Enterprise 요건이 명시되어 있으므로, 개인 계정으로 바로 실험하려는 경우에는 먼저 Cursor 플랜 조건과 Vercel 계정에서 Sandbox 사용 가능 여부를 확인해야 한다.
다만 학습 관점에서는 중요하다. 에이전트가 코드를 제안하는 수준을 넘어 저장소를 실제로 복제하고, 파일을 바꾸고, 테스트를 실행하는 워크플로우에서는 “모델이 똑똑한가”만큼 “어디에서 실행되는가”가 중요해진다. 과제 저장소, 연구 코드, 개인 프로젝트를 다룰 때도 실행 환경 격리, 권한 범위, 자격 증명 수명은 기본 체크 항목이 된다.
연구자와 개발팀이 주목할 지점
연구 코드나 사내 저장소에는 외부에 노출되면 안 되는 데이터, 실험 설정, API 키, 내부 문서가 함께 들어가는 경우가 많다. 에이전트가 이런 저장소에서 명령을 실행한다면, 실행 환경을 분리하고 자격 증명을 짧게 유지하는 구조가 필요하다. Vercel Sandbox가 요청마다 격리된 microVM을 제공한다는 설명은 이 문제를 다루기 위한 방향으로 읽을 수 있다.
팀 단위에서는 장기 실행 VM을 직접 유지하지 않아도 되는 점도 검토 대상이다. 원문은 scale-to-zero worker pool을 장점으로 제시한다. 항상 켜져 있는 머신을 관리하는 방식보다 유휴 비용과 패치 관리 부담을 줄일 가능성이 있지만, 실제 비용 절감 여부는 요청량, 실행 시간, 재시도 횟수, 로그 보존 정책에 따라 달라진다.
바로 전환하기 전에 확인할 조건
- Cursor Enterprise 사용 여부: Self-Hosted Machines API가 전제이므로 현재 계약이나 계정에서 사용할 수 있는지 확인해야 한다.
- Vercel 계정 권한: 참조 구현을 배포하려면 Vercel 계정에서 Sandbox, Functions, Workflow를 사용할 수 있어야 한다.
- 저장소 접근 범위: 에이전트가 읽고 쓸 저장소, 브랜치, 토큰 권한을 최소 단위로 제한할 수 있는지 봐야 한다.
- 명령 실행 범위: 테스트, 빌드, 린트처럼 허용할 명령과 금지할 명령을 구분해야 한다.
- 실패 복구: 워커나 세션이 실패했을 때 재시도가 어떤 단위로 일어나는지, 중복 커밋이나 중복 작업이 생기지 않는지 확인해야 한다.
- 정리 절차: 작업 종료 뒤 임시 파일, 체크아웃된 저장소, 자격 증명이 어떻게 정리되는지 문서로 확인해야 한다.
작은 저장소로 검증하는 방식
처음부터 핵심 서비스 저장소를 연결하는 것은 권장하기 어렵다. 더 현실적인 시작점은 의존성이 단순하고 테스트가 짧은 내부 샘플 저장소다. 예를 들어 문서 수정, 타입 오류 수정, 작은 테스트 추가처럼 결과를 눈으로 검토하기 쉬운 작업을 골라야 한다. 에이전트 실행 환경의 장점은 큰 작업에서 드러날 수 있지만, 위험도도 함께 커지기 때문이다.
검증할 때는 성공 여부만 보지 말고, 에이전트가 어떤 명령을 실행했는지, 실패했을 때 어떤 로그가 남는지, 재시도 후 작업물이 중복되지 않는지, 자격 증명이 필요한 범위보다 넓게 들어가지 않았는지를 함께 기록해야 한다. 특히 업무나 연구 자료가 포함된 저장소라면, 보안 검토가 끝나기 전에는 읽기 전용 토큰이나 테스트용 저장소로 제한하는 편이 안전하다.
기존 방식과 비교할 기준
이미 자체 VM, CI 러너, 개발 컨테이너, GitHub Actions 같은 환경에서 에이전트 작업을 돌리고 있다면, 이번 통합이 무조건 더 낫다고 볼 수는 없다. 비교 기준은 단순하다. 장기 실행 머신 관리가 줄어드는가, 요청 단위 격리가 명확해지는가, 실패 재시도가 더 안정적인가, 자격 증명 범위를 더 짧고 좁게 만들 수 있는가를 보면 된다.
반대로 현재 방식이 충분히 단순하고 비용 예측이 쉬우며 보안 경계도 명확하다면 당장 옮길 이유는 약하다. 새 기능은 반복 작업 하나를 확실히 줄이거나, 운영 리스크를 더 잘 통제하거나, 에이전트 실행을 팀 표준 워크플로우로 묶을 수 있을 때 가치가 커진다.
출처와 검증
이 글은 Vercel Changelog에 게시된 “Cursor Cloud Agents can now run in Vercel Sandbox” 내용을 바탕으로 정리했다. 기능 적용 전에는 Cursor Enterprise 플랜 조건, Vercel Sandbox 사용 가능 여부, Functions와 Workflow 과금, 자격 증명 처리 방식, 참조 구현 배포 절차를 공식 문서에서 다시 확인해야 한다.
원문: https://vercel.com/changelog/run-cursor-cloud-agents-vercel-sandbox