Webpack 마이그레이션 작업 (v4 -> v5) 및 디버깅, 최적화 공유

올해부터, 데이터 로그 정의 플랫폼 프로젝트를 맡게 되었다.

 

해당 프로젝트는 Node version 10.16.3, webpack v4, react class component와 function component의 산재 등으로, 오래된 프로젝트이다.

 

개편 과정에서 처음 삽을 뜬건, webpack 업그레이드 작업이었다.

 

vite나 rollup 같은 다른 번들러로 교체할 까 생각도 했지만, 해당 프로젝트는 사내 사용자가 많고, 최대한 사이드 이펙트를 줄이기 위해, 기존의 config들을 활용하는 방안이 안정성을 가지기에 좋다고 생각했다.

 

또, 웹팩에 관련된 커뮤니티도 잘 형성되어있고 디버깅에 대해 도움 받을 수 있는 글들도 많아서 마이그레이션 작업을 선택했다.

 

 

https://webpack.kr/migrate/5/

To v5 from v4 | 웹팩

 

docs도 친절하게 잘 나와 있고, 그 과정만 따라가면 어려울 것 없이 진행할 수 있다.

 

사실 docs대로 하면 거의 다 문제없이 되어서, 괜찮지만 그러면 이 글을 쓰는 목적이 없지.

 

내 경우의 오류 경험을 공유하면 좋지 않을까 싶다.

 

나의 경우, 업그레이드 이후, dev-server로 compile도 잘 되었고, 프론트 화면에 문제가 없는 것으로 보였다.

 

각 메뉴들도 잘 눌리고, 라우팅 처리도 잘 되고 해서 생각보다 매끄럽게 진행되었다.

 

딱 한가지, document 페이지에서 문제가 발생했다.

 

해당 메뉴는  ReactMarkdown 이라는 패키지를 사용하는데,

 

정확하게는 ReackMarkdown 의 하위 패키지인 VFile에서 process가 정의되지 않아 발생하는 문제였다.

 

https://github.com/remarkjs/react-markdown/issues/339

Uncaught ReferenceError: process is not defined · Issue #339 · remarkjs/react-markdown

https://github.com/vfile/vfile/issues/38 

Uncaught ReferenceError: process is not defined · Issue #38 · vfile/vfile

 

 

관련된 논의는 해당 이슈에서 진행중이었고, 내가 선택한 해결법은 다음과 같다.

 

 

webpack의 shimming을 이용해서, VFile에 process를 심어주는 것이다.

 

이를 위해서 imports-loader라는 패키지를 설치해야한다.

 

다른 사람들이 많이 사용하는 번들러를 사용하면 이런 점이 좋은 것 같다.

 

나와 같은 문제를 누군가도 겪고, 해결법을 공유할 수 있는 것.

 

이런 해결법을 한글로도 이렇게 적어본다.

 

끝!

 

 

++) 마이그레이션 이후 optimization 옵션 조정으로 빌드 사이즈와 시간을 다음과 같이 단축시킬 수 있었다.

---

📄 Webpack 업그레이드 및 최적화 효과 분석 보고서

1. 개요

본 문서는 Webpack v4에서 v5로 업그레이드 및 이후 최적화 작업을 통해 빌드 성능 및 번들 크기 개선 효과를 수치화하여 비교 분석한 자료입니다.

---

2. 비교 항목별 성능 변화

항목	Webpack v4	Webpack v5 (초기)	Webpack v5 (최적화)
빌드 사이즈	6.25 MB	6.08 MB	5.96 MB
빌드 시간	103,190 ms	157,223 ms	80,294 ms

---

3. 향상률 분석

항목	v4 → v5 (초기) 변화율	v5 (초기) -> v5 (최적화)	v4 -> v5 (최종) 향상률
빌드 사이즈	2.72% 감소	1.97% 추가 감소	총 4.64% 감소
빌드 시간	52.37% 증가 (악화)	48.94% 단축	최종 22.2% 단축

 

---

4. 요약 및 결론

• 빌드 번들 사이즈는 전체적으로 4.64% 감소,
  → 최종 산출물 크기 절감에 따른 배포 효율 향상 기대
• 빌드 시간은 최적화 이전에는 증가했으나,
  최적화 적용 후 오히려 기존 v4 대비 22.2% 빠르게 단축됨
• Webpack 5 업그레이드와 함께 최적화 전략 병행 시
  → 빌드 효율성 및 배포 체감 속도 모두 개선 효과를 확인함.

---

5. 추천 사항

• Webpack 5 최적화는 필수 요소이며,
  • TerserPlugin 설정 강화
  • 코드 스플리팅 최소화
  • 캐시 디렉토리 활용
  • 파일시스템 캐시(cache: filesystem) 적용 등은
    → 모든 환경(Jenkins/Local)에서 성능 이점을 보장함.'

---

✅ 최적화를 이룬 가장 큰 요소 Top 3

1. 코드 스플리팅 제거 (splitChunks: false, runtimeChunk: false)

• 가장 핵심적인 영향 요인입니다.
• Webpack 5에서 기본적으로 동작하는 코드 스플리팅(rich chunking)은 빌드 결과를 작게 만들어주는 효과도 있지만, 엔트리와 청크 간 의존 분석, 청크 분리, 병렬 최적화 처리 등으로 인해 빌드 시간이 크게 늘어납니다.
• 이를 제거하고 단일 번들(bundle.js)로 고정하면서 복잡한 청크 처리 과정을 제거한 것이 빌드 시간 개선에 가장 큰 영향을 주었습니다.

💡 결과적으로 “청크 최적화 → 제거”가 빌드 시간 최적화에 가장 핵심 역할.

---

2. TerserPlugin 설정 최적화

• drop_console, drop_debugger, parallel: true 등 압축 단계의 병렬화 및 불필요 코드 제거 설정도 빌드 시간 및 번들 크기 감소에 기여.
• 특히 extractComments: false 설정은 주석 추출을 막아 빌드 산출물에 불필요한 추가 파일 생성을 방지함.

💡 번들 크기를 줄이고 압축 효율을 높여 크기와 파일 수 감소에 직접적인 기여

---

3. Babel Loader 캐시 (cacheDirectory: true) 및 Webpack Filesystem Cache

• 재빌드 속도를 획기적으로 줄이는 보조요소
• babel-loader의 cacheDirectory 옵션과 webpack.cache: { type: 'filesystem' }는 Jenkins나 Local 빌드에서 변경 없는 모듈을 캐시 처리하여 전체 빌드 프로세스를 단축.

💡 “재컴파일 속도 단축” 측면에서 꾸준히 큰 효과

---

🎯 최종 결론

빌드 시간 최적화에 가장 큰 기여를 한 요소는 “코드 스플리팅 제거”이며,
번들 사이즈 최적화에는 “TerserPlugin 압축 최적화”가 가장 큰 역할을 했습니다.