AI 블로그 자동화에서 런타임 드리프트를 점검하는 법

요약

Futory처럼 Markdown 파일을 추가하고 npm run build를 실행한 뒤 PM2 프로세스를 재시작해 공개하는 블로그에서는 “파일이 있다”, “빌드가 됐다”, “사이트에 보인다”가 항상 같은 순간에 맞물리지 않습니다. 새 글은 content/posts에 존재하지만 오래된 런타임이 이전 빌드 결과를 들고 있을 수 있고, PM2 재시작은 성공했지만 목록 페이지 캐시가 잠시 예전 응답을 보여 줄 수도 있습니다. 이런 어긋남을 런타임 드리프트라고 부르면 운영 판단이 한결 쉬워집니다.

런타임 드리프트 점검의 목표는 원인을 과장하지 않고 상태를 분리해서 보는 것입니다. 글 파일, 콘텐츠 테스트, 테마 테스트, 빌드 산출물, PM2 재시작, 공개 상세 URL, 목록 페이지 노출을 같은 slug로 확인하면 어느 층에서 어긋났는지 빠르게 좁힐 수 있습니다. 이 글은 Futory의 바이브코딩 자동 발행 흐름에서 런타임 드리프트를 줄이는 실무 루틴을 정리합니다.

런타임 드리프트란 무엇인가

런타임 드리프트는 배포 경로의 소스 상태와 실제 서비스 프로세스가 사용자에게 보여 주는 상태가 달라지는 현상입니다. Git 기반 배포에서는 커밋, 빌드, 배포 서버가 각각 다른 버전을 가리킬 때 자주 발생하고, Futory 같은 Next.js Markdown 블로그에서는 Markdown 파일, .next 산출물, PM2 프로세스, nginx를 거친 공개 응답 사이에서 발생할 수 있습니다.

파일 존재는 공개 성공이 아니다

/opt/futory/content/posts에 오늘 날짜 파일이 생기면 작성 단계는 끝났다고 말할 수 있습니다. 하지만 독자가 읽을 수 있는 상태인지는 아직 별개입니다. 콘텐츠 테스트가 frontmatter와 본문 규칙을 확인하고, 테마 테스트가 렌더링 규칙을 확인하며, 빌드가 페이지 산출물을 만들어야 합니다. 그다음 PM2가 새 빌드 결과를 들고 다시 떠야 공개 상세 URL이 안정적으로 200을 반환합니다.

빌드 성공도 런타임 반영과 다르다

npm run build가 성공했는데 공개 페이지가 보이지 않는 경우가 있습니다. 이때 새 글을 다시 쓰거나 제목을 바꾸는 것은 좋은 대응이 아닙니다. 이미 파일과 빌드는 통과했으므로 다음 확인 지점은 .next에 slug가 있는지, PM2 재시작이 실제로 성공했는지, 공개 요청이 캐시를 우회했는지입니다. 단계를 나누면 콘텐츠 문제와 운영 문제를 섞지 않을 수 있습니다.

Futory에서 드리프트를 줄이는 점검 순서

Futory의 반복 발행은 KST 기준 평일, 선택된 시간, 오늘 날짜 중복 확인을 먼저 거칩니다. 이 기본 조건을 통과한 뒤에는 새 글을 쓰기 전 content tree를 백업하고, 새 Markdown 파일 하나만 추가합니다. 여기까지는 소스 상태를 안전하게 만드는 단계입니다.

같은 slug로 모든 층을 연결한다

오늘의 slug가 ai-blog-runtime-drift-check-routine이라면 파일명, 공개 URL, 빌드 산출물 검색, 목록 검증이 모두 이 문자열을 기준으로 움직여야 합니다. 운영 보고서도 같은 이름을 반복해야 다음 재시도에서 상태를 이어받기 쉽습니다. 제목은 사람이 읽는 이름이고, slug는 자동화가 상태를 추적하는 이름입니다.

백업은 드리프트 분석의 기준점이다

백업은 단순한 복구 수단이 아니라 “이번 실행이 바꾼 것”을 식별하는 기준점입니다. 빌드나 공개 검증이 실패했을 때 백업 경로가 있으면 기존 글을 건드렸는지, 새 파일만 추가했는지, 되돌릴 필요가 있는지 판단할 수 있습니다. 특히 live Markdown 폴더를 직접 쓰는 자동화에서는 백업 없는 변경이 가장 큰 불확실성입니다.

공개 검증은 두 갈래로 본다

