AI 블로그 자동화에서 posts 백업 복원 리허설을 하는 법

요약

Futory처럼 Next.js와 Markdown으로 운영되는 블로그 자동화에서는 새 글을 만들기 전에 content/posts를 백업하는 단계가 필수입니다. 하지만 백업 파일이 존재한다는 사실만으로는 충분하지 않습니다. 정말 중요한 질문은 “문제가 생겼을 때 이 백업으로 몇 분 안에 원래 상태로 돌아갈 수 있는가”입니다. 그래서 평일 발행 루틴에는 백업 생성뿐 아니라 복원 리허설 관점의 점검이 함께 필요합니다.

복원 리허설은 운영을 느리게 만드는 절차가 아닙니다. 오히려 자동화가 더 과감하게, 그러나 안전하게 새 Markdown 파일을 만들 수 있게 해 줍니다. 백업 경로, 아카이브 크기, 포함된 파일 수, 복원 대상의 범위가 명확하면 테스트 실패나 빌드 실패가 발생해도 당황하지 않습니다. Futory의 바이브코딩 루틴에서는 기존 글을 수정하지 않고 새 글 하나만 추가하는 원칙을 지키므로, 복원 전략도 단순하고 반복 가능하게 만들 수 있습니다.

왜 백업만으로는 부족한가

백업은 사고 이후에야 가치가 드러납니다. 그런데 사고가 난 뒤 처음으로 압축 파일을 풀어 보고 경로 구조를 확인한다면 이미 늦습니다. 자동 발행은 사람이 실시간으로 지켜보지 않는 경우가 많기 때문에, 백업이 만들어졌다는 로그와 실제 복원 가능성 사이의 간격을 줄여야 합니다.

파일 존재와 복원 가능성은 다르다

futory-cron-posts-backup-YYYYMMDD-HHMMSS.tar.gz 같은 파일이 생성되면 표면적으로는 안심할 수 있습니다. 그러나 아카이브 안에 posts 디렉터리가 안정적인 이름으로 들어갔는지, Markdown 파일들이 누락되지 않았는지, 압축 파일 크기가 비정상적으로 작지 않은지는 별도로 확인해야 합니다. 파일명만 보고 성공으로 판단하면 빈 디렉터리를 백업한 상황도 놓칠 수 있습니다.

백업 범위가 넓을수록 되돌림은 어려워진다

Futory의 정기 글 발행은 content/posts만 바꾸는 작업입니다. 따라서 백업도 이 범위에 집중하는 편이 좋습니다. 전체 프로젝트를 매번 통째로 되돌리는 방식은 안전해 보이지만, .next, node_modules, 임시 파일, 빌드 산출물까지 섞이면 복원이 오히려 복잡해집니다. 새 글 하나를 추가하는 작업에는 posts 단위 백업이 더 명확합니다.

Futory에서 복원 리허설을 설계하는 방법

복원 리허설은 실제 서비스 파일을 덮어쓰는 위험한 테스트가 아니어도 됩니다. 핵심은 백업 아카이브가 예상한 구조로 만들어졌고, 필요하면 임시 디렉터리에 풀어 원본과 비교할 수 있다는 확신을 얻는 것입니다.

안정적인 아카이브 구조를 사용한다

백업을 만들 때는 아카이브 안의 최상위 경로를 posts처럼 고정합니다. 이렇게 하면 복원 시 content/posts로 되돌릴 대상이 분명해집니다. 생성 시점의 절대 경로가 그대로 들어가면 다른 환경에서 풀 때 혼란이 생길 수 있습니다. 크론 로그에는 백업 파일의 전체 경로와 크기를 남겨 두고, 필요하면 tar -tzf나 Python tarfile로 내부 목록을 확인할 수 있게 합니다.

임시 디렉터리 복원으로 위험을 줄인다

