AI 블로그 자동화에서 유지보수 창을 정하는 법

요약

Futory처럼 평일마다 AI가 Markdown 글을 만들고 Next.js 빌드와 PM2 재시작까지 수행하는 블로그에서는 “언제 실행할 것인가”가 콘텐츠 품질만큼 중요합니다. 자동화가 아무 때나 파일을 쓰고 서버를 재시작하면 사용자가 글을 읽는 중에 응답이 흔들리거나, 운영자가 실패 보고를 확인하기 어려운 시간에 문제가 생길 수 있습니다. 그래서 반복 발행에는 작고 명확한 유지보수 창이 필요합니다.

유지보수 창은 거창한 배포 시스템이 아니라, 글 작성부터 공개 검증까지의 작업을 허용하는 시간 범위입니다. Futory의 경우 KST 평일 오후 2시부터 6시 사이에서 하루 한 시간을 선택하고, 그 시간에만 새 글을 만들도록 제한하면 중복 실행과 불필요한 재시작을 줄일 수 있습니다. 바이브코딩은 빠른 시도와 수정이 장점이지만, 공개 블로그 운영에서는 빠른 실행도 독자가 예측 가능한 리듬 안에 들어와야 안정적으로 보입니다.

유지보수 창이 필요한 이유

자동 발행은 한 번의 글쓰기처럼 보이지만 실제로는 여러 운영 작업의 묶음입니다. 날짜 중복 검사, Markdown 파일 생성, 콘텐츠 테스트, 테마 테스트, Next.js 빌드, 산출물 확인, PM2 재시작, 공개 URL 검증이 순서대로 이어집니다. 이 중 일부는 읽기 전용 확인이지만, 파일 생성과 재시작은 명확한 변경입니다. 변경이 있는 작업은 언제 실행되는지 정해져 있어야 장애가 생겨도 원인을 추적하기 쉽습니다.

모든 시간대가 같은 위험을 갖지는 않는다

블로그 트래픽이 많지 않더라도 배포와 재시작은 독자가 접속하는 순간과 겹칠 수 있습니다. 새 글 하나를 올리는 일이라도 빌드가 오래 걸리거나 PM2 재시작이 실패하면 사이트 반영이 지연될 수 있습니다. 유지보수 창을 두면 이런 위험을 하루 중 관리 가능한 시간대로 모을 수 있습니다. 운영자는 해당 시간대의 보고만 확인하면 되고, 자동화는 나머지 시간에 불필요하게 시스템을 건드리지 않습니다.

SKIP도 운영 결과다

유지보수 창을 쓰면 많은 실행이 새 글을 만들지 않고 SKIP으로 끝납니다. 이것은 실패가 아니라 정상적인 안전장치입니다. 예를 들어 크론이 여러 시간에 실행되더라도 오늘 선택된 시간이 아니면 아무 파일도 쓰지 않습니다. 이미 오늘 날짜 글이 있으면 같은 시간에 다시 실행되어도 중복을 만들지 않습니다. 자동화 운영에서는 “하지 않는 결정”이 “하는 결정”만큼 중요합니다.

Futory에 맞는 시간 규칙

Futory의 평일 발행은 KST 기준으로 해석하는 편이 자연스럽습니다. 독자와 운영자가 한국어 콘텐츠를 읽고 확인하기 때문입니다. UTC 기준 크론이 여러 번 실행되더라도 내부 판단은 Asia/Seoul 날짜와 시간을 기준으로 고정해야 날짜 착오를 줄일 수 있습니다.

하루 한 시간만 선택한다

하루에 여러 번 발행 가능성이 열려 있으면 중복 방지 로직이 더 중요해집니다. 물론 frontmatter 날짜와 파일명을 검사하면 대부분 막을 수 있지만, 애초에 새 글을 만들 수 있는 시간을 하나로 줄이면 운영 표면이 작아집니다. 날짜 문자열을 시드로 삼아 14시부터 18시 사이에서 한 시간을 결정하면 매일 다른 시간대가 선택되면서도 같은 날 재시도 결과는 항상 같습니다. 이 방식은 무작위처럼 보이지만 재현 가능하다는 장점이 있습니다.

날짜는 frontmatter와 파일명으로 함께 본다

