2026년 5월 AI 코딩 에이전트 비교: Cursor와 Cloudflare Workers의 2가지 격차

5월 13일 Cursor는 멀티 리포지토리 클라우드 에이전트 환경을 출시했습니다. Cursor 자체 제품 페이지에 따르면, 현재 Cursor가 병합하는 pull request 중 클라우드 샌드박스에서 작동하는 자율 AI 코딩 에이전트가 생성한 비율은 30%를 넘습니다.

Cursor가 5월 13일 실제로 내놓은 것

핵심은 멀티 리포지토리 클라우드 에이전트 환경입니다. Cursor가 4월 24일 출시한 multi-root workspaces를 확장해, 이제 에이전트가 설정된 단일 환경 안에서 여러 리포지토리를 넘나들며 작업할 수 있습니다. 이 환경은 세션이 바뀌어도 재사용됩니다. 에이전트를 실행할 때마다 같은 개발 환경을 다시 구성하지 않아도 된다는 점이 실무에서는 가장 중요합니다.

설정의 중심은 Dockerfile입니다. 빌드 시크릿은 빌드 단계에만 한정되며 실행 중인 에이전트에는 전달되지 않습니다. 빌드에 들어간 API 키가 뜻하지 않게 에이전트의 작업 메모리에 남는, 에이전트 인프라의 가장 흔한 실수를 막는 방식입니다. Cursor가 리포지토리의 툴과 의존성을 살펴 Dockerfile을 구성하게 할 수도 있습니다. 이 기능은 아직 Enterprise 팀을 대상으로 비공개 베타가 진행 중입니다.

성능 개선 폭이 가장 큰 부분은 레이어 캐싱입니다. 캐시가 적중하면 변경된 Dockerfile 레이어만 다시 빌드하므로 빌드 속도가 이제 70% 더 빠릅니다. 팀 전체에서 에이전트를 반복 실행할 때, 기다리는 시간과 실제로 일하는 시간을 가르는 차이입니다.

경쟁 제품들이 대체로 가볍게 다루는 운영 기능도 주목할 만합니다. 모든 환경에는 롤백 가능한 버전 기록이 있고, 롤백 권한은 관리자에게만 주어집니다. 감사 로그에는 팀원이 환경에서 수행한 모든 작업이 남습니다. 외부 통신 허용 목록과 시크릿 범위도 환경별로 분리되므로, 환경 A에 허용된 시크릿을 환경 B에서는 사용할 수 없습니다. 에이전트가 프로덕션 코드에 PR을 열도록 맡기려면 이런 눈에 띄지 않는 인프라부터 갖춰야 합니다.

Cursor가 발표에서 근거로 내세운 사례는 Amplitude입니다. 이 회사의 Cursor Automations는 공개 Slack 채널을 지켜보다가 신고된 문제를 조사하고, 영향을 받는 리포지토리를 찾아 적절한 리포지토리에 걸쳐 PR을 생성합니다. 실제 기업이 실제 규모로 운영하는 멀티 리포지토리 에이전트의 초동 트리아지입니다. 데모가 아닙니다.

Cursor가 공개한 병합 PR 비율이 결정적 근거인 이유

Cursor에 따르면, 현재 Cursor가 병합하는 pull request 중 클라우드 샌드박스에서 작동하는 자율 에이전트가 생성한 비율은 30%를 넘습니다. 여기서는 분모가 중요합니다. 에이전트가 시도한 작업이 아니라 실제로 병합된 pull request를 센 수치입니다. 사람이 모든 커밋을 직접 밀어 넣지 않아도 검토와 수정, 인계까지 이어지는 루프를 완주할 수 있다는 근거입니다.

2026년 9월 2일부터 Cursor의 Self-Hosted Machines를 사용하면 파일 편집, 터미널 명령, computer-use 툴, 로컬 MCP 실행을 고객이 관리하는 워커로 옮길 수 있습니다. 에이전트 루프와 추론, 계획은 계속 Cursor 클라우드에서 처리합니다. 이로써 비공개 실행 위치라는 격차는 해소됐지만, Cursor가 프로그래밍 가능한 영속 런타임으로 바뀐 것은 아닙니다.

