AI 블로그 자동화에서 재시도 증거를 남기는 법

요약

Futory처럼 매일 정해진 시간대에 AI가 Markdown 글을 만들고, 테스트와 빌드, PM2 재시작, 공개 검증까지 이어 가는 블로그에서는 성공 보고만큼 실패 보고도 중요합니다. 자동화가 한 번에 끝나면 좋지만, 실제 운영에서는 콘텐츠 테스트, 테마 테스트, 빌드, 런타임 재시작, 공개 목록 반영 중 어느 한 단계가 일시적으로 흔들릴 수 있습니다. 이때 증거 없이 “실패했다”만 남기면 다음 실행은 같은 날짜 글을 다시 만들거나, 이미 빌드된 글을 놓치거나, 공개 사이트의 캐시를 실제 장애로 오해할 수 있습니다.

재시도 증거는 거창한 장애 보고서가 아닙니다. 오늘의 date, slug, 파일 경로, 마지막으로 통과한 단계, 실패한 명령, 공개 URL의 상태 코드처럼 다음 실행이 판단에 바로 쓸 수 있는 작은 기록입니다. 이 글은 Futory의 바이브코딩 운영에서 재시도를 안전하게 만들기 위해 어떤 증거를 남기고, 어떤 행동을 피해야 하는지 정리합니다.

재시도는 새 글 작성이 아니라 상태 이어가기다

반복 발행 자동화에서 가장 위험한 착각은 재시도를 “처음부터 다시 하기”로 보는 것입니다. 오늘 날짜 파일이 이미 만들어졌다면 다음 실행의 첫 번째 임무는 새 글을 만드는 것이 아니라 기존 파일을 기준으로 어디까지 진행됐는지 확인하는 일입니다. 그래서 Futory는 frontmatter의 date와 파일명 검색으로 오늘 글 존재 여부를 먼저 봅니다. 이 중복 방지 장치가 있어야 크론이 여러 시간대에 실행되어도 하루 한 편 원칙이 유지됩니다.

slug는 재시도의 기준점이다

재시도에서 기준점은 제목보다 slug가 더 실용적입니다. 제목은 사람이 읽기 좋지만, 명령과 URL에서는 slug가 쓰입니다. 예를 들어 ai-blog-retry-evidence-routine이라는 slug가 정해졌다면 파일은 content/posts/ai-blog-retry-evidence-routine.md, 공개 주소는 /posts/ai-blog-retry-evidence-routine, 빌드 산출물 검색어도 같은 문자열이 됩니다. 다음 실행이 이 문자열 하나로 파일, 빌드, 공개 페이지를 모두 확인할 수 있으면 복구 속도가 빨라집니다.

실패 단계는 마지막 통과 단계와 함께 적는다

“빌드 실패”라고만 남기는 것보다 “콘텐츠 테스트 통과, 테마 테스트 통과, 빌드 실패”라고 남기는 편이 훨씬 낫습니다. 이렇게 쓰면 다음 실행은 frontmatter나 섹션 구조를 의심하기보다 빌드 로그와 Next.js 설정을 먼저 봅니다. 반대로 콘텐츠 테스트가 실패했다면 PM2 재시작이나 공개 URL 검증은 아직 실행하지 않는 것이 맞습니다. 단계별 증거는 자동화가 불필요한 작업을 건너뛰고 정확한 지점부터 복구하게 만듭니다.

Futory에 맞는 증거 항목

Futory의 발행 보고서는 짧아도 재현 가능해야 합니다. 선택된 KST 시간, 생성 파일, 제목, 날짜, slug, 백업 경로, 테스트 결과, 빌드 결과, .next 포함 여부, PM2 재시작 결과, 공개 상세와 목록 검증 결과를 같은 순서로 남기면 좋습니다. 이 항목들은 사람이 읽는 보고서이면서 다음 크론 실행의 운영 힌트가 됩니다.

명령 실패는 원문을 보존한다

