Astro 블로그는 정적 사이트라 배포가 단순하다.
하지만 글과 이미지가 늘면 GitHub Actions 빌드 시간이 길어진다.
처음에는 몇 초 차이라 신경 쓰이지 않는다.
그런데 매일 글을 발행하고, OG 이미지를 만들고, 검색 색인까지 생성하면 이야기가 달라진다.
install
build
generate images
generate search index
deploy이 흐름이 매번 반복되기 때문이다.
캐시는 결과물을 저장하는 게 아니다
캐시를 처음 볼 때 가장 흔한 오해는 이렇다.
캐시 = 배포 결과물 보관하지만 보통 GitHub Actions 캐시는 빌드 중간에 다시 쓰기 위한 파일을 보관하는 용도다.
예를 들어:
- 패키지 매니저 다운로드 캐시
node_modules에 가까운 의존성 캐시- OG 이미지 생성 캐시
- 변환된 이미지 캐시
- 도구가 만든 중간 결과
배포 결과물은 gh-pages나 GitHub Pages artifact로 따로 올라간다.
의존성 캐시는 기본이다
가장 먼저 볼 것은 패키지 설치 시간이다.
pnpm을 쓴다면 store 캐시를 재사용하는 식으로 줄일 수 있다.
핵심은 lockfile을 캐시 키에 넣는 것이다.
pnpm-lock.yaml이 바뀌면 새 캐시
그대로면 기존 캐시 재사용의존성이 자주 바뀌지 않는 블로그라면 효과가 꽤 있다.
OG 이미지 캐시는 별도로 본다
Astro 블로그에서 글마다 OG 이미지를 자동 생성한다면,
이 작업은 의존성 설치와 별개로 무겁다.
매번 모든 글의 이미지를 다시 만들면 낭비가 크다.
좋은 기준은 내용 기반 캐시다.
title
description
slug
template version이 값이 같으면 이전 이미지를 재사용하고,
바뀐 글만 다시 생성하는 식이다.
검색 색인은 보통 다시 만드는 편이 단순하다
Pagefind 같은 검색 색인은 빌드된 HTML 전체를 보고 만든다.
그래서 캐시보다 재생성이 단순할 때가 많다.
검색 색인 생성 시간이 아주 길지 않다면:
astro build
→ pagefind index이 흐름을 유지하는 편이 안전하다.
대신 검색 색인이 배포 결과에 빠지지 않는지만 확인하면 된다.
캐시가 깨졌을 때 복구 가능해야 한다
캐시는 있으면 빠르지만 없어도 빌드가 되어야 한다.
이 원칙이 중요하다.
cache hit → 빠른 빌드
cache miss → 느리지만 정상 빌드캐시가 없으면 빌드가 실패하는 구조는 위험하다.
GitHub Actions 캐시는 언제든 지워질 수 있다고 생각하는 편이 안전하다.
캐시 키는 너무 넓어도 너무 좁아도 문제다
캐시 키가 너무 넓으면 오래된 결과를 재사용할 수 있다.
key: astro-cache이런 식이면 무엇이 바뀌어도 같은 캐시를 쓴다.
반대로 너무 좁으면 매번 새 캐시가 생긴다.
key: astro-cache-${{ github.sha }}커밋마다 바뀌므로 재사용 효과가 거의 없다.
보통은 lockfile, 설정 파일, 템플릿 버전처럼 의미 있는 변화 기준을 넣는다.
캐시 대상은 작게 시작한다
처음부터 모든 것을 캐시하려고 하면 디버깅이 어려워진다.
추천 순서는 이렇다.
1. 패키지 매니저 캐시
2. OG 이미지 캐시
3. 필요하면 이미지 변환 캐시
4. 마지막에 특수한 빌드 중간 파일빌드 시간이 어디서 오래 걸리는지 먼저 보고,
가장 큰 작업부터 캐시하는 편이 낫다.
오늘 포인트
Astro GitHub Actions 빌드 캐시는 배포 결과물을 저장하는 기능이 아니다.
반복되는 빌드 중간 작업을 줄이는 도구다.
특히 효과가 큰 곳은 보통 두 군데다.
- 의존성 설치
- OG 이미지 생성
검색 색인은 재생성이 단순하면 그대로 두는 편이 안전하다.
캐시는 빌드를 빠르게 해야지,
빌드를 불안하게 만들면 안 된다.
한 줄 요약
Astro GitHub Actions 캐시는 없어도 빌드가 되게 만들고, 의존성 설치와 OG 이미지처럼 반복 비용이 큰 작업부터 적용하는 게 좋다.