TL;DR

• 각 패키지 매니저들의 간단한 동작 원리에 대해서 학습한다.
• 각 패키지 매니저들의 장단점을 이해한다.

패키지 매니저란?

패키지 매니저에 대해 알아보기 전에 먼저 패키지가 무엇인지부터 알아보자

패키지 (package)

패키지란 재사용 가능한 코드 조각이다. 즉 어떤 기능을 자주 사용하거나, 직접 구현하기 번거로운 기능을 쉽게 불러다 쓸 수 있도록 배포된 모음이다.

그렇다면, 패키지 매니저는 말 그대로 "패키지"를 관리하는 도구인 것이다. 설명을 덧붙이자면 소프트웨어 라이브러리와 의존성을 관리하는 도구이다. 패키지 매니저는 이러한 라이브러리들을 설치하는 과정에서 의존성(dependency)을 관리해 프로젝트의 효율성을 높여주는 도구이다.

어려운 내용은 아니지만 코드로 간단히 풀어보면 다음과 같다.

직접 구현한 예시

const removeDuplicates = (arr) => {
	return arr.filter((item, index) => arr.indexOf(item) === index);
}
 
const numbers = [1, 2, 2, 3, 4, 4, 5];
console.log(removeDuplicates(numbers)); // [1, 2, 3, 4, 5];

패키지(lodash)를 활용한 예시

const _ = require('lodash');
 
const numbers = [1, 2, 2, 3, 4, 4, 5];
const uniqueNumbers = _.uniq(numbers);
 
console.log(uniqueNumbers); // [1, 2, 3, 4, 5];

package.json

{
	name: "project",
	version: "1.0.0",
	"dependencies": {
		"lodash": "^x.y.z"
	}
}

• 패키지를 활용해 더 짧고 간결한 코드로 동일한 기능을 구현할 수 있다.
• 설치된 패키지는 package.json 파일 안에 명시되고, 패키지 매니저는 이 의존성에 따라 필요한 패키지를 설치하고 관리한다.

❓의존성(dependency) 💡 소프트웨어 문제를 해결하기 위해 작성된 제 3의 소프트웨어

정리하자면 패키지 매니저는 프로젝트의 의존성을 관리하는 도구이다.

패키지 매니저가 동작하는 세 단계

이제 패키지 매니저가 무엇인지 알았으니 어떤 방식으로 동작할지 알아볼 차례이다.

이 부분에 대한 설명은 토스에서 작성한 글과 yarn 공식 문서, 그리고 GPT를 참고했다.

1. Resolution

Resolution 단계는 한 마디로 정의하면 '필요한 버전을 결정(고정) (resolve dependencies)' 하는 단계이다. 패키지 매니저는 이 단계에서 package.json 또는 lock 파일을 참고해 필요한 패키지 버전을 결정한다.

2. Fetch

Resolution의 결과로 '결정된 버전의 패키지를 실제로 다운로드' 하는 단계이다. 이 과정에서 필요한 패키지를 캐시에 저장한다.

3. Link

다운로드한 패키지를 프로젝트의 node_modules에 배치하고, 각 패키지의 의존성도 올바르게 참조할 수 있도록 심볼릭 링크 등을 설정한다. 즉, 'Resolution/Fetch 된 라이브러리를 소스 코드에서 사용할 수 있는 환경을 제공하는 단계' 이다.

패키지 매니저의 종류

이 글을 쓰게 된 가장 중요한 목적이다. 각 패키지 매니저가 어떤 목적을 가지는지, 그리고 장점과 단점에 대해서 알아보려고 한다.

npm

npm(Node Package Manager)는 이름에서 알 수 있듯 Node.js 생태계에서 가장 널리 사용되는 패키지 매니저로, 자바스크립트 개발자들이 패키지를 쉽게 공유할 수 있도록 2009년에 등장했다.

JS 생태계에서 가장 먼저 등장한 패키지 매니저인만큼, 수많은 패키지가 공유되고 있으며 누구나 쉽게 공유하고 다운로드할 수 있다는 점이 가장 큰 특징이자 장점이다.

그러나 npm을 사용하는 개발자들이 고질적으로 겪는 가장 큰 문제가 있는데, 바로 의존성을 설치하는 과정이다. npm은 기본적으로 각 의존성을 설치할 때 모든 의존성을 node_modules 디렉토리 하위에 저장하는데, 의존성의 의존성까지 각기 다른 버전을 허용해 모든 하위 의존성 트리를 중복으로 저장한다.
이렇게 복잡한 트리 구조를 생성하면 패키지를 찾기 위해 node_modules를 계속 타고 올라가게 돼서 속도와 용량 측면에서 문제가 발생하게 되며, 다른 버전의 동일한 패키지가 중복으로 설치되는 문제가 발생할 수 있다.

yarn

(Engineering at Meta - Yarn: A new package manager for JavaScript)

