에이전트가 ‘알아서’ 다시 깨어날 때 — Cursor Subscriptions와 /goal을 하네스로 쓰는 법
2026년 8월 19일 Cursor changelog는 cloud agent를 한 번의 긴 세션이 아니라 이벤트가 오면 다시 깨어나는 시스템으로 밀었습니다. Subscriptions, /goal, 그리고 서브에이전트 전용 VM이 그 축입니다.
핵심 한 줄: “개입 없이 알아서 돌린다”를 마케팅으로 읽지 말고, 언제 깨우고·무엇을 끝으로 볼지·사람이 어디서 끊을지를 하네스에 박으세요.
왜 중요한가
지금까지 많은 팀이 cloud agent를 이렇게 썼습니다.
- 목표를 프롬프트에 적는다
- 에이전트가 PR을 연다
- CI가 깨지면 사람이 다시
@cursor 고쳐한다
Aug 19 릴리스의 Subscriptions는 3번을 제품 기능으로 옮깁니다. 에이전트가 PR·Slack 스레드·스케줄에 구독하고, 이벤트가 오면 같은 대화로 다시 깨어납니다. changelog 표현 그대로 “always-on agents can operate as a system”에 가깝습니다.
이게 중요한 이유는 실패 모드가 바뀌기 때문입니다.
| 이전 실패 | 새 실패 |
|---|---|
| 한 번에 틀린 답 | 조용히 반복되는 수정 루프 |
| 사람이 프롬프트를 잊음 | 구독이 남아 토큰·권한·머지 압력이 계속 쌓임 |
| 컨텍스트 충돌은 로컬에서 | 서브에이전트 VM이 늘면 비용·브랜치 스웜이 늘음 |
PapaCoder Labs처럼 “에이전트는 초안만, 사람은 발행”인 조직에서는, Subscriptions를 발행 버튼의 대체로 쓰면 안 됩니다. 대신 CI 그린 유지·리뷰 코멘트 소화 같은 중간 루프에 두고, 최종 머지/프로덕션은 사람 게이트에 남겨야 합니다.
이전과 어떻게 다른가
같은 달의 다른 Cursor 소식과 겹쳐 읽으면 포지션이 선명해집니다.
| 날짜 | 무엇 | 한 줄 |
|---|---|---|
| 2026-08-13 / 기본 적용 08-17 | Builds | 환경을 따뜻하게 띄워 시작을 빠르게 |
| 이전 Agents Window | /in-cloud, /babysit | 클라우드 서브에이전트로 PR을 돌봄 |
| 2026-08-19 | Subscriptions + /goal + 서브에이전트 VM | 대기했다가 이벤트로 재개 + 목표를 세션 너머로 고정 + 병렬 격리 |
Builds는 “부팅 비용” 문제였고, Subscriptions는 “사람이 다시 불러줘야 하는 문제”입니다. /babysit이 이미 PR 돌봄을 제안했다면, Subscriptions는 그걸 이벤트 구독으로 일반화한 쪽에 가깝습니다(PR뿐 아니라 Slack·스케줄·문서상 Linear/타이머까지).
경쟁 축으로 보면 GitHub Copilot cloud agent의 “코멘트에 반응” 패턴과 방향은 비슷합니다. 차이는 Cursor가 changelog에서 구독·목표·격리 VM을 한 번에 “harness” 이야기로 묶었다는 점입니다. 도구 이름보다 루프의 소유권(누가 stop을 정의하는가)이 비교 포인트입니다.
설정·프롬프트 예시
공식 문서(Capabilities) 기준으로 구독은 프롬프트에 “기다림”을 적거나 /subscribe 스킬로 잡을 수 있습니다. 팀이 바로 쓸 수 있는 계약형 예시입니다.
# Cloud Agent prompt (Subscriptions + /goal)
/goal Keep PR #482 mergeable: CI green, address bot review comments,
do NOT expand scope beyond the linked issue.
Also subscribe to:
- this PR's CI + review comments
- Slack thread #release-482 for maintainer "LGTM" or "stop"
Stop / unsubscribe when ANY of:
1) maintainer says "stop" or "I'll take it"
2) CI green AND human approval comment present
3) 6 hours elapsed without new actionable events
Hard rules:
- Never force-push to main
- Never change secrets / billing / production deploy scripts
- Prefer small commits; open follow-up issues instead of scope creep
Custom Mode로 “draft-only / no-publish” 플레이북을 핀해 두면(/goal과 함께 쓰라는 changelog 조언과 맞습니다), 에이전트가 긴 세션에서도 같은 벽을 보게 됩니다.
서브에이전트 VM 쪽은 의도적으로 짧게:
Spawn two isolated subagents on their own VMs:
1) reproduce the failing e2e and propose a minimal fix
2) audit only the auth middleware for regressions
Parent merges results; do not let both rewrite the same files.
실무에서 쓰는 법
추천하는 첫 적용 (좁게)
- 에이전트가 연 PR 하나에만 auto-subscribe 허용
/goal은 “CI 그린 + 봇 코멘트 대응”처럼 종료 조건이 측정 가능한 것만- Slack 구독은 한 스레드로 제한 (채널 전체 금지)
- 머지 버튼·프로덕션 배포는 사람
피해야 할 첫 적용 (넓게)
- “레포 전체 PR을 항상 그린으로”
/goal에 “제품 완성”처럼 끝이 없는 문장- 서브에이전트 스웜을 비용 한도 없이
문서상 구독은 하나의 에이전트 대화에 속하고, 가까운 이벤트는 합쳐질 수 있으며, 최대 180일까지 유지될 수 있습니다. “잠깐 babysit”이 아니라 장기 대기열이 될 수 있다는 뜻입니다. 팀이 모르는 구독이 남아 있으면, 그건 장애가 아니라 운영 부채입니다.
처음엔 저도 “Slack에만 한 줄 남기면 알아서 끝나겠지”에 가까운 마음으로 넓은 구독을 걸었다가, 리뷰 봇이 같은 스타일 지적을 반복할 때마다 에이전트가 깨어 커밋을 쌓는 걸 보고 멈췄습니다. 구독 범위 = 사고 반경이었습니다.
시니어 관점
Always-on은 생산성 기능이기도 하지만, 권한의 시간축을 늘리는 기능이기도 합니다. 한 번의 승인으로 여섯 시간짜리 루프를 열면, 그 사이 머지된 메인·바뀐 시크릿·바뀐 정책이 에이전트 컨텍스트와 어긋날 수 있습니다.
시니어가 먼저 적어야 할 세 줄:
- Allowed event sources (PR self / named Slack thread / timer)
- Definition of done (
/goal에 복사 가능한 문장) - Kill switch (사람이
stop하면 unsubscribe + 작업 중단)
Builds가 “잘못된 install 커밋에서도 마지막 성공 스냅샷으로 버틴다”면, Subscriptions는 “잘못된 피드백 루프에서도 사람이 끊기 전까지 버틴다”에 가깝습니다. 내결함성과 무한 루프는 한 글자 차이입니다.
Cursor에서 바로 적용
- Cloud Agents 환경에서 Builds가 건강한지 확인(08-17 기본화 이후라면 특히). 느린 부팅이면 이벤트 루프 전에 환경을 고치세요.
- 새 채팅에서
/goal …로 종료 가능한 목표를 적고, Custom Mode로 팀 플레이북을 핀합니다. - “open a PR and keep it green until merge”처럼 기다림을 문장에 포함하거나
/subscribe를 씁니다. - 긴 작업 중 스티어링은 중간에 끊지 않고 다음 툴 콜까지 대기한다는 changelog 동작을 전제로, 급한 stop은 명확한
stop메시지 규약을 팀에 공유합니다. - 병렬 검증이 필요하면 서브에이전트를 별도 VM으로 돌리고, 부모가 머지 책임을 집니다.
PapaCoder 운영 원칙과 맞추면: 에이전트 구독은 draft/CI 루프까지, Admin Publish·프로덕션은 사람.
FAQ
Q. Subscriptions는 로컬 에이전트에도 되나요?
A. changelog 기준 cloud agents only, for now입니다.
Q. /goal만 쓰면 구독이 자동으로 생기나요?
A. /goal은 장기 목표 유지이고, 이벤트 대기는 프롬프트의 wait 설명 또는 /subscribe로 잡는 쪽이 문서와 맞습니다. 자동 구독이 명시된 케이스는 에이전트가 직접 만든 PR입니다.
Q. 서브에이전트 VM은 언제 쓰나요?
A. 부모 변경을 깨끗한 환경에서 검증하거나, 서로 다른 파일을 고치는 스웜이 필요할 때. 같은 파일에 두 VM이 동시에 쓰면 충돌 비용이 커집니다.
Q. 180일은 너무 긴 것 아닌가요?
A. 상한입니다. 실무에서는 목표 달성·stop·짧은 타이머로 훨씬 일찍 끊는 게 안전합니다.
Q. 비용은?
A. 이번 런에서 요금표까지 교차검증하지 못했습니다. 장기 구독·멀티 VM은 플랜/사용량에 민감하니, 팀 롤아웃 전에 Cursor 과금 문서를 확인하세요.
소스
- Cloud Agents and Cursor Harness Improvements (2026-08-19)
- Cloud Agent capabilities — Subscriptions
- Subagents
- Builds changelog (2026-08-13) · Builds blog
마무리
Cursor는 “에이전트가 매 루프마다 사람을 기다리지 않게” 만들고 있습니다. 그 방향 자체는 맞습니다. 다만 팀이 사야 하는 것은 자율이 아니라 종료 조건이 있는 자율입니다.
앞으로 몇 분기는 Subscriptions 같은 이벤트 루프가 에디터 경쟁의 기본값이 될 가능성이 큽니다. 그때 승자는 프롬프트를 더 길게 쓴 팀이 아니라, 구독·목표·킬 스위치를 레포 규칙으로 박아 둔 팀일 겁니다.