기억력보다 시스템이 믿을 만하다
솔로 메이커의 하루는 이상할 정도로 자잘한 일로 가득 차 있습니다. 기능을 만들고 싶어서 노트북을 열었는데, 막상 손은 의존성 업데이트 알림을 확인하고 있습니다. 어제 실패한 테스트가 아직도 실패하는지 봐야 하고, 새로 올라온 버그 리포트가 중복인지 확인해야 하며, 지난주 변경사항을 정리해 사용자에게 공지해야 합니다. 급한 장애는 아니지만, 방치하면 언젠가 발목을 잡는 일들입니다.
문제는 이런 일들이 대부분 "기억해야 하는 일"이라는 점입니다. 매주 금요일에는 체인지로그를 쓰기로 했고, 매일 아침에는 테스트 상태를 보기로 했고, 새 PR을 만들면 보안 관점에서 한 번 더 보자고 마음먹었습니다. 하지만 제품을 혼자 만들고 운영하다 보면 기억은 가장 먼저 고장 나는 도구가 됩니다. 피곤한 날에는 점검을 건너뛰고, 기능 출시가 바쁜 주에는 문서 갱신을 미룹니다. 그러다 어느 날 사용자가 묻습니다. "이 기능 언제 바뀐 거예요?" 또는 더 무서운 질문이 옵니다. "왜 어제부터 로그인이 안 되죠?"
Cursor Automations는 바로 이 지점에서 등장합니다. 지금까지 Cursor의 Agent가 사람이 프롬프트를 입력하면 움직이는 작업자였다면, Automations는 일정과 이벤트를 신호로 삼아 스스로 실행되는 에이전트입니다. Cursor는 이를 "항상 켜져 있는 에이전트"로 설명합니다. 정해진 시간에 실행될 수도 있고, Slack 메시지, Linear 이슈, GitHub PR, PagerDuty 인시던트, 커스텀 웹훅 같은 외부 이벤트로도 시작될 수 있습니다.1
이 장의 핵심은 간단합니다. 하루에 한 번 해야 하는 유지보수와 점검을 사람의 기억이 아니라 시스템에 맡기는 것입니다. Automations는 마법의 운영자도 아니고, 모든 문제를 알아서 해결하는 만능 직원도 아닙니다. 하지만 반복되는 일, 입력 신호가 분명한 일, 성공과 실패를 확인할 수 있는 일에는 매우 강합니다. 잘 설계하면 당신이 자는 동안에도 에이전트는 저장소를 읽고, 로그를 확인하고, 테스트를 실행하고, PR을 만들고, 아침에 볼 수 있는 보고서를 남깁니다.
Automations는 '예약된 프롬프트'가 아니다
처음 Automations를 들으면 "아, 프롬프트를 예약 실행하는 기능이구나"라고 생각하기 쉽습니다. 절반은 맞지만, 절반은 부족한 이해입니다. 단순 예약 프롬프트라면 "매일 아침 9시에 이 문장을 Agent에게 보내기" 정도에 그칩니다. Automations의 중요한 차이는 실행 환경과 연결성에 있습니다.
Automation이 실행되면 Cursor는 클라우드 샌드박스를 띄우고, 설정된 모델과 MCP 도구를 사용해 지시사항을 수행합니다. MCP는 앞 장에서 살펴본 것처럼 Cursor가 외부 도구와 대화하기 위한 표준 연결 방식입니다. GitHub, Slack, Linear, Datadog, Notion, 내부 API 같은 도구를 에이전트의 손과 눈으로 붙일 수 있습니다. Cursor의 설명에 따르면 자동화 에이전트는 작업 후 자신의 결과를 검증하고, 이전 실행에서 배운 내용을 활용할 수 있는 메모리 도구에도 접근할 수 있습니다.1
여기서 중요한 관점 전환이 일어납니다. 기존의 Agent는 "내가 지금 시킬 일"을 처리했습니다. Automations는 "앞으로 특정 상황이 생기면 처리할 일"을 맡습니다. 다시 말해 사람의 입력이 아니라 시스템의 신호가 작업을 시작합니다.
대표적인 신호는 다음과 같습니다.
매일 오전 8시, 매주 월요일 오전 10시 같은 일정
GitHub PR 생성, PR 업데이트, main 브랜치 push, PR merge 같은 코드 이벤트
Slack 채널의 특정 메시지, Linear 이슈 생성, PagerDuty 인시던트 발생, 커스텀 웹훅 수신 같은 운영 이벤트
TechCrunch는 Automations를 두고, 사람이 모든 에이전트를 직접 시작하고 감시하는 방식에서 벗어나 필요한 시점에 에이전트가 자동으로 시작되고 사람은 적절한 지점에서 호출되는 구조라고 설명했습니다.2 이 표현은 솔로 메이커에게 특히 중요합니다. 혼자 일할 때 가장 부족한 자원은 시간이 아니라 주의력입니다. Automations의 목적은 당신을 개발에서 빼내는 것이 아니라, 당신의 주의력을 더 중요한 결정에 쓰게 만드는 것입니다.
무엇을 자동화할 것인가
자동화 후보를 고를 때는 "귀찮은가?"보다 "안전하게 맡길 수 있는가?"를 먼저 봐야 합니다. 귀찮다고 해서 결제 권한 변경이나 production 데이터베이스 수정부터 맡기면 안 됩니다. 반대로 조금 귀찮더라도 결과를 검증하기 쉽고 되돌리기 쉬운 작업은 좋은 출발점이 됩니다.
좋은 자동화 후보에는 세 가지 공통점이 있습니다. 첫째, 입력 신호가 분명합니다. PR이 열렸다, 이슈가 생성됐다, 매일 아침이 됐다, PagerDuty 알림이 왔다처럼 시작 조건이 명확해야 합니다. 둘째, 성공 기준을 테스트나 체크리스트로 확인할 수 있습니다. 테스트가 통과했는지, 문서가 갱신됐는지, 중복 이슈를 확인했는지, 관련 로그를 첨부했는지 같은 기준이 있어야 합니다. 셋째, 실패해도 되돌릴 수 있습니다. PR을 닫거나 브랜치를 삭제하거나 댓글을 정정하면 되는 작업이 좋습니다.
솔로 메이커에게 특히 잘 맞는 자동화 후보는 다음과 같습니다.
의존성 업데이트 후 테스트 실행과 변경 요약 PR 생성
최근 merge된 코드에서 테스트가 부족한 영역 찾기와 테스트 초안 작성
버그 리포트 중복 확인, 재현 절차 정리, Linear 또는 GitHub 이슈 생성
PR 사전 리뷰, 보안 위험 패턴 확인, 성능 회귀 가능성 점검
주간 체인지로그, 릴리스 노트, 문서 업데이트 초안 작성
PagerDuty나 모니터링 알림 발생 시 로그 수집, 최근 배포 내역 확인, 초동 조사 보고서 작성
Cursor가 공개한 자체 사례도 이 방향과 맞닿아 있습니다. Cursor는 보안 리뷰 자동화를 main 브랜치 push에 연결해 diff에서 취약점을 찾고, 고위험 발견 사항을 Slack에 알리도록 사용한다고 설명합니다. 또 매일 아침 최근 병합된 코드를 검토해 테스트 커버리지가 필요한 영역을 찾고, 관련 테스트를 추가한 뒤 PR을 만드는 자동화도 사용한다고 밝혔습니다.1
이 사례에서 배울 점은 "에이전트가 코드를 마음대로 바꾼다"가 아닙니다. 자동화가 다루는 일이 꽤 구체적이라는 점입니다. 보안 리뷰는 diff를 본다. 테스트 커버리지 자동화는 최근 병합된 코드를 본다. 인시던트 대응 자동화는 PagerDuty 신호를 받고 Datadog 같은 로그 도구를 통해 관련 정보를 모은다. 범위가 좁기 때문에 결과를 검토할 수 있고, 검토할 수 있기 때문에 운영에 넣을 수 있습니다.
첫 자동화는 작고 지루해야 한다
처음부터 "내 제품 운영 전체를 자동화하자"라고 생각하면 거의 실패합니다. 자동화는 작은 성공을 쌓아야 합니다. 첫 번째 Automation은 화려하면 안 됩니다. 오히려 작고 지루한 작업이 좋습니다. 예를 들어 "매일 오전 8시에 저장소의 최근 변경사항을 살펴보고, 테스트 실패 가능성이 있는 영역을 요약해 Slack에 남기기" 같은 작업입니다.
왜 이런 작업이 좋을까요? 코드 변경 권한이 없어도 됩니다. 실패해도 제품이 망가지지 않습니다. 결과가 마음에 들지 않으면 프롬프트를 고치면 됩니다. 그리고 매일 반복되기 때문에 Automation의 품질을 관찰하기 쉽습니다. 에이전트가 너무 장황한지, 엉뚱한 파일을 보는지, 같은 내용을 반복하는지, 중요한 실패를 놓치는지 금방 알 수 있습니다.
처음 만들 자동화의 구조는 다음처럼 생각하면 됩니다.
Trigger
- 매일 오전 8시 실행
Scope
- my-product 저장소의 main 브랜치
- 최근 24시간의 commit과 PR만 검토
Task
- 테스트 실패 가능성이 높은 변경사항 찾기
- 문서 업데이트가 필요한 변경사항 찾기
- 사용자에게 공지해야 할 변경사항 찾기
Verification
- 코드 수정은 하지 않는다
- 관련 파일 경로와 근거를 함께 적는다
- 확신이 낮은 항목은 '확인 필요'로 표시한다
Output
- Slack #solo-ops 채널에 10줄 이내 요약 게시
- 필요한 경우 GitHub 이슈 초안 생성이 정도면 충분합니다. 처음부터 PR 생성, 테스트 실행, 배포까지 붙이지 마세요. 자동화의 첫 단계는 "내가 놓치던 일을 에이전트가 안정적으로 발견하는가?"를 확인하는 것입니다. 발견 품질이 좋아진 뒤에 수정 권한을 조금씩 열어도 늦지 않습니다.
Automation을 만들기 전에 써야 할 작업 명세
Cursor에서 Agent를 잘 쓰려면 PRD와 Plan이 필요하다고 앞에서 여러 번 이야기했습니다. Automations에서는 그 원칙이 더 중요해집니다. 수동 Agent는 중간에 멈춰 세우고 "아니, 그건 하지 마"라고 말할 수 있습니다. 하지만 Automation은 당신이 자는 동안 실행될 수 있습니다. 그러므로 시작 전에 경계선을 문서로 남겨야 합니다.
자동화 명세에는 최소한 다섯 가지가 들어가야 합니다. 작업 범위, 접근 권한, 검증 방법, 알림 위치, 중단 조건입니다. 이것이 없으면 Automation은 똑똑해 보이다가 어느 순간 너무 넓게 움직입니다.
예를 들어 의존성 업데이트 자동화를 만든다고 해봅시다. 나쁜 지시는 이렇습니다.
매주 월요일 의존성을 업데이트하고 문제가 있으면 고쳐줘.듣기에는 간단하지만 위험합니다. 어떤 의존성을 업데이트할까요? major 버전도 올릴까요? 실패하면 어디까지 고칠까요? 테스트는 무엇을 돌릴까요? 배포 설정을 바꿔도 될까요? lockfile 충돌은 어떻게 처리할까요?
더 나은 지시는 다음과 같습니다.
매주 월요일 오전 7시에 실행한다.
대상은 my-product 저장소의 develop 브랜치다.
새 브랜치 automation/dependency-update-{date}를 만든다.
patch와 minor 업데이트만 적용한다. major 업데이트는 목록만 작성하고 변경하지 않는다.
변경 후 다음 명령을 실행한다.
- pnpm install --frozen-lockfile=false
- pnpm lint
- pnpm test
- pnpm build
성공하면 PR을 만들고 다음 내용을 포함한다.
- 업데이트한 패키지 목록
- major 업데이트를 건너뛴 패키지 목록
- 실행한 명령과 결과
- 실패한 테스트가 있다면 로그 요약
다음 작업은 하지 않는다.
- production DB 접근
- 배포 실행
- 환경변수 또는 secret 수정
- package manager 변경
- lockfile 삭제 후 재생성
테스트가 실패하면 수정은 한 번만 시도한다.
두 번째 실패부터는 PR을 draft로 만들고 Slack #solo-ops에 확인 요청을 남긴다.이 지시의 장점은 에이전트가 해야 할 일보다 하지 말아야 할 일이 더 선명하다는 데 있습니다. 자동화에서는 긍정 명령만큼 금지 명령이 중요합니다. 특히 rm -rf, 강제 push, 배포 명령, production DB 접속, secret 수정, 결제 설정 변경, 사용자 권한 변경처럼 피해가 큰 작업은 deny-list나 승인 단계로 막아야 합니다. 여기서 deny-list는 "절대 실행하지 말아야 할 명령이나 작업 목록"입니다.
안전장치: 자동화의 속도보다 중요한 것
자동화의 위험은 에이전트가 나쁜 의도를 가진다는 데 있지 않습니다. 에이전트는 의도가 없습니다. 위험은 사람이 범위를 흐릿하게 주고, 권한을 넓게 열어두고, 결과를 확인하지 않는 데서 생깁니다. 자동화는 빠르게 잘못될 수 있기 때문에, 시작할 때부터 브레이크를 설계해야 합니다.
가장 먼저 실행 환경을 분리하세요. 가능하면 Automations는 클라우드 샌드박스에서 실행하게 합니다. Cursor Automations는 트리거가 발생하면 격리된 클라우드 환경에서 에이전트를 실행하는 구조를 소개합니다.1 이 방식은 로컬 작업 디렉터리를 망가뜨리지 않는다는 점에서 유리합니다. 특히 솔로 메이커는 노트북 하나가 곧 사무실이고, 운영 콘솔이고, 개발 서버입니다. 자동화가 로컬 환경을 직접 건드리지 않게 하는 것만으로도 사고 가능성이 크게 줄어듭니다.
다음은 권한 최소화입니다. GitHub 토큰 하나에 모든 저장소 권한을 주고, Slack 전체 채널을 읽게 하고, production 로그와 결제 API까지 열어두면 편할 수는 있습니다. 하지만 자동화에 필요한 권한은 대개 그보다 훨씬 작습니다. 문서 업데이트 자동화는 결제 API를 알 필요가 없습니다. PR 리뷰 자동화는 production DB에 접근할 이유가 없습니다. 장애 초동 조사 자동화도 처음에는 읽기 전용 로그 접근만으로 충분합니다.
마지막으로 사람 승인 지점을 정해야 합니다. 자동화가 PR을 만들 수는 있어도 main에 merge하는 것은 사람 승인 후로 둘 수 있습니다. 자동화가 장애 원인을 추정할 수는 있어도 production 설정 변경은 사람이 승인하게 만들 수 있습니다. 자동화가 보안 취약점을 발견할 수는 있어도 secret 회전이나 권한 변경은 별도 절차를 타게 해야 합니다.
간단한 기준을 정해두면 좋습니다. "되돌릴 수 있는 변경은 자동화가 PR까지 만들 수 있다. 되돌리기 어렵거나 돈, 권한, 데이터에 영향을 주는 변경은 사람 승인을 거친다." 이 한 문장만 지켜도 많은 사고를 피할 수 있습니다.
완료물은 코드가 아니라 운영 기록이다
Automations를 만들 때 많은 사람이 "에이전트가 코드를 바꿔주는가?"에만 집중합니다. 하지만 운영 자동화에서 진짜 중요한 완료물은 코드 변경 자체보다 기록입니다. 특히 혼자 일하는 사람에게 기록은 미래의 나에게 보내는 인수인계입니다.
아침에 일어나서 Automation 결과를 봤다고 해봅시다. PR 하나가 올라와 있습니다. 코드 diff만 있으면 다시 처음부터 추리해야 합니다. 왜 이 변경을 했는지, 어떤 테스트를 돌렸는지, 실패한 명령은 없었는지, 어떤 로그를 근거로 판단했는지 알 수 없습니다. 그러면 자동화가 시간을 아껴준 것이 아니라 검토 부담을 뒤로 미룬 셈이 됩니다.
좋은 Automation은 항상 흔적을 남깁니다. PR 설명에는 변경 요약이 있어야 하고, 실행한 테스트 명령과 결과가 있어야 하며, 실패했다면 실패 원인과 재현 절차가 있어야 합니다. UI 작업이라면 스크린샷이나 before/after 설명이 필요합니다. 장애 조사라면 관련 로그 시간대, 최근 배포, 의심되는 commit, 아직 확인하지 못한 가설을 남겨야 합니다.
다음은 PR을 생성하는 자동화에 붙일 수 있는 출력 템플릿입니다.
PR 본문은 다음 형식으로 작성한다.
## 변경 요약
- 사용자가 이해할 수 있는 언어로 3줄 이내 설명
## 변경한 파일
- 주요 파일과 변경 이유
## 검증
- 실행한 명령
- 성공/실패 결과
- 실패 시 핵심 로그 20줄 이내 요약
## 위험도
- 낮음/중간/높음 중 하나로 표시
- 그렇게 판단한 이유
## 사람이 확인할 것
- 리뷰어가 꼭 봐야 할 체크리스트
- 확신이 낮은 부분
## 하지 않은 것
- 의도적으로 제외한 작업
- 후속 이슈가 필요한 작업이런 템플릿은 단순한 형식 놀이가 아닙니다. 에이전트에게 "일을 끝낸다"의 의미를 가르치는 장치입니다. 코드만 바꾸고 끝내는 것이 아니라, 다음 사람이 판단할 수 있는 근거를 남기는 것까지가 완료라는 기준을 주는 것입니다.
실전 예시: 매일 아침 테스트 커버리지 점검
이제 실제로 쓸 만한 자동화 하나를 설계해봅시다. 목표는 매일 아침 최근 변경된 코드 중 테스트가 부족한 영역을 찾아 PR을 만드는 것입니다. Cursor도 유사한 방식으로 최근 병합된 코드를 검토하고 테스트가 필요한 영역을 찾아 관련 테스트 타깃을 실행한 뒤 PR을 생성하는 자동화를 소개했습니다.1
솔로 메이커 버전으로 줄이면 이렇게 됩니다. 매일 오전 8시에 main 브랜치의 최근 24시간 변경사항을 확인합니다. 테스트가 없는 새 함수, 분기가 늘어난 핵심 로직, 버그 수정인데 회귀 테스트가 없는 변경을 찾습니다. 에이전트는 기존 테스트 스타일을 따라 테스트를 추가합니다. 단, 프로덕션 코드는 가능한 수정하지 않습니다. 테스트를 추가하기 위해 불가피한 작은 구조 변경이 필요하면 먼저 PR 설명에 이유를 적고, 위험도를 중간 이상으로 표시합니다.
프롬프트는 다음처럼 작성할 수 있습니다.
목표
최근 24시간 동안 main에 merge된 변경사항을 검토하고, 테스트가 부족한 영역에 회귀 테스트 또는 단위 테스트를 추가한다.
범위
- 저장소: my-product
- 기준 브랜치: main
- 작업 브랜치: automation/test-coverage-{date}
- 최근 24시간 내 merge commit과 PR만 검토한다.
작업 규칙
- 기존 테스트 파일의 네이밍과 구조를 따른다.
- 프로덕션 동작은 바꾸지 않는다.
- 테스트를 위해 필요한 경우에만 작은 리팩토링을 허용한다.
- 새 패키지를 설치하지 않는다.
- 스냅샷 테스트는 기존 프로젝트에서 이미 쓰는 경우에만 추가한다.
검증 명령
- pnpm lint
- pnpm test -- --runInBand
- pnpm build
중단 조건
- 테스트 실행 환경 자체가 깨져 있으면 수정하지 말고 원인만 요약한다.
- 같은 테스트가 두 번 연속 실패하면 더 이상 수정하지 않는다.
- 인증, 결제, 권한 로직을 변경해야 테스트가 가능하다고 판단되면 PR을 만들지 말고 이슈만 생성한다.
완료물
- PR 생성
- 변경 요약
- 추가한 테스트 목록
- 실행한 명령과 결과
- 사람이 확인할 체크리스트이 자동화의 핵심은 "테스트를 많이 만들어라"가 아닙니다. 최근 변경사항이라는 좁은 범위, 기존 테스트 스타일이라는 형식, 프로덕션 동작 변경 금지라는 가드레일, 실패 시 중단 조건이 함께 있다는 점입니다. 이런 자동화는 처음부터 완벽하지 않아도 됩니다. 첫 주에는 comment-only로 운영해도 좋습니다. 즉, PR을 만들지 않고 "테스트가 필요해 보이는 곳"만 보고하게 합니다. 결과가 신뢰할 만해지면 draft PR을 만들게 하고, 그다음에 일반 PR을 만들게 하면 됩니다.
실전 예시: 버그 리포트 triage
다음으로 좋은 후보는 버그 리포트 triage입니다. triage는 병원 응급실에서 환자의 긴급도를 분류하는 말에서 온 표현입니다. 개발 운영에서는 들어온 이슈를 중복인지, 재현 가능한지, 심각도가 높은지, 어느 영역 담당인지 분류하는 일을 뜻합니다.
솔로 메이커에게 버그 triage는 은근히 피곤한 일입니다. 사용자는 "안 돼요"라고 말하지만, 실제로는 브라우저 문제인지, 권한 문제인지, 결제 상태 문제인지, 최근 배포 때문인지 알 수 없습니다. Automations는 이 중 초동 정리를 맡기기에 좋습니다. Slack 메시지나 Linear 이슈가 생성되면 에이전트가 관련 정보를 모읍니다. 기존 이슈와 중복인지 찾고, 필요한 질문을 정리하고, 코드베이스에서 의심 지점을 찾아보고, 가능하다면 재현 절차를 만듭니다.
이 자동화는 처음부터 수정 PR까지 만들 필요가 없습니다. 오히려 처음에는 "조사 보고서"만 남기게 하는 편이 안전합니다. 예를 들어 다음과 같은 출력이면 충분합니다.
버그 triage 결과
1. 요약
- 사용자가 겪은 문제를 한 문장으로 설명
2. 중복 여부
- 유사 이슈 링크
- 중복 가능성: 낮음/중간/높음
3. 재현 절차
- 현재 정보로 가능한 재현 단계
- 추가로 필요한 정보
4. 의심 영역
- 관련 파일 또는 모듈
- 최근 변경사항과의 관련성
5. 심각도
- S1/S2/S3 중 하나
- 사용자 영향 범위
6. 다음 액션
- 사람에게 물어볼 질문
- 수정 PR을 만들기 전에 확인할 것Cursor가 소개한 사례 중에도 Slack 채널에 버그 리포트가 올라오면 중복 여부를 확인하고 Linear MCP를 통해 이슈를 생성한 뒤, 코드베이스에서 근본 원인을 조사하고 원래 스레드에 요약을 남기는 흐름이 있습니다.1 이 패턴은 혼자 일하는 사람에게도 잘 맞습니다. 중요한 것은 에이전트가 사용자와 바로 약속하지 않게 하는 것입니다. "수정했습니다"라고 답하게 하기보다 "조사 결과와 다음 확인 사항"을 남기게 하세요. 고객 커뮤니케이션은 제품의 신뢰와 직결되므로 처음에는 사람이 최종 답변을 하는 편이 안전합니다.
실전 예시: 장애 초동 조사
장애 대응은 자동화하고 싶지만 조심해야 하는 영역입니다. PagerDuty 같은 인시던트 신호가 울렸을 때 에이전트가 로그를 모으고 최근 배포와 연결해 초동 보고서를 만드는 것은 매우 유용합니다. Cursor는 PagerDuty 인시던트를 트리거로 Datadog MCP를 사용해 로그를 조사하고, 최근 코드 변경을 확인한 뒤, 온콜 엔지니어를 위한 Slack 메시지와 제안 수정 PR을 첨부하는 사례를 소개했습니다.1
솔로 메이커는 온콜 엔지니어도 자기 자신입니다. 새벽에 알림이 왔을 때 가장 힘든 순간은 "어디서부터 봐야 하지?"입니다. 자동화가 이 첫 10분을 줄여줄 수 있습니다. 알림이 발생하면 에이전트가 최근 1시간의 에러 로그, 최근 24시간의 배포 내역, 에러가 집중된 endpoint, 영향받은 사용자 수 추정, 관련 commit을 모아 Slack이나 이메일로 보냅니다.
다만 장애 자동화에는 강한 제한이 필요합니다. 처음 단계에서는 읽기 전용으로 두세요. 로그 조회, 배포 이력 조회, 코드 diff 확인까지는 허용하되, 롤백 실행, DB 수정, feature flag 변경, scale 조정, 결제 상태 변경은 사람 승인을 거치게 합니다. 에이전트가 제안할 수는 있지만 실행하지는 않게 하는 것입니다.
장애 초동 조사 프롬프트에는 이런 문장을 넣을 수 있습니다.
너는 장애 초동 조사 에이전트다.
목표는 원인을 확정하는 것이 아니라, 사람이 5분 안에 상황을 파악하도록 근거를 모으는 것이다.
허용된 작업
- 최근 로그 조회
- 최근 배포 및 commit 확인
- 에러 빈도와 영향 endpoint 요약
- 유사 과거 인시던트 검색
- 가능한 원인 가설 작성
금지된 작업
- 배포 또는 롤백 실행
- production DB 쓰기 작업
- secret, 환경변수, 권한 변경
- 고객에게 직접 메시지 발송
- 결제, 구독, 계정 상태 변경
출력
- 현재 상태 요약
- 영향 범위
- 가장 가능성 높은 원인 3개
- 확인한 근거
- 지금 사람이 해야 할 일
- 에이전트가 확신하지 못하는 부분이 자동화는 문제를 해결하는 자동화가 아니라, 공포를 줄이는 자동화입니다. 새벽의 운영자는 완벽한 답보다 좋은 출발점이 필요합니다.
MCP와 웹훅으로 연결하되, 작게 열기
Automations의 힘은 외부 세계와 연결될 때 커집니다. GitHub PR을 읽고, Slack에 메시지를 남기고, Linear 이슈를 만들고, 모니터링 시스템에서 로그를 가져오고, 내부 API로 상태를 확인할 수 있습니다. Cursor는 기본 통합 외에도 웹훅을 통해 커스텀 이벤트를 구성할 수 있다고 설명합니다.1
웹훅은 어떤 일이 일어났을 때 외부 시스템이 Cursor에 "지금 실행해"라고 알려주는 신호입니다. 예를 들어 결제 실패 이벤트가 발생했을 때, 내부 백오피스에서 특정 플래그가 켜졌을 때, 사용자 피드백 폼이 제출됐을 때 Automation을 실행할 수 있습니다. 다만 연결 가능한 것이 많다고 해서 모두 연결하면 안 됩니다.
권한은 작게 열고, 출력도 한 곳으로 모으는 것이 좋습니다. 처음에는 Slack의 공개 운영 채널 하나, GitHub의 특정 저장소 하나, Linear의 특정 팀 하나만 연결하세요. MCP 서버나 웹훅을 추가할 때마다 "이 자동화가 이 권한을 정말 필요로 하는가?"를 물어야 합니다. 필요하지 않은 권한은 장애의 재료가 됩니다.
내부 API를 연결할 때는 더 신중해야 합니다. 가능하면 읽기 전용 endpoint를 따로 만들고, 자동화 전용 토큰을 발급하세요. 토큰에는 만료일을 두고, 어떤 Automation이 어떤 API를 호출했는지 로그를 남기세요. 솔로 메이커라고 해서 감사 로그가 필요 없는 것이 아닙니다. 혼자일수록 어제의 내가 무엇을 자동화했는지 기억하지 못할 가능성이 큽니다.
자동화가 늘어날수록 소음도 늘어난다
Automation을 몇 개 만들고 나면 이상한 일이 생깁니다. 분명 시간을 아끼려고 만들었는데, Slack 알림이 더 많아집니다. PR이 늘어나고, 이슈가 늘어나고, "확인 필요" 메시지가 쌓입니다. 자동화의 적은 실패만이 아닙니다. 성공처럼 보이는 소음도 적입니다.
소음을 줄이려면 각 자동화마다 알림 기준을 정해야 합니다. 모든 실행 결과를 Slack에 보내지 말고, 성공한 실행은 일일 요약에만 포함할 수 있습니다. 실패, 위험도 높음, 사람 승인 필요, 테스트 실패, 보안 의심 같은 경우만 즉시 알림으로 보냅니다. 나머지는 대시보드나 주간 요약으로 충분합니다.
또 하나 중요한 지표는 오탐입니다. 오탐은 문제가 아닌데 문제라고 판단하는 것입니다. 보안 리뷰 자동화가 매번 별것 아닌 경고를 올리면 결국 당신은 보안 알림을 무시하게 됩니다. 테스트 자동화가 의미 없는 테스트만 계속 만들면 PR을 열어보지 않게 됩니다. 자동화는 신뢰 잔고를 먹고 삽니다. 쓸모없는 알림을 한 번 보낼 때마다 다음 알림의 무게가 줄어듭니다.
처음 몇 주 동안은 자동화별로 간단한 운영 지표를 기록해보세요. 실행 횟수, 성공률, 사람이 실제로 채택한 PR 비율, 닫은 PR 비율, 오탐으로 판단한 알림 수, 평균 비용을 보면 됩니다. 이 숫자는 거창한 분석을 위한 것이 아니라 "계속 켜둘 가치가 있는가?"를 판단하기 위한 것입니다.
멀티 에이전트 파이프라인은 나중에 생각하라
에이전트 시대의 데모는 늘 멋집니다. 하나의 이벤트가 발생하면 분석 에이전트가 로그를 보고, 수정 에이전트가 PR을 만들고, 리뷰 에이전트가 검토하고, QA 에이전트가 테스트하고, 릴리스 에이전트가 배포합니다. 듣기만 해도 미래 같습니다. 하지만 솔로 메이커가 처음부터 이런 파이프라인을 만들면 대부분 운영하기 어렵습니다.
자동화는 복잡할수록 실패 지점이 늘어납니다. 첫 번째 에이전트가 잘못된 가설을 만들면 두 번째 에이전트는 그 가설을 바탕으로 잘못된 수정 PR을 만듭니다. 세 번째 에이전트가 그 PR을 그럴듯하게 리뷰하면, 틀린 결론이 점점 단단해집니다. 이것을 막으려면 중간마다 사람의 판단 지점과 검증 기준이 필요합니다.
그러니 순서는 단순해야 합니다. 먼저 하루 한 번 실행되는 작은 유지보수 작업을 만듭니다. 결과를 관찰합니다. 프롬프트를 조정합니다. 권한을 줄입니다. 출력 형식을 고칩니다. 성공률이 안정되면 PR 리뷰, QA, 보안 점검, 장애 초동 조사 같은 이벤트 기반 워크플로로 확장합니다.
좋은 성장 순서는 다음과 같습니다.
1단계: 읽기 전용 요약 자동화
2단계: draft PR 생성 자동화
3단계: 테스트와 체크리스트를 포함한 PR 자동화
4단계: 특정 이벤트에 반응하는 triage 자동화
5단계: 사람 승인 후 실행되는 운영 자동화
이 순서를 지키면 자동화가 제품을 위협하는 존재가 아니라, 당신의 운영 습관을 조금씩 강화하는 시스템이 됩니다.
솔로 메이커의 Automation 운영 원칙
Automations를 잘 쓰는 사람은 에이전트에게 많은 일을 시키는 사람이 아닙니다. 에이전트가 해도 되는 일과 하면 안 되는 일을 명확히 나누는 사람입니다. 혼자 일할수록 이 원칙이 중요합니다. 팀에서는 누군가 이상한 PR을 보고 말릴 수 있지만, 솔로 메이커의 자동화는 조용히 쌓입니다.
마지막으로 실전에 바로 적용할 수 있는 원칙을 정리해보겠습니다.
반복되지만 자주 까먹는 일부터 자동화한다.
입력 신호가 명확하고, 성공 기준을 검증할 수 있으며, 되돌릴 수 있는 일만 맡긴다.
처음에는 읽기 전용 또는 comment-only로 시작한다.
코드 변경보다 운영 기록을 완료물로 요구한다.
production, 결제, 권한, secret, DB 쓰기 작업은 기본적으로 금지한다.
MCP와 웹훅 권한은 필요한 만큼만 열고, 자동화별 토큰을 분리한다.
실패보다 소음을 경계하고, 오탐이 많은 자동화는 과감히 끈다.
Automations의 목적은 당신이 아무것도 하지 않아도 되는 제품을 만드는 것이 아닙니다. 오히려 반대입니다. 당신이 해야 할 일을 더 선명하게 만드는 것입니다. 에이전트는 밤새 로그를 모으고, 테스트를 돌리고, 문서를 정리하고, PR을 준비할 수 있습니다. 하지만 무엇을 출시할지, 어떤 위험을 감수할지, 사용자에게 어떻게 설명할지는 여전히 당신의 일입니다.
이제 솔로 메이커의 워크플로우는 조금 달라집니다. 밤에 노트북을 닫는 순간 일이 완전히 멈추지 않습니다. 잘 설계한 작은 Automation 하나가 저장소를 살피고, 놓친 일을 기록하고, 아침에 당신을 기다립니다. 중요한 것은 에이전트가 잠을 자지 않는다는 사실이 아닙니다. 당신이 잠든 사이에도 제품을 지키는 규칙이 작동한다는 사실입니다.
다음 장에서는 이 흐름이 한 걸음 더 나아갑니다. Cloud Agents와 모바일에서 일을 시작하는 방식입니다. 이제 작업은 책상 앞에서만 시작되지 않습니다. 산책 중 떠오른 아이디어, 이동 중 발견한 버그, 침대에 눕기 전 남긴 한 줄 지시가 클라우드에서 실제 작업으로 이어질 수 있습니다.
참고
2TechCrunch - Cursor is rolling out a new kind of agentic coding tool
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.