Cursor Automations v1.0
IT/AI
Cursor Automations, 프롬프트 안 쳤는데 PR이 열렸습니다
Cursor가 2026년 3월 5일 공식 출시한 Automations는 개발자가 프롬프트를 입력하지 않아도 에이전트가 스스로 코드를 리뷰하고 PR을 여는 기능입니다. 그런데 막상 공식 문서와 실제 사용 흐름을 같이 놓고 보니, 기대와 다른 부분이 몇 가지 보였습니다.
Cursor Automations가 등장한 배경
AI 코딩 도구를 쓰다 보면 반드시 맞닥뜨리는 장면이 있습니다. 에이전트에게 작업을 맡겨 놓고, 끝났는지 확인하고, 다시 프롬프트를 입력하고, 또 기다리는 루프입니다. 이 패턴이 비효율적이라는 건 다들 알지만, 마땅한 대안이 없었습니다.
Cursor는 2026년 3월 5일 이 문제를 정면으로 겨냥한 기능을 공식 출시했습니다. Cursor Automations입니다. (출처: cursor.com/ko/blog/automations, 2026.03.05) 개발자가 직접 프롬프트를 치지 않아도, GitHub PR 머지·Slack 메시지·PagerDuty 인시던트 같은 외부 이벤트가 발생하는 순간 에이전트가 자동으로 실행되는 구조입니다.
Cursor CEO Michael Truell은 2026년 2월 26일 “The Third Era(세 번째 시대)” 포스팅에서 AI 개발의 흐름을 세 단계로 정리했습니다. 탭 자동완성이 첫 번째였고, 사용자가 직접 프롬프트를 입력해 에이전트를 돌리는 방식이 두 번째입니다. 세 번째가 바로 Automations가 지향하는 형태, 즉 배경에서 알아서 돌아가는 자율 에이전트입니다. (출처: cursor.com/ko/blog/third-era, 2026.02.26)
💡 공식 발표문과 실제 사용 흐름을 같이 놓고 보니 이런 차이가 보였습니다 — Truell이 ‘세 번째 시대’라고 부르는 것은 단순히 새 기능 추가가 아니라 개발자의 역할 자체를 재정의하는 방향 전환입니다. 이제 Cursor의 비전은 “더 나은 코드 에디터”가 아니라 “소프트웨어를 만드는 공장”입니다. (출처: Cursor 공식 블로그, 2026.02.26)
트리거 종류와 실제 작동 흐름
Cursor Automations의 핵심은 트리거입니다. 트리거가 발동하면 클라우드 샌드박스 안에서 에이전트가 스핀업되고, 프롬프트에 정의된 지침대로 작업을 수행한 뒤 결과를 Slack 메시지나 GitHub PR 코멘트 형태로 돌려줍니다. (출처: Cursor 공식 문서, 2026.03 기준)
현재 지원하는 트리거 유형은 다음과 같습니다.
| 트리거 유형 | 세부 이벤트 예시 | 주요 활용 |
|---|---|---|
| GitHub | PR 오픈 / 머지 / 코멘트 / CI 완료 | 자동 코드 리뷰, 보안 스캔 |
| Slack | 채널 메시지 / 신규 채널 생성 | 버그 트리아지, 요약 보고 |
| Linear | 이슈 생성 / 상태 변경 / 사이클 종료 | 이슈 자동 분석 및 담당자 배정 |
| PagerDuty | 인시던트 발생 / 승인 / 해결 | 장애 로그 분석, 자동 근본 원인 파악 |
| 스케줄(Cron) | 시간/일/주 단위 반복 실행 | 매주 월요일 변경 내역 요약 |
| Webhook | 외부 시스템 HTTP POST | 내부 CI 파이프라인 연동 |
에이전트가 외부 서비스에 행동할 때의 신원도 공식 문서에 명시되어 있습니다. GitHub 코멘트와 리뷰는 `cursor` 계정으로 남고, 팀 스코프 자동화의 PR은 `cursor`가 열지만, 개인 스코프 자동화의 PR은 본인 GitHub 계정으로 열립니다. Slack 메시지는 Cursor 봇으로 전송됩니다. 팀에서 공유 계정처럼 보이고 싶다면 Team Owned 권한으로 설정해야 합니다.
탭 자동완성보다 에이전트를 더 많이 쓰기 시작했습니다
여기서 잠깐 짚고 넘어갈 숫자가 있습니다. 대부분은 “Cursor = 빠른 자동완성 도구”로 인식합니다. 그런데 Cursor 공식 블로그의 수치를 보면 이 인식이 이미 뒤집혔습니다.
📊 Cursor 내부 사용 데이터 (출처: cursor.com/ko/blog/third-era, 2026.02.26)
2025년 3월 기준: Tab 자동완성 사용자 vs 에이전트 사용자 = 2.5 : 1
2026년 2월 기준: Tab 자동완성 사용자 vs 에이전트 사용자 = 1 : 2 (역전)
→ 불과 11개월 만에 비율이 뒤집혔습니다.
에이전트 사용량은 1년 사이 15배 증가했습니다. (출처: Cursor 공식 블로그, 2026.02.26) 이 수치가 의미하는 바는 단순합니다 — 개발자들이 코드를 직접 치는 것보다 에이전트에게 시키는 시간이 더 길어졌다는 뜻입니다.
Automations는 바로 이 흐름 위에 올라탄 기능입니다. 에이전트를 이미 쓰고 있다면, 그 에이전트를 수동으로 호출하는 것 자체가 병목이 됩니다. Rippling의 시니어 스태프 엔지니어 Tim Fall은 공식 블로그에서 이렇게 말했습니다. “반복적인 업무를 오프로드하기가 쉬워졌다. 중요한 일에 집중할 수 있다.” (출처: cursor.com/ko/blog/automations, 2026.03.05)
Cursor는 현재 자체 코드베이스에서 시간당 수백 건의 자동화를 돌리고 있습니다. 이 중에는 보안 취약점 탐지, 아키텍처 리뷰, PR 코드 리뷰가 포함되며, 사람이 놓친 취약점과 크리티컬 버그를 잡아냈다고 공식 문서에 명시했습니다. (출처: cursor.com/ko/blog/automations, 2026.03.05)
요금 구조, 생각보다 빨리 쌓입니다
Automations는 클라우드 에이전트 사용량 기준으로 과금됩니다. 중요한 건 권한 범위(Permission Scope)에 따라 누구 계정에서 차감되는지가 달라진다는 점입니다.
| 권한 범위 | 사용량 차감 대상 | 관리 권한 |
|---|---|---|
| Private | 자동화 생성자 개인 풀 | 본인만 관리 |
| Team Visible | 자동화 생성자 개인 풀 | 팀원 열람, 본인 관리 |
| Team Owned | 팀 공유 사용량 풀 | 팀 어드민만 관리 |
(출처: Cursor 공식 문서, Automations 섹션)
⚠️ 실제 비용 사례
Reddit 사용자 보고: 자동화를 집중적으로 돌린 한 주에 $350(약 50만 원) 초과 청구. 에이전트가 하루에도 수백 번 실행될 수 있으므로, 사용량 모니터링 없이 Team Visible 또는 Private로 실행하면 개인 풀이 빠르게 소진됩니다. (출처: byteiota.com, 2026.03.08 수집 기준)
이미 2026년 2월 Cursor 공식 포럼에서는 사용 한도 강화에 대한 불만이 제기됐습니다. Pro+ ($60)를 쓰던 사용자가 한도 기준 변경으로 실질 사용량이 약 1.7배 줄었다는 내용이었습니다. (출처: forum.cursor.com, 2026.02.18) 요금 구조를 이해하지 않고 자동화를 풀 가동했다가 청구서 보고 놀라는 상황이 충분히 발생할 수 있습니다.
GitHub Copilot과 결정적으로 다른 점
GitHub Copilot도 2026년 2월 13일 “Agentic Workflows”를 기술 프리뷰 형태로 내놓았습니다. 그런데 공식 발표 자료를 보면 결정적인 차이가 있습니다 — Copilot의 에이전틱 워크플로는 여전히 사람이 GitHub 이슈를 지정해서 시작하는 구조입니다. 자동으로 이벤트에 반응하지 않습니다.
Cursor Automations는 이미 프로덕션 환경에서 이벤트 기반으로 완전 자동 실행됩니다. 벤치마크 수치도 함께 보면 그림이 더 명확합니다.
| 항목 | Cursor Pro ($20/월) | GitHub Copilot Pro ($10/월) |
|---|---|---|
| 이벤트 기반 자동화 | ✅ 프로덕션 출시 | 기술 프리뷰 |
| SWE-bench 정확도 | 51.7% | 56.0% |
| 작업 처리 속도 | 62.95초/작업 | 89.91초/작업 |
| 코드베이스 인덱싱 | Pro 플랜 기본 포함 | Enterprise만 지원 |
| 지원 IDE | Cursor 전용 | VS Code·JetBrains·Xcode 등 |
| 프리미엄 모델 접근 | Claude Opus 4.6·GPT-5.4 포함 | Opus급은 Pro+ ($39) 필요 |
(출처: nxcode.io, 2026.03.20 기준 / SWE-bench 수치는 280개 태스크 기준)
정확도 벤치마크는 Copilot이 앞서지만, 속도는 Cursor가 30% 빠릅니다. 빠른 게 중요한 반복 작업이라면 이 차이가 하루 단위로 쌓입니다.
실제로 막히는 조건들
공식 발표만 보면 Automations가 마치 모든 걸 해결해줄 것 같지만, 실제 사용 흐름을 보면 주의할 점이 여럿 있습니다.
💡 공식 문서와 실제 후기를 교차해보니 이런 패턴이 보였습니다 — 기능은 강력하지만 기업 환경에서는 보안 검토 없이 바로 도입하기 어려운 조건이 있습니다.
① PR 코멘트 트리거는 PR 이벤트가 있어야만 작동합니다
공식 문서에 “PR 코멘트 액션은 PR 트리거가 있어야 한다”고 명시되어 있습니다. 스케줄 트리거에서는 이 액션을 쓸 수 없습니다.
② 팀 공유 자동화는 OAuth 인증을 별도 설정해야 합니다
Private에서 Team Owned로 승격하면 실행 주체가 바뀝니다. MCP 연동이나 개인 OAuth를 쓰던 자동화라면 팀 서비스 계정 기준으로 인증을 다시 설정해야 하고, Webhook URL도 재생성해야 합니다. (출처: Cursor 공식 문서)
③ 보안팀이 막는 경우가 있습니다
기업 고객 CISO 담당자들이 DLP(데이터 유출 방지) 계획, 테넌트 격리, SOC 2 컴플라이언스를 요구한다는 사례가 있습니다. 또한 팀 플랜에서도 커밋 정보가 Cursor 서버로 전송되는 것을 막을 방법이 공식적으로 이유를 밝히지 않은 부분입니다. (출처: byteiota.com, 2026.03.08)
④ 에이전트 품질은 5~10번 실행 후에 안정됩니다
Automations에는 Memories 기능이 있어 에이전트가 이전 실행 내역을 기억합니다. 처음부터 완벽한 결과를 기대하면 실망하기 쉽습니다. 공식 가이드도 “5~10번 반복 실행하면서 개선하라”고 권장합니다. (출처: cursor.com/ko/blog/agent-best-practices, 2026.01.09)
자주 묻는 질문
마치며 — 프롬프트 없이 PR이 열린다는 건 어떤 의미인가
Cursor Automations는 기능 자체보다 신호로서의 의미가 더 큽니다. ‘프롬프트를 잘 쓰는 것’이 개발자의 핵심 역량이던 시대가 예상보다 빨리 끝나고 있습니다. 이제는 어떤 이벤트에 어떤 자동화를 연결할지 설계하는 능력이 더 중요해졌습니다.
솔직히 말하면, 지금 당장 모든 팀이 바로 도입하기엔 걸리는 것들이 있습니다. 요금이 생각보다 빠르게 쌓이고, 보안팀이 막는 경우도 있고, 에이전트 품질이 안정되기까지 10번 정도는 돌려봐야 합니다. 그래도 Cursor가 내부에서 이미 시간당 수백 건을 돌리고 있다는 사실은, 이게 실험 단계가 아니라는 증거입니다.
시작하기 가장 좋은 방법은 읽기 전용 자동화 하나부터입니다. 매주 월요일 아침 코드 변경 내역을 Slack으로 요약해주는 것, 그게 첫 걸음입니다.
📌 본 포스팅 참고 자료
- ① Cursor 공식 블로그 — Automations 출시 발표 (cursor.com/ko/blog/automations)
- ② Cursor 공식 문서 — Automations 기능 상세 (cursor.com/docs/cloud-agent/automations)
- ③ Cursor 공식 블로그 — 세 번째 시대 (2026.02.26) (cursor.com/ko/blog/third-era)
- ④ Cursor 공식 블로그 — 에이전트 모범 사례 (2026.01.09) (cursor.com/ko/blog/agent-best-practices)
- ⑤ nxcode.io — GitHub Copilot vs Cursor 2026 비교 (nxcode.io)
- ⑥ letsdatascience.com — Cursor $2B ARR 분석 (2026.03.07) (letsdatascience.com)
본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. 본문의 요금 수치 및 기능 범위는 2026년 3월 25일 기준이며, Cursor 서비스 업데이트에 따라 달라질 수 있습니다.
댓글 남기기