AI 블로그 자동화에서 공개 검증 영수증을 남기는 법

요약

Futory처럼 AI가 Markdown 글을 만들고 Next.js 빌드와 PM2 재시작을 거쳐 공개하는 블로그에서는 “성공했다”는 말보다 “무엇을 확인했는가”가 더 중요합니다. 파일이 생겼다는 사실, 콘텐츠 테스트가 통과했다는 사실, .next 산출물에 slug가 들어갔다는 사실, 공개 URL이 200을 반환했다는 사실은 모두 다른 층의 증거입니다. 이 증거를 한데 묶어 두면 다음 실행에서 같은 날짜 글을 다시 만들지 않고, 어느 단계부터 이어 가야 하는지 빠르게 판단할 수 있습니다.

공개 검증 영수증은 복잡한 감사 문서가 아닙니다. 오늘 날짜, slug, 파일 경로, 백업 경로, 테스트 결과, 빌드 결과, PM2 재시작 결과, 상세 URL과 목록 페이지 확인 결과를 짧게 남기는 운영 기록입니다. 바이브코딩은 빠른 실행을 장점으로 하지만, 반복 발행에서는 빠른 증거 정리가 있어야 안전합니다. 이 글은 Futory의 일일 자동 발행에서 검증 영수증을 어떻게 남기면 좋은지 실무 기준으로 정리합니다.

공개 검증 영수증이 필요한 이유

자동화가 매일 같은 일을 반복하면 대부분의 날에는 조용히 끝납니다. 문제는 실패하거나 애매하게 성공한 날입니다. 빌드는 통과했지만 공개 목록에 보이지 않는 날, 상세 URL은 열리지만 홈에는 늦게 반영되는 날, PM2 재시작은 성공했지만 캐시가 낡은 응답을 보여 주는 날에는 단순한 성공/실패 라벨이 부족합니다.

한 줄 성공은 재시도에 약하다

“발행 완료”라는 한 줄만 남기면 다음 사람이 무엇을 믿어야 하는지 알기 어렵습니다. Markdown 파일은 있는지, 오늘 날짜 중복 검사는 통과했는지, 빌드 산출물에는 포함됐는지, 공개 URL은 어떤 상태였는지가 빠져 있기 때문입니다. 재시도 자동화도 같은 문제를 겪습니다. 오늘 날짜 파일이 이미 있는데 공개 확인만 실패한 상태라면 새 글을 만들면 안 됩니다. 검증 영수증은 이런 결정을 돕는 최소한의 단서입니다.

증거는 같은 slug로 묶어야 한다

Futory 운영에서는 slug가 가장 좋은 공통 키입니다. 파일명, 공개 URL, .next 검색어, 목록 페이지 포함 여부가 모두 같은 slug를 기준으로 움직입니다. 제목은 사람이 읽기 편하지만 약간 수정될 수 있고, 날짜는 하루 단위로만 구분됩니다. 반면 slug는 이번 발행 실행의 고유한 손잡이입니다. 검증 영수증에 slug를 반복해서 남기면 각 단계가 서로 다른 글을 보고 있는지 의심할 필요가 줄어듭니다.

Futory에서 남길 핵심 항목

검증 영수증은 길 필요가 없습니다. 다만 자동화와 사람이 모두 이해할 수 있는 항목을 빠뜨리지 않아야 합니다. 특히 live Markdown content tree를 직접 다루는 구조에서는 쓰기 전 백업과 쓰기 후 공개 검증을 분리해 기록하는 편이 안전합니다.

작성 전 항목

작성 전에는 KST 날짜와 선택된 발행 시간이 맞는지, 오늘 날짜가 frontmatter나 파일명에 이미 없는지 확인합니다. 중복이 있으면 아무 파일도 만들지 않는 것이 올바른 결과입니다. 중복이 없을 때만 최근 글의 주제를 훑고 새 주제를 정합니다. 이 단계의 영수증에는 선택 시간, 오늘 날짜, 중복 검사 결과, 새 slug 후보를 남기면 충분합니다.

작성 직후 항목

새 파일을 만들기 전에는 /opt/futory/content/posts를 백업합니다. 백업 경로가 남아 있으면 이후 테스트나 빌드 실패가 발생해도 이번 실행의 변경 범위를 좁힐 수 있습니다. 새 파일을 만든 뒤에는 파일 경로, title, description, date, category, tags가 의도대로 들어갔는지 확인합니다. 기존 글을 수정하지 않았다는 점도 중요한 운영 신호입니다.

