AI 블로그 자동화에서 목록 페이지 계약을 검증하는 법

요약

Futory처럼 Next.js와 Markdown으로 운영되는 AI 블로그에서는 새 글 상세 URL이 200을 반환하는 것만으로 발행이 끝났다고 보기 어렵습니다. 독자가 실제로 새 글을 발견하는 경로는 대부분 홈, 전체 글 목록, 카테고리 목록입니다. 그래서 평일 자동 발행 루틴은 /posts/<slug> 상세 페이지뿐 아니라 /, /posts, /vibe-coding 목록 페이지에 오늘 날짜나 slug가 반영됐는지 확인해야 합니다.

목록 페이지 계약은 “새 Markdown 파일 하나가 블로그의 발견 경로 전체에 나타나야 한다”는 운영 약속입니다. 이 계약을 분리해 두면 빌드 성공, PM2 재시작 성공, 상세 페이지 접근 성공 이후에도 목록 생성이나 캐시 계층에서 생길 수 있는 문제를 놓치지 않습니다. 이 글은 Futory의 바이브코딩 자동화에서 목록 페이지 계약을 실무적으로 검증하는 방법을 정리합니다.

왜 상세 페이지 확인만으로 부족한가

상세 URL은 새 글이 라우팅 가능한지 확인하는 가장 직접적인 증거입니다. 하지만 블로그 운영에서 중요한 것은 “주소를 아는 사람이 열 수 있는가”와 “목록을 보는 독자가 발견할 수 있는가”를 나누어 보는 일입니다. 전자는 라우트와 Markdown 파싱의 문제이고, 후자는 정렬, 필터링, 카테고리 매핑, 빌드 산출물, 공개 캐시의 문제입니다.

발견 경로가 발행 품질을 결정한다

Futory의 독자는 새 글 URL을 미리 알지 못합니다. 홈에서 최신 글을 보거나, /posts에서 전체 목록을 훑거나, /vibe-coding에서 바이브코딩 카테고리 글을 찾습니다. 따라서 자동 발행 보고서에는 상세 페이지 200과 함께 목록 페이지 반영 여부가 들어가야 합니다. 목록에 보이지 않는 글은 기술적으로 존재하더라도 운영적으로는 반쯤 발행된 상태입니다.

목록은 여러 규칙이 동시에 작동한다

Markdown 파일의 frontmatter 날짜, category, tags, slug, 빌드 시점의 콘텐츠 수집 로직이 모두 목록에 영향을 줍니다. 예를 들어 상세 페이지는 열리지만 카테고리 값이 잘못되어 /vibe-coding에 빠질 수 있습니다. 또는 빌드는 성공했지만 공개 런타임이 이전 .next를 보고 있어 목록만 예전 상태로 남을 수도 있습니다. 그래서 목록 검증은 단순 반복이 아니라 다른 종류의 증거입니다.

Futory에서 목록 페이지 계약을 정의하기

목록 페이지 계약은 복잡할 필요가 없습니다. 새 글을 만든 날에는 세 가지 공개 경로가 같은 신호를 보여야 합니다.

1. 홈에는 최신 발행 신호가 있어야 한다

홈(/)은 가장 넓은 진입점입니다. 새 글이 최신 카드나 글 목록에 직접 보이면 좋고, 레이아웃에 따라 제목 대신 slug나 날짜 일부만 보일 수도 있습니다. 자동 검증에서는 한국어 제목 전체보다 오늘 날짜 YYYY-MM-DD 또는 영어 slug를 기준으로 확인하는 편이 안정적입니다. 텍스트가 줄바꿈되거나 HTML 엔티티로 바뀌어도 slug와 날짜는 비교적 흔들리지 않기 때문입니다.

2. 전체 글 목록은 날짜 정렬을 지켜야 한다

/posts는 모든 글의 색인입니다. 여기에서 오늘 날짜 글이 보이면 Markdown 수집과 정렬이 정상적으로 이어진 것입니다. 특히 Futory처럼 하루 한 편 루틴을 유지할 때 전체 목록은 중복 방지의 공개 증거가 됩니다. 같은 날짜 글이 하나만 보이는지까지 사람이 확인하면 더 좋지만, 자동화에서는 최소한 오늘 날짜 또는 새 slug가 응답 HTML에 포함되는지를 확인합니다.

3. 바이브코딩 목록은 category 계약을 확인한다

