Skip to main content

Command Palette

Search for a command to run...

Webpack, Vite, Rollup 설정 및 커스터마이징 — 프론트엔드 개발자가 알아야 할 진짜 이유

Published
4 min readView as Markdown

프론트엔드 개발을 하다 보면 자연스럽게 접하게 되는 단어가 있다.
바로 Webpack, Vite, Rollup 같은 번들러(Bundle Tool) 들이다.

“빌드 속도가 느리다”, “코드가 너무 커졌다”, “라이브러리로 패키징해야 한다” 같은 문제를 해결하다 보면
결국 이 세 가지 이름으로 다시 돌아오게 된다.
그런데 이 번들러들은 단순히 빌드 도구가 아니라,
프로젝트의 구조와 품질, 배포 효율성까지 결정짓는 핵심 인프라 레벨의 도구다.


🧱 Webpack — 복잡한 빌드 구조를 제어하는 정밀한 도구

Webpack은 오래됐지만 여전히 강력하다.
대규모 프로젝트, 혹은 복잡한 폴더 구조와 커스텀 로더가 필요한 환경에서는
여전히 Webpack이 가장 세밀한 제어를 제공한다.

Webpack을 이해한다는 것은 단순히 webpack.config.js를 고칠 수 있다는 뜻이 아니다.
실제 개발에서는 이런 장면들이 훨씬 많다.

  • SplitChunks 전략을 직접 조정해 공통 벤더 번들을 분리하거나,

  • 빌드 시간이 길어졌을 때 esbuild-loader와 캐시 시스템으로 속도를 단축하고,

  • DefinePlugin으로 런타임 환경변수를 빌드 타임에 주입하는 등.

예를 들어, moment.js처럼 용량이 큰 라이브러리를 교체하거나 불필요한 로케일을 제거할 때는
IgnorePlugin으로 특정 모듈을 무시하거나, dayjs로 대체하기도 한다.

이런 식의 커스터마이징 경험은 단순히 “빌드 툴 설정을 안다”를 넘어서,
서비스 성능을 수치로 개선할 수 있는 능력으로 이어진다.

예시
“Webpack 기반 SPA에서 빌드 시간이 80초 걸리던 문제를 esbuild-loadercache: { type: 'filesystem' } 설정으로 25초 이하로 줄였다.”


⚡ Vite — 빠른 개발 환경과 현대적 DX(Developer Experience)

Vite는 요즘 프론트엔드 프로젝트의 기본값처럼 자리 잡았다.
Webpack이 컴파일 중심의 빌드라면, Vite는 ESM 기반 개발 서버를 통해
“필요한 모듈만 즉시 로드”하는 구조로 훨씬 빠르다.

이 말은 곧 개발 서버를 켜자마자 즉시 반응하는 경험(HMR 성능)으로 이어진다.
Vite를 제대로 이해하면 단순히 “빠르다”를 넘어,
어떻게 빠른지를 설명하고 제어할 수 있게 된다.

예를 들어 이런 설정들이 있다.

  • optimizeDeps.include : 사전 번들링할 대형 의존성을 명시

  • manualChunks : 코드 스플리팅 전략을 수동 제어

  • server.fs.allow : 모노레포 환경에서 symlink된 패키지 접근 허용

  • import.meta.env : 빌드 타임 환경변수 주입

이런 설정을 직접 다뤄본 개발자는
프로젝트를 이식하거나 빌드 시스템을 리팩터링할 때에도 훨씬 유연하게 대응할 수 있다.

예시
“Webpack 기반 프로젝트를 Vite로 마이그레이션하면서 HMR 속도를 10배 향상시켰고,
vite-plugin-svgrvite-tsconfig-paths를 적용해 DX를 유지했습니다.”


📦 Rollup — 라이브러리와 SDK 배포를 위한 정제된 번들

Rollup은 웹앱보다는 라이브러리 배포용 번들러로 최적화되어 있다.
특히 tree-shaking 성능이 뛰어나고, ESM/CJS/UMD 등 다양한 포맷으로 빌드할 수 있다.

이 도구를 이해하면 “프로젝트 빌드”가 아닌
“모듈을 다른 개발자가 쓸 수 있게 배포하는 과정”을 설계할 수 있다.
즉, 내 코드를 패키지로 만든다는 개념을 체계적으로 다루게 되는 것이다.

주요 포인트는 다음과 같다.

  • external 옵션으로 peerDependencies를 외부화 → 패키지 크기 최소화

  • rollup-plugin-dts로 타입 선언 파일(.d.ts) 자동 번들

  • esbuild 플러그인으로 빠른 트랜스파일

  • terser로 압축

  • sideEffects: false를 명시해 tree-shaking 극대화

예시
“사내 공용 UI 컴포넌트를 Rollup으로 재구성해 ESM/CJS 병행 빌드를 지원하고,
peerDeps를 external 처리하여 패키지 용량을 80% 줄였습니다.”


🧠 세 번들러의 공통된 커스터마이징 개념

Webpack, Vite, Rollup은 내부 구조는 다르지만 핵심적으로 다루는 개념은 같다.

영역주요 개념
엔트리/아웃풋entry, output, publicPath, fileName 패턴
모듈 해석alias, extensions, external, resolve 조건
자원 처리CSS loader, asset module, image optimization
환경 분리mode(dev/stage/prod), 환경변수 주입
코드 스플리팅vendor 분리, route 단위 chunk, lazy import
트랜스파일babel/swc/esbuild, target 관리
최적화tree-shaking, sideEffects, minify, 캐싱
분석 및 품질bundle analyzer, source map, CI/CD 통합