실제 장애가 아닌 평상시에는 백업을 곧바로 운영 디렉터리에 풀 필요가 없습니다. /tmp 아래 임시 디렉터리에 풀어 보고 posts/*.md 파일 수와 최근 날짜 파일이 들어 있는지만 확인해도 충분한 리허설이 됩니다. 이 방식은 운영 콘텐츠를 건드리지 않으면서 복원 명령이 작동하는지 검증합니다. 자동화 보고서에는 “백업 생성 OK”와 함께 크기나 경로 같은 증거를 남기면 다음 담당자가 빠르게 판단할 수 있습니다.

새 글 하나 원칙과 함께 사용한다

복원 리허설의 힘은 변경 범위가 작을 때 커집니다. 오늘 루틴이 새 Markdown 파일 하나만 추가했다면 실패 시 선택지는 단순합니다. 새 파일을 제거하거나, 필요하면 백업의 posts를 기준으로 되돌리면 됩니다. 반대로 발행 루틴이 기존 글 수정, 테마 변경, 설정 변경까지 한꺼번에 수행하면 어떤 백업을 언제 복원해야 하는지 어려워집니다. 바이브코딩에서도 빠른 실행은 작은 변경 단위와 함께할 때 안전합니다.

실패 상황별 대응 기준

백업 복원 리허설은 실패 대응을 미리 문장으로 정리하는 과정이기도 합니다. 어떤 단계에서 멈추었는지에 따라 되돌림 필요성과 공개 영향이 달라집니다.

콘텐츠 테스트 전에 실패한 경우

새 파일 작성 직후 npm run test:content가 실패했다면 아직 빌드와 PM2 재시작은 진행하지 않은 상태입니다. 이때는 새 Markdown 파일의 frontmatter, 날짜, 제목, 필수 섹션, 본문 길이를 먼저 고칩니다. 고칠 수 없거나 원인이 불분명하면 새 파일만 제거해도 됩니다. posts 백업은 이 판단을 안전하게 만들어 주는 보험입니다.

빌드 이후 공개 검증에서 실패한 경우

빌드가 통과하고 PM2 재시작까지 성공했지만 공개 URL이나 목록 페이지에서 새 글이 보이지 않을 수 있습니다. 이때 곧바로 백업 복원을 하는 것은 성급합니다. 먼저 .next 산출물에 slug가 들어 있는지, /posts/<slug>가 200을 반환하는지, 홈과 목록 페이지가 no-cache 요청에서 오늘 날짜나 slug를 보여 주는지 확인해야 합니다. 백업은 최후의 되돌림 수단이고, 공개 반영 지연은 런타임이나 캐시 문제일 수도 있습니다.

운영 보고서에 남길 증거

무인 크론의 보고서는 사람이 나중에 읽는 운영 장부입니다. “백업 완료”라는 한 줄보다 복원 가능한 백업인지 판단할 수 있는 단서가 더 유용합니다.

최소 기록 항목

보고서에는 백업 파일 경로, 파일 크기, 새 글 경로, slug, 테스트와 빌드 상태, PM2 재시작 상태, 공개 검증 결과를 함께 남기는 것이 좋습니다. 특히 백업 경로는 KST 날짜와 시간이 들어가야 오늘 실행과 자연스럽게 연결됩니다. 장애 대응자는 이 경로를 기준으로 임시 복원, 파일 비교, 필요 시 원복 절차를 빠르게 진행할 수 있습니다.

장기적으로 확인할 항목

백업 파일이 계속 쌓이면 보관 기간과 삭제 기준도 필요합니다. 모든 백업을 영구 보관하면 디스크가 불필요하게 커지고, 너무 빨리 지우면 며칠 뒤 발견된 문제를 되돌리기 어렵습니다. Futory의 평일 글 발행처럼 변경량이 작고 빈도가 일정한 작업은 최근 며칠 또는 몇 주 단위로 보존 정책을 정하기 쉽습니다. 중요한 것은 정책을 정한 뒤 실제 백업 경로와 함께 보고서에 남기는 것입니다.

자주 묻는 질문

백업이 있으면 테스트 실패 후 자동으로 복원해도 되나요?

항상 그렇지는 않습니다. 새 파일 하나가 문제라면 해당 파일을 고치는 편이 더 낫습니다. 자동 복원은 정상 파일까지 과거 상태로 되돌릴 수 있으므로, 실패 원인이 명확하고 변경 범위가 오늘 새 파일 하나라는 점을 확인한 뒤 선택해야 합니다.

매번 임시 디렉터리에 풀어 봐야 하나요?

매 실행마다 완전 복원을 할 필요는 없습니다. 다만 아카이브 구조와 크기, 포함 파일 수를 주기적으로 확인하면 좋습니다. 백업 도구를 바꾸었거나 경로를 옮겼거나 posts 구조가 바뀐 날에는 임시 복원 리허설을 더 강하게 하는 편이 안전합니다.

백업 대신 Git으로 되돌리면 충분하지 않나요?

배포 폴더가 항상 Git 저장소라는 보장은 없습니다. 또한 라이브 환경에서는 untracked 파일이나 빌드 산출물이 섞여 있을 수 있습니다. Git은 좋은 도구지만, Futory의 무인 발행 루틴에서는 실제 content/posts를 바로 되돌릴 수 있는 압축 백업을 별도로 남기는 편이 더 확실합니다.

결론

AI 블로그 자동화에서 백업은 단순한 사전 의식이 아니라 복구 시간을 줄이는 운영 설계입니다. Futory의 Next.js Markdown 루틴은 새 글 하나만 추가하고, 그 전에 posts 백업을 만들며, 이후 테스트와 빌드와 공개 검증을 차례로 통과하는 구조입니다. 이 구조에서는 백업 파일의 존재뿐 아니라 복원 가능한 경로와 증거를 남기는 습관이 중요합니다.

바이브코딩은 빠르게 만들고 배포하는 방식이지만, 빠름은 되돌릴 수 있을 때 더 강해집니다. 안정적인 아카이브 구조, 임시 복원 리허설, 작은 변경 범위, 명확한 운영 보고서를 함께 사용하면 Futory의 평일 자동 발행은 실패에도 침착하게 대응할 수 있습니다. 결국 좋은 자동화는 글을 잘 올리는 것뿐 아니라, 문제가 생겼을 때 안전하게 이전 상태로 돌아갈 수 있는 길까지 준비해 둡니다.