AI 블로그 자동화에서 공개 증거 묶음을 관리하는 법

요약

Futory처럼 AI가 평일마다 Markdown 글을 만들고 Next.js 빌드와 PM2 재시작까지 이어 가는 블로그에서는 “글을 썼다”와 “공개되었다”를 구분해야 합니다. 파일이 /content/posts에 생긴 것만으로는 독자가 읽을 수 있다는 보장이 없습니다. 콘텐츠 테스트를 통과했는지, 빌드 산출물에 slug가 들어갔는지, 런타임이 새 빌드를 바라보는지, 공개 상세 URL과 목록 페이지가 실제로 응답하는지를 함께 확인해야 합니다.

공개 증거 묶음은 이 확인 결과를 하나의 기준으로 모으는 운영 습관입니다. 제목, 날짜, 파일 경로, slug, 백업 경로, 테스트 결과, 빌드 결과, PM2 재시작 결과, 공개 URL 상태를 같은 순서로 남기면 다음 실행이나 수동 점검이 훨씬 쉬워집니다. 바이브코딩은 빠르게 만드는 흐름이지만, 반복 발행에서는 빠르게 증명하는 흐름도 필요합니다.

공개 증거 묶음이 필요한 이유

자동 발행은 여러 시스템을 지나갑니다. Markdown 파일은 저장소나 배포 폴더의 원천이고, Next.js 빌드는 그 원천을 정적 또는 서버 렌더링 가능한 산출물로 바꿉니다. PM2 재시작은 새 산출물을 실제 프로세스에 반영하고, 공개 URL 검증은 독자가 보는 경로까지 확인합니다. 어느 한 단계만 보고 성공이라고 말하면 장애가 생겼을 때 원인을 찾기 어렵습니다.

파일 존재와 공개 상태는 다르다

오늘 날짜의 Markdown 파일이 있다는 것은 중복 방지에는 충분한 신호입니다. 하지만 공개 상태를 말하려면 한 단계 더 나아가야 합니다. 파일은 있는데 콘텐츠 테스트가 실패할 수 있고, 테스트는 통과했지만 빌드가 실패할 수 있습니다. 빌드가 성공해도 기존 PM2 프로세스가 이전 산출물을 계속 바라보면 공개 페이지는 바뀌지 않습니다. 그래서 공개 증거는 파일 하나가 아니라 단계별 확인값의 묶음이어야 합니다.

재시도 판단을 단순하게 만든다

증거 묶음이 없으면 다음 실행은 같은 질문을 반복합니다. “오늘 글이 이미 있나?”, “빌드는 됐나?”, “PM2를 재시작했나?”, “상세 URL은 200인가?”, “목록에도 보이나?” 같은 질문이 매번 새롭게 생깁니다. 반대로 증거가 정리되어 있으면 재시도는 첫 실패 지점부터 시작할 수 있습니다. 새 글을 또 만들지 않고, 이미 정해진 slug와 URL을 기준으로 런타임이나 캐시만 다시 확인할 수 있습니다.

Futory에 맞는 증거 항목

Futory의 운영 흐름에서는 증거 항목을 복잡하게 늘릴 필요가 없습니다. 매일 같은 항목을 같은 순서로 확인하는 것이 더 중요합니다. 자동화 보고가 짧더라도 값이 일정하면 운영자는 정상 패턴과 다른 지점을 빠르게 찾을 수 있습니다.

원천 증거: frontmatter와 파일 경로

첫 번째 증거는 새 Markdown 파일입니다. frontmatter의 date: "YYYY-MM-DD", category: "바이브코딩", 제목, 설명, 태그가 의도한 형식인지 확인합니다. 파일명은 영어 kebab-case slug로 만들고, 공개 URL /posts/<slug>와 직접 연결합니다. 이 값이 흔들리지 않아야 이후 테스트, 빌드, 공개 검증이 모두 같은 대상을 바라봅니다.

검증 증거: 콘텐츠와 테마 테스트

npm run test:content는 글의 구조와 메타데이터가 블로그 규칙에 맞는지 확인합니다. npm run test:theme는 테마와 카테고리, 렌더링 전제가 깨지지 않았는지 확인합니다. 두 테스트가 성공하면 원천 파일은 다음 단계로 넘길 수 있는 상태가 됩니다. 이 시점 이후에는 같은 실행 안에서 본문을 다시 다듬기보다 빌드와 공개 검증으로 넘어가는 편이 안전합니다.

