Cursor, /automate 공개… Slack·GitHub로 상시 AI 자동화

무엇이 공개됐나

Cursor는 6월 18일 changelog에서 /automate 스킬, Slack 이모지 트리거, GitHub 신규 이벤트 트리거를 묶어 발표했습니다. 설명대로라면 사용자는 로컬 에이전트 세션에서 자연어로 자동화를 만들고, 그 자동화는 이슈 댓글, PR 리뷰 댓글, 리뷰 제출, 리뷰 스레드 상태 변경, GitHub Actions 완료 같은 이벤트에 반응할 수 있습니다.

즉, “PR 하나 봐줘”를 매번 손으로 던지는 대신 실패한 액션이 생기면 자동으로 원인 정리를 하거나, 리뷰 댓글이 달리면 자동으로 수정 작업을 이어가는 구조를 만들 수 있다는 뜻입니다.

클라우드 에이전트와 왜 같이 봐야 하나

하루 전인 6월 17일 Cursor는 Agents Window 쪽에서 클라우드 개발 환경 준비, /in-cloud 서브에이전트, 로컬과 클라우드 사이 세션 핸드오프를 공개했습니다. 공식 설명 기준으로 에이전트는 별도 VM과 브랜치에서 돌아가고, 환경 스냅샷을 저장해 다음 실행도 더 빠르게 이어갈 수 있습니다.

그래서 이번 6월 18일 자동화 발표는 단독 기능보다, 이벤트가 오면 클라우드 에이전트가 계속 돌면서 테스트와 수정까지 이어가는 퍼즐의 마지막 조각처럼 읽는 편이 더 정확합니다.

누구에게 실질적으로 달라지나

이 변화는 특히 CI 실패 정리, PR 리뷰 후속 수정, 슬랙에서 반복 요청되는 운영성 작업이 많은 팀에게 체감이 큽니다. Cursor가 직접 예시로 든 것도 실패한 GitHub Actions 트리아지와 PR 리뷰 댓글 자동 수정입니다.

쉽게 비유하면 지금까지의 AI 코딩 도구가 “옆자리에 앉아 잠깐 도와주는 조수”였다면, 이번 구조는 특정 벨이 울리면 알아서 출근하는 야간 당번에 조금 더 가깝습니다. 이 차이가 팀 운영에서는 꽤 큽니다.

먼저 체크할 점

다만 상시 자동화가 곧바로 무제한 자율주행을 뜻하지는 않습니다. Cursor docs도 개발 환경 준비, 저장소 권한, 비밀값 접근, 네트워크 연결 같은 기반이 갖춰져야 에이전트가 테스트와 검증까지 닫을 수 있다고 설명합니다.

그래서 팀이 먼저 정해야 할 것은 “자동화가 가능한가”보다 어디까지 자동으로 고치게 둘지, 어떤 이벤트는 사람 승인 전까지만 움직이게 할지입니다. 상시 에이전트의 가치는 크지만, 경계 설정이 느슨하면 운영 부담도 같이 커집니다.