Webpack Tree Shaking 동작 원리

트리셰이킹(Tree Shaking)

트리셰이킹(Tree Shaking)은 프로젝트에서 사용되지 않는 코드를 제거하는 최적화 기법이에요. 마치 나무를 흔들어 불필요한 잎을 떨어뜨리듯, 실제로 사용하지 않는 코드(Dead Code)가 번들 파일에 포함되지 않도록 해요.

예를 들어, 라이브러리에서 특정 함수 하나만 사용했는데도 전체 코드가 번들에 포함돼 파일 크기가 불필요하게 커지는 문제가 발생할 수 있어요. 이럴 때 트리셰이킹을 적용하면 실제로 사용하는 코드만 번들에 남기기 때문에 번들 크기를 크게 줄일 수 있어요.

 

번들 크기가 줄어들면 애플리케이션의 로딩 속도가 빨라지고, 사용자 경험도 개선할 수 있어요. 이제 트리셰이킹의 주요 특징에 대해 살펴볼게요.

트리셰이킹이 동작하는 환경

트리셰이킹은 정적 분석(Static Analysis) 기반으로 작동해요. 정적 분석은 코드가 실행되기 전에 구조를 분석해, 사용되지 않는 코드를 정확히 찾아낼 수 있는 기법이죠. 따라서 트리셰이킹은 코드를 분석하고 번들링하는 빌드 타임에 적용돼요.

 

트리셰이킹이 잘 동작하려면, 번들러가 모듈 간의 관계를 명확하게 분석할 수 있도록 모듈이 구성되어야 해요. 자바스크립트의 모듈 시스템에는 ESM과 CJS 두 가지 방식이 있는데, ESM은 정적인 구조를 가지기 때문에 빌드 타임에 분석이 가능하고, 트리셰이킹이 효과적으로 적용돼요.

ESM과 CJS의 구조적인 특성을 비교하면서 트리셰이킹이 ESM에서 효과적인 이유를 더 자세히 살펴볼게요.

 

ESM

ESM은 import와 export 구문으로 모듈 간의 관계를 분석해 의존성 그래프를 만들어요. 이 의존성 그래프로 번들러가 불필요한 코드를 쉽게 판단하고 제거할 수 있어요.

 

 

의존성 그래프는 추상 구문 트리(AST)를 기반으로 생성돼요. AST는 번들러가 문자열로 된 코드를 트리 형태로 변환한 자료구조로, 코드의 구조와 모듈 간 관계를 분석하는 데 활용되는 자료구조예요.
번들러는 AST를 분석해 의존성 그래프를 만들고, 이 정보를 바탕으로 참조되지 않는 코드를 찾아 제거해 최적화된 번들을 생성할 수 있어요.

 

이러한 특성 덕분에 ESM에서는 불필요한 코드를 쉽게 찾아 제거할 수 있어요.

• import한 모듈은 다른 값으로 재할당할 수 없어요

  import { math } from "./math.js";
  
  math = {}; // Error

• ESM의 import는 읽기 전용(immutable)이기 때문에 가져온 모듈을 재할당할 수 없어요.
  이는 모듈 간의 의존성을 명확하게 유지하고, 정적 분석을 용이하게 하기 위한 설계예요.
• import 및 export 구문은 항상 파일의 최상단에 위치해야 해요 ESM에서는 import와 export가 코드가 실행되기 전에 정적으로 분석되므로, 실행 도중 동적으로 평가될 수 없어요. 따라서 조건문 안에서 import를 사용할 수 없으며, 항상 최상단에 위치해야 해요.

• if (condition) {
    import { func } from "./module.js"; // Error
  }

• ESM은 import() 구문을 지원해서 필요한 시점에 모듈을 동적으로 불러올 수 있고, 이를 통해 초기 번들 크기를 줄일 수 있어요.

• async function loadUtils() {
    const { deepEqual } = await import("lodash-es");
    console.log(deepEqual(a, b));
  }

CJS

