🌲Tree Shaking

“쓰지 않는 코드는 버려라.” — 번들 속 불필요한 잎사귀를 털어내는 기술

---

🌲 들어가며

대부분의 웹앱은 수많은 라이브러리로 구성됩니다.
lodash, date-fns, moment, react-icons, three.js...
우리가 사용하는 코드보다 사용하지 않는 코드가 훨씬 많습니다.

이제 브라우저가 그 모든 코드를 다운로드하고, 파싱하고, 실행해야 한다면?
필요하지 않은 코드도 사용자 경험에 직접적인 성능 비용을 유발하게 됩니다.

이 문제를 해결하는 것이 바로 Tree Shaking입니다.

“빌드 단계에서 사용되지 않는(Dead) 코드를 제거해 번들을 더 작게 만드는 기술”

---

Tree Shaking 개념

Tree Shaking은 정적 분석(Static Analysis) 을 통해
사용되지 않는 코드를 “감지하고 제거”하는 번들 최적화 기술입니다.

말 그대로 트리에서 안 쓰이는 가지(코드)를 “털어내는(shake)” 과정이죠.

용어	설명
“Tree”	모듈 간의 import/export 의존 그래프
“Shake”	사용되지 않는(exported but unused) 코드 제거

Tree Shaking 작동 원리 (사용되지 않는 코드 제거 과정)

• 상단의 Input: { Used: { scope1 } } 는 번들러(Webpack, Rollup 등)가 실제로 사용 중인 함수(scope1) 만 추적한다는 것을 의미합니다.
• 코드 내에서 scope1과 scope2는 실행되지만, scope3은 호출되지 않습니다.
• 따라서 scope3에서 사용하는 isNumber() 함수는 실제 빌드 결과에서 제거(Tree Shaking) 됩니다.
  👉 Tree Shaking은 이렇게 “사용되지 않는 모듈(import)”을 정적 분석(Static Analysis) 을 통해 감지하고, 최종 번들에서 제외함으로써 파일 크기를 최소화하고 성능을 최적화합니다.

---

🌲 왜 Tree Shaking이 필요한가?

문제 상황

모듈 단위의 import/export 구조를 가지는 ES6(ESM) 환경에서는,
다음처럼 작은 기능 하나만 가져와도 사실상 전체 코드가 번들될 수 있습니다.

// utils.js
export function add(a, b) { return a + b; }
export function sub(a, b) { return a - b; }
export function mul(a, b) { return a * b; }

// main.js
import { add } from './utils.js';
console.log(add(2, 3));

위 코드의 결과는?

👉 기본적으로 add, sub, mul 세 함수가 모두 번들에 포함됩니다.
왜냐하면 번들러가 “어떤 함수가 실제로 쓰이는지” 분석하지 않으면 전체 모듈을 가져오기 때문입니다.

Tree Shaking은 이 중 사용된 함수(add)만 남기고, 나머지(sub, mul)를 제거합니다.

Tree Shaking 적용 전후 구조 비교

• 왼쪽(Before Tree Shaking): index.js가 여러 모듈(Module 1~3, file1~4.js)과 함수들을 참조하고 있습니다. 하지만 이 중 다수의 모듈과 함수는 실제 실행되지 않음에도 번들에 포함되어 있습니다.
• 오른쪽(After Tree Shaking): 번들러(Webpack/Rollup 등)가 정적 분석(Static Analysis) 을 통해 실제로 참조되는 함수(file3.js → function) 만 남기고, 사용되지 않는 코드(죽은 가지, Dead Code)를 모두 제거했습니다.
  👉 Tree Shaking은 이렇게 “필요한 코드만 살아남게” 하여 번들 크기를 최소화하고, 불필요한 로드 및 파싱 비용을 줄이는 핵심 최적화 기법입니다.

---

🌲 Tree Shaking의 작동 원리

Tree Shaking은 ES Modules(ESM) 구조와 정적 분석(Static Analysis) 을 기반으로 작동합니다.

작동 단계

단계	설명
① 의존성 그래프 생성	import/export 관계를 분석
② 사용 경로 추적	실제로 참조된 export만 “활성(active)” 표시
③ 미사용 코드 제거	활성되지 않은 export는 빌드 결과에서 제거
④ Dead Code Elimination (DCE)	압축기(Uglify/Terser)가 남은 코드 중 부수효과 없는 부분 제거

예시로 이해하기

// math.js
export const add = (a, b) => a + b;
export const minus = (a, b) => a - b;

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

빌드 결과 (Before)

const add=(a,b)=>a+b;const minus=(a,b)=>a-b;console.log(add(2,3));

빌드 결과 (After Tree Shaking)