결국 번들러 설정 경험이 쌓이면,
“어떤 프레임워크를 쓰든 빌드 파이프라인이 어떻게 돌아가는지”를
전체적으로 조망할 수 있게 된다.


🧩 실무에서 자주 등장하는 커스터마이징 사례

  1. 빌드 속도 개선

    • Babel → esbuild-loader 교체

    • 캐시(cache: filesystem) 적용

    • thread-loader로 병렬 처리

  2. 코드 스플리팅

    • splitChunks.cacheGroups 또는 manualChunks를 활용

    • 초기 로딩 + lazy chunk 로드 최적화

  3. 환경 변수 관리

    • Webpack: DefinePlugin

    • Vite: .env, import.meta.env

    • Rollup: @rollup/plugin-replace

  4. CSP(보안 정책) 대응

    • inline script 제거

    • nonce/hash 기반 script 삽입

    • html-plugin 또는 vite-plugin-html로 동적 주입

  5. 모노레포 구조 지원

    • Vite: server.fs.allow

    • Webpack: resolve.symlinks=false

    • Rollup: preserveSymlinks

    • TS path alias 동기화


🚀 정리 — 번들러 경험이 결국 ‘프런트엔드 아키텍처’를 만든다

Webpack, Vite, Rollup은 모두 “빌드 도구”로 보이지만
사실은 서비스의 성능, 구조, 배포 전략을 설계하는 도구다.

  • Webpack은 복잡한 빌드 구조를 세밀하게 제어할 수 있는 산업용 공구

  • Vite는 개발자 경험과 속도를 극대화한 차세대 표준 환경

  • Rollup은 컴포넌트와 라이브러리를 세상에 배포하는 정제된 번들러

이 세 가지를 이해하고 다뤄본 개발자는,
단순히 프론트엔드 코드를 작성하는 것을 넘어
“서비스 전체의 품질을 설계하는 개발자”로 성장할 수 있다.


💬 “번들러를 다룬다는 건, 단순히 코드를 묶는 게 아니라 프로젝트의 구조를 설계하는 일이다.”
— 어느 시니어 프론트엔드 개발자의 말처럼.


🧾 작성 참고

이 글은 ChatGPT의 도움을 받아 내용을 정리하였습니다.

More from this blog

LangGraph의 astream_events: 에이전트 실행을 실시간으로 들여다보기

💡 한 줄 요약: astream_events()는 LangGraph 그래프 실행 중 발생하는 모든 이벤트(LLM 토큰, 툴 호출, 노드 시작/종료 등)를 실시간 스트림으로 받을 수 있는 비동기 API입니다. 들어가며 AI 에이전트가 응답을 생성하는 데 25초가 걸린다고 상상해보세요. 사용자는 평균 8초 후에 페이지를 이탈합니다. 하지만 스트리밍을 도입

Jun 20, 20266 min read

LLM은 어떻게 글을 읽고 쓰는가 — 입력부터 출력까지

대화형 AI에게 질문을 던지면, 마치 사람처럼 문장을 이해하고 답을 써 내려가는 것처럼 보인다.하지만 그 안에서 벌어지는 일은 생각보다 단순하고, 또 생각보다 기계적이다.이 글에서는 두 가지 질문에 답해 본다.LLM은 어떻게 글을 만들어내는가,그리고 우리가 입력한 프롬프트는 모델에 어떤 모습으로 들어가는가. 1부. LLM은 어떻게 글을 만들어내는가 핵심은

Jun 10, 20264 min read

useEffect 지옥이란 무엇이며, 어떻게 안전하게 사용하는가

React를 어느 정도 사용하다 보면 한 번쯤은“useEffect 지옥에 빠졌다”는 말을 듣거나 직접 느껴본 적이 있을 것이다. useEffect가 계속 늘어나고 의존성 배열은 점점 길어지고 왜 실행되는지 이해하기 어려워지며 eslint-disable-next-line 이 늘어나는 상태 하지만 많은 사람들이 오해한다.useEffect 지옥은 useEffect가 많아서 생기는 문제가 아니다. 이 글에서는 ‘useEffect 지옥’의 ...

Jan 12, 20263 min read

Zod란 무엇인가: TypeScript에서 런타임 검증과 타입 안정성을 동시에 해결하는 방법

TypeScript 프로젝트를 하다 보면 반드시 마주치는 문제가 있다.바로 “타입은 있는데, 데이터는 믿을 수 없다”는 것이다. TypeScript는 컴파일 타임에는 강력하지만,런타임에 들어오는 데이터에 대해서는 아무런 보장을 해주지 않는다. API 요청 데이터 사용자 입력(Form) 환경 변수 (process.env) 외부 JSON / 설정 파일 이 모든 것은 타입 시스템 바깥에서 들어온다. 이 문제를 해결하기 위해 등장한 라이브러...

Jan 10, 20263 min read

Flatpak을 이해하기 위한 배경 지식

배포판, 라이브러리 충돌, 그리고 OSTree까지 리눅스 데스크톱에서 Flatpak이 표준처럼 자리 잡은 데에는 분명한 이유가 있다.그 이유를 이해하려면 단순히 “Flatpak은 패키징 시스템이다”를 넘어서,리눅스 배포판 구조, 라이브러리 버전 충돌, OSTree라는 기술까지 함께 이해해야 한다. 이 글에서는 다음 질문에 답해본다. 리눅스에서 말하는 배포판이란 무엇인가? 라이브러리 버전 충돌은 왜 발생하는가? Flatpak은 이 문제를 어...

Jan 8, 20265 min read

Dev note

32 posts