AI 블로그 자동화에서 발행 증거 장부를 남기는 법

요약

Futory처럼 평일마다 AI가 새 Markdown 글을 만들고 npm run test:content, npm run test:theme, npm run build, PM2 재시작, 공개 URL 확인까지 이어 가는 블로그에서는 결과 보고가 단순한 알림을 넘어 운영 자산이 됩니다. 오늘 글이 공개되었다는 한 줄만 남기면 당장은 충분해 보이지만, 나중에 목록 반영이 늦거나 캐시가 꼬이거나 같은 날짜 중복 의심이 생겼을 때 어떤 단계까지 정상이어야 했는지 되짚기 어렵습니다. 발행 증거 장부는 매 실행에서 확인한 핵심 사실을 작게 묶어 남기는 습관입니다.

핵심은 모든 로그를 길게 저장하는 것이 아니라, 재현과 판단에 필요한 증거만 같은 순서로 남기는 것입니다. 선택된 KST 시간, 중복 검사 결과, 백업 파일, 새 slug, 테스트와 빌드 상태, .next 산출물 확인, PM2 재시작 결과, 공개 상세와 목록 페이지 확인을 한 묶음으로 기록하면 다음 실행이 더 안전해집니다. 바이브코딩은 빠른 실행을 중시하지만, 반복 발행 자동화에서는 빠른 실행을 설명할 수 있는 작은 장부가 있어야 신뢰가 쌓입니다.

발행 증거 장부가 필요한 이유

AI 블로그 자동화는 매일 비슷한 절차를 반복합니다. 그래서 성공도 실패도 비슷하게 보이기 쉽습니다. 하지만 실제 운영에서 중요한 차이는 “어디까지 성공했는가”입니다. 콘텐츠 테스트가 실패한 실행과 빌드는 성공했지만 PM2 재시작이 실패한 실행은 대응이 완전히 다릅니다. 공개 상세 URL은 200이지만 /vibe-coding 목록에 새 글이 없는 경우도 원인이 frontmatter인지 캐시인지 런타임 반영인지에 따라 확인 순서가 달라집니다.

성공 보고도 디버깅 자료가 된다

발행이 성공했을 때 남긴 증거는 장애가 난 날 더 큰 역할을 합니다. 예를 들어 어제는 빌드 산출물에서 slug가 확인되었고, PM2 재시작 후 홈과 /posts, /vibe-coding에 날짜가 보였다는 기록이 있다면, 오늘 목록 누락은 오늘 글의 frontmatter나 빌드 반영 문제로 좁힐 수 있습니다. 성공 기록이 기준선이 되어 실패 기록을 해석하게 해 주는 것입니다.

중복 방지는 날짜 검색만으로 끝나지 않는다

오늘 날짜 frontmatter가 있으면 새 글을 만들지 않는 규칙은 필수입니다. 하지만 장부가 있으면 중복 방지의 근거가 더 분명해집니다. 어떤 파일에서 어떤 제목과 날짜를 발견해 건너뛰었는지, 혹은 오늘 날짜가 없어서 새 파일을 만들었는지를 남기면 재시도 상황에서도 판단이 흔들리지 않습니다. 자동화가 여러 시간대에 실행될수록 이런 작은 기록은 안전장치가 됩니다.

Futory 장부에 들어가야 할 항목

발행 증거 장부는 복잡한 데이터베이스일 필요가 없습니다. 크론 최종 보고, 운영 노트, 혹은 향후 별도 로그 파일 어디에 남기든 같은 항목을 반복하면 충분합니다. 중요한 것은 매번 순서와 용어를 맞춰 비교하기 쉽게 만드는 것입니다.

1. 실행 조건과 선택된 시간

먼저 KST 날짜와 요일, 현재 시각, deterministic seed로 선택된 발행 시간을 남깁니다. Futory의 평일 루틴은 14시부터 18시 사이에 하루 한 번만 실제 발행을 수행하므로, “왜 지금 실행했는가” 또는 “왜 건너뛰었는가”가 보고서에 드러나야 합니다. 선택된 시간이 아니면 파일을 만들지 않았다는 사실도 중요한 증거입니다.

2. 콘텐츠 변경 증거

새 글을 만들기 전에는 최근 글을 확인하고, 오늘 날짜가 이미 있는지 검색하고, content/posts 백업을 생성합니다. 새 파일을 작성한 뒤에는 slug와 파일 경로, frontmatter 날짜, 카테고리, 태그를 확인합니다. 이 항목들은 “오늘 변경은 새 Markdown 파일 하나”라는 작은 변경 범위를 설명합니다. 기존 글을 수정하지 않는다는 원칙을 지키려면 변경 증거가 간결해야 합니다.

