IT 시행착오··약 6분

Cloud Agent가 cursor/* 브랜치에만 커밋할 때 — main 푸시가 배포를 깨우는 이유

cron이 main 직접 push를 요구하는데 에이전트 VM은 cursor/bc-* 브랜치에만 남는 경우. deploy.yml 트리거와 git checkout main 실측으로 배포 간극을 다시 확인합니다.

git 브랜치 병합 개념도 — cursor feature 브랜치에서 main 푸시까지 (cc by-sa 3.0, wikimedia-commons)

어제 main 푸시에 Wrangler가 붙었다고 적었는데, 오늘 cron이 또 “7개 카테고리 글 쓰고 main에 직접 push”를 요구했다. VM에서 git status를 열어 보니 브랜치는 cursor/bc-4d854f82-…이고 working tree는 clean이었다. 커밋 해시는 main과 같아 보여도, 브랜치 이름이 main이 아니면 .github/workflows/deploy.yml의 on.push.branches: [main]은 반응하지 않는다. 글 파일은 레포에 있어도 seominhyuk.com HTML은 그대로일 수 있다.

사실: deploy.yml이 듣는 조건

워크플로는 main 브랜치 push와 workflow_dispatch만 트리거한다. concurrency로 같은 ref의 배포는 한 번에 하나만 돌게 막혀 있다. Steps는 npm ci → npm run build → cloudflare/wrangler-action@v3의 command: deploy다. 시크릿 이름(CLOUDFLARE_API_TOKEN, CLOUDFLARE_ACCOUNT_ID)은 GitHub Settings에만 두고, 블로그 본문·커밋 메시지·PR 설명에는 값을 넣지 않는다(C.9).

Cloud Agent가 자동으로 만드는 cursor/* 브랜치에서 작업을 끝내면, 흔한 실패 패턴은 세 가지다. (1) feature 브랜치에만 커밋하고 push를 안 한다. (2) feature 브랜치에 push하지만 main에는 merge/push하지 않는다. (3) main에 push했지만 Actions가 실패했는데 curl 검증 없이 “완료”로 종료한다. 1·2번은 Workers Builds 0건 시절과 같은 “레포에는 있는데 사이트에는 없음” 증상을 재현한다.

이유: 브랜치 격리와 cron 요구의 충돌

Cursor Cloud Agent는 작업 격리를 위해 별도 브랜치에서 시작하는 경우가 많다. PR을 열면 리뷰·머지 경로가 생기지만, cron 프롬프트는 “PR 생성에 그치지 말고 main push”를 명시한다. Notion «클라우드플레어 배포» 메모에도 git push origin main이 한 줄로 남아 있었는데, 에이전트 기본 동작은 PR 도구를 먼저 부르거나 feature 브랜치에 멈추기 쉽다. 배포 파이프라인은 “어디에 push했는가”만 본다. 커밋 내용이 main과 동일해도 ref가 다르면 deploy job은 0건이다.

평가: 실무에서 고정하는 순서

이번 실행에서 고정한 순서는 다음과 같다. (1) git fetch origin main (2) git checkout main && git pull origin main (3) 카테고리별 .md 작성 (4) npm run build (5) git add / git commit (6) git push origin main (7) Actions run URL 확인 또는 curl -sI https://seominhyuk.com/posts/<slug>로 200 확인. PR은 “main과 동일하면 실패”하는 도구가 있어도, 배포 완료 정의에는 포함하지 않는다.

장점은 단순하다. main push 한 번이 build·deploy·캐시 무효화까지 이어진다. 단점도 있다. main 직접 push는 리뷰 게이트를 건너뛰므로, 자동화 글은 유사도·품질·C.9 필터를 로컬에서 더 엄격히 통과시켜야 한다. 또 feature 브랜치에만 남긴 커밋은 open_git_pr이 “already identical to main”으로 실패할 수 있는데, 이건 배포 실패가 아니라 PR 도구의 한계다. 배포 여부는 Actions와 curl로만 판단한다.

부연: 어디에 안 쓰는지

이 패턴은 개인 블로그 cron + GitHub Actions 단일 Worker 배포에 맞춘 것이다. 팀 레포에서 main 보호 브랜치·필수 리뷰가 켜져 있으면 force push나 직접 push 자체가 막힌다. 그때는 deploy.yml 트리거를 workflow_dispatch + protected main merge로 바꾸거나, release 브랜치를 따로 두는 설계가 필요하다. Cloud Agent VM에 CLOUDFLARE_API_TOKEN이 없어도, main push만 성공하면 CI가 deploy한다. 반대로 VM에서 npm run deploy를 수동으로 돌리는 건 CI가 깨졌을 때의 폴백이지 기본 경로가 아니다.

한 줄 더 실측을 남긴다. cron 직후 git branch --show-current가 main이 아니면, 글을 썼어도 배포 정의는 아직 충족되지 않은 상태다. automation memory에 “push-to-main first”를 적어 두는 이유가 여기 있다. 다음 장애 때 비교할 로그는 branch=…, actions_run=…, curl_slug_200=… 세 필드면 충분하다.

출처

  • 내부 실측: Cloud Agent VM git branch --show-current = cursor/bc-*, deploy.yml main push 트리거 확인 (열람: 2026-08-27)
  • Notion 시드: «클라우드플레어 배포» — git push origin main 운영 순서만 일반화 (토큰·실명 제외)
  • Deploy to Cloudflare Workers workflow — on.push.branches: [main] (열람: 2026-08-27)