Cursor 3 병렬 에이전트, 내 제품에서 어떻게 쓸 수 있나

Cursor 3이 2026년 4월 2일 출시됐다. IDE 레이아웃을 버리고 여러 에이전트를 동시에 관리하는 구조로 전환했다. 변화의 핵심은 기능 목록이 아니라 빌더의 작업 방식이 어떻게 달라지는가다.

병렬 에이전트가 실제로 뭘 바꾸나

기존 Cursor에서 빌더는 에이전트 하나에 작업을 주고, 결과를 확인하고, 다음 작업을 줬다. 순서대로, 하나씩이었다. Cursor 3의 전체 화면 Agents Window는 여러 에이전트가 동시에 돌아가는 상황을 한 화면에서 보면서 필요한 것만 개입하는 구조다.

이게 실제로 의미 있는 상황은 구체적이다. 프론트엔드 UI 수정과 백엔드 API 변경을 동시에 진행해야 할 때, 서로 의존성이 없는 두 작업을 순서대로 기다릴 필요가 없어진다. 다른 예로, 새 기능 브랜치 작업을 에이전트에게 맡기면서 동시에 버그 수정 에이전트를 별도로 돌릴 수 있다.

단, 같은 파일을 두 에이전트가 동시에 수정하려 하면 충돌이 생긴다. 이 상황에서 어떻게 복구하는지, 컨텍스트가 섞이는 경우 어떻게 처리되는지는 커뮤니티에서 아직 검증이 진행 중이다. 병렬로 돌리기 전에 각 에이전트가 건드리는 파일 영역을 미리 나눠두는 것이 현재로선 안전하다.

Slack 진입점과 클라우드·로컬 에이전트 선택, 빌더에게 실제 쓸모가 있나

Slack·GitHub·Linear에서 에이전트에 지시를 보낼 수 있다는 것은 코딩 환경이 Slack으로 옮겨간다는 뜻이 아니다. 이동 중에 다음 작업을 예약하거나, 비개발 팀원이 에이전트에 직접 요청을 넣게 하는 구조다. 1인 빌더에게 실질적인 장면은 외출 중에 Slack으로 에이전트에게 다음 할 일을 던져두고, 돌아왔을 때 결과를 확인하는 것이다.

클라우드 에이전트와 로컬 에이전트의 선택도 용도가 다르다. 클라우드 에이전트는 속도가 빠르지만 코드를 직접 편집하지 않는다. 코드베이스 탐색이나 요구사항 분석처럼 결과를 보고 판단하는 작업에 맞다. 로컬 에이전트는 느리지만 파일을 실제로 수정한다. 코드 변경이 목표라면 로컬 에이전트를 써야 한다. 두 유형을 섞어 쓴다면, 분석은 클라우드로 빠르게 돌리고 실제 수정은 로컬로 이어받는 구조가 현실적이다.

Design Mode는 UI 요소를 자연어로 선택해 수정 지시하는 기능이다. 디자이너가 직접 에이전트에 레이아웃 조정을 요청하거나, 빌더가 코드를 열지 않고 시각적으로 수정 지시를 내리는 장면에서 쓸 수 있다. 아직 베타 성격이 강하므로 복잡한 컴포넌트보다 단순한 레이아웃 변경부터 시험해보는 것이 좋다.