AI 블로그 자동화에서 빌드 산출물의 slug 증거를 확인하는 법

요약

Futory처럼 Next.js Markdown 블로그를 AI 에이전트와 크론으로 운영할 때 새 글의 성공 여부는 여러 단계로 나뉩니다. Markdown 파일이 만들어졌는지, 콘텐츠 테스트가 통과했는지, 빌드가 새 글을 실제 라우트 데이터로 받아들였는지, PM2 재시작 뒤 공개 URL이 열리는지는 서로 다른 증거입니다. 이 중 빌드 산출물의 slug 확인은 파일 작성과 공개 검증 사이를 이어 주는 중요한 중간 관문입니다.

slug는 자동 발행에서 가장 안정적인 추적 키입니다. 제목은 한국어이고, 설명은 길며, 목록 HTML은 테마 변경에 따라 달라질 수 있지만 ai-blog-build-artifact-slug-check-routine 같은 slug는 파일명, 내부 링크, 공개 URL, 빌드 산출물에서 반복해서 확인할 수 있습니다. 이 글은 Futory의 바이브코딩 발행 루틴에서 .next 안의 slug 증거를 어떻게 다루면 운영 보고서가 더 재현 가능해지는지 정리합니다.

왜 빌드 산출물 확인이 필요한가

Markdown 파일을 추가하고 npm run build가 성공했다는 사실만으로도 많은 것을 알 수 있습니다. 하지만 무인 발행에서는 한 단계 더 구체적인 증거가 도움이 됩니다. 빌드는 통과했지만 새 글이 예상한 라우트에 포함되지 않았거나, 정적 생성 결과가 오래된 데이터를 참조하거나, 파일명과 slug 규칙이 어긋나는 경우를 조기에 발견할 수 있기 때문입니다.

파일 존재와 라우트 반영은 다르다

content/posts 아래에 새 Markdown이 있다는 것은 원본이 생겼다는 뜻입니다. 반면 .next 산출물 안에 slug가 있다는 것은 Next.js가 그 원본을 읽고 앱의 빌드 결과 어딘가에 반영했다는 뜻입니다. 두 신호를 분리하면 문제가 생겼을 때 원인을 좁히기 쉽습니다. 파일은 있는데 산출물에 slug가 없다면 콘텐츠 로딩 규칙, frontmatter, 경로 필터를 먼저 의심할 수 있습니다.

공개 검증 전에 실패 위치를 좁힌다

PM2를 재시작하고 공개 URL을 확인하는 단계는 운영 런타임까지 포함합니다. 만약 공개 상세 페이지가 404라면 빌드가 새 글을 몰랐던 것인지, 런타임이 새 빌드를 읽지 못한 것인지, 프록시나 캐시 문제인지 구분해야 합니다. 빌드 직후 .next에서 slug를 확인해 두면 공개 실패가 나왔을 때 적어도 “빌드 결과에는 새 글이 들어갔다”는 기준점을 갖게 됩니다.

Futory 루틴에 넣는 slug 산출물 점검

Futory의 평일 발행 루틴은 길고 복잡한 분석을 목표로 하지 않습니다. 새 글 하나를 만들고, 테스트와 빌드를 통과시키고, 공개 표면에서 확인하는 것이 핵심입니다. 따라서 산출물 점검도 짧고 결정적이어야 합니다.

1. 새 파일의 slug를 단일 키로 정한다

slug는 영어 kebab-case 파일명에서 .md를 뺀 값으로 유지하는 것이 좋습니다. frontmatter 제목이나 태그를 기준으로 검색하면 한글 인코딩, HTML escape, 테마 출력 방식에 영향을 받을 수 있습니다. 반면 slug는 /posts/<slug> 공개 URL과 직접 연결되므로 자동화가 같은 값을 계속 사용할 수 있습니다.

2. 빌드 성공 후에만 .next를 검색한다

.next는 빌드 산출물이므로 테스트 전이나 빌드 실패 후에 확인하면 의미가 흐려집니다. 순서는 npm run test:content, npm run test:theme, npm run build, .next slug 확인이 자연스럽습니다. 빌드가 실패하면 PM2 재시작과 공개 검증을 하지 않고 실패 보고서에 멈춘 지점을 남기는 편이 안전합니다.

