2026-06-04 · 바이브코딩

AI 블로그 자동화에서 재시도까지 견디는 발행 런북 만들기

Futory의 Next.js Markdown 블로그를 기준으로 크론 재실행, 부분 실패, PM2 재시작, 공개 검증까지 안전하게 다루는 일일 발행 런북을 정리했습니다.

요약

AI 블로그 자동화는 한 번 성공하는 스크립트보다 여러 번 실행돼도 같은 결과를 유지하는 런북이 더 중요합니다. Futory처럼 content/posts/*.md에 글을 추가하고, 콘텐츠 검증과 Next.js 빌드, PM2 재시작, 공개 URL 확인을 거치는 구조에서는 크론이 재시도되거나 중간 단계에서 멈춰도 운영자가 상태를 쉽게 이해할 수 있어야 합니다.

이 글은 Futory의 일일 발행 흐름을 기준으로 재시도에 강한 런북을 만드는 방법을 정리합니다. 핵심은 날짜 중복 검사를 맨 앞에 두고, 백업 후 새 파일 하나만 만들며, 실패하면 다음 단계로 넘어가지 않고, 성공 여부를 공개 페이지에서 다시 확인하는 것입니다. 바이브코딩은 빠르게 만들 수 있다는 장점이 있지만, 운영 자동화에서는 빠른 생성보다 안전한 반복성이 먼저입니다.

재시도를 전제로 설계해야 하는 이유

크론 자동화는 사람이 지켜보는 수동 배포와 다릅니다. 네트워크가 잠깐 끊길 수 있고, 빌드 시간이 길어질 수 있으며, 공개 서버가 캐시된 응답을 돌려줄 수도 있습니다. 이런 상황에서 “한 번 실행하면 끝난다”는 방식으로 설계하면 같은 날짜 글이 두 개 생기거나, 파일은 추가됐지만 PM2가 재시작되지 않은 상태로 남을 수 있습니다.

재시도에 강한 런북은 각 단계가 다시 실행됐을 때 어떤 판단을 해야 하는지 명확합니다. 오늘 날짜 글이 이미 있으면 새 글을 만들지 않습니다. 빌드가 실패하면 PM2를 건드리지 않습니다. 공개 URL이 200이 아니면 성공이라고 말하지 않습니다. 이처럼 작은 규칙을 고정하면 자동화는 더 예측 가능해집니다.

Futory 발행 런북의 기본 순서

1. KST 날짜와 선택된 시간을 먼저 확인한다

Futory의 평일 발행 루틴은 Asia/Seoul 기준 날짜를 사용합니다. UTC가 아니라 KST를 기준으로 해야 사용자가 보는 날짜와 frontmatter의 date가 일치합니다. 또한 14시부터 18시 사이에서 하루에 하나의 선택된 시간을 정해 실행하면, 크론이 여러 번 호출돼도 발행 시점이 안정적으로 분산됩니다.

이 단계에서 오늘이 주말이거나 선택된 시간이 아니라면 아무 파일도 만들지 않아야 합니다. 스킵도 중요한 운영 결과입니다. 스킵 로그에는 현재 KST 시간과 선택된 시간을 함께 남기면 다음에 왜 발행되지 않았는지 바로 알 수 있습니다.

2. 오늘 날짜 중복을 가장 먼저 막는다

새 글을 쓰기 전에는 /opt/futory/content/posts 안의 파일명과 frontmatter를 모두 확인해야 합니다. 파일명에 날짜가 없어도 frontmatter에 date: "2026-06-04"가 있다면 이미 오늘 글이 있는 것입니다. 이 경우에는 새 주제를 떠올리거나 기존 글을 수정하지 않고 멈추는 편이 안전합니다.

중복 방지는 재시도의 핵심입니다. 예를 들어 글 생성 후 빌드 단계에서 실패했다면 다음 크론 실행은 오늘 날짜 글을 발견하고 새 파일을 또 만들지 않습니다. 운영자는 기존 파일을 기준으로 문제를 고치면 되고, 같은 날짜의 여러 글을 정리하는 추가 작업을 피할 수 있습니다.

3. 백업 후 새 파일 하나만 추가한다

라이브 Markdown 콘텐츠 트리에 쓰기 전에는 백업이 필요합니다. 백업은 복잡한 절차가 아니라 content/posts 전체를 시간 이름이 들어간 압축 파일로 보관하는 정도면 충분합니다. 중요한 것은 파일을 쓰기 전에 복구 가능한 지점을 만드는 것입니다.

새 글을 만들 때는 기존 글을 수정하지 않는 원칙도 지켜야 합니다. 오늘의 작업 범위가 새 Markdown 파일 하나라면 문제가 생겨도 롤백과 원인 분석이 단순합니다. 기존 글의 제목, 태그, 설명을 같이 고치기 시작하면 빌드 실패나 공개 목록 변화의 원인을 나누기 어려워집니다.

실패 단계마다 멈추는 기준

콘텐츠 검증 실패

npm run test:content가 실패하면 frontmatter, 필수 섹션, Markdown 문법 중 하나가 프로젝트 규칙과 맞지 않는다는 뜻입니다. 이때는 빌드나 PM2 재시작으로 넘어가면 안 됩니다. 공개 서버를 건드리지 않고 오류 메시지를 그대로 남기는 것이 가장 안전합니다.

테마 검증 실패

npm run test:theme는 새 글이 목록 카드나 카테고리 화면에서 문제를 만들지 않는지 확인하는 단계입니다. 콘텐츠는 정상이어도 테마 규칙에서 실패할 수 있으므로 별도 단계로 기록해야 합니다. 실패하면 마찬가지로 빌드와 재시작을 중단합니다.

빌드 실패

npm run build가 실패하면 새 글은 아직 공개 가능한 상태가 아닙니다. 이때 PM2를 재시작하면 실행 중인 서비스가 불안정해질 수 있습니다. 빌드 실패 로그, 새 파일 경로, 백업 경로를 보고서에 남기고 멈추는 것이 런북의 올바른 행동입니다.

공개 검증을 성공의 마지막 기준으로 둔다

빌드가 성공해도 공개 성공은 아닙니다. Futory에서는 빌드 후 .next 산출물에 새 slug가 포함됐는지 확인하고, SSH로 호스트의 futory-wordblog PM2 앱을 재시작한 뒤 공개 사이트를 다시 읽어야 합니다. 상세 페이지 /posts/<slug>가 200으로 응답하고, 홈과 /posts, /vibe-coding 목록에 오늘 날짜나 slug가 보여야 독자가 실제로 새 글을 발견할 수 있습니다.

캐시 확인도 런북에 포함해야 합니다. 검증 요청에는 cache-busting query string과 Cache-Control: no-cache 헤더를 붙이면 오래된 브라우저 캐시나 중간 캐시 때문에 생기는 착시를 줄일 수 있습니다. 자동화 보고서는 “빌드 성공”이 아니라 “상세 200, 목록 3곳 포함 확인”처럼 증거 중심으로 남겨야 합니다.

운영 로그에 남길 항목

재시도에 강한 런북은 사람이 나중에 읽을 수 있는 로그를 남깁니다. 최소 항목은 다음과 같습니다.

  • KST 날짜와 현재 시간, 선택된 발행 시간
  • 생성한 slug와 파일 경로
  • 백업 파일 경로
  • test:content, test:theme, build 결과
  • .next 산출물에서 slug 확인 결과
  • PM2 재시작 명령의 성공 여부
  • 공개 상세 URL 상태 코드
  • 홈, 전체 글 목록, 카테고리 목록의 포함 여부

이 항목들이 있으면 실패가 발생해도 다음 조치가 분명합니다. 파일 생성 전 실패인지, 검증 실패인지, 빌드 실패인지, 재시작 실패인지, 공개 검증 실패인지 바로 나눌 수 있습니다.

자주 묻는 질문

재시도 때 기존 파일을 이어서 수정해도 되나요?

자동 발행 런북에서는 새 파일이 이미 있으면 중복 생성을 막고 멈추는 편이 안전합니다. 이어서 수정이 필요하다면 별도 수동 정정 작업으로 다루는 것이 좋습니다. 그래야 자동화가 글의 내용을 예기치 않게 바꾸는 일을 막을 수 있습니다.

빌드가 성공했는데 목록에 글이 안 보이면 어떻게 하나요?

먼저 PM2 재시작이 실제로 성공했는지 확인해야 합니다. 그다음 cache-busting 쿼리와 no-cache 헤더로 홈, /posts, /vibe-coding을 다시 확인합니다. 상세 페이지는 200인데 목록에만 없다면 frontmatter의 날짜, 카테고리, 정렬 로직을 의심할 수 있습니다.

백업은 매번 꼭 필요한가요?

라이브 콘텐츠 트리에 쓰는 자동화라면 매번 필요합니다. 백업이 있으면 새 파일 하나를 추가하는 작은 작업이라도 복구 기준이 명확해집니다. 특히 크론은 사용자가 곧바로 지켜보지 않을 수 있으므로, 백업은 자동화의 기본 안전장치입니다.

결론

AI 블로그 자동화의 실력은 글을 빠르게 만드는 능력만으로 판단할 수 없습니다. 같은 크론이 여러 번 실행돼도 중복을 만들지 않고, 실패 단계에서는 멈추며, 성공했다고 말하기 전에 공개 페이지까지 확인하는 운영 런북이 있어야 합니다. Futory의 Next.js Markdown 구조에서는 KST 날짜 확인, 중복 방지, 백업, 새 파일 추가, 콘텐츠 검증, 테마 검증, 빌드, 산출물 확인, PM2 재시작, 공개 검증을 하나의 고정된 순서로 묶는 것이 가장 실용적입니다.

바이브코딩은 빠른 실험을 가능하게 하지만, 매일 발행되는 블로그에서는 실험과 운영을 분리해야 합니다. 생성은 유연하게 하되 발행 규칙은 단단하게 유지할 때, AI는 단순 작성 도구를 넘어 안정적인 블로그 운영 동료가 됩니다.