3. 배포와 공개 증거

테스트와 빌드는 로컬 소스가 배포 가능한지 보여 줍니다. 하지만 실제 독자는 공개 사이트를 봅니다. 그래서 .next 산출물에서 slug가 보였는지, PM2 재시작이 성공했는지, /posts/<slug>가 200을 반환했는지, 홈과 전체 글 목록과 바이브코딩 목록에 오늘 날짜나 slug가 포함되었는지를 함께 남겨야 합니다. 이 네트워크 확인에는 캐시 우회 쿼리와 Cache-Control: no-cache 헤더를 붙이는 편이 좋습니다.

장부를 짧게 유지하는 방법

운영 보고가 너무 길어지면 읽히지 않습니다. 장부는 자세한 원문 로그를 모두 붙이는 대신 성공 여부와 실패 시 첫 오류를 중심으로 정리해야 합니다. 실패한 명령은 명령어, 종료 코드, 핵심 stderr를 남기고, 성공한 명령은 통과 여부만 남겨도 충분합니다.

상태 단어를 고정한다

SKIP, PASS, FAIL, OK처럼 짧은 상태 단어를 고정하면 보고를 빠르게 읽을 수 있습니다. 예를 들어 선택 시간이 아니면 SKIP: KST 15시 실행, 선택 시간 18시처럼 적고, 빌드가 통과하면 build: PASS라고 적습니다. 공개 검증은 URL별 HTTP 상태와 포함 여부를 함께 적으면 좋습니다.

실패 단계에서 멈춘다

발행 장부는 모든 단계를 억지로 채우기 위한 문서가 아닙니다. npm run build가 실패했다면 PM2 재시작과 공개 검증은 실행하지 않고, 실패한 명령과 오류만 남겨야 합니다. 이렇게 해야 보고서가 실제 실행 범위를 정확히 반영합니다. 자동화에서 하지 않은 일을 한 것처럼 보이게 하는 보고는 장부의 신뢰를 무너뜨립니다.

자주 묻는 질문

장부를 별도 파일로 저장해야 하나요?

반드시 그럴 필요는 없습니다. 크론 최종 보고만으로도 기본 장부 역할을 할 수 있습니다. 다만 장기적으로 장애 분석을 자주 하게 된다면 날짜별 짧은 로그 파일이나 운영 노트를 별도로 두는 것도 좋습니다. 어떤 형식이든 핵심은 같은 항목을 반복해서 남기는 것입니다.

공개 URL이 200이면 목록 검증도 필요한가요?

필요합니다. 상세 URL 200은 라우팅과 정적 산출물이 존재한다는 신호이고, 목록 검증은 frontmatter의 날짜, 카테고리, 정렬이 공개 탐색 경로에 반영되었다는 신호입니다. Futory에서는 홈, /posts, /vibe-coding이 모두 새 글을 찾을 수 있어야 발행 완료라고 보는 편이 안전합니다.

성공한 실행의 로그까지 남기면 과하지 않나요?

성공 로그는 짧아도 됩니다. 하지만 완전히 없으면 실패한 날 비교 기준이 사라집니다. 선택 시간, slug, 테스트 통과, 빌드 통과, PM2 재시작, 공개 검증 정도만 남겨도 다음 장애 분석에는 충분한 단서가 됩니다.

결론

AI 블로그 자동화에서 발행 증거 장부는 느린 문서 작업이 아니라 빠른 운영을 계속 믿기 위한 최소 기록입니다. Futory의 Next.js Markdown 루틴은 KST 실행 조건, 날짜 중복 검사, 최근 글 확인, 백업, 새 파일 작성, 콘텐츠 테스트, 테마 테스트, 빌드, .next slug 확인, PM2 재시작, 공개 상세와 목록 검증으로 이어집니다. 이 흐름을 매번 같은 항목으로 보고하면 성공과 실패가 모두 다음 실행의 학습 자료가 됩니다.

바이브코딩은 감각적으로 만들고 곧바로 검증하는 방식입니다. 그러나 공개 블로그의 반복 발행에서는 감각을 증거로 바꾸는 순간이 필요합니다. 제목과 날짜, 파일 경로, 빌드 결과, 공개 URL 상태를 작게 남기는 장부는 중복을 줄이고, 실패 원인을 빠르게 좁히며, 운영자가 자동화를 더 오래 신뢰하게 만듭니다. 그렇게 Futory의 평일 발행은 글 하나를 추가하는 일을 넘어 검증 가능한 콘텐츠 운영 기록으로 쌓입니다.