Cursor Cloud Agent vs 로컬 Agent, 언제 무엇을 쓰나

Cursor Cloud Agent와 로컬 Agent(에디터 사이드페인 채팅)는 같은 에이전트 기본기(지시·도구·모델)를 쓰지만 실행 장소가 다릅니다. 클라우드는 격리된 VM에서, 로컬은 지금 열린 워크스페이스에서 돌아갑니다. 가격·플랜·사용 후기는 다루지 않습니다.

이 글은 버튼 나열이 아닙니다. PR·장시간 작업에 Cloud를 쓸지, 대화형 수정에 로컬을 쓸지, 그리고 결과가 오면 어떻게 넘길지만 정리합니다. 근거는 Cursor Cloud Agents와 Agent 개요입니다.

Cloud Agent가 잘하는 일?

한 줄 답: 노트북을 붙잡아 두지 않아도 되는 장시간·병렬·브랜치/PR 산출 작업에 맞습니다. 격리 VM에서 빌드·테스트·데스크톱/브라우저 조작까지 닫을 수 있습니다.

공식 문서 기준으로 Cloud가 강한 축:

축왜 Cloud인가
실행 장소격리 Ubuntu VM. 로컬 머신 전원·네트워크에 묶이지 않음
병렬여러 Cloud Agent를 동시에 돌릴 수 있음
산출물별도 브랜치에서 작업 후 원격에 push·PR 핸드오프
검증환경만 갖추면 빌드·테스트·아티팩트(스크린샷·로그)까지
진입점Desktop(Cloud 선택), cursor.com/agents, Slack·GitHub/Linear @cursor, API 등

실무에서 Cloud를 고르는 신호:

  1. 이슈 → PR처럼 “끝나면 리뷰할 브랜치”가 목표인 경우.
  2. 수십 분 이상 돌 가능성이 있어 로컬 채팅을 붙잡고 싶지 않은 경우.
  3. 로컬에 없는 의존성·시크릿·네트워크를 Cloud 환경(.cursor/environment.json·Secrets·MCP)에 이미 맞춰 둔 경우.
  4. 슬랙/이슈 트래커에서 멘션으로 바로 킥오프하고 싶은 경우.
  5. 멀티 레포 변경이 필요해 한 에이전트가 여러 클론을 다루는 경우(문서는 multi-repo를 지원한다고 안내; long-running은 multi-repo에서 아직 제한될 수 있음).

환경이 비어 있으면 Cloud는 “코드만 쓰는 원격 노트북”에 가깝습니다. 문서도 환경 셋업이 효과의 핵심이라고 강조합니다. install 스크립트·Dockerfile·Secrets를 먼저 맞춘 뒤 장시간 작업을 넘기는 편이 안전합니다.

로컬이 나은 경우?

한 줄 답: 지금 열린 파일·터미널·체크포인트를 붙잡고 짧게 대화하며 방향을 트는 작업은 로컬 Agent가 낫습니다.

로컬(사이드페인 Agent)이 유리한 축:

축왜 로컬인가
컨텍스트미저장 버퍼, 로컬-only 파일, 지금 켠 디버거·디바이스
피드백 루프한 문장 follow-up으로 즉시 스티어링(큐·Steer)
롤백세션 Checkpoints로 Agent 변경만 되돌리기(Git과 별개)
비밀·정책~/.cursor 사용자 훅·로컬 키체인·보드/USB 등 VM에 없는 것
탐색“이 함수가 어디 쓰이지?”처럼 질문→소수정정이 빠른 경우

로컬을 고르는 신호:

  1. 설계·범위가 아직 흐릴 때 — Plan/Ask에 가깝게 묻고, 합의 후 작은 패치.
  2. 하드웨어·에뮬레이터·사내 VPN 전용 도구가 로컬에만 있을 때.
  3. 미커밋 실험을 체크포인트로 되돌리며 반복할 때.
  4. Cloud 환경에 아직 install/테스트 재현이 안 될 때 — 먼저 로컬에서 재현 명령을 고정.
  5. 팀 규칙상 원격 VM에 올리면 안 되는 시크릿·데이터가 작업에 섞일 때.

로컬 Agent도 터미널·브라우저·편집 도구를 씁니다. 차이는 “할 수 있느냐”보다 누구의 머신·세션에 붙어 있느냐입니다. 노트북을 닫으면 로컬 세션의 장시간 루프는 끊기기 쉽고, Cloud는 그 반대입니다.

핸드오프는 어떻게 하나?

한 줄 답: Cloud는 브랜치/PR·아티팩트·에이전트 URL로 넘기고, 로컬은 diff·재현 명령·짧은 인수인계 노트로 Cloud(또는 사람 리뷰)에 넘깁니다. 한쪽에만 컨텍스트를 가두지 않습니다.

로컬 → Cloud

  1. 로컬에서 재현 명령·실패 로그·스코프(경로)·비목표를 한 덩어리로 적습니다.
  2. 필요하면 이슈/Linear에 붙이거나, Cloud 킥오프 프롬프트 첫머리에 그대로 넣습니다.
  3. Cloud 환경에 같은 재현이 되는지 Secrets·install을 확인합니다.
  4. Desktop에서 Cloud를 고르거나 cursor.com/agents·@cursor로 시작합니다.
  5. 완료 후 PR·브랜치·아티팩트를 리뷰하고, 로컬에서는 checkout 없이 remote desktop으로 검증할 수도 있습니다(문서의 artifacts / remote desktop).

프롬프트 뼈대 예:

Goal: open a PR that <outcome>.
Repro (must exit 0 when done):
  <command>
Scope: <paths>
Out of scope: <list>
Notes from local session:
  <1–5 bullets: root cause hypothesis, files already tried>

Cloud → 로컬

  1. PR/브랜치를 pull(또는 리뷰 UI에서 diff 확인).
  2. CI·아티팩트·에이전트 대화 URL을 로컬 채팅에 @/링크로 넘깁니다.
  3. 남은 일(네이밍·엣지 케이스·로컬-only 검증)만 로컬 Agent에 맡깁니다.
  4. 시크릿이 Cloud Secrets에만 있으면, 로컬 재현 전에 같은 값이 로컬에 있는지 확인합니다(문서: 실행 중 Agent는 나중에 추가한 Secret을 자동으로 안 받음 → 새 런 필요).

역할 나누기 한 장

단계담당
모호한 요구 정리·파일 탐색로컬
장시간 수정·테스트·PR 초안Cloud
보드/USB·미저장 버퍼 검증로컬
팀 공유·리뷰 링크Cloud 에이전트 URL / PR

이름은 예전에 Background Agents였고 지금은 Cloud Agents입니다. UI·문서에서 옛 이름이 보이면 같은 계열로 보면 됩니다.

마무리

Cursor Cloud Agent는 격리 VM·병렬·브랜치/PR·원격 검증에 강하고, 로컬 Agent는 열린 워크스페이스·즉시 스티어링·체크포인트·로컬-only 자원에 강합니다. 선택 축은 기능 목록이 아니라 장시간/PR이냐, 짧은 대화형 수정이냐입니다. 핸드오프는 재현 명령·스코프·PR/아티팩트를 양쪽으로 명시하면 됩니다.

출처