AI 블로그 자동화에서 런타임 재시작 증거를 남기는 법

요약

Futory 같은 Next.js Markdown 블로그 자동화에서는 새 글을 쓰는 일보다 “실제로 새 런타임이 그 글을 서빙하고 있는가”를 확인하는 일이 더 중요할 때가 많습니다. 콘텐츠 테스트와 빌드가 모두 성공해도, 실행 중인 PM2 프로세스가 오래된 산출물을 잡고 있으면 공개 사이트는 이전 상태처럼 보일 수 있습니다. 그래서 평일 자동 발행 루틴에는 파일 생성, 테스트, 빌드뿐 아니라 런타임 재시작 증거와 공개 HTML 확인까지 포함되어야 합니다.

오늘의 핵심은 재시작을 감각이 아니라 증거로 다루는 것입니다. npm run build가 통과했다는 로그, .next 산출물 안에 새 slug가 있다는 확인, PM2 재시작 명령의 성공, 상세 URL과 목록 페이지에서 오늘 날짜 또는 slug가 보인다는 결과를 순서대로 남기면 자동화의 신뢰도가 크게 올라갑니다. 바이브코딩은 빠른 실행을 중시하지만, 운영 자동화에서는 빠른 만큼 작은 체크포인트를 촘촘히 남겨야 다음 실패를 작게 고칠 수 있습니다.

왜 런타임 재시작 증거가 필요한가

Markdown 파일을 추가하는 방식의 블로그는 겉으로 단순해 보입니다. 파일 하나를 만들고 빌드하면 끝이라고 생각하기 쉽습니다. 하지만 실제 공개까지는 정적 생성 결과, 서버 프로세스, 프록시, 브라우저 또는 중간 캐시가 함께 움직입니다. 이 중 하나라도 예전 상태를 보고 있으면 사용자는 새 글을 찾지 못합니다.

빌드 성공과 서비스 반영은 다른 사건이다

빌드 성공은 “새 산출물을 만들 수 있다”는 뜻입니다. 반면 서비스 반영은 “실행 중인 프로세스가 그 산출물을 읽고 있다”는 뜻입니다. 두 사건은 가까이 붙어 있지만 동일하지 않습니다. 특히 PM2로 오래 실행되는 Next.js 앱은 재시작 전후를 분리해서 기록해야 합니다. 자동화 보고서에 빌드 성공만 남아 있으면, 나중에 공개 사이트가 비어 있을 때 빌드 문제인지 런타임 문제인지 바로 구분하기 어렵습니다.

재시작 로그는 중복 발행을 막는 안전장치다

공개 반영이 늦어질 때 가장 위험한 대응은 같은 날짜 글을 다시 만드는 것입니다. 오늘 날짜의 Markdown 파일이 이미 있고 빌드도 통과했다면 새 글을 또 만드는 것이 아니라 재시작과 공개 검증을 다시 봐야 합니다. 재시작 증거가 남아 있으면 “콘텐츠는 이미 준비됨, 런타임 확인 필요”라는 판단이 쉬워집니다. 이는 Futory의 하루 한 편 원칙을 지키는 데도 도움이 됩니다.

Futory에서 남겨야 할 증거 묶음

자동화가 신뢰를 얻으려면 매번 같은 모양의 결과를 남겨야 합니다. 사람이 읽기 쉬운 짧은 보고서라도 내부에는 단계별 증거가 있어야 합니다.

1. 파일과 frontmatter 확인

새 파일 경로, 제목, 날짜, 카테고리, slug를 먼저 확정합니다. 날짜는 KST 기준이어야 하고, category: "바이브코딩"처럼 목록 라우팅이 기대하는 값과 정확히 맞아야 합니다. 이 단계가 흔들리면 상세 페이지가 생기더라도 카테고리 페이지에서 빠질 수 있습니다.

2. 콘텐츠 테스트와 테마 테스트

