Cursor 3, IDE를 버렸다. 컨텍스트 전환이 새 병목이다

Cursor 3가 2026년 4월 2일 출시됐다. IDE 보조 도구에서 에이전트 오케스트레이터로 포지션을 바꿨다. Slack·GitHub·Linear 등 6개 외부 진입점을 추가했고, 클라우드와 로컬 에이전트를 즉시 전환하거나 병렬로 돌릴 수 있게 됐다. 바이브 코딩이 성숙하면서 병목이 코드 생성 속도에서 도구 간 이동 비용으로 옮겨간 것에 대한 응답이다.

무엇이 바뀌었나 — IDE 탈출, 오케스트레이터 진입

Cursor 2까지는 에디터 안에서 AI 보조를 받는 구조였다. 코드를 짜는 속도가 올라갔지만, 작업 흐름은 그대로였다. Slack에서 이슈를 확인하고, GitHub에서 PR을 열고, Linear에서 태스크를 닫는 사이클은 별개였다.

Cursor 3는 그 경계를 없애는 쪽으로 설계됐다. Slack·GitHub·Linear를 포함한 6개 진입점이 IDE 외부에서 직접 에이전트를 실행할 수 있게 연결됐다. 클라우드 에이전트(속도 우선)와 로컬 에이전트(비공개 코드베이스·보안 우선)를 필요에 따라 즉시 전환하거나 병렬로 돌릴 수 있다.

1인 빌더 기준으로 실질적인 변화는 이렇다. 하루에 Cursor ↔ Slack ↔ GitHub ↔ Linear를 오가는 횟수가 줄어든다면, 같은 산출물에 드는 시간이 줄어든다. AI 코딩 보조가 일반화된 지금, 남은 병목은 코드를 더 빨리 생성하는 것이 아니라 도구 사이를 오가는 비용이었다는 진단이 Cursor 3의 출발점이다.

클라우드 vs 로컬 — 1인 빌더가 골라야 할 트레이드오프

클라우드 에이전트와 로컬 에이전트의 선택은 단순한 속도 문제가 아니다. 클라이언트 코드베이스, 내부 데이터, 비공개 API 키가 포함된 프로젝트라면 클라우드로 보내는 것 자체가 리스크가 된다. Cursor 3가 로컬 옵션을 명시적으로 분리한 것은 이 장벽을 의식한 설계다.

멀티 에이전트 병렬 운용은 복합 워크플로우를 다루는 빌더에게 실질적 변화가 될 수 있다. 단, 오케스트레이션도 설계 역량을 요구한다. 어떤 에이전트에 어떤 작업을 맡길지, 결과를 어떻게 검증할지는 여전히 빌더 몫이다. 도구가 바뀌었다고 해서 프로세스가 자동으로 따라오지는 않는다.