Cursor 사용법: Projects로 팀 리뷰 큐 운영하기

Cursor Projects는 Cursor 사용법의 중심을 프롬프트 하나에서 리뷰 대기열로 옮깁니다. 2026년 9월 10일, Cursor는 코디네이터와 공유 프로젝트 컨텍스트, 반복 실행 트리거를 베타로 공개했습니다. 이제 팀은 작업마다 일일이 시작 버튼을 누르지 않고도 업무를 위임할 수 있으며, 병목은 범위 설정과 검토, 병합 여부를 결정하는 단계로 이동합니다.

이 글은 AI 코딩 도구를 팀 차원에서 운영하는 엔지니어링 리드와 기술 창업자, 에이전시 운영자를 위한 실무 중심 해설입니다. 중요한 질문은 Cursor가 AI 코딩 에이전트를 몇 개나 띄울 수 있느냐가 아닙니다. 비용과 품질에 대한 통제력을 잃지 않으면서 에이전트가 가져온 결과물을 팀이 소화할 수 있느냐가 핵심입니다.

Cursor 사용법의 새 단위, Projects란 무엇인가

Cursor Project는 기능 개발이나 마이그레이션, 앱 전체 제작처럼 하나의 작업 묶음을 장기간 운영하는 컨테이너입니다. 이 구조에서 관리자 역할을 하는 코디네이터 에이전트가 계획을 세우고 구현을 위임합니다. 다만 코디네이터가 직접 코드를 작성하지는 않습니다.

실제 코딩은 클라우드 머신에서 구현 에이전트가 맡습니다. 코디네이터는 여러 구현 에이전트를 만들어 작업을 병렬로 실행한 뒤, 검토할 결과물을 다시 가져옵니다. 자체 머신에서 테스트해야 한다면 그곳에서 로컬 에이전트를 시작할 수도 있습니다.

두 번째 요소는 공유 컨텍스트입니다. 각 Project에는 에이전트가 사용하는 클라우드 머신과 로컬 머신 사이에서 동기화되는 파일이 있습니다. 여기에 리서치, 산출물, 코드베이스 지식, 테스트 지침, 팀의 작업 방식에 관한 메모를 모아 둘 수 있습니다.

이 구조는 인수인계 방식을 바꿉니다. Project에 저장된 컨텍스트가 정확하고 최신 상태라면, 새 에이전트가 매번 테스트 명령어나 서비스 경계를 처음부터 다시 파악할 필요가 없습니다.

세 번째 요소는 구독 기능입니다. Project가 Slack 채널을 지켜보거나, 일정에 맞춰 실행되거나, 풀 리퀘스트를 추적하도록 설정할 수 있습니다. 조건에 맞는 신호가 들어오면 누군가 새 프롬프트를 작성하지 않아도 위임된 작업이 시작됩니다.

반복 실행 에이전트 자체가 Cursor에 처음 등장한 것은 아닙니다. 8월 19일 릴리스부터 Cloud Agents는 이미 풀 리퀘스트와 Slack 스레드, 일정을 모니터링할 수 있었습니다. Projects는 이 반복 작업을 하나의 코디네이터 아래에 두고, 더 긴 작업 흐름에서도 유지되는 공유 컨텍스트를 결합합니다.

이번 출시의 본질은 여기에 있습니다. Cursor는 단순히 코딩 채팅 하나를 더 제공하는 것이 아닙니다. 위임한 작업이 지속적으로 머무를 공간을 마련한 것입니다.

리뷰 대기열이 비즈니스의 핵심 결과인 이유

공유 컨텍스트를 활용하면 반복 설정을 줄일 수 있습니다. 그러나 Cursor는 속도 향상 수치를 공개하지 않았고, 이번 베타 역시 그런 수치를 뒷받침하기에는 너무 새롭습니다. 따라서 아직 절감 시간을 예산에 반영해서는 안 됩니다.

실제로 달라지는 것은 팀의 시간이 쓰이는 지점입니다. 코디네이터는 여러 경로에서 구현 작업을 병렬로 만들 수 있지만, 리뷰어 한 명은 여전히 변경 사항을 순서대로 읽어야 합니다. 이 불균형 때문에 비어 있던 백로그가 가득 찬 풀 리퀘스트 대기열로 바뀔 수 있습니다.

작업 범위가 좁고 테스트를 신뢰할 수 있으며 리뷰어가 빠르게 판단할 수 있다면 대기열은 유용합니다. 반대로 에이전트가 광범위한 diff나 중복 작업, 의도가 불분명한 변경을 돌려보내면 비용이 커집니다. 병렬로 나온 결과물도 누군가 승인하기 전까지는 재고일 뿐입니다.

