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

🤔 turborepo로 모노레포 프로젝트를 시작하려고 설치를 하기 위한 패키지 매니저들 중 어떤 걸 사용해야 하나?
이들의 차이와 선택 기준은 뭘까?

Turborepo 설치

🍀 때마침 패키지 매니저에 대해 한번 짚고 넘어가 보려다가 토스에 패키지 매니저의 과거, 토스의 선택, 그리고 미래란 좋은 글이 올라와서 정리해보고자 한다. 

👩🏻‍💻 살펴볼 내용
- 패키지 매니저가 무엇인지
- 패키지 매니저가 동작하는 3가지 단계
- npm vs pnpm vs Yarn PnP
- 토스의 Pick

 

👩🏻‍💻 패키지 매니저란?

모듈시스템 (ESM & CJS)에 대해서 다뤘듯이 JS/TS에서는 require 혹은 import로 외부의 모듈을 사용할 수 있다.

여기서 외부의 모듈을 올바르게 참조하도록 관리하는 프로그램이 바로바로 패키지 매니저다.

프로젝트를 시작(ex. yarn install)하면 package.json이 최상위 디렉터리에 생기는 걸 흔히 떠올릴 수 있다.

혹은 cra를 하면 자동적으로 package.json이 생기고,

이 package.json에서 현재 리액트 버전이 무엇인지와 어떤 버전들을 사용할 수 있는지 명시할 수 있다.

{
  "dependencies": {
    "react": "^18.2.0" // react는 ≥ 18.2.0, <19 사이의 어떤 버전이든지 쓸 수 있다고 명시
  }
}

 

모든 소스 코드 파일이 어떤 버전의 라이브러리를 사용할 수 있는 지를 package.json 파일에 디펜던시를 명시하고,

터미널에서 yarn install 을 입력하면 package.json에서 명시된 버전이 설치된다. 

즉, 패키지 매니저는 명시한 버전대로 외부 라이브러리들을 설치하여 모호함을 없애주는 역할을 해준다. 

🔗 패키지 매니저가 동작하는 세 단계 : Resolution ➡️ Fetch ➡️ Link

이제 패키지 매니저는 버저닝 문제를 해결해 주는 프로그램이라는 걸 알게 되었으니, 어떻게 동작하는지에 대해 살펴보자.

yarn의 동작 3단계 : Resolution, Fetch, Link

1. Resolution : 버전 고정 ➡️ 다른 의존성 확인 ➡️ 다른 의존성 버전 고정

📕 Resolution의 사전적 뜻은 '결단/결심'이다. 무엇을 결단한다는 걸까?

우리는 종종 새해가 되면 '결심'을 한다. 뜬금없이 왜 새해 결심에 대해 이야기하나 싶겠지만, 
이 Resolution단계가 우리가 새해 결심을 하는 것과 유사하다 (다만 패키지 매니저는 새해 결심을 반드시 완수한다는 점에서는 다를 수도..).

예를 들면, 새해가 되면 올해는 "다이어트 해야지! 🏋️"라는 결심을 할 수 있다.
"다이어트는 식단이지" 닭가슴살을 주문하기로 한다.

🍗 닭가슴살을 주문하는 과정을 Resolution 단계와 비교하자면,
package.json 파일에 명시된 버전에 따라 정확한 버전 고정(닭가슴살 유통기한에 따라 개수를 결정)하고,
의존성 버전을 고정(냉장고 안의 다른 음식들 유통기한 살펴 결정)시키고, 의존성의 의존성을 찾아 그 버전을 고정(식비와 칼로리 섭취에 대한 결정)한다.

Resolution 단계에서 하는 일에 대한 감을 가지고 더 상세히 살펴보자.

 

1. Resolution의 첫 단계는 package.json 파일에 명시된 버전 범위에 따라 정확한 버전 고정한다. 

예를 들면, "^" 규칙은  18.2.0이상 , 19 미만 사이의 어떤 버전이든지 쓸 수 있다는 것을 명시한 package.json에서는

해당 범위의 가장 가능한 최신버전을 사용한다. 따라서 18.3.1 버전을 선택한다.

{
  "dependencies": {
    "react": "^18.2.0" // react는 ≥ 18.2.0, <19 사이의 어떤 버전이든지 쓸 수 있다고 명시
  }
}

 

2. Resolution의 두번째 단계는 설치한 다른 라이브러리들의 의존성을 확인한다.

