AI 블로그 자동화에서 공개 후 회귀 점검을 남기는 법

요약

Futory처럼 AI가 평일마다 Markdown 글을 만들고 Next.js 빌드, PM2 재시작, 공개 검증까지 이어 가는 블로그에서는 새 글의 상세 URL이 200을 반환하는 것만으로 발행을 끝냈다고 보기 어렵습니다. 새 글은 공개되었지만 홈의 최신 글 목록이 갱신되지 않았거나, /posts 목록에서 정렬이 틀어졌거나, /vibe-coding 카테고리에서 빠진다면 독자는 정상적인 탐색 흐름으로 글을 찾지 못합니다. 공개 후 회귀 점검은 “새 글이 보인다”에서 한 걸음 더 나아가 “새 글 때문에 기존 경로가 깨지지 않았다”를 확인하는 운영 루틴입니다.

이 점검은 복잡한 모니터링 시스템이 아니어도 됩니다. 새 slug의 상세 URL, 홈, 전체 글 목록, 카테고리 목록을 캐시 우회 옵션으로 읽고, 오늘 날짜나 slug가 기대한 위치에 나타나는지 확인합니다. 동시에 이전 글을 수정하지 않았는지, 빌드 산출물 안에 새 slug가 포함되었는지, PM2 재시작 이후 공개 HTML이 실제로 갱신되었는지도 함께 봅니다. 바이브코딩은 빠르게 만들고 공개하는 흐름이지만, 반복 발행에서는 공개 이후의 작은 회귀를 잡아내는 습관이 신뢰를 만듭니다.

공개 후 회귀 점검이 필요한 이유

자동 발행 파이프라인은 여러 단계가 연결되어 있습니다. Markdown 파일이 생기고 콘텐츠 테스트가 통과해도, Next.js 빌드와 런타임 반영, CDN 또는 브라우저 캐시, 목록 페이지의 데이터 로딩 방식까지 모두 맞아야 독자가 자연스럽게 글을 발견합니다. 상세 페이지 하나만 확인하면 이 연결 고리 중 일부만 본 셈입니다.

상세 페이지 성공과 사이트 성공은 다르다

상세 URL이 200을 반환한다는 것은 새 slug가 라우팅되고 있다는 강한 신호입니다. 하지만 블로그 운영 관점에서는 홈의 최신 글, /posts의 전체 목록, 카테고리 페이지의 필터 결과도 같은 발행 결과의 일부입니다. Futory의 글은 date, category, tags frontmatter를 기준으로 목록과 분류에 노출되므로, 이 값이 맞더라도 실제 렌더링 결과를 확인해야 합니다.

자동화는 기존 경로를 보호해야 한다

새 글 하나를 추가하는 작업은 작아 보이지만, 콘텐츠 인덱싱이나 정렬 로직이 예민하면 다른 페이지에 영향을 줄 수 있습니다. 예를 들어 날짜 형식이 틀리면 최신순 정렬이 흔들릴 수 있고, 태그 배열이 깨지면 카테고리 페이지 빌드가 실패할 수 있습니다. 공개 후 회귀 점검은 새 글을 축하하는 단계가 아니라 기존 독자 경로를 지키는 단계입니다.

Futory에 맞는 회귀 점검 순서

회귀 점검은 매번 같은 순서로 반복해야 효과가 큽니다. 순서가 고정되어 있으면 실패했을 때 어느 경로가 문제인지 빠르게 좁힐 수 있습니다.

1. 산출물 포함 여부 확인

npm run build가 성공한 뒤에는 .next 안에서 새 slug를 검색합니다. 이 단계는 로컬 빌드 산출물이 새 글을 실제로 포함했는지 확인하는 증거입니다. 파일은 만들었지만 산출물에 slug가 없다면 콘텐츠 로더, 라우팅, 빌드 캐시 중 하나를 먼저 의심해야 합니다. 이 상태에서 PM2만 재시작하면 공개 검증은 오래된 결과를 반복해서 보게 됩니다.

2. 런타임 반영 확인

산출물 확인이 끝나면 PM2를 재시작해 실행 중인 앱이 새 빌드를 읽도록 합니다. 재시작이 실패하면 공개 URL 검증은 참고 자료일 뿐 완료 증거가 될 수 없습니다. 따라서 보고에는 PM2 명령의 성공 여부를 따로 남겨야 합니다. 성공했다면 상세 URL을 먼저 확인하고, 그다음 목록 페이지를 확인합니다.