모든 Cursor 사용자가 같은 영향을 받는 것은 아닙니다. 한 번에 범위가 정해진 작업 하나를 처리하는 1인 개발자라면 코디네이터의 이점이 크지 않을 수 있습니다. 테스트가 부실하거나 담당 리뷰어가 없는 팀은 처리량보다 불확실성을 더 키울 수 있습니다. 이미 반복형 Cloud Agent 자동화를 운영하는 팀에는 트리거 자체보다 공유 Project 컨텍스트가 더 큰 이점입니다.

누가 사용할 수 있고, 무엇이 달라지는가

마이그레이션을 진행하는 SaaS 엔지니어링 리드

명확한 제외 범위와 테스트 명령어, 롤아웃 규칙, 책임 경계를 갖춘 마이그레이션 하나를 Project에 맡깁니다. 코디네이터는 기계적으로 처리할 변경을 여러 구현 에이전트에 나눠 주고, 리드는 작업 순서와 위험 구간을 검토할 수 있습니다.

여러 브랜치에 걸쳐 맥락이 이어지는 것이 핵심 이점입니다. 리드는 에이전트 활동량이 아니라 승인된 변경과 리뷰 시간을 측정해야 합니다.

고객 프로젝트를 관리하는 에이전시 기술 책임자

고객 한 곳의 설정 메모와 코딩 규칙, 테스트 경로, 납품 규칙을 해당 고객의 공유 Project 컨텍스트에 보관합니다. 그러면 반복 유지보수 작업을 새 온보딩 프롬프트가 아닌 동일한 운영 지침에서 시작할 수 있습니다.

반복 설명이 줄어드는 것이 이점입니다. 다만 고객 분리는 반드시 지켜야 할 경계입니다. 한 계정의 컨텍스트와 자격 증명이 다른 계정과 공유하는 공용 저장소에 섞여서는 안 됩니다.

버그 접수를 모니터링하는 지원 엔지니어링 관리자

공개 Slack 버그 신고 채널 하나를 연결하고, 범위를 좁힌 선별 규칙을 적용합니다. 재현 절차가 있는 신고는 Project로 보내고, 질문이나 중복 신고, 계정별 사고는 사람이 계속 담당하도록 합니다.

목표는 자동 병합이 아니라 검토할 준비가 된 브랜치와 근거를 확보하는 것입니다. 현재 Cursor의 Automations 문서에 따르면 Slack 트리거는 공개 채널로 제한되며, Projects 출시 자료에는 별도의 채널 지원표가 공개되지 않았습니다.

반복 유지보수를 맡는 플랫폼 팀

Project에 반복 유지보수 흐름에 필요한 테스트 지침과 서비스 맵을 보관할 수 있습니다. 코디네이터가 풀 리퀘스트나 일정을 추적하고, 구현 결과물을 지정된 담당자에게 돌려보내도록 구성합니다.

안정적인 운영 루프를 만들 수 있다는 점이 이점입니다. 규제 대상 팀이라면 보안 검토에서 클라우드 런타임과 동기화 컨텍스트, 비밀 정보, 베타 제어 기능을 모두 다룰 때까지 기다려야 합니다.

범위를 제한한 팀 파일럿 운영법

Cursor는 Projects API나 상세한 Projects 설정 가이드를 공개하지 않았습니다. 따라서 현실적인 파일럿은 현재 보이는 베타 화면과 문서로 확인할 수 있는 관련 Cloud Agent 제어 기능만 사용해야 합니다.

1. 1

   접근 권한과 과금 확인

   Cursor 왼쪽 탐색 메뉴에서 Projects가 보이는지 확인합니다. 출시 안내에는 베타가 모든 사용자에게 순차 적용된다고 나와 있지만, Cloud Agents를 사용하려면 여전히 유료 플랜이 필요합니다. 팀 파일럿을 시작하기 전에 실제 계정에서 기능 플래그를 확인하고, 좌석 유형을 점검한 뒤, 반복 실행 트리거를 추가하기 전에 팀 전체 지출 한도를 설정합니다.

2. 2

   반복 가능한 작업 하나 선택

   저장소 하나와 종료 조건이 명확한 저위험 작업 유형 하나만 사용합니다. 테스트 명령어가 정해져 있고, diff 범위가 작으며, 결과를 판단할 담당자가 있는 작업이 적합합니다. 제품 결정을 아직 내리지 못한 마이그레이션과 권한 변경, 프로덕션 사고 대응은 첫 파일럿에서 제외합니다.

