AI 블로그 자동화에서 콘텐츠 캘린더와 중복 방지를 함께 설계하는 법

요약

AI 블로그 자동화에서 가장 먼저 망가지는 부분은 글쓰기 품질이 아니라 운영 기준입니다. 오늘 글이 이미 있는데 새 글을 한 번 더 만들거나, 같은 주제를 다른 제목으로 반복하거나, 빌드까지 성공했지만 공개 목록에는 보이지 않는 일이 생기기 쉽습니다. Futory처럼 content/posts/*.md 파일을 기준으로 운영하는 Next.js Markdown 블로그에서는 콘텐츠 캘린더와 중복 방지 규칙을 함께 설계해야 합니다.

이 글은 매일 한 편씩 발행하는 Futory 운영 흐름을 기준으로 날짜, 파일명, frontmatter, 최근 주제, 빌드, 공개 URL 검증을 하나의 루틴으로 묶는 방법을 설명합니다. 핵심은 AI가 글을 잘 쓰게 만드는 것보다, AI가 같은 실수를 반복하지 못하도록 작은 안전장치를 앞단에 배치하는 것입니다.

콘텐츠 캘린더는 거창한 도구가 아니어도 된다

블로그 자동화에서 콘텐츠 캘린더라고 하면 별도 SaaS나 복잡한 에디토리얼 보드를 떠올리기 쉽습니다. 하지만 Futory 같은 Markdown 블로그에서는 기존 글 목록 자체가 가장 현실적인 캘린더가 됩니다. 파일의 frontmatter에는 날짜, 제목, 카테고리, 태그가 들어 있고, 파일명은 공개 URL의 slug가 됩니다.

운영 루틴은 다음 세 가지 질문에서 시작하면 충분합니다.

• 오늘 KST 날짜의 글이 이미 있는가
• 최근 며칠 동안 어떤 주제를 다뤘는가
• 새 글이 기존 글을 보완하는가, 아니면 반복하는가

이 기준만 있어도 자동화는 훨씬 안전해집니다. AI에게 “새 글을 써줘”라고 바로 요청하는 대신, 먼저 최근 Markdown 파일을 읽고 빈 날짜와 주제 공백을 확인하게 만들면 중복 가능성이 크게 줄어듭니다.

날짜 기반 중복 방지 규칙 만들기

매일 발행 블로그에서 가장 강한 중복 방지 기준은 날짜입니다. Futory에서는 frontmatter의 date가 운영 날짜를 나타내므로, 새 글을 쓰기 전 반드시 오늘 날짜가 이미 존재하는지 확인해야 합니다.

frontmatter 우선 확인

파일명에 날짜가 없더라도 frontmatter에는 날짜가 있을 수 있습니다. 따라서 중복 검사는 파일명만 보는 방식보다 frontmatter를 먼저 확인하는 방식이 안전합니다.

date: "2026-06-01"

이 값이 이미 있으면 새 글을 만들지 않고 스킵해야 합니다. 크론이 같은 날 여러 번 실행되거나 재시도되더라도 같은 날짜 글이 하나만 유지됩니다.

slug도 함께 확인

날짜가 다르더라도 slug가 비슷하면 주제가 겹칠 수 있습니다. 예를 들어 nextjs-markdown-blog-rebuild-routine과 markdown-blog-build-checklist는 다른 파일이지만 독자 입장에서는 비슷한 글처럼 느껴질 수 있습니다. 그래서 새 파일명은 최근 글의 slug와 비교해 역할을 분명히 해야 합니다.

오늘의 주제는 콘텐츠 캘린더와 중복 방지입니다. 최근 Futory 글들이 빌드, 배포 경로, 릴리즈 체크리스트를 다뤘기 때문에, 이 글은 “글을 만들기 전 단계의 안전장치”에 초점을 맞춥니다.

AI에게 맡길 일과 고정 규칙을 나누기

바이브코딩 방식의 장점은 AI가 초안을 빠르게 만들고 운영자가 방향을 조정할 수 있다는 점입니다. 하지만 자동 발행에서는 AI가 자유롭게 판단하면 안 되는 영역도 있습니다.

고정 규칙으로 둘 것

다음 항목은 AI의 창의성이 아니라 검증 가능한 규칙으로 처리해야 합니다.

• 게시 날짜는 Asia/Seoul 기준으로 계산한다
• 평일에만 게시한다
• 하루에 한 파일만 만든다
• category는 바이브코딩으로 유지한다
• 새 파일을 만들기 전에 content/posts를 백업한다
• 테스트와 빌드가 실패하면 PM2를 재시작하지 않는다

이 규칙들은 글의 내용과 무관하게 항상 같아야 합니다. 자동화가 안정적이라는 말은 이런 고정 규칙이 매번 같은 순서로 실행된다는 뜻입니다.

AI에게 맡길 것

반대로 다음 항목은 AI가 도움을 주기 좋은 영역입니다.

• 최근 글과 겹치지 않는 실무 주제 제안
• 독자가 바로 따라 할 수 있는 설명 구조 만들기
• FAQ와 결론 정리
• 제목과 description을 검색 친화적으로 다듬기
• 태그를 기존 블로그 톤에 맞게 구성하기

즉, 운영 안전성은 스크립트와 검증에 맡기고, 글의 설명력은 AI에게 맡기는 분리가 필요합니다.

Next.js Markdown 운영에서 검증 순서

새 글이 만들어졌다면 바로 공개했다고 생각하지 말아야 합니다. Next.js Markdown 블로그에서는 파일 생성, 콘텐츠 검증, 테마 검증, 빌드, 실행 프로세스 재시작, 공개 페이지 확인이 모두 필요합니다.

1. 콘텐츠 검증

npm run test:content는 Markdown 구조와 frontmatter가 프로젝트 규칙에 맞는지 확인합니다. 이 단계에서 제목 누락, 날짜 형식 오류, 카테고리 누락 같은 문제를 잡을 수 있습니다.

2. 테마 검증

npm run test:theme는 글 하나와 직접 관련 없어 보일 수 있지만, 목록 카드나 카테고리 페이지가 새 frontmatter를 처리하는 과정에서 깨지는 문제를 발견할 수 있습니다.

3. 빌드와 산출물 확인

npm run build가 성공해야 Next.js가 새 글을 정적 또는 서버 산출물에 반영합니다. 빌드 후에는 .next 안에서 새 slug가 포함됐는지도 확인하면 좋습니다. 파일은 있는데 빌드 산출물에 없다면 공개 URL 검증은 실패할 가능성이 큽니다.

공개 검증까지 캘린더에 포함하기

콘텐츠 캘린더는 작성 예정표에서 끝나지 않습니다. 운영 관점에서는 “공개 사이트에서 실제로 보이는가”까지 캘린더의 상태입니다. Futory에서는 다음 URL들을 확인해야 합니다.

• /posts/<slug> 상세 페이지
• / 홈 목록
• /posts 전체 글 목록
• /vibe-coding 카테고리 목록

캐시 때문에 오래된 응답이 보일 수 있으므로 cache-busting query string과 Cache-Control: no-cache 헤더를 함께 쓰는 편이 안전합니다. 자동화 보고서에는 단순히 “빌드 성공”이 아니라 “상세 URL 200, 목록에서 오늘 날짜 또는 slug 확인”처럼 검증 결과가 남아야 다음 장애 대응이 쉬워집니다.

자주 묻는 질문

콘텐츠 캘린더를 별도 파일로 만들어야 하나요?

처음부터 별도 파일이 필요하지는 않습니다. Futory처럼 frontmatter가 잘 정리된 Markdown 블로그라면 content/posts 폴더 자체가 기본 캘린더 역할을 합니다. 다만 시리즈 기획이나 장기 주제 분배가 필요해지면 별도 content-calendar.md를 추가해도 좋습니다.

같은 날짜 글이 이미 있으면 새 주제로 바꿔서 올려도 되나요?

자동화에서는 그러지 않는 편이 안전합니다. 하루 한 편이라는 규칙을 지켜야 재시도, 중복 실행, 부분 실패 상황에서도 운영 상태를 이해하기 쉽습니다. 추가 글이 필요하면 별도 수동 배포로 다루는 것이 좋습니다.

AI가 최근 글과 비슷한 주제를 고르면 어떻게 하나요?

최근 파일의 제목과 slug를 먼저 읽게 하고, 새 글의 역할을 한 문장으로 구분하게 만들면 좋습니다. “빌드 체크리스트”가 이미 있다면 다음 글은 “빌드 전 중복 방지”처럼 단계나 독자 문제를 달리 잡는 방식입니다.

결론

AI 블로그 자동화의 품질은 좋은 문장만으로 결정되지 않습니다. 오늘 날짜 중복을 막고, 최근 주제와 겹치지 않게 하고, Markdown frontmatter를 지키고, 빌드와 공개 URL까지 확인하는 운영 루틴이 함께 있어야 합니다. Futory의 Next.js Markdown 구조에서는 content/posts를 콘텐츠 캘린더로 활용하고, 날짜 기반 중복 방지와 공개 검증을 자동화 앞단과 뒷단에 배치하는 것이 가장 실용적인 방법입니다.