클라우드 에이전트 Computer Use, 2월 24일에 무엇이 바뀌었나

Cursor 클라우드 에이전트는 원래 있던 기능입니다. 2025년 6월부터 클라우드에서 독립 VM에 에이전트를 띄워 백그라운드로 작업을 돌리는 개념은 이미 출시되어 있었습니다. 2026년 2월 24일 업데이트의 핵심은 여기에 Computer Use가 붙었다는 점입니다.

기존 클라우드 에이전트는 코드를 읽고 수정할 수는 있었지만, 자신이 만든 소프트웨어를 직접 실행해서 확인하지는 못했습니다. Cursor 공동 엔지니어링 헤드 Jonas는 이를 “모델 입장에서 토큰만 뽑아내고 그게 제대로 됐는지 확인할 방법이 없는 상태”라고 설명했습니다. 이번에 추가된 것은 에이전트가 VM 안에서 브라우저를 열고, localhost로 이동해서, UI를 직접 클릭하고 검증하는 능력입니다. (출처: cursor.com/blog/agent-computer-use, 2026.02.24)

결과물은 머지 가능한 PR에 영상, 스크린샷, 로그가 첨부된 형태로 나옵니다. 검토자는 diff를 머릿속으로 시뮬레이션하는 대신 30초짜리 영상으로 “이게 실제로 작동하는지” 먼저 확인할 수 있습니다. 에이전트가 문제를 발견하면 스스로 수정하고 다시 테스트합니다.

요금제별로는 Pro($20/월) 이상에서 클라우드 에이전트 자체에 접근할 수 있고, Ultra($200/월)는 Pro 대비 20배 사용량에 신규 기능 우선 접근 권한이 붙습니다. Computer Use는 요금제 차이가 아니라 모델 선택에 따라 가능 여부가 갈립니다. (출처: cursor.com/pricing, 2026.03 기준)

▲ 목차로 돌아가기

35%라는 수치, 그대로 믿으면 오해가 생깁니다

“Cursor 내부 PR의 35%가 이제 클라우드 에이전트가 만든 것”이라는 수치가 발표 후 많이 공유됐습니다. 이 수치 자체는 공식 블로그에 직접 나온 내용입니다. (출처: cursor.com/blog/agent-computer-use, 2026.02.24) 그런데 이 수치를 일반화하면 오해가 생깁니다.

35%가 나올 수 있는 조건은 특정합니다. Cursor 팀은 한 달간 내부에서 이 기능을 도그푸딩하면서, 인증 없이도 돌아가는 프론트엔드 중심 작업부터 쌓아갔습니다. 실제 포럼에서 사용자들이 가장 먼저 부딪히는 문제는 .env 파일의 데이터베이스 자격증명, 외부 인증(SSO), 스테이징 DB 연결입니다. (출처: Cursor Community Forum, 2026.02.25)

Cursor 공동 엔지니어링 헤드도 직접 인정했습니다. “복잡한 Docker 레이어 캐싱이 필요한 인프라에서는 아직 지원하기 어렵다. 프론트엔드-백엔드 구조가 단순한 프로젝트에서는 에이전트가 스스로 설치하고 실행한다.” (출처: Latent Space 인터뷰, cursor.com, 2026.03.05) 35%는 단순한 구조의 프로젝트에서 나오는 수치입니다.

▲ 목차로 돌아가기

Composer 모델에서는 작동하지 않습니다 — 공식 확인 사항

Computer Use 기능이 붙었다는 뉴스를 보고 클라우드 에이전트를 설정해서 실행해봤는데, 영상도 나오지 않고 데스크톱 연결도 안 된다는 경우가 꽤 발생했습니다. 이유가 있습니다.

Cursor의 기본 추천 모델인 Composer 계열(Composer 1.5 포함)로 클라우드 에이전트를 돌리면 Computer Use 없이 코드만 생성합니다. 영상 녹화도 안 됩니다. Computer Use와 RecordSession이 작동하려면 OpenAI Codex 5.3 또는 Anthropic Claude Opus 모델을 선택해야 합니다. 이것은 요금제 문제가 아니라 모델 선택 문제입니다.

