cron이 글을 쓰는 동안 미리보기는 `astro dev --background`로 — 터미널을 붙잡지 않는 법

증상은 익숙했다. src/content/posts/에 md를 여러 편 넣고 npm run build는 통과했는데, “카테고리 첫 카드가 맞는지”를 눈으로 확인하려면 dev 서버가 필요했다. 그런데 npm run dev를 포그라운드로 띄우면 터미널이 붙잡혀 cron·에이전트가 다음 단계(빌드·커밋·푸시)로 못 넘어간다. 프로덕션은 Workers에만 있고 스테이징 URL이 없는 구성에서는, 배포 전 로컬 미리보기가 유일한 조기 경보인데, 그 경보를 띄우는 방식이 곧 자동화 SLA가 된다.

사실: Astro 7의 --background는 프로세스를 놓아준다

레포 package.json의 dev 스크립트는 astro dev 한 줄이다. Astro CLI 7.x에는 별도 서브커맨드가 있다. astro dev --background로 띄우면 PID와 URL이 즉시 출력되고 셸은 반환된다. 이번 실측(2026-09-04)에서는 http://localhost:4321에 pid 4395로 기동됐고, astro dev status가 uptime을 보여 줬다. astro dev logs에는 콘텐츠 동기화와 ready in 2231 ms가 남았다. 끝날 때는 astro dev stop으로 같은 PID를 종료했다.

포그라운드 astro dev와 산출물은 같다. 차이는 프로세스 소유권이다. Cloud Agent·cron 스크립트는 한 터미널에서 빌드·curl·git을 이어야 하므로, dev를 백그라운드로 두는 편이 자연스럽다. AGENTS.md에 적어 둔 astro dev --background / stop / status / logs는 문서 장식이 아니라, “미리보기 때문에 자동화가 멈추지 않게” 하는 운영 계약에 가깝다.

이유: 미리보기·빌드·배포는 계층이 다르다

npm run build가 성공해도 pubDate 정렬·카테고리 리드·relatedSlugs 렌더는 브라우저에서 한 번 더 보는 편이 싸다. 반면 dist/만 열어도 되는 검증(사이트맵 loc, HTML 첫 카드)은 dev 없이 끝난다. 문제는 마크다운 프리뷰·태그·히어로 원격 URL 로딩처럼 개발 서버 HMR이 편한 구간이다.

Notion에 정리해 둔 “운영은 Cloudflare, 개발은 localhost” 패턴과 맞물린다. 프리뷰 Workers가 없으면 astro dev --background + dist 스모크가 조기 경보다. 시니어 IT 실무자 시각으로 보면, 자동화 파이프라인에 “선택적 dev 스모크” 단계를 넣되 터미널 점유 시간은 0에 가깝게 유지하는 게 핵심이다. 배포 후 curl 200은 최종 게이트이고, dev는 그 전에 레이아웃·frontmatter 깨짐을 잡는 완충재다.

평가: 쓰는 곳과 안 쓰는 곳

쓰는 곳: 카테고리 7편 동시 발행처럼 pubDate 시각을 촘촘히 넣을 때, 새 slug 경로가 라우팅되는지 빠르게 확인할 때, Pagefind·빌드 전에 콘텐츠 컬렉션 동기화 오류를 볼 때. 안 쓰는 곳: 프로덕션과 동일한 Workers html_handling·캐시 동작 검증(이건 dist + wrangler deploy 또는 Actions), 장시간 수동 편집 세션(그때는 포그라운드 dev가 낫다), 이미 astro dev가 다른 세션에서 떠 있을 때 --ignore-lock 없이 중복 기동.

한계도 분명하다. background dev는 로컬 Node 환경에 묶인다. CI에는 그대로 옮기기 어렵고, “dev에서 보임 = 프로덕션 OK”가 아니다. 그래서 이 레포의 cron 검증 루프는 dev 스모크(선택) → build → push → gh run watch → slug curl 순으로 정의하는 편이 안전하다. dev만 하고 배포를 건너뛰면 독자에게는 아무 일도 없었다.

부연: 최소 체크와 다음 관찰

실무에서 남긴 최소 루프는 네 줄이다. (1) astro dev --background 후 status로 URL·PID 확인. (2) 새 글 /posts/<slug>/ 또는 카테고리 첫 카드 스모크. (3) astro dev stop. (4) npm run build → 커밋·푸시. 로그에 비밀값 없이 dev_pid=… ready_ms=2231만 남겨도 다음 장애 때 비교점이 된다.

반례로, dev를 띄운 채 빌드·배포를 잊으면 “미리보기만 최신”인 상태가 길어진다. stop을 빼먹으면 포트 4321 점유가 다음 실행을 막을 수 있다. 자동화 스크립트 끝에 astro dev stop을 넣거나, 시작 전 status로 잔존 프로세스를 정리하는 습관이 필요하다. 다음에 볼 것: CI에 headless로 카테고리 HTML 스냅샷을 넣을지, 아니면 dev background를 에이전트 전용 단계로만 둘지. 정적 블로그에서 미리보기는 빠를수록 좋지만, 발행 정의는 여전히 main 푸시 뒤 200 응답이다.

출처

• 내부 실측: npm run astro -- dev --background → http://localhost:4321 pid 4395, ready in 2231 ms, dev status·dev logs·dev stop 확인 (2026-09-04, 비밀값 제외)
• Notion 시드: «리뷰올 오프아이스 구성 설명» — 운영 URL만 Cloudflare, 개발은 localhost 패턴(공개 가능 요지만)
• Astro CLI: astro dev — --background, stop, status, logs 서브커맨드 (열람: 2026-09-04)