Cursor Automations가 뭔지 30초 만에 파악하기

Cursor Automations는 2026년 3월 5일 Anysphere가 공식 출시한 기능입니다. (출처: cursor.com/ko/blog/automations) 쉽게 말하면, 개발자가 직접 프롬프트를 입력하지 않아도 특정 이벤트가 발생하면 AI 에이전트가 백그라운드에서 알아서 코드 작업을 수행하는 구조입니다.

기존 Cursor 에이전트 방식은 “프롬프트 입력 → 결과 확인 → 다시 입력”의 반복이었는데, Automations는 이 루프를 끊어냅니다. GitHub PR이 열리면 보안 검토를, Slack에 버그 메시지가 올라오면 로그를 분석해서, PagerDuty 알림이 뜨면 원인 분석까지 자동으로 처리합니다.

Cursor CEO Michael Truell은 2026년 2월 “Third Era” 블로그 포스트에서 현재 에이전트 사용자 수가 Tab 완성 사용자 수를 2:1로 역전했다고 밝혔습니다. (출처: cursor.com/blog/third-era) 1년 전만 해도 Tab 사용자가 에이전트 사용자보다 2.5배 많았는데, 완전히 뒤집힌 것입니다. 비율 역전이 반년도 안 걸렸습니다.

Pro $20으로 못 쓰는 이유 — 클라우드 에이전트의 실제 청구 구조

Cursor Automations를 막상 켜보면 바로 느끼는 것이 하나 있습니다. “왜 이렇게 크레딧이 빠르게 줄지?” 공식 문서에 나와 있는 이유가 있습니다. 클라우드 에이전트는 기본적으로 MAX 모드로 실행됩니다. (출처: Reddit r/cursor, 2026.03.15, 사용자 dryu12 확인)

Vantage의 분석 자료에도 이 구조가 나와 있습니다. 2025년 6월 이전 구형 Pro 플랜은 한 달에 고속 요청 500건을 제공했습니다. 크레딧제로 전환된 이후에는 $20짜리 크레딧으로 모델과 프롬프트 길이에 따라 200~300건 수준으로 줄었습니다. (출처: vantage.sh, 2026.03.04) 겉보기엔 같은 $20 플랜인데 실제 사용 가능 횟수가 최대 60% 줄어든 셈입니다.

Automations 공식 문서에는 요금 청구 방식을 이렇게 설명합니다. “자동화는 클라우드 에이전트를 생성하며, 클라우드 에이전트 사용량을 기준으로 요금이 청구됩니다.” (출처: cursor.com/ko/docs/cloud-agent/automations) 즉, 자동화가 실행될 때마다 클라우드 에이전트 실행 비용이 발생하며, 이것이 크레딧 풀에서 차감됩니다.

현재 환경 설정(Environment setup) 비용은 무료입니다. 공식 문서에는 “환경 설정은 항상 opus-4.6을 사용하며 무료”라고 나와 있습니다. (출처: Reddit r/cursor, 사용자 dryu12, 2026.03.15) 단, 이 정책은 이후 바뀔 가능성이 있으며 Cursor 측이 별도 공지를 내놓지 않은 상태입니다.

트리거 7종 완전 정리 — 어떤 이벤트에 반응하나

Cursor Automations의 핵심은 트리거입니다. 공식 문서 기준으로 현재 지원되는 트리거는 예약(cron), GitHub, Slack, Webhook, Linear, PagerDuty, 이렇게 총 5개 카테고리에 세부 항목까지 합치면 10개 이상의 이벤트를 지원합니다. (출처: cursor.com/ko/docs/cloud-agent/automations)

예약 트리거는 cron 표현식을 지원합니다. “매 시간”, “매일 오전 9시”, “매주 월요일”처럼 반복 실행이 가능하고, 더 세밀한 제어가 필요하면 직접 cron 표현식을 입력할 수 있습니다. 예약 트리거는 지정 시각보다 일찍 실행되지는 않지만, 지연될 수는 있다고 공식 문서에 명시되어 있습니다.

GitHub 트리거는 가장 실용적입니다. PR이 열릴 때, 기존 PR에 커밋이 푸시될 때, PR이 병합될 때, 댓글이 달릴 때, 특정 브랜치에 push가 발생할 때, CI가 완료될 때 등 여섯 가지 이벤트를 지원합니다. 코드 리뷰 자동화나 병합 후 보안 스캔에 바로 쓸 수 있는 구성입니다.

