커서 프로젝트(Cursor Projects)란 무엇인가? 에이전트 모드 및 플랜 모드와의 완벽 비교

안녕하세요, Hoda입니다.

커서(Cursor)가 2026년 9월 10일(미국 시간)에 발표한 새로운 기능인 “프로젝트(Projects)“는 기존의 에이전트 모드(Agent Mode)나 플랜 모드(Plan Mode)의 단순한 확장이 아닙니다. 이는 작업의 단위로서 ‘하나의 채팅’이라는 개념 자체를 깨부수는 기능입니다. 결론부터 말씀드리면, 둘의 차이는 다음과 같습니다.

• 에이전트 모드 / 플랜 모드 / Ask 모드 → 단일 채팅(하나의 세션) 내에서 단일 에이전트가 어떻게 동작할지 결정하는 모드 전환
• 커서 프로젝트(Cursor Projects) → ‘채팅’ 단위를 완전히 벗어나 장기적으로 전체 작업 흐름을 아우르는 관리 레이어

그 차이점에 대해 아래에서 좀 더 자세히 파헤쳐 보겠습니다.

커서 프로젝트(Cursor Projects) 개요

프로젝트는 기능 개발, 마이그레이션, 혹은 전체 앱 구축 등 몇 주에서 몇 달에 걸쳐 진행되는 대규모 작업을 위해 만들어졌습니다. 왼쪽 내비게이션에서 프로젝트를 시작하고 만들고자 하는 바를 알려주면, 그 시점부터 “코디네이터(coordinator)“라는 에이전트가 인계받아 작업을 진행합니다.

IDE 내부가 아니라 클라우드 에이전트를 통해 실행되므로, 먼저 Agent Window을(를) 열고 그곳에서 선택해야 합니다.

다음과 같이 새로 생성할 수 있습니다.

여기서 중요한 점은 코디네이터 자체는 절대 코드를 직접 작성하지 않는다는 것입니다. 코디네이터의 역할은 오로지 계획을 세우고, 클라우드에서 실행되는 별도의 하위 에이전트(subagent)에게 실제 구현을 위임하며, 완성된 작업물(초안 PR)을 검토용으로 사용자에게 돌려주는 것뿐입니다. 실행을 기다리며 대기 상태에 빠지지 않기 때문에, 사용자가 보내는 추가 지시사항에는 언제나 즉각적으로 응답할 수 있습니다.

클라우드에서 실행되므로 노트북을 덮은 후에도 목표를 향해 자동으로 작업을 계속 진행합니다.

프로젝트의 기반에는 세 가지 메커니즘이 자리 잡고 있습니다.

에이전트 모드 / 플랜 모드 / Ask 모드와의 차이점

아마 가장 궁금해하실 부분일 텐데요, 표로 정리해 드립니다.

즉, 에이전트 모드와 플랜 모드의 차이는 실질적으로 동일한 단일 작업 내에서의 단계 차이일 뿐입니다. 구현 전에 계획 승인 단계를 거치느냐 마느냐의 차이일 뿐, 결국 작업을 수행하는 에이전트는 동일합니다.

반면 프로젝트는 “단일 작업”이라는 전제 자체를 없애 버리고, 훨씬 더 거대한 “작업물”을 위해 승인, 위임, 메모리 시스템 전체를 도입합니다. 플랜 모드에서 세우는 계획이 하나의 작업을 위한 설계도라면, 프로젝트에서의 공유 컨텍스트는 프로젝트가 진행되는 동안 계속해서 커져가는 운영 매뉴얼에 가깝습니다.

세 가지 핵심 메커니즘 자세히 살펴보기

클라우드 실행 (기본적으로 클라우드, 필요할 때만 로컬) 프로젝트는 전용 클라우드 환경에서 실행되므로 본인의 컴퓨터가 절전 모드에 들어가도 작업은 계속 진행됩니다. 테스트가 로컬 환경에서 반드시 재현되어야 할 때만 코디네이터가 로컬 에이전트를 구동합니다.

공유 컨텍스트 각 프로젝트는 클라우드와 로컬을 막론하고 작업을 수행하는 모든 에이전트 간에 동기화 상태를 유지하는 파일 세트를 보관합니다. 한 에이전트가 특정 서비스를 테스트하는 방법을 알아내면, 그 이후의 모든 에이전트는 동일한 파일을 참조하여 같은 단계를 따를 수 있습니다. 이 데이터가 쌓일수록 코디네이터의 정확도가 시간이 지날수록 높아진다는 개념입니다.