3. 산출물 증거는 짧게 기록한다

보고서에는 .next contains slug: OK처럼 간단히 남기면 충분합니다. 필요하면 검색된 파일 수나 대표 경로 하나만 덧붙입니다. 중요한 것은 빌드 로그 전체를 붙이는 것이 아니라, 오늘 만든 slug가 빌드 결과에 포함됐다는 판단 가능한 증거를 남기는 것입니다. 이렇게 하면 성공 보고서는 간결하고, 실패 보고서는 재현 가능한 형태가 됩니다.

공개 검증과 함께 보는 방법

빌드 산출물 확인은 공개 검증을 대체하지 않습니다. 오히려 공개 검증을 더 잘 해석하기 위한 중간 증거입니다. Futory에서는 상세 URL, 홈, /posts, /vibe-coding을 no-cache 요청으로 확인하고, 각 표면에서 200 상태와 오늘 날짜 또는 slug 노출을 봅니다.

상세 페이지는 라우트의 최종 확인이다

.next에 slug가 있고 /posts/<slug>가 200을 반환하면 원본 파일, 빌드, 런타임 라우트가 한 줄로 이어졌다고 볼 수 있습니다. 이때 목록 페이지까지 확인하면 독자가 실제로 새 글을 발견할 수 있는지도 검증됩니다. 상세 페이지 200만으로 끝내지 않는 이유는 블로그의 성공이 URL 직접 접근뿐 아니라 목록 노출에도 달려 있기 때문입니다.

목록 실패는 다른 종류의 신호다

상세 페이지는 열리는데 홈이나 카테고리 목록에 보이지 않는다면 새 글 자체보다 정렬, 필터, 캐시, 목록 데이터 생성 방식을 살펴야 합니다. 이때 빌드 산출물 slug 확인은 “글이 빌드에서 누락된 문제는 아닐 가능성이 높다”는 단서를 줍니다. 작은 증거 하나가 장애 분류 시간을 줄이는 셈입니다.

자주 묻는 질문

빌드가 성공했는데도 slug 검색이 꼭 필요한가요?

항상 긴 검색이 필요한 것은 아니지만, 무인 발행 보고서에는 짧은 slug 확인이 큰 도움이 됩니다. 빌드 성공은 앱 전체가 만들어졌다는 넓은 신호이고, slug 확인은 오늘 새 글이 그 결과에 포함됐다는 좁은 신호입니다. 두 신호가 함께 있으면 다음 복구가 빨라집니다.

.next 내부 구조가 바뀌면 어떻게 하나요?

Next.js 버전에 따라 산출물 파일 이름과 위치는 달라질 수 있습니다. 그래서 특정 파일 하나에 의존하기보다 .next 전체에서 오늘 slug 문자열이 발견되는지 확인하는 방식이 더 유연합니다. 검색 자체가 실패하면 그 사실을 보고하고, 공개 상세 페이지와 목록 검증 결과를 함께 보아야 합니다.

slug 대신 제목을 검색해도 되나요?

가능은 하지만 자동화 키로는 slug가 더 안전합니다. 한국어 제목은 HTML 변환, escape, 줄바꿈, 테마 변경의 영향을 받을 수 있습니다. slug는 파일명과 공개 URL에 그대로 쓰이므로 발행 루틴의 공통 키로 삼기 좋습니다.

결론

Futory의 AI 블로그 자동화에서 빌드 산출물의 slug 증거는 작지만 유용한 운영 기준입니다. Markdown 파일이 생겼다는 사실과 공개 페이지가 200을 반환한다는 사실 사이에, Next.js 빌드가 새 글을 실제 산출물에 포함했다는 중간 확인을 놓으면 실패 위치를 더 빠르게 좁힐 수 있습니다.

좋은 바이브코딩 발행 루틴은 화려한 자동 수정보다 단순하고 반복 가능한 증거를 쌓습니다. 오늘의 slug를 정하고, 새 파일 하나만 만들고, 테스트와 빌드를 통과한 뒤, .next에서 slug를 확인하고, PM2 재시작 후 공개 상세와 목록을 no-cache로 검증하는 순서가 매일의 Markdown 운영을 더 믿을 수 있게 만듭니다.