본문으로 이동
패키지 매니저의 과거, 토스의 선택, 그리고 미래
문서

패키지 매니저의 과거, 토스의 선택, 그리고 미래

박서진 · 토스 · 토스 기술 블로그

원본 보기

소개

토스는 왜 패키지 매니저로 Yarn을 선택했을까요? 이번 라이트닝 토크에서는 JavaScript의 패키지 매니저, 동작 방식, 그리고 토스의 선택과 앞으로의 방향성에 대해 이야기해 보려고 해요.

AI 핵심 요약

패키지 매니저는 package.json의 버전 범위를 실제 버전으로 확정하고, 파일을 내려받아 코드에서 참조할 수 있게 연결한다. 이 과정은 Resolution·Fetch·Link로 나뉘며, Link 단계에서 npm은 node_modules에 파일을 배치하고 pnpm은 하드 링크를, Yarn PnP는 JavaScript 맵으로 의존성을 찾는다. 토스는 Yarn의 모듈화된 구조와 PnP의 엄격성·성능, 플러그인 확장성을 이유로 Yarn을 유지하되, 저장소와 Git 관리 부담을 줄이기 위해 Zero-install은 기본적으로 끄는 방향을 택했다. 브라우저와 Deno의 Import Map처럼 URL 기반으로 의존성을 연결하는 표준도 소개하며, 현재 Node.js 환경에서는 패키지 매니저가 여전히 필요하다고 설명한다.

  • Resolution은 의존성 트리 전체의 버전을 확정하고 lock 파일에 기록한다.
  • Link 방식은 성능과 호환성의 균형을 고려해 선택한다. npm은 node_modules에 파일을 배치하고, pnpm은 하드 링크를, Yarn PnP는 의존성 맵을 활용한다.
  • PnP는 선언되지 않은 의존성 사용을 막아 의존성 관리를 엄격하게 하지만, Node.js 시작 시간과 node_modules 호환성에 부담이 있다.
  • Zero-install은 PnP와 별개로 설치 파일까지 Git에 포함하는 운영 방식이며, 저장소 크기와 Git 관리 비용을 따져 도입해야 한다.
  • 브라우저와 Deno의 Import Map은 패키지 이름을 URL에 연결해 의존성을 불러오는 방식이다.