산출물 증거: 빌드와 slug 검색

npm run build가 성공하면 .next 안에서 새 slug가 실제로 포함되었는지 확인해야 합니다. 빌드 성공 로그만으로도 많은 것을 알 수 있지만, slug 검색은 “이번 글이 산출물에 들어갔다”는 직접 증거입니다. 특히 자동화에서는 이 작은 확인이 나중에 공개 URL 문제를 파일 문제와 런타임 문제로 나누는 데 도움이 됩니다.

공개 검증을 나눠서 보는 법

공개 검증은 상세 페이지와 목록 페이지를 분리하는 것이 좋습니다. 상세 URL /posts/<slug>가 200을 반환하면 글 자체는 접근 가능한 상태입니다. 홈과 /posts, 카테고리성 목록에서 날짜나 slug가 보이면 독자가 탐색 경로에서도 새 글을 발견할 수 있다는 뜻입니다.

캐시 우회 요청을 기본으로 한다

공개 사이트는 캐시나 프록시 때문에 이전 응답을 줄 수 있습니다. 그래서 검증할 때는 cache-busting query string을 붙이고 Cache-Control: no-cache 헤더를 함께 보내는 편이 좋습니다. 이 방식은 완벽한 캐시 무효화가 아니라 운영 판단의 오해를 줄이는 장치입니다. 상세는 정상인데 목록만 늦다면 새 글 생성이 아니라 목록 캐시나 런타임 반영을 의심해야 합니다.

실패 단계는 과장하지 않는다

공개 상세가 실패했다고 해서 앞 단계가 모두 실패한 것은 아닙니다. 파일, 테스트, 빌드, 산출물 확인이 성공했다면 문제는 PM2 재시작, 라우팅, 캐시, 네트워크 중 하나일 가능성이 큽니다. 보고에는 성공한 증거와 실패한 첫 지점을 나눠 적어야 합니다. 그래야 다음 조치가 “새 글 다시 작성”이 아니라 “런타임과 공개 경로 재검증”으로 좁혀집니다.

자주 묻는 질문

공개 증거 묶음은 별도 파일로 저장해야 하나요?

처음에는 크론 최종 보고만으로도 충분합니다. 중요한 것은 저장 위치보다 같은 항목을 반복해서 남기는 일입니다. 장기적으로 발행 이력 분석이 필요해지면 날짜, slug, 테스트 결과, 공개 상태만 별도 로그나 데이터베이스로 옮길 수 있습니다.

상세 URL은 200인데 홈 목록에 안 보이면 실패인가요?

부분 실패 또는 지연으로 보는 것이 정확합니다. 상세 URL이 200이면 글 자체의 공개 경로는 살아 있습니다. 홈 목록이나 /posts에 늦게 보인다면 캐시, 목록 생성 규칙, 런타임 반영을 따로 확인해야 합니다. 이때 새 Markdown 파일을 다시 만들면 중복이 생기므로 피해야 합니다.

빌드 산출물에서 slug를 꼭 찾아야 하나요?

필수는 아니지만 반복 자동화에서는 매우 유용합니다. 산출물 검색은 빌드 성공과 공개 검증 사이의 빈틈을 줄여 줍니다. slug가 산출물에 없으면 공개 URL을 확인하기 전에 빌드 입력이나 라우팅 문제를 먼저 봐야 합니다.

결론

AI 블로그 자동화에서 공개 증거 묶음은 운영자가 신뢰할 수 있는 발행을 만드는 작은 체크리스트입니다. Futory의 Next.js Markdown 흐름에서는 파일 생성, 백업, 콘텐츠 테스트, 테마 테스트, 빌드, 산출물 slug 확인, PM2 재시작, 공개 상세와 목록 검증을 같은 순서로 묶어야 합니다.

바이브코딩은 빠르게 시도하고 개선하는 문화에 잘 맞지만, 공개 블로그는 그 결과가 실제 독자 화면에 도달했는지 증명해야 오래 안정적으로 운영됩니다. 매일의 발행 보고에 증거 묶음을 남기면 중복 생성은 줄고, 실패 지점은 선명해지며, 다음 실행은 더 조용하고 정확하게 이어질 수 있습니다.