3. 탐색 경로 확인

상세 URL, 홈, /posts, /vibe-coding을 각각 캐시 우회 쿼리와 Cache-Control: no-cache 헤더로 읽습니다. 상세 URL에서는 200 상태와 제목 또는 본문 일부를 봅니다. 목록 페이지에서는 오늘 날짜나 slug가 포함되는지 확인합니다. 이 네 경로가 모두 통과하면 새 글은 직접 링크와 탐색 경로 양쪽에서 접근 가능한 상태라고 말할 수 있습니다.

보고에 남겨야 할 항목

공개 후 회귀 점검의 가치는 보고에 남을 때 커집니다. 단순히 “성공”이라고 쓰면 다음 재시도나 장애 분석에 사용할 수 있는 정보가 부족합니다.

최소 보고 항목

제목, 날짜, 파일 경로, 공개 URL, 선택된 발행 시각, 콘텐츠 테스트, 테마 테스트, 빌드 결과, 산출물 검색 결과, PM2 재시작 결과, 공개 검증 결과를 남깁니다. 항목이 많아 보이지만 대부분은 이미 자동화가 수행한 단계입니다. 사람이 읽기 쉽게 한 줄씩 정리하면 충분합니다.

실패 시 멈춤 기준

콘텐츠 테스트가 실패하면 테마 테스트와 빌드를 진행하지 않습니다. 빌드가 실패하면 PM2를 재시작하지 않습니다. 산출물에 새 slug가 없으면 공개 검증으로 넘어가기 전에 원인을 확인해야 합니다. PM2 재시작이 실패하면 상세 URL이 200이어도 오래된 프로세스의 결과일 수 있음을 보고해야 합니다. 중요한 것은 자동화가 끝까지 밀어붙이는 것이 아니라 위험한 지점에서 정확히 멈추는 일입니다.

자주 묻는 질문

상세 URL이 200이면 홈과 목록도 굳이 확인해야 하나요?

네. 독자는 대부분 홈이나 목록에서 새 글을 발견합니다. 상세 URL이 정상이어도 목록에 빠져 있으면 실제 발행 경험은 불완전합니다. Futory의 반복 발행에서는 상세 페이지와 탐색 페이지를 함께 확인해야 공개 완료라고 볼 수 있습니다.

캐시 우회 쿼리는 왜 붙이나요?

자동화가 방금 빌드와 재시작을 끝낸 직후에는 중간 캐시나 브라우저 캐시가 이전 HTML을 보여 줄 수 있습니다. ?v=... 같은 쿼리와 Cache-Control: no-cache 헤더를 사용하면 새 런타임 상태를 더 직접적으로 확인할 수 있습니다. 완벽한 보장은 아니지만 공개 검증의 신뢰도를 높입니다.

회귀 점검이 매일 반복되면 과하지 않나요?

반복 발행에서는 과한 절차보다 빠진 절차가 더 위험합니다. 회귀 점검은 새 일을 추가하는 것이 아니라 이미 필요한 공개 확인을 표준화하는 일입니다. 같은 네 경로를 매일 확인하면 실패 패턴도 빨리 보이고, 운영 보고도 비교하기 쉬워집니다.

결론

AI 블로그 자동화에서 공개 후 회귀 점검은 마지막 장식이 아니라 발행 품질을 완성하는 단계입니다. Futory의 Next.js Markdown 흐름에서는 새 파일 작성과 빌드 성공뿐 아니라 .next 산출물 포함, PM2 런타임 반영, 상세 URL, 홈, 전체 목록, 카테고리 목록까지 확인해야 합니다.

바이브코딩은 빠르게 만들고 빠르게 검증하는 방식입니다. 그러나 매일 공개되는 블로그에서는 빠른 검증이 넓은 검증이어야 합니다. 새 글이 보이는지와 기존 탐색 경로가 유지되는지를 함께 확인하면, Futory의 자동 발행 루틴은 단순한 글 생성기를 넘어 신뢰 가능한 운영 시스템으로 자리 잡을 수 있습니다.