es-toolkit 공부 정리 | lodash를 다시 만들기로 한 이유
토스가 lodash 대신 자체 유틸리티 라이브러리를 만든 이유와 오픈소스로 성장한 과정을 정리했다.
토스 테크 블로그에 es-toolkit 이야기가 올라왔다. 사내에서 만든 작은 유틸리티 라이브러리가 어떻게 주간 2천만 회 다운로드짜리 오픈소스가 됐는지를 팀이 직접 쓴 글인데, 읽다 보니 “왜 이걸 만들었어?”라는 출발점이 생각보다 단순했다.
lodash를 대체할 라이브러리가 마땅히 없었다는 거다. 있긴 있는데, 다 뭔가 아쉬웠다는 얘기. 그 이유가 구체적으로 뭔지 좀 더 읽어봤다.
1️⃣ 이게 뭐냐?
es-toolkit은 throttle, debounce, uniq 같은 자주 쓰이는 유틸리티 함수들을 현대 JavaScript 방식으로 다시 작성한 라이브러리다. 토스 내부에서 쓰던 @toss/utils가 출발점이었고, “lodash를 대체할 만한 게 없으니 만들자”는 판단에서 시작됐다.
lodash가 왜 문제냐면, 구조 자체가 오래됐다. Array#map 같이 브라우저가 이미 제공하는 기능을 직접 구현하고 있고, Internet Explorer용 방어 코드도 여전히 남아 있다. ECMAScript Modules도 지원 안 해서 Tree-shaking이 제대로 안 된다. Tree-shaking이 안 된다는 건 내가 쓰지도 않는 함수들이 최종 번들에 포함된다는 얘기다. 디자이너 관점에서도 번들 크기는 페이지 로딩 속도와 직결되니까 완전 무관한 이야기는 아니다.
lodash-es라는 대안도 있다. ESM 지원만 얹은 버전인데, 코드베이스 자체는 lodash랑 같다. 구조적인 문제가 그대로 남아 있는 거다.
es-toolkit은 그 불필요한 코드를 걷어냈다. 성능이 함수마다 다르지만 최소 두 배, 많게는 열 배 이상 빨라졌고, 번들 크기는 서른 배 이상 줄어든 케이스도 있다. 수치 자체보다 “구현 방식을 바꾸면 이 정도 차이가 나는구나”라는 게 흥미로웠다.
2️⃣ 내가 든 생각
공부하면서 정리해보니, 이 라이브러리가 잘 됐다는 게 단순히 “더 빠른 lodash”여서는 아닌 것 같다. 처음 공개했을 때 한국 커뮤니티에서 반응이 왔고, 그다음 Reddit 같은 해외 커뮤니티에서 바이럴이 됐다. “2.3배 빠르고 97% 작은”이라는 수치가 딱 나오니까 공유하기도 쉬웠을 것 같다.
👉🏻 가장 흥미로웠던 건 es-toolkit/compat이라는 호환성 레이어다. 기존 lodash 코드를 그대로 두고 import 경로만 바꿔서 쓸 수 있게 만든 거다. 이게 없었다면 “좋다는 건 알겠는데 마이그레이션이 부담스럽다”는 반응이 훨씬 많았을 것 같다. 도입 장벽을 낮추는 결정이었던 것 같다.
💡 읽으면서 든 질문: Yarn Berry나 Recharts 같은 프로젝트들이 채택했다는 게 나오는데, 잘 알려진 프로젝트가 쓴다는 게 생태계 안에서 어떤 역할을 하는 걸까.
Yarn Berry가 쓴다는 건, 내가 따로 선택하지 않아도 이미 es-toolkit에 의존하고 있을 수 있다는 얘기다. 직접 채택하지 않아도 이미 연결돼 있을 수 있다는 게 조금 낯설게 느껴졌다.
⭐️ 마지막으로, 이 이야기를 읽으면서 남은 한 가지
공부 끝에 남은 건 기술적인 수치보다 “없으면 만들기로 한 결정”이라는 한 줄짜리 인상이다. lodash 대체제를 찾다가 없으니까 그냥 만들어버렸고, 그게 오픈소스로 공개되면서 나중엔 다른 프로젝트들이 의존하는 라이브러리가 됐다. 결과보다 그 결정을 내린 맥락이 더 기억에 남는다.