구독(Subscriptions) 특정 슬랙 채널, PR 생성 또는 병합, 고정된 일정 등 감시 조건을 설정할 수 있으며, 조건이 충족되면 사람이 추가 지시를 내릴 때까지 기다리지 않고 작업이 시작됩니다.

이것의 기반은 클라우드 에이전트의 모니터링 기능(자동화)입니다. 프로젝트는 그러한 기능을 코디네이터 산하로 편입하고 공유 컨텍스트와 결합한 형태로 볼 수 있습니다.

어떤 작업에 적합한가?

커서 자체에서는 다음과 같은 세 가지 유스케이스를 언급합니다.

• 기능 개발: 연구, 계획, 병렬 구현 및 테스트, 심지어 출시 후 버그 수정에 이르기까지 전체 과정의 처음부터 끝까지 하나의 프로젝트가 담당하며, 전 과정에 걸쳐 컨텍스트를 유지합니다.
• 마이그레이션: “시작하기는 쉽지만 끝내기는 어려운” 작업. 처음에는 각 PR을 엄격하게 검토하다가 상황이 안정됨에 따라 더 많은 부분을 코디네이터에게 위임합니다.
• 가드닝(Gardening): 끝이 없는 지속적인 품질 관리 및 회귀 모니터링. 새로운 PR을 지속적으로 스캔하고, 동일한 실수가 반복해서 발생할 경우 향후 이를 잡아낼 수 있도록 린트(lint) 규칙을 추가하도록 합니다.

반대로 생각하면, 단일 버튼의 색상만 고치는 정도라면 프로젝트를 열 이유가 없습니다. 일반 에이전트 모드로도 충분합니다.

가격 정책

2026년 9월 기준으로, 프로젝트 자체에는 별도의 가격표가 붙어 있지 않으며 유료 플랜 사용자에게 베타 기능으로 제공됩니다. 다만 클라우드 에이전트 인프라를 기반으로 구동되므로, 선택한 모델에 적용되는 API 비용은 여전히 청구됩니다. 커서 측에서 언급하듯 가령 5개의 하위 에이전트를 병렬로 실행하는 것은 단순 계산으로 토큰 사용량이 약 5배 늘어난다는 뜻이며, “수천 개의 하위 에이전트”는 모든 작업에 실제로 필요한 것이 아니라 상한선을 의미합니다.

도입 전 확인할 사항

• 단일 저장소와 단일 종류의 작업부터 먼저 시작하세요.
• 프로덕션 배포 및 결제 관련 사항은 자동 권한 범위에서 제외하세요.
• 프로젝트별 공유 컨텍스트 파일들을 주기적으로 검토하세요. 내부에 방치된 오래된 지시사항은 동일한 잘못된 판단을 반복하게 만들 수 있습니다.
• 슬랙이나 일정 기반 시작의 트리거 조건을 좁게 유지하고 오작동 여부를 모니터링하세요.
• 모든 결과물이 초안 PR 형태로 돌아온다는 전제를 느슨하게 만들지 마세요. 병합 권한은 인간의 손에 유지해야 합니다.

요약

• 에이전트 모드 / 플랜 모드 / Ask 모드는 단일 채팅 내에서 단일 에이전트가 어떻게 동작할지 결정하는 “모드”입니다.
• 커서 프로젝트는 코디네이터와 공유 컨텍스트를 활용하여 (여러 PR이나 작업에 걸치는) 전체 “작업물”을 장기적으로 관리하는 별도의 레이어입니다.
• 둘 사이의 가장 큰 차이는 실제로 작업을 구현하는 주체가 누구인가에 있습니다. “직접 대화하는 상대”(에이전트 모드) 대 “위임받은 하위 에이전트”(프로젝트).
• 기능 개발, 마이그레이션, 지속적인 유지보수에 적합합니다. 작고 일회성인 수정 작업의 경우, 여전히 일반 에이전트 모드 하나면 충분합니다.

사이트 내의 별도 아티클에서 플랜 모드에 대해 더 자세히 다루었으니, 관심 있으신 분들은 그 글도 함께 확인해 보세요.