AI 블로그 자동화에서 날짜 메타데이터를 점검하는 루틴

요약

AI 블로그 자동화에서 날짜는 단순히 글이 쓰인 날을 표시하는 장식이 아닙니다. Futory처럼 content/posts/*.md 파일을 기준으로 Next.js가 상세 페이지와 목록 페이지를 만드는 구조에서는 frontmatter의 date, 파일명, 빌드 산출물, 공개 목록의 표시가 모두 같은 발행 사건을 가리켜야 합니다. 이 연결이 어긋나면 이미 오늘 글이 있는데도 새 글을 만들거나, 반대로 파일은 있는데 공개 목록에서는 찾기 어려운 상태가 생길 수 있습니다.

날짜 메타데이터 점검 루틴의 목표는 매일 한 편을 안전하게 발행하는 것입니다. 자동화는 먼저 Asia/Seoul 기준 오늘 날짜를 정하고, 같은 날짜가 frontmatter나 파일명에 이미 있는지 확인해야 합니다. 새 글을 만든 뒤에는 콘텐츠 테스트와 빌드를 통과했는지뿐 아니라 공개 상세와 목록에서도 오늘 날짜나 slug가 보이는지 확인해야 합니다. 이 글은 Futory의 바이브코딩 운영 관점에서 날짜 메타데이터를 하나의 운영 신호로 다루는 방법을 정리합니다.

날짜는 중복 방지의 기준이다

반복 발행에서 가장 먼저 막아야 할 문제는 같은 날짜에 글이 여러 개 생기는 일입니다. 크론은 네트워크 오류, 빌드 실패, 프로세스 재시작 지연 때문에 같은 날 여러 번 실행될 수 있습니다. 이때 날짜 점검이 약하면 자동화는 이전 실행이 남긴 파일을 보지 못하고 새 파일을 또 만들 수 있습니다. 그래서 오늘 날짜 글이 이미 존재하는지 확인하는 단계는 작성보다 앞에 있어야 합니다.

frontmatter는 사람이 읽는 로그이자 기계가 읽는 키다

Markdown 본문 안의 date: "YYYY-MM-DD"는 목록 정렬과 중복 방지에 쓰이는 핵심 키입니다. 사람이 보면 발행일이고, 자동화가 보면 오늘 작업을 이미 수행했는지 판단하는 기준입니다. 파일명은 slug를 담당하지만, 날짜는 frontmatter에 고정하는 편이 안전합니다. 파일명이 주제 중심으로 만들어져도 날짜 검색은 동일한 형식으로 수행할 수 있기 때문입니다.

파일명만 믿으면 놓치는 경우가 생긴다

영어 kebab-case 파일명은 공개 URL을 예측하기 쉽다는 장점이 있습니다. 하지만 파일명에는 날짜가 들어가지 않을 수도 있고, 운영자가 수동으로 만든 글은 다른 명명 규칙을 따를 수도 있습니다. 따라서 중복 방지는 파일명 검색과 frontmatter 검색을 함께 보는 것이 좋습니다. 특히 Futory 루틴에서는 오늘 날짜가 frontmatter에 있거나 파일명에 포함되면 새 글을 만들지 않는 방식이 안정적입니다.

작성 전 점검 루틴

새 글을 쓰기 전의 점검은 짧지만 순서가 중요합니다. 먼저 KST 기준으로 오늘이 평일인지 확인하고, 날짜별 선택 시간이 맞는지 계산합니다. 그 다음 content/posts에서 오늘 날짜가 이미 있는지 찾습니다. 여기까지 통과한 뒤에야 최근 글을 읽고 주제가 겹치지 않는 새 글을 작성합니다.

최근 글을 읽는 이유

날짜 중복이 없다고 해서 바로 글을 만들면 주제 중복이 생길 수 있습니다. 최근 Futory 글들은 파일 계약, 배포 신호, 운영 알림, 재시도 런북처럼 Next.js Markdown 자동화의 실제 운영 문제를 다룹니다. 오늘 글도 이 흐름을 이어가되, 같은 제목이나 같은 결론을 반복하지 않아야 합니다. 날짜 메타데이터 점검이라는 관점은 기존의 빌드 확인이나 알림 기준과 연결되지만, 중복 방지의 첫 기준을 더 선명하게 보여 줍니다.

백업은 변경 전의 안전선이다

새 파일 하나만 추가하더라도 live content tree를 건드리는 작업이라면 백업이 먼저입니다. 백업은 실수를 되돌리기 위한 장치이면서, 자동화가 보수적으로 움직였다는 증거입니다. 특히 발행 자동화는 사람이 실시간으로 감시하지 않을 수 있으므로, 변경 전 상태를 복구할 수 있는 tar.gz 파일을 남기는 편이 좋습니다.

작성 후 검증 루틴

작성 후 검증은 “파일이 있다”에서 끝나지 않습니다. 콘텐츠 테스트는 frontmatter와 필수 섹션을 확인하고, 테마 테스트는 사이트의 표시 규칙과 충돌하지 않는지 확인합니다. 빌드는 Next.js가 새 Markdown을 실제 페이지 생성 과정에 포함할 수 있는지 검증합니다.

빌드 산출물에서 slug를 확인한다

npm run build가 성공해도 오늘 만든 slug가 산출물에 포함됐는지 따로 확인하면 좋습니다. 이 단계는 날짜 메타데이터와 공개 URL을 연결하는 작은 증거입니다. slug가 .next 안에서 확인되면 새 파일이 빌드 과정에 들어갔다는 신뢰가 커집니다. 반대로 빌드는 성공했지만 slug가 보이지 않는다면 콘텐츠 로딩 규칙이나 경로 문제를 의심해야 합니다.

공개 목록은 발견 가능성을 보여 준다

상세 페이지가 200을 반환하는 것은 직접 URL 접근이 가능하다는 의미입니다. 그러나 홈, /posts, /vibe-coding 목록에 오늘 날짜나 slug가 보여야 독자가 새 글을 발견할 수 있습니다. 날짜 메타데이터가 목록 정렬에 쓰이는 구조에서는 이 확인이 특히 중요합니다. 캐시를 피하기 위해 query string과 Cache-Control: no-cache를 함께 사용하는 습관도 운영 신뢰도를 높입니다.

운영 보고서에 남길 항목

날짜 점검 루틴은 보고서에서도 드러나야 합니다. 선택된 KST 시간, 오늘 날짜, 기존 글 여부, 새 파일 경로, 백업 경로, 테스트 결과, 빌드 결과, PM2 재시작 결과, 공개 상세와 목록 검증을 짧게 적으면 충분합니다. 중요한 것은 감상보다 증거입니다.

실패 시에는 중복 생성을 막는 메시지가 필요하다

검증이나 빌드가 실패하더라도 이미 새 파일이 만들어졌다면 다음 실행에서 오늘 날짜 중복 방지 규칙이 작동해야 합니다. 실패 보고서에는 생성된 파일과 날짜를 남겨 다음 운영자가 같은 날 새 글을 다시 만들지 않도록 해야 합니다. 필요하다면 기존 파일을 수정하고 다시 빌드하는 것이 맞지, 새 주제로 하나 더 만드는 것은 위험합니다.

자주 묻는 질문

날짜는 파일명에도 넣어야 하나요?

반드시 그럴 필요는 없습니다. Futory에서는 영어 kebab-case slug가 공개 URL이 되므로 파일명은 주제를 잘 설명하는 편이 좋습니다. 날짜는 frontmatter에 고정하고, 중복 방지 검색에서는 frontmatter와 파일명을 함께 확인하는 방식이 더 유연합니다.

오늘 날짜 글이 있는데 공개 사이트에 안 보이면 어떻게 하나요?

새 글을 다시 만들지 말고 반영 경로를 확인해야 합니다. 콘텐츠 테스트, 빌드 산출물, PM2 재시작, 공개 상세 페이지, 목록 페이지를 순서대로 보면 어디에서 끊겼는지 좁힐 수 있습니다. 날짜 점검은 중복 생성을 막기 위한 기준이고, 공개 미반영은 별도의 배포 신호 문제로 다루는 것이 안전합니다.

KST 기준을 꼭 써야 하나요?

운영자가 보는 일정과 크론이 실행되는 서버 시간이 다를 수 있으므로 기준 시간대를 명확히 해야 합니다. Futory의 발행 의도는 Asia/Seoul 평일 오후 시간대이므로 날짜와 선택 시간도 KST로 계산해야 합니다. 그래야 UTC 크론과 실제 발행일이 어긋나지 않습니다.

결론

AI 블로그 자동화에서 날짜 메타데이터는 작은 값처럼 보이지만, 실제로는 중복 방지와 발행 검증의 중심축입니다. Futory의 Next.js Markdown 운영에서는 frontmatter의 날짜, slug 파일명, 빌드 산출물, 공개 목록이 서로 같은 글을 가리켜야 안정적인 일일 발행이 가능합니다.

바이브코딩은 빠른 실행을 장점으로 삼지만, 매일 반복되는 발행에는 빠름을 붙잡아 주는 기준이 필요합니다. 오늘 날짜를 먼저 확인하고, 변경 전 백업을 남기고, 새 파일 하나만 만들고, 테스트와 빌드와 공개 확인을 거치는 루틴은 단순하지만 강력합니다. 날짜를 운영 신호로 다루면 자동화는 더 조용하게 중복을 피하고, 문제가 생겼을 때도 어디를 확인해야 하는지 분명하게 알려 줍니다.