어떤 프로그램을 만들 때 굉장히 많은 자원이 필요할 것이다. 특히 프로젝트가 커질수록 HTML, js 파일, CSS, 이미지, 폰트 등 아주 많은 프론트엔드 자원을 필요로 한다.
그런데 이 수많은 파일들을 그냥 마구잡이로 가져다 쓰다 보면 브라우저가 버거워하거나, 로딩 속도가 느려지거나, 심지어 호환성 문제까지 터질 수 있다. 개발자 입장에서도 이걸 일일이 관리하는 건 꽤나 고생일 것이다.
이때 등장하는 게 바로 '웹팩(Webpack)'이다. 웹팩은 이렇게 복잡하고 방대한 프론트엔드 자원들을 묶어주고(번들링) 웹이 더 빠르고 효율적으로 이해할 수 있게 가공해주는 도구이다.
웹팩을 사용할 때는 로더의 개념도 포함되어있는데, 이에 대해 조금 더 자세히 알아보도록 하자.
1. Webpack(웹팩)
웹팩은 여러 js 파일, CSS, 이미지 등(프론트엔드 자원)을 하나의 번들 파일(bundle.js)로 묶어주는 모듈 번들러이다. 얘는 기본적으로 js 파일만 처리가 가능하기 때문에 JSX, SASS, 이미지 등 웹팩이 이해하지 못하는 다른 파일들을 로더(Loader)라는 외부 도구를 이용하여 웹팩이 이해할 수 있도록 변환해주어야 한다.
쉽게 말해 여러 개의 파일을 하나의 파일로 묶어주는 역할을 하며, 이렇게 하면 웹 애플리케이션의 로딩 속도가 빨라지고 관리하기도 쉬워지는 것이다.
1) 작동 원리
웹팩은 '엔트리 포인트'를 기준으로 시작한다. 이 엔트리 포인트는 웹 애플리케이션의 시작 파일이라고 보면 된다. 웹팩은 이 파일을 읽고 그 파일이 의존하는 다른 파일들을 찾아서 모두 모으게 되는데, 이렇게 모인 파일들은 최종적으로 하나의 번들 파일로 만들어진다. 이 과정에서 웹팩은 각 파일의 타입에 맞는 로더를 사용해 파일을 변환하게 된다.
2) 웹팩이 하는 일
-
모듈을 하나로 묶음 (bundling)
웹팩의 가장 큰 역할은 모듈을 하나로 묶는 것(bundling)이다. 다양한 자원을 웹 브라우저가 한 번에 이해하고 불러올 수 있도록 하나의 파일로 정리해준다. -
파일 의존성 분석 (import, require)
모듈 번들링은 여러 개의 파일을 하나로 묶는 과정인데 import, require 같은 걸 통해 서로 연결된 JS 파일들을 찾아서 하나의 번들 파일로 만들어준다. 그리고 이 과정에서 각 파일의 의존성을 관리해준다. 이를 통해 어떤 파일이 어떤 걸 쓰는지 의존성을 분석해서 누락 없이 처리할 수 있다. -
로더(loader)를 사용하여 다양한 파일 변환 가능
예를 들어 JSX → JS나 Sass → CSS 같은 변환이 가능하다. 이를 위해서는 로더를 사용하는데 로더는 아래에서 더 자세히 살펴보겠다. 이러한 변환을 통해 웹 브라우저가 바로 이해할 수 없던 파일들을 변환해서 사용 가능하게 만든다. -
코드 최적화, 압축, 분할 (plugin 사용)
웹팩은 코드 스플리팅 기능도 제공하는데, 이 기능은 코드 크기를 줄이거나, 필요한 파일만 나눠서 로딩하게 만들어서 성능을 최적화할 수 있다. 그리고 HMR(Hot Module Replacement) 기능을 통해 개발 중에 변경된 내용을 실시간으로 반영할 수도 있다.
Webpack 개념 정리
여러 개의 js, CSS, 이미지 등 파일들(프론트엔드 자원)을 하나로 묶어주는 번들러
웹 프로젝트를 실행 가능한 하나의 파일로 정리해주는 도구
웹사이트를 만들 때 수십개의 파일들이 섞여있는데 이를 그대로 사용자에게 보내면 느리고 복잡하고 브라우저가 제대로 처리 못하기 때문에 필요
→ 여러개의 js 파일을 budle.js 로 묶고 CSS 파일도 하나도 묶고 이미지도 필요한 것만 포함 시켜서 묶음
→ 브라우저가 빠르고 쉽게 읽을 수 있도록 묶어줌
3) 웹팩의 동작 흐름과 DOM의 관계
- 개발자가 작성한 여러 파일을 웹팩이 하나로 압축해 최적화된 파일을 생성한다.
-
브라우저는 HTML을 읽다가(파싱)
<script src="bundle.js">같은 코드를 만나면, 웹팩이 만든 그 번들 파일을 로드하고 실행한다. -
이 번들 안에 들어있는 js 코드는 DOM 요소를 만들거나 수정하고, 버튼 클릭 같은 이벤트 리스너도 등록하게 될 것이다.
-
그 결과로, 브라우저는 DOM을 그리고 사용자와 상호작용할 수 있는 화면을 렌더링하게 된다.
즉, 웹팩(준비자)은 브라우저가 DOM(결과물)을 만들기 전에 필요한 자바스크립트 파일들을 하나로 잘 준비해주는 도구이며, 이렇게 준비된 코드가 DOM을 만들거나 수정하는 역할을 하게 되는 것으로 정리해볼 수 있다.
2. Loader(로더)
로더는 웹팩이 다양한 파일 형식을 처리할 수 있도록 도와주는 도구이다. 자바스크립트 파일뿐만 아니라 CSS, 이미지 파일, HTML 등 다양한 파일을 변환할 수 있다. 로더는 입력받은 파일을 원하는 형태로 변환한 후 새로운 모듈로 출력한다. 웹팩의 번역기라고 보면 이해하기 쉬울 것이다.
1) 사용 방법
로더는 웹팩 기본 설치에 포함되지 않기 때문에 필요한 로더를 외부에서 개발자가 직접 설치해야하는데, 방법은 웹팩 설정 파일인 webpack.config.js에서 로더를 설정해주면 끝이다. 생각보다 간단하다 !
로더는 특정 파일 형식에 맞춰서 설정할 수 있다. 예를 들어 SCSS 파일을 처리하기 위해서는 style-loader, css-loader, sass-loader를 사용할 수 있으며 이렇게 설정된 로더는 웹팩이 파일을 처리할 때 자동으로 적용된다.
로더의 종류는 꽤 다양한데 CSS 파일을 처리하는 css-loader(SCSS → CSS), 이미지 파일을 처리하는 file-loader, 자바스크립트 파일로 변환하는 babel-loader(JSX → JS) 등이 있다. 각 로더는 특정한 역할을 가지고 있어서 필요한 파일 형식에 맞는 로더를 선택해서 사용해야 한다.
2) 로더가 포함된 웹팩의 작동 흐름
-
웹팩이 시작 파일 (mian.js 등)을 분석
-
import된 파일을 하나씩 살펴봄 (
.js,.jsx,.sass,.png등) -
JS가 아닌 파일이면 웹팩은 직접 못 읽기에 지정된 로더에게 전달
-
로더가 해당 파일을 브라우저가 이해할 수 있는 JS/CSS 등 으로 변환
-
변환된 결과를 웹팩이 다시 받아와서 하나의
bundle.js같은 파일로 묶음 -
브라우저는 완성된 파일 (
bundle.js등)만 받아와서 실행
3. 추가 지식 !
❓ 모듈(Module)이 정확히 무엇일까 ..
웹팩을 '모듈 번들러'라고 부른다고 설명했는데, 여기서 말하는 '모듈'이 뭔지 헷갈릴 수도 있을 것 같다. 모듈은 쉽게 말해서 '재사용 가능한 코드 조각'이라고 생각하면 된다.
예전에는 자바스크립트 코드를 하나의 거대한 파일에 다 때려 박거나 <script> 태그로 여러 파일을 덕지덕지 붙이는 식으로 개발했었는데, 이러면 코드가 복잡해지고 변수 이름 충돌 같은 문제도 자주 발생했을 것이다.
그래서 등장한 개념이 바로 모듈이다. 모듈은 특정 기능 단위로 코드를 분리해서 파일 하나하나를 독립적인 모듈(프로그램을 구성하는 독립적인 기능을 수행하는 단위)로 만드는 것이다. 예를 들어 회원가입 기능은 signUp.js, 로그인 기능은 login.js 이런 식으로 말이다. 이렇게 모듈로 나누면 다음과 같은 장점들이 있다.
- 코드 재사용성 증가 : 한 번 만든 모듈은 다른 곳에서도 쉽게 가져다 쓸 수 있다.
- 유지보수 용이 : 특정 기능에 문제가 생기면 해당 모듈만 수정하면 되니 관리가 훨씬 편해진다.
- 코드 충돌 방지: 각 모듈은 독립적인 스코프(범위)를 가지므로 변수 이름 충돌 같은 문제가 줄어든다.
웹팩은 이렇게 쪼개진 수많은 모듈들을 분석해서 필요한 것들만 뽑아 하나의 최적화된 파일로 묶어주는 역할을 하는 것이다. 그 덕분에 개발자는 모듈 단위로 깔끔하게 코드를 작성하고 웹팩이 알아서 최적화된 형태로 만들어주니 결론적으로 개발 효율이 상승하게 된다.
❓그렇다면 플러그인(Plugin)은 무엇일까 ..
웹팩에는 로더 말고도 '플러그인(Plugin)'이라는 또 다른 핵심 도구가 있다. 로더가 파일 하나하나를 변환하는 '번역가' 같은 역할이라면 플러그인은 번들링 과정 전체에 걸쳐 더 큰 그림을 그리는 '매니저'라고 생각하면 이해하기 쉬울 것이다.
플러그인은 번들링된 결과물의 형태를 바꾸거나 특정 작업을 자동화하거나 최적화하는 등 웹팩의 기능을 확장해주는 역할을 한다. 아래는 여러 플러그인들 중 몇 가지의 기능이다. 이외에도 더 많은 기능을 포함한 플러그인들이 있다.
- 번들 파일 최적화 (코드 스플리팅, 트리 쉐이킹 등 사용) : 최종 결과물의 크기를 줄여 로딩 속도를 더 빠르게 만들 수 있다.
- HTML 파일 생성 : 웹팩으로 번들링된 js 파일을 자동으로
<script>태그로 넣어주는 HTML 파일을 만들어주기도 한다. - 환경 변수 주입 : 개발 환경인지, 배포 환경인지에 따라 다른 값을 코드에 넣어줄 수도 있다.
로더와 마찬가지로 플러그인도 필요한 기능을 직접 설치해서 webpack.config.js 파일에 설정해줘야 한다. 웹팩을 제대로 활용하려면 로더와 플러그인의 개념 정도는 모두를 잘 이해하고 사용하는 게 중요하다 !
❓트렌드
요즘 프론트엔드 개발 생태계는 엄청 빠르게 변하고 있어서 웹팩 말고도 Vite처럼 더 빠르고 간편한 빌드 도구들이 많이 등장하고 있다. 왜 이렇게 뜨고 있냐면 개발 서버 구동 속도에서 웹팩보다 압도적으로 빠르다고 한다. (이름부터 Vite '빠른' 이라는 뜻이다.)
웹팩은 프로젝트의 모든 모듈을 다 번들링한 다음에야 서버를 띄우기 때문에 그래서 프로젝트가 크면 클수록 서버 띄우는 데 시간 엄청 걸린다. (보일러플레이트 기준으로 7.8초 정도 걸린다고 한다.) 근데 Vite는 esbuild라는 것으로 미리 번들링해놓고 필요한 모듈만 그때그때 동적으로 가져와서 바로 서버를 띄운다. (그래서 거의 즉각적으로 서버가 켜는데 1.8초면 충분하다고 한다. 확실히 빠르다 ..)
이런 속도 차이 때문에 많은 개발자들이 웹팩 대신 Vite를 많이 쓰는 추세로 바뀌고 있다는데, 그렇다고 웹팩이 완전히 사라지는 건 아니다. 웹팩은 워낙 오래되고 안정화된 도구라 Vite가 빠르긴 해도, 기존 웹팩 프로젝트를 Vite로 마이그레이션하는 게 생각보다 쉽지 않거나 안정성 문제가 거론되기도 한다.
결론적으로 말하면 빠른 빌드 속도가 최우선이고 간단한 앱을 빠르게 만들고 싶다면 Vite를, 복잡하고 서드파티 라이브러리 많은 대규모 앱이라면 웹팩이 안정적이고 추천된다. 그러니까 웹팩이 완전히 대체된다기보다는 프로젝트의 특성과 개발 환경에 맞춰서 더 효율적인 도구를 선택하는 방향으로 가고 있다고 보면 될 것이다 !
