600KB WASM 라이브러리로 인한 번들 비대화 해결 전략

Context

heic2any 라이브러리 사용 시 600KB 규모의 WebAssembly 바이너리가 클라이언트 번들에 포함되는 문제 발생. dynamic import와 next/dynamic을 적용했으나 빌드 타임 정적 분석으로 인해 청크 그룹에 여전히 포함되는 구조적 한계 직면.

Technical Solution

• Web Worker를 별도 엔트리 포인트로 구성하여 메인 번들에서 완전히 격리하고 필요 시에만 로드하는 독립 청크 구조 설계
• new URL('...', import.meta.url) 구문을 활용하여 Webpack이 워커를 개별 파일로 생성하도록 유도하는 전략
• WASM 디코더의 높은 메모리 점유율로 인한 모바일 브라우저 크래시 방지를 위해 동시 실행 워커 수를 2개로 제한하는 큐잉 시스템 구현
• Vite 환경에서 modulePreload: false 설정과 manualChunks 옵션을 조합하여 브라우저의 선제적 프리로드를 차단하고 실제 호출 시점에만 로드하는 격리 방식 적용
• CDN을 통한 스크립트 동적 주입 방식으로 번들 영향도를 제로화하는 최후순위 대체 방안 마련
• 실제 라이브러리 로드 전 base64 테스트 이미지를 활용해 브라우저의 HEIC 네이티브 렌더링 지원 여부를 먼저 판별하는 최적화 로직 추가

Impact

• 라이브러리 크기: ~600KB (WASM 바이너리 ~500KB 포함)
• 동시성 제한: MAX_PARALLEL = 2

Key Takeaway

특정 사용자 액션에서만 필요한 100KB 이상의 대형 라이브러리는 번들러의 정적 분석 대상에서 제외하여 초기 로딩 비용을 최소화하는 격리 설계가 필수적임.