AI 블로그 자동화에서 환경 신호를 점검하는 법

요약

Futory 같은 Next.js Markdown 블로그의 평일 자동 발행은 글을 잘 쓰는 일만으로 끝나지 않습니다. 같은 프롬프트와 같은 저장소를 사용하더라도 실행 시점의 시간대, 배포 경로, 테스트 명령, 공개 URL, 런타임 재시작 권한이 조금만 달라지면 결과가 달라질 수 있습니다. 그래서 무인 크론은 새 글을 쓰기 전에 “오늘이 맞는지”, “여기가 실제 배포 폴더인지”, “중복 글이 없는지”를 먼저 확인해야 합니다.

환경 신호 점검은 거창한 관측 시스템이 아닙니다. KST 날짜와 선택 시간을 고정하고, /opt/futory/content/posts에 이미 오늘 날짜가 있는지 확인하고, 백업을 만든 뒤, npm run test:content, npm run test:theme, npm run build가 같은 폴더에서 실행되는지 검증하는 작은 습관입니다. 이 습관은 AI가 글을 생성하는 속도와 운영자가 믿을 수 있는 배포 품질 사이의 간격을 줄여 줍니다.

환경 신호가 중요한 이유

자동화는 반복되기 때문에 작은 착각도 반복됩니다. 한 번 잘못된 경로에서 빌드하면 새 Markdown 파일은 생겼지만 공개 사이트에는 반영되지 않을 수 있습니다. UTC 날짜를 그대로 사용하면 한국 독자가 보는 오늘과 frontmatter의 날짜가 어긋날 수 있습니다. PM2 재시작 명령이 실패했는데도 공개 검증을 생략하면 오래된 런타임을 새 배포처럼 착각할 수 있습니다.

시간대는 콘텐츠 계약의 일부다

Futory의 weekday 루틴은 Asia/Seoul 기준으로 하루 한 편을 발행합니다. 따라서 현재 시간이 UTC로 몇 시인지보다 KST 날짜와 시각이 더 중요합니다. frontmatter의 date도 KST 날짜로 맞춰야 하고, 중복 검사도 같은 기준으로 수행해야 합니다. 시간대가 흔들리면 같은 물리적 실행이 어제 글의 재시도인지, 오늘 글의 신규 발행인지 모호해집니다.

경로는 배포 결과를 결정한다

Next.js Markdown 블로그에서는 파일이 어디에 쓰였는지가 곧 배포 결과입니다. /opt/futory/content/posts가 실제 콘텐츠 경로이고, 빌드도 /opt/futory에서 실행되어야 합니다. 비슷한 이름의 복사본이나 임시 폴더에서 글을 만들면 테스트는 통과할 수 있어도 public site에는 아무 변화가 없습니다. 자동화 보고서에 파일 경로와 빌드 작업 디렉터리를 남기는 이유가 여기에 있습니다.

발행 전 점검 순서

좋은 점검은 글을 쓰기 전에 대부분의 위험을 제거합니다. 첫째, KST 기준 오늘이 평일인지 확인합니다. 둘째, 결정적 선택 시간에만 실행합니다. 셋째, 오늘 날짜가 들어간 기존 Markdown frontmatter나 파일명이 있는지 검색합니다. 넷째, 최근 글의 제목과 설명을 읽어 주제가 겹치지 않도록 새 각도를 잡습니다. 마지막으로 posts 디렉터리를 압축 백업합니다.

중복 방지는 생성보다 먼저다

AI 글쓰기 루틴에서 가장 비싼 실수는 비슷한 글이 두 개 생기는 것입니다. 새 초안을 만든 뒤 중복을 발견하면 되돌릴 파일이 늘어나고, 빌드 산출물이나 공개 캐시에도 흔적이 남을 수 있습니다. 그래서 중복 검사는 작성 전 계약이어야 합니다. 오늘 날짜가 이미 frontmatter에 있으면 글의 품질과 관계없이 SKIP하는 편이 안전합니다.

백업은 복구 시간을 줄인다

content/posts 백업은 새 글 하나를 추가하는 작업에도 필요합니다. 자동화가 기존 글을 수정하지 않도록 설계되어 있어도, 운영 중에는 파일 권한, 인코딩, 도구 오류 같은 예외가 생길 수 있습니다. 백업 경로와 크기를 보고서에 남기면 장애가 생겼을 때 어느 시점으로 되돌릴지 바로 판단할 수 있습니다.

