Cursor의 2026년 6월 업데이트는 AI 코딩 도구가 어디로 가고 있는지 꽤 선명하게 보여줍니다. 핵심은 세 가지입니다. 로컬 IDE 안에서만 돌던 에이전트를 클라우드 VM으로 보내고, 긴 작업을 서브에이전트에게 맡기고, SDK 기반 자동화에서도 도구 실행을 리뷰 정책으로 통제하는 방향입니다.
이번 글은 “Cursor Cloud Agents가 실무 개발팀에 어떤 의미인가”, “/in-cloud와 /babysit을 어디에 써야 하는가”, “Cursor SDK의 custom tools와 auto-review를 어떻게 운영해야 하는가”를 다룹니다. Cursor changelog에 따르면 Cloud Environment Setup, Cloud Subagents in Agents Window, Bugbot 성능 개선, Design Mode 개선, Cursor SDK의 custom stores, custom tools, auto-review, nested subagents가 포함됐습니다.
AI 코딩 에이전트를 하루만 써봐도 로컬 실행의 한계가 보입니다. 에이전트가 테스트를 돌리는 동안 노트북 팬이 돌고, 브랜치가 더러워지고, 다른 작업을 하려면 세션을 멈춰야 합니다. 의존성 설치가 오래 걸리는 프로젝트에서는 에이전트가 실제 코딩보다 환경 세팅에 시간을 더 씁니다.
Cursor의 Cloud Environment Setup은 이 문제를 정면으로 겨냥합니다. 에이전트가 클라우드에서 개발 환경을 설정하고, 의존성을 설치하고, 그 결과를 reusable snapshot으로 저장합니다. 팀이 .cursor/environment.json 같은 설정을 커밋하면 이후 클라우드 에이전트는 더 빠르게 시작할 수 있습니다.
개발팀 관점에서 장점은 명확합니다.
하지만 클라우드 환경은 공짜 점심이 아닙니다. secret, private dependency, 사내 네트워크 접근, 비용, 로그 보존 정책을 같이 설계해야 합니다.
Cursor는 /in-cloud로 클라우드 서브에이전트를 별도 VM과 별도 브랜치에서 실행할 수 있게 했습니다. 이 기능의 가치는 “병렬 작업”보다 “격리”에 있습니다.
잘 맞는 작업은 다음과 같습니다.
반대로 맞지 않는 작업도 있습니다.
좋은 사용법은 “메인 에이전트는 현재 흐름을 유지하고, 클라우드 서브에이전트는 독립적으로 증거를 모으게 하는 것”입니다. 예를 들어 로컬에서는 기능 구현을 계속하고, /in-cloud에는 “최근 실패한 CI 로그를 읽고 원인을 좁혀라. 코드 수정은 별도 브랜치에 제안만 해라”라고 맡길 수 있습니다.
Cursor changelog에는 cloud subagent가 /babysit으로 PR을 돌볼 수 있다는 내용도 있습니다. 이름은 가볍지만 실무 효용은 큽니다. PR을 올린 뒤 가장 귀찮은 시간은 리뷰 전후의 작은 반복입니다.
이런 일은 개발자의 깊은 판단보다 반복 실행이 더 중요합니다. 클라우드 에이전트가 PR을 지켜보며 실패한 체크를 읽고, 수정하고, 다시 돌리는 구조는 생산성에 직접 영향을 줍니다.
다만 자동 merge까지 허용하는 건 별개의 문제입니다. 초기 운영에서는 다음 원칙을 권합니다.
이 기준을 정하지 않으면 “에이전트가 알아서 고쳤다”가 나중에 감사하기 어려운 변경으로 남습니다.
Cursor는 Bugbot 평균 리뷰 시간이 약 5분에서 90초로 줄었고, 리뷰당 발견 버그가 0.56에서 0.62로 늘었으며, 비용은 약 22% 낮아졌다고 밝혔습니다. 숫자가 작아 보일 수 있지만 코드 리뷰 자동화에서는 꽤 의미가 있습니다.
리뷰 시간이 5분이면 개발자는 기다리거나 다른 일을 시작합니다. 90초면 push 전 확인 루틴에 넣을 수 있습니다. 비용이 22% 줄면 작은 PR에도 돌리는 부담이 낮아집니다. 발견 버그가 10% 늘었다는 점은 품질 측면의 보너스입니다.
특히 /review, /review-bugbot, /review-security처럼 push 전에 실행하는 흐름은 중요합니다. PR을 열고 나서 봇이 지적하는 것보다, push 전에 동일한 diff를 리뷰하고 PR에서는 중복 리뷰를 건너뛰는 구조가 개발자 경험이 좋습니다.
실무 적용은 간단합니다.
/review-bugbot 실행./review-security 추가.AI 리뷰 도구는 처음부터 완벽할 필요가 없습니다. 오탐률과 실제 버그 발견률을 팀이 알 수 있으면 채택 여부를 판단할 수 있습니다.
이번 Cursor SDK 업데이트에서 개발자에게 가장 실용적인 부분은 custom tools와 auto-review입니다. 이제 Agent.create()나 send()에 function definition을 넘겨 local.customTools로 노출할 수 있습니다. 별도 stdio MCP 서버나 remote HTTP MCP 서버를 세우지 않아도 됩니다.
이건 내부 자동화에 유용합니다. 예를 들어 다음 함수를 에이전트 도구로 노출할 수 있습니다.
하지만 도구를 쉽게 붙일수록 위험도 늘어납니다. 그래서 auto-review가 중요합니다. headless SDK 실행에서는 기본적으로 사람이 중간 승인하지 않는 경우가 많습니다. local.autoReview를 설정하면 tool call을 auto-review 경로로 보내고, classifier가 자동 실행할지 보류할지 판단합니다. permissions.json의 allow_instructions, block_instructions로 기준을 줄 수 있습니다.
권장 정책은 단순합니다.
Cursor SDK는 SQLite 외에 JSONL store와 custom store를 지원합니다. 이 변화는 작지만 좋습니다. 에이전트 상태 저장이 append-only JSONL이면 diff가 쉽고, CI artifact로 남기기도 좋습니다. 실패한 자동화 세션을 재현할 때도 SQLite 파일보다 읽기 쉽습니다.
nested subagents는 더 공격적인 자동화를 가능하게 합니다. 예를 들어 메인 에이전트가 “결제 모듈 리팩터링”을 맡고, 하위 reviewer subagent가 테스트 누락을 찾고, 그 아래 test-writer subagent가 테스트를 추가할 수 있습니다. 이 구조는 강력하지만 통제가 필요합니다.
팀 규칙은 다음처럼 잡는 게 안전합니다.
Cursor Cloud Agents와 SDK 업데이트는 “AI에게 더 많은 일을 맡긴다”가 아니라 “맡길 수 있는 작업과 맡기면 안 되는 작업을 분리한다”에 가깝습니다. 도입 전에 아래를 확인하세요.
.cursor/environment.json을 팀 표준으로 관리한다./in-cloud는 CI, 테스트, 조사처럼 독립 작업에 먼저 쓴다./babysit은 PR 자동 수정까지만 허용하고 자동 merge는 막는다./review-bugbot, /review-security를 push 전 루틴으로 시험한다.결론적으로 이번 Cursor 업데이트는 개발자의 IDE를 “에이전트 작업 관제실”로 바꾸는 방향입니다. 로컬에서 직접 붙잡고 있던 작업을 클라우드로 넘기고, PR 주변 반복 작업을 봇에게 맡기고, SDK 자동화를 리뷰 정책으로 묶는 흐름입니다. 제대로 쓰면 개발자는 더 빨라집니다. 대충 쓰면 권한과 브랜치가 지저분해집니다. 시작은 작게, 정책은 먼저, 자동화 범위는 숫자로 검증하는 게 안전합니다.