명령이 실패했을 때는 해석보다 원문이 먼저입니다. npm run build가 어떤 exit code로 끝났는지, SSH PM2 재시작 명령이 어떤 stderr를 냈는지, 공개 URL이 404인지 500인지가 복구 판단을 가릅니다. 특히 PM2 재시작 실패는 빌드 성공과 공개 성공 사이에 있는 문제이므로, 빌드가 통과했다고 해서 발행 완료로 보고하면 안 됩니다. 정확한 명령과 에러를 남기면 운영자는 접근 권한, 프로세스 이름, 배포 경로를 빠르게 좁힐 수 있습니다.

공개 검증은 상세와 목록을 나눠 남긴다

상세 페이지 /posts/<slug>가 200을 반환하는 것과 홈, /posts, /vibe-coding 목록에서 새 글이 보이는 것은 다른 신호입니다. 상세는 직접 접근 가능성을 보여 주고, 목록은 발견 가능성을 보여 줍니다. 재시도 증거에는 각 URL의 상태 코드와 slug 또는 오늘 날짜 포함 여부를 분리해 적어야 합니다. 상세는 성공했는데 목록만 실패했다면 캐시, 정렬, 목록 생성 문제로 좁힐 수 있고, 상세도 실패한다면 빌드 산출물과 런타임 반영을 다시 봐야 합니다.

재시도 때 피해야 할 행동

첫째, 같은 날짜로 새 Markdown 파일을 만들지 않습니다. 이미 오늘 날짜 frontmatter가 있다면 그 파일이 원천입니다. 둘째, 빌드 실패 상태에서 PM2를 재시작하지 않습니다. 실패한 빌드를 서비스 프로세스에 반영하려고 하면 공개 상태가 더 불명확해집니다. 셋째, 공개 사이트에 보이지 않는다는 이유만으로 콘텐츠를 수정하지 않습니다. 캐시나 프로세스 문제일 수 있으므로 파일 내용과 배포 상태를 분리해서 봐야 합니다.

백업은 재시도 판단의 안전망이다

새 파일을 만들기 전 content/posts를 백업해 두면 실패 후에도 변경 범위를 분명히 알 수 있습니다. 백업은 단순한 되돌리기 수단이 아니라 “오늘 자동화가 실제로 무엇을 바꿨는가”를 확인하는 기준입니다. 재시도에서 기존 파일을 유지할지, 이전 상태로 되돌릴지 판단하려면 이 기준점이 필요합니다.

자주 묻는 질문

실패했는데 다음 시간에 다시 실행되면 자동으로 고쳐지나요?

항상 그렇지는 않습니다. 일시적인 네트워크나 캐시 문제라면 다음 실행에서 통과할 수 있지만, 콘텐츠 형식 오류나 빌드 오류는 같은 파일을 기준으로 원인을 고쳐야 합니다. 그래서 실패 보고에는 어느 단계가 실패했는지와 어떤 파일이 기준인지가 반드시 필요합니다.

공개 상세 URL이 200이면 성공으로 봐도 되나요?

상세 URL 200은 중요한 성공 신호이지만 전체 성공은 아닙니다. 독자가 새 글을 발견하려면 홈, /posts, /vibe-coding 같은 목록에도 반영되어야 합니다. Futory 운영에서는 상세와 목록을 모두 확인한 뒤 공개 검증 완료로 보고하는 것이 안전합니다.

재시도 증거를 너무 많이 남기면 보고서가 길어지지 않나요?

보고서는 길 필요가 없습니다. 핵심은 같은 순서와 같은 이름을 반복하는 것입니다. 날짜, slug, 통과한 단계, 실패한 단계, 공개 URL 상태만 있어도 다음 실행이 훨씬 정확해집니다. 장황한 설명보다 재현 가능한 값이 더 중요합니다.

결론

AI 블로그 자동화의 품질은 성공한 날보다 흔들린 날에 드러납니다. Futory의 Next.js Markdown 운영에서 재시도 증거를 남기는 일은 중복 발행을 막고, 실패 범위를 줄이며, 다음 실행이 같은 기준으로 이어 달릴 수 있게 만드는 작은 습관입니다.

바이브코딩은 빠르게 만들고 빠르게 확인하는 방식이지만, 반복 운영에서는 빠른 재시도보다 정확한 재시도가 중요합니다. 오늘의 slug와 단계별 검증 결과를 짧게 남기면 자동화는 조용히 이어지고, 운영자는 새 글 작성과 배포 반영을 더 자신 있게 구분할 수 있습니다.