[Frontend] 패키지 매니저의 동작 과정

목차 (OPEN)

• ⚙️ 패키지 매니저는 어떻게 작동할까
• 1️⃣ Resolution 단계 (누굴 설치할지 정하는 단계)
• 2️⃣ Fetch 단계 (결정된 버전의 파일을 받아오는 단계)
• 3️⃣ Link 단계 (코드에서 쓸 수 있게 연결해주는 단계)
• 🔸 npm 방식
• 🔸 pnpm 방식
• 🔸 Yarn Plug’n’Play (PnP)
• ✅ 총정리

 

 

 

⚙️ 패키지 매니저는 어떻게 작동할까

프론트엔드 개발을 하면서 yarn install이나 npm install은

거의 반사적으로 치는 명령어 중 하나이다.

 

나는 문득, "이 명령어가 내부적으로 어떤 일을 하고 있는걸까?" 라는 궁금증이 생겼다.

 

결론부터 말하면 패키지 매니저는

Resolution → Fetch → Link 라는 과정을 통해서

우리가 쓸 수 있는 상태로 의존성을 준비해준다.

 

그런데 이 과정을 좀 더 깊이 이해하고 나면,

실무에서 더 안정적이고 예측 가능한 개발 환경을 만들 수 있다는 걸 알게 되었다.

따라서 이 글에서는 각 단계가 어떤 역할을 하는지,

어떻게 동작하는 지를 하나씩 정리해보고자 한다.

 

 

---

1️⃣ Resolution 단계 (누굴 설치할지 정하는 단계)

Resolution 단계는 쉽게 말하면,

이 프로젝트에 어떤 패키지들이 필요하고,

그 중 어떤 버전을 설치해야 할지 결정하는 과정이다.

 

예를 들어 package.json에 아래처럼 적혀 있다고 해보자.

{
  "dependencies": {
    "react": "^18.2.0",
    "lodash": "~4.17.21"
  }
}

 

패키지 매니저는 여기에 명시된버전 범위를 해석해서

react는 18.2.0 이상, 19.0.0 미만 중 가능한 최신 버전을,

lodash는 4.17.21 이상, 4.18 미만 중 가장 안정적인 버전을 찾는다.

 

또한, 각 패키지들이 또 어떤 패키지를 의존하고 있는지,

즉 의존성의 의존성(dependency of dependency)도 전부 따라가서 전체 트리를 구성해준다.

 

그리고 이러한 작업이 끝나면 생기는 게 바로

yarn.lock 또는 package-lock.json이다.

여기에는 누가 누구랑 어떤 버전으로 연결되어야 하는지에 대한 스냅샷이 담기게 된다.

 

이러한 과정을 거치는 이유는

누가 설치하든, 언제 설치하든, 항상 같은 의존성 구조를 유지하기 위함이다.

 

 

---

2️⃣ Fetch 단계 (결정된 버전의 파일을 받아오는 단계)

Resolution 단계에서 어떤 버전의 패키지를 설치할지 결정되었다면,

이제는 그 실제 파일을 받아와야 할 차례다.

 

이때 수행되는 과정이 Fetch 단계인데, 말 그대로

결정된 버전의 패키지를 공식 저장소에서 다운로드하는 과정이다.

 

이 단계에서 주로 일어나는 작업은 아래의 세 가지가 있다.

✅ .tgz 형태의 압축 패키지 받아오기

✅ 캐시 저장소에 저장하기

✅ 중복 다운로드 방지하기 (같은 버전은 다시 다운로드하지 않도록)

 

이 과정에서, ~/.yarn/cache/ , ~/.npm 같은 디렉토리에

이렇게 다운로드한 패키지들이 캐시 형태로 저장되는데,

이 캐시 덕분에, 같은 패키지를 여러 번 설치해도

이미 받은 파일을 다시 다운로드할 필요가 없기 때문에

속도가 훨씬 빨라진다.

 

정리하자면, Fetch 단계란

결정된 버전을 효율적으로 가져오는 과정이라고 보면 된다.

 

 

---

3️⃣ Link 단계 (코드에서 쓸 수 있게 연결해주는 단계)

이제 필요한 패키지를 다 받았으니,

마지막으로 해야 할 일은

이걸 실제 코드에서 사용할 수 있게 연결해주는 것이다.

그리고 이 작업을 해주는 게 바로 Link 단계이다.

 

그러나 이 Link 단계는 생각보다 복잡하고,

패키지 매니저마다 차이가 많이 난다.

 

따라서 패키지 매니저 유형별로 알아보고자 한다.

 

---