CJS는 require를 사용해 항상 동기 방식으로 모듈을 불러와요. 즉, 코드가 실행될 때 즉시 해당 모듈을 불러야 하고 비동기 로딩은 지원하지 않아요.

예를 들어 다음과 같은 상황에서는 CJS의 동작을 정확히 예측하기 어려워요.

1. 함수나 조건문 안에서 동적으로 모듈을 로드할 때

다음 코드처럼 require나 import 같은 모듈 로드를 함수나 조건문 안에서 동적으로 사용할 때, 번들러는 코드 실행 전에는 정확히 어떤 모듈이 로드될지 알 수 없어요.

그래서 번들러가 전체 의존성을 미리 파악하거나 최적화하기 어려워져요.

let foo;
if (SOME_CONDITION) {
  foo = require("something");
} else {
  foo = require("something_else");
}

2. 몽키 패칭 등으로 예상하지 못한 동작이 생길 때

몽키 패칭은 이미 존재하는 모듈이나 함수의 동작을 런타임 중에 덮어써서 원하는 대로 바꾸는 기법이에요. 이 경우도 마찬가지로, 번들러 입장에서는 코드가 실행되기 전에는 어떤 모듈이, 어떤 방식으로 변경될지 알 수 없어요. 결과적으로 번들러는 코드 분석이 어려워지고, 예상하지 못한 동작이나 오류가 발생할 수 있어요.

ESM 기반의 라이브러리를 사용해야 하는 이유

라이브러리에서 필요한 기능만 가져오더라도, 모듈 시스템이나 번들 설정이 제대로 되어 있지 않으면 전체 라이브러리가 포함돼 번들 크기가 커질 수 있어요.

예를 들어, lodash 라이브러리에서 deepEqual 함수 하나만 사용한다고 해볼게요.

import { deepEqual } from "lodash";

하지만 lodash는 CJS 방식으로 작성돼 트리셰이킹이 잘 적용되지 않아요. 결과적으로 deepEqual 외에도 lodash의 모든 코드가 번들에 포함될 수 있어요.

이 문제를 해결하려면 lodash 대신 ESM을 지원하는 es-toolkit을 사용해야 해요.

import { isEqual } from "es-toolkit";

const result = isEqual(a, b);

es-toolkit는 ESM 구조를 사용해 필요한 함수만 선택적으로 가져올 수 있고, 트리셰이킹을 사용해 번들 크기를 효과적으로 줄일 수 있어요.

사이드 이펙트가 없는 코드 제거

사이드 이펙트(Side-Effect)는 코드가 예상치 못한 방식으로 애플리케이션의 동작에 부작용을 줄 수 있는 가능성을 의미해요. 즉, 사이드 이펙트가 없는 코드란 번들링된 코드가 실행될 때 동작에 영향을 주지 않는 코드예요.

사이드 이펙트가 있는 코드를 몇 가지 예를 들어 볼게요.

 

 

1. 호출될 때 외부 상태를 변경하는 함수

let count = 0;

function incrementCount() {
  count = count + 1; // 함수가 호출될 때마다 전역 변수 값이 변경됨 (사이드 이펙트 발생)
}

incrementCount();

 

2.직접적으로 DOM 변경

function updateDOM() {
  document.body.innerHTML = "<h1>Hi Toss!</h1>"; // DOM이 변경됨
}

 

3.조회를 할 때마다 다른 결과 반환

const user = {};

// Object.defineProperty를 이용한 속성 조작
Object.defineProperty(user, "name", {
  get() {
    console.log("이름이 뭐예요?");
    this._name = this._name ? this._name + "!" : "Hany"; // 값을 변경하는 부작용 발생
    return this._name;
  }
});

console.log(user.name); // "이름이 뭐에요?" 출력 후 "Hany"
console.log(user.name); // "이름이 뭐에요?" 출력 후 "Hany!"
console.log(user.name); // "이름이 뭐에요?" 출력 후 "Hany!!"