console.log(((a,b)=>a+b)(2,3));

👉 minus()는 제거됨

ES Module의 Binding 구조

• ES Module은 단순히 값을 복사하지 않고, “참조(reference)”로 연결된 바인딩(binding) 을 유지합니다.
• 즉, 한 모듈에서 export한 변수가 변경되면, 이를 import한 다른 모듈에서도 자동으로 최신 값이 반영됩니다.
• 하지만 반대로 import한 쪽에서 값을 변경하려는 시도는 불가능합니다 (읽기 전용 바인딩).
  👉 이러한 정적 구조적 연결성 덕분에 Tree Shaking 같은 정적 분석 기반 최적화가 가능해집니다.

---

🌲 Tree Shaking이 가능한 전제 조건

Tree Shaking이 작동하려면 몇 가지 필수 조건이 있습니다.

조건	설명
✅ ES Module(ESM) 사용	import/export 구조만 정적 분석 가능. require()는 불가능
✅ 부수효과(side effects)가 없어야 함	모듈 로드시 실행되는 코드가 있으면 제거 불가
✅ 번들러 최적화 옵션 활성화	Webpack: usedExports, Rollup: treeshake: true
✅ Production 모드 빌드	Development에서는 최적화 미적용

// webpack.config.js
module.exports = {
  mode: "production",
  optimization: { usedExports: true },
};

🧭 주의:
CommonJS(require)는 동적 import 경로를 분석할 수 없어 Tree Shaking이 불가능합니다.

ESM vs CJS: Tree Shaking이 가능한 이유

• CJS(CommonJS) 는 require()를 런타임에 실행하므로, 어떤 모듈이 실제로 사용될지 정적 분석 시점에 알 수 없습니다.
• ESM(ES Modules) 은 import/export가 파일 상단에서 정적으로 선언되기 때문에, 번들러(Webpack, Rollup 등)가 의존 그래프를 쉽게 분석하여 사용되지 않는 코드를 안전하게 제거(Tree Shaking) 할 수 있습니다.
  👉 Tree Shaking은 ESM의 정적 구조 덕분에 가능한 최적화입니다.

---

🌲 Tree Shaking vs Dead Code Elimination (DCE)

항목	Tree Shaking	Dead Code Elimination
동작 시점	모듈 그래프 단계	코드 압축 단계
주체	번들러 (Webpack, Rollup 등)	압축기 (Terser, UglifyJS 등)
대상	미사용 export	실행되지 않는 코드 블록
핵심 원리	정적 의존성 분석	조건 분기 제거
예시	사용되지 않은 함수 제거	if (false) { ... } 블록 제거

결국 Tree Shaking은 DCE의 전처리 단계라고 볼 수 있습니다.
→ 번들러가 “무의미한 export”를 제거하고,
→ 압축기가 “조건상 절대 실행되지 않는 코드”를 제거합니다.

---

🌲 Tree Shaking의 한계와 실패 사례

원인	설명	해결책
⚠️ CommonJS	require()는 정적 분석 불가	ESM(import/export)로 변경
⚠️ 동적 import 경로	문자열 조합으로 경로 결정 시 분석 불가	정적 문자열 사용
⚠️ 부수효과(side effect)	import 시 전역 변수 수정, 콘솔 출력 등	모듈을 “순수(pure)”하게 유지
⚠️ 배럴 파일(index.js)	모든 모듈을 재export 하면 모두 포함	직접 경로로 import
⚠️ ESLint / Babel 트랜스파일	require 기반 변환 시 Tree Shaking 깨짐	modules: false 설정 유지

// babel.config.json
{
  "presets": [["@babel/preset-env", { "modules": false }]]
}

배럴 파일 import 문제 도식

• index.js에서 모든 모듈을 한꺼번에 export하면, 사용되지 않는 함수까지 모두 번들 파일(bundle.js) 에 포함됩니다.
• 즉, Tree Shaking이 제대로 작동하지 않아 번들 크기가 커지는 원인이 됩니다.
  👉 "배럴 구조는 Tree Shaking의 적"이라고 할 수 있습니다.

---

🌲 마무리

Tree Shaking은 “코드를 지운다”는 행위가 아닙니다.
“사용자에게 도달하지 않는 코드가 존재하지 않도록 한다”는 원칙입니다.

즉, 성능 최적화의 목적은 “코드를 덜 쓰는 것”이 아니라,
“사용하지 않는 코드를 아예 배포하지 않는 것”이죠.

이건 결국 “사용자의 다운로드 시간을 줄이는 UX 최적화”이기도 합니다.

Tree Shaking은 가벼운 사용자 경험을 위한 사전 청소기다.