커서 Cloud Agents로 반복 작업 자동화하기

커서가 Background Agents를 Cloud Agent로 이름을 바꾸면서 성격도 같이 달라졌습니다. 내가 시작 버튼을 누르는 도우미가 아니라, 트리거가 오면 알아서 깨어나는 상주 프로세스에 가까워졌습니다. 2026년 6월 18일 3.8 버전에 들어온 /automate 스킬이 그 설정을 대신 써줍니다.

편해진 만큼 새로 생긴 문제도 있습니다. 그 얘기까지 같이 하겠습니다.

넘길 일과 아닌 일을 가르는 한 줄

커서 문서의 구분이 꽤 날카롭습니다. 자동화에 적합한 건 사람 개입 없이 트리거만으로 끝까지 갈 수 있는 작업이고, 부적합한 건 입력을 먼저 검토해야 판단이 서는 작업입니다.

이 기준을 실제 업무에 대보면 의외로 많은 게 걸러집니다. "PR 리뷰를 자동화하자"는 대개 후자입니다. 무엇을 문제로 볼지가 사안마다 달라지니까요. 반면 "CI가 빨갛게 뜨면 로그를 읽고 원인 후보를 댓글로 남긴다"는 전자입니다. 판단이 아니라 수집과 요약이기 때문입니다.

넘길 만한 일의 목록을 뽑아보면 대체로 이런 모양입니다.

• CI 실패 시 실패한 잡 로그를 읽고 diff에서 원인 후보를 찾아 PR에 댓글
• 매일 아침 병합된 코드 중 테스트가 없는 함수를 찾아 기존 규칙대로 테스트 PR 생성
• 지원 채널의 버그 제보를 기존 이슈와 대조해 중복 여부 확인 후 이슈 생성
• 오전 8시 45분에 최근 커밋·PR 댓글·이슈 업데이트를 모아 팀 채널에 요약

공통점이 보이시나요. 넷 다 결과물이 틀려도 사람이 곧바로 알아채는 종류입니다. 자동화 초기에는 이 조건을 지키는 게 안전합니다.

실제로 만들기 — 세 단계

1. 원하는 결과를 문장으로 쓴다

에이전트 채팅에 /automate를 치고 하고 싶은 일을 그대로 설명합니다.

/automate When a GitHub Actions workflow run finishes on a
pull request in this repo and it failed, read the failing job
logs, find the root cause in the diff, and post a PR review
comment with the diagnosis and a fix.

커서가 이 문장에서 트리거("Workflow run completed")를 고르고, 지시사항을 상주 프롬프트로 변환하고, 필요한 도구(PR 댓글, 저장소 접근)를 켭니다.

2. 생성된 설정을 확인한다

여기서 손볼 게 네 가지입니다. 도구, 저장소 범위, 모델, 권한. 특히 권한은 청구와 직결됩니다. Private/Team Visible은 만든 사람 계정에 청구되고, Team Owned로 두면 팀 풀에서 나갑니다. 공유해서 쓸 자동화라면 Team Owned가 맞습니다.

저장소 범위도 셋 중 하나를 고릅니다. 알림만 보내는 작업이면 No repository, 기본은 Single repository, 서비스 간 작업이면 Multi-repo입니다.

3. 프롬프트를 다듬는다

설명이 모호하면 설정도 모호하게 잡힙니다. 그럴 때 프롬프트를 다시 쓰는 것보다 생성된 설정을 직접 고치는 편이 빠릅니다. 재설명은 다른 방향으로 어긋날 여지가 있어서요.

이벤트가 아니라 정기 실행이 필요하면 cron 표현식을 씁니다. 평일 오전 9시라면 0 9 * * 1-5.

GitHub 트리거 5종, 각각의 쓸모

첫 자동화로는 Workflow run completed를 권합니다. 발동 빈도가 예측 가능하고, 결과가 틀려도 PR 댓글 하나라 피해가 없고, 유용하면 바로 체감되기 때문입니다.

편해진 만큼 사라진 두 가지

/automate의 강점은 설정 복잡도를 감춰준다는 것입니다. 그런데 감춰진 게 복잡도만은 아닙니다.

청구가 안 보인다

클라우드 에이전트는 항상 Max Mode로 실행됩니다. 트리거가 한 번 발동하면 Max Mode 실행 한 번의 비용이 나간다는 뜻입니다. Workflow run completed처럼 빈도가 예측되는 트리거는 괜찮은데, PR review comment는 활발한 저장소에서 하루 수십 번도 발동합니다. 요금제 기준으로 Pro는 월 20달러에 에이전트 요청 500회, Pro+는 60달러, Teams는 사용자당 40달러입니다. 탭 자동완성은 이 할당량에서 빠지지만 자동화 실행은 그대로 계산됩니다.

버전 관리가 없다

자동화 설정은 .github/workflows처럼 저장소에 커밋되는 파일이 아닙니다. 누가 언제 무엇을 바꿨는지 git으로 추적할 수 없다는 뜻입니다. 팀에서 쓴다면 저장소 어딘가에 수동으로 문서를 남겨두는 것이 사실상 유일한 감사 수단입니다. 저는 docs/automations.md 같은 파일에 트리거·대상 저장소·소유권을 적어두길 권합니다.

사소해 보이지만, 몇 달 뒤 "이 PR 댓글은 누가 다는 거야"라는 질문이 나왔을 때 답할 수 있느냐가 여기서 갈립니다.

어디서부터 시작할까

커서 문서와 사례들이 공통으로 짚는 한계가 있습니다. 클라우드 에이전트는 레거시 모놀리식, 일관성 없는 컨벤션, 불명확한 의존성, 문서 부재인 코드베이스에서 성능이 떨어집니다. 자동화가 가장 절실한 프로젝트가 대체로 그런 상태라는 게 역설이죠.

참고 삼아, 커서의 Bugbot 자동 수정 제안 중 PR에 그대로 병합되는 비율은 35% 정도로 알려져 있습니다. 이 숫자를 낮다고 볼지 높다고 볼지는 관점에 따라 다릅니다. 다만 세 번에 두 번은 사람이 손을 댄다는 전제로 워크플로를 짜야 한다는 건 분명합니다.

그러니 순서는 이렇습니다. 규칙이 또렷한 작은 모듈에서 하나만 걸어보고, 발동 빈도와 결과 품질을 며칠 지켜보고, 문서에 한 줄 남기고, 그다음에 범위를 넓힌다. 핵심 비즈니스 로직은 마지막입니다.

자동화를 늘리는 일은 결국 내가 확인하지 않아도 되는 영역을 넓히는 일입니다. 확인하지 않기로 한 것과 확인을 잊은 것은 다르고, 그 차이를 만드는 게 위에서 말한 문서 한 줄입니다.