같은 포럼에서 실제 사용자가 추가로 확인한 내용도 있습니다. “같은 작업을 Composer로 돌리면 안 된다고 응답하고, Codex와 Opus로 돌리면 잘 된다. 비용 효율이 좋은 Composer를 쓰고 싶은데 이 부분이 아쉽다.” (출처: Cursor Community Forum, 2026.02.26) Cursor 팀이 이유를 공개적으로 설명하지 않은 부분입니다.

▲ 목차로 돌아가기

실제로 쓸 수 있는 조건과 환경 세팅

클라우드 에이전트 Computer Use가 제대로 돌아가려면 몇 가지 환경 조건이 맞아야 합니다. 포럼에서 실제 사용자들이 겪은 시행착오를 모아봤습니다.

① .cursor/environment.json 충돌 주의

기존에 environment.json 파일이 .cursor/ 폴더에 있으면 Computer Use가 스냅샷을 제대로 적용하지 못합니다. 새로 환경을 세팅했는데 데스크톱 연결이 안 된다면 이 파일을 삭제하고 다시 시작하는 게 첫 번째 점검 항목입니다. (출처: Cursor Community Forum, 2026.02.25)

② 네트워크 허용 목록 — Next.js 기본 세팅에서 막히는 이유

기본 Next.js 앱을 클라우드 에이전트로 돌리면 Google 폰트 도메인(fonts.gstatic.com, fonts.googleapis.com)이 네트워크 허용 목록에 없어서 에이전트가 오래 헤매는 경우가 있습니다. 개인 설정 탭에서 네트워크 허용 목록을 추가할 수 있지만, 팀 설정 탭에는 아직 이 옵션이 없습니다. 팀 단위로 쓴다면 우선 개인 설정에서 확인해야 합니다. (출처: Cursor Community Forum, 2026.02.25)

③ DB가 필요한 앱 — 현재 한계와 우회 방법

VM 안에 자체 DB를 세팅하거나, Supabase·Render 같은 외부 서비스의 자격증명을 Secrets에 넣어서 연결하는 방식이 현재 가능한 우회 방법입니다. 스테이징 DB를 그대로 연결하는 건 신중하게 판단해야 합니다. 에이전트가 실제 데이터에 접근해서 작업하는 방향은 아직 검증된 안전한 패턴이 없습니다.

④ Automations에서는 Computer Use가 작동하지 않습니다

Cursor의 Automations 기능(트리거 기반 자동 실행)에서는 Computer Use가 현재 지원되지 않습니다. Automation에서 스크린샷을 찍으라고 명시적으로 지시해도 에이전트가 실행하지 않습니다. 이것은 2026년 3월 8일 포럼에서 확인된 제약이고, 공식 답변은 아직 나오지 않은 부분입니다. (출처: Cursor Community Forum, 2026.03.08)

▲ 목차로 돌아가기

로컬 에이전트와 클라우드 에이전트, 언제 어떤 걸 써야 하나

클라우드 에이전트 발표 이후 “그럼 로컬 에이전트는 이제 필요 없는 거냐”는 질문이 많이 나왔습니다. 결론부터 말하면, 지금은 병행해서 써야 하는 단계입니다.

로컬 에이전트는 코드베이스 전체에 대한 컨텍스트를 즉시 가져오고, 로컬 환경의 MCP를 모두 활용할 수 있습니다. 빠른 피드백 루프가 필요하거나 자신이 직접 확인하면서 진행해야 하는 작업에 여전히 적합합니다. 반면 클라우드 에이전트는 45분씩 돌아가는 UI 테스트, 병렬로 여러 기능을 동시에 만드는 작업, 또는 자리를 비워도 되는 장시간 작업에 강점이 있습니다.

주목할 만한 수치가 있습니다. 2025년 3월에는 Tab 사용자가 에이전트 사용자보다 2.5배 많았습니다. 2026년 3월 현재는 반전됐습니다. 에이전트 사용자가 Tab 사용자보다 2배 많습니다. (출처: cursor.com/blog/third-era, 2026.02.26) 단 1년 만에 기본 사용 패턴이 완전히 바뀐 것입니다.

한편 클라우드 에이전트에서 아직 지원되지 않는 로컬 MCP 통합이 있습니다. 로컬에서 Datadog MCP나 Stripe MCP 등을 쓰고 있다면, 클라우드 에이전트에서 동일하게 쓰려면 별도 설정이 필요하고 일부는 아직 클라우드 에이전트용으로 베타 상태입니다. Cursor는 클라우드 에이전트 MCP 지원 확대를 근시일 내 진행할 계획이라고 밝혔지만, 구체적인 일정은 공개되지 않았습니다.

