2024년 어느 날, 토스 프론트엔드팀 안에서 한 가지 질문이 돌았다. "한국에서 글로벌 규모의 JavaScript 라이브러리가 나온 적 있는가?" 솔직한 대답은 '없다'에 가까웠다. 네이버의 egjs나 NHN의 TOAST UI처럼 알려진 프로젝트가 없진 않지만, npm 생태계의 판도를 바꿀 만한 규모는 아니었다. 그로부터 18개월이 지났다. 토스가 만든 es-toolkit은 npm 주간 다운로드 1천만을 돌파했고, Microsoft 내부 프로젝트에까지 들어갔다.

lodash의 빈틈

lodash는 JavaScript 생태계의 공기 같은 존재다. 주간 다운로드 5천만 이상, npm에서 가장 의존도 높은 패키지 중 하나. 하지만 설계 기반이 2012년이다. ES2015 이후 네이티브 JavaScript가 Array.prototype.flat, optional chaining, Object.entries 등을 직접 제공하면서, lodash 함수 상당수는 폴리필 수준이 됐다. 번들은 여전히 무겁고 트리쉐이킹은 불완전한 채로 10년 넘게 이어져 왔다.

88바이트 vs 2,000바이트

토스의 접근법은 명쾌했다. 모던 런타임을 전제로 바닥부터 새로 짜면 어디까지 가벼워질 수 있을까.

결과는 극적이다. es-toolkit의 sample 함수는 88바이트에 불과하다. lodash의 동일 함수는 2,000바이트 — 96%의 차이다. omit은 실행 속도 기준 11.8배 빠르다. 라이브러리 전체로 보면 2-3배의 속도 향상에 최대 97%의 번들 사이즈 절감을 달성했다. 여기엔 구조적 이유가 있다.

lodash 함수들은 내부적으로 서로 물려 있다. get 하나를 import하면 baseGet, castPath, toKey가 딸려온다. 번들러의 트리쉐이커가 잘라내기 어려운 의존성 사슬이다. es-toolkit은 이 구조를 근본적으로 바꿨다. 각 함수가 완전히 독립적이고, 하나를 import하면 그 코드만 번들에 포함된다. 외부 의존성도 제로다.

타입스크립트 측면에서도 접근이 다르다. lodash는 @types/lodash라는 커뮤니티 유지보수 패키지에 타입 정의를 의존하고, 복잡한 유틸리티에서 타입 추론이 깨지는 경우가 잦다. es-toolkit은 소스 코드 자체가 TypeScript이므로 이런 문제가 구조적으로 발생할 수 없다. Remeda나 Radash 같은 다른 대안 라이브러리도 시장에 있지만, lodash와의 API 호환성을 제공하는 건 es-toolkit이 유일하다.

채택 명단이 증명하는 것

npm 다운로드 수만으로는 실질적 채택을 판단하기 어렵다. CI 파이프라인에서의 반복 설치가 포함되니까. 누가 쓰느냐가 더 의미 있는 지표다.

Microsoft는 여러 내부 프로젝트에서 lodash를 es-toolkit으로 교체했다. Storybook, Yarn, IBM, Recharts, Ink — JavaScript 생태계 인프라의 핵심 축에 해당하는 이름들이다. Vue.js 코어 저장소에는 lodash를 es-toolkit/compat으로 바꾸자는 이슈까지 올라와 있다. 이건 호기심 차원의 설치가 아니다. 프로덕션 코드베이스의 핵심 의존성을 바꾸겠다는 수준의 신뢰를 의미한다.

채택 속도의 핵심에는 es-toolkit/compat 레이어가 있다. lodash의 API 시그니처를 그대로 유지하면서 내부 구현만 교체하는 방식이라, 기존 코드를 거의 건드리지 않고 마이그레이션이 가능하다. "성능이 좋으니까 갈아타세요"가 아닌 "import 경로 하나만 바꾸면 됩니다"라는 전략이다. 전환 비용이 제로에 수렴할 때, 성능 차이가 비로소 설득력을 갖는다. 프론트엔드 번들 사이즈에 민감한 팀이라면 검토하지 않을 이유가 없는 구조다.

한국 오픈소스, 그 다음 단계

한국 테크 기업의 오픈소스 기여는 그동안 얇은 편이었다. 네이버의 Billboard.js, LINE의 Armeria 정도가 해외에서 어느 정도 인지도를 확보한 프로젝트였고, 나머지는 대부분 사내 도구 공개에 머물렀다. 글로벌 개발자 커뮤니티에서 '표준'으로 인식된 한국발 라이브러리는 거의 전무했다.

es-toolkit이 궤적을 달리한 건 출발점 때문이다. '우리 사내에서 쓸 도구'가 아니라 'JavaScript 생태계 전체가 안고 있는 비효율'을 정조준했다. 영문 문서를 기본으로 깔고, GitHub 이슈 대응을 영어로 하고, lodash 사용자가 즉시 전환할 수 있는 호환 레이어를 제공한 것 — 이 모든 선택이 글로벌 채택을 전제한 것이다.

이전에 다뤘던 당근의 Ventyd(서버사이드 이벤트 소싱)도 비슷한 결을 보인다. 자기네 문제를 풀다가 범용 프레임워크가 된 케이스다. 이런 흐름이 한국 테크 전반의 오픈소스 전략 전환인지, 소수 팀의 개별적 시도인지는 아직 판단이 이르다. 다만 npm 주간 1천만이라는 숫자 앞에서 "한국에서 글로벌 JS 라이브러리가 나올 수 있느냐"는 더 이상 질문이 아니게 됐다.