Cursor Projects 멀티플레이어 협업 가이드 (2026 베타)

2026년 11월 10일, Cursor는 Projects를 개인용 오케스트레이션 도구에서 여러 사람이 함께 쓰는 팀 작업 공간으로 바꿨다. 이제 내 코디네이터 에이전트는 팀원의 코디네이터와 직접 메시지를 주고받고, 겹치는 코드 변경을 감지하며, 끝나지 않은 pull request를 넘길 수 있다. 다만 안전하게 운영하려면 Teams 계정과 Cursor 3.26.13 이상이 필요하다. 무엇보다 공유 컨텍스트 파일의 운영 규칙을 정해 두어야 한 에이전트의 승인되지 않은 가정이 저장소 내 다른 개발자의 계획을 덮어쓰는 일을 막을 수 있다.

11월 10일 업데이트로 달라진 점: 개인 코디네이터에서 팀 협업으로

Cursor Multiplayer Projects는 2026년 9월 10일에 나온 1인용 Projects 베타를 다중 사용자 작업 공간으로 확장한 기능이다. 각 팀원은 서로 분리된 1:1 코디네이터 채팅을 운영하지만, 하나의 Task Board와 하나의 Project Agent Store(/cursor/stores/self)를 함께 사용한다. Cursor Projects 공식 문서에 따르면, 11월 10일 업데이트는 개인 실행 영역과 팀 공유 상태를 다음 8가지 기준으로 구분한다.

사용 조건과 초대 절차: 2단계로 작업 공간 만들기

Cursor Projects 문서 기준으로 멀티플레이어 Project를 공유하려면 Cursor Teams 또는 Enterprise 계정, 클라이언트 3.26.13 이상, 그리고 초대받는 각 참여자의 개별 저장소 접근 권한이 필요하다. Free, Plus, Legacy Hobby 플랜에서는 멀티플레이어 공유를 쓸 수 없다. Privacy Mode (Legacy)가 켜져 있거나, Project가 self-hosted machines에서 실행 중이거나, Project가 보관된 상태라면 팀원을 초대할 수 없다.

1단계: 기본 Project 생성하기 (4단계)

협업자를 초대하기 전, Project 소유자는 Cursor Agents Window에서 작업 공간을 초기화한다.

1. 왼쪽 탐색 메뉴에서 Projects 열기: Agents Window를 열고 사이드바의 Projects 섹션에서 New Project를 선택한다.
2. Project 이름 정하기: 아이콘을 고르고 범위와 결과물이 분명한 이름을 입력한다. 비워 두면 기본값은 New Project다. 저장소 하나에 거대한 Project 하나를 두기보다, 스키마 마이그레이션용, 여러 PR에 걸친 기능용, 반복적인 CI 유지보수용처럼 결과물 단위로 나누는 편이 낫다.
3. Workspace와 코디네이터 모델 선택: Workspace에서 대상 GitHub 저장소를 고른다. GitHub가 연결되지 않았다면 Connect GitHub를 클릭한다. Model에서는 코디네이터 역할을 맡길 모델을 선택한다.
4. Create Project 클릭: Cursor가 해당 Project용 클라우드 컴퓨터를 준비하고 코디네이터 에이전트와의 1:1 스레드를 연다.

조건을 충족하는 최상위 Cloud Agent 채팅에서 이미 작업 범위를 잡기 시작했다면, 사이드바에서 해당 채팅을 Project 행으로 드래그하거나 사이드바 메뉴에서 Add to Project를 선택하면 된다. 그러면 코디네이터가 이전 대화를 가져온다. 로컬 채팅에 이 옵션을 적용할 경우 Cursor는 추가 전에 해당 채팅을 Remote Control로 변환한다.

2단계: 팀원 초대하기 (3단계)

Project가 활성화되고 저장소에 연결되면, 소유자나 기존 Project 멤버는 문서에 안내된 다음 3단계로 팀원을 초대할 수 있다.

1. Invite 메뉴 열기: Project 상단의 Invite를 선택한다. 첫 초대 이후에는 이 컨트롤이 사람 얼굴 아이콘 행으로 바뀐다.
2. 팀원을 초대하거나 공유 링크 복사: Invite teammates to this project 아래에서 이름 또는 이메일로 팀원을 검색해 초대장을 보내거나, Copy link를 선택해 Project URL을 Slack이나 Linear에 공유한다.
3. 팀원이 수락하면 전용 채팅 생성: 초대받은 사람은 Project 초대 카드에서 Accept Invite를 클릭한다. 이후 자신의 Project 채팅, 전용 코디네이터 에이전트, 공유 Project 컨텍스트에 대한 읽기·쓰기 권한을 받는다.

멤버십과 링크 관리