이제 차이는 세션 단위인가 영속적인가가 아닙니다. Cursor는 대화 상태를 백엔드에 보존해 실행을 다시 열고 이어갈 수 있으며, Self-Hosted Team Pools는 최대 절전 상태의 워크스페이스를 복원할 수 있습니다. 더 정확한 구분은 벤더가 관리하는 에이전트 상태와 프로그래밍 가능한 애플리케이션 상태입니다. Cloudflare는 에이전트별 SQLite 상태와 코드로 제어하는 영속적인 워크플로 단계를 제공합니다.

내 Cloudflare Workers와 Agents SDK 스택이 이미 하는 일

필자는 Cloudflare에서 프로덕션 에이전트 6개를 운영합니다. 런타임은 Workers이고, 상태는 인스턴스별 SQLite를 갖춘 Durable Objects에 저장하며, 장기 실행 오케스트레이션은 Cloudflare Workflows에서 처리합니다. 혼자 구축해 단일 계정으로 운영하는 구성으로, 여기에서 자세히 해부했습니다. Cloudflare 전체 스택의 2026년 4월 비용은 $19.14였습니다. 플랫폼의 공시 가격이 아니라 특정 시점의 실제 프로덕션 청구액입니다. Cursor는 Enterprise 가격을 Custom으로 안내합니다. Team Pools에는 Enterprise가 필요하며, Self-Hosted Machines도 선택한 모델의 사용료와 자체 워커 비용이 함께 듭니다.

이 스택은 현재 Cursor 제품과 세 가지 면에서 다릅니다.

코드로 구현하는 멀티 리포지토리. Worker는 런타임에 HTTP로 리소스를 가져올 수 있습니다. 컨텍스트가 웹사이트 뒤에 있을 때는 이전에 Browser Rendering으로 불렸던 Browser Run으로 헤드리스 브라우저를 제어할 수 있습니다. Cursor는 멀티 리포지토리 접근을 재사용 가능한 환경 설정으로 묶어 제공하지만, Cloudflare에서는 가져오기와 인증, 리포지토리 로직을 직접 구현해야 합니다. 어느 쪽이 더 낫거나 나쁜 문제가 아니라 제어 방식이 다릅니다.

프로그래밍 가능한 영속 상태. Cloudflare Agent는 애플리케이션 상태를 자체 SQLite 데이터베이스에 자동 저장하고, 재시작하거나 최대 절전 모드에서 깨어날 때 다시 불러옵니다. Cursor도 대화 상태를 보존하고 실행 재개를 지원합니다. 차이는 제어권입니다. Cursor는 대화 저장소와 에이전트 런타임을 소유하지만, Cloudflare에서는 애플리케이션 상태와 그 스키마를 코드에서 직접 다룰 수 있습니다.

정확히 한 번 실행을 자동 보장하는 것이 아니라, 영속적인 단계 경계. Workflows에서는 각 단계를 개별적으로 재시도할 수 있고 상태를 기록할 수 있어, 네트워크나 인프라 장애가 발생해도 실행을 보존하고 이어갈 수 있습니다. step.do는 단계별 재시도 설정을 받고, NonRetryableError는 종료형 오류에서 재시도를 멈추며, 인스턴스 ID는 Workflow마다 고유합니다. 다만 한 단계가 두 번 이상 실행될 수 있으므로, Cloudflare도 부수 효과가 있는 호출은 명시적으로 멱등하게 만들라고 안내합니다. 장점은 중복 pull request나 이메일, 과금을 자동으로 막아 주는 데 있지 않습니다. 개발자가 영속성과 재시도 방식을 정의할 수 있다는 데 있습니다.

AI 코딩 에이전트 인프라에서 Cursor에 남은 2가지 격차

