AI 블로그 자동화에서 롤백 경계를 정하는 법

요약

Futory처럼 평일마다 AI가 Markdown 글을 만들고 테스트, 빌드, PM2 재시작, 공개 검증까지 이어 가는 블로그에서는 “문제가 생기면 어디까지 되돌릴 것인가”를 미리 정해 두는 것이 중요합니다. 자동화는 빠르게 움직이지만, 빠르게 움직인 만큼 실패 지점을 흐릿하게 만들 수도 있습니다. 새 파일을 쓴 직후의 문제와 빌드가 끝난 뒤의 문제, 그리고 PM2 재시작 이후 공개 사이트에서 발견된 문제는 같은 롤백으로 처리하면 안 됩니다.

롤백 경계는 되돌리기 시작하는 기준선입니다. Futory의 Next.js Markdown 운영에서는 백업 전, 파일 작성 후, 콘텐츠 테스트 후, 빌드 후, 런타임 재시작 후가 각각 다른 경계가 됩니다. 이 경계를 명확히 두면 바이브코딩 방식으로 빠르게 글을 만들면서도, 실패했을 때 기존 공개 사이트를 불필요하게 흔들지 않고 복구할 수 있습니다.

롤백 경계가 필요한 이유

자동 발행은 겉으로는 새 글 하나를 추가하는 작업입니다. 하지만 실제로는 content tree를 변경하고, 정적 빌드 산출물을 만들고, 실행 중인 프로세스를 재시작하며, 공개 목록에 반영되는지 확인하는 운영 작업입니다. 어느 단계에서 실패했는지에 따라 되돌릴 대상이 달라집니다. 이 차이를 무시하면 이미 안전한 단계까지 되돌리거나, 반대로 문제가 남은 상태로 성공처럼 보고할 수 있습니다.

모든 실패가 파일 삭제를 뜻하지는 않는다

예를 들어 npm run test:content가 frontmatter 오류로 실패했다면 새 Markdown 파일을 고치는 것이 맞습니다. 하지만 빌드까지 성공했고 공개 목록만 늦게 보이는 상황이라면 파일을 삭제하거나 새 글을 다시 만들 필요가 없습니다. 이때는 PM2 반영, 캐시, 목록 페이지 생성 규칙을 확인해야 합니다. 롤백 경계가 없으면 운영자는 “문제가 있으니 오늘 글을 지우자”처럼 너무 큰 조치를 선택하기 쉽습니다.

자동화는 복구 기준을 스스로 설명해야 한다

사람이 직접 배포할 때는 화면과 로그를 보며 감으로 판단할 수 있습니다. 하지만 크론 기반 발행은 보고서 한 장으로 다음 행동을 결정해야 합니다. 그래서 보고에는 백업 경로, 새 파일 경로, 테스트 상태, 빌드 상태, 재시작 상태, 공개 URL 상태가 함께 남아야 합니다. 이 정보가 있어야 다음 실행에서 같은 글을 중복 생성하지 않고, 필요한 경계부터만 다시 검증할 수 있습니다.

Futory에 맞는 단계별 경계

Futory의 글은 /opt/futory/content/posts 아래 Markdown 파일로 관리됩니다. 이 구조에서는 새 파일 하나가 콘텐츠의 원천이고, .next 빌드 산출물은 공개 런타임으로 넘어가기 전의 결과입니다. 따라서 롤백도 원천 파일과 빌드 산출물, 실행 프로세스를 분리해 생각해야 합니다.

파일 작성 전: 백업 경계

가장 중요한 첫 경계는 백업입니다. 새 글을 쓰기 전에 content/posts 전체를 타임스탬프가 있는 압축 파일로 보관하면, 이후 어떤 단계에서 실패하더라도 원천 데이터로 돌아갈 기준이 생깁니다. 백업은 “실패했을 때 반드시 되돌린다”는 의미가 아니라 “되돌릴 수 있다”는 보증입니다. 운영 자동화에서는 이 차이가 큽니다. 복구 가능성이 확보되어야 이후 단계도 자신 있게 진행할 수 있습니다.

파일 작성 후: 원천 콘텐츠 경계

새 Markdown 파일이 만들어진 뒤에는 가장 먼저 오늘 날짜 중복과 frontmatter 형식을 확인해야 합니다. 이 단계에서 문제가 발견되면 기존 글을 건드리지 않고 새 파일만 수정하거나 제거하면 됩니다. 아직 빌드나 PM2 재시작이 일어나지 않았기 때문에 공개 사이트에는 영향이 없습니다. 따라서 이 경계의 롤백은 작고 안전합니다.

빌드 후: 산출물 경계

테스트를 통과하고 npm run build까지 성공하면 문제의 성격이 바뀝니다. 이제 새 글은 코드와 테마 규칙을 통과했고, .next 안에 라우트나 데이터로 포함되었는지 확인해야 합니다. 빌드 산출물에서 slug가 보이지 않는다면 파일은 존재하지만 공개 경로 계약이 어긋난 상태일 수 있습니다. 이때는 PM2를 재시작하기 전에 멈추는 것이 맞습니다. 런타임에 반영하지 않았으므로 공개 사이트는 여전히 이전 상태를 유지할 가능성이 높습니다.