🔸 npm 방식

npm은 node_modules 폴더에 물리적으로 디렉토리를 만들고,

각 패키지를 그 안에 복사해서 넣는다.

 

예를 들면 아래와 같은 구조가 만들어질 것이다.

my-project/
├── node_modules/
│   ├── react/
│   └── lodash/

 

이 방식은 파일 시스템 기반이라 이해하기 쉽고, 호환성도 매우 좋지만,

구조적으로 여러 문제가 있다고 한다.

 

✅ 장점

🔄 가장 보편적인 방식으로, 대부분의 툴 및 라이브러리와 호환된다.

🧩 구조가 직관적이라 디버깅이 쉽다.

🤝 오랜 시간 써온 방식이라 레거시 프로젝트에서 안전하다.

 

❌ 단점

🐢 패키지를 import 할 때마다 디렉토리를 재귀적으로 탐색해서 속도가 느리다.

📁 여러 프로젝트가 동일한 패키지를 쓴다 해도, 매번 따로 복사해서 저장하기에 디스크 낭비가 크다.

🔀 버전이 미묘하게 다르면 node_modules 아래에 중첩 디렉토리가 생기고, 트리가 복잡해진다.

 

 

---

🔸 pnpm 방식

pnpm은 npm의 한계를 극복하기 위해 등장한 방식으로,

패키지를 한 번만 설치하고, 각 프로젝트에서는 링크만 건다는 특징이 있다.

 

예를 들면 아래와 같은 구조가 될 것 이다.

~/.pnpm-store/ ← 여기에 실제 패키지가 설치됨

my-project/
├── node_modules/
│   └── react/ ← 여기는 실제 복사본이 아니라 하드링크

 

이 기반은 하드링크 기반의 효율적인 구조로,

여기에도 장단점이 존재한다.

 

✅ 장점

🚀 중복 다운로드 및 설치가 없으므로 속도가 빠르다.

💾 하나만 설치해서 여러 프로젝트가 공유하므로 디스크가 절약된다.

🧹 의존성 충돌이 적고, node_modules도 정돈돼서 깔끔한 트리 구조를 유지한다.

🔄 npm 처럼 node_moduels를 사용하므로 호환성 문제가 적다.

 

❌ 단점

🧰 파일 시스템을 더 깊이 활용하므로, Windows 등 일부 환경에서 하드링크 관련 이슈가 발생할 수 있다.

🔍 의존성 디버깅이 다소 복잡할 수 있다. (링크 경로를 따라가야 하기 때문에)

 

 

---

🔸 Yarn Plug’n’Play (PnP)

Yarn PnP는 아예 발상의 전환을 시도한 것이다.

 

"왜 굳이 node_modules 폴더를 만들어야 하지?

그냥 메모리 기반으로 연결해버리면 안되나?"

 

라는 생각에서 시작된 것으로,

동작 원리는 아래와 같다.

 

1) yarn install 시 .pnp.cjs 파일을 생성한다.

2) 이 파일은 어떤 패키지가 어떤 버전이고, 어디에 저장되어 있는지를 JS 객체(Map) 형태로 관리한다.

3) Node.js가 실행될 때, 이 매핑 정보를 로딩해서 import/require 경로를 해석한다.

 

이 방법에도 역시 장단점은 존재한다.

 

✅ 장점

⚡ 디렉토리 생성 없이 .zip 캐시만 쓰면 돼서 설치 속도가 매우 빠르다.

📚 철저하게 버전을 분리하기에 의존성 충돌이 거의 없다.

🧠 dependencies에 명시되지 않은 라이브러리는 사용 불가하기에 품질 관리에 유리하다.

 

❌ 단점

📦 일부 라이브러리나 툴에서 PnP를 지원하지 않아서 호환성 이슈가 있다.

🛠️ .pnp.cjs , VSCode , webpack , babel 등 추가 설정이 필요하다.

💥 기존 node_moduels 구조를 가정한 도구들과 충돌이 일어날 가능성이 있다.

 

---

✅ 총정리

구분	npm	pnpm	Yarn PnP
속도	🐢 느림	🚀 빠름	⚡ 매우 빠름
디스크 공간	📁 많이 씀	💾 적게 씀	📦 최소화
호환성	✅ 최고	✅ 높음	⚠️ 낮음
설정 난이도	🔧 쉬움	🔧 중간	🔧 어려움
디버깅 편의	쉬움	보통	어려움
사용 추천 상황	보편적인 프로젝트	빠른 개발, 모노레포	고도화된 프로젝트 속도 및 정확성이 우선인 경우