AI 블로그 자동화에서 공개 실패 후 롤백 기준 세우기

요약

AI 블로그 자동화에서 중요한 것은 글을 매일 만드는 능력만이 아닙니다. 자동화가 실패했을 때 어떤 상태를 안전하다고 보고, 어떤 상태에서는 롤백해야 하며, 어떤 상태에서는 재시도만 하면 되는지 판단하는 기준이 필요합니다. Futory처럼 content/posts/*.md에 Markdown 파일을 추가하고, 콘텐츠 검증과 테마 검증, Next.js 빌드, PM2 재시작, 공개 URL 확인을 거치는 구조에서는 실패 위치에 따라 대응이 달라져야 합니다.

이 글은 Futory의 일일 발행 흐름을 기준으로 공개 실패 후의 롤백 기준을 정리합니다. 핵심은 “무조건 되돌리기”가 아니라 “아직 공개되지 않은 실패인지, 공개 서버가 일부만 갱신된 실패인지, 공개는 됐지만 목록 검증이 부족한 상태인지”를 나누는 것입니다. 바이브코딩으로 빠르게 운영 자동화를 만들수록 이런 판단표가 있어야 재시도와 복구가 안정적으로 반복됩니다.

실패 위치를 먼저 분류한다

자동 발행 실패를 다룰 때 가장 흔한 실수는 결과만 보고 바로 파일을 지우거나 프로세스를 재시작하는 것입니다. 하지만 Futory의 발행 흐름은 여러 단계로 나뉘어 있으므로, 실패가 발생한 위치를 먼저 확인해야 합니다.

파일 생성 전 실패

오늘 날짜 계산, 선택된 발행 시간 확인, 기존 글 중복 검사에서 멈췄다면 콘텐츠 트리는 바뀌지 않았습니다. 이 경우에는 롤백할 대상이 없습니다. 보고서에는 KST 현재 시간, 선택된 시간, 스킵 이유만 남기면 충분합니다. 자동화가 아무것도 쓰지 않았다는 사실도 중요한 검증 결과입니다.

파일 생성 후 검증 실패

새 Markdown 파일을 만든 뒤 npm run test:content나 npm run test:theme에서 실패했다면 아직 공개 서버를 건드리기 전입니다. 이 단계에서는 PM2를 재시작하지 않아야 하며, 공개 URL 검증도 성공으로 말하면 안 됩니다. 운영자는 새 파일의 frontmatter, 필수 섹션, 태그 배열, 제목 길이 같은 규칙을 확인하면 됩니다.

이때 롤백은 선택 사항입니다. 같은 날짜 글이 이미 생겼기 때문에 다음 크론은 중복 방지 규칙에 따라 새 파일을 만들지 않고 멈춥니다. 따라서 운영자가 고쳐서 다시 빌드할 계획이라면 파일을 남기는 편이 낫고, 잘못된 주제나 잘못된 날짜라면 백업에서 복구하거나 해당 파일만 제거하는 것이 좋습니다.

빌드 실패와 공개 실패는 다르게 본다

빌드 실패는 실행 프로세스를 건드리지 않는다

npm run build가 실패했다면 새 글은 아직 배포 가능한 산출물에 들어가지 않았습니다. 이 상태에서 PM2를 재시작하면 기존 서비스가 깨질 가능성은 낮더라도, 실패한 빌드를 기준으로 운영 판단이 흐려집니다. Futory 루틴에서는 빌드 실패 시 정확한 오류와 새 파일 경로, 백업 경로를 남기고 멈추는 것이 원칙입니다.

빌드 실패의 롤백 기준은 비교적 단순합니다. 오류가 Markdown 문법이나 frontmatter에서 왔다면 새 파일만 수정하면 됩니다. 의존성, Next.js 설정, 테마 코드에서 왔다면 오늘 글을 지우는 것보다 빌드 환경을 먼저 점검해야 합니다. 새 글 하나 때문에 전체 앱 빌드가 실패한 것인지, 기존 코드 상태가 이미 불안정한 것인지 구분해야 합니다.

PM2 재시작 실패는 파일을 되돌리기보다 운영 반영을 보류한다

빌드가 성공했지만 SSH나 PM2 재시작이 실패했다면 콘텐츠와 빌드 산출물은 준비됐지만 실행 중인 서비스가 최신 상태를 반영하지 못했을 가능성이 큽니다. 이때 새 Markdown 파일을 바로 삭제할 필요는 없습니다. 더 중요한 것은 PM2 재시작 명령, 종료 코드, stderr를 정확히 기록하는 것입니다.

이 상태에서는 공개 사이트가 이전 버전을 계속 보여줄 수 있습니다. 따라서 “글 작성 성공”과 “공개 반영 성공”을 분리해서 보고해야 합니다. 재시작 접근 권한이나 호스트 프로세스 상태를 고친 뒤 같은 빌드 산출물을 다시 반영하면 됩니다.

공개 검증 실패의 판단표

빌드와 PM2 재시작이 모두 성공했는데 공개 검증이 실패하는 경우도 있습니다. 이때는 상세 페이지와 목록 페이지를 나눠 봐야 합니다.

상세 URL이 404인 경우

/posts/<slug>가 404라면 라우팅 산출물에 새 글이 포함되지 않았거나, 실행 중인 프로세스가 이전 .next를 보고 있을 수 있습니다. 먼저 .next 내부에서 slug가 확인됐는지 다시 봅니다. 산출물에는 있는데 공개가 404라면 PM2가 다른 경로에서 실행 중인지, 재시작이 실제 앱에 적용됐는지 확인해야 합니다.

상세 URL은 200이지만 목록에 없는 경우

상세 페이지는 열리지만 /, /posts, /vibe-coding에 오늘 날짜나 slug가 보이지 않는다면 목록 생성 로직, 정렬 기준, 카테고리 필터, 캐시를 점검해야 합니다. 이 상태에서 글 파일을 지우는 것은 성급합니다. 독자가 직접 URL로 접근할 수는 있지만 발견 경로가 막힌 것이므로, 목록 페이지 검증을 실패로 보고 원인을 좁히는 편이 안전합니다.

캐시 때문에 오래된 화면이 보이는 경우

검증 요청에는 cache-busting query string과 Cache-Control: no-cache 헤더를 붙여야 합니다. 그래도 오래된 화면이 나온다면 브라우저 캐시가 아니라 서버, 프록시, 실행 프로세스 중 하나가 이전 산출물을 제공하고 있을 가능성이 있습니다. 공개 검증은 한 번의 느낌이 아니라 상태 코드와 본문 포함 여부로 판단해야 합니다.

롤백보다 재시도가 나은 경우

자동 발행에서 롤백은 강력한 도구지만 항상 첫 번째 선택은 아닙니다. 특히 새 글 파일이 정상이고 빌드까지 통과했다면, 문제는 대개 배포 반영이나 공개 검증 단계에 있습니다. 이때 파일을 되돌리면 이미 준비된 정상 콘텐츠까지 잃게 됩니다.

재시도가 나은 대표 상황은 다음과 같습니다.

• SSH 연결이 일시적으로 실패했다
• PM2 재시작 명령은 실패했지만 빌드는 성공했다
• 공개 목록이 캐시된 응답을 돌려줬다
• 상세 페이지는 200이고 목록 반영만 늦다
• 검증 스크립트의 네트워크 요청이 일시적으로 타임아웃됐다

반대로 롤백이 나은 상황은 날짜가 틀렸거나, 기존 글과 거의 같은 주제를 생성했거나, frontmatter 구조가 프로젝트 규칙과 맞지 않아 빠른 수정이 어렵거나, 빌드 실패 원인이 새 파일의 본문에 명확히 있는 경우입니다.

운영 로그에 남길 문장

Futory 같은 Markdown 블로그에서는 장애 대응 로그를 길게 쓰기보다 같은 형식으로 남기는 것이 좋습니다. 예를 들어 “파일 생성 완료, 콘텐츠 검증 실패, PM2 미실행”처럼 단계별 상태를 분리하면 다음 사람이 바로 이어서 볼 수 있습니다.

좋은 로그에는 다음 항목이 들어갑니다.

• KST 날짜와 선택된 발행 시간
• 새 slug와 파일 경로
• 백업 파일 경로
• 실패한 명령과 종료 코드
• PM2 재시작 실행 여부
• 공개 상세 URL 상태 코드
• 홈, 전체 글 목록, 카테고리 목록의 포함 여부
• 롤백이 필요한지, 재시도가 충분한지에 대한 판단

이 기록은 자동화가 사람을 대신해 결론을 내리는 것이 아니라, 사람이 빠르게 결정할 수 있는 근거를 정리하는 역할을 합니다.

자주 묻는 질문

실패하면 새 Markdown 파일을 바로 지워야 하나요?

항상 그렇지는 않습니다. 파일이 정상이고 검증이나 빌드도 통과했다면 삭제보다 재시작이나 공개 검증 재시도가 더 적절할 수 있습니다. 날짜나 주제가 틀린 경우처럼 콘텐츠 자체가 잘못됐을 때만 롤백을 우선 고려하는 편이 안전합니다.

PM2 재시작이 실패했는데 글은 발행된 것으로 봐도 되나요?

아닙니다. 파일과 빌드 산출물이 준비된 상태일 수는 있지만, 공개 사이트가 최신 내용을 보여준다는 보장은 없습니다. 상세 URL과 목록 페이지를 확인하기 전까지는 “작성 및 빌드 완료, 공개 반영 미확정”으로 기록해야 합니다.

공개 상세 페이지만 열리면 성공인가요?

Futory 운영 기준에서는 부족합니다. 상세 페이지가 200이어도 홈, /posts, /vibe-coding 목록에서 독자가 글을 발견할 수 있어야 발행 검증이 완료됩니다. 목록 검증까지 통과해야 최종 성공으로 보고하는 것이 좋습니다.

결론

AI 블로그 자동화에서 롤백 기준은 실패를 두려워해서 만드는 장치가 아니라, 실패가 생겨도 같은 방식으로 회복하기 위한 운영 계약입니다. Futory의 Next.js Markdown 구조에서는 파일 생성, 검증, 빌드, PM2 재시작, 공개 확인을 단계별로 나누고, 각 단계의 실패에 맞는 대응을 선택해야 합니다.

바이브코딩은 빠르게 만들고 개선하는 방식이지만, 공개 블로그 운영에서는 빠른 생성만큼 안전한 판단이 중요합니다. 새 파일이 문제인지, 빌드 산출물이 문제인지, 실행 프로세스가 문제인지, 공개 캐시가 문제인지 분리해서 보면 롤백과 재시도는 훨씬 단순해집니다. 매일 한 편씩 안정적으로 발행하려면 글쓰기 자동화와 함께 복구 기준도 자동화의 일부로 다뤄야 합니다.