웹팩(webpack), webpack-dev-server

웹팩

웹 모듈 번들러

• 복잡한 자바스크립트 파일을 패키징해주며 파일 압축을 지원하여 스크립트 성능이 더욱 최적화되는 도움을 준다.
• 관련된 리소스들을 브라우저에서 사용할 수 있는 번들로 묶고 패킹을 하게 된다.
• "애플리케이션 동작과 관련된 여러 개의 파일(HTML, CSS, JS, 이미지 등)들을 1개의 자바스크립트 파일 안에 다 넣어 버리고, 해당 자바스크립트 파일만 로딩해도 웹 앱이 돌아가게 하자"는 취지

자바스크립트 코드가 많아지면 하나의 파일로 관리하는데 한계가 있다. 그렇다고 여러개 파일을 브라우저에서 로딩하는 것은 그만큼 네트웍 비용을 치뤄야하는 단점이 있다. 뿐만 아니라 각 파일은 서로의 스코프를 침범하지 않아야 하는데 잘못 작성할 경우 변수 충돌의 위험성도 있다. 함수 스코프를 사용하는 자바스크립트는 즉시호출함수(IIFE)를 사용해 모듈을 만들 수 있다. CommonJS나 AMD 스타일의 모듈 시스템을 사용하면 파일별로 모듈을 관리할 수도 있다.
그러나 여전히 브라우저에서는 파일 단위 모듈 시스템을 사용하는 것은 쉽지 않은 일이다. 모듈을 IIFE 스타일로 변경해 주는 과정 뿐만 아니라 하나의 파일로 묶어(bundled) 네트웍 비용을 최소화 할수 있는 방법이 웹 프로트엔드 개발 과정에는 필요하다.

웹팩은 이러한 배경에서 이해할 수 있다. 기본적으로 모듈 번들러로 소개하고 있는 웹팩의 주요 네 가지 개념을 정리해 보자.

 

 

엔트리, 아웃풋, 로더, 플러그인

엔트리

웹팩에서 모든 것은 모듈이다. 자바스크립트, 스타일시트, 이미지 등 모든 것을 자바스크립트 모듈로 로딩해서 사용하도록 한다.

위 그림처럼 자바스크립트가 로딩하는 모듈이 많아질수록 모듈간의 의존성은 증가한다. 의존성 그래프의 시작점을 웹팩에서는 엔트리(entry)라고 한다.

웹팩은 엔트리를 통해서 필요한 모듈을 로딩하고 하나의 파일로 묶는다.

 

아웃풋

엔트리에 설정한 자바스크립트 파일을 시작으로 의존되어 있는 모든 모듈을 하나로 묶을 것이다. 번들된 결과물을 처리할 위치는 output에 기록한다.

 

로더

웹팩은 모든 파일을 모듈로 관리한다고 했다. 자바스크립트 파일 뿐만 아니라 이미지, 폰트, 스타일시트도 전부 모듈로 관리한다. 그러나 웹팩은 자바스크립트 밖에 모른다. 비 자바스크립트 파일을 웹팩이 이해하게끔 변경해야하는데 로더가 그런 역할을 한다.

로더는 test와 use키로 구성된 객체로 설정할 수 있다.

• test에 로딩할 파일을 지정하고
• use에 적용할 로더를 설정한다

babel-loader

가장 간간한 예가 바벨이다. 

개발자들이 많이 사용하는 JS ES6문법을 지원하지 않는 인터넷 익스플로러나 구형 브라우저를 사용하는 사용자들도 많다. 이러한 문제점을 해결할 수 있는 것이 바로 webpack babel이다. webpack babel은 최신 사양의 자바스크립트 문법 코드를 IE나 구형 브라우저에서도 동작하는 ES5 이하의 코드로 변환(트랜스파일링)을 지원한다. ES6에서 ES5로 변환할 때 바벨을 사용할수 있는데 test에 ES6로 작성한 자바스크립트 파일을 지정하고, use에 이를 변환할 바벨 로더를 설정한다.

css-loader, style-loader

