Cursor 3.3 첫날 켜야 하는 4가지 — Build in Parallel·Split Changes into PRs·Pin Skills·/multitask

핵심 요약 (TL;DR)

Cursor 3.3은 5월 7일 출시됐고, Claude Code Multi-agent에 정면 응수하는 4가지 기능이 핵심입니다 — Build in Parallel(async subagents 병렬 실행)·Split Changes into PRs(변경분 자동 분할)·Pin Skills as Quick Actions(skill 채팅창 고정)·/multitask 명령. 첫날 켤 때 "의존성 잘못 추론으로 race condition"과 "병렬 실행 토큰 폭증"이 두 함정만 피하면 됩니다.

어떤 도구를 켜야 할지 모르겠다면

Cursor 3.3 changelog를 처음 본 분이라면 토글이 한꺼번에 너무 많아 어디부터 만질지 헷갈릴 거예요. 5월 6일 Anthropic의 Code w/ Claude 키노트에서 발표된 Multi-agent orchestration에 Cursor가 하루 만에 응수한 결과물이라, 비슷한 추상이 두 도구에 동시에 깔린 상황이거든요.

그래서 먼저 결론부터 — 첫날에 무조건 켜야 할 건 4개입니다. 나머진 천천히 익혀도 됩니다.

1. Build in Parallel — async subagents 병렬 실행

채팅에서 plan을 세우면 그 안에 "이건 동시에 해도 되는 일"과 "이 다음에 해야 하는 일"이 섞여 있죠. 'Build in Parallel' 버튼을 누르면 Cursor가 그 의존성 그래프를 자체 추론해서, 독립적인 작업은 async subagents로 동시 실행하고 의존성 있는 단계는 순서를 지킵니다.

예를 들어 "새 결제 API 엔드포인트 추가, 마이그레이션 작성, 클라이언트 SDK 업데이트, README 갱신" 네 작업을 던지면, README와 SDK는 병렬로, 마이그레이션은 API 코드 완성 뒤에 — 이런 분배가 자동으로 됩니다.

주의점 한 가지. 이 의존성 추론이 틀리면 race condition이 납니다. 병렬 실행된 두 작업이 같은 파일을 동시에 만지는 경우가 대표적이죠. r/cursor에서 이미 "dependency graph 추론이 안 맞으면 race condition 위험"이라는 우려가 올라왔습니다. 첫날엔 plan을 한 번 검토하고 시작하시는 걸 권합니다.

2. Split Changes into PRs — AI가 너무 많이 짜놨을 때의 구원자

Cursor changelog 표기로는 "Split Changes into PRs"(통칭 PR Splitter). chat context를 분석해서 변경분을 logical slice 단위로 자동 분할하고, 백업 스냅샷을 떠둔 뒤 사용자 승인을 받아 다중 PR로 푸시합니다.

바이브코더에게 가장 직접적으로 와닿는 기능이에요. "한 채팅 안에서 인증·로깅·UI 수정을 다 해버려서 PR 하나가 1,200줄이 됐다" 같은 상황을 자주 만들거든요. 이걸 동료가 리뷰하기 좋은 3개 PR로 자동 분리해주는 거죠.

3. Pin Skills as Quick Actions — 자주 쓰는 skill을 고정

Cursor changelog 표기로는 "Pin Skills as Quick Actions"(통칭 Pinnable Skills). 자주 쓰는 skill을 채팅 입력창 옆에 quick-action pill로 고정하는 기능입니다.

작은 변화 같지만 의미는 큽니다. Cursor가 'plugin' 대신 'skill' 중심 ecosystem으로 가는 흐름의 마무리거든요. 5월 8일 Prismatic Skills for Claude Code 출시까지 합치면, 향후 1인 인디 개발자의 생산성 차이는 "누가 더 좋은 skill을 깔았느냐"에서 갈립니다.

