어떤 상황이었나
매월 결산에 4~5시간을 쓴다. 첫 자동화로 KB 주통장 월말 잔액을 Runway 시트에 자동 입력하는 작은 dry-run/apply 스크립트는 이미 5월에 성공시켜 둔 상태였다. 이번 라운드의 목표는 남은 자동화(거래내역 import, 계정과목 추천, Slack 카드 대조, Mixpanel 지표, 주주보고 초안)를 끝까지 마스터 계획으로 묶는 것.
그 자리에 Rona가 month-end-close-automation 스킬을 던져줬다. 7단계 가이드, 각 step 끝마다 "다음 갈까요?" 동의 게이트, dry-run/apply 패턴, structured output, draft → review → apply 게이트까지 깔끔한 설계 컨벤션을 들고 왔다.
스킬은 친절했지만, 나는 3군데에서 비틀었다
스킬을 그대로 따라가면 자동화 7개를 일관된 패턴으로 정리할 수 있었다. 그런데 실제로 진행하니 3군데에서 내가 더 좁은/더 안전한 쪽으로 비틀게 됐다. 그 차이가 1인 운영자가 스킬을 쓰는 방식의 핵심이라 정리해 공유한다.
1. ⑥ Slack 카드 대조 → 본 라운드 제외
스킬 제안: slack_sdk 4-tuple 매칭(일자·카드끝번호·금액·상호명), 4분류(matched/slack_only/sheet_only/amount_mismatch), HTTP 429/500 재시도 백오프까지 표준 설계. 매월 20분 절약.
내 결정: 본 라운드 제외.
왜: 카드사·Slack 봇마다 메시지 포맷이 다르다. 정규식을 박으려면 실제 메시지를 보고 합의하는 또 한 라운드가 필요한데, 그 라운드 비용이 20분 절약보다 크다. 잊혔다가 우발적으로 부활하지 않게 "별도 라운드 필요"로 마스터 계획에 명문화했다.
2. ⑧ Mixpanel 풀 자동화 → "구현 전 4가지 재점검" 박음
스킬 제안: Service Account 인증(2027-03 Secret 인증 폐기 대비), WAU/MAU 쿼리, 시트 입력까지 일관된 dry-run/apply 패턴.
내 결정: 컨벤션·인증 윤곽까지만. 실제 구현 직전에 4가지를 사용자와 재점검해야 진입 허용.
어떤 지표를 매월 보고하는가 (WAU/MAU/Signup/Activation/Retention 중)
그 지표의 Mixpanel 이벤트·필터 정의
결과물 출력 형태(시트 / Markdown 요약 / Slack 게시)
검증 기준(5월 답안지가 있는지, 없으면 어떻게 정확성을 판단하는가)
왜: 코드 비용보다 이 4가지 결정 비용이 크다. 안 정한 채로 코드 박으면 폐기될 가능성이 높다. 4가지 합의 전까지 scripts/sync_mixpanel_metrics.py 구현 착수 금지를 명문화했다.
3. ⑨ 주주보고 초안 → 봇은 "제안까지", --apply 자체를 제거
스킬 제안: draft → review → apply 3단계 게이트 + Anthropic structured output cross-check ± 0.5% + codex 2차 리뷰. 봇이 시트 "초안" 탭에 쓰는 단계까지 포함.
내 결정: 봇 범위를 더 좁힘. 시트 쓰기·발송은 사람 영역으로 전부 옮김. --apply 옵션 자체를 코드에서 제거.
왜: 옵션이 존재하면 누군가 한 번쯤 누른다. 그 한 번이 잘못된 보고로 이어질 수 있다. 옵션 자체를 코드에서 빼면 봇이 그 행위를 "할 수 없게" 된다. "행위를 막는" 가드보다 "행위가 불가능한" 설계가 한 단계 강한 차단이다.
3가지를 관통하는 한 줄
스킬은 "안전한 최댓값"을 제안한다. 1인 운영자는 그보다 더 좁은 쪽으로 칠 수 있다.
도메인 비용·결정 비용을 가장 잘 아는 사람이 결국 마지막 게이트키퍼다. 스킬이 사람을 대체하지 않는다는 말이 추상이 아니라, 각 단계마다 실제 결정으로 드러났다.
스킬을 끝까지 쓰면서 좋았던 점
각 step 동의 게이트 — 7번 "다음 갈까요?"가 강제 되니 매 단계 결정이 명시적으로 남았다. 진행 중 ⑥⑧⑨ 처럼 비틀 지점이 자연스럽게 드러났다.
dry-run 기본 패턴 — 기존
update_main_balance.py의 검증된 패턴이 새 자동화 5개에 일관되게 박혔다. 컨벤션 강제력이 컸다."5월 답안지" 활용 — 이미 끝낸 5월 결산을 신규 자동화 검증의 기준선으로 쓰자는 아이디어가 강력했다. 코드 정확도를 사람이 눈으로 안 봐도 통과/실패가 즉시 판별된다.
아쉬웠던 점·앞으로
Step 3에서 dry-run 실행 단계에 들어가자마자 oauth2.googleapis.com 연결이 timeout 났다. 일반 인터넷은 되는데 Google API 호스트만 안 닿는 환경 이슈. 라이브 시트 검증은 미루고 설계 문서까지만 마치는 절충을 선택했다. 네트워크 복구 후 첫 작업은 ④ 거래내역 import의 라이브 dry-run.
산출물: 설계 문서 4개(④⑤⑧⑨) + 마스터 실행계획 1장. 매월 추정 절약 135~260분. 다음 라운드에서 ④부터 구현 시작.
이 글은 Rona의 month-end-close-automation 스킬을 받아 끝까지 진행한 1인 운영자 후기다. 스킬이 권한 것과 내가 실제로 한 일이 갈리는 지점을 정직하게 남기는 게 다음 버전에 도움 된다고 봤다.