빌드와 런타임 항목

콘텐츠 테스트, 테마 테스트, Next.js 빌드는 각각 별도로 기록합니다. 세 명령이 모두 성공한 뒤에는 .next 안에서 slug가 발견되는지 확인합니다. 이 확인은 “빌드가 성공했다”를 “오늘 글이 빌드 산출물에 들어갔다”로 바꾸는 작은 강화 단계입니다. 이후 PM2 재시작은 빌드 성공 이후에만 실행해야 하며, 실패하면 정확한 명령과 오류를 남겨야 합니다.

공개 페이지 확인 방법

공개 검증은 상세 페이지와 목록 페이지를 나누어 봐야 합니다. 상세 페이지 /posts/<slug>가 200을 반환하면 직접 접근은 가능한 상태입니다. 하지만 홈, /posts, /vibe-coding에 오늘 글이 보이지 않으면 독자가 일반 탐색으로 찾기 어렵습니다. 따라서 검증 영수증에는 상세 URL 상태와 각 목록의 slug 또는 날짜 포함 여부를 따로 남깁니다.

캐시를 고려한 요청

검증 요청에는 cache-busting query string과 Cache-Control: no-cache 헤더를 붙이는 습관이 좋습니다. 이것만으로 모든 캐시를 무력화할 수는 없지만, 오래된 응답을 보고 배포 실패로 착각할 가능성을 낮춥니다. 같은 slug로 여러 페이지를 확인하면 캐시 문제인지, 라우팅 문제인지, 목록 생성 문제인지 더 빨리 분리할 수 있습니다.

목록이 늦을 때의 판단

상세 URL은 200인데 목록에서 보이지 않는 경우에는 글을 다시 만들지 않습니다. 먼저 빌드 산출물과 PM2 재시작 상태를 확인하고, 목록 생성 규칙과 캐시를 봅니다. 오늘 날짜 파일이 이미 존재한다면 이후 작업의 기준은 새 파일 생성이 아니라 기존 slug의 공개 상태 확인입니다. 검증 영수증은 이 기준을 흔들리지 않게 해 줍니다.

자주 묻는 질문

검증 영수증을 별도 파일로 저장해야 하나요?

반드시 별도 파일이 필요한 것은 아닙니다. 크론 실행 보고서, 운영 로그, 배포 노트 어디든 같은 항목이 남아 있으면 됩니다. 중요한 것은 날짜, slug, 파일 경로, 테스트, 빌드, PM2, 공개 URL 확인이 같은 순서로 반복되는 것입니다.

공개 URL이 200이면 목록 검증은 생략해도 되나요?

생략하지 않는 편이 좋습니다. 상세 URL 200은 직접 링크 접근 가능성을 뜻하고, 홈이나 목록 노출은 독자가 발견할 수 있는지를 뜻합니다. 두 신호가 모두 있어야 발행 완료 판단이 더 안정적입니다.

실패한 날에는 같은 주제로 새 글을 만들면 되나요?

오늘 날짜 파일이 이미 있다면 새 글을 만들지 않아야 합니다. 실패 지점이 콘텐츠인지, 빌드인지, 런타임인지, 공개 캐시인지 확인한 뒤 같은 slug를 기준으로 이어 가는 것이 안전합니다. 중복 글은 문제 해결보다 정리를 더 어렵게 만듭니다.

결론

AI 블로그 자동화에서 공개 검증 영수증은 발행 속도를 늦추는 문서가 아니라 반복 운영을 안전하게 만드는 작은 증거 묶음입니다. Futory의 Next.js Markdown 흐름에서는 KST 날짜, slug, 백업, 파일 생성, 테스트, 빌드, PM2 재시작, 공개 상세와 목록 확인을 같은 기준으로 남길 때 재시도와 장애 판단이 쉬워집니다.

바이브코딩은 실행으로 배우는 방식이지만, 운영에서는 실행의 흔적을 읽을 수 있어야 합니다. 매일 한 편을 안정적으로 공개하려면 새 글을 잘 쓰는 것만큼 새 글이 실제 독자 화면에 도착했음을 확인하는 습관이 필요합니다. 검증 영수증은 그 습관을 가장 작고 반복 가능한 형태로 만드는 방법입니다.