▲ 목차로 돌아가기

코드 리뷰 흐름이 바뀌는 방식 — 영상 아티팩트의 실제 의미

클라우드 에이전트가 만든 PR에는 영상이 붙어 있습니다. 이게 단순한 기능 데모가 아닙니다. Cursor의 Futurum Group 분석에 따르면, 에이전트가 생성한 PR의 비중이 35%에 달하면 코드 리뷰가 새로운 병목이 됩니다. (출처: DevOps.com, 2026.02.26)

500줄짜리 diff를 읽는 것과 30초 영상을 보는 것은 인지 부하가 다릅니다. Cursor가 영상 리뷰를 코드 리뷰의 ‘진입점’으로 설계한 이유입니다. 영상이 기준을 충족하면 코드를 더 볼지 결정하고, 미흡하면 추가 피드백을 주는 방식입니다. 영상이 코드 리뷰를 대체하지는 않지만, 리뷰 시작점이 바뀝니다.

또 하나 주목할 점은 Slack 연동입니다. Cursor 팀은 Slack 채널에서 “@Cursor”를 멘션해 에이전트를 킥오프하고, 결과가 스레드로 돌아오는 방식으로 일합니다. 리뷰에 참여하지 않던 팀원도 스레드에서 추가 컨텍스트를 붙이면 에이전트가 참고해서 수정합니다. 개발이 IDE에서 Slack으로도 일부 이동하는 형태입니다. 보안 취약점 재현, UI 전체 테스트처럼 반복적이고 시간이 걸리는 작업에 이 흐름이 특히 잘 맞습니다.

한편 샌드박스 환경에서 돌아간 에이전트는 중단율이 그렇지 않은 에이전트보다 40% 낮습니다. (출처: DevOps.com, cursor.com 공식 발표 기반, 2026.02.26) 자신이 만든 코드를 직접 실행해서 확인할 수 있으면 막다른 곳에서 멈추는 빈도가 줄어드는 것입니다. 이 수치가 실제로 의미하는 건, 에이전트에게 직접 검증 도구를 주면 생성 품질이 올라간다는 점입니다.

▲ 목차로 돌아가기

자주 나오는 질문 5가지

▲ 목차로 돌아가기

마치며

Cursor 클라우드 에이전트 Computer Use는 방향성이 분명히 맞는 기능입니다. AI가 자기 코드를 직접 실행해서 확인하는 루프는, 단순히 코드를 뽑아내던 방식보다 품질이 다릅니다. 실제로 샌드박스에서 돌린 에이전트의 중단율이 40% 낮아진다는 건, 검증 도구가 결과물에 직접 영향을 준다는 것입니다.

그러나 지금 당장 쓰기 위해서는 현실적인 조건 확인이 필요합니다. Composer 모델에서는 작동하지 않고, Automations에서도 아직 지원되지 않으며, DB 연결과 외부 인증이 필요한 프로젝트는 추가 설정 없이는 막힙니다. 35%라는 Cursor 내부 수치도 단순 구조의 프로젝트에서 나온 것입니다.

써보기에 가장 좋은 시작점은 인증 없이 돌아가는 프론트엔드 프로젝트에서 Codex 5.3이나 Opus 모델을 선택하고 버그 재현이나 UI 기능 추가 작업을 맡겨보는 것입니다. 영상이 딸려 나온 PR을 한 번 경험하면 개발 흐름이 어디로 가는지 체감됩니다.

▲ 목차로 돌아가기

본 포스팅 참고 자료

1. Cursor 공식 블로그 — Agents are only as capable as the environment they run in
   https://cursor.com/blog/agent-computer-use (2026.02.24)
2. Cursor 공식 블로그 — The third era of AI software development
   https://cursor.com/blog/third-era (2026.02.26)
3. DevOps.com — Cursor Cloud Agents Get Their Own Computers
   https://devops.com/cursor-cloud-agents-get-their-own-computers-and-35-of-internal-prs-to-prove-it/ (2026.02.26)
4. Cursor Community Forum — Computer use cloud agent snapshot not applied
   https://forum.cursor.com/t/computer-use-cloud-agent-snapshot-not-applied/152863 (2026.02.25)
5. Cursor 공식 요금 페이지
   https://cursor.com/pricing (2026.03 기준)