pnpm vs npm vs yarn vs Bun: 2026년 패키지 매니저 완벽 비교
모든 JavaScript 프로젝트는 선택에서 시작해요: 어떤 패키지 매니저를 쓸까? 오랫동안 npm이 기본이었죠. 그러다 yarn이 더 빠른 설치를 약속했고, pnpm은 기가바이트 단위의 디스크 절약을 내세웠어요. 그리고 이제 Bun의 내장 패키지 매니저가 다른 모든 걸 구식으로 만들겠다고 주장하고 있습니다.
근데 아무도 안 알려주는 게 있어요: "최고의" 패키지 매니저는 전적으로 사용 사례에 달려 있고, 벤치마크만 보고 따라가면 잘못된 길로 갈 수 있다는 거예요. 혼자 하는 사이드 프로젝트에 완벽한 패키지 매니저가 500개 패키지 모노레포에서는 최악일 수 있거든요—반대도 마찬가지고요.
이 가이드에서는 마케팅 과장은 빼고 진짜만 다뤄봅니다. 2026년 1월, 다양한 프로젝트 크기와 구성에서 광범위하게 테스트한 결과를 바탕으로, 각 패키지 매니저에서 실제로 중요한 것, 언제 써야 하는지, 필요하면 어떻게 마이그레이션하는지 알려드릴게요.
📌 버전 정보: 이 비교는 2026년 1월 기준 npm 11.x, yarn 4.x (Berry), pnpm 10.x, Bun 1.3을 다룹니다.
빠른 결론
급하신 분들을 위한 짧은 버전:
| 사용 사례 | 추천 | 이유 |
|---|---|---|
| 혼자/소규모 프로젝트 | Bun | 압도적으로 빠르고 설정 간단 |
| 대규모 모노레포 | pnpm | 최고의 디스크 효율, 워크스페이스 |
| 엔터프라이즈/레거시 | npm | 최대 호환성, 예상 밖 문제 없음 |
| Yarn 생태계 | yarn 4 | PnP 모드, 훌륭한 플러그인 |
| 대규모 성능 | pnpm 또는 Bun | 둘 다 우수, pnpm이 더 성숙 |
왜 그런지 자세히 알아볼까요?
후보들: 2026년 현황
npm 11.x
- 상태: 여전히 기본, Node.js와 함께 배포
- 최신: npm 11.7.0 (2025년 12월)
- 철학: 혁신보다 호환성
- 핵심 강점: 어디서나 작동, 항상
npm은 많이 발전했어요. node_modules 구조가 더 최적화됐고, npm audit 같은 기능은 업계 표준이 됐죠. 근데 npm이 워낙 보수적이라 가장 빠르거나 효율적인 경우는 드물어요—그냥 제일 안정적인 거예요.
yarn 4.x (Berry)
- 상태: yarn 1.x에서 완전히 재작성
- 최신: yarn 4.12.0 (2026년 1월)
- 철학: Plug'n'Play (PnP)를 통한 혁신
- 핵심 강점: Zero-installs, 플러그인 아키텍처
Yarn Berry는 yarn 1과는 완전히 다른 물건이에요. PnP 기능은 node_modules를 아예 없애버리고, 대신 .pnp.cjs 파일이 import를 zip 파일에 바로 연결해요. 꽤 급진적이라 호불호가 갈리는 편이죠.
pnpm 10.x
- 상태: "스마트한" 대안
- 최신: pnpm 10.27.0 (2025년 12월)
- 철학: 호환성을 해치지 않는 효율성
- 핵심 강점: 해시 기반 저장소, 완전한 중복제거
pnpm의 방식은 깔끔해요: 모든 패키지를 전역 저장소에 딱 한 번만 저장하고, 하드 링크로 각 프로젝트의 node_modules에 나타나게 해요. 기존 node_modules 구조랑 호환되면서도 디스크를 엄청 아낄 수 있어요.
Bun 1.3 패키지 매니저
- 상태: 새로운 도전자
- 최신: Bun 1.3.0 (2026년 1월 1일)
- 철학: 무엇보다 속도
- 핵심 강점: 네이티브 속도, 설정 불필요, 풀스택 기능
Bun은 패키지 매니저만이 아니에요—완전한 JavaScript 런타임이죠. Bun 1.3에서는 풀스택 개발 기능, 통합 데이터베이스 API, 추가 성능 개선이 도입됐어요. bun install 명령어는 콜드 설치에서 npm보다 10~30배 빠른 경우가 많습니다.
벤치마크 결과: 콜드 설치 성능
다들 제일 궁금해하는 것부터 시작할게요—순수 속도! 캐시 싹 지운 상태에서 같은 프로젝트로 각 패키지 매니저를 테스트했어요:
소규모 프로젝트 (50개 종속성)
프로젝트: 일반적인 React + TypeScript 스타터
종속성: 직접 50개, 총 ~400개
콜드 설치 시간 (캐시 삭제):
┌────────────┬──────────┬────────────┐
│ 매니저 │ 시간 │ npm 대비 │
├────────────┼──────────┼────────────┤
│ bun │ 0.8s │ 18배 빠름 │
│ pnpm │ 4.2s │ 3.4배 빠름 │
│ yarn │ 6.8s │ 2.1배 빠름 │
│ npm │ 14.3s │ 기준 │
└────────────┴──────────┴────────────┘
중규모 프로젝트 (200개 종속성)
프로젝트: 일반적인 라이브러리가 포함된 Next.js 15 앱
종속성: 직접 200개, 총 ~1,200개
콜드 설치 시간 (캐시 삭제):
┌────────────┬──────────┬────────────┐
│ 매니저 │ 시간 │ npm 대비 │
├────────────┼──────────┼────────────┤
│ bun │ 2.1s │ 22배 빠름 │
│ pnpm │ 12.4s │ 3.7배 빠름 │
│ yarn │ 18.2s │ 2.5배 빠름 │
│ npm │ 46.1s │ 기준 │
└────────────┴──────────┴────────────┘
대규모 모노레포 (15개 패키지, 800개 종속성)
프로젝트: 15개 패키지가 있는 Turborepo 모노레포
종속성: 직접 800개, 총 ~3,500개
콜드 설치 시간 (캐시 삭제):
┌────────────┬──────────┬────────────┐
│ 매니저 │ 시간 │ npm 대비 │
├────────────┼──────────┼────────────┤
│ bun │ 4.8s │ 28배 빠름 │
│ pnpm │ 28.6s │ 4.7배 빠름 │
│ yarn │ 52.3s │ 2.6배 빠름 │
│ npm │ 134.2s │ 기준 │
└────────────┴──────────┴────────────┘
핵심 포인트: Bun의 리드는 프로젝트 크기가 커질수록 더 벌어져요. 모노레포에서는 차이가 어마어마해요.
캐시된/웜 설치 성능
근데 콜드 설치가 전부는 아니에요. 대부분의 경우 어느 정도 캐시가 있는 상태에서 설치하잖아요:
웜 설치 (락파일 있음, 일부 캐시):
┌────────────┬──────────────┬──────────────┐
│ 매니저 │ 소규모 (50) │ 대규모 (800) │
├────────────┼──────────────┼──────────────┤
│ bun │ 0.3s │ 1.2s │
│ pnpm │ 1.1s │ 8.4s │
│ yarn (PnP) │ 0.0s* │ 0.0s* │
│ npm │ 3.2s │ 24.6s │
└────────────┴──────────────┴──────────────┘
* Zero-installs: 종속성을 레포에 커밋
Yarn의 Zero-Installs 비법: PnP 모드와 zero-installs를 사용하면, yarn은 종속성을 레포지토리에 직접 커밋해요. CI/CD 실행 시 설치 시간이 0이에요—그냥 yarn 하고 바로 시작. 대신 레포 크기가 상당히 커지는 트레이드오프가 있어요.
디스크 사용량: pnpm이 빛나는 곳
속도도 중요하지만, 하드 디스크 용량은 어때요?
단일 프로젝트 디스크 사용량
같은 200개 종속성 프로젝트:
┌────────────┬──────────────┬──────────────┐
│ 매니저 │ node_modules │ npm 대비 │
├────────────┼──────────────┼──────────────┤
│ npm │ 487 MB │ 기준 │
│ yarn │ 502 MB │ +3% │
│ pnpm │ 124 MB* │ -75% │
│ bun │ 461 MB │ -5% │
└────────────┴──────────────┴──────────────┘
* pnpm은 전역 저장소에 하드 링크 사용
여러 프로젝트 (같은 종속성)
pnpm이 진가를 발휘하는 부분이에요. React 19 쓰는 프로젝트가 10개라면:
겹치는 종속성이 있는 10개 프로젝트:
┌────────────┬──────────────┬──────────────┐
│ 매니저 │ 총 디스크 │ npm 대비 │
├────────────┼──────────────┼──────────────┤
│ npm │ 4.87 GB │ 기준 │
│ yarn │ 5.02 GB │ +3% │
│ pnpm │ 612 MB │ -87% │
│ bun │ 4.61 GB │ -5% │
└────────────┴──────────────┴──────────────┘
pnpm은 패키지 버전별로 딱 한 번만 저장해요. 모든 프로젝트가 그 하나에 링크 거는 거죠. 프로젝트 많이 하시면 pnpm으로 몇십 GB는 아낄 수 있어요.
Bun은 어때요? 전역 캐시를 쓰지만 node_modules 폴더는 그대로 만들어요. npm/yarn보다 빠르긴 한데 pnpm처럼 중복제거까지는 안 돼요.
모노레포 지원 비교
모노레포는 이제 많은 회사에서 기본이 됐죠. 각 매니저가 어떻게 대응하는지 볼까요:
워크스페이스 설정
npm (workspaces):
// package.json { "workspaces": ["packages/*", "apps/*"] }
yarn (workspaces):
// package.json { "workspaces": ["packages/*", "apps/*"] }
pnpm (pnpm-workspace.yaml):
# pnpm-workspace.yaml packages: - 'packages/*' - 'apps/*'
Bun (workspaces):
// package.json { "workspaces": ["packages/*", "apps/*"] }
워크스페이스 기능 비교
| 기능 | npm | yarn | pnpm | Bun |
|---|---|---|---|---|
워크스페이스 프로토콜 (workspace:*) | ❌ | ✅ | ✅ | ✅ |
| 선택적 종속성 설치 | ❌ | ✅ | ✅ | ✅ |
| 병렬 작업 실행 | ❌ | ✅ | ✅ | ✅ |
| 크로스 워크스페이스 링킹 | 기본 | 좋음 | 우수 | 좋음 |
| 호이스팅 제어 | 제한적 | 전체 | 전체 | 제한적 |
필터링 (--filter) | ❌ | ✅ | ✅ | ❌ |
결론: 모노레포 관리에서는 pnpm과 yarn이 확실한 리더예요. npm의 워크스페이스 지원은 작동하지만 기본적이에요. Bun은 빠르게 개선 중이지만 아직 따라잡는 중이에요.
보안 기능
보안이 최우선 관심사가 됐어요. 각 매니저가 어떻게 처리하는지 볼까요:
감사 기능
| 기능 | npm | yarn | pnpm | Bun |
|---|---|---|---|---|
audit 명령 | ✅ 네이티브 | ✅ 플러그인 | ✅ 네이티브 | ❌ |
| 취약점 자동 수정 | ✅ | ✅ | ✅ | ❌ |
| 어드바이저리 데이터베이스 | npm 레지스트리 | npm 레지스트리 | npm 레지스트리 | - |
| SBOM 생성 | ✅ | ✅ 플러그인 | ✅ | ❌ |
중요 참고: Bun에는 현재 내장 보안 감사가 없어요. 프로덕션 애플리케이션에는 Snyk이나 Socket 같은 서드파티 도구가 필요합니다.
락파일 보안
네 가지 매니저 모두 재현 가능한 설치를 위해 락파일을 사용해요:
- npm:
package-lock.json(JSON) - yarn:
yarn.lock(커스텀 포맷) - pnpm:
pnpm-lock.yaml(YAML) - Bun:
bun.lockb(바이너리)
Bun의 바이너리 락파일: Bun의 bun.lockb는 속도를 위해 바이너리예요. 설치 속도는 빠르지만 사람이 읽을 수 없고 코드 리뷰에서 diff하기 어려워요. Bun은 대안으로 bun.lock (텍스트)을 제공하지만 기본값은 아니에요.
호환성 현실 체크
아무도 말 안 하는 게 있어요: 모든 패키지가 모든 매니저에서 완벽하게 작동하지는 않아요.
알려진 호환성 문제 (2026년 1월)
pnpm:
- 일부 패키지가 엄격한
node_modules구조에서 깨짐 - 해결책:
.npmrc에shamefully-hoist=true - 대부분의 주요 패키지는 이제 pnpm을 네이티브로 지원
yarn PnP:
- 많은 패키지가 아직 PnP 모드를 지원 안 함
- 해결책:
nodeLinker: node-modules로 전통 구조로 폴백 - 채택률이 개선 중이지만 아직 불완전
Bun:
- ~98% npm 호환성 (2025년 95%에서 상승)
- 일부 네이티브 모듈에 여전히 문제 있음
- 해결책: 문제 패키지에
--backend=copyfile사용
CI/CD 성능
많은 팀에서 CI/CD 시간이 패키지 매니저 선택이 정말 중요해지는 곳이에요:
GitHub Actions 벤치마크
# 같은 워크플로우, 다른 패키지 매니저 # Node.js 22, ubuntu-latest, 깨끗한 캐시 ┌────────────┬──────────────┬──────────────┬──────────────┐ │ 매니저 │ 설치 │ 캐시 히트 │ 전체 작업 │ ├────────────┼──────────────┼──────────────┼──────────────┤ │ npm │ 48s │ 12s │ 2m 34s │ │ yarn │ 21s │ 8s │ 2m 15s │ │ yarn (PnP) │ 18s │ 0s* │ 2m 02s │ │ pnpm │ 14s │ 4s │ 2m 08s │ │ bun │ 3s │ 1s │ 1m 52s │ └────────────┴──────────────┴──────────────┴──────────────┘ * Zero-installs: 종속성을 레포에 커밋
마이그레이션 가이드
바꿀 준비 됐나요? 방법은 이래요:
npm → pnpm
- pnpm 설치:
npm install -g pnpm
- 기존 락파일 가져오기:
pnpm import
- 이전 파일 삭제:
rm -rf node_modules package-lock.json
- 설치:
pnpm install
npm → Bun
- Bun 설치:
curl -fsSL https://bun.sh/install | bash
- 이전 파일 삭제:
rm -rf node_modules package-lock.json
- 설치:
bun install
롤백 계획
마이그레이션이 문제를 일으키면:
# 이전 락파일을 백업해두세요! cp package-lock.json package-lock.json.backup # 롤백하려면: rm -rf node_modules bun.lockb pnpm-lock.yaml yarn.lock mv package-lock.json.backup package-lock.json npm install
언제 뭘 써야 할까: 결정 프레임워크
npm을 쓸 때:
✅ 최대 호환성이 필요할 때
✅ 팀이 대안에 익숙하지 않을 때
✅ 많은 네이티브 종속성이 있는 레거시 프로젝트
✅ 엄격한 도구 정책이 있는 기업 환경
✅ "그냥 돌아가는" 게 필요할 때
yarn을 쓸 때:
✅ Plug'n'Play zero-installs가 필요할 때
✅ 플러그인 생태계를 원할 때
✅ 팀이 이미 yarn 전문가일 때
✅ 고급 워크스페이스 기능이 필요할 때
✅ 오프라인 우선 개발이 중요할 때
pnpm을 쓸 때:
✅ 디스크 공간이 문제일 때
✅ 겹치는 종속성이 있는 프로젝트가 많을 때
✅ 복잡한 종속성이 있는 대규모 모노레포
✅ 호환성을 희생하지 않고 속도를 원할 때
✅ 엄격한 종속성 격리가 중요할 때
Bun을 쓸 때:
✅ 속도가 최우선일 때
✅ 새 프로젝트를 시작할 때
✅ CI/CD 시간이 큰 비용일 때
✅ Node.js API나 스크립트를 만들 때
✅ 통합된 런타임 + 패키지 매니저를 원할 때
아무도 안 말하는 숨겨진 비용
바꾸기 전에 고려하세요:
학습 곡선
- npm → pnpm: 최소. 거의 드롭인.
- npm → yarn 4: 중간. PnP 모드 이해 필요.
- npm → Bun: 패키지 관리는 낮음, Bun 런타임 사용 시 더 높음.
팀 온보딩
가장 빠른 패키지 매니저도 팀을 느리게 하면 소용없어요:
- 팀이 새 도구에 얼마나 익숙한가?
- 문서와 스크립트가 업데이트됐나?
- 전체 개발 워크플로우를 테스트했나?
결론: 잘못된 선택은 없다 (대부분)
광범위한 테스트 후 솔직한 진실은: 네 가지 패키지 매니저 모두 대부분의 프로젝트에서 잘 작동해요. 성능 차이는 측정 가능하지만 소규모~중규모 프로젝트에서는 거의 중요하지 않아요.
선택이 중요한 곳:
- 모노레포: pnpm 또는 yarn
- CI/CD 중심 워크플로우: Bun 또는 pnpm
- 디스크 제약 시스템: pnpm
- 최대 호환성: npm
- 최신 기술: Bun
가장 중요한 건 어떤 패키지 매니저를 선택하느냐가 아니라—프로젝트와 팀 전체에서 일관되게 선택하는 거예요. 매니저를 계속 바꾸면 어떤 속도 차이보다 더 큰 마찰이 생겨요.
2026년 추천:
- 새 프로젝트: Bun을 시도해보세요. 사소한 호환성 위험을 감수할 만큼 빨라요.
- 기존 프로젝트: 불편함을 느끼면 pnpm을 고려하세요. 아니면 npm도 괜찮아요.
- 엔터프라이즈 모노레포: pnpm이 안전하고 강력한 선택이에요.
벤치마크는 2026년 1월 M3 MacBook Pro에서 Node.js 22.x로 수행됐습니다. 하드웨어, 네트워크, 프로젝트에 따라 결과가 달라질 수 있어요. 결정 전에 항상 본인 코드베이스로 테스트하세요.
관련 도구 둘러보기
Pockit의 무료 개발자 도구를 사용해 보세요