재시작 후: 공개 검증 경계

PM2 재시작이 끝난 뒤에는 이미 런타임에 새 빌드가 반영된 단계입니다. 이때 상세 URL이 200을 반환하지 않거나 목록에서 slug가 보이지 않으면 단순 파일 롤백보다 공개 검증을 먼저 반복해야 합니다. 캐시 우회 요청, 홈과 글 목록 확인, 날짜 노출 확인을 통해 실제 문제인지 지연인지 구분합니다. 필요하다면 이전 백업으로 돌아갈 수 있지만, 먼저 증거를 모아야 불필요한 되돌리기를 줄일 수 있습니다.

보고서에 남길 롤백 단서

롤백 경계는 문서에만 있으면 부족합니다. 매 실행 보고서가 다음 조치를 가능하게 만들어야 합니다. 특히 자동 발행에서는 성공 보고도 복구 단서가 됩니다. 성공한 날의 파일 경로와 공개 URL이 남아 있으면, 다음 날 중복 검사나 장애 분석에서 기준점으로 쓸 수 있습니다.

경로와 상태를 짧게 남긴다

보고서에는 새 파일 경로, 백업 파일 경로, slug, 테스트 결과, 빌드 결과, PM2 재시작 결과, 공개 검증 결과가 들어가야 합니다. 긴 로그 전체보다 각 단계의 상태가 중요합니다. 실패한 경우에는 첫 실패 단계의 명령과 오류를 남기고, 그 뒤 단계는 실행하지 않았다고 표시하는 편이 좋습니다. 그러면 운영자는 복구를 시작할 경계를 바로 알 수 있습니다.

중복 방지는 롤백보다 먼저다

롤백을 잘 설계해도 같은 날짜 글을 두 번 만들면 운영이 복잡해집니다. 그래서 Futory 자동화는 오늘 날짜가 frontmatter나 파일명에 이미 있으면 새 글을 만들지 않아야 합니다. 기존 파일이 있다면 그 파일이 오늘의 기준점이며, 필요한 작업은 새 글 생성이 아니라 공개 상태 확인이나 빌드 반영 확인입니다. 롤백 경계는 중복 생성을 막는 규칙과 함께 있을 때 가장 안전합니다.

자주 묻는 질문

실패하면 항상 백업으로 되돌려야 하나요?

아닙니다. 백업은 되돌릴 수 있는 안전망이지, 모든 실패의 기본 행동은 아닙니다. 콘텐츠 테스트에서 오타나 frontmatter 문제가 나오면 새 파일만 수정하면 됩니다. 빌드 실패도 원인을 확인해 고칠 수 있다면 전체 복원이 필요하지 않습니다. 백업 복원은 원천 파일 상태가 불명확해졌거나, 여러 변경이 섞여 정확한 수정이 어려울 때 선택하는 마지막 수단에 가깝습니다.

PM2 재시작 후 문제가 생기면 어떻게 하나요?

먼저 상세 URL과 목록 페이지를 캐시 우회로 다시 확인합니다. 상세 페이지가 정상인데 목록만 늦으면 캐시나 목록 생성 지연일 수 있습니다. 상세 페이지도 실패한다면 빌드 산출물에 slug가 포함되었는지, 재시작 명령이 실제 앱에 적용되었는지 확인합니다. 이 단계에서도 새 글을 다시 만들면 안 됩니다. 이미 오늘의 원천 파일은 존재하므로 재시작과 공개 검증 경계에서 문제를 좁혀야 합니다.

롤백 경계를 너무 세분화하면 운영이 느려지지 않나요?

오히려 빨라집니다. 경계가 없으면 실패할 때마다 전체 흐름을 다시 의심해야 하지만, 경계가 있으면 마지막으로 통과한 지점부터 보면 됩니다. 바이브코딩은 빠른 실험을 장점으로 삼지만, 반복 운영에서는 빠른 복구 기준도 함께 있어야 합니다. 작은 경계는 자동화를 느리게 만드는 규칙이 아니라, 다음 판단을 빠르게 만드는 메모입니다.

결론

AI 블로그 자동화에서 롤백 경계는 장애가 났을 때만 필요한 비상 절차가 아닙니다. 새 글을 쓰기 전 백업하고, 파일 작성과 테스트, 빌드, 산출물 확인, PM2 재시작, 공개 검증을 각각 다른 경계로 보는 습관은 매일의 발행을 더 안전하게 만듭니다. Futory의 Next.js Markdown 구조에서는 원천 파일과 빌드 산출물, 런타임 반영을 분리해 보아야 불필요한 복원과 중복 생성을 피할 수 있습니다.

바이브코딩은 빠르게 만들고 검증하는 방식이지만, 공개 블로그에서는 빠르게 되돌릴 수 있는 기준도 품질의 일부입니다. 오늘 무엇을 썼는지, 어디까지 통과했는지, 문제가 생기면 어느 경계부터 확인할지를 보고서에 남기면 자동화는 더 조용하고 예측 가능한 운영 도구가 됩니다.