예를 들면, @toss/use-overlay는 react를 사용하는데,  react도 의존성을 가지고 있다.

따라서 의존성의 의존성에는 어떤 것이 있는지 파악해야 한다.

 

3. Resolution의 마지막 단계는 의존성 자체의 버전 고정한다.

의존성의 버전을 범위로 명시하고, 패키지 별로 의존성을 지니기 때문에 같은 package.json에 대해서도 의존성 버전이 

달라질 수 있기 때문에 의존성 자체에도 버저닝을 해야 한다.

예를 들면, Next 14에서 app 라우터가 등장하면서, app 라우터를 사용한다면 useRouter훅은 next/router가 아닌 next/navigation에서 import 되어야 하는데, Next 13.1 + React18.1.0에서는 동작하는 코드가 Next 14.2 + React18.2.0을 사용하는 기기에서는 버그를 일으킬 수 있다.

Resolution의 역할은 의존성 고정문제를 해결하는 하는 것이다. 

이렇게 고정한 모든 의존성들과 의존성들 간의 버전을 고정한 버전은 yarn.lock이나 package-lock.json에 저장된다. 

2. Fetch : 결정된 버전의 파일을 다운로드

Resolution을 통해 yarn.lock에 명시된 패키지들을 실제로 다운로드하는 과정이다.

네트워크를 통해 npm 레지스트리(99%)에서 다 받아온다.

(닭가슴살 주문서를 토대로 집에 배송되는 과정)

3. Link : Resoltion과 Fetch 된 라이브러리를 소스 코드에서 사용할 수 있는 환경을 제공

npm, pnpm, PnP(Plug'n'Play) 사례를 살펴보면서 Link 단계에서는 어떤 일이 발생하는지 알아보자.

(1) npm Linker

- node_modules 기반의 Linker

- package.json에서 명시하는 모든 의존성을 그냥 node_modules 디렉터리 아래에 하나씩 쓰는 역할을 한다.

 

- 동작 예시 : React와 TDS 모바일 라이브러리의 react-dialog을 사용한다고 할 때

    - my-service의 node_modules 하위에는 react와 TDS 모바일 패키지가 추가되고,

    - TDS 모바일 패키지에도 node_modules가 있다면 @radix-ui/dialog를 또 추가해 준다.

my-service/
└─ node_modules/
|  ├─ react/
|  |  
|  └─ @tossteam/tds-mobile/
|     └─ node_modules/
|         └─ @radix-ui/react-dialog
|
└─ src
    └─ index.ts

 

- 단점 : 실제 파일 시스템에 디렉터리와 파일을 일일이 추가하고 사용하기 때문에, 패키지를 찾기 위해 node_modules를 계속 타고 올라가야 한다. 따라서 import/require 속도가 느려지고, 디렉터리도 비대해진다. Hoisting이라는 방식으로 개선을 시도한다고는 하지만, 아직 불안정하고 최적화가 불완전하다는 점에서 더 좋은 Linker 옵션을 살펴보자.

(2) pnpm Linker

pnpm의 공식 사이트는 pnpm은 빠르고 디스크 공간을 효율적으로 사용하는 패키지 매니저라고 소개한다.

 

- Pnpm의 장점

  - npm 보다 두 배까지 빠르다.

  - node_modules 안의 파일들은 하나의 content-addressable storage(이름이나 위치가 아닌 내용을 기준으로 정보가 저장된 저장소)에 복제 또는 hard link 되기 때문에 효율적. Hard link 방식은 alias를 걸어서 alias에 바로 접근하여 의존성이 디스크에 하나만 설치되도록 한다. 

  - 모노레포 지원: 하나의 리포지터리 내의 여러 패키지들을 빌트인 지원.

  -  pnpm은 디폴트로 non-flat node_modules을 만드므로 임의의 패키지에 접근할 위험이 없다.

 

npm에서 디렉터리를 계속 돌면서 파일들을 일일히 찾아 만들고, 찾을 때도 하나씩 찾아 쓰는 번거로움은 개선되었지만,

pnpm에서는 alias를 걸기 위해 디렉토리를 도는 작업은 여전히 필요하다.  그리고 node_modules 디렉터리 자체는 그대로 유지하므로 파일 읽기 과정이 많으면 중간중간 멈추는 문제도 발생한다고 한다.

(3) PnP Linker

🤔 그럼 node_modules 디렉토리 자체가 없다면 더 빠르지 않을까?

