AI 블로그 자동화에서 원천 자료를 하나로 고정하는 법

요약

AI 블로그 자동화에서 가장 자주 생기는 혼선은 “무엇이 오늘 발행의 기준인가”가 흐려질 때 발생합니다. 원고 초안, Markdown 파일, 빌드 산출물, 공개 URL, 운영 보고서가 서로 다른 상태를 말하면 자동화는 같은 글을 다시 만들거나, 이미 공개된 글을 누락으로 판단할 수 있습니다. Futory처럼 content/posts/*.md를 기준으로 Next.js가 페이지를 만드는 구조에서는 오늘 날짜의 Markdown 파일 하나를 source of truth로 고정하는 편이 가장 단순하고 안전합니다.

이 글은 Futory의 바이브코딩 운영 관점에서 원천 자료를 고정하는 루틴을 정리합니다. 핵심은 작성 전에 기존 날짜와 최근 주제를 확인하고, 작성 중에는 frontmatter와 slug를 일관되게 만들며, 작성 후에는 테스트·빌드·공개 검증 결과를 같은 slug에 연결하는 것입니다. 이렇게 하면 크론이 반복 실행되어도 오늘의 발행 상태를 한눈에 판단할 수 있고, 문제가 생겼을 때도 새 글을 또 만드는 대신 끊긴 단계를 점검할 수 있습니다.

source of truth가 필요한 이유

자동화는 빠르지만 맥락을 잃으면 빠르게 잘못된 일을 반복합니다. 특히 매일 발행되는 블로그는 날짜, 주제, 파일명, 공개 링크가 조금씩 겹치기 때문에 기준점이 없으면 중복과 누락을 구분하기 어렵습니다. 오늘 날짜 글이 이미 있는데 공개 목록이 늦게 갱신된 상황과, 실제로 파일이 없는 상황은 전혀 다른 문제입니다. 기준이 없으면 둘 다 “발행 안 됨”으로 보일 수 있습니다.

Markdown 파일을 기준으로 삼는 장점

Futory에서는 Markdown 파일이 가장 좋은 기준점입니다. 파일 안에는 title, description, date, category, tags가 있고, 파일명은 곧 공개 URL의 slug가 됩니다. 즉 하나의 파일만 읽어도 운영자가 알아야 할 대부분의 정보가 들어 있습니다. 데이터베이스나 외부 CMS 상태를 따로 맞추는 구조보다 단순하며, Git이 없는 live deployment 폴더에서도 백업과 검증을 통해 안전하게 운영할 수 있습니다.

보고서와 공개 URL은 파일의 파생 신호다

운영 보고서는 별도의 진실이 아니라 파일과 빌드 결과를 설명하는 기록이어야 합니다. 공개 URL도 slug에서 파생된 결과입니다. 그래서 보고서에는 “오늘 글을 만들었다”가 아니라 “어떤 파일을 만들었고, 어떤 slug가 빌드 산출물에 들어갔으며, 어떤 공개 URL이 200을 반환했다”처럼 연결된 증거를 남기는 편이 좋습니다. 이 방식은 다음 실행이 같은 상태를 재확인할 때도 유용합니다.

작성 전에는 기준을 먼저 좁힌다

새 글을 쓰기 전에 가장 먼저 해야 할 일은 오늘 날짜의 기존 글이 있는지 확인하는 것입니다. frontmatter의 date: "YYYY-MM-DD"와 파일명 검색을 함께 사용하면 수동으로 만든 글도 놓칠 가능성이 줄어듭니다. 오늘 글이 있으면 새 파일을 만들지 않는 것이 원칙입니다. 자동화의 목표는 매시간 무언가를 생성하는 것이 아니라, 평일 하루 한 편을 정확히 발행하는 것입니다.

최근 글은 주제 중복을 막는 참고 자료다

날짜 중복이 없다고 해서 곧바로 새 글을 쓰면 주제 중복이 생길 수 있습니다. 최근 Futory 글들은 날짜 메타데이터, 배포 신호, 파일 계약, 운영 알림, 재시도 런북처럼 AI 블로그 운영의 실무 문제를 다룹니다. 오늘 글은 이 흐름을 이어가되, 같은 결론을 반복하기보다 “원천 자료를 어디에 둘 것인가”라는 관점으로 좁히는 것이 좋습니다. 이렇게 하면 블로그 전체가 하나의 운영 매뉴얼처럼 쌓입니다.

백업은 기준 고정의 첫 증거다

live content tree에 새 파일을 추가하기 전에는 반드시 백업을 남겨야 합니다. 백업은 단순한 보험이 아니라, 변경 전 기준 상태를 보존했다는 증거입니다. 나중에 새 글의 frontmatter가 잘못되었거나 빌드가 실패하더라도, 어떤 상태에서 작업을 시작했는지 되돌아볼 수 있습니다. 자동화가 사람보다 안정적으로 보이려면 이런 작은 보수성이 필요합니다.

작성 후에는 같은 slug로 모든 신호를 연결한다

새 글이 만들어지면 검증의 중심은 slug입니다. 콘텐츠 테스트는 파일 형식과 필수 섹션을 확인하고, 테마 테스트는 표시 규칙과 충돌하지 않는지 확인합니다. 빌드는 Next.js가 새 Markdown을 처리할 수 있는지 보여 줍니다. 여기에 .next 산출물에서 slug를 찾으면 “오늘 파일이 실제 빌드에 들어갔다”는 연결이 생깁니다.

상세 페이지와 목록 페이지를 분리해 본다

공개 검증에서는 /posts/<slug> 상세 페이지가 200인지 확인하는 것과 홈, /posts, /vibe-coding 목록에 오늘 날짜나 slug가 보이는지 확인하는 것을 나누어야 합니다. 상세 페이지가 열리면 직접 접근 가능성은 확인된 것이고, 목록에 보이면 독자가 발견할 수 있다는 뜻입니다. 둘 중 하나만 성공한 경우에는 캐시, 정렬, 프로세스 재시작, 배포 경로를 별도로 점검해야 합니다.

실패해도 기준 파일은 바꾸지 않는다

빌드나 공개 검증이 실패했다고 해서 같은 날짜의 새 글을 다시 만들면 안 됩니다. 이미 오늘 날짜 파일이 있다면 그 파일이 기준입니다. 다음 작업은 그 파일을 수정하거나, 빌드 로그를 확인하거나, PM2 재시작과 공개 캐시를 점검하는 방향이어야 합니다. source of truth를 유지하면 실패 대응도 작고 안전해집니다.

운영자가 바로 적용할 수 있는 체크리스트

1. KST 기준 오늘이 평일인지 확인한다.

2. 오늘 날짜가 frontmatter나 파일명에 이미 있는지 확인한다.

3. 최근 글 제목과 주제를 읽어 겹치는 주제를 피한다.

4. content/posts를 백업한다.

5. 영어 kebab-case slug로 새 Markdown 파일 하나만 만든다.

6. 콘텐츠 테스트, 테마 테스트, 빌드를 순서대로 실행한다.

7. .next에서 slug가 확인되는지 본다.

8. PM2 재시작 뒤 공개 상세와 목록을 cache-busting 요청으로 확인한다.

9. 보고서에는 파일, URL, 선택 시간, 검증 결과를 같은 slug 기준으로 남긴다.

이 체크리스트의 목적은 자동화를 복잡하게 만드는 것이 아닙니다. 오히려 매번 판단해야 할 일을 줄이는 데 있습니다. 기준을 고정하면 글 작성은 더 자유로워지고, 운영 확인은 더 짧아집니다.

자주 묻는 질문

초안 문서와 Markdown 파일 중 무엇을 기준으로 해야 하나요?

발행 자동화에서는 최종 Markdown 파일을 기준으로 삼는 것이 안전합니다. 초안은 생각을 모으는 단계이고, 공개 사이트가 실제로 읽는 입력은 content/posts/*.md입니다. 초안의 내용이 좋더라도 frontmatter, slug, 날짜가 최종 파일에 반영되지 않으면 운영 자동화는 그것을 발행 상태로 판단할 수 없습니다.

공개 사이트에는 보이는데 로컬 파일 기준과 다르면 어떻게 하나요?

먼저 중복 발행을 멈추고 어떤 경로가 실제 배포 경로인지 확인해야 합니다. Futory에서는 배포 경로의 Markdown 파일, 빌드 산출물, PM2 프로세스, 공개 URL이 같은 slug를 가리키는지 보는 것이 우선입니다. 공개 상태와 로컬 상태가 어긋나면 새 글을 만들기보다 경로와 런타임을 맞추는 작업이 필요합니다.

매일 같은 형식이면 글이 단조로워지지 않나요?

운영 형식과 글의 내용은 다릅니다. frontmatter, 섹션 구조, 검증 흐름은 안정적으로 유지하되, 매일 다루는 문제와 사례는 달라질 수 있습니다. 오히려 형식이 일정하면 독자는 필요한 정보를 빠르게 찾고, 운영자는 자동화 상태를 더 쉽게 검증할 수 있습니다.

결론

Futory의 AI 블로그 자동화에서 source of truth는 거창한 시스템이 아니라 오늘 날짜의 Markdown 파일 하나에서 시작됩니다. 그 파일이 날짜, 제목, 설명, 태그, slug를 담고 있고, 테스트와 빌드와 공개 URL이 같은 slug로 연결될 때 발행 상태는 명확해집니다.

바이브코딩은 빠르게 만들고 검증하는 흐름에 강하지만, 반복 발행에서는 기준을 고정하는 습관이 필요합니다. 원천 자료를 하나로 두면 자동화는 중복을 피하고, 운영자는 실패 지점을 빠르게 찾을 수 있습니다. 결국 좋은 AI 블로그 자동화는 더 많은 파일을 만드는 시스템이 아니라, 오늘의 한 파일을 끝까지 책임지는 시스템입니다.