Webpack 사용방법과 기능 요점 정리

Webpack의 정의와 사용방법 요점 정리 – part 2

Webpack 설정과 사용 방법은 아주 다양할 수 있지만 이 글에서는 가장 보편적인 사용법과 핵심만 중점으로 짚어 보도록 하겠다.

*** 웹팩이 무엇인지 궁금하신 분은 여기로 : 웹팩 1편 (Webpack 정의와 필요성, 그리고 장단점)

인스톨

우선 Webpack을 인스톨하고 (물론 노드와 npm 이미 상주라고 가정하에; 참고로 Webpack 5를 실행하려면 최소 Node.js 버전 10.13.0(LTS)이 필요)

Webpack install
npm i webpack webpack-cli webpack-dev-server -D

이것이 Webpack 인스톨의 가장 간소한 핵심이라고 본다. 사실 웹팩은 configuration 없이도 실행가능하다. 그럴 경우에 webpack은 프로젝트의 엔트리 포인트를 src/index.js으로 가정하고, 프로덕션을 번들을 dist/main.js로 내보낸다. 하지만 이에 대한 실제 이용도와 현실성은 의문이니 그냥 알고만 있자.

Config 파일들 조정

configuration 조정은 두 군데에서 할 수 있다: package.json & webpack.config.js

package.json

"scripts": {
     "build": "webpack", 
     "dev": "webpack serve"
  },

webpack.config.js

Webpack.config.js 파일을 root 디렉토리에 만들고 설정 시작한다. 웹팩 설정이 정확히 동일한 경우는 없지만 다음과 같은 핵심 요소들이 있다.

Webpack config 파일 구조 분석을 통한 4가지 주요 속성 이해

webpack anatomy

Entry

Webpack | Entry

웹팩을 실행할 대상 파일, 그 진입점과 경로 정의. 보통 웹 애플리케이션의 전반적인 구조와 내용이 들어있어 있는 메인 JS 파일을 지정한다. 

유형: single이나 array

Output

Webpack | Output

웹팩을 실행 후 결과물의 파일 경로 — filename과 path 설정한다.

Loader

Webpack | Loader

loader는 특정 파일을 해석하고 변환하는 작업 담당이다. 즉 HTML, CSS, 이미지나, font 같은 asset 파일들을 웹팩이 인식하고 할 수 있도록 해주는 것을 loader가 맡아서 해준다. 각 객체에는 적어도 2개의 속성을 입력한다:

  • test: 로더를 적용할 “파일 유형” (CSS, JS..등등)
  • use: 로더 이름

참고로, 다수의 로더를 적용해야 할 때는 적용 법칙이 오른쪽에서 -> 왼쪽 순인 관계로, 로더 나열의 “순서”에 주의해야 한다. (위의 예를 보자면, ‘sass-loader’, ‘css-loader’, ‘styles-loader’ 순으로 적용되니, 올바르게 나열되어있다.)

많이 쓰이는 로더 종류와 인스톨 방법

  • files: npm install file-loader -D
  • CSS: npm i css-loader -D
  • SASS: npm i sass-loader sass -D
  • Babel: npm install babel-loader @babel/core @babel/preset-env -D
  • TypeScript: npm i typescript ts-loader -D

Plugins

plugins

웹팩 실행시 원하는 추가적인 기능을 추가 할 수 있는 옵션이다.

자주 사용하는 플러그인

마지막으로

devServer와 devtool 그리고 mode(웹팩 실행 모드)

devServer: 프록시(Proxy) 등 설정

devserver

devtool

devtool

HMR(Hot Module Replacement)
HMR를 통해 웹팩으로 빌드한 결과물이 웹 애플리케이션에 실시간으로 반영되므로 간편하다.

소스 맵(Source Map) 
성능 최적화를 위해 HTML, CSS, JS와 같은 웹 자원들을 압축하여 배포하는 관계로, 배포 후 에러 생성 시 디버깅이 힘들다. 이 문제의 도움을 주는 것이 Source Map이다. Source Map을 사용함으로써 배포된 빌드 파일과 원본 파일을 연결 추적이 가능하다.

Mode

mode

웹팩 실행 모드에는 세가지 종류가있다: none, development, production

기본 값을 지정해주지 않을 경우 default로 production모드로 지정되는데, 각 모드에 따라 웹팩 실행 결과물이 달라지게 설정할수있는 기능이 핵심이다.

  • development: 말 그대로 개발 모드
  • production: 배포 모드; 성능 최적화를 위해 기본적인 파일 압축 등의 빌드 과정이 추가된다. 

이외에 참고로,

Webpack 외의 번들러들

Webpack이 현재에도 단연 선두를 달리고 있는 번들러이지만, 이 외에 Parcel(“설정 불필요”라는 관계로 선호됨), Rollup과 Vite 등이 있는데, 이 중 Vite의 최근 성장(Vitepress, SvelteKit, Astro과 연관하여)이 주목할만하다. 하지만 ES Module과 TypeScript 서포트 관련 문제를 볼 때 아직 production-ready인지는 개인적으로 의문이다.

번들러의 미래 – 정답은 JS가 아닐 수도?

최근 많은 사람들이 추진하는 더욱 빠르고 효율적인 번들링 대안은 Go나 Rust 같은 보다 더 최적화된 언어를 사용하는 것. 이런 방법으로 나온 가장 주목할만한 두 가지 도구는 esbuild 및 SWC인듯하다. 만일 이 방법이 안정/선호된다면 – 그때 아마도 우리에게 Webpack이 더 이상 필요하지 않을 수 있다.

마무리하며…

WebPack은 단순히 JavaScript ecosystem의 혼란 상황 해결의 필요성에 대응하여 출현된 빌더이다. 이 글을 읽으며, 진정 “개발” 이외에 현재 모던 웹 개발 시 알아야 기술(Git, CI/CD 등) 증가 추세를 볼 때 다시 한번 심란 해질 수도 있지만, 사실 이것은 우리 인간들의 끊임없이 더 새롭고, 더 빛나고, 더 나은 것을 추구하는 성향과 연관이 있지 않을까 한다. 아무튼, 나를 포함한 다수의 개발자와 마찬가지로 웹팩 사용이 까다롭게 느껴지면, 이러한 tooling 없이 선택한 언어(React, Angular, Vue 등)가 제공하는 기존 상용구를 사용하여 프로젝트 구축하는 것을 우선으로 하고, 그다음 필요할 때 천천히 웹팩을 습득하는 것도 권장한다.

한편으로 보면 이 21세기 시대에는 완벽한 “정복/정석”이나 일률적 랭킹을 추구하던 20세기와는 달리, 유연성과 포용성, 그리고 주어진 상황 반영하여 가장 현실적이고 현명한 길을 선택하는 주체성이 더욱 필요하지 않나-하는 생각이 든다. 말하자면 “수학의 정석”과 multiple choice의 시대—선호했건 아니건—는 이제 더 이상 적용하기가 힘들다. 특히 테크 분야에 있어서는, 깊은 리서치와 경험을 토대로 상황에 따라, 그리고 트렌드보다는 주어진 프로젝트의 여건과 목표를 고려하여, 가장 효율적인 유연 적절한 로드맵을 추구하는 리드 소프트웨어/cloud/웹 개발자들의 소임이 아닌가 싶다. 물론– 그것을 현실적으로 실행 가능하지 않은 경우가 많은 것이 안타깝긴 하다만.

관련 있는 글