왜 lodash-es를 사용할까

개발을 하다 보면 lodash는 자주 사용하는 라이브러리 중 하나입니다. 하지만 많은 프론트엔드 실무 팁 중 하나로 lodash 대신 lodash-es를 사용하라고 하죠. 이유는 간단합니다. 바로 lodash는 트리쉐이킹이 되지 않아서 번들 크기가 커지기 때문입니다. 그러면 왜 lodash는 트리쉐이킹이 불가할까요?

CommonJS

그 이유는 lodash가 CommonJS로 만들어진 라이브러리이기 때문입니다. CommonJS는 Node.js가 등장하고 모듈 시스템이 필요해지면서 등장했습니다.

// math.js
const add = (a, b) => a + b;
module.exports = { add };

// app.js
const { add } = require('./math');

이런식으로 모듈을 만들고 다른 파일에서 사용 가능하죠

동적 사용

CommonJS의 특징 중 하나는 동적 사용이 가능하다는 것입니다. 보통 파일 최상단에서 require을 사용하지만 코드 중간에서도 사용이 가능합니다.

if (condition) {
  const moduleA = require('./moduleA');
} else {
  const moduleB = require('./moduleB');
}

ES Modules

lodash-es는 ES Modules로 만들어졌습니다. 아마 CommonJS보다 ES Modules이 친숙한 개발자가 많을 것입니다.

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

// app.js
import { add } from './math';

ES Modules의 정적 import는 항상 파일 최상단에서만 사용할 수 있고, 이 특징 때문에 번들러가 정적 분석을 할 수 있어 트리쉐이킹이 가능합니다.

트리쉐이킹

트리쉐이킹은 번들링 과정에서 불필요한 코드를 식별하고 제거하는 기법입니다. lodash-es를 예를 들면, lodash-es에 수많은 함수가 존재해도 아래처럼 하나만 import하면 나머지 함수들은 번들에 포함되지 않습니다.

// 트리쉐이킹이 되면 debounce만 번들에 포함된다

import { debounce } from 'lodash-es';

트리쉐이킹 조건

번들러가 트리쉐이킹을 하려면 빌드 타임에 어떤 코드가 사용되는지 판단해야 합니다. 여기서 눈치채실 수 있겠지만, CommonJS는 동적 사용이 가능하다는 특징 때문에 번들러가 빌드 시점에 동적으로 사용될 수 있다는 가정에 모든 파일을 번들에 포함합니다. 이 때문에 트리쉐이킹이 불가해져 번들 크기가 거지는 거죠.

그러면 이 처럼 lodash-es의 이점이 많은데 왜 아직도 lodash의 사용량이 많을까요? ES Modules은 CommonJS보다 늦게 등장했고, Node.js에서 ESM을 지원한건 비교적 최근입니다. 이 때문에 레거시 코드에선 lodash를 사용하는 경우가 많죠.

현재 프론트엔드 환경에선 번들 크기의 중요성이 커지고 있으므로 이 글을 읽는 분들은 lodash-es 사용을 권장합니다.