발행 후 검증 순서

발행 후에는 내부 검증과 공개 검증을 분리합니다. 내부 검증은 콘텐츠와 테마와 빌드가 프로젝트 규칙을 만족하는지 확인합니다. 공개 검증은 새 slug가 실제 웹 표면에서 보이는지 확인합니다. 두 단계 중 하나라도 빠지면 “빌드는 됐지만 독자가 못 보는 글” 또는 “페이지는 보이지만 규칙을 깨는 글”이 생길 수 있습니다.

빌드 산출물에서 slug를 확인한다

npm run build가 성공한 뒤에는 .next 산출물 안에서 새 slug가 포함되었는지 확인하는 것이 좋습니다. 이 단계는 Markdown 파일이 빌드 입력으로 실제 수집되었는지 확인하는 중간 증거입니다. slug가 산출물에서 보이지 않으면 공개 URL을 요청하기 전에 콘텐츠 로더, 라우팅, 정적 생성 설정을 먼저 의심해야 합니다.

공개 URL은 no-cache로 확인한다

PM2 재시작 뒤에는 /posts/<slug> 상세 페이지가 200을 반환하는지 확인하고, /, /posts, /vibe-coding 목록에서 오늘 날짜나 slug가 보이는지 확인합니다. 이때 cache-busting query string과 Cache-Control: no-cache를 함께 사용해야 합니다. 자동화가 오래된 HTML을 성공으로 오해하지 않도록 하기 위한 최소한의 안전장치입니다.

운영 보고서에 남길 항목

무인 발행 보고서는 짧아도 다음 실행자가 재현할 수 있어야 합니다. 선택된 KST 시간, 실제 실행 시간, 중복 검사 결과, 백업 파일, 새 Markdown 경로, 제목과 slug, 본문 글자 수, H2/H3 개수, 필수 섹션 존재 여부, 테스트와 빌드 결과, PM2 재시작 결과, 공개 URL 검증 상태를 남기면 충분합니다.

성공보다 경계가 더 중요하다

보고서의 목적은 자랑이 아니라 경계 기록입니다. 어떤 단계까지 통과했고 어떤 단계에서 멈춰야 하는지 명확하면 재시도도 안전해집니다. 특히 빌드 실패 시 PM2를 재시작하지 않는다는 원칙, 공개 검증 실패 시 명령과 응답을 남긴다는 원칙은 무인 자동화의 피해 범위를 줄입니다.

자주 묻는 질문

환경 점검을 매번 하면 발행이 느려지지 않나요?

조금 느려질 수 있지만, 대부분은 몇 초 안에 끝나는 확인입니다. 반대로 잘못된 날짜나 경로로 발행한 뒤 복구하는 시간은 훨씬 깁니다. Futory처럼 평일 하루 한 편을 목표로 하는 블로그에서는 속도보다 재현 가능한 성공이 더 중요합니다.

테스트가 통과하면 공개 검증은 생략해도 되나요?

아니요. 테스트와 빌드는 로컬 프로젝트 상태를 확인하고, 공개 검증은 서비스에 반영된 상태를 확인합니다. PM2 재시작, 프록시, 캐시, 정적 산출물 문제는 로컬 테스트만으로는 놓칠 수 있습니다. 상세 페이지와 목록 페이지를 각각 확인해야 합니다.

오늘 날짜가 파일명에만 있으면 중복으로 봐야 하나요?

네. frontmatter가 더 강한 신호이지만 파일명에 오늘 날짜가 들어간 초안이나 임시 글도 중복 위험을 의미합니다. 무인 루틴에서는 애매하면 새 글을 만들지 않고 보고하는 편이 안전합니다. 하루 한 편 계약은 콘텐츠 품질만큼 운영 신뢰를 지키는 장치입니다.

결론

AI 블로그 자동화의 품질은 생성 모델의 문장력뿐 아니라 실행 환경을 얼마나 꾸준히 확인하느냐에 달려 있습니다. Futory의 Next.js Markdown 루틴에서 시간대, 경로, 중복 상태, 백업, 빌드 산출물, PM2 재시작, 공개 URL은 모두 같은 발행 계약을 이루는 신호입니다. 이 신호를 매번 작게 확인하면 무인 발행은 더 예측 가능해지고, 실패하더라도 어느 단계에서 멈췄는지 빠르게 설명할 수 있습니다.