IT 시행착오··약 5분

카테고리 ‘맨 위 글’이 바뀌지 않을 때…pubDate·빌드·사이트맵을 같이 보는 이유

같은 날 여러 카테고리에 글을 올린 뒤, 카테고리 리드와 sitemap loc 수를 로컬 빌드로 대조한 운영 메모입니다.

노트북으로 코딩·검증하는 장면 — 빌드 산출물·사이트맵 점검 맥락 (cc by-sa 2.0, openverse:flickr)

증상은 미묘했다. 레포에는 새 .md가 있고 npm run build도 성공했는데, 카테고리 페이지를 열면 기대했던 글이 맨 위에 없거나, 사이트맵 URL 개수가 직전 배포와 같아 보였다. 배포 파이프라인이 침묵하는 날이면 더 헷갈린다. 콘텐츠가 안 올라간 건지, 정렬만 안 바뀐 건지 한눈에 안 들어온다.

사실: 로컬 빌드가 말해주는 두 숫자

이 블로그의 카테고리 페이지는 컬렉션을 pubDate 기준으로 정렬해 보여 준다. 따라서 같은 날 여러 편을 넣을 때는 시각까지 포함한 ISO 시각이 리드를 가른다. 2026-08-01 저녁에 올린 7편을 기준으로 로컬에서 카테고리별 최신 슬러그를 다시 집계해 보니, 각 카테고리 리드는 그날 20시대 pubDate를 가진 글이었다. 날짜만 2026-08-01로 두고 시각을 빠뜨리면, 같은 날 오전 글과 동률이 되거나 의도치 않은 순서가 난다.

두 번째 숫자는 사이트맵이다. astro builddist/sitemap-0.xml<loc> 개수를 세면, 새 글·카테고리·정적 페이지가 인덱스 후보에 포함됐는지 대략 보인다. 열람 시점 로컬 산출물에서는 <loc>이 77개였다. 글 7편을 추가했는데 loc가 거의 안 늘었다면, 빌드 캐시·콘텐츠 동기화·경로 누락을 의심하는 편이 빠르다. 초록 빌드 ≠ 인덱스 그래프 갱신 확인이다.

이유: ‘파일 존재’와 ‘노출 순서’는 다른 계층

시니어 IT 실무자 시각으로 정리하면, Markdown 추가는 저장소 계층이고, 카테고리 리드는 정렬 계층이며, 사이트맵은 발견 계층이다. 하나라도 어긋나면 “글이 안 보인다”로 뭉개진다. GitHub Actions가 목록에 안 뜨는 날에는 Wrangler로 올리는 것과 별개로, 로컬 dist/를 먼저 열어 카테고리 HTML과 sitemap을 확인하는 습관이 싸게 먹힌다. Notion 쪽에 적어 둔 ‘운영 URL만 있고 프리뷰 URL은 로컬’ 패턴과도 맞물린다. 프리뷰 Workers가 없으면 astro dev --backgrounddist 스모크가 유일한 조기 경보다.

평가: 어디에 쓰고, 어디에 안 쓰는지

쓰는 읽기: 카테고리별 동시 발행·자동화 글쓰기처럼 pubDate를 촘촘히 넣는 워크플로. 안 쓰는 읽기: “빌드만 되면 검색·카테고리 정렬이 자동으로 맞다”는 가정. relatedSlugs 침묵 드롭과 마찬가지로, 스키마·빌더는 의도한 노출까지 보증하지 않는다.

체크리스트는 짧게 유지한다. (1) 새 글 pubDate가 카테고리 내 최신인지, (2) /category/<slug>/ HTML 첫 카드 제목, (3) sitemap-0.xml loc 증가, (4) 그다음 npm run deploy. 순서를 뒤집으면 프로덕션만 보고 헤매기 쉽다.

부연하면, 사이트맵 증가는 SEO 즉시 반영을 뜻하지 않는다. 다만 배포 전 자가 검증으로는 충분하다. 카테고리 리드가 기대와 다를 때는 본문 품질보다 시각 필드·타임존(+09:00) 부터 의심하는 편이 반복 실수를 줄인다. 자동화 실행 로그에는 비밀값 없이 category_lead=… / sitemap_locs=…만 남겨도 다음 장애 때 비교점이 된다.

한 가지 더. 같은 날 보조 카테고리를 여러 편 쓸 때는 유사도·품질 게이트뿐 아니라 노출 순서 게이트를 배포 정의에 넣는 것이 안전하다. 글쓰기 기준의 발행 목적지는 파일이 아니라 사이트에 보이는 글이다.

실측을 한 줄 더 남긴다. 카테고리 리드가 기대와 다를 때 HTML을 저장해 두면, 다음 배포 때 pubDate만 바꿔도 순서가 복구되는지 A/B로 확인할 수 있다. 자동화 로그에 카테고리별 리드 슬러그를 남기는 비용은 낮고, “글이 안 보여요” 문의에 대한 응답 속도는 빨라진다. 사이트맵 loc는 SEO 순위가 아니라 배포 직전 존재 증명으로만 쓴다.

배포 정의에 “콘텐츠 검증” 단계를 명시해 두면, Actions가 살아 돌아오는 날에도 Wrangler 수동 배포 날에도 같은 체크리스트를 재사용할 수 있다.

출처

  • 내부 실측: astro build 후 카테고리별 최신 pubDate 슬러그 집계, dist/sitemap-0.xml <loc> 77개(열람: 2026-08-02)
  • Notion 시드: «리뷰올 오프아이스 구성 설명» — 운영/로컬 검증 분리 요지만 일반화 (제품 실명·비밀 제외)
  • 관련 레포 설정: package.jsondeploy 스크립트(astro build + wrangler deploy)