번들링과 웹팩

아기코린이·2022년 7월 25일

들어가기

이번 블로깅은 내가 만든 웹 어플리케이션을 배포하기 위한 첫번째 단계 번들링에 관한내용이다. 번들링 툴인 웹팩에 대해 알아보자!

번들링

웹팩에 대해 알아보기 전에 웹팩을 사용하는 이유인 번들링에 대해 알아보자!

번들링은 실질적으로 여러 제품이나, 코드, 프로그램을 묶어서 패키지로 제공하는 행위를 의미한다.

프론트엔드 개발자에게 번들링은 “사용자에게 웹 애플리케이션을 제공하기 위한 파일 묶음"을 만드는 과정이다. 사용자가 브라우저를 열고 주소를 입력하면, 해당 주소에서 프론트엔드 개발자가 번들링한 여러 파일을 받는다. 이 파일을 브라우저가 실행하여 멋진 웹 애플리케이션을 사용자에게 제공하게 된다.

그런데 꼭 번들링은 꼭 필요한 과정일까? 내가 작성한 HTML, CSS, JavaScript 파일을 그대로 전송하는 것이 무슨 문제가 있을까? 문제는 없다. 하지만, 아래와 같은 상황들이 일어나 어려움에 처할 수 있다.

두 개의 .js 파일에서 같은 변수를 사용하고 있어서, 변수 간 충돌이 일어났다.
딱 한 번 불러오는 프레임워크 코드가 8MB라서, 인터넷 속도가 느린 국가의 모바일 환경에서 사용자가 불편을 호소한다.
번들 파일 사이즈를 줄이기 위해서 파일의 공백을 모두 지웠는데, 가독성이 너무 떨어져서 코딩하기가 어렵다.
배포 코드가 너무 읽기 쉬워 개발을 할 줄 아는 사용자가 프론트엔드 애플리케이션을 임의로 조작하여 피해가 발생했다.

webpack

Webpack이란 여러 개의 파일을 하나의 파일로 합쳐주는 모듈 번들러를 의미한다. 모듈 번들러란 HTML, CSS, JavaScript 등의 자원을 전부 각각의 모듈로 보고 이를 조합해 하나의 묶음으로 번들링(빌드)하는 도구다.

모듈 번들러(Module Bundler)의 등장

모던 웹으로 발전하면서 JavaScript 코드의 양이 절대적으로 많이 증가했고, 또 대규모의 의존성 트리를 가지고 있는 대형 웹 애플리케이션이 등장하므로써 세분화된 모듈 파일이 폭발적으로 증가했다. 이 모듈 단위의 파일들을 호출을 해 브라우저에 띄워야 하는데, JavaScript 언어의 특성에 따라 발생하기 쉬운 각 변수들의 스코프 문제를 해결해야 하고, 각 자원을 호출할 때에 생겨나는 네트워크 쪽의 코스트도 신경써줘야만 했다.

그래서 이런 복잡성에 대응하기 위해 하나의 시작점으로부터 의존성을 가지는 모듈을 모두 추적하여 하나의 결과물을 만들어내는 모듈 번들러가 등장하게 되었다.

Webpack에서의 모듈

Webpack에서의 모듈은 JavaScript의 모듈에만 국한하지 않는다. HTML, CSS, 혹은 .jpg나 .png 같은 이미지 파일들도 전부 포함한 포괄적인 개념이다.

웹팩의 핵심 개념

웹팩 공식문서에서는 아래 항목을 핵심 개념으로 제안하고 있다. 아래 개념에 대해서 제대로 이해하고 있으면, 웹팩의 작동 원리에 대해서 더 쉽게 이해할 수 있다.

entry

일반적인 문맥에서 entry의 뜻은 “입구"다. webpack에서의 entry는 프론트엔드 개발자가 작성한 코드의 “시작점"으로 이해된다. React도 index.js에서 HTML 엘리먼트 하나에 React 코드를 적용하는 것 부터 시작한다. 또한, 실제로 webpack을 사용하기도 했다.

