CI MDX 컴파일 결과 캐시 도입

[hyoseong1994]

배경

#91 에서 CI 빌드 캐시(bun install / Playwright / Vite pre-bundle)를 도입합니다. 다만 node_modules/.vite 캐시는 의존성 사전 번들 결과만 재사용할 뿐, 콘텐츠 .md를 @mdx-js/rollup으로 컴파일하는 비용은 캐시하지 못합니다. (remark/rehype 체인 중 특히 rehypeExpressiveCode 코드 하이라이팅이 무겁습니다.)

콘텐츠가 늘어날수록 이 컴파일 비용이 선형으로 증가하므로, 안 바뀐 파일은 재컴파일을 건너뛰는 캐시를 검토합니다.

mermaid는 현재 strategy: "pre-mermaid"(클라이언트 런타임 렌더)라 빌드 캐시 대상이 아닙니다.

현재 변환 흐름

• 콘텐츠: src/content/blog/*.md (현재 7개)
• sync-blog.mts가 prebuild에서 GitHub Discussions를 fetch해 .md를 매번 재생성
• loader.ts의 import.meta.glob으로 전부 로드 → Vite가 빌드 중 @mdx-js/rollup으로 인라인 컴파일 (개별 산출물 파일 없이 번들에 녹아듦)

구현 방안

@mdx-js/rollup을 감싸는 래퍼 Vite 플러그인으로 컴파일 결과를 디스크에 캐싱합니다.

• transform(code, id) 훅에서 id가 콘텐츠 .md이면 sha256(code + 플러그인 버전 + 옵션)을 키로 계산
• .cache/mdx/<hash>.js가 있으면 재사용, 없으면 컴파일 후 기록 (.cache/는 gitignore)
• 키에 플러그인 버전·옵션을 포함해 업그레이드/설정 변경 시 자동 무효화

콘텐츠는 sync-blog으로 매 빌드 재생성되므로, 캐시 키는 CI 스텝의 hashFiles가 아니라 트랜스폼 훅에서 실제 파일 내용으로 계산합니다. 그래야 sync 타이밍과 무관하게 정확합니다.

GitHub Actions 캐시 스텝

integration.yml, deploy.yml에 .cache/mdx 복원/저장 스텝을 추가합니다.

- uses: actions/cache@v4
  with:
    path: .cache/mdx
    key: mdx-${{ runner.os }}-${{ hashFiles('bun.lock', 'vite.config.ts', 'src/content/blog/**') }}
    restore-keys: mdx-${{ runner.os }}-

검증

• 콘텐츠 1개만 수정 시 나머지 파일이 재컴파일되지 않는지 확인
• 플러그인 버전 변경 시 전체 캐시가 무효화되는지 확인

우선순위 메모

현재 콘텐츠 7개 수준이라 컴파일 비용이 미미합니다. 콘텐츠가 유의미하게 늘거나 mermaid를 빌드 타임 렌더로 전환하는 시점에 착수하는 것을 권장하며, 이 이슈는 그 트리거용 트래킹입니다.