반대로 사이드 이펙트가 없는 코드는 다음과 같아요.

1. 순수함수: 외부 변수나 전역 상태를 변경하지 않고, 입력값에 따라 항상 동일한 결과 반환

function add(a, b) {
  return a + b;
}

const result = add(2, 3);
console.log(result);

 

 

 

2. 조회 시 동일한 결과를 반환

const user = {
  _name: "Hany",
  get name() {
    console.log("이름이 뭐예요?");
    return this._name; // 값을 변경하지 않고 그대로 반환
  }
};

console.log(user.name); // "이름이 뭐예요?" 출력 후 "Hany"
console.log(user.name); // "이름이 뭐예요?" 출력 후 "Hany"
console.log(user.name); // "이름이 뭐예요?" 출력 후 "Hany"

 

3.원본 데이터를 변경하지 않고 새로운 값을 반환하는 내장 함수

arr.slice(1);
arr.map((num) => num * 2);
arr.filter((num) => num > 1);

str.toUpperCase();
str.repeat(3);

Math.floor(4.8);
Math.abs(-10);

이처럼 사이드 이펙트가 없는 코드는 번들러가 안전하다고 판단하면, 최종 번들에서 제거돼요.

트리셰이킹 최적화를 위한 추가 설정

실제로 작성하는 코드에는 사이드 이펙트가 포함될 때가 많아요. 번들러가 이를 올바르게 처리할 수 있도록, 개발자가 직접 정보를 제공하거나, 번들러가 자동으로 최적화를 수행할 수도 있어요.

대표적인 방법은 다음 두 가지예요.

주석 설정

/* @__PURE__ */ 주석은 이 코드가 실행되더라도 사이드 이펙트가 없다는 것을 번들러에게 명시적으로 알리는 역할을 해요. 즉, 외부 상태에 영향을 주지 않는다고 단언하는 거예요. 트리셰이킹 최적화를 위해 번들러가 번들링 과정에서 자동으로 추가할 수도 있고, 개발자가 직접 명시적으로 추가할 수도 있어요.

 

다음과 같이 /* @__PURE__ */ 주석이 포함된 코드를 번들링하면,

const Icon = /* @__PURE__ */ React.createElement(...);

 

번들러는 해당 코드가 사이드 이펙트가 없다고 판단할 수 있어요. 그 결과, 최적화 과정에서 필요하지 않은 경우 아래처럼 제거될 수 있어요.

const Icon = /* @__PURE__ */ React.createElement(...);

sideEffects 필드 활용

package.json 파일의 sideEffects 필드는 특정 파일이나 코드가 번들링 과정에서 제거되지 않도록 번들러에 알려주는 역할을 해요.

모든 파일에 사이드 이펙트가 없다고 선언하기

// package.json
{
  "sideEffects": false
}

이렇게 설정하면, 번들러는 사용되지 않는 모든 파일을 안전하게 제거할 수 있어요.

특정 파일이나 디렉토리를 제거하지 않도록 설정하기

// package.json
{
  "sideEffects": ["*.css", "./src/global.js"]
}

이 설정은 CSS 파일과 특정 자바스크립트 파일이 제거되지 않도록 명시하는 방식이에요. 예를 들어, global.js 파일이 전역 변수를 설정하거나 애플리케이션의 초기화를 담당하는 경우, 트리셰이킹 과정에서 실수로 제거되지 않도록 보호할 수 있어요.

이렇게 필요한 파일을 지정하면, 트리셰이킹의 효과를 유지하면서도 필수적인 코드가 번들에서 빠지는 문제를 방지할 수 있어요. 이로써 빌드 성능을 최적화할 수 있어요.

번들러 세팅 가이드

트리셰이킹으로 사용하지 않는 코드를 제거하더라도, 빌드 결과물에는 여전히 불필요한 공백, 주석, 최적화되지 않은 표현 등이 남아 있을 수 있어요. 프로덕션 빌드에서는 이 잔여 요소를 압축(minify)해 코드 크기를 추가로 줄여야 최종 번들의 성능을 극대화할 수 있어요.

 

 

