Cursor Automations 활용법: 에이전트를 크론잡처럼 돌리기

핵심 요약: Automations는 "셸 스크립트 대신 코딩 에이전트를 실행하는 크론잡"입니다. 트리거(시간 스케줄, 또는 GitHub·Slack·Linear·웹훅 같은 이벤트) + 지시문 + 허용 도구(모델·MCP)를 정의해두면, 조건이 맞을 때 클라우드 샌드박스에서 에이전트가 돌고 결과(PR·리포트)를 배달합니다. 사람이 IDE에 없어도 돌아간다는 점에서 클라우드 에이전트의 다음 단계 — "시키는 것"에서 "시켜둔 것"으로. 잘 맞는 자리는 반복 유지보수(의존성 점검, 린트 청소, 테스트 플레이크 정리)와 이벤트 대응(PR 열리면 사전 점검)입니다. 반복 실행인 만큼 지시문 품질과 비용 상한이 성패를 가릅니다.

이 글에서 다루는 내용: 구성 요소 3가지, 잘 맞는 자동화 레시피 5개, 지시문 요령, 비용·안전 통제.

구성: 트리거 + 지시문 + 도구

자동화 하나는 세 가지로 정의됩니다. 트리거 — 시간 기반(매일 아침 9시, 매주 월요일) / 이벤트 기반(PR 열림, 테스트 실패, Slack·Linear·PagerDuty·웹훅) / 수동(API 호출). 지시문 — 에이전트에게 줄 프롬프트. 도구 범위 — 사용할 모델과 연결할 MCP. 실행은 클라우드 샌드박스에서 이뤄지고(클라우드 에이전트와 같은 기반), 이전 실행의 기억을 유지하는 옵션도 있어 회차를 거듭할수록 다듬어지는 구성이 가능합니다.

레시피 5개

① 아침 의존성 브리핑 (매일 9시) — "의존성 보안 공지와 마이너 업데이트를 확인하고, 영향받는 코드와 함께 요약 리포트." 사람이 하기엔 지루하고 안 하기엔 찜찜한 일의 대표. ② PR 사전 점검 (PR 열림 이벤트) — 시크릿·명백한 버그·관례 위반 1차 스캔 후 코멘트. CI 리뷰 파이프라인의 Cursor판입니다. ③ 주간 테스트 위생 (매주 금요일) — 플레이키 테스트 탐지·격리 제안, 느려진 테스트 목록. ④ 온콜 보조 (PagerDuty 이벤트) — 알림 발생 시 관련 로그·최근 배포 diff를 모아 초동 조사 리포트. ⑤ 문서 신선도 점검 (매주) — 코드와 README·API 문서의 불일치 목록.

지시문 요령: 크론잡의 프롬프트는 더 엄격하게

대화형과 달리 중간에 되물을 사람이 없습니다. 그래서 지시문에 세 가지가 반드시 들어가야 합니다 — 완료 기준("리포트에 항목이 없으면 '이상 없음' 한 줄로"), 중단 조건("수정 대상이 10개 파일을 넘으면 실행하지 말고 목록만 보고"), 출력 형식(받는 채널에 맞는 고정 형식). 명세 원칙(그 글)의 최대 강도 버전이라고 보면 되고, 처음엔 "보고만 하는" 자동화로 시작해 신뢰가 쌓이면 "수정 PR까지"로 승격하는 순서를 권합니다.

비용과 안전: 반복 × 에이전트 = 통제 필수

자동화는 잊힌 채 돌면서 비용을 만드는 물건입니다. 장치 세 가지 — 실행 빈도 보수적으로(매시간 돌 필요가 정말 있는지), 지출 한도·사용량 모니터링(팀 대시보드에서 자동화별 소모 추적), 권한 최소화(읽기·보고용 자동화에 쓰기 권한 금지, 훅 안전장치 — 그 레시피 — 는 자동화 실행에도 적용). 그리고 결과물이 무인으로 머지되는 경로는 만들지 마세요 — 마지막 승인은 언제나 사람입니다.

수동 위임과의 경계

모든 반복 작업이 자동화 감은 아닙니다. 기준: "입력이 매번 같은가" — 같으면(의존성 점검, 문서 대조) 자동화, 매번 판단이 다르면(리팩토링, 기능 작업) 그때그때 시키는 위임이 맞습니다. 애매하면 2주만 수동으로 같은 지시를 반복해보고, 지시문이 한 글자도 안 바뀌면 그게 자동화 후보라는 신호입니다.

자주 묻는 질문 (FAQ)

Q. 어떤 플랜에서 쓸 수 있나요?

A. 클라우드 에이전트 기반 기능이라 유료 플랜 전제이고, 베타 단계 기능은 제공 범위가 바뀔 수 있으니 공식 문서에서 현재 조건을 확인하세요.

Q. GitHub Actions로도 되는 일 아닌가요?

A. 겹칩니다. 차이는 작성 비용 — Actions는 스크립트를 짜야 하고, Automations는 지시문을 씁니다. 판단이 필요한 작업(요약, 탐지, 제안)은 에이전트 쪽이 훨씬 싸게 만들어지고, 결정적 로직(빌드·배포)은 여전히 Actions가 맞습니다.

Q. 실행이 실패하면 알 수 있나요?

A. 실행 이력과 결과를 확인할 수 있습니다. 다만 "조용히 실패하는 자동화"가 최악이므로, 지시문에 "실패·불확실 시 반드시 보고" 조건을 넣는 것을 권합니다.

한눈에 보는 요약

트리거+지시문+도구로 에이전트 크론잡을 만들되 — 완료 기준·중단 조건·출력 형식을 박고, 보고부터 시작해 승격하고, 빈도·지출·권한을 통제하세요. "입력이 매번 같은 일"이 자동화 감입니다.

함께 보면 좋은 글

Cursor Cloud Agents 사용법
Cursor 훅으로 에이전트 안전장치 만들기
AI에게 좋은 작업 명세 쓰는 법

참고 자료

Cursor Automations 공식 페이지
Cursor 공식 문서