/vibe-coding은 Futory의 핵심 카테고리 목록입니다. frontmatter의 category: "바이브코딩"이 제대로 해석되지 않으면 상세 글이 있어도 이 목록에서 빠질 수 있습니다. 그래서 카테고리 목록 검증은 frontmatter 계약의 공개 버전입니다. 새 글이 이 페이지에 보이면 카테고리 값, 목록 필터, 빌드 반영이 함께 통과한 것으로 볼 수 있습니다.

자동화 루틴에 넣는 방법

cache-busting을 기본값으로 둔다

목록 페이지는 캐시 영향을 받기 쉽습니다. 검증 요청에는 매번 ?v=timestamp 같은 쿼리 문자열을 붙이고 Cache-Control: no-cache 헤더를 함께 보내는 것이 좋습니다. 이렇게 하면 오래된 HTML을 보고 실패라고 오판할 가능성을 줄일 수 있습니다. Futory의 크론 보고서도 “no-cache 요청으로 확인했다”는 문장을 남기면 운영자가 캐시 문제와 실제 반영 문제를 구분하기 쉽습니다.

상세, 목록, 카테고리를 같은 기준으로 읽는다

검증 기준은 단순해야 합니다. 상세 URL은 HTTP 200을 확인하고, 목록 세 곳은 오늘 날짜 또는 slug 포함 여부를 확인합니다. 제목 전체를 기준으로 삼으면 한글 인코딩, 공백, 디자인 변경에 흔들릴 수 있습니다. 반대로 slug는 파일명, URL, 빌드 산출물, 공개 HTML을 연결하는 공통 식별자라서 자동화에 적합합니다.

실패 보고는 페이지별로 나눈다

목록 검증이 실패하면 “공개 검증 실패”라고만 쓰지 말고 어느 페이지가 실패했는지 나누어야 합니다. /posts/<slug>는 200인데 /vibe-coding만 빠졌다면 category나 카테고리 목록 생성 문제를 의심할 수 있습니다. 홈만 늦게 반영된다면 홈의 최신 글 쿼리나 캐시를 볼 수 있습니다. 페이지별 결과는 작은 블로그에서도 장애 범위를 빠르게 줄여 줍니다.

자주 묻는 질문

상세 페이지가 200이면 검색엔진도 결국 찾지 않나요?

그럴 수도 있지만 운영 검증에서는 충분하지 않습니다. 독자와 검색엔진 모두 내부 링크와 목록 페이지를 통해 새 글을 발견하는 경우가 많습니다. 목록에 노출되지 않는 글은 사이트 안에서 고립될 수 있으므로 상세 200과 목록 반영을 함께 확인해야 합니다.

목록 페이지에서 제목 대신 slug만 확인해도 괜찮나요?

자동화 검증 기준으로는 괜찮습니다. 사람이 읽는 품질 평가는 제목과 설명이 중요하지만, 기계 검증에서는 slug나 날짜가 더 안정적인 신호입니다. 다만 최종 보고서에는 제목, 날짜, 파일 경로, 공개 URL을 함께 남겨 사람이 쉽게 이해할 수 있게 해야 합니다.

세 목록 중 하나만 늦게 갱신되면 다시 글을 만들어야 하나요?

아니요. 새 Markdown 파일과 빌드 산출물에 slug가 확인됐다면 글을 다시 만들면 안 됩니다. 이 경우에는 목록 생성 로직, 런타임 재시작, 캐시 계층을 확인해야 합니다. 같은 날짜의 두 번째 글을 만드는 것은 중복 방지 계약을 깨는 일입니다.

결론

AI 블로그 자동화에서 발행 완료는 파일 생성이나 상세 페이지 200에서 끝나지 않습니다. Futory의 Next.js Markdown 구조에서는 새 글이 홈, 전체 글 목록, 바이브코딩 목록까지 이어져야 독자가 자연스럽게 발견할 수 있습니다. 목록 페이지 계약은 이 발견 경로를 매일 같은 방식으로 확인하게 해 주는 작고 실용적인 기준입니다.

바이브코딩의 장점은 빠르게 만들고 바로 검증하는 데 있습니다. 하지만 빠른 발행일수록 검증 신호를 세밀하게 나누어야 합니다. 새 slug가 .next 산출물에 있고, 상세 URL이 200이며, /, /posts, /vibe-coding에서 오늘 날짜나 slug가 보인다면 오늘의 한 파일은 콘텐츠 원천, 빌드, 런타임, 공개 목록을 모두 통과한 것입니다. 이때 비로소 자동화는 “글을 만들었다”가 아니라 “블로그에 발행했다”고 말할 수 있습니다.