AI 블로그 자동화에서 재시작 후 관찰 창을 두는 법

요약

Futory처럼 Next.js Markdown 블로그를 AI 에이전트와 크론으로 발행하면 성공의 마지막 장면은 파일 생성이 아니라 공개 사이트에서 독자가 새 글을 볼 수 있는 상태입니다. npm run build가 통과하고 PM2 재시작이 성공해도, 실제 운영에서는 캐시, 프록시, 목록 페이지의 정렬, 런타임 준비 시간 때문에 몇 초 동안 애매한 상태가 생길 수 있습니다. 그래서 자동 발행 루틴에는 재시작 직후의 짧은 관찰 창이 필요합니다.

관찰 창은 긴 모니터링 시스템이 아닙니다. 새 slug의 상세 페이지가 200을 반환하는지, 홈과 /posts, /vibe-coding 목록에 오늘 날짜나 slug가 보이는지, no-cache 요청에서도 같은 결과가 나오는지를 확인하는 작은 운영 절차입니다. 이 글은 Futory의 바이브코딩 발행 흐름에서 재시작 후 관찰 창을 어떻게 설계하면 안전하고 실용적인지 정리합니다.

왜 재시작 직후를 따로 보아야 할까

자동화는 단계별로 성공을 기록하지만, 단계 사이에는 짧은 공백이 있습니다. Markdown 파일은 디스크에 존재하고, 빌드 산출물도 만들어졌지만, 실행 중인 Next.js 프로세스가 새 산출물을 읽기 전일 수 있습니다. 또는 PM2 재시작은 완료됐지만 첫 요청에서 아직 캐시된 HTML이 내려올 수 있습니다.

빌드 성공과 공개 성공은 다르다

빌드 성공은 새 글이 앱 내부에서 해석 가능하다는 뜻입니다. 공개 성공은 외부 사용자가 실제 URL로 접근할 수 있다는 뜻입니다. 두 결과는 자주 함께 움직이지만 같은 검증은 아닙니다. Futory의 평일 발행 루틴에서는 이 차이를 분리해서 봐야 합니다. .next 산출물에 slug가 들어 있는지 확인한 뒤, 별도로 공개 URL을 요청해야 운영자가 문제 위치를 좁힐 수 있습니다.

목록 페이지는 상세 페이지보다 늦게 드러날 수 있다

상세 페이지 /posts/<slug>가 200을 반환해도 홈, 전체 글 목록, 바이브코딩 카테고리 목록이 곧바로 같은 글을 보여 준다고 가정하면 안 됩니다. 목록은 정렬, 필터, 요약 데이터, 캐시의 영향을 더 많이 받습니다. 따라서 관찰 창은 상세 페이지 하나만 보는 것이 아니라 독자가 글을 발견하는 표면을 함께 확인하는 방식이어야 합니다.

Futory에 맞는 관찰 창 설계

Futory의 관찰 창은 복잡하지 않을수록 좋습니다. 무인 크론이 실행하는 절차이므로 오래 기다리거나 사람의 판단을 요구하면 안 됩니다. 대신 짧고 반복 가능한 확인 항목을 고정합니다.

1. 같은 키를 여러 표면에서 확인한다

새 글의 안정적인 키는 slug와 날짜입니다. 파일명은 ai-blog-post-restart-observation-window-routine.md처럼 영어 kebab-case로 두고, frontmatter의 날짜는 KST 기준 2026-09-10으로 둡니다. 공개 검증에서는 이 두 값을 기준으로 봅니다. 상세 페이지는 slug가 URL에 들어가므로 HTTP 200이 핵심이고, 목록 페이지는 오늘 날짜나 slug가 HTML 안에 보이는지를 확인합니다.

2. 캐시 무효화 요청을 기본값으로 둔다

브라우저나 중간 캐시를 피하려면 검증 요청에 쿼리 문자열을 붙이고 Cache-Control: no-cache 헤더를 사용합니다. 예를 들어 ?cron=20260910-1400 같은 값은 내용에 영향을 주지 않으면서 캐시된 응답을 피하는 단서가 됩니다. 이 방식은 “내 브라우저에서는 안 보인다” 같은 주관적 확인보다 자동화 보고서에 남기기 쉽습니다.

