AI 블로그 자동화에서 재시도 경계를 정하는 법

요약

Futory처럼 평일마다 AI가 Next.js Markdown 글을 만들고 테스트, 빌드, PM2 재시작, 공개 URL 확인까지 이어지는 블로그에서는 실패 자체보다 실패 후 재시도 방식이 더 중요합니다. 자동화는 빠르게 다시 실행할 수 있지만, 기준 없이 재시도하면 같은 날짜 글이 두 개 생기거나, 빌드에 실패한 상태에서 런타임을 다시 시작하거나, 공개 캐시가 늦게 풀린 것을 새 오류로 오해할 수 있습니다.

재시도 경계란 “어디까지는 다시 해도 안전하고, 어디부터는 멈춰야 하는가”를 단계별로 정한 운영선입니다. Futory의 경우 날짜 중복 검사, posts 백업, 새 Markdown 파일 작성, 콘텐츠 테스트, 테마 테스트, 빌드, .next 산출물 확인, PM2 재시작, 공개 상세 및 목록 검증이 각각 다른 경계를 가집니다. 이 글은 하루 한 편 발행 루틴에서 재시도를 안전하게 다루는 방법을 정리합니다.

왜 재시도 경계가 필요한가

자동 발행 크론은 사람의 눈앞에서 실행되지 않습니다. 실패 보고를 받았을 때 운영자는 이미 몇 분 또는 몇 시간이 지난 상태에서 로그를 읽습니다. 이때 “다시 돌리면 되겠지”라는 판단이 가장 위험할 수 있습니다. 특히 Markdown 기반 블로그는 파일 하나가 곧 콘텐츠 원본이므로, 같은 날짜의 파일이 중복되면 목록 정렬과 사이트맵, 검색 노출까지 흔들릴 수 있습니다.

같은 실패도 단계에 따라 의미가 다르다

npm run test:content가 실패한 상황과 PM2 재시작 후 공개 페이지가 늦게 갱신되는 상황은 같은 실패가 아닙니다. 전자는 새 글의 형식이나 내용 계약을 확인해야 하고, 후자는 빌드 산출물과 런타임 반영, 캐시 계층을 나누어 보아야 합니다. 그런데 두 경우 모두 단순히 “발행 실패”라고만 남기면 다음 실행이 무엇을 건드려야 하는지 알 수 없습니다.

재시도는 중복 방지에서 시작한다

Futory의 첫 번째 경계는 오늘 KST 날짜입니다. 재시도든 정상 실행이든 새 글을 만들기 전에 frontmatter와 파일명에서 오늘 날짜가 이미 있는지 확인해야 합니다. 이미 오늘 날짜 글이 있다면 그 글이 완전히 공개되지 않았더라도 새 파일을 만들면 안 됩니다. 이때 필요한 작업은 새 글 작성이 아니라 기존 파일을 기준으로 테스트, 빌드, 재시작, 공개 검증 중 어느 단계가 남았는지 판단하는 것입니다.

Futory 발행 단계별 재시도 원칙

1. 백업 전에는 아무것도 쓰지 않는다

백업은 단순한 보험이 아니라 재시도 경계의 시작점입니다. /opt/data/futory-cron-posts-backup-YYYYMMDD-HHMMSS.tar.gz 형태로 content/posts를 먼저 묶어 두면, 이후 새 파일 작성이나 검증 실패가 발생해도 어느 시점으로 돌아갈 수 있는지 분명합니다. 백업이 만들어지지 않았다면 새 Markdown 파일을 쓰지 않는 것이 안전합니다.

2. 새 파일 작성은 하루 한 번만 허용한다

새 글 파일은 정확히 하나만 추가해야 합니다. 같은 날짜의 frontmatter가 이미 보이면 재시도 실행은 SKIP으로 끝나야 합니다. 이 원칙은 자동화가 조금 보수적으로 보이더라도 중요합니다. 발행이 반쯤 진행된 상태에서 같은 주제의 두 번째 글을 만들면 테스트는 통과할 수 있지만 운영 기록은 오히려 더 복잡해집니다.

3. 테스트 실패 후에는 런타임을 건드리지 않는다

콘텐츠 테스트나 테마 테스트가 실패했다면 PM2 재시작은 금지입니다. 아직 서비스에 올릴 수 있는 빌드 입력이 아니기 때문입니다. 보고서에는 실패한 명령과 첫 번째 조치 가능한 오류를 그대로 남기고 멈추는 편이 좋습니다. 자동화가 이 경계를 지키면 운영자는 안심하고 실패 로그를 읽을 수 있습니다.

4. 빌드 성공과 산출물 확인을 분리한다

npm run build가 성공해도 새 slug가 .next 산출물에 포함되었는지 확인해야 합니다. 빌드는 성공했지만 새 글이 라우팅 입력에서 누락되었다면 PM2를 재시작해도 공개 사이트는 바뀌지 않습니다. 반대로 산출물에서 slug가 확인되면 파일 작성과 빌드 반영은 통과한 것이므로 이후 문제는 런타임 재시작이나 공개 캐시 쪽으로 좁힐 수 있습니다.