자바스크립트 커뮤니티가 성장하고 각 비즈니스마다 코드베이스가 점점 비대해짐에 따라 일관성, 보안, 성능 측면에서 문제가 발생하게 됐다. 이를 해결하기 위해 2016년 Facebook을 주축으로 개발된 yarn이 등장했다.

yarn은 다음과 같은 문제를 해결하고자 했다.

• 의존성 관리의 안정성 향상
• 성능 개선
• 일관성 있는 설치 환경

yarn은 병렬 다운로드와 Fetching 단계에서 캐싱을 통해 보다 빠르게 패키지를 설치할 수 있도록 했다. 또한 yarn은 yarn.lock 파일을 통해 모든 의존성의 정확한 버전을 고정하여 패키지의 일관성을 보장한다.

• 만약 yarn.lock 파일이 존재하고 package.json에 명시된 모든 의존성을 만족한다면, yarn.lock에 명시된 버전 그대로 설치되고 yarn.lock 파일은 변하지 않는다.
• 만약 yarn.lock 파일이 존재하지 않거나 package.json에 명시된 의존성을 만족하지 않는다면, package.json의 조건을 만족할 수 있는 가장 최신 버전을 찾아 설치하고 이를 yarn.lock 파일에 저장한다.

또한 yarn은 flat한 node_modules 구조를 채택해 node_modules 중첩 문제를 해결했다. flat한 node_modules 구조란, yarn은 node_modules 폴더에 각 패키지를 최상위 수준에 flat하게 설치해 하위 패키지에 대해 중복 설치를 피하고 단일 버전만 배치하는 방식을 말한다. 예를 들어, 여러 패키지가 동일한 버전의 lodash를 의존성으로 가진다면, node_modules/lodash에 한 번만 설치하고 모든 패키지가 이 위치의 lodash를 참조하도록 처리한다.

pnpm

pnpm 공식 문서 - 동기 pnpm은 디스크 공간 효율성과 패키지 설치 속도를 높이기 위해 2017년에 출시되었다.

디스크 공간 효율성 개선

pnpm은 모든 의존성을 전역적으로 단일 위치에 저장하고, 이를 하드 링크로 참조해 추가적인 디스크 공간을 소비하지 않는다.

설치 속도 개선

1. Resolution : 필요한 모든 의존성을 파악해 저장소에 fetch한다.
2. Fetch : 의존성을 기반으로 node_modules 디렉토리 구조를 계산한다.
3. Link : 남아있는 모든 의존성들은 store로부터 node_modules로 fetch하고 하드 링크된다.

하드 링크 방식 덕분에 pnpm은 용량과 속도 문제를 해결할 수 있다. 의존성을 하나만 설치하고, 해당 위치에 바로 접근하고!

또한 pnpm은 symlink를 사용해 프로젝트에 필요한 의존성을 서로 참조하도록 한다. 특정 패키지의 모든 의존성들은 node_modules/.pnpm/ 내의 적절한 디렉토리에 대한 심볼릭 링크가 되도록 한다. (더 자세한 내용은 pnpm 공식 문서 - 평탄한 node_modules가 유일한 방법은 아닙니다. 를 읽고 공부해봐야겠다)

(추가 개념) PnP (Plug'n'Play)

PnP는 yarn의 최신 버전인 yarn berry에서 등장한 전략이다. (주의해야 할 점은, PnP는 패키지 매니저가 아닌 패키지를 설치하는 방식이다.)

PnP는 node_modules 없이 (!) 의존성을 처리하는 것이 특징이다. PnP는 의존성을 .pnp.cjs 파일에 기록하며, 메모리 상에서 패키지를 직접 로드해 더 빠른 패키지 설치를 가능하게 한다.이 과정에서 모든 의존성의 버전을 단일 파일에서 지정함으로써 의존성 문제를 더 엄격하게 관리한다.

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

위와 같이 패키지와 버전을 명시해 node_modules를 사용하지 않음으로써 Link 단계의 속도를 더욱 올렸다.

마치며

이렇게 패키지 매니저가 무엇인지와 각 패키지 매니저가 어떤 문제를 해결하는지, 나아가 PnP에 대해서도 간단하게 다뤄봤다. 글을 쓰며 느낀 점은, 결국 공부를 함에 있어 가장 중요한 점은 해당 기술이 어떤 문제를 해결하는가에 집중하면 해당 기술에 대한 이해가 더 빠르게 된다는 점이다. 이 기술이 어떤 문제를 해결하고, 나는 이 기술을 활용해 어떤 문제를 해결할 수 있는지 를 한 번 더 고민하고 생각하면 더 나은 개발자로 성장할 수 있을 것 같아, 어렵지만 매우 뿌듯한 공부였다!

참고한 글들

• toss tech - 패키지 매니저의 과거, 토스의 선택, 그리고 미래
• toss tech - node_modules로부터 우리를 구원해 줄 Yarn Berry
• Meta - Yarn: A new package manager for JavaScript
• npm 공식 문서
• Yarn 공식 문서
• pnpm 공식 문서
• mdn web docs - Package management basics