3. 3

   공유 운영 컨텍스트 작성

   Project에 저장소 맵과 설정 절차, 테스트 명령어, 완료 조건, 수정 금지 영역, 에스컬레이션 규칙을 제공합니다. 이 파일은 지속적으로 관리하는 운영 문서로 취급해야 합니다. 잘못된 공유 컨텍스트는 같은 실수를 더 효율적으로 반복하게 만듭니다.

4. 4

   접수 경로 하나 추가

   일정, 풀 리퀘스트 구독, Slack 채널 하나 가운데 하나를 선택합니다. 어떤 신호를 접수할지, 코디네이터가 무엇을 위임할 수 있는지, 어떤 근거를 결과물과 함께 반환해야 하는지, 코드를 변경하지 않고 언제 중단해야 하는지를 명시합니다.

5. 5

   리뷰 대기열 책임자 지정

   시니어 리뷰어 한 명을 지정합니다. 변경이 다음 단계로 넘어가려면 diff와 테스트 출력, 관련 산출물을 반드시 제출하도록 합니다. 베타 기간에는 병합 권한을 Project 외부에 둡니다.

6. 6

   리뷰를 통과한 작업 측정

   시작된 작업 항목, 승인된 변경, 리뷰 시간(분), 재작업, 운영으로 빠져나간 결함, 모델 사용량을 기록합니다. 파일럿 이전의 동일 작업 유형과 이 수치를 비교합니다. 에이전트 수를 생산성으로 환산해서는 안 됩니다.

리뷰 시간을 포함해 파일럿 비용 계산하기

기본 플랜 가격은 확인하기 쉽습니다. Teams Standard는 사용자당 월 $40이므로 신규 좌석 4개는 한 번의 결제 주기에 $160입니다. Teams Premium은 사용자당 월 $120이며 Standard 사용량의 5배를 제공합니다. 하지만 파일럿에서 실제 사용량 데이터가 나오기도 전에 Premium을 구매하면 테스트의 중요한 부분을 건너뛰게 됩니다.

변동 비용은 계산하기가 더 어렵습니다. Cloud Agents는 선택한 모델의 API 요금에 따라 과금됩니다. Teams와 Enterprise에는 대상이 되는 서드파티 입력·출력·캐시 토큰 100만 개당 $0.25의 Cursor Token Rate가 추가됩니다. Teams에서는 온디맨드 사용이 기본으로 활성화되며, 팀 관리자가 팀 전체 월간 한도를 설정할 수 있습니다.

아래는 모든 작업량 수치를 가정으로 명시한 제한형 모델입니다.

• 범위 가정: 저장소 하나, 트리거 하나, 리뷰 단계까지 도달하는 작업 항목 최대 20개.
• 사용량 가정: 완료된 작업 항목 하나가 코디네이터와 구현 에이전트 활동을 합쳐 Claude Sonnet 5에서 캐시되지 않은 입력 토큰 100,000개, 캐시 읽기 토큰 400,000개, 출력 토큰 20,000개를 사용하며, 캐시 쓰기 토큰은 없음.
• 리뷰 가정: 시니어 리뷰어가 반환된 항목마다 20분을 배정하며, 총 인건비는 시간당 $100.

현재 Cursor의 Claude Sonnet 5 요금을 적용하면, 모델링한 작업 항목 하나의 비용은 입력 $0.20, 캐시 읽기 $0.08, 출력 $0.20입니다. 여기에 대상 토큰 520,000개에 대한 Team 토큰 요금 $0.13이 붙습니다. 따라서 모델링한 사용료는 항목당 $0.61, 20개 항목에 $12.20입니다.

더 큰 비용 항목은 리뷰입니다. 20개 항목에 각각 20분을 배정하면 총 400분, 즉 6시간 40분입니다. 가정한 시간당 비용 $100을 적용하면 리뷰어 시간 비용은 $666.67입니다.

신규 Standard 좌석 4개의 $160을 더하고, 실제 초과 사용료로 청구되는지와 관계없이 모델링한 사용료까지 포함하면 월 총계획 비용은 $838.87입니다. 이는 청구액 예측이 아닙니다. 기존 좌석을 쓰면 $160 구매 비용이 빠지고, 포함 사용량으로 $12.20이 충당될 수 있습니다. 또한 코디네이터가 여러 에이전트에 위임할 수 있으므로 실제 Projects 작업은 토큰을 더 많이 사용할 수 있습니다.