Entry 속성은 Entry point라고도 하며, webpack이 내부의 디펜던시 그래프를 생성하기 위해 사용해야 하는 모듈이다. Webpack은 이 Entry point를 기반으로 직간접적으로 의존하는 다른 모듈과 라이브러리를 찾아낼 수 있다.

  //기본 값
  module.exports = {
      ...
    entry: "./src/index.js",
  };

  //지정 값
  module.exports = {
      ...
    entry: "./src/script.js",
  };

기본 값은 ./src/index.js이지만 webpack 설정에서 이런 식으로 Entry 속성을 설정하여 다른 (또는 여러 entry point)를 지정할 수 있다.

output

Output 속성은 생성된 번들을 내보낼 위치와 이 파일의 이름을 지정하는 방법을 webpack에 알려주는 역할을 한다.

  const path = require('path');

  module.exports = {
      ...
    output: {
      path: path.resolve(__dirname, "docs"), // 절대 경로로 설정을 해야 한다. 
      filename: "app.bundle.js",
      clean: true
    },
  };

기본 출력 파일의 경우에는 ./dist/main.js로, 생성된 기타 파일의 경우에는 ./dist 폴더로 설정된다. 위의 예제에서는 output.filename과 output.path 속성을 사용하여 webpack에 번들의 이름과 내보낼 위치를 알려주고 있다. path 속성을 사용할 때는 path 모듈을 사용해야만 한다.

loader

Webpack은 기본적으로 JavaScript와 JSON 파일만 이해한다. 그러나 loader를 사용하면 Webpack이 다른 유형의 파일을 처리하거나, 그들을 유효한 모듈로 변환해 애플리케이션에 사용하거나 디펜던시 그래프에 추가할 수 있다.

  module.exports = {
      ...
    module: {
      rules: [
        {
          test: /\.css$/,
          use: [MiniCssExtractPlugin.loader, "css-loader"],
          exclude: /node_modules/,
        },
      ],
    },
  };

상위 수준에서 loader는 webpack 설정에 몇 가지 속성을 가진다.

test: 변환이 필요한 파일들을 식별하기 위한 속성
use: 변환을 수행하는데 사용되는 로더를 가리키는 속성
exclude: 바벨로 컴파일하지 않을 파일이나 폴더를 지정. (반대로 include 속성을 이용해 반드시 컴파일해야 할 파일이나 폴더 지정 가능)

여기서 test와 use 속성은 필수 속성이며, 이런 속성을 넣어 규칙을 정하기 위해서는 module.rules 아래에 정의해야 한다. 그저 rules 아래에 정의하면 webpack은 경고를 하게 된다.

plugin

Plugins를 사용하면 번들을 최적화하거나 에셋을 관리하고, 또는 환경변수 주입 등의 광범위한 작업을 수행할 수 있게 된다.

  const webpack = require('webpack');
  const HtmlWebpackPlugin = require("html-webpack-plugin");
  const MiniCssExtractPlugin = require("mini-css-extract-plugin");

  module.exports = {
    ...
    plugins: [
      new HtmlWebpackPlugin({
        template: path.resolve(__dirname, "src", "index.html"),
      }),
      new MiniCssExtractPlugin(),
    ],
  };

플러그인을 사용하기 위해서는 require()를 통해 플러그인을 먼저 요청해야 한다. 그리고 plugins 배열에 사용하고자 하는 플러그인을 추가해야 한다. 대부분의 플러그인은 사용자가 옵션을 통해 지정할 수 있다. 다른 목적으로 플러그인을 여러 번 사용하도록 설정할 수 있기 때문에 new 연산자를 사용해 호출하여 플러그인의 인스턴스를 만들어줘야 한다.

위의 코드에서 html-webpack-plugin은 생성된 모든 번들을 자동으로 삽입하여 애플리케이션용 HTML 파일을 생성해준다. 또한, mini-css-extract-plugin은 CSS를 별도의 파일로 추출해 CSS를 포함하는 JS 파일 당 CSS 파일을 작성해주게끔 지원한다.

아기코린이

이전 포스트

코드스테이츠 프론트엔드 3달차 회고[프론트엔드 39기]

다음 포스트