AI 블로그 자동화에서 미리보기 검증을 운영 루틴으로 만드는 법

요약

AI 블로그 자동화에서 “발행했다”는 말은 실제로 여러 단계를 통과했다는 뜻이어야 합니다. Markdown 파일이 만들어졌고, frontmatter가 오늘 날짜를 가리키며, 콘텐츠 테스트와 테마 테스트를 지나고, Next.js 빌드 산출물에 새 slug가 포함되어야 합니다. 그다음 PM2 재시작과 공개 URL 검증이 이어질 때 비로소 독자가 보는 발행 상태를 말할 수 있습니다.

Futory처럼 content/posts/*.md가 공개 페이지의 원천이 되는 구조에서는 미리보기 검증을 별도의 거창한 환경으로 만들 필요가 없습니다. 새 파일을 만들기 전 백업을 남기고, 작성 후 로컬 테스트와 빌드를 순서대로 확인하며, .next 산출물에서 slug를 찾는 것만으로도 충분히 강한 사전 신호를 얻을 수 있습니다. 이 글은 매일 반복되는 바이브코딩 블로그 발행에서 미리보기 검증을 어떻게 작고 안정적인 루틴으로 만들지 정리합니다.

미리보기 검증이 필요한 이유

자동화된 글 발행은 사람이 직접 브라우저에서 초안을 훑어보는 과정이 줄어드는 대신, 기계가 확인할 수 있는 신호를 더 엄격하게 다뤄야 합니다. 파일이 존재한다는 사실만으로는 충분하지 않습니다. 날짜가 잘못되었거나, slug가 예상과 다르거나, 테마에서 요구하는 섹션이 빠졌거나, 빌드가 오래된 산출물을 보고 있을 수 있습니다. 이런 문제는 공개 후에 발견하면 원인 추적이 더 어려워집니다.

공개 전 신호와 공개 후 신호를 나눈다

미리보기 검증의 핵심은 공개 전 신호와 공개 후 신호를 섞지 않는 것입니다. 공개 전에는 Markdown 파일, frontmatter, 테스트, 빌드, .next 포함 여부를 봅니다. 공개 후에는 상세 URL의 HTTP 200, 홈과 목록 페이지의 노출, 캐시 우회 요청 결과를 봅니다. 둘을 분리하면 실패 지점이 선명해집니다. 빌드 전 실패라면 글이나 구조 문제이고, 재시작 후 실패라면 런타임·캐시·프록시 문제일 가능성이 큽니다.

운영 보고서도 미리보기의 일부다

자동화가 끝난 뒤 남기는 보고서는 단순한 알림이 아니라 다음 실행을 위한 미리보기 자료입니다. 어떤 slug가 선택되었고, 어떤 파일을 만들었고, 어떤 테스트가 통과했으며, 어떤 URL이 확인되었는지 남기면 다음 크론 실행은 중복 생성 대신 기존 상태를 빠르게 판별할 수 있습니다. 보고서가 정확할수록 자동화는 더 조용하고 예측 가능해집니다.

Futory에서 적용할 수 있는 사전 점검 순서

Futory의 운영 루틴은 큰 플랫폼 배포보다 작은 파일 계약에 가깝습니다. 그래서 미리보기 검증도 복잡한 대시보드보다 순서가 중요합니다. 먼저 KST 기준 오늘이 발행 대상인지 확인하고, 오늘 날짜가 이미 frontmatter나 파일명에 있는지 검색합니다. 그다음 최근 글 제목을 읽어 주제 중복을 피하고, content/posts 전체를 백업합니다.

새 파일은 하나만 만든다

자동화가 반복 실행될 수 있다는 점을 고려하면, 선택된 시간에 새 Markdown 파일은 정확히 하나만 만들어야 합니다. 파일명은 영어 kebab-case slug로 정하고, frontmatter의 date는 KST 오늘 날짜와 일치시킵니다. 이 규칙은 미리보기 검증의 출발점입니다. 파일이 여러 개 생기거나 날짜가 엇갈리면 이후 테스트가 통과해도 운영 판단이 흐려집니다.

테스트와 빌드는 같은 순서로 반복한다

콘텐츠 테스트, 테마 테스트, 빌드 순서를 매번 동일하게 유지하면 실패 로그를 비교하기 쉬워집니다. npm run test:content는 글의 구조와 메타데이터를 확인하고, npm run test:theme는 화면 규칙과 충돌하지 않는지 살핍니다. npm run build는 Next.js가 실제로 새 Markdown을 페이지로 만들 수 있는지 확인합니다. 이 세 단계를 통과한 뒤에야 PM2 재시작을 시도하는 것이 안전합니다.

산출물에서 slug를 확인하는 습관

빌드 성공 메시지만 보고 끝내면 새 글이 빌드에 포함되었는지 확신하기 어렵습니다. 그래서 .next 산출물에서 새 slug를 검색하는 단계를 추가하는 것이 좋습니다. 이 검사는 짧지만 효과가 큽니다. 파일은 존재하고 빌드도 성공했지만 라우팅이나 수집 로직에서 누락된 경우를 조기에 발견할 수 있기 때문입니다.

캐시 우회 검증까지 이어간다

PM2 재시작 후에는 공개 상세 URL과 목록 페이지를 cache-busting query string으로 확인합니다. Cache-Control: no-cache 헤더를 함께 쓰면 브라우저나 프록시가 보여 주는 오래된 화면에 속을 가능성을 줄일 수 있습니다. 상세 페이지가 200을 반환하고, 홈·posts·vibe-coding 목록 중 필요한 위치에 오늘 날짜나 slug가 보이면 독자 관점의 검증까지 완료된 것입니다.

자주 묻는 질문

미리보기 환경을 따로 만들어야 하나요?

작은 Markdown 기반 블로그라면 반드시 별도 환경이 필요하지는 않습니다. 중요한 것은 공개 전 신호를 충분히 모으는 것입니다. 파일 백업, frontmatter 확인, 테스트, 빌드, 산출물 slug 확인만 꾸준히 해도 대부분의 실수를 공개 전에 잡을 수 있습니다.

빌드는 성공했는데 공개 목록에 안 보이면 어떻게 하나요?

먼저 상세 URL이 200인지 확인하고, 그다음 PM2 재시작 여부와 캐시 우회 요청을 확인해야 합니다. 상세 페이지가 열리는데 목록만 늦게 보이면 정렬, 목록 생성 로직, 캐시 문제일 수 있습니다. 상세도 열리지 않으면 배포 경로, 빌드 산출물, 런타임 프로세스를 다시 점검하는 편이 좋습니다.

실패하면 새 글을 다시 만들면 되나요?

아닙니다. 오늘 날짜의 Markdown 파일이 이미 만들어졌다면 그 파일이 기준입니다. 실패 원인을 고치거나 재빌드·재시작·검증을 다시 해야지, 같은 날짜의 새 글을 만들면 중복과 혼선이 커집니다. 미리보기 검증은 실패를 안전하게 멈추기 위한 장치이기도 합니다.

결론

미리보기 검증은 자동화를 느리게 만드는 절차가 아니라, 자동화가 같은 실수를 반복하지 않게 만드는 안전장치입니다. Futory의 Next.js Markdown 운영에서는 오늘 날짜 파일 하나를 기준으로 삼고, 백업·테스트·빌드·산출물 확인·공개 검증을 같은 slug에 연결하면 충분히 실용적인 발행 루틴을 만들 수 있습니다. 매일 한 편을 안정적으로 공개하려면 글쓰기만큼이나 “무엇을 확인했는지”를 꾸준히 남기는 습관이 중요합니다.