CI MDX 컴파일 결과 캐시 도입

배경

#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를 빌드 타임 렌더로 전환하는 시점에 착수하는 것을 권장하며, 이 이슈는 그 트리거용 트래킹입니다.

Start with loader.ts, sync-blog.mts, and the existing Vite configuration to trace how blog Markdown reaches @mdx-js/rollup. Then inspect integration.yml and deploy.yml for the cache steps. Done means unchanged content avoids recompilation, content changes invalidate only their entries, plugin or option changes invalidate the cache, and both workflows restore and save .cache/mdx.