격차 1: 고객이 제어하는 프로그래밍 가능한 에이전트 상태. Cursor는 기본적인 재개 기능을 해결했습니다. 대화 상태는 기본적으로 기한 없이 보관되고, 관리형 VM 스냅샷에는 활동이 없는 기간을 기준으로 순환하는 90일 보존 창이 적용됩니다. Self-Hosted Machines는 툴 실행 위치를 옮기지만, 에이전트 루프는 여전히 Cursor가 운영하고 대화도 Cursor가 저장합니다. Cloudflare Agent는 애플리케이션 런타임 안에서 SQLite 기반 상태를 노출합니다. 에이전트가 사고를 모니터링하거나 마이그레이션을 조율하고, 여러 날에 걸친 온보딩 과정에서 비즈니스 상태를 이어 가야 할 때 이 차이가 중요합니다.

이는 5월에 설명했던 격차보다 범위가 좁아졌습니다. Cursor 제품의 에이전트 실행은 이제 재개할 수 있습니다. 하지만 애플리케이션이 Cursor 채팅과 별개로 조회하고 확장하며 조율할 수 있는, 고객 소유의 상태 머신을 제공하지는 않습니다.

격차 2: 개발자가 정의하는 영속적인 단계 인터페이스. 현재 Cursor의 Cloud Agent와 Self-Hosted Machine 문서에는 상태가 보존되고 단계별 재시도 설정이 가능한 Workflow 단계에 대응하는 애플리케이션 프리미티브가 없습니다. Cloudflare에는 있습니다. 코딩 에이전트의 작업이 결제, 이메일, 배포 또는 다른 외부 부수 효과로 이어질 때 이 차이가 중요해집니다.

툴 호출을 자체 머신으로 옮겨도 이 격차는 사라지지 않습니다. 달라지는 것은 오케스트레이션 계약이 아니라 실행 위치이기 때문입니다. Cloudflare 역시 부수 효과의 정확히 한 번 실행을 보장하지 않습니다. 재시도되는 단계는 여전히 멱등하게 설계해야 합니다.

이는 Cursor를 깎아내리는 이야기가 아닙니다. 제품 범주의 차이를 말하는 것입니다. Cursor는 관리형 툴 실행과 고객 운영형 툴 실행을 모두 제공하는 코딩 제품입니다. Cloudflare는 프로그래밍 가능한 애플리케이션 런타임입니다. 9월 릴리스로 인프라 격차는 좁아졌지만, 상태와 오케스트레이션의 경계는 여전히 두 제품을 가릅니다.

창업자와 CTO가 이번 주에 할 일

세 가지 상황에는 서로 다른 선택이 필요합니다.

제품 기능을 출시하는 소규모 제품 팀이라면, Cursor의 환경과 네트워크 제어로 빌드를 재현할 수 있을 때 Cursor 관리형 Cloud Agents를 사용하면 됩니다. 5월 13일 환경 릴리스는 멀티 리포지토리 설정과 빌드 시크릿, 캐싱, 감사 기능을 갖췄고, 병합 PR의 30%를 넘는다는 Cursor의 공개 수치가 실제 활용을 뒷받침합니다. 정책상 이유가 없다면 워커 플릿을 직접 운영할 필요는 없습니다.

이미 Cloudflare 또는 Vercel에서 장기 실행 백그라운드 프로세스를 운영한다면, 영속적인 애플리케이션 상태와 오케스트레이션은 그곳에 유지하는 편이 낫습니다. 이제 Cursor Self-Hosted Machines가 Cloudflare 또는 Vercel 인프라를 툴 실행에 사용할 수 있지만, 에이전트 루프는 계속 Cursor가 소유합니다. Anthropic이 비슷한 프리미티브를 중소기업용으로 묶는 방식을 보여 주는 소비자 측의 유사 사례도 읽어볼 만합니다. 플랫폼이 에이전트를 중심으로 수렴하는 흐름은 곳곳에서 나타나고 있습니다.

엔터프라이즈 도입을 준비한다면, 허용 목록, Tailscale, AWS PrivateLink 또는 Cloudflare Tunnel로 접근 요구사항을 충족할 수 있을 때는 관리형 Cloud Agents부터 시작하면 됩니다. 체크아웃과 툴 실행, 커스텀 하드웨어 또는 워커 이미지를 직접 통제해야 한다면 Team Pools를 사용합니다. Team Pools에는 가격이 Custom인 Enterprise가 필요하며, Cursor가 Dockerfile을 구성해 주는 기능은 아직 비공개 베타입니다.

