AI 블로그 자동화에서 콘텐츠 매니페스트를 점검하는 법

요약

Futory처럼 content/posts/*.md 파일을 원천으로 삼는 Next.js Markdown 블로그에서는 글 하나가 만들어지는 순간부터 여러 목록에 동시에 참여합니다. 파일 시스템의 목록, frontmatter의 날짜와 카테고리, 빌드가 읽는 콘텐츠 배열, 공개 사이트의 홈과 카테고리 목록이 모두 같은 글을 가리켜야 합니다. 이 연결을 느슨하게 두면 새 글 파일은 있는데 목록에는 없거나, 상세 페이지는 열리는데 운영 보고서가 어떤 파일을 기준으로 하는지 모호해지는 문제가 생깁니다.

콘텐츠 매니페스트는 복잡한 별도 시스템을 뜻하지 않습니다. 오늘 발행 대상의 slug, title, date, category, tags, 파일 경로, 공개 URL을 한 묶음의 운영 단서로 보는 방식입니다. Futory의 바이브코딩 자동화에서는 이 묶음을 매일 짧게 점검하는 것만으로도 중복 발행, 누락, 캐시 오해, 재시도 혼선을 크게 줄일 수 있습니다.

콘텐츠 매니페스트가 필요한 이유

Markdown 블로그는 단순해서 좋지만, 단순하다는 말이 검증이 필요 없다는 뜻은 아닙니다. 자동화가 새 파일을 만들고 테스트와 빌드를 실행하면 대부분의 날에는 조용히 성공합니다. 그러나 실패한 날에는 “무엇이 원천인가”를 바로 답할 수 있어야 합니다. 원천이 파일인지, 빌드 산출물인지, 공개 응답인지가 뒤섞이면 같은 날짜로 글을 다시 만들거나 이미 공개된 글을 장애로 오해할 수 있습니다.

slug는 운영의 공통 키다

제목은 사람이 읽기 쉽고, slug는 시스템이 추적하기 쉽습니다. 오늘의 파일명이 ai-blog-content-manifest-routine.md라면 공개 URL은 /posts/ai-blog-content-manifest-routine이 되고, 빌드 산출물 검색어도 같은 문자열이 됩니다. 이 공통 키가 있으면 콘텐츠 테스트, 빌드 확인, PM2 재시작, 공개 검증 결과를 한 줄로 연결할 수 있습니다.

frontmatter는 작은 계약서다

Futory의 새 글은 title, description, date, category, tags를 frontmatter에 담습니다. 이 값들은 단순 장식이 아니라 목록 생성과 검증의 입력입니다. 특히 date는 하루 한 편 원칙을 지키는 중복 방지 기준이고, category: "바이브코딩"은 /vibe-coding 목록에 글이 등장해야 한다는 기대를 만듭니다. frontmatter가 정확하면 자동화는 다음 단계로 자신 있게 넘어갈 수 있습니다.

Futory에서 적용하는 점검 루틴

콘텐츠 매니페스트 점검은 글을 길게 분석하는 과정이 아니라 발행 단계를 같은 값으로 묶는 과정입니다. 먼저 KST 기준 오늘 날짜가 이미 frontmatter나 파일명에 있는지 확인합니다. 이미 있다면 새 글을 만들지 않는 것이 가장 중요합니다. 없다면 최근 글의 주제와 겹치지 않도록 확인한 뒤 새 slug와 제목을 정합니다.

백업 후 새 파일 하나만 추가한다

live content tree를 다루는 자동화에서는 백업이 먼저입니다. /opt/futory/content/posts를 타임스탬프가 있는 아카이브로 보관해 두면 테스트나 빌드가 실패해도 이번 실행이 추가한 파일을 분리해서 볼 수 있습니다. 그다음에는 새 Markdown 파일 하나만 추가합니다. 기존 글을 동시에 수정하지 않으면 실패 원인이 훨씬 단순해집니다.

테스트와 빌드는 매니페스트를 검증한다

npm run test:content는 frontmatter와 본문 구조가 계약에 맞는지 확인합니다. npm run test:theme는 글이 테마 규칙과 충돌하지 않는지 봅니다. npm run build는 Next.js가 이 콘텐츠를 실제 페이지로 만들 수 있는지 확인합니다. 여기서 끝내지 않고 .next에서 slug를 검색하면 “빌드가 성공했다”를 “오늘 글이 빌드 입력과 산출물에 연결됐다”로 한 단계 더 구체화할 수 있습니다.

공개 목록까지 이어 보기

PM2 재시작 후 공개 검증은 상세 페이지와 목록 페이지를 나누어 봐야 합니다. 상세 URL이 200을 반환하면 직접 접근은 가능한 상태입니다. 하지만 홈, /posts, /vibe-coding에 보이지 않으면 독자가 새 글을 발견하기 어렵습니다. 그래서 Futory 운영 보고서는 각 페이지의 상태 코드와 slug 또는 날짜 포함 여부를 따로 남기는 편이 안전합니다.

캐시는 상태 판단을 흐릴 수 있다

공개 페이지를 확인할 때는 cache-busting query string과 Cache-Control: no-cache 헤더를 함께 쓰는 습관이 좋습니다. 캐시를 완전히 제거하는 만능 해법은 아니지만, 오래된 목록을 보고 배포 실패로 착각할 가능성을 낮춥니다. 같은 slug로 상세와 목록을 반복 확인하면 캐시 문제와 빌드 문제를 더 쉽게 구분할 수 있습니다.

실패 보고도 매니페스트 기준으로 쓴다

빌드가 실패했다면 실패한 명령과 exit code를 남기고 PM2 재시작은 하지 않아야 합니다. PM2 재시작이 실패했다면 빌드 성공과 공개 실패 사이의 문제로 보고해야 합니다. 공개 목록만 실패했다면 상세 URL의 상태와 목록 포함 여부를 분리해서 적어야 합니다. 모든 보고가 같은 date와 slug를 쓰면 다음 재시도는 새 글 작성이 아니라 상태 이어가기가 됩니다.

자주 묻는 질문

콘텐츠 매니페스트 파일을 따로 만들어야 하나요?

반드시 별도 파일이 필요한 것은 아닙니다. Futory의 반복 발행에서는 Markdown frontmatter, 파일명, 빌드 산출물 검색, 공개 URL 검증 결과를 같은 묶음으로 기록하는 것만으로 충분합니다. 중요한 것은 별도 도구보다 같은 기준을 반복하는 습관입니다.

목록에 늦게 보이면 글을 수정해야 하나요?

대부분은 바로 글을 수정할 필요가 없습니다. 파일과 frontmatter가 정상이고 빌드 산출물에 slug가 있다면 다음 확인 지점은 PM2 재시작, 캐시 우회 요청, 목록 페이지 생성 규칙입니다. 콘텐츠와 런타임 반영을 분리해서 보는 편이 안전합니다.

오늘 날짜 파일이 있는데 공개 URL이 없으면 새 글을 만들까요?

아닙니다. 오늘 날짜 파일이 이미 있다면 그 파일이 기준입니다. 새 파일을 추가하면 중복 발행이 되고, 다음 검증이 더 어려워집니다. 기존 파일의 slug로 테스트, 빌드, 산출물, PM2, 공개 응답을 차례로 확인해야 합니다.

결론

AI 블로그 자동화에서 콘텐츠 매니페스트를 점검한다는 것은 새 글의 정체성을 끝까지 잃지 않는다는 뜻입니다. Futory의 Next.js Markdown 운영에서는 slug, date, 파일 경로, frontmatter, 빌드 산출물, 공개 URL이 같은 대상을 가리킬 때 발행 판단이 선명해집니다.

바이브코딩은 빠른 실행을 가능하게 하지만, 반복 운영에서는 빠른 실행만큼 빠른 확인도 중요합니다. 오늘의 글을 하나의 매니페스트로 보고 단계별 신호를 남기면 자동화는 중복 없이 이어지고, 운영자는 파일 생성과 실제 공개를 더 안정적으로 구분할 수 있습니다.