Cursor 공식 문서 기준
Cursor Automations, 플랜별 요금이 달라집니다
2026년 3월 5일, Cursor가 Automations 기능을 공식 출시했습니다. 이제 GitHub PR이 열리거나 Slack 메시지가 오면 에이전트가 자동으로 실행되는데, 정작 한국어 자료는 거의 없습니다. 써보려고 켰다가 막히는 지점들, 공식 문서와 실사용 사례를 바탕으로 정리했습니다.
Cursor Automations가 뭔지, 한 문장으로
Cursor Automations는 코드베이스를 상시 모니터링하면서, 특정 이벤트가 발생하거나 스케줄이 되면 클라우드 에이전트를 자동으로 실행하는 기능입니다. 기존 Cursor의 에이전트가 “직접 요청해야 작동하는 도구”였다면, Automations는 “알아서 깨어나는 에이전트”입니다.
핵심 구조는 간단합니다. 트리거 → 클라우드 샌드박스 생성 → 에이전트 실행 → 결과 처리(Slack 알림·PR 생성 등) 순서입니다. 에이전트는 과거 실행 기록을 기억(Memories 기능)해 반복 수행을 거치며 성능이 개선됩니다. (출처: Cursor 공식 문서, cursor.com/docs/cloud-agent/automations)
Cursor 공식 블로그에 따르면, Cursor 자체 내부 코드베이스에서 현재 머지되는 PR의 35%가 클라우드 에이전트가 생성한 것입니다. (출처: Cursor 공식 블로그, cursor.com/ko/blog/third-era, 2026.02.26) 전체 PR의 3개 중 1개가 사람이 아니라는 뜻입니다.
Pro 플랜이어도 그냥은 안 됩니다
Automations를 처음 켜려고 하면 “on-demand 사용 설정을 활성화해야 한다”는 메시지를 만나게 됩니다. 많은 사람이 “Pro 구독 중인데 왜?”라고 멈추는 지점입니다. 공식 문서가 이 구조를 명확하게 설명하고 있습니다.
💡 공식 발표문과 실제 사용 흐름을 같이 놓고 보니 이런 차이가 보였습니다.
Pro $20 플랜에는 월 $20 상당의 사용 크레딧이 포함되어 있습니다. 이 크레딧은 탭 자동완성이나 일반 채팅과 공유됩니다. Automations는 클라우드 에이전트로 구동되기 때문에, 크레딧 풀에서 토큰 소비량에 따라 비용이 차감됩니다. 크레딧이 소진되면 on-demand 초과 과금이 발생합니다.
| 플랜 | 월 구독료 | 포함 크레딧 | Automations 사용 가능 |
|---|---|---|---|
| Hobby (무료) | $0 | 제한적 | ⚠️ 제한 |
| Pro | $20/월 | $20 크레딧 | ✅ 가능 (크레딧 소진 시 추가 과금) |
| Pro+ | $60/월 | 약 $70 크레딧 | ✅ 가능 |
| Ultra | $200/월 | 약 $400 크레딧 | ✅ 가능 |
| Teams | $40/사용자/월 | $20/사용자 | ✅ 가능 (과금 주체 주의) |
(출처: Cursor 공식 가격 정책, Vantage 분석 보고서 cursor-pricing-explained, 2026.03.04)
트리거 5가지, 어디에 쓰는가
Automations의 실용성은 트리거 설계에서 결정됩니다. 현재 공식 문서 기준(2026.03.05)으로 5가지 트리거 플랫폼을 지원합니다. 각각이 의미하는 실제 시나리오를 살펴보겠습니다.
GitHub
PR 열림·푸시·머지·CI 완료 등 8가지 이벤트. 보안 취약점 자동 탐지 후 Slack 알림.
Slack
채널 메시지·채널 생성 이벤트. 키워드·정규식 필터 적용 가능. 버그 리포트 자동 분류.
Linear
이슈 생성·상태 변경·사이클 종료. 이슈 발생 시 즉시 근본 원인 분석 착수.
PagerDuty
인시던트 발생·인지·해결. Datadog MCP로 로그 분석 후 수정 PR 자동 생성.
Webhook / Cron
커스텀 HTTP 엔드포인트 또는 Cron 표현식. 사내 시스템·CI 파이프라인과 직접 연결 가능. Webhook URL은 자동화를 저장해야 생성됨. (출처: Cursor 공식 문서, cursor.com/docs/cloud-agent/automations)
팀 쓰면 과금 주체가 바뀝니다
Cursor Automations에는 세 가지 권한 범위가 있고, 이게 과금 방식을 완전히 바꿉니다. 공식 문서를 그냥 읽으면 지나치기 쉬운 부분입니다.
💡 세 가지 권한 범위와 그 실제 의미
- Private: 본인만 관리. 사용량은 자동화를 만든 개인의 크레딧에서 차감됩니다.
- Team Visible: 팀원은 볼 수 있지만, 역시 개인 크레딧에서 차감됩니다. 이름은 “팀” 같지만 비용은 혼자 냅니다.
- Team Owned: 팀 어드민이 관리. 팀 공유 사용량 풀에서 차감되므로 개인 크레딧에 영향 없습니다.
실수하기 쉬운 케이스가 있습니다. PR 자동 보안 리뷰를 팀 전체 저장소에 걸어두고 Private로 설정하면, 팀 저장소 전체 PR에 에이전트가 돌면서 발생하는 비용이 모두 본인 $20 크레딧에서 나갑니다. 이 경우 하루 몇십 건의 PR이 열리는 팀이라면 순식간에 크레딧이 바닥납니다.
팀 전체가 쓰는 자동화는 반드시 Team Owned로 올리고, 팀 어드민이 팀 서비스 계정에 OAuth 연동을 별도로 설정해야 합니다. Webhook 트리거가 있었다면 Team Owned로 승격 시 Webhook API 키를 재생성해야 한다고 공식 문서에 명시돼 있습니다. (출처: Cursor 공식 문서, cursor.com/docs/cloud-agent/automations)
공식 발표문과 실제 흐름을 같이 놓고 보니 이런 차이가 보였습니다
Cursor Automations 블로그 발표에는 Bugbot을 “원조 자동화”라고 소개하는 문장이 있습니다. Bugbot은 PR이 열리거나 업데이트될 때마다 실행되고, 출시 이후 수백만 개의 버그를 잡아냈다고 Cursor가 공식 블로그에서 밝혔습니다. (출처: Cursor 공식 블로그, cursor.com/ko/blog/automations, 2026.03.05)
💡 이 수치가 말하는 것
Bugbot이 “하루에 수천 번 트리거된다”는 수치를 Automations 비용 구조에 대입하면, 활발한 팀 저장소에서 자동화를 Private나 Team Visible로 방치하면 며칠 만에 월 크레딧 전부가 소진될 수 있습니다. 수백만 버그를 잡은 것도 그만큼의 에이전트 실행이 있었다는 뜻입니다.
또 하나 주목할 부분이 있습니다. Cursor는 제3의 에이전트 아이덴티티를 명시합니다. 팀 소유 자동화가 생성하는 PR은 GitHub에서 “cursor”라는 계정 이름으로 올라갑니다. 개인 소유 자동화는 자신의 GitHub 계정 이름으로 PR을 엽니다. (출처: Cursor 공식 문서, cursor.com/docs/cloud-agent/automations) 코드 리뷰 히스토리나 저장소 책임 추적이 중요한 팀이라면 이 차이가 실무에서 혼란을 일으킬 수 있습니다.
Cursor 내부 데이터를 한 번 더 확인하면, 2025년 3월에는 Tab 사용자가 에이전트 사용자보다 약 2.5배 많았습니다. 지금은 그 반대로, 에이전트 사용자가 Tab 사용자보다 2배 많습니다. (출처: Cursor 공식 블로그, cursor.com/ko/blog/third-era) 생산성의 무게중심이 Tab에서 에이전트로 완전히 넘어갔고, Automations는 그 다음 단계입니다.
GitHub Actions랑 뭐가 다른가
“결국 GitHub Actions 아닌가?”라는 반응이 나올 수 있습니다. 솔직히 말하면, 표면적 트리거 구조는 비슷합니다. PR이 열리면 에이전트가 뭔가를 한다는 것도 같습니다. 차이는 에이전트가 실행 후 무엇을 할 수 있냐에 있습니다.
| 항목 | GitHub Actions | Cursor Automations |
|---|---|---|
| 실행 방식 | YAML 스크립트 고정 실행 | LLM이 실시간 판단 후 실행 |
| 코드 수정 | 직접 작성된 스크립트만 가능 | 근본 원인 분석 → 코드 수정 → PR까지 |
| 학습 기능 | ❌ | ✅ Memories로 실행 이력 학습 |
| 외부 통합 | Action 마켓플레이스 | MCP 서버 (Datadog, Notion, Jira 등) |
| 비용 구조 | 분당 실행 시간 기준 | 토큰 소비량 기준 (API 요금) |
GitHub Actions는 “어떻게 할지”를 YAML로 미리 정의해야 합니다. Cursor Automations는 “무엇을 원하는지”를 자연어 프롬프트로 씁니다. 에이전트가 실행 중에 코드베이스 맥락을 보고 판단합니다.
다만 GitHub Actions의 무료 티어(공개 저장소 무제한, 비공개 저장소 월 2,000분)와 달리, Cursor Automations는 플랜 크레딧 안에서 움직이기 때문에 실행 빈도가 높을수록 더 빨리 소진됩니다. 단순 반복 작업이라면 GitHub Actions가 여전히 비용 면에서 유리할 수 있습니다.
Q&A 5가지
마치며
Cursor Automations는 “코딩 보조 도구”의 개념을 꽤 크게 넘어섰습니다. PR을 열면 알아서 보안 취약점을 찾고, 버그 리포트가 Slack에 올라오면 스스로 코드베이스를 뒤져 수정 PR을 만듭니다.
다만 과금 구조를 정확히 알고 설계하지 않으면 월 크레딧이 예상보다 빠르게 소진됩니다. 팀 공용 자동화는 Team Owned 권한으로 올리는 것, Slack 트리거에는 반드시 키워드 필터를 걸어두는 것, 이 두 가지만 챙겨도 불필요한 과금을 크게 줄일 수 있습니다.
기능 자체의 완성도는 높습니다. 개인적으로는 공식 블로그에서 소개한 “주간 변경사항 요약” 자동화와 “테스트 커버리지 보완” 자동화 두 가지가 실무에서 바로 써볼 만한 케이스라고 봤습니다. 처음부터 복잡하게 만들 필요 없이, 마켓플레이스의 공식 템플릿에서 시작하는 것이 현실적입니다.
본 포스팅 참고 자료
- Cursor 공식 블로그 — Automations 발표 (cursor.com/ko/blog/automations, 2026.03.05)
- Cursor 공식 문서 — Cloud Agent Automations (cursor.com/docs/cloud-agent/automations)
- Cursor 공식 블로그 — 소프트웨어 엔지니어링 제3의 시대 (cursor.com/ko/blog/third-era, 2026.02.26)
- Cursor 공식 체인지로그 (cursor.com/ko/changelog)
- Vantage — Cursor Pricing Explained (vantage.sh/blog/cursor-pricing-explained, 2026.03.04)
※ 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. 본문의 가격 정보·기능 설명은 2026.03.31 기준이며, Cursor의 업데이트에 따라 달라질 수 있습니다. 최신 정보는 Cursor 공식 문서(cursor.com/docs)에서 확인하시기 바랍니다.
댓글 남기기