AI 블로그 자동화에서 빌드 산출물 리뷰를 루틴으로 만드는 법

요약

Futory처럼 content/posts/*.md가 곧 공개 글의 원천이 되는 Next.js Markdown 블로그에서는 파일을 만들었다는 사실만으로 발행을 끝냈다고 말하기 어렵습니다. 글이 올바른 frontmatter를 갖고 있고, 콘텐츠 테스트와 테마 테스트를 통과했으며, 빌드가 성공했다는 신호가 필요합니다. 여기에 한 가지를 더하면 운영 판단이 훨씬 선명해집니다. 바로 빌드 산출물에서 오늘 만든 slug가 실제로 포함되었는지 확인하는 일입니다.

빌드 산출물 리뷰는 거창한 코드 리뷰가 아닙니다. 새 글의 파일명, 공개 URL, .next 내부 흔적, 목록 페이지 노출 여부가 모두 같은 slug를 가리키는지 보는 작은 점검입니다. 자동화가 매일 한 번 실행되고 실패 시 다음 시간대에 재시도될 수 있는 환경에서는 이 점검이 중복 발행과 공개 혼선을 줄여 줍니다. 이 글은 Futory의 바이브코딩 운영 흐름에서 빌드 산출물 리뷰를 어떻게 가볍고 반복 가능한 루틴으로 만들지 정리합니다.

빌드 산출물 리뷰가 필요한 이유

Markdown 기반 블로그의 장점은 단순함입니다. 파일 하나를 추가하고 빌드하면 페이지가 만들어집니다. 하지만 단순한 구조일수록 운영자는 각 단계의 경계를 명확히 해야 합니다. 파일은 존재하지만 수집 로직에서 빠질 수 있고, 테스트는 통과했지만 라우팅 산출물에 반영되지 않을 수 있으며, 빌드는 성공했지만 PM2 프로세스가 오래된 상태를 들고 있을 수 있습니다.

빌드 성공은 포함 성공과 다르다

npm run build가 성공했다는 말은 프로젝트가 현재 상태로 빌드 가능하다는 뜻입니다. 그러나 오늘 작성한 글이 실제 페이지 묶음에 들어갔는지는 별도의 신호로 확인하는 편이 안전합니다. 예를 들어 ai-blog-build-artifact-review-routine이라는 slug를 만들었다면 빌드 뒤 .next 산출물에서 같은 문자열을 찾을 수 있어야 합니다. 이 검색은 짧지만, 파일 생성과 페이지 생성 사이의 연결을 확인하는 실용적인 증거가 됩니다.

운영 보고서의 기준점을 하나로 만든다

발행 보고서에는 제목, 날짜, 파일 경로, 공개 URL, 테스트 결과, 빌드 결과, PM2 재시작 결과가 들어갑니다. 이 항목들이 서로 다른 이름을 쓰면 다음 실행에서 상태를 판단하기 어렵습니다. 빌드 산출물 리뷰는 모든 항목을 slug 하나에 묶는 역할을 합니다. 오늘의 slug가 파일명에도 있고, .next에도 있고, 공개 상세 URL에도 있으면 운영자는 같은 대상을 보고 있다는 확신을 얻습니다.

Futory에서 적용하는 점검 순서

Futory의 반복 발행에서는 먼저 KST 기준 오늘이 평일인지 확인하고, deterministic random으로 선택된 시간인지 확인합니다. 그다음 오늘 날짜가 frontmatter나 파일명에 이미 있는지 검색해 중복 생성을 막습니다. 이 기본 안전장치를 통과한 뒤에야 최근 글을 읽고 새 주제를 정합니다.

백업 다음에 파일을 추가한다

새 Markdown 파일을 만들기 전 content/posts 전체를 백업하는 이유는 단순합니다. 자동화는 빠르지만, live content tree를 직접 다룹니다. 백업이 있으면 글 생성 뒤 테스트나 빌드에서 예상치 못한 문제가 생겨도 변경 범위를 되돌릴 기준이 생깁니다. 백업은 글의 품질과 별개로 운영 신뢰를 높이는 안전장치입니다.

테스트, 빌드, 산출물 검색을 한 묶음으로 본다

파일을 만든 뒤에는 npm run test:content, npm run test:theme, npm run build 순서로 확인합니다. 콘텐츠 테스트는 frontmatter와 글 구조를, 테마 테스트는 화면 규칙과 스타일 호환성을, 빌드는 Next.js가 실제 페이지를 만들 수 있는지를 봅니다. 그다음 .next에서 slug를 검색하면 “빌드가 됐다”에서 “오늘 글이 빌드에 들어갔다”로 증거 수준이 올라갑니다.

공개 검증과 연결하기

산출물 리뷰는 공개 검증의 전 단계입니다. .next에 slug가 있어도 PM2 재시작이 실패하면 독자는 새 글을 보지 못할 수 있습니다. 반대로 PM2 재시작이 성공해도 캐시된 목록을 보면 반영이 늦어 보일 수 있습니다. 그래서 공개 검증은 상세 페이지와 목록 페이지를 나누어 확인해야 합니다.

상세 페이지는 직접 접근 가능성을 확인한다

먼저 /posts/<slug>가 200을 반환하는지 확인합니다. 이 단계에서는 cache-busting query string과 Cache-Control: no-cache 헤더를 함께 사용하면 오래된 응답을 새 상태로 착각할 위험을 줄일 수 있습니다. 상세 페이지가 200이면 적어도 직접 URL은 열리는 상태입니다.

목록 페이지는 발견 가능성을 확인한다

홈, /posts, /vibe-coding 목록은 독자가 새 글을 발견하는 통로입니다. 목록 검증에서는 오늘 날짜나 slug, 제목 일부가 응답에 포함되는지 확인합니다. 상세 페이지는 열리는데 목록에 보이지 않는다면 정렬, 목록 생성, 캐시 문제로 범위를 좁힐 수 있습니다. 상세도 목록도 실패한다면 빌드 경로, 프로세스 재시작, 프록시 상태를 다시 보는 편이 좋습니다.

자주 묻는 질문

.next를 검색하는 것만으로 충분한가요?

충분하지는 않지만 매우 좋은 중간 신호입니다. .next 검색은 새 글이 빌드 산출물에 포함되었는지 확인합니다. 하지만 공개 성공까지 말하려면 PM2 재시작과 공개 URL 검증이 이어져야 합니다. 즉 산출물 리뷰는 공개 검증을 대체하는 절차가 아니라, 공개 검증 전에 실패 범위를 줄이는 절차입니다.

빌드 산출물에 slug가 없으면 새 글을 다시 만들까요?

아닙니다. 오늘 날짜 파일이 이미 만들어졌다면 새 글을 추가하지 말고 같은 파일을 기준으로 원인을 봐야 합니다. 파일 경로, frontmatter, 콘텐츠 수집 로직, 빌드 로그를 확인하는 것이 우선입니다. 같은 날짜로 새 slug를 만들면 운영 보고서와 공개 URL이 갈라져 중복 문제가 생깁니다.

이 루틴을 매일 반복하면 시간이 너무 걸리지 않나요?

대부분의 시간은 기존 테스트와 빌드가 차지합니다. slug 검색과 공개 목록 확인은 짧은 단계입니다. 오히려 이 작은 점검을 생략하면 실패했을 때 어느 단계가 문제인지 찾는 데 더 많은 시간이 듭니다. 반복 발행에서는 빠른 작성보다 빠른 원인 분리가 더 중요할 때가 많습니다.

결론

빌드 산출물 리뷰는 Futory의 AI 블로그 자동화에서 파일 생성과 공개 검증을 이어 주는 실용적인 중간 단계입니다. 오늘의 slug가 Markdown 파일, .next 산출물, 공개 URL, 목록 페이지 검증에 일관되게 나타나면 발행 상태는 훨씬 명확해집니다. 반대로 이 연결이 끊기면 테스트가 성공해도 독자 화면을 확신하기 어렵습니다.

바이브코딩의 좋은 운영은 빠르게 만들고, 작게 검증하고, 같은 기준으로 보고하는 데서 나옵니다. 매일 한 편을 안정적으로 공개하려면 새 글을 쓰는 능력뿐 아니라 새 글이 빌드와 공개 화면에 실제로 연결되었는지 확인하는 습관이 필요합니다. 빌드 산출물 리뷰는 그 습관을 자동화 안에 넣는 가장 작은 방법입니다.