AI 블로그 자동화에서 원자적 Markdown 작성 루틴을 운영하는 법

요약

Futory 같은 Next.js Markdown 블로그를 AI 에이전트로 운영할 때 가장 안전한 변경 단위는 “새 글 파일 하나”입니다. 자동화가 기존 글을 수정하거나 여러 파일을 동시에 바꾸기 시작하면, 문제 발생 시 원인을 찾기 어려워지고 되돌릴 범위도 커집니다. 원자적 Markdown 작성 루틴은 새 파일 하나를 만들기 전 백업을 남기고, frontmatter와 본문 구조를 검증한 뒤, 테스트와 빌드와 공개 확인을 순서대로 통과시키는 작은 운영 규칙입니다.

이 방식은 글쓰기 속도를 늦추기 위한 장치가 아닙니다. 오히려 AI가 빠르게 콘텐츠를 만들 수 있도록 변경 경계를 작게 고정하는 안전장치입니다. 오늘 날짜 중복 검사, 최근 주제 확인, 백업, 단일 파일 생성, .next 산출물 확인, PM2 재시작, no-cache 공개 검증을 한 줄 흐름으로 묶으면 무인 발행도 사람이 추적할 수 있는 작업이 됩니다.

원자적 작성이 필요한 이유

Markdown 블로그는 파일 시스템이 곧 콘텐츠 관리 시스템입니다. 파일 하나의 이름, frontmatter, 본문 구조가 라우트와 목록과 검색 메타데이터에 영향을 줍니다. 그래서 “잠깐 고친다”는 작은 수정도 운영 환경에서는 실제 배포 변경입니다.

변경 범위가 작아야 실패가 읽힌다

새 글 하나만 추가했다면 빌드 실패가 났을 때 확인할 대상이 명확합니다. 방금 만든 Markdown의 YAML, 제목, 날짜, 태그, 링크, 코드 블록을 먼저 보면 됩니다. 반대로 기존 글 여러 개를 함께 수정했다면 어느 파일이 실패를 만들었는지 다시 조사해야 합니다. 무인 크론에서는 이 차이가 큽니다. 실패 보고가 곧 복구 지시서가 되어야 하기 때문입니다.

기존 콘텐츠를 보존하는 것이 신뢰다

Futory의 반복 발행 목적은 매일 새 운영 지식을 쌓는 것입니다. 과거 글을 자동으로 고치기 시작하면 독자는 같은 URL에서 내용이 예고 없이 바뀌는 경험을 할 수 있고, 운영자는 어떤 날짜의 지식이 언제 변했는지 추적하기 어렵습니다. 따라서 평일 발행 루틴에서는 기존 파일을 읽어 스타일과 주제를 참고하되, 수정 대상은 새 Markdown 파일 하나로 제한하는 편이 안전합니다.

Futory에서 적용하는 파일 생성 경계

원자적 작성 루틴은 작성 전, 작성 중, 작성 후의 경계를 분리하면 실무에 쉽게 들어갑니다.

작성 전에는 중복과 백업을 먼저 확인한다

첫 번째 단계는 KST 오늘 날짜 글이 이미 있는지 확인하는 것입니다. frontmatter의 date나 파일명에 오늘 날짜가 있으면 새 글을 만들지 않습니다. 두 번째 단계는 최근 글의 제목, 설명, 태그를 읽어 주제 중복을 피하는 것입니다. 세 번째 단계는 /opt/futory/content/posts 전체를 압축 백업하는 것입니다. 새 글 하나만 추가하더라도 백업이 먼저 있으면 도구 오류나 실수 발생 시 되돌릴 기준점이 생깁니다.

작성 중에는 새 파일 하나만 만든다

파일명은 영어 kebab-case slug로 정하고, frontmatter는 현재 테마가 기대하는 필드만 사용합니다. title, description, date, category, tags가 정확하면 목록과 상세 페이지가 같은 글을 해석하기 쉽습니다. 본문은 한국어로 작성하고 ## 요약, 여러 H2와 H3, ## 자주 묻는 질문, ## 결론을 포함해야 합니다. 이 구조는 독자에게도 좋고, 자동화가 콘텐츠 계약을 검증하기에도 좋습니다.

작성 후에는 산출물과 공개 표면을 모두 본다

파일이 생겼다고 발행이 끝난 것은 아닙니다. npm run test:content, npm run test:theme, npm run build를 순서대로 실행하고, 실패하면 PM2를 재시작하지 않아야 합니다. 빌드가 성공하면 .next 산출물 안에서 새 slug가 들어갔는지 확인합니다. 그다음 런타임을 재시작하고 상세 페이지와 홈, 전체 글 목록, 바이브코딩 목록에서 오늘 날짜나 slug를 no-cache 요청으로 확인해야 합니다.

운영 보고서에 남길 증거

원자적 작성 루틴의 마지막 단계는 짧은 증거 장부입니다. 선택된 발행 시간, 현재 KST 시각, 중복 검사 결과, 백업 경로, 새 파일 경로, 제목, 날짜, slug, 본문 글자 수, H2와 H3 개수, 테스트와 빌드 결과, PM2 재시작 결과, 공개 URL 검증 결과를 남기면 충분합니다.

증거는 다음 실행의 입력이 된다

오늘 보고서에 남긴 제목과 slug는 내일의 주제 중복 방지에 쓰입니다. 빌드와 공개 검증 결과는 다음 장애 분석의 기준이 됩니다. 즉 보고서는 단순한 완료 메시지가 아니라 다음 자동화가 읽을 수 있는 운영 컨텍스트입니다.

자주 묻는 질문

임시 파일을 만들고 나중에 옮기는 방식이 더 안전하지 않나요?

복잡한 편집기나 긴 생성 과정이 있다면 임시 파일을 쓰는 방식도 가능합니다. 다만 Futory의 현재 루틴처럼 새 Markdown 파일 하나를 완성된 내용으로 쓰고 즉시 테스트하는 흐름에서는 백업과 단일 파일 경계가 더 단순하고 충분합니다. 중요한 것은 기존 파일을 수정하지 않고, 실패 시 어느 파일을 제거하면 되는지 명확하게 유지하는 것입니다.

새 글 하나만 추가해도 전체 빌드를 해야 하나요?

네. Markdown 하나가 목록 정렬, 카테고리 필터, 정적 생성 경로, 메타데이터에 영향을 줄 수 있기 때문입니다. 콘텐츠 테스트만 통과해도 테마나 빌드 단계에서 문제가 드러날 수 있으므로 전체 검증을 생략하지 않는 편이 좋습니다.

공개 목록까지 꼭 확인해야 하나요?

상세 URL이 200을 반환해도 홈이나 /posts, /vibe-coding 목록에 빠질 수 있습니다. category 값, 날짜 정렬, 캐시, 런타임 재시작 문제가 목록에서 드러나는 경우가 많습니다. 그래서 공개 검증은 상세 페이지와 목록 페이지를 함께 보는 것이 안전합니다.

결론

원자적 Markdown 작성 루틴은 AI 블로그 자동화를 단순하고 복구 가능한 운영으로 만드는 방법입니다. Futory에서는 오늘 날짜 중복 방어를 먼저 수행하고, posts 백업을 만든 뒤, 새 파일 하나만 추가하고, 테스트와 빌드와 공개 검증을 차례대로 통과시키는 흐름이면 충분합니다. 변경 범위를 작게 유지할수록 실패는 더 읽기 쉬워지고, 성공은 더 신뢰할 수 있는 발행 기록으로 남습니다.