예제를 하나더 살펴보자. 웹팩은 모든 것을 모듈로 다루기 때문에 CSS 파일을 자바스크립트로 변환해서 로딩해야 한다. css-loader가 그런 역할을 하는 로더이다.

css-loader를 적용한 뒤 번들링하면 다음처럼 CSS 코드가 자바스크립트로 변환된 것을 확인할 수 있다.

 

플러그인

웹팩에서 알아야할 마지막 개념이 플러그인이다. 로더가 파일단위로 처리하는 반면 플러그인은 번들된 결과물을 처리한다. 번들된 자바스크립트를 난독화 한다거나 특정 텍스트를 추출하는 용도로 사용할 수 있다.

UglifyJsPlugin

UglifyJsPlugin은 로더로 처리된 자바스크립트 결과물을 난독화 처리하는 플러그인이다.

난독화는 컴퓨터는 이해하지만 사람들이 이해하기 어렵게 변경하는 작업이다. 난독화를 하는 이유는 코드에 중요한 내용을 보호하기 위해서이기도 하며, 브라우저 상에 그대로 노출이 되기 때문에 누군가에게 복제가 될 수도 있기 떄문이다. 웹팩 4 이상부터는 모드 옵션에서 production으로 빌드하면 자동적으로 난독화가 이루어지지만, 3 이하부터는 uglify-js같은 난독화 전용 플러그인을 설치해준다.

ExtractTextPlugin

마지막으로 플러그인을 하나 더 살펴보자.

CSS의 전처리기인 사스(SASS)를 사용하려면 어떻게 해야할까? 기존의 CSS파일을 사스 파일로 변경해서 코딩한 뒤 웹펙에서는 사스로더(sass-loader)만 추가하면 될 것이다. 이 역시 bundle.js 파일에 포함될 것이다.

만약 사스 파일이 매우 커진다면 분리하는 것이 효율적일 수 있다. bundle.js 파일이 아니라 style.css 파일로 따로 번들링 한다는 말이다. 이때 사용하는 것이 extract-text-webpack-plugin이다.

 

정리

웹팩은 기본적으로 모듈 번들러다.

의존성 그래프에서 엔트리로 그래프의 시작점을 설정하면 웹팩은 모든 자원을 모듈로 로딩한 후 아웃풋으로 묶어준다. 로더로 각 모듈별로 바벨, 사스변환 등의 처리하고 이 결과를 플러그인이 받아 난독화, 텍스트 추출 등의 추가 작업을 한다.

 

 

webpack-dev-server

실시간 리로드 기능을 갖춘 로컬 웹 서버

 

• 웹팩 설정 파일의 변화를 감지하여 빠르게 웹팩을 빌드할 수 있도록 지원하는 유틸리티이자 Node.js 서버
• 웹팩 설정 파일이 변경되면 브라우저 화면을 자동으로 새로 고침(hot reloading)하고, 바로 다시 웹팩으로 빌드하는 기능을 갖고 있다. (소스 파일을 감시하고 내용이 변경될 때마다 번들을 다시 컴파일한다.)
• npm run build 명령어로 /dist/라는 웹팩 빌드 결과물을 만들지 않고도 npm run dev 명령어를 실행했을 때 마치 웹팩으로 빌드한 것 같은 효과를 얻게된다.
  (npm run dev 명령어로 띄운 서버에서 참조하고 있는 빌드 결과물은 메모리 상에 있다. 파일 시스템에 파일을 읽고 쓰는 시간보다 메모리에 저장하고 읽는 시간이 더 빠르기 때문이다. 따라서 webpack-dev-server를 인 메모리 기반이라고 말한다.)

- 동작원리

1. 서버 실행 시 소스 파일들을 번들링하여 메모리에 저장소스 파일을 감시
2. 소스 파일이 변경되면 변경된 모듈만 새로 번들링
3. 변경된 모듈 정보를 브라우저에 전송
4. 브라우저는 변경을 인지하고 새로고침되어 변경사항이 반영된 페이지를 로드