Slack 트리거는 채널에 새 메시지가 올라올 때 반응합니다. 키워드 필터나 정규식으로 조건을 좁힐 수 있고, 스레드 답글에도 반응하게 하려면 필터를 명시적으로 추가해야 합니다. 스레드 자동 반응이 필요한 사용자가 놓치기 쉬운 부분입니다.

Webhook 트리거는 자동화당 비공개 HTTP 엔드포인트를 하나 생성합니다. 내부 CI 파이프라인, 모니터링 도구, 커스텀 시스템과 연결할 때 씁니다. Webhook URL은 자동화를 저장해야 발급되고, 인증용 API 키도 함께 생성됩니다.

PagerDuty 트리거는 인시던트 발생, 확인, 해결 세 가지 이벤트를 지원합니다. 프로덕션 알림이 뜨면 Datadog MCP로 로그를 조회하고 원인을 파악해 Slack에 요약을 올리는 플로우가 공식 블로그 데모에 소개됐습니다. 이 시나리오 하나가 Cursor 내부에서 이미 실사용 중입니다.

Team Owned 설정이 팀장에게 독이 되는 이유

Cursor Automations의 권한 설정에는 세 가지 옵션이 있습니다. 비공개(Private), 팀 공개(팀원이 볼 수 있지만 관리는 본인), 팀 소유(Team Owned). 여기서 Team Owned를 선택하면 비용 구조가 완전히 달라집니다. (출처: cursor.com/ko/docs/cloud-agent/automations)

반면 Private나 팀 공개 설정은 자동화를 만든 본인 크레딧에서 차감됩니다. 팀 소유로 설정하면 공유 팀 서비스 계정으로 실행되고 팀의 사용량 풀에서 청구되는 방식입니다. 팀원 10명이 각자 자동화를 몇 개씩 만들어 팀 소유로 전환해두면, 팀장이 모르는 사이에 팀 크레딧 풀이 빠르게 소진될 수 있습니다.

또 한 가지 주의점이 있습니다. 비공개나 팀 공개 상태에서 팀 소유로 전환하면 실행 주체가 바뀝니다. 공식 문서는 이렇게 설명합니다. “더 이상 본인의 인증을 사용하지 않고 팀의 공유 Automations 서비스 계정을 사용하기 시작합니다.” Webhook 트리거를 쓰고 있었다면 범위 변경 후 반드시 Webhook API 키를 다시 발급해야 합니다. 이 과정을 빠뜨리면 기존 자동화가 인증 오류로 작동하지 않게 됩니다.

Teams 플랜 사용자라면 공식 문서의 권한 설정 섹션을 꼭 읽고 시작하는 걸 권장합니다. 팀 관리자만 자동화를 Team Owned로 승격할 수 있지만, 일단 승격되면 비용 제어권은 관리자 손에 달리게 됩니다.

GitHub Copilot Agentic과 결정적으로 다른 점 하나

Cursor Automations가 나온 같은 날, OpenAI는 GPT-5.4를 발표했습니다. 경쟁 구도를 보면 GitHub Copilot의 “Agentic Workflows”와 비교가 불가피합니다. 차이는 분명합니다. GitHub Copilot Agentic Workflows는 2026년 2월 13일 Technical Preview로 공개됐고, 아직 프로덕션에서 event-triggered 방식으로 동작하지 않습니다. (출처: github.blog/changelog)

Copilot Agentic은 여전히 개발자가 GitHub 이슈에서 시작해 계획을 생성하고 변경 사항을 리뷰하는 방식으로, 사람이 시작점을 만들어야 합니다. Cursor Automations는 아무도 프롬프트를 입력하지 않아도 트리거가 발동하면 에이전트가 자율적으로 실행됩니다. 이 차이가 실무에서는 꽤 크게 느껴집니다.

IDE 통합 측면에서도 차이가 납니다. Copilot은 VS Code 플러그인 형태로 동작하지만, Cursor는 VS Code를 포크해 직접 만든 에디터입니다. 2026년 3월 4일에는 JetBrains와 ACP(Agent Client Protocol)로 연동을 시작했습니다. (출처: cursor.com/ko/changelog/03-04-26) IntelliJ IDEA, PyCharm, WebStorm에서도 Cursor 에이전트를 쓸 수 있게 된 것입니다.

요금 비교도 냉정하게 봐야 합니다. GitHub Copilot Pro가 월 $10인 반면 Cursor Pro는 $20입니다. 단순 자동완성만 필요하다면 Copilot이 반값입니다. Automations 같은 완전 자율 에이전트 워크플로우가 필요할 때 Cursor의 프리미엄이 정당화됩니다.