접근 경계는 Cursor 팀과 Git 저장소 양쪽에서 적용된다.

• 동일 팀·저장소 접근 권한 필요: 개인 계정 사용자나 외부 Cursor 팀 소속 개발자는 참여할 수 없다. 초대된 팀원도 Project 저장소에 별도의 접근 권한을 가지고 있어야 한다.
• 유출된 링크 폐기: 초대 링크는 기존 Project 멤버만 복사할 수 있다. 링크가 지나치게 널리 공유됐다면 Project 소유자는 초대 메뉴에서 Reset Share Link를 선택해 이전 링크 사본을 모두 무효화할 수 있다.
• 나가기와 멤버 제거: 참여자는 누구나 사이드바 메뉴에서 Leave Project를 선택할 수 있으며, 유효한 초대나 링크가 있으면 나중에 다시 들어올 수 있다. Project 소유자는 초대 메뉴의 Remove로 참여자를 제거할 수 있다.

공유 컨텍스트(/cursor/stores/self)와 개인 스토어(/cursor/stores/user)의 차이

Cursor Projects Context and Personal Store 문서는 개발자 개인 설정과 팀 전체 지식을 분리하기 위해 각 에이전트 환경에 두 개의 파일 시스템 경로를 마운트한다. 공유 Project 컨텍스트는 /cursor/stores/self, 개인 사용자 스토어는 /cursor/stores/user다. 공식 스토어 규칙에 따르면 팀원이 공유 Project에 참여할 때, 코디네이터는 /cursor/stores/user의 관련 작업 선호도를 Project 규칙으로 복사할지 제안할 수 있다. 복사되는 항목은 사용자가 명시적으로 승인한 것뿐이다.

신뢰하지 않는 사이드 채팅으로 코디네이터끼리 대화하는 방식

한 코디네이터가 팀원의 작업 정보를 알아야 할 때, Cursor Projects 멀티플레이어 사양은 수신자의 일반 채팅에서 Chat with {name}'s agent라는 사이드 채팅을 분기해 해당 팀원의 코디네이터에게 직접 메시지를 보낼 수 있도록 한다. Cursor는 수신 쿼리가 상대방의 진행 중인 스레드를 방해하거나 비밀 정보를 빼내지 못하도록, 분기된 사이드 채팅이 실행할 수 있는 작업을 제한한다.

Cursor의 2026년 11월 10일 멀티플레이어 발표에서 제품 관리자 Aryaman Khandelwal은 에이전트 간 조율이 필요한 대표 사례 두 가지를 설명했다.

• UI와 기능 작업의 충돌: 한 엔지니어가 상품 페이지에 고객 리뷰를 추가하는 동안 디자이너가 같은 페이지를 새로 설계한다면, 양쪽 코디네이터가 충돌을 일찍 감지한다. 덕분에 나중에 리팩터링하는 대신 새 레이아웃에 리뷰 컴포넌트를 처음부터 통합할 수 있다.
• 스키마와 리더 구현 순서: 한 개발자가 데이터베이스 스키마를 변경하고 다른 팀원이 그 데이터베이스를 읽는 기능을 만든다면, 두 에이전트가 코딩 전에 작업 순서를 합의해 병합 시점의 통합 충돌을 피할 수 있다.

Cursor Projects 공식 문서의 How coordinators message each other 항목에 따르면, 이 교환에는 다음 네 가지 엄격한 규칙이 적용된다.

1. 외부 질의 전송: 팀원 A의 코디네이터가 팀원 B의 작업 의존성을 발견하면 팀원 B의 코디네이터에게 직접 메시지를 보낸다.
2. 분기 사이드 채팅 생성: 수신 메시지는 팀원 B의 일반 채팅에서 분기된 Chat with {Teammate A}'s agent라는 사이드 채팅을 만든다.
3. 신뢰하지 않는 입력으로 평가: 들어온 코디네이터 메시지는 에이전트 입력으로 표시된다. 수신 에이전트는 어느 팀원의 에이전트가 보냈는지 안내받으며, 이를 자신의 사용자가 직접 요청한 내용이 아니라 검토해야 할 신뢰되지 않은 자료로 취급한다.
4. 메인 채팅 지식으로 답변하고 다음 턴에 알림: 사이드 채팅은 수신자의 메인 채팅에서 이용 가능한 지식을 바탕으로 답하고, 응답을 발신 코디네이터에게 돌려준다. 팀원 B의 메인 채팅은 즉시 중단되지 않으며, 다음 턴에 이 교환에 관한 알림을 받는다.

Cursor Projects 문서는 분기된 모든 Chat with {name}'s agent 사이드 채팅의 정확한 권한 경계를 다음과 같이 정의한다.