공개 검증에서의 재시도 판단

PM2 재시작이 성공한 뒤에도 공개 상세 URL과 목록 페이지를 따로 확인해야 합니다. 상세 URL /posts/<slug>가 200을 반환하면 글 페이지 자체는 접근 가능한 것입니다. 하지만 홈, /posts, /vibe-coding 목록에 오늘 날짜나 slug가 보이지 않는다면 목록 생성, 캐시, 또는 배포 반영 타이밍을 의심해야 합니다.

cache-busting은 재시도의 기본 예의다

공개 검증에는 쿼리 문자열과 Cache-Control: no-cache 헤더를 붙이는 것이 좋습니다. 캐시된 HTML을 보고 실패라고 판단하면 불필요한 재시작을 반복할 수 있습니다. Futory 같은 작은 블로그에서도 브라우저, 프록시, Next.js 런타임 사이에 응답이 잠깐 엇갈릴 수 있으므로, 검증 요청 자체를 매번 새롭게 만드는 습관이 필요합니다.

보고서는 다음 실행의 입력이다

재시도 경계가 잘 작동하려면 보고서가 짧지만 충분해야 합니다. 선택된 KST 시간, 중복 검사 결과, 백업 경로, 새 파일 경로, 테스트와 빌드 상태, 산출물 slug 확인, PM2 재시작 결과, 공개 URL 상태를 남기면 다음 자동화나 사람이 같은 실수를 반복하지 않습니다. 특히 실패한 경우에는 “무엇을 하지 않았는지”도 중요합니다. 예를 들어 빌드 실패 후 PM2 재시작을 하지 않았다고 명시하면 운영 판단이 훨씬 쉬워집니다.

실무 체크리스트

1. KST 기준 오늘이 평일인지 확인한다.

2. 결정된 발행 시간인지 확인한다.

3. 오늘 날짜의 frontmatter 또는 파일명이 있는지 확인한다.

4. posts 디렉터리를 먼저 백업한다.

5. 새 Markdown 파일 하나만 추가한다.

6. 콘텐츠 테스트, 테마 테스트, 빌드를 순서대로 실행한다.

7. .next 산출물에서 새 slug를 찾는다.

8. PM2를 재시작하고 공개 상세 URL과 목록 페이지를 no-cache로 확인한다.

9. 실패 시 다음 단계로 넘어가지 않고 경계 안에서 멈춘다.

이 목록은 복잡해 보이지만 실제로는 자동 발행이 이미 수행하는 동작을 순서대로 고정한 것입니다. 핵심은 성공 경로를 빠르게 만드는 것이 아니라 실패 경로를 안전하게 만드는 데 있습니다.

자주 묻는 질문

재시도할 때 기존 오늘 글을 삭제하고 새로 만들면 안 되나요?

정기 발행 크론에서는 권장하지 않습니다. 오늘 날짜 글이 이미 있다면 중복 방지 계약을 통과한 상태이므로, 새 글 생성이 아니라 기존 파일을 기준으로 남은 검증 단계를 확인해야 합니다. 삭제와 재작성은 별도 수동 복구 작업으로 분리하는 편이 안전합니다.

PM2 재시작만 실패했다면 글 파일을 다시 만들어야 하나요?

아니요. 파일 작성, 테스트, 빌드, 산출물 확인이 끝난 뒤 PM2 재시작만 실패했다면 콘텐츠 원본은 이미 준비된 상태입니다. 이때는 SSH 명령, PM2 앱 이름, 호스트 접근 권한을 확인해야 하며 새 Markdown 파일을 만들면 안 됩니다.

공개 목록에는 안 보이지만 상세 URL은 200이면 성공인가요?

부분 성공으로 보는 것이 좋습니다. 상세 URL이 200이면 글 페이지는 접근 가능하지만, 홈이나 카테고리 목록에서 독자가 발견하지 못할 수 있습니다. 보고서에는 상세와 목록 검증을 나누어 적고, 목록 반영이 늦는지 캐시 문제인지 확인해야 합니다.

결론

AI 블로그 자동화의 품질은 글을 생성하는 능력만으로 결정되지 않습니다. 실패했을 때 어디서 멈추고, 무엇을 다시 하지 않으며, 어떤 증거를 남기는지가 운영 신뢰를 만듭니다. Futory의 재시도 경계는 단순합니다. 오늘 날짜 중복을 먼저 막고, 백업 없이 쓰지 않으며, 테스트나 빌드 실패 후에는 PM2를 건드리지 않고, 공개 검증은 상세와 목록을 분리해서 확인하는 것입니다.

이 경계를 지키면 평일 자동 발행은 더 차분해집니다. 성공한 날에는 짧은 운영 로그가 남고, 실패한 날에는 다음 조치가 분명해집니다. 결국 좋은 바이브코딩 운영은 빠른 실행과 신중한 경계를 함께 갖는 일입니다.