AI 블로그 자동화에서 발행 입력값 체크섬을 남기는 법

요약

Futory 같은 Next.js Markdown 블로그를 AI 에이전트로 자동 발행할 때 중요한 것은 글을 잘 쓰는 능력만이 아닙니다. 매 실행이 어떤 입력값을 보고 판단했는지 남겨야 재시도, 장애 분석, 중복 방지가 쉬워집니다. 여기서 입력값 체크섬은 반드시 암호학적 해시를 뜻하지 않습니다. 오늘 날짜, 선택된 발행 시간, 최근 글 목록, 새 글의 slug, 테스트 명령, 공개 검증 URL을 하나의 작은 묶음으로 고정해 “이번 실행은 무엇을 근거로 움직였는가”를 설명하는 운영 장부에 가깝습니다.

이 루틴을 두면 무인 크론이 같은 날 다시 실행되더라도 왜 스킵했는지, 새 글을 만들었다면 어떤 기준으로 주제를 골랐는지, 빌드 실패가 글 내용 때문인지 환경 때문인지 더 빠르게 구분할 수 있습니다.

왜 발행 입력값을 고정해야 할까

AI 블로그 자동화는 매번 비슷한 작업을 반복하지만, 실제 입력은 조금씩 달라집니다. 날짜가 바뀌고, 최근 글이 늘어나며, 의존성 상태나 공개 캐시도 변합니다. 이 변화가 기록되지 않으면 “어제는 됐는데 오늘은 왜 실패했는지”를 추적하기 어렵습니다.

재시도 때 같은 결정을 유지한다

평일 14시부터 18시 사이에 하나의 시간을 결정적으로 고르는 규칙은 좋은 예입니다. 같은 날짜에 같은 선택 시간이 나오면, 크론이 여러 번 실행되어도 한 번만 실제 발행을 시도합니다. 이때 보고서에 KST 날짜, 현재 시간, 선택된 시간을 함께 남기면 중복 발행 방어가 눈에 보입니다.

주제 중복을 줄인다

최근 글의 제목과 설명을 훑은 뒤 새 주제를 고르는 과정도 입력값입니다. 예를 들어 최근에 frontmatter 품질, 환경 점검, 공개 계약, 결정적 발행 창을 다뤘다면 오늘은 발행 판단의 입력 묶음 자체를 기록하는 쪽으로 좁힐 수 있습니다. 이처럼 최근 글 목록을 topic fingerprint로 보면 자동화가 비슷한 운영 글만 반복하는 문제를 줄입니다.

Futory에서 적용하는 입력값 묶음

Futory의 발행 루틴에서는 다음 항목을 작은 체크리스트로 다루면 충분합니다.

시간과 중복 방어

첫 번째 묶음은 KST 날짜, 요일, 현재 시간, 선택된 발행 시간, 같은 날짜 글 존재 여부입니다. 이 값은 실행 여부를 결정하므로 가장 먼저 확인해야 합니다. 같은 날짜가 frontmatter나 파일명에 이미 있으면 새 글을 만들지 않고 기존 파일과 제목을 보고하는 편이 안전합니다.

콘텐츠 컨텍스트

두 번째 묶음은 최근 Markdown 파일의 제목, 설명, 태그, slug입니다. AI가 새 글을 작성할 때 이 목록은 금지 주제이자 스타일 샘플입니다. 문체는 실무적이고, 설명문은 프로젝트 맥락과 독자 효용을 함께 담으며, 파일명은 영어 kebab-case로 유지합니다.

검증 계약

세 번째 묶음은 npm run test:content, npm run test:theme, npm run build, .next artifact 확인, PM2 재시작, 공개 URL 200 확인입니다. 글을 만들었다는 사실보다 이 검증 계약을 끝까지 통과했는지가 운영적으로 더 중요합니다.

실무 루틴 예시

새 글을 쓰기 전에는 먼저 posts 디렉터리를 백업합니다. 그다음 오늘 날짜 글이 없는지 확인하고, 최근 글의 frontmatter를 읽어 주제를 정합니다. 새 Markdown 파일은 하나만 추가하고 기존 파일은 수정하지 않습니다. 이후 콘텐츠 테스트, 테마 테스트, 빌드를 순서대로 실행합니다. 하나라도 실패하면 PM2를 재시작하지 않고 멈춥니다.

빌드가 성공하면 .next 결과물 안에서 새 slug가 실제로 포함되었는지 확인합니다. 마지막으로 PM2를 재시작하고, 캐시 무효화 쿼리와 Cache-Control: no-cache 헤더를 사용해 상세 페이지와 목록 페이지를 확인합니다. 이 전체 과정이 하나의 입력값 체크섬과 결과 장부가 됩니다.

자주 묻는 질문

체크섬을 꼭 파일로 저장해야 하나요?

필수는 아닙니다. 크론 최종 보고서에 시간, 파일, slug, 검증 결과가 남는 것만으로도 작은 체크섬 역할을 합니다. 다만 장애가 잦거나 여러 에이전트가 함께 운영한다면 별도의 실행 로그 파일을 두는 것도 좋습니다.

AI가 알아서 판단하면 되는데 왜 이렇게 많이 기록하나요?

자동 판단은 편리하지만, 무인 발행에서는 설명 가능성이 더 중요합니다. 기록이 있어야 사람이 나중에 중복 방지, 빌드 실패, 공개 반영 지연을 빠르게 검토할 수 있습니다.

공개 페이지가 200이면 충분하지 않나요?

상세 페이지 200만으로는 부족합니다. 홈, 전체 글 목록, 카테고리 목록에 오늘 글이 보이는지도 확인해야 독자와 검색 엔진이 실제로 새 글을 발견할 수 있습니다.

결론

발행 입력값 체크섬은 거창한 시스템이 아니라, 무인 AI 발행이 어떤 조건을 보고 움직였는지 압축해서 남기는 습관입니다. Futory의 Next.js Markdown 운영에서는 시간 게이트, 중복 방어, 최근 주제, 새 slug, 테스트와 빌드, 공개 검증을 한 묶음으로 기록하면 충분합니다. 이 작은 장부가 쌓이면 매일의 바이브코딩 자동화는 더 예측 가능해지고, 실패했을 때도 어디서 멈췄는지 빠르게 찾을 수 있습니다.