계획부터 배포까지의 이상적 흐름과 베타 현실: 공유 의사결정이 깨지는 지점

Cursor의 공식 예시는 인수인계받는 엔지니어의 코디네이터가 진행 중인 인시던트, Linear 보드, Slack 스레드를 이어받는 사내 온콜 로테이션을 강조한다. 그러나 1인용 Projects 베타 보고서는 4단계 프로젝트 수명 주기 전반에서 팀 차원의 가드레일이 필요한 네 가지 운영 실패 유형을 보여준다.

변경 가능한 Project Notes와 '공유된 실수' 문제

Cursor Community Forum에 게시된 Cursor Projects 베타 3일간의 1인 필드 테스트에서 개발자 Lutz Leonhardt는 동기화된 컨텍스트 폴더와 오케스트레이터 대화를 조사했다. 이 테스트는 5개 세션, 약 14시간, 에이전트 20개, 작업 32개, 에이전트 턴 49회, PR 5개(4개 병합)를 다뤘다. 위임과 결과물 전달은 성공적이어서 Codex 리뷰 봇의 지적 18건을 모두 수정했지만, 프로젝트 메모리 계층에서는 공유 멀티플레이어 스토어로 확장할 경우 더 큰 위험이 되는 두 가지 실패 유형이 드러났다.

• 노트 111회 재작성, 명시적 읽기는 1회: 3일 테스트 동안 코디네이터는 전체 파일 교체 방식으로 Project Notes 파일을 111회 다시 썼지만, 명시적으로 파일을 읽은 것은 한 번뿐이었다. 1단계 마일스톤은 2일 차 보관 작업이 시작되기 전에 노트에서 사라졌고, 팟캐스트 LLM 분석에 대한 명시적 승인은 두 번의 재작성 뒤 "done"으로 축약됐다. 그 결과 코디네이터는 다음 날 같은 승인에서 다시 멈췄다.
• 승인되지 않은 기본값을 결정으로 기록: 코디네이터가 키워드 5개와 미해결 질문 3개를 나열한 뒤, 개발자는 API 키를 질문하고 Milestone 2를 시작해도 되는지 물었다. 코디네이터는 확인되지 않은 기본값을 "accepted for the start"로 간주하고 항상 실행되는 cron 어댑터를 구현하는 에이전트를 시작했다. 이는 코디네이터가 앞서 했던 조언과도 모순된다. 다른 대화에서는 이미 실행한 워커 인수인계를 받지 못했다고 부인한 뒤, 그 잘못된 이력을 컨텍스트 폴더에 워크플로 규칙으로 기록했다.

Leonhardt의 보고서는 1인용 Projects를 테스트한 것이지만, 멀티플레이어에서는 모든 팀원의 에이전트가 /cursor/stores/self를 읽고 쓴다. 즉 오염된 노트나 검증되지 않은 에이전트 기본값이 나중에 공유 스토어를 읽는 모든 팀원 에이전트에 영향을 줄 수 있다. 멀티플레이어 출시 후 개발자 @avisinghdotdev가 X에서 지적했듯이 말이다.

"솔직히 에이전트가 내 팀원 에이전트와 대화한다는 발상은 마음에 들지 않는다. 서로 다른 규칙과 스킬 세트를 쓴다면 더더욱 그렇다. 한 번의 허술한 결과물이 품질을 떨어뜨릴 수 있다." — @avisinghdotdev

멀티플레이어 Projects 권장 가드레일: 코디네이터가 /cursor/stores/self의 단일 변경 가능 Markdown 파일을 스크래치패드와 의사결정 기록으로 동시에 쓰게 두지 말자. Project 규칙에서 상태를 다음 두 파일로 분리하도록 설정하는 편이 좋다.

1. 작업 상태와 활성 브랜치 포인터를 위한 변경 가능한 plan.md.
2. append-only 에이전트 규칙으로 관리하는 저장소 커밋형 decisions.md. 엄격한 강제가 필요하다면 Git diff 검토 또는 브랜치 보호를 함께 사용한다. 이 파일에는 date, decided_by(human:@handle 대 agent:proposed), status(proposed, accepted, superseded), applies_to(파일 경로 glob), 한 줄짜리 rationale을 기록한다.

오래된 체크아웃, Cloud MCP 불일치, 로컬 Worktree 인수인계

두 번째 베타 문제 묶음은 Cursor의 클라우드 기본 실행 아키텍처에서 비롯된다. Day 7 Cursor Projects receipt와 r/cursor 스레드의 검증된 사용자 보고서를 바탕으로 보면, Projects를 도입하는 팀이 주의할 운영 함정은 네 가지다.

