lodash 버리고 es-toolkit으로 갈아타기

lodash 버리고 es-toolkit으로 갈아타는 이유

프론트엔드에서 유틸 함수 라이브러리는 늘 사소한 선택처럼 보입니다. 그런데 운영 단계에 들어가면 이런 사소한 선택이 번들 크기, 타입 안정성, import 습관, 리팩터링 비용까지 줄줄이 건드립니다. 2026년 4월 1일 기준 토스 기술 블로그와 es-toolkit 공식 문서를 함께 보면, 새 프로젝트에서 굳이 lodash의 오래된 전제를 계속 끌고 갈 이유는 꽤 줄었습니다.

한 줄로 요약하면 이렇습니다. lodash가 나빠서 버리는 게 아니라, es-toolkit이 ES Modules, tree-shaking, TypeScript 중심의 현대 웹 전제에 더 잘 맞기 때문에 갈아타는 것입니다.

먼저 결론만 보면

• 새 프로젝트라면 처음부터 es-toolkit이나 네이티브 API 중심으로 가는 편이 자연스럽습니다.
• 기존 프로젝트라면 es-toolkit/compat로 리스크를 낮춘 뒤, 자주 쓰는 함수부터 순수 es-toolkit import로 옮기는 흐름이 현실적입니다.
• 공식 자료 기준으로 es-toolkit은 번들 크기, 실행 성능, 타입 경험, 마이그레이션 비용 네 가지 축에서 모두 설득력이 있습니다.

lodash가 나쁜 게 아니라, 웹이 바뀌었다

lodash는 자바스크립트 표준 라이브러리가 지금보다 훨씬 빈약하던 시절에 정말 좋은 해답이었어요. 문제는 웹의 기본 전제가 이미 바뀌었다는 점입니다. 토스는 es-toolkit을 소개하며 ES Modules가 표준이 됐고, tree-shaking이 가능해졌고, TypeScript가 기본 언어가 됐으며, 번들 크기가 Core Web Vitals와 직결되는 지표가 됐다고 설명합니다.

이 맥락에서 보면 es-toolkit은 단순한 lodash 복제품이 아닙니다. 토스가 직접 밝힌 표현대로, lodash를 대체하기 위해 ES Modules와 TypeScript 중심으로 처음부터 다시 설계된 라이브러리에 더 가깝습니다.

왜 es-toolkit이 더 끌리냐면

1. 번들 크기가 아니라 구조가 다릅니다

es-toolkit 공식 번들 비교표를 보면 차이가 꽤 선명해요. pick은 132 bytes, lodash-es의 pick은 9,520 bytes이고, sample은 94 bytes 대 4,817 bytes, debounce는 531 bytes 대 2,873 bytes였습니다. 공식 문서는 최대 97%까지 번들 크기를 줄였다고 설명합니다.

중요한 건 숫자보다 구조입니다. 토스 글은 lodash-es도 ESM 버전이지만 내부 helper dependency를 여전히 끌고 오기 때문에 함수 하나만 import해도 추가 코드가 따라올 수 있다고 설명합니다. 반면 es-toolkit은 각 함수가 독립적으로 설계돼 있어서 tree-shaking 관점에서 훨씬 유리합니다.

즉, es-toolkit이 작은 이유는 운이 좋아서가 아니라 설계가 현대적인 번들링 방식에 맞춰져 있기 때문입니다.

2. 현대 엔진 기준으로 실행 성능도 앞섭니다

es-toolkit 공식 성능 비교 페이지는 평균적으로 약 2배 수준의 개선을 보여줍니다. 표에 따르면 omit은 11.8배, pick은 3.43배, difference는 2.02배 빠르게 측정됐습니다. 물론 이 수치가 모든 서비스에서 그대로 재현되지는 않겠지만, 적어도 공식 벤치마크 기준으로는 하위 호환성 중심 설계보다 현대 엔진 최적화에 맞춘 설계가 유리하다는 방향이 분명합니다.

토스 글도 같은 맥락을 짚습니다. 예전엔 느리거나 불가능했던 자바스크립트 패턴이 지금 엔진에서는 잘 최적화되고 있고, es-toolkit은 그 전제를 기준으로 만들어졌다는 거예요.

3. 타입 경험이 훨씬 자연스럽습니다

TypeScript를 기본값처럼 쓰는 팀이라면 이 부분이 꽤 크게 다가옵니다. 토스는 lodash가 보통 별도의 @types/lodash 패키지에 의존하는 반면, es-toolkit은 source와 types가 함께 관리된다고 설명합니다. 그래서 타입이 더 정확하고, 버전 불일치로 인한 미묘한 어긋남도 줄어듭니다.

