AI 블로그 일일 발행을 위한 헬스체크 지표 설계

요약

AI 블로그 자동화는 글을 생성하는 순간보다 글이 실제로 독자에게 보이는 순간이 더 중요합니다. Futory처럼 content/posts/*.md에 Markdown 파일을 추가하고, Next.js 빌드와 PM2 재시작을 거쳐 공개하는 구조에서는 매일의 발행을 하나의 작은 운영 이벤트로 다뤄야 합니다. 이때 필요한 것은 거창한 대시보드가 아니라 반복해서 확인할 수 있는 헬스체크 지표입니다.

이 글은 Futory 일일 발행 루틴에서 기록하면 좋은 지표를 정리합니다. 오늘 날짜 파일이 하나만 존재하는지, 콘텐츠 검증과 테마 검증이 통과했는지, 빌드 산출물에 새 slug가 포함됐는지, PM2 재시작 후 공개 URL과 목록 페이지가 최신 상태인지 확인하는 방식입니다. 핵심은 “성공했다”는 감각을 줄이고, 어떤 단계가 어떤 증거로 성공했는지 남기는 것입니다.

왜 발행 지표가 필요한가

AI와 함께 블로그를 운영하면 초안 작성 속도는 빨라집니다. 하지만 운영 속도가 빨라질수록 작은 누락이 잘 보이지 않습니다. 파일은 생성됐지만 날짜가 틀릴 수 있고, 빌드는 성공했지만 실행 중인 프로세스가 이전 산출물을 보고 있을 수 있습니다. 공개 상세 페이지는 열리지만 홈이나 카테고리 목록에는 빠져 있을 수도 있습니다.

그래서 매일 발행 루틴에는 다음 질문을 지표로 바꿔야 합니다.

• 오늘 KST 날짜의 글이 정확히 하나인가
• 새 글의 frontmatter가 Futory 규칙을 따르는가
• 검증 명령과 빌드가 모두 성공했는가
• .next 산출물에 새 slug가 포함됐는가
• PM2 재시작 이후 공개 URL이 200으로 응답하는가
• 홈, 글 목록, 바이브코딩 목록에 날짜나 slug가 보이는가

이 질문들은 사람이 감으로 확인해도 되지만, 자동화에서는 로그와 결과로 남겨야 다음 장애를 빠르게 좁힐 수 있습니다.

Futory 기준 핵심 헬스체크 항목

1. 날짜와 중복 상태

가장 먼저 볼 지표는 날짜입니다. Futory는 KST 기준 평일에 하루 한 편을 발행하는 흐름이므로, 새 글을 만들기 전 date: "YYYY-MM-DD"가 이미 존재하는지 확인해야 합니다. 파일명에 날짜가 없어도 frontmatter에 오늘 날짜가 있다면 이미 발행 대상이 있는 것으로 보고 멈추는 편이 안전합니다.

중복 방지 지표는 단순하지만 효과가 큽니다. 크론이 재시도되거나 같은 시간대에 여러 번 실행돼도 오늘 날짜 글이 하나만 유지되기 때문입니다.

2. 콘텐츠 구조 상태

두 번째 지표는 Markdown 구조입니다. Futory 글은 ## 요약, 여러 본문 섹션, ## 자주 묻는 질문, ## 결론을 포함하는 방식으로 독자가 빠르게 흐름을 파악할 수 있게 구성됩니다. 자동 발행에서는 글자 수만 확인하는 것보다 섹션의 역할이 명확한지 보는 것이 좋습니다.

예를 들어 요약은 운영 문제와 해결 방향을 짧게 설명하고, 본문은 실제 체크 순서를 다루며, FAQ는 운영자가 자주 헷갈리는 부분을 정리해야 합니다. 이렇게 구조를 고정하면 매일 다른 주제를 다루더라도 블로그의 읽는 경험이 흔들리지 않습니다.

3. 빌드 산출물 상태

Next.js Markdown 블로그에서는 파일 생성이 곧 공개가 아닙니다. npm run test:content, npm run test:theme, npm run build가 모두 통과해야 다음 단계로 넘어갈 수 있습니다. 특히 빌드가 성공한 뒤에는 .next 내부에 새 slug가 반영됐는지 확인하는 것이 좋습니다.

이 지표는 “빌드 명령이 0으로 끝났다”와 “새 글이 빌드 결과에 포함됐다”를 분리해 줍니다. 전자는 전체 앱의 빌드 상태이고, 후자는 오늘 글이 실제 라우팅 후보가 됐는지를 보여줍니다.

공개 검증은 상세 페이지와 목록을 나눠서 본다

공개 검증은 상세 URL 하나만 확인하면 부족합니다. Futory의 독자는 홈, 전체 글 목록, 바이브코딩 카테고리 목록을 통해 새 글을 발견할 수 있습니다. 따라서 /posts/<slug>가 200으로 응답하는지와 함께 /, /posts, /vibe-coding에 오늘 날짜나 slug가 포함되는지 확인해야 합니다.

캐시 문제를 줄이기 위해 공개 페이지 확인에는 cache-busting query string과 Cache-Control: no-cache 헤더를 함께 사용하는 것이 좋습니다. 이 방식은 브라우저 캐시가 아니라 서버가 현재 어떤 내용을 돌려주는지 확인하는 데 도움이 됩니다.

운영 로그로 남기면 좋은 형식

일일 자동화 결과는 길게 설명하기보다 다음 항목을 일정한 순서로 남기면 충분합니다.

• 선택된 KST 발행 시간
• 생성한 파일 경로와 slug
• 백업 파일 경로
• 콘텐츠 검증 결과
• 테마 검증 결과
• 빌드 결과
• PM2 재시작 결과
• 공개 상세 URL 상태 코드
• 목록 페이지별 slug 또는 날짜 포함 여부

이 형식은 장애가 생겼을 때 특히 유용합니다. 예를 들어 빌드는 성공했는데 목록 페이지에 slug가 없다면 콘텐츠 파일 문제보다는 라우팅, 캐시, 재시작 문제를 먼저 확인할 수 있습니다. 반대로 test:content에서 멈췄다면 공개 서버를 건드릴 필요가 없습니다.

자주 묻는 질문

헬스체크 지표를 매일 모두 확인해야 하나요?

자동 발행이라면 모두 확인하는 편이 안전합니다. 항목이 많아 보여도 대부분은 스크립트와 명령 결과로 자동 수집할 수 있습니다. 사람이 매일 길게 검토하는 것이 아니라, 자동화가 같은 순서로 확인하고 실패 지점을 보고하도록 만드는 것이 목표입니다.

공개 상세 페이지만 200이면 성공 아닌가요?

아닙니다. 상세 페이지가 열려도 홈이나 목록에 새 글이 보이지 않으면 독자가 발견하기 어렵습니다. Futory처럼 블로그 목록이 중요한 서비스에서는 상세 URL, 홈, 전체 글 목록, 카테고리 목록을 함께 검증해야 합니다.

PM2 재시작이 항상 필요한가요?

운영 방식에 따라 다르지만, 현재 Futory 루틴에서는 빌드 후 실행 중인 Next.js 프로세스가 새 산출물을 보도록 PM2 재시작을 포함합니다. 빌드가 실패하면 PM2를 재시작하지 않아야 하며, 재시작 후에는 공개 URL을 다시 확인해야 합니다.

결론

AI 블로그 운영에서 좋은 자동화는 글을 대신 쓰는 데서 끝나지 않습니다. 매일의 발행이 어떤 증거로 성공했는지 확인하고, 실패했을 때 어느 단계에서 멈췄는지 알 수 있어야 합니다. Futory의 Next.js Markdown 구조에서는 날짜 중복 검사, 콘텐츠 검증, 테마 검증, 빌드 산출물 확인, PM2 재시작, 공개 URL 검증을 하나의 헬스체크 지표 묶음으로 관리하는 것이 가장 실용적입니다.

이 지표들이 쌓이면 발행 루틴은 단순한 반복 작업이 아니라 안정적인 운영 시스템이 됩니다. 바이브코딩의 장점은 빠른 생성이고, 운영 지표의 장점은 빠른 확인입니다. 두 가지가 함께 있을 때 매일 발행하는 블로그가 오래 유지될 수 있습니다.