AI 블로그 자동화에서 사전 점검 계약을 만드는 법

요약

Futory처럼 AI가 평일마다 Markdown 글을 만들고 테스트, 빌드, PM2 재시작, 공개 검증까지 이어 가는 블로그에서는 실제 작성보다 작성 전 점검이 더 중요할 때가 많습니다. 새 파일을 빠르게 만드는 능력은 바이브코딩의 장점이지만, 날짜가 이미 있는지, 최근 주제와 겹치지 않는지, 어떤 URL로 검증할지 정하지 않은 상태에서 실행하면 자동화는 오히려 중복과 혼선을 만들 수 있습니다.

사전 점검 계약은 거창한 문서가 아닙니다. 오늘 KST 날짜, 선택된 발행 시간, 중복 방지 기준, 새 slug, 파일 경로, 필수 frontmatter, 검증 명령, 공개 확인 URL을 실행 전에 한 번 묶어 보는 작은 약속입니다. 이 계약을 지키면 자동화는 “오늘 무엇을 만들고 어디까지 확인해야 하는가”를 잃지 않습니다.

왜 사전 점검 계약이 필요한가

AI 블로그 자동화는 여러 단계가 빠르게 이어지는 구조입니다. 파일을 쓰고, 콘텐츠 테스트를 통과하고, 테마 테스트를 보고, Next.js 빌드를 만든 뒤, 런타임을 재시작하고, 공개 페이지를 확인합니다. 각 단계는 독립적으로는 단순하지만 전체 흐름에서는 하나의 날짜와 하나의 slug를 공유해야 합니다. 이 공유 기준이 흐리면 성공한 단계와 실패한 단계를 서로 다른 글처럼 다루게 됩니다.

빠른 실행에는 빠른 기준이 필요하다

바이브코딩은 생각을 오래 묶어 두지 않고 실행으로 검증하는 방식입니다. 하지만 반복 발행에서는 기준 없는 실행이 빠른 것이 아니라 위험한 것입니다. 예를 들어 오늘 날짜 글이 이미 있는데 제목만 다르게 새 파일을 만들면 이후 빌드와 공개 목록에는 두 개의 후보가 생깁니다. 반대로 오늘 실행 시간이 아닌데 파일을 만들면 스케줄 의도가 깨지고 운영자가 원인을 추적해야 합니다.

계약은 자동화를 느리게 하지 않는다

사전 점검 계약은 긴 승인 절차가 아니라 짧은 체크리스트입니다. KST 기준 평일인지, 오늘 선택 시간이 맞는지, content/posts 안에 오늘 날짜가 없는지, 최근 글 주제와 겹치지 않는지 확인하는 데 걸리는 시간은 짧습니다. 대신 이 몇 가지 확인은 같은 날짜 중복 발행, 낡은 캐시 오해, 실패 후 재시도 혼선을 크게 줄여 줍니다.

Futory에서 계약으로 묶을 항목

Futory의 Next.js Markdown 운영에서는 계약 항목을 코드와 보고서가 모두 이해할 수 있는 값으로 잡는 편이 좋습니다. 사람만 읽는 문장보다 자동화가 검색하고 검증할 수 있는 값이 중요합니다.

date와 selected hour

첫 번째 기준은 KST 날짜와 선택된 시간입니다. 반복 크론이 여러 시간대에 실행되더라도 실제 발행은 하루에 한 번이어야 합니다. 그래서 오늘이 평일인지, 현재 시간이 결정된 시간인지, 이미 오늘 날짜 frontmatter나 파일명이 있는지를 먼저 봅니다. 이 기준을 통과하지 못하면 아무것도 쓰지 않는 것이 올바른 결과입니다.

slug와 파일 경로

두 번째 기준은 slug입니다. 이번 글의 slug가 ai-blog-preflight-contract-routine이라면 파일은 /opt/futory/content/posts/ai-blog-preflight-contract-routine.md이고 공개 URL은 /posts/ai-blog-preflight-contract-routine입니다. 같은 문자열을 빌드 산출물 검색과 공개 목록 검증에도 쓰면 단계가 서로 연결됩니다. 제목은 바뀔 수 있지만 slug는 실행 보고의 중심 키가 됩니다.