PnP Linker는 node_modules로 의존성을 처리하는 대신, JS 객체로 처리한다.

JS 객체로 처리가 가능한 것은 패키지 import 할 때에는 결국 "어디 파일"에서 "무엇"을 import 하는가에 초점을 맞췄기 때문이다.

 

PnP 동작은 다음과 같다.

 

먼저 yarn install을 하면 아래와 같은. pnp.cjs라는 파일이 생긴다.

["my-service", /* ... */ [{
  // ./my-service에서...
  "packageLocation": "./my-service/",
  "packageDependencies": [
    // React를 import 하면 18.2.0 버전을 제공하라.
    ["react", "npm:18.2.0"]
  ]
]

// 마찬가지로 리액트 사용시 npm 18.2.0이 위치한 곳과,
// 그 아래의 패키지를 import하면 명시된 버전의 패키지를 반환하라.

/* react 패키지 중에서 */
["react", [
  /* npm:18.2.0 버전은 */
  ["npm:18.2.0", {
    /* 이 위치에 있고 */
    "packageLocation": "./.yarn/cache/react-npm-18.2.0-98658812fc-a76d86ec97.zip/node_modules/react/",
    /* 이 의존성들을 참조한다. */
    "packageDependencies": [
      ["loose-envify", "npm:1.4.0"]
    ],
  }]
]],

 

yarn을 실행하는 순간, Node.js 프로세스가 --require와 --loader옵션을 사용해서 이 Map을 메모리에 전부 로드하고, import과 require문에서 이 Map을 참조한다.

yarn.lock 기반으로. pnp.cjs 파일 하나만 써서 설치를 하면 되므로 속도가 빠르다.

메모리에 파일이 로드된 후 Map 연산만 하면 되기 때문에  node_modules을 순회하는데 시간을  할애할 필요가 없기 때문이다.

반면, Node.js 프로세스가 뜨는 속도가 느리고 node_modules 디렉터리와 호환성이 낮다는 점에서 아쉬운 점도 있다.

🛝 PnP vs. Zero-install

플러그 앤 플레이 (PnP)와 zero-install은 어감 때문인지 혼동하는 경우가 종종 있다.

 

하지만 이 둘은 명백히 다르다.

 

PnP Linker에서 살펴봤듯이, PnP는 node_modules 없이 JS Map 객체로 의존성을 관리하는 방식이다.

한편, Zero-install은 PnP의 JS Map 객체와 Fetch 된 의존성들까지 모두 Git에 넣어 버전을 관리하자는 방식이다.

즉, npm을 사용하면서 Zero-install을  할 수도 있고(⚠️ 의존성 중복으로 인해 용량 거대해지므로 yarn 사용 지향),

PnP를 사용하면서도 Zero-install을 사용할 수 있다.

 

토스에서는 프런트엔드 팀이 작았을 당시에는,

브랜치 변경 시 yarn install을 했을 때 안되면 node_modules을 제거하고,

다시 설치해야 하는 번거로움을 Zero-install을 해결했다고 한다.

모든 의존성 버전 관리를 git으로 하기 때문에 Zero-install은 편리하지만,

점차 레포지터리가 커지면서 오히려 git 관리가 까다로워져서 Zero-install을 기본으로 끄는 방향으로 진행하고 있다고 한다.

 

결국, 프로젝트의 크기와 필요성에 따라 사용 여부와 방식이 달라질 수 있다는 것이다.

마지막으로 토스의 선택 (스포: Yarn🤭)의 이유와 토스가 지향하는 방향성,

그리고 이번 프로젝트에서 결정사항에 대해 다루고 마무리 지으려고 한다.

🧶 토스의 Pick

토스는 지금까지 Yarn사용하고 있다. 그 이유는 크게 4가지가 있다고 한다.

 

1. Yarn의 아키텍처 설계 방식

     - 패키지 매니저의 각 구성 요소가 모듈화 되어 있으며, 인터페이스가 잘 분리되어 있다.

     - Resolution, Fetch와 Link 각 단계의 코드가 분리되어 고 모듈화 되어 있는 건 PnP 밖에 없고, 코드작성 방식과 컨벤션도 일관적이다.

2. 정확성

     - PnP는 가장 엄격하고 정확한 설치 방식이기 때문에 에러 발생 가능성이 적다.

     - dependencies/peerDependencies에 명시하지 않은 의존성은 참조할 일이 없다. 따라서 npm/pnpm에서도 잘 동작한다.

3. 성능

     - PnP는 파일 I/O의 수가 적고, 설치 과정 또한 간단해서 속도가 빠르다. 또한 CLI 품질이 제일 좋고 읽기 편하다고 하다.

     - 설치 시 걸리는 시간 비교 : npm (30초) >> pnpm (8초) > yarn

 

[출처] https://pnpm.io/benchmarks : npm, pnpm, yarn, yarn pnp 설치 시간을 초단위로 비교 (그래프가 작을 수록 빠름)

 

4. 확장 가능성

     - Yarn은 코어 부분을 제외하면 전부 플러그인화 되어 있어서 (Pluggable) 다양한 기능을 쉽게 추가 가능하기 때문에 API 확장성이 좋다.

 

즉, yarn pnp가 지닌 깔끔한 아키텍처, 확장 가능성, 정확성, 성능을 토대로 토스가 패키지 매니저로 Pick 한 것이다.

토스는 Zero-install은 끄고, 레포지터리 크기를 줄이는 방향으로 나아가고 있다고 한다.

따라서 브랜치 변경 시 yarn install을 해줘야 하는 번거로움이 있겠지만

Git에 주는 부하가 더 크고,. pnp.cjs 파일 충돌이 더 큰 이슈라고 판단한 거 같다.

📦 JS 표준으로 패키지 관리 방법

🤔 package.json이 없는 브라우저나 Deno 같은 환경에서는 패키지 매니저 관리를 어떻게 할까?

 

브라우저에서도 패키지 매니저와 비슷한 JS 표준 방식인 Import Map이 있다. 

Import Map이 react로 지정된 URL로 매핑하여, 해당 URL로 React를 불러오는 방식의 예시를 살펴보자.

// React를 명시
<script type="importmap">
{
  "imports": {
    "react": "https://cdn.jsdelivr.net/npm/react@17/umd/react.development.js"
  }
}
</script>

// 스크립트 타입을 모듈로 지정한 후,
// 리액트에서 가져오기
<script type="module">
  import React from 'react';
</script>

 

Deno와 브라우저는 위의 방식으로 패키지 매니저를 관리하고 있으며, JS 표준이 향하고 있는 방향, Node.js도 Import Map을 지원하고 있다는 점에서 미루어보면, 어떤 패키지 매니저를 선택할 것인지에 대한 논의 자체가 불필요할 수 있을 것 같다.

즉, 현재는 Node.js에서는 패키지 매니저가 필수지만,

먼 미래에는 패키지 매니저 없이 모든 의존성을 가져오는 방식으로 전환할 수 있는 행복한 미래가 올 수도 있다.

🤔 마치면서 : pnpm냐, Yarn PnP냐 

여기까지 읽었다면 당연히 Yarn PnP를 써야겠다고 생각할 수 있다.

하지만 둘의 장점을 비교하면 갈팡질팡..

 

- pnpm: content-addressed storage 시스템을 활용하는 아키텍쳐 덕분에 고성능, 크기가 큰 모노레포에 효율적 (빠른 설치 + 캐싱), 의존성 관리 유연성이 높음 (peer/optional 의존성 등등)

- yarn pnp:  의존성이 많은 큰 규모의 프로젝트, 그리고 보안과 엄격한 conflict 방지, 모노레포에서 효율적 사용 가능성

 

처음 모노레포를 구성하는 프로젝트라서 당연히 Yarn PnP을 써봐야겠다 싶으면서도 pnpm도 좋은 옵션이라고 하니까 고민이 된다. 결론적으로 pnpm을 먼저 사용해 보고 사용했던 경험을 토대로 나중에 기회가 된다면 yarn pnp도 사용해 사용 경험을 직접 비교해보고 싶다.

---

📚 References

https://toss.tech/article/lightning-talks-package-manager

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

https://yarnpkg.com/

Home page | Yarn

https://pnpm.io/ko/

Fast, disk space efficient package manager | pnpm

https://www.npmjs.com/

npm | Home

https://nextjs.org/docs/app/api-reference/functions/use-router#migrating-from-nextrouter

Functions: useRouter | Next.js

https://en.wikipedia.org/wiki/Content-addressable_storage

Content-addressable storage - Wikipedia

https://yarnpkg.com/features/pnp

Plug'n'Play | Yarn

https://www.syncfusion.com/blogs/post/pnpm-vs-npm-vs-yarn

PNPM vs. NPM vs. Yarn: What Should I Choose in 2024?