3. 실패하면 다음 단계를 추측하지 않는다

관찰 창에서 실패가 나오면 보고서는 어느 표면이 실패했는지 분리해야 합니다. 상세 페이지가 404라면 라우트 생성이나 런타임 반영을 먼저 봐야 합니다. 상세은 200이지만 목록에 없으면 목록 생성 로직, 정렬 기준, 캐시를 봐야 합니다. 모든 요청이 실패하면 PM2 재시작이나 프록시 상태를 의심할 수 있습니다. 중요한 것은 실패 원인을 단정하지 않고, 재현 가능한 URL과 상태를 남기는 것입니다.

운영 보고서에 남길 증거

관찰 창은 보고서와 짝을 이룰 때 가치가 커집니다. 발행 보고서에는 선택된 시간, KST 현재 시각, 중복 검사 결과, 백업 경로, 새 파일 경로, 테스트와 빌드 상태, PM2 재시작 결과, 공개 검증 결과가 들어가야 합니다. 여기에 관찰 창의 결과를 더하면 운영자는 “빌드는 됐지만 공개가 안 됐다”와 “공개까지 확인됐다”를 즉시 구분할 수 있습니다.

증거는 짧아도 충분하다

좋은 증거는 장황한 로그 전체가 아니라 판단에 필요한 최소 정보입니다. detail 200, home contains slug, posts contains date, vibe-coding contains slug처럼 표면별 결과를 남기면 됩니다. 실패한 경우에는 실행한 명령이나 요청 URL, HTTP 상태, 첫 번째 오류 메시지를 함께 적습니다. 이 정도면 다음 운영자가 같은 조건으로 다시 확인할 수 있습니다.

관찰 창은 다음 글의 주제 지문이 된다

오늘의 관찰 결과는 내일의 자동화에도 도움을 줍니다. 최근 글의 제목과 설명을 읽을 때 “재시작 후 관찰 창”이라는 주제가 이미 다뤄졌다는 사실이 남기 때문입니다. Futory의 글은 운영 지식을 쌓는 동시에 다음 발행의 중복 방지 데이터가 됩니다.

자주 묻는 질문

관찰 창은 몇 분이나 필요할까요?

Futory 같은 소규모 Next.js Markdown 블로그에서는 긴 대기보다 즉시 no-cache 확인이 더 실용적입니다. PM2 재시작이 끝난 뒤 상세와 목록 페이지를 바로 확인하고, 실패하면 보고서에 멈춘 지점을 남기는 방식이 좋습니다. 무인 크론이 오래 대기하면 다음 실행이나 다른 작업과 겹칠 수 있습니다.

상세 페이지가 200이면 목록 확인은 생략해도 되나요?

생략하지 않는 편이 좋습니다. 상세 페이지는 직접 URL을 아는 사람에게만 의미가 있습니다. 홈, /posts, /vibe-coding 목록은 독자가 새 글을 발견하는 입구입니다. 자동 발행의 목적이 공개라면 발견 가능성까지 확인해야 합니다.

캐시 때문에 실패처럼 보이면 어떻게 하나요?

검증 요청에 cache-busting query와 Cache-Control: no-cache를 붙입니다. 그래도 목록에 보이지 않으면 단순 캐시로 단정하지 말고, 목록 생성 로직과 빌드 산출물, 실행 중인 프로세스 경로를 확인해야 합니다. 보고서에는 추측보다 확인한 URL과 상태를 남기는 것이 우선입니다.

결론

AI 블로그 자동화에서 재시작 후 관찰 창은 작은 절차지만 공개 품질을 크게 높입니다. Futory의 발행 루틴은 새 Markdown 파일을 만들고, 테스트와 빌드를 통과시키고, PM2를 재시작한 뒤, 상세와 목록 페이지를 no-cache로 확인할 때 완성됩니다. 이 짧은 관찰은 캐시와 런타임 반영의 애매한 구간을 줄이고, 실패가 발생해도 다음 조치를 바로 찾을 수 있게 해 줍니다. 자동화가 믿을 만해지는 순간은 글을 쓰는 순간이 아니라, 공개 표면에서 같은 slug와 날짜가 반복해서 확인되는 순간입니다.