Cursor Automations GA
Cursor Automations, 혼자 써도 됩니다
— 조건 3가지
Cursor Automations가 2026년 3월 5일 정식 출시됐습니다. 공식 블로그는 “Slack 알림이 오면 에이전트가 코드를 수정하고 PR을 올린다”고 소개합니다. 근데 이걸 보고 “팀이 있어야 쓸 수 있는 기능이겠지”라고 넘긴 분들이 많습니다. 직접 확인해 봤습니다. Pro $20 플랜에서도 됩니다. 단, 막히는 조건이 딱 3가지 있습니다.
Cursor Automations가 정확히 뭔가요
한 줄로 요약하면, 사람이 에디터를 열지 않아도 알아서 돌아가는 코딩 에이전트입니다. Cursor 공식 블로그(2026.03.05)에는 이렇게 나옵니다. “Define a trigger, write a prompt, and choose which tools the agent can use. When triggered, a cloud agent spins up, follows your instructions, and verifies its own output.” — 트리거를 정의하고 지시를 쓰면, 클라우드 에이전트가 스스로 실행하고 결과를 검증합니다. 즉, 개발자가 잠든 사이에도 PR을 열고, 슬랙 메시지를 보내고, 테스트를 돌릴 수 있습니다.
Automations를 만들면 세 가지를 설정합니다. ① 트리거(언제 실행할지) → ② 지시문(뭘 할지) → ③ 도구(어떤 MCP·플러그인을 쓸지). 트리거로 쓸 수 있는 건 스케줄(cron), Slack 메시지, Linear 이슈, GitHub PR, PagerDuty 알림, 그리고 커스텀 웹훅 총 6종류입니다. (출처: Cursor 공식 changelog, 2026.03.05) 새벽 3시에 PagerDuty 알림이 울려도, 에이전트가 먼저 코드를 뒤지고 수정안을 만들어 놓습니다. 개발자가 기상하면 PR이 기다리고 있는 구조입니다.
메모리 기능도 붙어 있습니다. 같은 버그 패턴이 반복되면 에이전트가 이전 실행 이력을 참고해 더 빠르게 처리합니다. 반복 학습이 가능하다는 뜻입니다.
팀 전용이라는 오해 — 공식 가격 페이지에 다 나옵니다
솔직히 말하면, 처음 기사들을 봤을 때 “팀 기능이겠지”라고 넘겼습니다. Slack 연동, GitHub PR 자동화, 멀티 에이전트 같은 말이 나오면 자연스럽게 팀용 SaaS를 떠올리니까요. 근데 공식 가격 페이지(cursor.com/pricing)를 직접 확인하니 달랐습니다.
💡 공식 가격 페이지(2026.03.23 기준)와 실제 사용 패턴을 같이 놓고 보니 이런 차이가 보였습니다
Pro $20 플랜 기능 목록에 “Cloud agents”가 명시돼 있습니다. Automations는 Cloud Agent 기반으로 동작하기 때문에 Pro 이상이면 접근 자체는 가능합니다. Teams $40 플랜과의 차이는 “팀 공유 기능(공유 채팅·명령·규칙, 중앙 결제, 사용 분석, SAML SSO)”이지, Automations 자체가 Teams 전용은 아닙니다. (출처: cursor.com/pricing)
| 플랜 | 월 요금 | Cloud Agents | Automations |
|---|---|---|---|
| Hobby | 무료 | ❌ | ❌ |
| Pro | $20/월 | ✅ | ✅ |
| Pro+ | $60/월 | ✅ | ✅ |
| Ultra | $200/월 | ✅ | ✅ + 우선 접근 |
| Teams | $40/인/월 | ✅ | ✅ + 팀 공유 |
출처: cursor.com/pricing (2026.03.23 기준)
Pro 플랜은 월 $20의 크레딧 풀이 포함됩니다. Automations가 실행될 때마다 클라우드 에이전트가 모델을 사용하므로 크레딧이 소모됩니다. 자동화 실행 횟수가 많으면 크레딧이 빠르게 줄어드는데, 이건 뒤에서 다시 다룹니다.
실제 작동 방식 — 트리거부터 PR까지
Automations를 만드는 곳은 cursor.com/automations입니다. 에디터 앱이 아니라 웹 대시보드에서 설정합니다. 현재(2026.03.23 기준) 에디터 내에서 직접 생성하는 기능은 공식 포럼에서도 “곧 추가될 것”이라는 답변만 있고, 아직 미지원입니다. (출처: Cursor 공식 포럼 Release Discussions, 2026.03.06)
설정 순서는 이렇습니다.
어떤 저장소에서 에이전트가 작업할지 고릅니다. 현재는 자동화 1개당 레포지토리 1개만 연결됩니다.
스케줄(cron 형식), Slack, Linear, GitHub 이벤트, PagerDuty 알림, 커스텀 웹훅 중 선택합니다.
에이전트에게 무엇을 할지 자연어로 씁니다. “PR이 올라오면 보안 취약점을 검토하고 Slack #code-review 채널에 보고하라”는 식입니다.
Claude Haiku 4.5(저비용), Claude Sonnet(균형), 등 모델을 선택합니다. Datadog, Figma, Linear 등 마켓플레이스 플러그인도 연결 가능합니다. (출처: Cursor changelog, 2026.03.11)
트리거 발생 시 클라우드 샌드박스가 자동 생성됩니다. PR 생성, Slack 메시지 전송, MCP 호출 등이 자동으로 이뤄집니다.
에이전트가 실행될 때마다 이전 실행 이력이 메모리에 쌓입니다. 동일 유형의 버그가 두 번 신고되면 두 번째 처리는 더 빠르고 정확해집니다. 단순 스크립트 실행이 아니라 맥락을 축적하는 구조입니다.
혼자 쓸 때 막히는 조건 3가지
Pro 플랜에서 쓸 수 있다는 건 확인했습니다. 근데 실제로 설정하다 보면 멈추는 지점이 있습니다. 공식 포럼(forum.cursor.com)과 Reddit(r/cursor)에서 출시 직후 가장 많이 나온 불만을 정리했습니다.
GitHub Actions랑 뭐가 다른가요
처음 Cursor Automations를 보면 “GitHub Actions에 AI 프롬프트 붙인 거 아닌가?”라는 생각이 드는 게 자연스럽습니다. 외형은 비슷합니다. 이벤트 트리거 → 클라우드 실행 → 결과 반환. 근데 작동 방식이 근본적으로 다릅니다.
💡 코드베이스를 이해하는 에이전트 vs 명령을 실행하는 파이프라인
GitHub Actions는 YAML에 명령어를 나열하고, 그 명령어를 순서대로 실행합니다. PR이 올라오면 “npm test 실행 → 결과가 실패면 알림”처럼 사전에 정의한 명령 시퀀스를 따릅니다. Cursor Automations의 에이전트는 지시문(자연어)을 받고 코드베이스 전체를 읽은 뒤 스스로 판단해서 행동합니다. “PR의 보안 취약점을 찾아라”는 지시에 대해 어떤 파일을 볼지, 어떤 패턴을 검색할지를 에이전트가 결정합니다. 미리 명령을 작성할 필요가 없습니다.
| 항목 | GitHub Actions | Cursor Automations |
|---|---|---|
| 작업 정의 | YAML 명령 시퀀스 | 자연어 지시문 |
| 코드 이해 | 없음 | 코드베이스 전체 분석 |
| 판단·결정 | 사전 정의된 조건만 | 에이전트가 직접 판단 |
| PR 생성 | 별도 스크립트 필요 | 자동 생성 가능 |
| 메모리·학습 | 없음 | 실행 이력 누적 |
| 비용 | 무료~(공개 레포) | Pro $20/월~ |
물론 GitHub Actions가 더 정밀하게 제어할 수 있는 상황도 있습니다. “테스트 통과 여부에 따라 정확히 이 배포 파이프라인을 실행하라”는 결정론적 작업은 여전히 Actions가 낫습니다. Cursor Automations는 “어디가 문제인지 알아서 찾아라”는 탐색·분석 작업에 강점이 있습니다.
실사용 사례 — 실제로 이렇게 쓰고 있습니다
출시 직후 Reddit r/cursor와 Cursor 공식 포럼에서 수집한 실제 사용 패턴입니다. 아직 기능이 막 나온 시점이라 “헤비 유저” 사례가 많지는 않지만, 방향성은 뚜렷합니다.
💡 “나 혼자 Linear 에픽 전체를 던져줬더니 2시간 동안 혼자 작업했습니다”
Reddit 사용자 Final_Effect_7647(2026.03.06): Linear 플러그인을 연결해 스프린트 에픽을 통째로 넘기면 에이전트가 태스크 확인 → 코딩 → PR 검토 → 머지까지 2~2.5시간 혼자 처리했다고 밝혔습니다. SaaS 앱을 React Native로 리팩토링하는 작업이었으며, Bugbot과 함께 반복 사이클로 돌렸다고 합니다. 1인 개발자도 에픽 단위 작업을 백그라운드로 위임할 수 있다는 뜻입니다.
💡 “고객 지원팀이 Slack에 플래그 달면 에이전트가 DB까지 직접 확인합니다”
Reddit 사용자 Wimell(2026.03.06): 고객 서비스 팀이 시스템에서 항목을 플래그 → Slack 자동화 트리거 → Cloud Agent가 읽기 전용 DB 레플리카와 API 엔드포인트에 접근해 처리. 에이전트가 직접 해결 가능하면 바로 실행하고, 새로운 케이스면 새 스킬을 만들어 엔지니어링 팀 검토 큐에 넣는 구조로 운용 중입니다. 개발팀 없이도 고객 지원 흐름이 반자동화된 예시입니다.
Cursor 측이 직접 소개한 Rippling 사례도 주목할 만합니다. Rippling의 Senior Staff Software Engineer Tim Fall는 “cron 기반 자동화로 GitHub PR 생성, Jira 태스크 업데이트, Slack 보고가 하나의 워크플로우로 묶였다”고 밝혔습니다. (출처: Cursor 공식 블로그, 2026.03.05) 반복 유지보수 루틴 전체를 에이전트 루프 하나로 연결한 케이스입니다.
이 부분에서 주목할 점이 있습니다. 세 사례 모두 “코딩 도구”가 아니라 “운영 자동화 도구”처럼 쓰이고 있습니다. 코드를 쓰는 게 아니라 코드베이스를 관리하는 루틴을 위임하는 방향입니다. Cursor가 스스로를 “AI 코드 에디터”에서 “AI 코딩 에이전트”로 포지셔닝을 바꾸는 이유가 여기 있습니다.
자주 묻는 질문 5가지
마치며
Cursor Automations는 팀 전용도 아니고, 대기업 엔지니어링 조직만 쓸 수 있는 기능도 아닙니다. Pro $20 플랜에서 오늘 당장 시작할 수 있고, 레포지토리가 1~2개인 솔로 개발자라면 현재 제약 조건 대부분이 문제가 되지 않습니다.
단, 세 가지 조건은 실제로 막힙니다. 멀티레포 구조라면 지금은 불편합니다. Pro $20 크레딧이 무한정은 아닙니다. 그리고 “일이 일어나지 않았을 때” 반응하는 트리거는 없습니다. 이 세 가지를 모르고 쓰면 중간에 예상치 못한 벽을 만납니다.
솔직한 총평을 하자면 — 아직 완성형은 아닙니다. 에디터 내 생성 UI도 없고, 멀티레포도 미지원이고, 모델 선택지도 제한적입니다. 근데 방향은 맞습니다. “코드를 쓰는 AI”에서 “코드베이스를 관리하는 AI”로 가는 전환점을 이 기능이 만들고 있습니다. 지금 써보는 게 손해는 아닙니다.
본 포스팅 참고 자료
- Cursor 공식 블로그 — Automations 출시 발표 (2026.03.05): cursor.com/blog/automations
- Cursor 공식 Changelog (2026.03.05): cursor.com/changelog/03-05-26
- Cursor 공식 가격 페이지 (2026.03.23 기준): cursor.com/pricing
- Cursor 공식 포럼 — Introducing Cursor Automations (2026.03.05~): forum.cursor.com
- Tessl 분석 블로그 — Cursor launches Automations (2026.03.09): tessl.io
- UIBakery — Cursor AI Pricing Explained 2026 (2026.03.06): uibakery.io
본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. 본 포스팅은 2026년 3월 23일 기준으로 작성됐으며, Cursor의 업데이트에 따라 내용이 달라질 수 있습니다. 최신 정보는 cursor.com/docs에서 확인하세요.
댓글 남기기