PM2 재시작 후에는 상세 페이지와 목록 페이지를 나눠 확인해야 합니다. 상세 페이지 /posts/<slug>는 직접 접근 가능성을 보여 주고, 홈과 /posts, /vibe-coding은 독자가 새 글을 발견할 수 있는지를 보여 줍니다. 두 신호가 모두 맞아야 발행 완료라고 보고하는 편이 안전합니다.

캐시 우회는 습관으로 만든다

공개 검증에서는 cache-busting query string과 Cache-Control: no-cache 헤더를 함께 쓰는 것이 좋습니다. 캐시를 완전히 없애는 만능 도구는 아니지만, 오래된 응답을 최신 상태로 착각하거나 최신 반영을 늦은 장애로 오해하는 일을 줄여 줍니다. 검증 로그에는 상태 코드와 함께 slug 또는 오늘 날짜 포함 여부를 남기면 충분합니다.

실패하면 새 글이 아니라 끊긴 층을 본다

상세 URL이 404라면 먼저 빌드 산출물과 PM2 재시작을 봅니다. 상세는 200인데 목록에 보이지 않는다면 정렬, 목록 생성, 캐시 문제로 좁힙니다. 목록에는 보이는데 상세가 실패한다면 라우팅이나 빌드 산출물 연결을 의심합니다. 중요한 점은 실패했다고 같은 날짜로 새 Markdown을 만들지 않는 것입니다. 오늘 날짜 파일이 이미 있으면 그 파일이 기준입니다.

운영 보고서에 남길 신호

좋은 보고서는 길지 않아도 재현 가능해야 합니다. 선택된 KST 시간, 파일 경로, 제목, 날짜, slug, 백업 경로, 테스트 결과, 빌드 결과, .next 포함 여부, PM2 재시작 결과, 공개 상세와 목록 검증 결과를 같은 순서로 남기면 다음 실행과 사람이 같은 상태를 볼 수 있습니다.

성공과 반영을 분리해서 쓴다

“작성 성공”은 파일 생성과 테스트 통과를 뜻할 수 있고, “공개 성공”은 PM2 재시작과 공개 URL 검증까지 끝났다는 뜻입니다. 이 둘을 구분하지 않으면 운영자가 이미 공개된 글을 다시 만들거나, 아직 반영되지 않은 글을 완료로 오해할 수 있습니다. Futory의 자동화에서는 성공 단어보다 단계 이름을 그대로 쓰는 편이 더 안전합니다.

자주 묻는 질문

런타임 드리프트가 생기면 항상 PM2 문제인가요?

아닙니다. PM2 재시작 실패가 흔한 원인 중 하나일 수는 있지만, 빌드 산출물 누락, 목록 생성 규칙, 캐시, 프록시 응답도 후보입니다. 그래서 먼저 파일, 빌드, 런타임, 공개 응답을 나눠 확인해야 합니다.

빌드가 성공했는데 공개가 늦으면 다시 빌드해야 하나요?

바로 다시 빌드하기보다 .next에 slug가 있는지, PM2 재시작이 성공했는지, 공개 요청이 캐시를 우회했는지 확인하는 편이 좋습니다. 같은 입력으로 반복 빌드만 하면 원인 분리가 늦어질 수 있습니다.

목록에 안 보이면 글을 수정해야 하나요?

대부분은 글 본문보다 목록 생성이나 런타임 반영 문제일 가능성이 큽니다. frontmatter의 date, category, slug가 정상이라면 본문을 고치기보다 공개 목록 응답과 빌드 결과를 먼저 확인해야 합니다.

결론

AI 블로그 자동화에서 런타임 드리프트를 줄이는 핵심은 한 번에 모든 문제를 해결하려는 것이 아니라 상태를 층별로 나누어 보는 것입니다. Futory의 Next.js Markdown 운영에서는 오늘의 slug를 기준으로 파일, 테스트, 빌드, 산출물, PM2, 공개 페이지를 차례로 확인하면 어긋난 지점을 빠르게 찾을 수 있습니다.

바이브코딩은 빠른 실행을 장점으로 삼지만, 반복 발행에서는 빠른 확인이 함께 있어야 합니다. 새 글 하나를 만드는 일보다 더 중요한 것은 그 글이 실제 독자 화면까지 같은 이름으로 도착했는지 확인하는 습관입니다. 런타임 드리프트 점검은 그 습관을 매일의 자동화 안에 작게 넣는 방법입니다.