실제로 쓸 만한 시나리오와 쓰면 안 되는 상황

공식 블로그와 실사용 사례를 교차하면 쓸 만한 시나리오가 선명해집니다. 보안 취약점 스캔, PR 리뷰 자동화, 인시던트 대응, 주간 코드베이스 요약은 검증된 사용 사례입니다. Cursor 내부에서 이미 수백 건/시간 단위로 실가동 중이고, Rippling 같은 엔터프라이즈 사용 사례도 공식 블로그에 실명으로 소개됐습니다.

Rippling의 경우, 2시간마다 Slack, GitHub PR, Jira 이슈, 회의 메모를 취합해서 개발자 개인별 대시보드를 만드는 자동화를 운영 중입니다. (출처: cursor.com/ko/blog/automations) 이 정도 복잡도의 주기적 업무를 사람이 직접 할 때 절감되는 시간이 하루 30분이라면, 월 $20이 금방 뽑힙니다.

반면 조심해야 할 상황도 있습니다. 가장 큰 주의 사항은 비용 모니터링 없이 Heavy 자동화를 켜두는 것입니다. 실사용자 중에는 일주일 만에 $350 이상의 크레딧을 소진했다는 보고가 있습니다. (출처: byteiota.com, 2026.03.08) 처음 시작할 때는 읽기 전용(코드를 직접 바꾸지 않고 분석·리포트만 하는) 자동화부터 5~10회 실행해보며 비용 감각을 먼저 익히는 게 맞습니다.

기업 도입 시에는 보안 검토도 필요합니다. 일부 기업 CISO들이 DLP 계획, 테넌트 격리, SOC 2 컴플라이언스 확인을 요구하고 있습니다. 또한 Cursor의 텔레메트리 정책상 회사 구독에서 커밋 정보가 Cursor 서버로 전송되는 것을 완전히 차단하기 어렵다는 지적도 있습니다. 민감한 코드베이스를 다루는 팀이라면 도입 전에 이 부분을 별도로 확인해야 합니다.

공식 문서가 권장하는 실전 원칙은 명확합니다. 에이전트가 main 브랜치에 직접 머지하지 못하게 하고, 고위험 결정은 사람에게 에스컬레이션하도록 지침에 명시하며, 메모리 기능을 활용해 5~10회 실행 후 자동화가 스스로 개선되도록 두는 것입니다. 그래야 자동화가 오히려 팀의 부담이 되는 상황을 막을 수 있습니다.

자주 묻는 질문 5가지

마치며 — 총평

Cursor Automations는 “AI가 알아서 코드 일을 해준다”는 약속을 가장 구체적으로 실현한 기능입니다. Bugbot이 매달 200만 건 PR을 처리하고, 내부에서 하루 수백 건의 자동화가 돌아가고 있다는 사실은 그냥 마케팅 문구가 아닙니다.

솔직히 말하면, 지금 당장 Pro $20으로 Heavy하게 쓰기엔 비용 구조가 불투명한 부분이 있습니다. 클라우드 에이전트 MAX 모드 강제 적용, 모델 이름 불일치로 인한 청구 혼란, 팀 소유 설정 시의 예상치 못한 비용 공유 — 이 세 가지를 모르고 들어가면 예산이 생각보다 빠르게 나갑니다.

그래도 방향은 맞습니다. 개발자가 반복 작업에서 벗어나 복잡한 문제에 집중하는 구조, 그걸 실제 프로덕션 환경에서 구현한 건 Cursor Automations가 현재로선 경쟁사 중 가장 앞서 있습니다. GitHub Copilot Agentic이 아직 Technical Preview인 상황이라는 점을 생각하면 더욱 그렇습니다.

시작은 읽기 전용 자동화 한 개, 주간 코드 요약 정도가 적당합니다. 비용 패턴을 파악한 뒤 점점 확장해 나가는 게 손해 없이 이 기능을 체득하는 가장 현실적인 방법입니다.

📚 본 포스팅 참고 자료

1. Cursor 공식 블로그 — Automations 출시 발표 (2026.03.05)
2. Cursor 공식 문서 — Automations 트리거·요금·설정 가이드
3. Vantage — Cursor Pricing Explained 2026 (2026.03.04)
4. Let’s Data Science — Cursor $2B ARR & Automations 분석 (2026.03.07)
5. ByteIota — Cursor Automations 실사용 분석 (2026.03.08)
6. GitHub Changelog — Copilot Agentic Workflows Technical Preview (2026.02.13)
7. Cursor Changelog — JetBrains ACP 연동 (2026.03.04)