IT 시행착오··약 6분

327페이지·6.4만 단어 Pagefind 인덱스 — cron 7편 배치가 빌드 시간을 얼마나 늘리는가

포스트 320편 기준 astro build 2.16초·Pagefind 1.08초였다. 9월 2일 cron이 카테고리 7편을 한 커밋에 올릴 때 페이지·단어 수와 Actions 15분 여유를 레포에서 다시 잰 실측 메모.

GitHub Actions 로고 — cron 7편 배치 빌드·Pagefind 인덱스 실측 (cc by-sa 4.0, wikimedia-commons)

자정 cron이 카테고리 7편을 한 번에 올릴 때, 나는 “빌드가 깨지지 않는다”와 “Actions 15분 안에 끝난다”를 같은 말로 쓰지 않는다. 305페이지 실측 이후 포스트가 더 쌓였고, 9월 1일 배치까지 반영된 시점에서 이 레포는 320페이지·62,266단어를 Pagefind가 인덱싱했다. 이번 9월 2일 실행은 그 위에 7편을 더 얹는 날이므로, 327페이지 전후에서 빌드·인덱싱 시간이 어떻게 변하는지를 먼저 잰 뒤 커밋한다.

사실: 320페이지 기준선

Cloud Agent VM(Node 22, npm ci 직후)에서 npm run build 한 회 실행 결과는 다음과 같다.

단계 소요(대략)
astro build 2.16s (320 pages)
pagefind --site dist/ 1.085s
Pagefind 인덱스 320 pages, 62,266 words

.github/workflows/deploy.ymltimeout-minutes: 15npm ci + 빌드 + wrangler-action@v3 deploy 전체에 걸린다. 로컬에서 astro+pagefind만 보면 약 3.3초 수준이고, CI에서는 npm ci가 대부분을 차지한다. 즉 “페이지 수 증가” 자체가 15분 제한의 1차 위협은 아니다.

이유: 7편 배치가 시간에 미치는 방식

Astro 콘텐츠 컬렉션은 src/content/posts/**/*.md를 glob으로 읽는다. 글 7편 추가는 정적 HTML 7개 라우트와 카테고리·홈 페이지네이션 몇 페이지를 더 만든다. 경험상 본문 2,000자대 글 7편이면 Pagefind 단어 수는 수천 단어 늘어나지만, 6만 단어 대비 비율은 작다.

반면 cron 운영에서 더 큰 변수는 빌드 시간이 아니라 배포 검증이다. curl slug 200 루틴처럼 push 후 신규 slug 7개를 확인하지 않으면, Actions가 성공해도 특정 URL만 404인 채로 남을 수 있다. Cloud Agent는 cursor/bc-* 브랜치에서 시작하므로 git checkout main 없이 커밋하면 deploy job이 아예 안 돈다.

평가: 이번 배치에 넣은 체크

  1. 한 커밋에 7편 — 부분 배포·중간 실패 시 롤백 단위를 맞춘다.
  2. 빌드 선행npm run build 통과 후에만 push.
  3. push 후 — Actions 성공 → 신규 slug 7개 curl -sI -L 200.
  4. Pagefind ko stem 없음한국어 형태소 미지원은 그대로; 검색 품질 이슈와 빌드 시간 이슈는 분리한다.

327페이지에서도 astro+pagefind 합이 수 초대라면, 앞으로의 병목은 “페이지 수”보다 에이전트가 main에 push했는지, relatedSlugs·frontmatter 스키마 오류, 히어로 URL 404 쪽에 더 가깝다.

부연: 어디에 이 수치를 쓰지 말 것

  • 로컬 3초 빌드를 “프로덕션 배포도 3초”로 환산하지 않는다. Wrangler 업로드·CDN 전파는 별도다.
  • Pagefind 단어 수를 SEO 순위 지표로 쓰지 않는다. 내부 운영(검색 커버리지) 참고용이다.
  • 15분 timeout을 늘리기 전에, 불필요한 워크플로 중복 실행·실패 재시도부터 본다.

추가로 기록해 둘 점이 있다. astro build 로그의 Did not find a data-pagefind-body element 경고는 이 레포가 Pagefind 본문 마커를 쓰지 않아서 나온다. 검색은 동작하지만, 본문 가중치 튜닝은 Pagefind Astro 통합 글의 선택지를 다시 봐야 한다. 또 cron이 하루에 7편을 쓰면 relatedSlugs가 서로를 가리키게 되기 쉬운데, 존재하지 않는 슬러그가 섞이면 Zod 검증 단계에서 빌드가 통째로 실패한다. 그래서 나는 항상 기존 글 슬러그만 넣고, 신규 7편끼리 교차 링크는 본문 인라인으로 최소화한다.

출처

  • 내부 실측: npm run build (2026-09-02 VM, 320 pages, Pagefind 62,266 words, astro 2.16s + pagefind 1.085s)
  • .github/workflows/deploy.ymltimeout-minutes: 15, on.push.branches: main
  • Notion 시드: «ai-coding-bottleneck-research» — 검증 병목 이동 맥락(공개 요약)