토스가 예시로 든 pick처럼, 반환 타입이 더 자연스럽게 추론되는 경험은 실제 리팩터링 비용에도 바로 연결됩니다. 결국 유틸 함수 라이브러리는 문법 설탕이 아니라 팀의 타입 감각을 결정하는 도구이기도 하니까요.

진짜 좋은 점은 갈아타기 쉬운 데 있습니다

좋은 대체재는 성능보다 전환 비용에서 승부가 납니다. 그 점에서 es-toolkit의 가장 현실적인 장점은 es-toolkit/compat입니다. 공식 호환성 문서는 1.39.3부터 lodash와 100% 호환성을 보장한다고 밝히고 있고, lodash의 실제 테스트 코드 기준으로 동일 동작을 검증했다고 설명합니다. Storybook, Recharts, CKEditor 같은 프로젝트가 이 호환성 레이어를 채택했다는 점도 함께 강조합니다.

가장 간단한 마이그레이션은 import 경로를 바꾸는 방식입니다.

import { pick, debounce, groupBy } from 'es-toolkit';

조금 더 과감하게 가려면 package.json에서 lodash를 es-toolkit에 alias로 연결하는 방법도 있습니다. 토스가 2026년 4월 1일 공개한 글에 나온 예시는 아래와 같습니다.

{
  "dependencies": {
    "lodash": "npm:es-toolkit@^1.44.0"
  }
}

토스는 이 방식이면 기존 import ... from 'lodash' 코드를 거의 건드리지 않고 바로 전환을 시작할 수 있다고 설명합니다. 여기에 @es-toolkit/codemod까지 공개돼 있어서, 호환성 레이어로 먼저 옮긴 뒤 점진적으로 순수 es-toolkit import로 정리하는 흐름도 만들 수 있습니다.

그렇다고 무조건 바로 바꾸라는 이야기는 아닙니다

여기서 중요한 건 compat이 최종 목적지가 아니라 징검다리라는 점입니다. 공식 문서도 es-toolkit/compat은 원본 es-toolkit보다 번들이 더 커질 수 있고 성능 영향이 있을 수 있으므로, 마이그레이션이 끝나면 원래의 es-toolkit import로 돌아가는 것이 최적이라고 안내합니다.

또 가장자리 케이스도 있습니다. 공식 호환성 문서는 암묵적 타입 변환, 수정된 내장 프로토타입 환경, JavaScript realms, Seq 기반 메서드 체이닝 등은 호환성 레이어의 범위 밖이라고 적고 있어요. 오래된 lodash 습관을 깊게 쓰는 프로젝트라면, 전면 교체 전에 이런 케이스부터 먼저 확인하는 편이 안전합니다.[4]

내 결론

제가 보기에 lodash를 버리고 es-toolkit으로 간다는 건 단순히 유틸 함수 라이브러리를 하나 바꾸는 일이 아닙니다. 더 정확히는, 예전 자바스크립트의 부족함을 메우기 위해 들고 있던 습관을 지금의 자바스크립트에 맞게 업데이트하는 일에 가깝습니다.

새 프로젝트라면 처음부터 es-toolkit이나 네이티브 API 중심으로 가는 게 자연스럽습니다. 기존 프로젝트라면 es-toolkit/compat로 무중단 전환을 먼저 하고, 자주 쓰는 함수부터 순수 es-toolkit import로 옮긴 뒤, 마지막에 정말 필요한 유틸만 남기는 방식이 가장 현실적입니다.

es-toolkit은 Node.js, Deno, Bun, 브라우저를 지원하고 있고, 토스는 2026년 4월 1일 기준 Microsoft, Yarn, Storybook, IBM, Recharts, Ink 같은 사용 사례도 공개했습니다.

정리하면 이렇습니다.
lodash가 나빠서 버리는 게 아닙니다.
이제는 더 작은 비용으로, 더 현대적인 전제 위에서, 더 쉽게 같은 문제를 풀 수 있게 됐기 때문에 바꾸는 것입니다.

참고 자료

• [1] Toss Tech, 97% Smaller, 2x Faster: How es-toolkit Reached 10 Million Weekly Downloads (토스 기술 블로그, 토스 테크)
• [2] es-toolkit 공식 문서, Bundle Footprint (ES Toolkit)
• [3] es-toolkit 공식 문서, Performance (ES Toolkit)
• [4] es-toolkit 공식 문서, Compatibility with Lodash (ES Toolkit)
• [5] es-toolkit 공식 문서, Installation & Usage (ES Toolkit)