설치 방법

npm install --save-dev terser-webpack-plugin

설정 예시

// webpack.config.js
const TerserPlugin = require("terser-webpack-plugin");

module.exports = {
  optimization: {
    minimize: true,
    minimizer: [new TerserPlugin()]
  }
};

 

 

 

🤔 그렇다면 Webpack은 어떻게 의존성 그래프를 만들고, AST 분석을 통해 트리 쉐이킹(Tree Shaking)을 수행할까요?

의존성 그래프

1. 엔트리(entry)에서 시작 : Webpack은 index.js를 읽고 import/require 구문을 추적하기 시작합니다.
2. entry: "./src/index.js"
3. 모듈 탐색
   • import A from './A.js'
   • import { B } from './B.js'
     이런 구문을 따라가며 모듈들을 수집합니다.
4. 그래프 구성
   • 각 모듈을 노드(node)로, import 관계를 엣지(edge)로 연결
   • 최종적으로 하나의 Directed Graph(의존성 그래프)가 만들어짐

 

 AST 변환

• Webpack 자체는 AST를 직접 다루지 않고, acorn(JS 파서) 같은 라이브러리를 이용해서 소스를 AST(Abstract Syntax Tree)로 변환합니다.
• 각 모듈의 소스 코드를 AST로 파싱 → import/export 구문을 탐지 → 그래프와 연결

예:

import { add } from "./math.js";
console.log(add(2, 3));

 

이를 AST로 변환하면:

• ImportDeclaration 노드 (math.js를 가져옴)
• CallExpression 노드 (add 함수 호출)
• MemberExpression, Identifier 등등

Webpack은 이 AST를 해석해서 실제로 어떤 심볼이 사용되는지를 분석합니다.

---

트리 쉐이킹 (Tree Shaking)

https://webpack.kr/guides/tree-shaking/

 

트리 쉐이킹은 나무를 흔들어서 죽은 나뭇잎을 떨어트리는 것처럼 빌드 과정에서 사용되지 않는(exported but unused) 코드를 제거하는 최적화 기법입니다.

 

 

 

Webpack 문서에서 말하는 Tree Shaking 

 

• Tree Shaking이란 사용되지 않는 코드(예: export했지만 import되지 않거나 호출되지 않는 함수/변수/모듈)를 번들에서 제거하는 최적화 기법. 
• 이것이 가능하려면 ES2015 모듈(즉, import / export) 구문을 사용해야 함. 정적 구조(static structure)이 보장되어야 하기 때문. 
• Webpack 2부터는 ESM의 export 중 사용되지 않는(export만 되고 사용되지 않는) export를 감지 가능하며, Webpack 4에서는 package.json의 "sideEffects" 필드를 통해 “이 파일/모듈이 side effects(부수효과)가 있는가 없는가”를 사용자/라이브러리 개발자가 표시할 수 있게 확장됨.

트리 쉐이킹의 작동 흐름

Webpack 문서 예제를 바탕으로 흐름을 요약하면 다음과 같습니다. 

1. ESM 모듈 생성
   • 예를 들면 src/math.js 파일에 square 와 cube 함수를 export 함. 
2. 엔트리(entry) 코드에서 일부만 사용
   • index.js에서 cube만 import 사용. square는 사용되지 않음. 
3. Webpack 설정: usedExports 옵션 활성화
   • usedExports: true 설정을 통해 Webpack이 어떤 export가 “사용됨(used)”인지 마킹함.
4. 빌드 결과 살펴보기
   • 사용되지 않는 square 함수 위에 /* unused harmony export square */ 이런 주석이 붙음. 이는 “square는 사용되지 않는 export”라는 표시.
   • 하지만 개발 모드(dev mode)에서는 코드가 제거되지 않고 여전히 번들에 남을 수 있음.