다만 skill 마켓플레이스 자체가 OpenClaw 사건 이후 공급망 리스크 1순위 표면이 됐기 때문에, 출처 모르는 skill을 무작정 깔지 말고 화이트리스트만 pin 하시는 게 안전합니다.

4. /multitask 명령과 settings의 Explore subagent 제어

3.3에선 6개의 improvements가 추가됐는데, 그중 두 개는 첫날 만져둘 가치가 있습니다.

/multitask

채팅에 위 슬래시 명령을 치면, 한 번에 여러 task를 묶어서 던질 수 있습니다. Build in Parallel과 짝꿍이에요. "task A, task B, task C"를 한 번에 보내고 Cursor가 알아서 분배합니다.

그리고 Settings > Explore subagent 동작 제어도 켜두세요. Explore subagent는 Cursor가 코드베이스를 훑는 보조 에이전트인데, 어떤 모델로 돌릴지·어디까지 자율로 둘지를 settings에서 직접 정할 수 있게 됐습니다. 본인 코드베이스가 크면 "빠른 모델로", 보안 민감하면 "제한된 디렉토리만"으로 설정해두는 게 시작입니다.

토큰 폭증을 막는 한 가지 체크

루피가 본 가장 큰 함정은 비용이에요. async subagent가 같은 컨텍스트를 N번 곱해서 청구되는 구조라면, 4개 병렬 실행은 토큰을 4배로 씁니다. Cursor가 이걸 어떻게 산정하는지 일반 사용자 vs Pro/Business 차등이 있는지 공식 문서가 아직 명확하지 않아요. 첫 주는 사용량 대시보드를 매일 한 번씩 보면서 평소 대비 몇 배가 찍히는지 체감을 잡으시는 걸 권합니다.

Claude Code Multi-agent와 어떻게 다른가요

같은 추상을 두고 둘이 다른 위치에 자리 잡았습니다.

• Cursor 3.3 Build in Parallel: IDE 내장, 시각적 plan 검토, PR 분할까지 한 흐름.
• Claude Code Multi-agent: platform API, 외부 시스템과의 결합·서버 측 자동화에 강함.

1인 인디·UI 빌드 중심이면 Cursor 3.3, 백엔드 자동화·CI 통합이 중심이면 Claude Code 쪽이 자연스럽습니다. 둘 다 쓰는 사람도 늘고 있어요.

그래서 오늘 뭘 하면 되나요

Cursor 업데이트하고 — Build in Parallel·Split Changes into PRs를 첫 plan에서 한 번씩 직접 눌러보세요. Skill은 본인이 매주 3번 이상 쓰는 것만 핀에 고정. /multitask는 아침 "오늘 할 일 5개" 한 번에 던질 때 진가가 나옵니다. 비용은 첫 주 데일리 체크.

FAQ

Q. Build in Parallel은 어느 모델에서 동작하나요?
Cursor 공식 changelog는 모델 제한을 명시하지 않았습니다. 다만 의존성 그래프를 모델이 추론하는 구조라 추론력이 약한 작은 모델에선 race condition 위험이 큽니다. 첫날엔 Sonnet/Opus 같은 상위 모델로 돌리시는 걸 권합니다.

Q. 비용이 늘어나나요?
병렬 실행이 같은 컨텍스트를 N번 처리하는 구조면 토큰 사용량이 비례 증가할 수 있습니다. 공식 청구 정책이 추가 공개되기 전까진 첫 주 사용량 대시보드를 매일 확인하는 게 안전합니다.

Q. PR Splitter가 만든 PR 사이에 의존성이 있으면요?
분할된 PR끼리 의존성이 있다면 stack PR 형태로 표시돼야 안전합니다. 현 시점 changelog는 stack 표기 지원 여부를 명시하지 않았기 때문에, 첫 사용에선 분할 결과를 한 번 직접 검토하시고 푸시 순서를 본인이 정하시는 게 좋습니다.

원본: Cursor changelog · Cursor Forum 3.3 스레드