npm run test:content는 frontmatter, 날짜, 중복, 본문 구조 같은 콘텐츠 계약을 확인합니다. npm run test:theme는 사이트가 기대하는 테마나 UI 규칙을 깨지 않았는지 확인합니다. 새 글 하나만 추가했더라도 이 두 테스트는 공개 전 필수입니다. 실패하면 PM2를 재시작하지 않는 것이 원칙입니다. 실패한 산출물을 런타임에 반영하면 문제 범위가 커지기 때문입니다.

3. 빌드 산출물과 slug 검색

빌드가 끝난 뒤에는 .next 안에서 새 slug가 발견되는지 확인합니다. 이 검증은 “소스 파일이 존재한다”와 “빌드 결과가 새 글을 포함한다” 사이를 이어 줍니다. 파일은 있지만 산출물에 없다면 라우팅, 콘텐츠 로더, 정렬 필터, 빌드 캐시를 의심해야 합니다.

4. PM2 재시작 결과

호스트에서 pm2 restart futory-wordblog가 성공했는지 남깁니다. 여기서 중요한 것은 명령을 실행했다는 주장보다 종료 코드와 출력입니다. 재시작이 실패했다면 공개 사이트가 예전 상태를 유지할 수 있으므로, 상세 URL 검증 실패를 콘텐츠 문제로 착각하지 않아야 합니다.

공개 검증은 재시작 이후에 한다

PM2 재시작이 끝난 뒤에는 공개 URL을 캐시 우회 방식으로 읽습니다. 상세 페이지 /posts/<slug>는 200 상태와 제목 또는 본문 일부를 확인합니다. 홈 /, 전체 목록 /posts, 카테고리 /vibe-coding은 오늘 날짜나 slug가 들어 있는지 확인합니다.

목록 페이지까지 봐야 운영 완료다

상세 페이지가 열려도 목록에서 보이지 않으면 독자는 자연스럽게 새 글을 발견하기 어렵습니다. Futory의 반복 발행은 단순히 URL 하나를 만드는 일이 아니라 최신 글 흐름에 글을 올리는 일입니다. 그래서 목록 페이지 검증은 선택이 아니라 발행 완료 조건입니다.

자주 묻는 질문

PM2 재시작이 성공했는데 목록에 안 보이면 어떻게 하나요?

먼저 상세 URL이 200인지 확인합니다. 상세는 성공하고 목록만 실패하면 콘텐츠 인덱싱, 정렬 기준, 카테고리 값, 캐시를 확인합니다. 상세도 실패하면 빌드 산출물과 런타임 경로가 같은지 다시 봐야 합니다.

매번 재시작해야 하나요?

현재처럼 빌드 산출물을 사용하는 Next.js 운영 흐름에서는 새 콘텐츠를 안정적으로 반영하기 위해 재시작을 표준 단계로 두는 편이 안전합니다. 다만 재시작 전에 테스트와 빌드가 실패하면 재시작하지 않아야 합니다.

공개 검증이 느리면 자동화를 줄여도 되나요?

검증 대상은 최소한 상세, 홈, 전체 목록, 카테고리 네 곳을 유지하는 것이 좋습니다. 시간이 조금 더 걸리더라도 실패 위치가 분리되어 다음 조치가 빨라집니다. 자동화에서 가장 비싼 것은 검증 시간이 아니라 원인을 모르는 반복 실패입니다.

결론

AI 블로그 자동화에서 런타임 재시작 증거는 발행 결과를 운영 가능한 상태로 만드는 마지막 연결고리입니다. Futory의 평일 발행 루틴은 새 Markdown 파일 작성, 콘텐츠 테스트, 테마 테스트, 빌드, .next slug 확인, PM2 재시작, 공개 URL 검증을 하나의 흐름으로 다룰 때 안정적입니다.

바이브코딩의 장점은 빠르게 만들고 반복하며 개선하는 데 있습니다. 하지만 공개 블로그에서는 빠른 실행만큼 빠른 검증도 필요합니다. 재시작 증거와 공개 HTML 확인을 매번 남기면 중복 발행을 피하고, 실패 지점을 작게 나누며, 다음 자동화 개선의 기준을 분명히 세울 수 있습니다. 그렇게 Futory는 단순한 글 생성기가 아니라 매일 운영 상태를 스스로 증명하는 블로그 시스템에 가까워집니다.