es-toolkit: 사내 소형 라이브러리에서 글로벌 프로젝트로
토스 프론트엔드 팀이 사내 공유 유틸리티 라이브러리를 발전시켜 만든 es-toolkit이 주간 npm 다운로드 2,000만 건을 넘기며 글로벌 오픈소스 프로젝트로 자리 잡은 과정을 다룬다. lodash의 구조적 한계를 넘어 현대 웹 개발 환경에 최적화된 유틸리티 라이브러리를 처음부터 설계한 경험을 정리한다.
토스 프론트엔드 팀이 사내 공유 유틸리티 라이브러리를 발전시켜 만든 es-toolkit이 주간 npm 다운로드 2,000만 건을 넘기며 글로벌 오픈소스 프로젝트로 자리 잡은 과정을 다룬다. lodash의 구조적 한계를 넘어 현대 웹 개발 환경에 최적화된 유틸리티 라이브러리를 처음부터 설계한 경험을 정리한다.
토스 Technical Writing 팀이 AI Skill을 개발해 문서 작성과 검토 과정을 자동화한 경험을 다룬다. 4,000명 규모 조직에 TW가 3명뿐인 구조에서 기능 변화 속도를 문서가 따라가지 못하는 문제를 해결하기 위해, TW의 암묵지를 체계화하고 AI Skill로 배포해 개발자가 직접 문서화하는 구조를 만들었다.
토스팀이 lodash의 한계(ESM 미지원, 레거시 코드 비대)를 해결하기 위해 개발한 JavaScript 유틸리티 라이브러리 es-toolkit이 NPM 주간 다운로드 2천만 회를 돌파하며 전 세계 주요 오픈소스 프로젝트에 채택됐다. 사내 작은 프로젝트로 시작해 Storybook, Mermaid, Yarn Berry 등이 의존성을 전환한 과정과, lodash drop-in replacement인 es-toolkit/compat 전략을 최초 개발자 서진과 외부 기여자로 시작해 토스뱅크에 합류한 다용, 두 개발자의 시각으로 다룬다.
토스증권 Data Infra팀이 Spark Connect를 Kubernetes 위에서 멀티테넌트 서비스로 운영하며 맞닥뜨린 구조적 문제 3가지(Driver SPOF, 리소스 경합, 고정 스케일)와 그 해결책을 다룬다. 단일 SparkContext를 공유하는 구조에서 한 사용자의 OOM 쿼리가 전체 세션을 종료하는 문제를, Executor 실패 카운터 재설계와 멀티 Replica 아키텍처로 극복했다.
토스 UX 디자이너가 AI를 협력자로 삼아 피그마 시안 대신 실제 SwiftUI 코드로 iOS 앱을 직접 구현한 경험을 다룬다. "데드엔드" 화면(송금·결제 완료 등)을 다음 경험의 시작점으로 전환하는 underlay 컴포넌트를 설계하면서 Metal 셰이더 구현까지 디자이너가 주도했고, 완성된 코드를 개발팀에 전달해 협업 방식 자체를 바꿨다.
토스가 2,800만 MAU의 유저 이용 패턴을 이해하기 위해 개발한 세그멘테이션 시스템 TUES(Toss User Engagement Segment)의 설계와 V1에서 V2로의 진화 과정을 다룬다. Hard Clustering에서 Soft Clustering으로 전환하고 서비스별 관여도 차원을 추가해 분석 정밀도를 높인 실전 사례다.
결제 수단으로 얼굴을 쓰려면 오인식이 허용되지 않는 높은 보안·정확도가 필요하다.
사내 공용 Skill의 트리거 실패(에이전트 미호출)와 형식 위반 결함이 반복적으로 발생한다.
조직이 성숙할수록 팀 내부보다 팀 사이의 회색지대 문제(책임 불명확, 다중 조직이 얽혔으나 소유자 없음)가 병목이 된다. AI 시대에 그 복잡도는 더 커진다.
"지금 가로채 두고 나중에 양자 컴퓨터로 복호화하는(Harvest now, decrypt later)" 위협이 현실적이다. 오늘 암호화된 금융 트래픽이 미래에 풀릴 수 있다.
하나의 OLAP 클러스터(StarRocks)를 여러 팀이 공유할 때, 한 팀의 무거운 쿼리가 다른 팀의 SLA에 영향을 준다.
모든 팀원이 데이터를 다루는 시대인데, SQL/도구를 모르는 사람은 데이터 분석가에게 의존해야 한다.
"harvest now, decrypt later" 위협: 지금 암호화된 트래픽이 미래 양자컴퓨터가 등장하면 해독될 수 있다. 금융 서비스는 10년 단위 보존 데이터가 많아 특히 민감하다.
광고 Frequency Capping 을 7일 윈도우로 실시간 집계하려면 Apache Flink 의 RocksDB 상태 관리가 병목이 된다.
토스 프론트엔드 디자인 시스템 v1 이 한계에 도달. 새 컴포넌트 라이브러리(Toss Front 2) 를 만들기로 했는데 처음 설계 결정에 실패가 있었다.
lodash 가 무거워졌고, ESM/tree-shaking 시대에 잘 안 맞는 부분이 늘었다.
데이터 드리븐 의사결정이 "지표를 본다" 수준에 머물면 실행으로 안 이어진다.
기존 SAST/DAST 보안 도구는 비즈니스 로직 결함을 못 잡는다. false positive 도 많다.
소프트웨어 작성 패러다임이 1.0(직접 코드) → 2.0(신경망 학습) → 3.0(자연어 의도로 LLM 작동) 로 이동 중. 엔지니어 역할이 달라진다.
외부 개발자가 쓸 SDK 가 어려우면 채택률이 떨어진다. 초기화 부담 / 타입 안전성 / 에러 메시지의 명확함이 핵심.