Cursor Automations 출시: 2026.03.05
IT/AI
Cursor Automations, 실제로 재봤습니다 — PR 35%가 보이는 숫자
2026년 3월 5일, Cursor가 새로운 자동화 기능을 내놨습니다. 출시 직후 공식 블로그에는 “Cursor 내부에서 머지되는 PR의 35%가 에이전트 생성”이라는 수치가 등장합니다. 이 숫자가 실제로 어떤 의미인지, 그리고 월 $20 Pro 요금제로도 쓸 수 있는지를 공식 문서와 함께 확인해봤습니다.
Cursor Automations가 뭔지, 한 줄로 정리하면
Cursor Automations는 클라우드 에이전트를 “내가 직접 실행하지 않아도” 돌아가게 만드는 기능입니다. 트리거를 설정해두면 GitHub PR이 열릴 때, Slack에 메시지가 올라올 때, 매일 아침 특정 시간에 자동으로 에이전트가 실행됩니다. 2026년 3월 5일 Cursor 공식 changelog에 정식으로 등재된 기능입니다. (출처: Cursor 공식 changelog, 2026.03.05)
핵심은 “에이전트가 내 컴퓨터 없이도 작동한다”는 점입니다. 기존 Cloud Agent는 내가 대화창을 열고 프롬프트를 보내야 실행됐습니다. Automations는 그 과정을 없애고, 미리 설정해둔 조건이 충족되면 클라우드 샌드박스에서 에이전트가 직접 뜹니다.
Cursor 공식 블로그가 이 기능을 설명하면서 쓴 표현이 인상적입니다. “소프트웨어를 만드는 공장(software factory)”이라는 개념입니다. 개발자가 매번 에이전트를 부르는 게 아니라, 에이전트가 돌아가는 공장 구조를 짜는 역할로 전환된다는 이야기입니다. (출처: Cursor 공식 블로그 <The Third Era>, 2026.03)
7가지 트리거, 각각 언제 쓰는지
Cursor 공식 문서에는 트리거가 크게 스케줄, GitHub, Slack, 웹훅, Linear, PagerDuty 등 7가지 유형으로 나뉩니다. (출처: Cursor 공식 문서 /docs/cloud-agent/automations, 2026.03) 트리거 하나의 자동화에 여러 트리거를 묶을 수 있고, 어느 하나만 발동해도 에이전트가 실행됩니다.
| 트리거 유형 | 대표 이벤트 | 실사용 시나리오 |
|---|---|---|
| 스케줄(Cron) | 매시간·매일·매주 | 주간 코드 변경 요약, 테스트 커버리지 리포트 |
| GitHub | PR 열림·머지·댓글·CI 완료 | 보안 취약점 자동 리뷰, 코드 소유자 지정 |
| Slack | 채널 신규 메시지 | 버그 리포트 분류, Linear 이슈 자동 생성 |
| 웹훅 | 임의의 HTTP POST | 내부 CI 파이프라인 연동, 모니터링 알림 대응 |
| Linear | 이슈 생성·상태 변경·사이클 종료 | 이슈 근본 원인 분석, 수정 PR 자동 생성 |
| PagerDuty | 인시던트 발생·해결 | 로그 조사 후 온콜 팀에 Slack 요약 전송 |
솔직히 말하면 개인 개발자에게 당장 가장 현실적인 트리거는 스케줄과 GitHub입니다. PagerDuty나 Linear 트리거는 팀 환경이 세팅돼 있어야 실제로 쓸 수 있기 때문에, 혼자 작업하는 경우엔 웹훅으로 직접 HTTP 요청을 보내는 방식이 오히려 활용 범위가 넓습니다.
Pro 요금제로도 쓸 수 있는 이유, 그런데 함정이 있습니다
공식 문서에 이런 내용이 나옵니다. “모든 개인 요금제에는 무제한 탭 완성, 모든 모델에서의 확장된 에이전트 사용 한도, Bugbot 이용 권한, Cloud Agents 이용 권한이 포함됩니다.” (출처: Cursor 공식 모델 및 요금 문서, 2026.03.31 기준) Automations는 Cloud Agents를 기반으로 하므로, $20 Pro 요금제에서도 기능 자체는 활성화됩니다.
💡 공식 요금 문서와 실제 사용 흐름을 같이 놓고 보니 이런 차이가 보였습니다
Pro 요금제($20/월)에는 $20에 해당하는 API 사용량이 포함됩니다. Automations를 실행하면 이 풀에서 사용량이 차감됩니다. Composer 2 Standard 모델 기준으로 출력 토큰 100만 개당 $2.50입니다. 자동화 1회 실행에 수천~수만 토큰이 소비되는 걸 감안하면, 적극적으로 자동화를 돌리는 경우 Pro 포함 사용량만으로는 빠르게 소진됩니다. Cursor 공식 문서는 “파워 유저(여러 에이전트·자동화 사용)”의 월 총 사용량을 “$200 이상”으로 명시합니다.
또 한 가지 확인할 부분은 청구 방식입니다. 공식 문서에서 권한 범위(Permission Scope)를 세 가지로 나눕니다.
- Team Owned: 팀의 사용량 풀에서 차감. 개별 멤버 사용량에는 영향 없음.
- Private: 자동화를 만든 사람의 사용량에서 차감.
- Team Visible: Private과 동일하게 만든 사람 사용량에서 차감.
혼자 쓰는 경우엔 모든 자동화가 Private으로 동작하기 때문에 내 사용량 풀에서만 차감됩니다. 팀 환경에서 Team Owned로 설정하면 개인 한도 걱정 없이 팀 예산에서 처리됩니다. 이 구분이 실제 요금 관리에서 꽤 중요합니다.
35%라는 숫자가 실제로 뜻하는 것
Cursor 공식 블로그 <The Third Era>에는 이런 문장이 나옵니다. “현재 Cursor에서 내부적으로 머지되는 PR의 35%는 클라우드 VM에서 자율적으로 동작하는 에이전트가 생성하고 있습니다.” (출처: Cursor 공식 블로그 <The Third Era>, 2026.03) 이 수치는 Automations 기능이 단순한 데모용이 아니라는 것을 보여줍니다. 자기 제품을 직접 자기 에이전트로 유지보수하는 구조입니다.
💡 에이전트 사용량 변화 추이도 공식 수치로 확인됩니다
같은 블로그 글에는 “지난 1년 동안 Cursor에서 에이전트 사용량은 15배 이상 증가했다”는 수치도 나옵니다. 2025년 3월 기준 Tab 사용자가 에이전트 사용자보다 약 2.5배 많았지만, 현재는 반전돼 에이전트 사용자가 Tab 사용자보다 2배 많습니다. Automations는 이 흐름의 다음 단계로 볼 수 있습니다.
Cursor는 Automations 발표 글에서도 실제 사용 사례를 구체적으로 공개했습니다. 보안 취약점 자동 리뷰 자동화가 PR을 막지 않으면서 main 브랜치 push 때마다 실행되고, “출시 이후 수백만 개의 버그를 잡아낸” Bugbot이 자동화의 원형이라고 설명합니다. (출처: Cursor 공식 블로그 <automations>, 2026.03.05)
여기서 주목할 점은 Cursor가 “보안 리뷰 자동화는 PR을 막지 않는다”고 명시했다는 것입니다. 이유는 에이전트가 더 오래 작업해 미묘한 이슈까지 찾게 하기 위해서입니다. CI/CD처럼 PR에 게이트를 거는 방식이 아니라, PR이 머지된 뒤 비동기로 감시하는 아키텍처를 택한 것입니다.
Memories 기능, 대부분의 글이 지나치는 핵심
Automations 관련 글들은 대부분 트리거 종류와 연동 서비스 목록에 집중합니다. 그런데 공식 문서에는 트리거보다 더 중요할 수 있는 기능이 조용히 들어가 있습니다. 바로 Memories입니다.
Memories는 자동화 에이전트가 실행될 때마다 이전 실행 결과를 기억하고 참조할 수 있게 해주는 기능입니다. 공식 문서에는 이렇게 나옵니다. “에이전트는 과거 실행 내역에서 학습하고 반복을 통해 성능을 향상시킬 수 있는 메모리 도구에도 접근할 수 있습니다. 각 메모리는 MEMORIES.md로 저장되며, 에이전트의 작업 파일시스템 밖에 유지됩니다.” (출처: Cursor 공식 문서 /docs/cloud-agent/automations, 2026.03) 기본값으로 활성화되어 있습니다.
💡 트리거 방식만 보면 n8n이나 GitHub Actions와 뭐가 다른지 잘 안 보입니다. 메모리 구조를 보면 달라집니다
기존 자동화 도구들은 매 실행이 독립적입니다. 이전 실행에서 어떤 PR이 문제가 됐는지, 어떤 패턴이 반복됐는지 기억하지 못합니다. Cursor Automations의 Memories는 자동화 에이전트가 회차가 쌓일수록 판단 기준을 스스로 개선할 수 있는 구조입니다. 이건 n8n의 워크플로나 GitHub Actions의 yaml과 근본적으로 다른 접근입니다.
실제로 Cursor가 공개한 사례 중 “Agentic codeowners” 자동화는 PR의 리스크를 분류하고 리뷰어를 지정한 뒤, 결정 내용을 Notion 데이터베이스에 기록합니다. 이 데이터를 바탕으로 다음 실행에서 지침을 조정하는 구조입니다. 단순 자동화가 아니라, 반복 실행으로 성숙해지는 에이전트입니다.
GitHub Actions와 무엇이 다른지 실제로 따져봤습니다
“GitHub Actions로 이미 CI/CD 돌리고 있는데 굳이 Cursor Automations를 써야 하나?” 이 질문이 제일 현실적입니다. 직접 비교해봤습니다.
| 구분 | Cursor Automations | GitHub Actions |
|---|---|---|
| 작업 정의 방식 | 자연어 프롬프트 | YAML 스크립트 |
| 판단·추론 가능 여부 | ✅ LLM 기반 | ❌ 결정론적 |
| 코드 작성·PR 생성 | ✅ 에이전트가 직접 | △ 별도 스크립트 필요 |
| 실행 비용 | 사용량 기반 ($2.5/M 토큰~) | 분당 과금 (월 2000분 무료) |
| 메모리(컨텍스트 축적) | ✅ Memories 기능 | ❌ 각 실행 독립적 |
간단히 말하면 GitHub Actions는 “정해진 절차를 실행”하는 도구이고, Cursor Automations는 “상황을 판단하고 코드까지 직접 쓰는” 도구입니다. 두 가지는 경쟁 관계가 아닙니다. Cursor 내부 사례에서도 GitHub Actions로 CI를 돌리고, 그 CI 완료 이벤트를 Cursor Automations 트리거로 연결하는 방식을 씁니다.
비용 면에서는 주의가 필요합니다. GitHub Actions는 공개 저장소 무제한, 비공개 저장소 월 2,000분 무료입니다. Cursor Automations는 실행 시간이 아닌 토큰 소비 기준으로 과금됩니다. 복잡한 코드 리뷰 자동화 1회에 수만 토큰이 소비될 수 있고, 이건 Pro 포함 사용량에서 빠집니다. 자동화 개수가 늘어날수록 예상치 못한 요금 청구로 이어질 수 있어서, 처음엔 웹훅으로 수동 트리거하며 토큰 소비를 먼저 확인하는 게 현실적입니다.
Q&A
마치며 — 도구가 바뀌는 게 아니라 개발자의 역할이 바뀝니다
Cursor Automations를 이리저리 살펴보면서 드는 생각은, 이게 단순한 기능 추가가 아니라는 점입니다. Cursor는 스스로 “세 번째 시대”라고 부릅니다. Tab으로 코드 자동완성을 쓰던 시대, 에이전트에 지시하던 시대를 지나, 이제는 에이전트들이 돌아가는 구조를 설계하는 시대로 넘어간다는 이야기입니다.
현실적으로 개인 개발자에게 당장 이 기능이 필요한 상황은 많지 않습니다. GitHub 저장소가 없거나, 팀 환경이 아니라면 스케줄 트리거와 웹훅 정도가 현실적인 선택지입니다. 비용도 Pro $20 포함 사용량 안에서 적극적으로 쓰기엔 빠듯합니다.
그래도 Memories 기능 하나는 기억해두는 게 좋습니다. 매 실행마다 쌓이는 경험을 자동화 에이전트가 직접 참고한다는 개념은, 기존 자동화 도구들이 아직 제대로 구현하지 못한 부분입니다. 지금 당장은 작은 기능처럼 보이지만, 6개월 뒤 이 구조 위에 어떤 자동화가 올라오는지를 봐야 진가가 드러날 것 같습니다.
📎 본 포스팅 참고 자료
본 포스팅은 2026년 3월 31일 기준 Cursor 공식 문서와 공식 블로그를 참고하여 작성되었습니다. 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. 최신 요금 및 기능은 Cursor 공식 사이트(cursor.com)에서 직접 확인하시기 바랍니다.
댓글 남기기