이 모델의 요지는 리뷰 비용이 언제나 $666.67이라는 데 있지 않습니다. 리뷰에도 별도의 예산 항목이 필요하다는 뜻입니다. 파일럿이 저렴하다고 결론 내리기 전에 팀 상황에 맞게 작업 수와 소요 시간, 총 인건비를 조정해야 합니다.

제품과 구독 전반을 판단하려면 Cursor 종합 리뷰에서 에디터와 Cloud Agents, 가격, 기존 리뷰 게이트를 함께 확인할 수 있습니다.

솔직히 짚어야 할 한계

첫째, 이번 출시는 확립된 운영 표준이 아니라 베타의 순차 배포입니다. 출시 안내에는 왼쪽 탐색 메뉴가 언급되지만, Projects 전용 접근 권한표와 사용량 내역, 동시 실행 제어, 서비스 수준 약속은 제공되지 않습니다. 조달에 필요한 문서보다 기능이 먼저 열릴 수 있습니다.

둘째, 공유 컨텍스트에는 좋은 지침만큼이나 오래된 지침도 담길 수 있습니다. 지난달에는 맞았던 테스트 메모가 저장소 변경 뒤 모든 후속 에이전트를 잘못 이끌 수 있습니다. 컨텍스트 파일마다 담당자와 검토일, 삭제 규칙을 지정해야 합니다.

셋째, 코디네이터는 사용자가 검토할 작업을 반환합니다. 이것이 제품의 기본 약속입니다. 사람의 리뷰와 실행 가능한 테스트, 보안 검사, 병합 책임을 없애 주지는 않습니다.

넷째, 에이전트가 작업을 입증할 수 있는지는 여전히 환경에 달려 있습니다. Cloud Agents에는 작업에 필요한 저장소와 의존성, 비밀 정보, 시작 명령어, 네트워크 접근 권한이 필요합니다. 환경 Build에 실패하면 마지막으로 성공한 Build가 계속 활성 상태로 남지만, 불완전한 환경에서도 유효한 근거 없이 그럴듯한 코드가 만들어질 수 있습니다.

마지막으로 각 Project는 클라우드 컴퓨터에서 실행되며, 특정 머신에서만 가능한 테스트가 필요할 때 로컬 에이전트를 사용합니다. 사설망 요건이 있는 팀은 이 경계를 검토 범위에 포함해야 합니다. Cursor Self-Hosted Machines를 사용하면 툴 실행을 고객이 관리하는 워커로 옮길 수 있지만, Cursor 에이전트 루프와 모델 처리는 계속 Cursor 클라우드에 남습니다.

지금 무엇을 해야 하는가

반복 가능하고 테스트할 수 있는 작업이 있고, 베타가 표시되는 유료 Cursor 계정을 보유했으며, 시니어 리뷰어가 대기열을 감당할 여유가 있다면 이번 주에 실행에 옮겨도 됩니다. Standard 좌석부터 시작해 저장소 하나와 트리거 하나만 사용하고, 지출 한도를 엄격하게 설정합니다.

Projects가 보이지 않거나 Cloud Agent 환경에서 저장소 검증 절차를 실행할 수 없거나 리뷰 담당자가 없다면 기다리는 편이 낫습니다. 조달을 위해 Projects 전용 접근 권한 또는 과금 문서가 필요한데 Cursor가 아직 이를 공개하지 않은 경우도 마찬가지입니다.

일회성 작업이 중심이거나, 기존 에이전트 세션만으로도 컨텍스트가 충분하거나, 로컬 실행이 필수라면 거의 영향을 받지 않습니다. 여러 위임 작업 사이의 연속성이 병목일 때만 코디네이터를 둘 가치가 있습니다.

월요일에 할 일은 간단합니다. 반복 작업 유형 하나를 고르고, 파일럿의 상한을 리뷰 가능한 항목 20개로 정한 뒤, 리뷰어 한 명을 지정하고 팀 지출 한도를 설정합니다. 한 번의 결제 주기 동안 승인된 변경과 리뷰 시간(분), 재작업, 결함, 실제 사용량을 기록합니다. 모델 비용과 사람의 리뷰 대기열을 모두 계산한 뒤에도 검토를 통과한 결과물이 워크플로우를 개선할 때만 Projects를 유지합니다.

실무자를 위한 다음 AI 워크플로우 분석을 뉴스레터로 받아보세요.