Lodash를 사용할 때, 개별 모듈만 가져오면 번들 사이즈를 줄일 수 있다고 많이 알려져 있습니다. 하지만 실제 결과는 프로젝트 규모와 번들러 구성에 따라 달라질 수 있습니다. 이 글에서는 Lodash 사용 시 전체 import와 개별 import가 번들 사이즈에 미치는 영향을 분석해보았습니다.

예상과 다른 결과

Lodash의 모든 모듈을 사용하는 것이 아니기 때문에 개별적으로 필요한 모듈만 가져오는 것이 번들 사이즈를 줄일 것이라고 확신했습니다. 그래서 다음과 같이 개별 import 방식을 도입했습니다.

import _ from "lodash"; // 전체 import
import map from "lodash/map"; // 개별 import

확신에 차서 lint 규칙을 설정하여 전체 import 방식을 사용하지 못하도록 하고, 프로젝트의 약 180여 개 파일을 개별 import 방식으로 수정했습니다. 그리고 팀 내 공유하기 위해 bundle-analyzer를 사용해 번들 사이즈를 확인해본 결과, 예상과는 다른 결과가 나왔습니다.

전체 import	개별 import
Parsed size: 74.56KB	Parsed size: 92.13KB

공식 문서의 권고 사항

Lodash의 공식 문서에 따르면, 개별 모듈 사용은 권장되지 않습니다. 요약하면 다음과 같습니다:

1. 중복코드 문제
   Lodash 내부적으로 함수들이 공유하는 코드가 있습니다. 이 코드들은 전체 import 시 중복 없이 한 번만 포함되지만, 개별 모듈 import 시에는 각 모듈이 필요로 하는 내부 코드가 독립적으로 번들에 포함됩니다.

   • 전체 import
     모든 함수가 하나의 모듈로 가져와지므로 공유하는 내부 코드가 중복 없이 번들에 포함됩니다. 트리 쉐이킹을 통해 사용하지 않는 코드도 제거됩니다.
   • 개별 import
     각 모듈이 서로 다른 독립 모듈로 처리되면서 동일한 공유 내부 코드가 여러 번 번들에 포함됩니다. 예를 들어 lodash/map과 lodash/filter를 개별 import할 경우, 이들이 동일한 내부 코드를 사용하더라도 중복되어 번들에 포함됩니다.

2. 트리 쉐이킹 문제
   트리 쉐이킹은 모듈 내부에서 사용되지 않는 코드를 제거하지만, 개별 모듈이 독립적으로 처리되면 공통으로 사용하는 코드가 중복 포함되는 문제는 방지하지 못할 수 있습니다. 특히, Lodash는 CommonJS 모듈로 작성되어 있어 ES 모듈보다 트리 쉐이킹이 덜 최적화됩니다.

결론

Lodash를 사용할 때, 번들 사이즈 최적화를 위해서는 다음을 고려해야 합니다:

• 전체 import:
  다양한 Lodash 함수를 사용할 때는 전체 import가 더 효율적일 수 있습니다.

• 개별 import:
  단일 함수나 몇 가지 함수만 사용되는 작은 프로젝트에서는 개별 import가 효과적일 수 있습니다.

• Lodash-es 사용
  ES 모듈 버전인 lodash-es를 사용하여 필요한 코드만 번들에 포함시킬 수 있습니다.

$ npm install lodash-es

import { map } from "lodash-es";

• Babel 플러그인 사용:
  babel-plugin-lodash를 사용하면 전체 모듈을 import하더라도 트리 쉐이킹이 잘 작동하게 되어 번들 크기를 줄일 수 있습니다.

$ npm install --save-dev babel-plugin-lodash

// .babelrc 또는 next.config.js
{
  "plugins": ["lodash"]
}

• 불필요한 Lodash 사용 피하기:
  ES6+에서 제공하는 기본 내장 함수로 대체할 수 있는 경우, Lodash 사용을 피하는 것이 좋습니다.