유지보수 창이 열려 있더라도 오늘 글이 이미 있으면 새 파일을 만들면 안 됩니다. Futory에서는 frontmatter의 date: "YYYY-MM-DD"와 파일명에 포함된 날짜를 함께 확인하는 편이 안전합니다. 대부분의 파일은 날짜가 아닌 slug로 저장되지만, 두 기준을 모두 보면 과거 형식의 파일이나 수동 작성 글도 놓칠 가능성이 줄어듭니다.

실행 전후에 남길 증거

유지보수 창은 시간 규칙만으로 끝나지 않습니다. 실제로 그 창 안에서 무엇을 했고 어디까지 검증했는지를 남겨야 다음 실행이 안전하게 이어집니다. 특히 자동화 보고서는 사람이 길게 읽지 않아도 판단할 수 있도록 selected hour, slug, 파일 경로, 테스트 상태, 빌드 상태, 공개 URL 상태를 같은 순서로 반복하는 것이 좋습니다.

변경 전 백업을 먼저 만든다

Markdown content tree는 블로그의 원천 데이터입니다. 새 파일 하나만 추가하더라도 쓰기 전에는 백업을 만드는 습관이 좋습니다. 백업은 문제가 생겼을 때 “무엇을 되돌릴 수 있는가”를 보장합니다. Futory에서는 /opt/data/futory-cron-posts-backup-YYYYMMDD-HHMMSS.tar.gz처럼 실행 시각이 들어간 압축 파일을 남기면 충분합니다. 중요한 것은 백업이 파일 생성보다 먼저 완료되어야 한다는 점입니다.

공개 검증은 캐시를 우회한다

빌드와 재시작이 성공해도 공개 사이트에서 오래된 응답을 보면 발행이 실패한 것처럼 보일 수 있습니다. 그래서 상세 URL과 목록 페이지를 확인할 때는 cache-busting query string과 Cache-Control: no-cache 헤더를 함께 쓰는 것이 좋습니다. 상세 페이지가 200을 반환하고, 홈이나 글 목록에 오늘 날짜 또는 slug가 보이면 독자가 새 글을 찾을 수 있는 상태로 볼 수 있습니다.

자주 묻는 질문

유지보수 창이 있으면 발행이 너무 늦어지지 않나요?

창을 하루 한 시간으로 제한해도 평일 발행에는 충분합니다. 오히려 실행 시간을 좁히면 실패 보고를 확인하기 쉽고, 중복 재시도 가능성이 줄어듭니다. 긴급 수정이 필요할 때는 별도 수동 배포 절차를 쓰고, 반복 발행 자동화는 정해진 창을 지키는 편이 안정적입니다.

선택 시간이 랜덤이면 운영자가 예측하기 어렵지 않나요?

완전한 랜덤이 아니라 날짜 기반 결정이면 예측 가능합니다. 같은 날짜에는 항상 같은 시간이 나오므로 재시도해도 결과가 바뀌지 않습니다. 운영자는 보고서의 selected hour를 보면 왜 이번 실행이 SKIP되었는지, 또는 왜 발행을 진행했는지 바로 알 수 있습니다.

빌드는 성공했는데 공개 목록에 늦게 보이면 다시 글을 만들어야 하나요?

아닙니다. 오늘 날짜 파일과 상세 URL이 이미 기준점입니다. 목록 반영만 지연된다면 새 글을 만들지 말고 PM2 상태, 캐시, 목록 생성 규칙을 확인해야 합니다. 중복 콘텐츠를 만드는 재시도는 유지보수 창의 목적과 반대입니다.

결론

AI 블로그 자동화에서 유지보수 창은 발행 속도를 늦추는 장치가 아니라 반복 운영을 조용하게 만드는 안전장치입니다. Futory의 Next.js Markdown 흐름에서는 KST 평일, 하루 한 선택 시간, 중복 검사, 백업, 테스트, 빌드, PM2 재시작, 공개 검증을 같은 순서로 묶을 때 자동화가 예측 가능한 리듬을 갖게 됩니다.

바이브코딩은 빠르게 만들고 고치는 방식이지만, 공개 서비스에서는 빠른 실행을 언제 허용할지도 설계해야 합니다. 유지보수 창을 기준으로 쓰면 자동화는 필요한 시간에만 변경을 수행하고, 나머지 실행은 안전하게 SKIP하며, 성공과 실패 모두 재현 가능한 증거로 남길 수 있습니다.