5. sideEffects 설정 지정
   • package.json에 "sideEffects": false 또는 어떤 파일만 sideEffect가 있는지 배열로 명시하는 방식으로 설정 가능. 
   • 예: 사이드 이펙트 없는 파일은 사용되지 않으면 완전히 제거 가능. CSS 파일 등처럼 import 시 스타일 적용 같은 부수적 효과가 있는 파일은 sideEffects 리스트에 포함시켜야 제거되지 않음.
6. Production 모드로 빌드 → Minification 포함
   • mode: "production" 설정시 Webpack은 여러 최적화 옵션을 자동으로 사용 (예: ModuleConcatenationPlugin, Terser 등) 
   • 이 과정에서 실제로 “사용되지 않는 코드”가 제거됨. 

---

“sideEffects”와 "usedExports"의 관계 및 유의점

Webpack 문서에서는 usedExports 만으로는 부족한 경우도 많다며, sideEffects 플래그의 중요성을 강조합니다. 주요 유의점들은 다음과 같습니다.

• sideEffects: false → “이 모듈 혹은 파일은 import 되었을 때 부수적 효과(side effect)가 없다”는 힌트. 잘못 설정하면 필요한 코드(예: CSS, 폴리필, 글로벌 초기화 코드 등)가 제거될 위험이 있음.
• 부수 효과가 있는 파일 → sideEffects 필드에 명시해야 함. 예: CSS 파일, 글로벌 스코프 조작 등이 있는 파일.
• 재수출(re-export) 패턴에서는 특히 조심해야 함.
  예: 라이브러리에서 export * from './components' 등으로 여러 파일을 재수출하는 경우, 일부 파일들이 sideEffects 없다고 표시되었더라도 내부 의존성 때문에 완전히 제거되지 않거나 예상과 다른 결과가 나올 수 있음.

---

결론

Webpack 공식 글의 요점들을 합치면, 트리 쉐이킹이 제대로 작동하려면 다음 조건들이 필요합니다.

1. ES2015 모듈 구문 (import/export) 사용
2. usedExports 옵션 활성화
3. production mode 사용하여 minification 등의 최적화 활성화
4. package.json의 sideEffects 필드로 “어느 파일이 부수 효과(side effects)가 있는지 없는지” 명확히 표시
5. 스타일(css), 폴리필, 글로벌 초기화 코드처럼 부수 효과가 있는 코드가 잘못 제거되지 않도록 주의

이런 요소들이 조합되면 번들 크기를 줄이면서도 기능이 깨지지 않는 최적화가 가능해집니다.

 

 

 

Webpack은 다음 단계로 수행됩니다.

1. ESM(ECMAScript Module) 기반만 지원
   • import / export 구문은 정적 분석(static analysis)이 가능
   • CommonJS(require)는 런타임에 동적으로 결정되므로 트리 쉐이킹이 어려움
2. AST를 통한 사용 여부 추적
   • export function foo() {} 같은 선언을 찾음
   • 의존성 그래프에서 실제로 foo가 import + 사용되는지 확인
   • 사용되지 않으면 “dead code”로 표시
3. 마킹 단계 (Mark phase)
   • Webpack은 Terser(압축기)를 호출하기 전, 사용되지 않는 export를 "unused"로 마킹합니다.
   • 이때 단순히 import 되지 않은 함수·변수는 “제거 가능(dead)”로 태그
4. 압축 단계 (Sweep phase)
   • 최종 번들링 시 Terser 같은 minifier가 AST를 다시 분석하여, dead code를 실제로 삭제
   • 즉, Webpack은 unused code를 표시하고, Terser가 코드 제거를 실행

 

1. Webpack은 엔트리에서 시작해 import/require를 따라가며 의존성 그래프를 생성
2. 각 모듈 소스를 AST로 파싱해 어떤 export/import가 쓰이는지 분석
3. 트리 쉐이킹: 사용되지 않는 export는 마킹 → Terser 같은 최적화 도구가 실제 삭제