클라우드 Mac에서 Cursor Automations 설정: 예약 Agent, Webhook, Background Agent 분업 실측

1. 2026년 Agent가 「트리거」와 「실행」을 나누는 이유

지난 1년 개발자 AI 도구는 온디맨드 파견(Background/Cloud Agent), 이벤트 기반(Automations), 자체 오케스트레이션(launchd, cron, n8n+MCP) 세 갈래로 진화했습니다. 「다 Agent가 자동 실행 아닌가?」라고 섞으면 Linux 샌드박스에서 iOS 빌드를 억지로 돌리거나, PR마다 Background를 수동 클릭하거나, 클라우드 Mac에 cron만 쌓고 로그는 아무도 안 보는 결과가 납니다.

납기를 늦추는 건 모델 지능보다 워크플로 진입점 불일치입니다. 먼저 「Automations 켜기」( 공식 Automations 문서 ), 다음 「PR 머지 후 Archive 자동?」(Linux만으로는 불가), 마지막 「Webhook을 클라우드 Mac에?」——본문이 푸는 결정 체인입니다.

사이트 맥락: 지난주 Background Agent 런타임 실측 은 「어느 Mac에서 돌릴지」, launchd 예약 Agent FAQ 은 「자체 macOS 오케스트레이션」. 본문은 중간층——Cursor 공식 Automations 경계와 클라우드 Mac 보완.

2. Cursor Automations: always-on Cloud Agent

2026-03-05 변경 로그와 공식 발표에 따르면 Cursor Automations는 트리거+자연어 지시+선택 도구로 상시 Agent를 구성합니다.

cursor.com/automations에서 생성; 6월 /automate 스킬로 로컬 대화에서 설정 생성(06-18 개선 참고).

트리거 유형(하나만 맞아도 실행):

• Scheduled: 주기 또는 cron;
• GitHub/GitLab: PR opened/pushed/merged, 브랜치 push, CI completed, review comment 등;
• Slack: 채널 메시지, 이모지 반응;
• Linear/PagerDuty: Issue, Cycle, Incident;
• Webhook: 저장 후 비공개 HTTP+API Key, POST로 트리거.

트리거마다 클라우드 샌드박스 기동, PR 댓글·Slack·MCP·memory 가능. repo 모드: 무 repo(알림/MCP만), 단일, 다중——무 repo는 코드 수정·PR 불가.

비대칭 결론: Automations 가치는 트리거 생태계에 있고 macOS 런타임이 아님——「PR 머지 30초 내 누군가 조사 시작」의 가격은 응답 진입점입니다.

3. Background Agent: 수동으로 보내는 장거리 한 판

Background Agent(Cloud Agent)는 온디맨드: IDE, cursor.com/agents, Slack @Cursor, API로 명시적 파견, PR·로그·실패까지 VM에서 실행. 「매주 월요 의존성 스캔」「CI 빨강 자동 수정」은 내장 없음——Automations나 cron이 클릭 대체.

암기법:

• Automations: 「X 발생 → 템플릿 Y」——반복 운영·코드 위생;
• Background Agent: 「지금 이 복잡한 일」——탐색적 리팩터, 대규모 변경;
• 클라우드 Mac launchd: 「내 plist로 macOS에서」——Keychain, Xcode, 로컬 MCP.

PagerDuty 사례: Incident→Automation→Datadog MCP→변경 추적→Slack+수정 PR——Linux로 폐루프. 마지막에 xcodebuild archive면 별도 macOS 실행 채널 필요.

4. Automations 실행 위치: Cloud Agent와 동일 Linux 샌드박스

공식 문서: Cursor 호스트 클라우드 샌드박스(Linux+Dockerfile/snapshot). 즉:

• ✅ Node/Python/Go 수정, 단위 테스트, PR, 클라우드 MCP;
• ❌ 네이티브 xcodebuild, iOS 시뮬레이터, Keychain 서명, macOS 전용 CLI;
• ⚠️ 6월 changelog computer use도 샌드박스 내부——실제 Apple 툴체인 대체 아님.

Same conclusion as our Background Agent 런타임 글 과 동일: Cursor 공식 클라우드 = Linux 우선. 별도 macOS 트리거 런타임 없음.

「클라우드 Mac에서 Automations 구성」은 ① Cursor 콘솔 논리 설정, ② macOS 작업은 Webhook/CI completed → 전용 클라우드 Mac. 검색 대부분은 ②를 의미.

5. 자동화 스택에서 클라우드 Mac 역할

전용 클라우드 Mac(M4 Mac mini 호스팅) 네 가지 역할:

1. macOS 실행 노드: xcodebuild, Flutter iOS, notarytool, 시뮬레이터——Archive CI 트러블슈팅;
2. Webhook 수신: 터널/내부 HTTP, Automations/GitHub Actions/모니터링 POST;
3. launchd 상시 호스트: Claude Code, Codex CLI(launchd Agent FAQ);
4. MCP 동일 머신 배포(MCP 배치 가이드).

Windows 주력 팀: Windows에서 코드, iOS 빌드는 클라우드 Mac, Automations는 PR 위생, 머지 후 Webhook으로 Archive——3층 분업이 한 Automation에 몰아넣기보다 안정.

6. 세 형태 5차원 비교

「트리거 vs 실행」: Automations는 트리거 다양성, Background는 단일 작업 깊이, 클라우드 Mac은 OS 능력. 한 행이 세 열을 못 채움——하이브리드 필수.

7. 하이브리드: Webhook으로 Automations → 클라우드 Mac