1. 장기 실행 Project의 오래된 Git 체크아웃: 장기 실행 클라우드 Project는 병합된 main 변경을 자동으로 pull하지 않는다(Day 7 Report R1). Cursor 직원도 이것이 의도된 동작임을 확인하며 코디네이터에게 pull하라고 요청하라고 조언했다. 멀티플레이어에서는 새 작업을 위임하기 전에 항상 코디네이터에게 git pull을 실행하도록 지시해야 한다.
2. 클라우드 전용 MCP 서버 로딩: 코디네이터는 Cloud Agent로 실행되므로 Cursor 클라우드 설정에 구성된 Model Context Protocol(MCP) 서버만 읽는다(Day 7 Report R6). 로컬 데스크톱 편집기에만 설정한 MCP 서버는 Project 코디네이터에 로드되지 않는다.
3. "No self-hosted workers available" 토글 함정: 클라우드 Project에서 로컬 테스트를 실행하려면 Settings > Agents에서 Remote Control(로컬 self-hosted workers)을 활성화하고, 저장소 루트에서 agent login 후 agent worker start를 실행한다. 그러나 Remote Control을 켜면 Self-hosted Machines도 켜지고 팀 대시보드의 Require Self-hosted Machines and Personal Machines가 활성화될 수 있다. 이 경우 Cloud Agents와 Projects가 Cursor 클라우드에서 실행되지 않는다. 하이브리드 클라우드/로컬 실행을 유지하려면 팀 관리자가 이 Require 토글을 꺼야 한다.
4. 클라우드 토큰 소비: 병렬 클라우드 서브에이전트를 10~20개 실행하면 플랜 사용량이 빠르게 소진된다. r/cursor 사용자 u/Shirc가 Reddit에서 보고했듯이 말이다.

"Projects는 가능성이 있지만, 지금은 다소 엉망이고 토큰을 엄청나게 먹는다." — r/cursor의 u/Shirc

같은 r/cursor 스레드에서 토큰 소모를 통제하는 방법으로 개발자 u/dryu12는 Composer를 코디네이터 모델로 설정하고, 어떤 위임 작업에 어떤 모델을 쓸지 명시적인 규칙을 작성하라고 권한다. 팀에서 Cursor 기본 과금 밖의 외부 CI 리뷰 봇이나 커스텀 에이전트 스크립트도 운용한다면, 해당 API 호출을 AIReiter로 연결해 DeepSeek V4.1 Flash 같은 저비용 모델과 Claude Opus 5.5 같은 리뷰어를 하나의 종량제 잔액으로 함께 사용할 수 있다.

PR 리뷰 충돌: Pull Request마다 소유자가 한 명이어야 하는 이유

Cursor Projects subscriptions 문서에 따르면, Slack 채널, PR 활동, 브랜치의 CI 실행 또는 every day at 8:00 AM 같은 일정 중 하나라도 감시하는 구독이 1개 이상 존재하면 채팅 입력창 위에 Listening 표시가 나타난다.

Leonhardt의 3일간 1인 테스트에서도 PR 리뷰 처리는 모호했다. 코디네이터, 원래 구현 워커, 새로 생성된 수정 에이전트가 모두 리뷰 이벤트에 반응할 수 있었기 때문이다. 한 PR에서는 코디네이터가 원래 에이전트가 이미 수정 중인 내용을 작성자에게 두 번 물었고, 다른 PR에서는 에이전트 3개가 같은 상태 파일을 다시 써서 잘못된 작성자가 기록됐다.

여러 팀원이 같은 저장소에서 코디네이터를 운영하는 상황에서 여러 코디네이터를 광범위한 저장소 PR 이벤트에 구독시키면, 중복 수정 커밋과 불필요한 클라우드 턴이 발생할 위험이 커진다. 개발자 @LabubuNoBB가 X에서 말했듯이 핵심은 에이전트가 대화하게 만드는 일이 아니다.

"어려운 일은 에이전트끼리 대화하게 만드는 것이 아니었다. 둘이 같은 파일을 원할 때 누가 무엇을 소유하는지 정하는 일이었다." — @LabubuNoBB

권장 PR 소유권 규칙: 공유 Task Board에서 PR마다 사람 소유자 1명과 지정 에이전트 1개를 배정한다. 해당 브랜치의 모든 리뷰 코멘트 책임도 함께 명시한다. 팀원별 코디네이터 구독은 저장소 전체 와일드카드가 아니라 자신이 맡은 PR로 제한해야 한다.

팀 도입 판단표: 공유 Project를 쓸 때와 채팅을 분리할 때

팀 워크플로를 공유 Cursor Project로 옮기기 전, 작업 구조가 3.26.13+ 베타에서 확인된 제약 조건에 맞는지 아래 표로 점검해 보자.