es-toolkit 공부 정리 | 토스가 lodash를 안 쓰기로 한 이유

토스 테크 블로그에서 es-toolkit 이야기를 읽었다. lodash를 대신할 뭔가를 찾다가 없어서 직접 만들었다는 이야기인데, 처음엔 그냥 지나치려다 결국 끝까지 읽게 됐다.

사실 lodash라는 이름은 React 공부하면서 자주 접했는데, 그냥 “자주 쓰는 유틸 함수 모음” 정도로만 알고 있었다. es-toolkit은 그걸 대신하는 거라는 것까지만 알고 글을 읽기 시작했다.

읽다 보니 “뭘 만들었나”보다 “왜 만들었나”가 더 흥미로웠다. 결정의 흐름이 좀 구체적으로 나와 있어서 공부 노트로 정리해두기로 했다.

1️⃣ 이게 뭐냐?

lodash는 오래된 라이브러리다. IE를 지원하던 시절의 방어 코드가 아직 남아 있고, 브라우저 네이티브 API가 이미 지원하는 기능도 자체 구현으로 처리한다. 트리쉐이킹도 제대로 안 돼서, 일부 함수만 써도 라이브러리 전체가 번들에 들어가게 되는 경우가 많다.

토스 팀은 대안을 찾다가 마땅한 게 없어서 직접 만들기로 했다. 내부엔 이미 @toss/utils가 있었는데, 팀에서 직접 모든 함수를 구현하고 유지보수하는 구조라 엣지 케이스가 늘어날수록 관리 비용이 커졌다고 한다.

es-toolkit은 IE를 지원하지 않는다. 레거시 대응 로직을 빼고 네이티브 API를 적극 활용하는 방식이라, 같은 역할을 하는 함수라도 구현이 훨씬 간결하다. 그 결과로 번들 크기 차이가 의미 있게 나는 경우가 생겼다.

👉🏻 초기엔 lodash와 API 구조가 달라서 기존 코드를 그대로 가져올 수 없었다. 이 문제를 해결하려고 만든 게 es-toolkit/compat이다. lodash를 쓰던 코드에서 import 경로만 바꾸면 동작하도록 설계한 호환 레이어로, 이게 나오고 나서 프로젝트들의 마이그레이션 속도가 빨라졌다고 한다.

2️⃣ 내가 든 생각

가장 흥미로웠던 건 “왜 직접 만들었냐”보다 “왜 공개했냐”였다. 내부 도구를 그냥 밖으로 내보낸 뒤, Reddit에 올렸더니 반응이 왔고, 그 이후 Yarn, Recharts, Storybook 같은 오픈소스에서 채택했다는 흐름이다. 처음부터 공개를 목표로 만든 게 아니었다는 점이 인상적이었다.

React를 공부하면서 lodash 같은 유틸 함수를 어디서 가져다 쓰는가 하는 질문을 처음 만났을 때, 솔직히 “그냥 있는 걸 쓰면 되는 거 아닌가” 싶었다. 근데 이 글을 읽으니 그 선택 안에 생각보다 많은 결정이 있다는 걸 처음 실감하게 됐다. 어떤 라이브러리를 쓸지도, 어떤 이유로 대체할지도.

💡 여기서 드는 질문 하나. compat 레이어가 없었다면 es-toolkit은 지금쯤 어떻게 됐을까? 기능이 더 좋아도 기존 코드베이스를 전부 고쳐야 한다면, 대부분 그냥 lodash를 유지하는 걸 택했을 것 같다.

디자이너 입장에서 compat 레이어 이야기가 특히 낯설지 않았다. 디자인 시스템을 바꾸거나 컴포넌트를 새 버전으로 교체할 때도, 아무리 나아진 버전이라도 기존 사용처를 전부 수정해야 한다면 채택이 늦어진다. 진입 비용을 낮추는 게 기능 개선만큼 중요하다는 건 개발이든 디자인이든 비슷한 것 같다.

⭐️ 마지막으로, 학습자 관점에서 정리해보니

이 이야기를 읽으면서 든 생각은, 결국 es-toolkit이 퍼진 건 라이브러리 자체의 성능보다 compat 레이어가 만들어준 진입 경로 덕분이었을 가능성이 높다는 거다.

정리해보니 이 이야기는 “더 나은 도구를 만드는 것”보다 “더 나은 도구로 옮겨오게 만드는 것”에 가까운 얘기였다.

---

참고 원문: es-toolkit: How a Small Internal Library Became a Global Project