권장 표준 하이브리드 스택(일일 임대 1대 검증):

[GitHub PR merged]
       ↓
[Cursor Automation: trigger = PR merged, repo = 단일]
       → Linux 샌드박스: lint / 테스트 / docs PR(선택)
       → 도구: Webhook POST → https://<cloud-mac-tunnel>/hooks/ios-archive
       ↓
[클라우드 Mac 로컬: nginx/caddy + 인증]
       → launchd 또는 원샷: git pull → xcodebuild archive → exportArchive
       → 실패: Slack / Feishu webhook 알림
       ↓
[TestFlight / 내부 배포]

요점:

• Automation Webhook 도구로 payload를 지시에 추가——Webhook 전용·무 repo Automation으로 라우팅만도 가능;
• 클라우드 Mac은 단기 토큰으로 POST 검증, 노출 엔드포인트 금지;
• macOS 빌드를 Linux Automation에 넣지 말 것——Archive 파이프라인 은 Keychain/Scheme 민감. 클라우드 Mac에서 검증된 plist/Fastlane;
• 「월요 9:00 의존성 감사」는 Automations, 「월요 9:30 iOS 회귀」는 클라우드 Mac launchd——Slack으로 집계.

8. 시나리오 매트릭스

9. 권장 조합과 레드라인

조합 A(Web+iOS 소모듈): Automations로 PR 위생·의존성 bot; iOS merge 후 Webhook→클라우드 Mac Archive; Background는 대규모 마이그레이션만.

조합 B(Indie iOS): 16GB 클라우드 Mac 월임대; launchd 야간 테스트; Automations는 GitHub PR comment만(듀얼 Agent 격리).

조합 C(플랫폼/SRE): PagerDuty→Automations→Datadog MCP+수정 PR; iOS 클라이언트면 Webhook으로 클라우드 Mac 검증——Archive를 Linux에 넣지 말 것.

레드라인: ① 무 repo Automation으로 코드 수정 금지; ② Team Owned 후 Webhook API Key 로테이션·MCP OAuth 재설정; ③ 클라우드 Mac Webhook 인증+속도 제한; ④ 16GB에서 launchd 시뮬레이터+Background 병렬+Archive 동시 금지.

10. 흔한 오해

• 오해 1: 「Automations면 Background 불필요」——트리거 래퍼, 탐색 작업은 수동 Background.
• 오해 2: 「Automations가 클라우드 Mac 대체」——Linux 폐루프만. iOS/macOS는 Mac 런타임.
• 오해 3: 「Webhook=자동화 완료」——배선일 뿐. 수신 스크립트·Keychain·git 상태기가 핵심.
• 오해 4: 「launchd 글과 중복」——launchd는 자체 macOS 오케스트레이션, 본문은 공식 Automations 연결.
• 오해 5: 「예약 Agent는 전부 cron」——가능하면 Automations Scheduled 우선. macOS만 launchd.

11. 7단계 롤아웃 체크리스트

1. At cursor.com/automations 에 테스트 Automation: 6시간 Scheduled 또는 Webhook, 「오래된 의존성 Slack에」(macOS 불필요).
2. 일일 임대 클라우드 Mac 1대, 개통 검수 체크리스트 로 SSH+디스크 기선.
3. 클라우드 Mac에 최소 Webhook 수신(caddy 역프록시+Bearer), git pull && ./scripts/smoke-build.sh만.
4. 두 번째 Automation: GitHub「Workflow run completed」또는「PR merged」→Webhook→클라우드 Mac, payload에 commit SHA.
5. 같은 이벤트로 Background Agent 수동 1회, turnaround·재현성 비교.
6. macOS 빌드를 launchd plist/Fastlane에 고정. Automation 지시에 긴 shell 금지.
7. 48시간: 실제 merge 1회+의도적 실패 1회. 만족 시 월임대, Webhook Key 로테이션 SOP 기록.

12. FAQ

Q: Automations와 Background Agent를 하나로 볼 수 있나?

예. Automations=트리거+템플릿 Cloud Agent, Background=수동 Cloud Agent. Linux 런타임 공유, 「언제」설정은 별도.

Q: Automation이 클라우드 Mac에 SSH 가능?

공식 테넌트 Mac SSH 도구 없음. Webhook→클라우드 Mac HTTP 또는 self-hosted runner(병행).

Q: 무 repo Automation 용도?

Slack 집계, PagerDuty, 외부 MCP, Webhook 라우팅——코드 수정 불가. PR은 repo 바인딩.

Q: Team Owned 후 Webhook Key 교체 이유?

팀 서비스 계정화로 구 Key 무효. MCP OAuth도 팀 자격으로.

Q: 16GB 클라우드 Mac으로 이 하이브리드 충분?

단일 worktree+가끔 Archive+경량 Webhook: 16GB 일일 검증 가능. launchd 상시 시뮬레이터+병렬 Agent는 24GB 월 권장.

13. 결론

Cursor Automations는 always-on Agent를 트리거 제품화——2026년 먼저 올릴 오케스트레이션층. Background와 공유 Linux 샌드박스로 Xcode/Keychain은 못 품.

정답은 3층 분업: Automations 이벤트·템플릿 수정, Background 일회성 심층, 클라우드 Mac Webhook/launchd로 macOS 실행. 트리거 진입과 실행 경계 정렬이 핵심.

이번 주: Cursor에서 Webhook Automation 1개, 일일 임대 클라우드 Mac에 Archive 스모크——48시간 안에 공식 자동화와 Mac 런타임 자리가 보입니다.