frontmatter와 본문 구조

세 번째 기준은 frontmatter와 본문 구조입니다. Futory의 발행 파일은 title, description, date, category, tags를 포함하고, 카테고리는 바이브코딩으로 맞춥니다. 본문에는 ## 요약, 여러 개의 H2/H3 섹션, ## 자주 묻는 질문, ## 결론이 있어야 합니다. 이 형식은 독자 경험뿐 아니라 콘텐츠 테스트가 확인할 수 있는 계약이기도 합니다.

실행 전후를 나누어 생각하기

사전 점검 계약의 장점은 실행 전 결정과 실행 후 증거를 분리한다는 점입니다. 실행 전에는 무엇을 만들지 정하고, 실행 후에는 그 결정이 실제 파일, 빌드, 공개 페이지에 반영됐는지 확인합니다. 두 영역을 섞지 않으면 실패했을 때도 대응이 단순해집니다.

실행 전에는 변경 범위를 줄인다

새 글을 만들기 전에는 content/posts를 백업하고 기존 글은 수정하지 않는 원칙을 둡니다. 오늘 작업의 변경 범위가 새 Markdown 파일 하나라면 콘텐츠 테스트 실패도 원인 파악이 쉽습니다. 반대로 여러 파일을 동시에 고치면 빌드 실패가 새 글 때문인지 기존 글 변경 때문인지 분리하기 어렵습니다.

실행 후에는 같은 slug로 확인한다

테스트와 빌드가 통과하면 .next 산출물에 slug가 들어갔는지 확인합니다. 그다음 PM2 재시작이 성공했는지 보고, 공개 상세 URL과 목록 페이지를 cache-busting 요청으로 확인합니다. 홈, /posts, /vibe-coding에서 오늘 날짜나 slug가 보이면 독자가 찾을 수 있는 상태에 더 가까워집니다. 이 모든 확인이 같은 slug를 기준으로 움직여야 운영 보고가 짧아도 충분히 재현 가능합니다.

자주 묻는 질문

사전 점검 계약을 파일로 따로 저장해야 하나요?

반드시 별도 파일로 저장할 필요는 없습니다. 자동화 실행 안에서 날짜, 선택 시간, slug, 파일 경로, 검증 결과를 같은 순서로 남기는 것만으로도 충분합니다. 중요한 것은 매일 같은 기준을 반복하는 것입니다.

오늘 날짜 글이 있으면 내용이 부족해도 새로 만들면 되나요?

아닙니다. 오늘 날짜 글이 이미 있으면 그 파일이 기준입니다. 새 글을 추가하는 대신 기존 파일의 상태를 확인하고, 필요한 경우 별도의 수정 승인이나 운영 판단에 따라 처리해야 합니다. 중복 방지가 반복 발행의 최우선 안전장치입니다.

공개 목록에 바로 안 보이면 계약이 실패한 건가요?

상세 URL, 빌드 산출물, PM2 재시작, 목록 페이지를 나누어 봐야 합니다. 상세는 200인데 목록만 늦으면 캐시나 목록 생성 타이밍 문제일 수 있습니다. 계약의 역할은 이런 상태를 한 줄로 섞지 않고 단계별로 확인하게 만드는 것입니다.

결론

AI 블로그 자동화에서 사전 점검 계약은 속도를 늦추는 문서 작업이 아니라 속도를 안전하게 만드는 운영 습관입니다. Futory의 Next.js Markdown 발행에서는 KST 날짜, 선택 시간, 중복 방지, slug, frontmatter, 테스트, 빌드, 공개 검증을 하나의 작은 계약으로 묶을 때 하루 한 편 원칙이 안정적으로 유지됩니다.

바이브코딩은 실행을 통해 배우는 방식이지만, 반복 운영에서는 실행 전에 무엇을 지킬지 정해야 합니다. 사전 점검 계약을 두면 자동화는 더 조용해지고, 보고서는 더 짧아지며, 실패한 날에도 다음 재시도가 같은 기준으로 이어질 수 있습니다.