5월 이후 달라진 점

두 가지 신호가 있습니다.

첫째, Cursor는 이제 대화 상태와 런타임 워크스페이스를 별도로 문서화합니다. 실행을 다시 열고 이어갈 수 있도록 대화 상태를 기본적으로 기한 없이 보관합니다. 관리형 VM 스냅샷은 90일 동안 활동이 없으면 만료되지만, 시작하거나 재개하면 그 기간이 연장됩니다. 기본적인 재개 기능은 더 이상 격차가 아닙니다. 이제 쟁점은 소유권과 프로그래밍 가능성입니다.

둘째, 비공개 실행 위치 역시 더 이상 격차가 아닙니다. Self-Hosted Machines가 이 문제를 해결하면서도 에이전트 루프와 추론, 계획은 Cursor 클라우드에 남겨 둡니다. 고객이 제어하는 에이전트 상태와 개발자가 정의하는 영속적인 단계 인터페이스가 여전히 의미 있는 두 가지 차이입니다.

Cursor의 5월 13일 릴리스로 자체 호스팅 에이전트 인프라는 더 이상 필요 없나요?

아닙니다. Cursor는 이제 개인 워크플로를 위한 My Machines와 Enterprise 플릿을 위한 Team Pools라는 자체 호스팅 경로도 제공합니다. 툴 실행을 사용자 네트워크로 옮길 수 있지만, 에이전트 루프는 계속 Cursor가 실행하고 대화 상태도 Cursor가 저장합니다. 프로그래밍 가능한 애플리케이션 런타임이나 영속적인 워크플로 단계가 필요한 팀은 해당 계층을 위한 인프라가 여전히 필요합니다.

Cursor의 캐시된 클라우드 에이전트 빌드는 얼마나 빨라졌나요?

5월 13일 레이어 캐싱 업그레이드 이후, 캐시가 적중한 빌드는 70% 더 빠르게 실행됩니다. 이때는 변경된 Dockerfile 레이어만 다시 빌드합니다.

Cursor가 공개한 내부 병합 PR 비율은 무엇을 의미하나요?

Cursor의 현재 공식 페이지에 따르면, Cursor가 병합하는 pull request 중 클라우드 샌드박스에서 작동하는 자율 에이전트가 생성한 비율은 30%를 넘습니다. 시도한 작업이 아니라 병합된 pull request를 측정한 수치이므로, 프로덕션 도입 수준을 보여 주는 유용한 근거입니다.

프로덕션 시크릿을 다루는 코드에도 Cursor 클라우드 에이전트가 안전한가요?

5월 13일 릴리스는 외부 통신과 시크릿 범위를 환경별로 제한하고, 빌드 시크릿을 실행 중인 에이전트와 격리하며, 버전 기록과 롤백, 감사 로그를 제공합니다. Self-Hosted Machines를 사용하면 전체 체크아웃과 머신 로컬 자격 증명을 자체 워커에 둘 수 있습니다. 다만 필요한 파일 내용과 툴 출력, diff, 스크린샷, 로컬 MCP 결과는 여전히 Cursor로 전송될 수 있습니다. 두 경계를 모두 승인할 수 있는지가 안전성을 좌우합니다.

Cloudflare Workers와 Cursor 클라우드 에이전트를 함께 운영할 수 있나요?

가능합니다. Cursor는 Cloudflare를 Self-Hosted Machines 통합 대상으로 안내하며, 참조 템플릿에서는 Cloudflare Worker를 컨트롤러로 사용해 접수된 요청마다 Cloudflare Container 하나를 시작합니다. Cursor는 코딩 에이전트 루프를 맡고, Workers와 Durable Objects, Workflows는 영속적인 애플리케이션 상태와 오케스트레이션을 담당할 수 있습니다. 이제 두 제품은 툴 실행 영역에서는 겹치지만 에이전트 루프의 경계에서는 겹치지 않습니다.