3월 5일, AI 코딩 도구 시장에서 진짜 의미 있는 변화가 나왔습니다. 모델 성능 향상도, 새로운 자동완성도 아닙니다. 실행 구조 자체가 바뀌었습니다.
Cursor Automations는 2026년 3월 5일 Cursor에서 공식 출시한 이벤트 기반 AI 에이전트 자동화 기능으로, GitHub 푸시·Slack 메시지·PagerDuty 인시던트 등 외부 이벤트를 트리거로 AI 에이전트가 격리된 클라우드 샌드박스에서 자동 실행됩니다. 현재 Scheduled(cron), GitHub, Slack, Linear, PagerDuty, Webhook 6가지 트리거를 지원합니다.
지금까지 AI 코딩이라고 하면 “이 코드 리팩토링해줘”, “테스트 짜줘”, “버그 고쳐줘” — 전부 내가 먼저 말을 걸어야 하는 구조였습니다. Copilot이든 Cursor Agent Mode든 Claude Code든, 결국 사람이 프롬프트를 입력하는 순간에만 AI가 움직였어요.
3월 5일에 Cursor가 이 전제를 깼습니다. “사람이 말 안 걸어도, 이벤트가 발생하면 AI가 알아서 돌아간다.” 이것이 Cursor Automations입니다.
AI 코딩, 지금까지와 뭐가 다른가
Cursor Automations란? 외부 이벤트(GitHub 푸시, Slack 메시지, PagerDuty 알림 등)를 트리거로 AI 에이전트가 격리된 클라우드 샌드박스에서 자동 실행되는 기능입니다. 2026년 3월 5일 Cursor 공식 출시.
이걸 이해하려면 AI 코딩의 진화 단계를 한번 정리할 필요가 있어요.
1단계 — 자동완성 (2021~) GitHub Copilot이 시작. 다음 줄을 예측해서 제안. 개발자가 Tab 눌러서 수락. 수동적.
2단계 — 대화형 에이전트 (2024~) Cursor Agent Mode, Claude Code 등장. “이 함수 리팩토링해줘” 하면 AI가 멀티 파일 수정. 능동적이지만, 사람이 먼저 말을 걸어야 동작.
3단계 — 이벤트 기반 자동 실행 (2026.03~) Cursor Automations. GitHub에 코드가 푸시되면 AI가 보안 리뷰를 자동으로 돌리고, Slack에 인시던트가 올라오면 AI가 로그를 분석해서 수정 PR을 자동으로 생성. 사람이 말 안 걸어도 됩니다.
평소에 Claude랑 Cursor로 에이전트 시스템을 운영하고 있었는데, 이 뉴스를 보는 순간 “이거 내가 하네스 코드로 직접 짜고 있던 거 아닌가?” 싶었어요. runtime_harness.py로 health check, 자동 재시작, 폴백을 구현해놓은 게 있는데, Cursor가 이걸 플랫폼 레벨에서 해버린 겁니다.
Cursor가 제시하는 3대 시나리오
Cursor 공식 블로그에서 3가지 핵심 시나리오를 소개했는데, 이게 정확히 개발팀이 매일 겪는 반복 업무를 짚어요.
시나리오 1: 보안 리뷰 자동화
트리거: main 브랜치에 코드가 푸시될 때마다 AI가 하는 일:
- 전체 커밋 내용을 스캔
- 보안 취약점(하드코딩된 시크릿, SQL 인젝션, 인증 우회 등) 탐지
- PR에서 이미 논의된 항목은 자동 스킵
- 고위험 발견 시 Slack 채널로 즉시 알림
중요한 건, 현실적으로 코드 리뷰에서 보안 리뷰는 항상 밀립니다. “기능이 돌아가는지”가 급하니까 보안은 “나중에 볼게” 하다가 결국 안 봐요. Automations를 걸어두면 main에 머지되는 순간 자동으로 돌아가니까, 리뷰어가 깜빡해도 보안 검사는 누락되지 않습니다.
기존에 이런 걸 하려면? SonarQube나 Snyk 같은 별도 보안 도구를 CI에 붙이거나, GitHub Actions로 워크플로우를 짜야 했어요. 근데 그건 규칙 기반이라 패턴에 없는 취약점은 못 잡습니다. Cursor Automations는 LLM이 코드 맥락을 이해하고 판단하니까 “이 패턴은 의도적인 건지, 실수인 건지”를 구분할 수 있어요.
시나리오 2: Agentic Codeowners
트리거: PR이 열리거나 업데이트될 때 AI가 하는 일:
- PR의 blast radius(영향 범위), 코드 복잡도, 인프라 영향도 분석
- 저위험 PR → 자동 승인
- 고위험 PR → 적절한 검토자 자동 지정
- Slack에 PR 요약 전송 + Notion MCP로 리뷰 로그 기록
이걸 보고 “아, 코드 리뷰도 자동화되는 거야?” 하실 수 있는데, 정확히는 트리아지(분류)가 자동화되는 겁니다. “이 PR은 누가 봐야 하고, 얼마나 긴급한지”를 AI가 판단해주는 거예요. 실제 코드 리뷰 자체는 사람이 하되, 우선순위 매기는 작업을 AI가 해주는 구조.
개인 프로젝트에서는 모르겠지만, 팀 규모가 10명만 넘어가도 PR 큐가 쌓이면서 “이거 누가 봐야 돼?”로 시간 잡아먹는 게 현실이잖아요. Codeowners 파일 관리도 귀찮고, 사람이 바뀌면 업데이트도 안 되고. AI가 코드 변경 내용을 보고 “이건 인프라 변경이니까 SRE 팀이 봐야 해요”라고 자동으로 라우팅해주면 꽤 쓸모 있을 거 같아요.
시나리오 3: 인시던트 자동 대응
트리거: PagerDuty에 인시던트가 생성될 때 AI가 하는 일:
- Datadog MCP로 에러 로그 자동 조사
- 관련 코드 변경 이력 추적
- Slack으로 온콜 엔지니어에게 요약 알림
- 가능하면 수정 PR 자동 생성
이건 진짜 눈에 띄는 시나리오입니다. 새벽 3시에 PagerDuty 알림 울리면 개발자가 졸린 눈 비비면서 로그 뒤지고, git blame 하고, 어디서 터졌는지 찾는 그 과정을 AI가 먼저 해놓는 거예요. 온콜 엔지니어가 눈 떴을 때 이미 “여기가 원인이고, 이 PR이 문제이고, 수정 PR은 여기 있습니다” 상태.
물론 자동 생성된 PR을 바로 머지하는 건 위험하겠죠. 하지만 원인 분석과 초안 PR이 준비되어 있는 것만으로도 MTTR(Mean Time To Recovery)을 엄청나게 줄일 수 있습니다.
Bugbot — Automations의 원형
Cursor 내부에서는 이미 이 구조를 쓰고 있었어요. Bugbot이라는 내부 도구가 그 원형입니다.
- PR이 열리거나 업데이트될 때마다 자동 실행
- 하루에 수천 회 트리거
- 누적으로 수백만 건의 버그를 탐지 (Cursor 공식 블로그 기준)
Bugbot이 실전에서 동작한다는 걸 검증한 뒤에 이걸 외부에 공개한 거라, 단순한 데모가 아니라 production-proven 기능이라는 점이 신뢰도를 높여줍니다.
10분 세팅 가이드 — 보안 리뷰부터 시작하기
이론은 충분하고, 실제로 어떻게 세팅하는지 알아보죠.
1단계: Automations 페이지 접속
cursor.com/automations/new
또는 Cursor IDE에서 Command Palette → “Automations” 검색.
2단계: 트리거 선택
6가지 트리거 중 하나를 선택합니다.
| 트리거 | 언제 실행 | 적합한 용도 |
|---|---|---|
| Scheduled (cron) | 지정된 주기 | 일일 코드 품질 점검, 대시보드 생성 |
| GitHub | PR/푸시/CI 완료 | 코드 리뷰, 보안 감사, 테스트 |
| Slack | 채널 메시지/생성 | 인시던트 대응, 요청 처리 |
| Linear | 이슈/상태/사이클 | 이슈 트리아지, 자동 할당 |
| PagerDuty | 인시던트 생성 | 장애 대응, 로그 분석 |
| Webhook | 커스텀 이벤트 | 뭐든 연결 가능 |
보안 리뷰 자동화라면 → GitHub 트리거 → “Push to main branch” 이벤트 선택.
3단계: 프롬프트 작성
트리거가 발생했을 때 AI가 뭘 할지 자연어로 작성합니다.
이 커밋의 보안 취약점을 분석해줘. 특히 하드코딩된 API 키, SQL 인젝션 가능성, 인증 우회 패턴을 중점 확인. PR에서 이미 논의된 항목은 스킵. 고위험 발견 시 #security-alerts Slack 채널에 알림.
4단계: MCP 도구 연결 (선택)
Slack 알림, Notion 로깅, Datadog 조회 등을 하려면 MCP 서버를 연결합니다. Cursor의 .cursor/mcp.json에 설정하면 Automations에서도 같은 도구를 사용할 수 있어요.
5단계: 저장 + 활성화
끝. 이제 main에 코드가 푸시될 때마다 AI가 자동으로 보안 리뷰를 돌립니다.
실제로 해보면 5~10분이면 됩니다. 근데 중요한 건 “트리거 선택 + 프롬프트 작성”이 전부라는 점이에요. GitHub Actions처럼 YAML 짤 필요 없고, SonarQube처럼 별도 서버 띄울 필요 없습니다. 자연어로 “뭐 하라”고 쓰면 끝.
GitHub Actions vs Cursor Automations — 뭐가 다른가
이 질문 많이 나올 거 같아서 정리합니다.
| 항목 | GitHub Actions | Cursor Automations |
|---|---|---|
| 실행 주체 | 정의된 스크립트/CLI | AI 에이전트 (LLM) |
| 설정 방식 | YAML 워크플로우 | 자연어 프롬프트 |
| 판단 능력 | 규칙 기반 (if/else) | 맥락 이해 기반 |
| 적합한 작업 | 빌드, 테스트, 배포 | 코드 리뷰, 보안 분석, 트리아지 |
| 학습 | 없음 | Memory 도구로 과거 실행에서 학습 |
| 실행 환경 | GitHub runner | Cursor 클라우드 샌드박스 |
핵심은 대체가 아니라 보완입니다.
GitHub Actions는 “빌드 → 테스트 → 배포”처럼 결정적(deterministic) 작업에 강합니다. 항상 같은 입력에 같은 결과가 나와야 하는 작업.
Cursor Automations는 “이 PR이 위험한가?”, “이 인시던트 원인이 뭔가?” 같은 판단이 필요한 작업에 강합니다. 맥락을 이해하고 추론해야 하는 작업.
가장 현실적인 구조는 GitHub Actions로 CI/CD를 돌리고, Cursor Automations로 AI 기반 리뷰/모니터링을 얹는 하이브리드입니다.
GitHub에 PR 생성 ├── GitHub Actions: 빌드 + 테스트 + 린트 (자동) └── Cursor Automations: 보안 리뷰 + 위험도 분류 + 리뷰어 지정 (자동)
이렇게 하면 “기능은 돌아가는데 보안 검토 안 했네” 같은 상황이 구조적으로 방지됩니다.
실제 팀 사례 — Rippling
이론만으로는 감이 안 잡힐 수 있으니까, Cursor 블로그에 소개된 실제 사례를 보겠습니다.
Rippling은 HR/IT/Finance 통합 플랫폼 회사인데, Cursor Automations를 이렇게 쓰고 있어요.
2시간마다 cron 에이전트가 실행:
- 최근 미팅 노트 수집
- PR 변경 이력 정리
- Jira 이슈 상태 업데이트
- Slack 토론 요약
- 이 모든 걸 통합 대시보드로 생성
2시간마다. 자동으로. 사람 개입 없이.
이게 뭐가 대단하냐면, 보통 이런 “주간 현황 정리”를 누군가가 수동으로 합니다. PM이든 테크리드든 금요일 오후에 Jira 뒤지고, Slack 스크롤하고, PR 정리하고. 그 시간이 매주 2~3시간은 날아가요. Automations를 걸면 이 작업이 2시간 간격으로 최신 상태를 유지하면서 자동으로 돌아갑니다.
Cloud Agent와 Memory — 핵심 인프라
Automations가 돌아가는 인프라도 한번 짚고 갈게요.
Cloud Agent
Automations는 격리된 클라우드 샌드박스에서 실행됩니다. 로컬 머신이 꺼져 있어도 돌아갑니다. 기존 Cursor Agent Mode와 가장 큰 차이점이 바로 여기 있어요.
기존 Agent Mode는 내 로컬 머신에서 돌아가니까 PC를 꺼두면 끝이었는데, Cloud Agent는 Cursor 서버에서 돌아가니까 24/7 운영이 가능합니다. “always-on AI 에이전트”가 정확히 이 의미예요.
Memory 도구
Cursor Automations는 Memory 도구를 통해 과거 실행에서 학습합니다. 처음에는 보안 리뷰에서 false positive(거짓 양성)가 많을 수 있지만, 반복 실행하면서 “이 패턴은 의도적인 것”이라고 학습하면 점점 정확도가 올라갑니다.
GitHub Actions에서는 불가능한 영역이에요. Actions는 매번 동일한 규칙으로 동일하게 동작하지만, Cursor Automations는 “지난번에 이건 괜찮다고 했으니 이번에는 스킵”할 수 있습니다.
주의할 점 — Slack은 public 채널만
여기서 하나 짚어야 할 게 있어요.
현재(2026년 3월 기준) Slack 트리거는 public 채널만 지원합니다. private 채널이나 DM에서는 트리거가 동작하지 않아요.
보안 관련 논의가 private 채널에서 이뤄지는 팀이라면 이 점을 감안해야 합니다. Webhook 트리거로 우회하는 방법도 있겠지만, 네이티브 지원은 아직입니다.
또 하나, Cursor 공식 사이트에서 Pro 플랜 가격이 월 $20으로 안내되는데, 이 가격에 Background Agents와 Automations가 포함되는지 정확한 범위는 공식 pricing 페이지에서 확인하는 게 좋습니다. 커뮤니티 글에서는 “Pro 플랜에 unlimited tab completion + background agents 포함”이라고 하지만, Automations 실행 횟수에 제한이 있을 수 있어요.
내가 느낀 점
이 소식을 처음 봤을 때 두 가지 감정이 동시에 왔어요.
첫 번째는 “드디어”였습니다. 평소에 .claude/agents/ 폴더에 에이전트 17개, 스킬 33개를 만들어놓고 운영하는 입장에서, 이벤트 기반 자동 실행은 항상 원하던 기능이었어요. 지금까지는 하네스 코드를 직접 짜서 health check, 자동 재시작, 폴백을 구현했는데, 이걸 플랫폼에서 기본 제공한다는 건 진입 장벽이 크게 낮아진다는 뜻이니까요.
두 번째는 “이러면 나도 바뀌어야 하는데”였습니다. 지금까지 “AI한테 말 걸어서 일 시키는 것”에 익숙해져 있었는데, “AI가 알아서 돌아가게 구조를 짜는 것”은 완전히 다른 스킬이에요. 프롬프트 엔지니어링이 아니라 시스템 디자인에 가깝습니다.
“트리거를 뭘로 잡을까? 실패하면 어떻게 처리할까? 사람 검증은 어디에 넣을까?” — 이런 질문들은 코딩 능력이 아니라 운영 감각의 영역이에요.
솔직한 마음
하나 불안한 건 있어요. “AI가 자동으로 PR 만들고, 자동으로 머지하면, 결국 사람이 빠지는 거 아닌가?”
근데 Cursor의 3대 시나리오를 자세히 보면, 전부 사람 검증(HITL, Human-in-the-Loop)이 포함되어 있어요.
- 보안 리뷰 → 고위험 발견 시 Slack으로 사람에게 알림
- Agentic Codeowners → 고위험 PR은 사람 검토자 지정
- 인시던트 대응 → 수정 PR 자동 생성, 하지만 머지는 사람 판단
결국 자동화 80% + 사람 검증 20% 구조입니다. AI가 반복 작업과 초안을 처리하고, 사람이 판단과 승인을 하는 구조. 이전에 쓴 글에서 “LLM 잘 쓰는 팀은 HITL 정책이 있다”고 했는데, Cursor Automations가 정확히 이 구조를 플랫폼 레벨에서 구현한 겁니다.
두려움보다는 기대가 더 커요. 반복 작업에서 해방되면 그 시간에 더 중요한 설계/아키텍처 작업에 집중할 수 있으니까요.
앞으로 할 것들
이 글 쓰면서 정리한 제 액션 플랜입니다.
이번 주 (3/7~3/13):
- Cursor Automations 페이지에서 보안 리뷰 자동화 1개 세팅해보기
- GitHub 트리거 → main 브랜치 푸시 시 보안 스캔 → Slack 알림 연결
- 기존 하네스 코드와 역할 분담 정리 (뭘 하네스로 남기고 뭘 Automations로 옮길지)
이번 달 (3월): 4. Scheduled cron으로 일일 코드 품질 리포트 자동 생성 테스트 5. MCP 연동 (Notion, Datadog) 가능 범위 확인 6. 팀 도입 시나리오 문서화 (10분 세팅 가이드 확장)
관찰할 것:
- false positive 비율이 반복 실행으로 얼마나 줄어드는지 (Memory 도구 효과)
- 클라우드 샌드박스 실행 속도와 안정성
- Pro 플랜 내 Automations 실행 제한 유무
FAQ
Q: Cursor Automations는 무료인가요?
A: Cursor Pro 플랜($20/월)에 Background Agents가 포함되어 있으며, Automations도 이 인프라 위에서 동작합니다. 다만 실행 횟수 제한은 공식 pricing 페이지에서 확인하세요.
Q: GitHub Actions랑 뭐가 다른가요?
A: GitHub Actions는 YAML 기반 규칙 실행(빌드·테스트·배포), Cursor Automations는 LLM 기반 판단 실행(코드 리뷰·보안 분석·트리아지)입니다. 대체가 아니라 보완 관계로, 둘 다 쓰는 하이브리드 구조가 현실적입니다.
Q: Slack private 채널에서도 동작하나요?
A: 2026년 3월 현재, Slack 트리거는 public 채널만 지원합니다. private 채널과 DM은 미지원. Webhook 트리거로 우회 가능할 수 있습니다.
Q: 자동 생성된 PR을 바로 머지해도 되나요?
A: 권장하지 않습니다. Cursor의 3대 시나리오 모두 사람 검증(HITL) 단계가 포함되어 있습니다. AI가 초안을 만들고, 사람이 검토·승인하는 구조가 안전합니다.
Q: Memory 도구가 뭔가요?
A: Cursor Automations가 과거 실행 결과를 기억하는 기능입니다. 반복 실행하면서 “이 패턴은 괜찮다”고 학습하면 false positive가 줄어듭니다. GitHub Actions에는 없는 기능입니다.
Q: 로컬 PC가 꺼져 있어도 동작하나요?
A: 네. Cursor Automations는 격리된 **클라우드 샌드박스(Cloud Agent)**에서 실행됩니다. 로컬 머신 연결 불필요, 24/7 운영 가능합니다.
Q: 기존 CI/CD 파이프라인을 완전히 대체할 수 있나요?
A: 아닙니다. 빌드·테스트·배포 같은 결정적(deterministic) 작업은 GitHub Actions/Jenkins가 더 적합합니다. Cursor Automations는 판단이 필요한 작업(코드 리뷰, 보안 분석, 인시던트 대응)에 특화되어 있습니다.
결론
AI 코딩의 진짜 변화는 “더 좋은 자동완성”이 아니었습니다.
“사람이 말 안 걸어도 AI가 알아서 돌아가는 구조” — 이게 Cursor Automations가 열어주는 세계입니다.
Copilot → Agent Mode → Automations로 이어지는 진화에서, 핵심은 “AI의 코딩 실력”이 아니라 “AI를 언제, 어떤 조건에서, 어떻게 동작시킬 것인가”를 설계하는 능력으로 무게중심이 옮겨간다는 점이에요.
프롬프트 엔지니어링에서 시스템 디자인으로. 대화형 AI에서 이벤트 기반 AI로.
이 전환은 이미 시작됐습니다. 3월 5일에.