패키지 매니저 세 개, 프로젝트마다 하나만 선택해야 해요. 실제로 중요한 기준으로 비교해봤어요.
결정 테이블
| 기준 | npm | pnpm | bun |
|---|---|---|---|
| 설치 속도 | 느림 | 빠름 | 매우 빠름 |
| 디스크 공간 | 큼 | 아주 작음 (store + 하드링크) | 중간 |
| 엄격한 의존성 해결 | 아니오 | 예 | 예 |
| 워크스페이스 / 모노레포 | 기본적 | 우수 | 양호 |
| CI/CD 생태계 | 범용 | 성숙 | 성장 중 |
| 패키지 호환성 | 100% | 99% | 95% |
| 성숙도 | 매우 성숙 | 성숙 | 신생 (2022년부터) |
| 패키지 매니저 외 기능 | 없음 | 없음 | 런타임 + 번들러 + 테스트 |
pnpm을 선택할 때
- 예측 가능성이 새로움보다 중요한 장기적인 진지한 프로젝트.
- 하나의 레포에 여러 패키지가 있는 모노레포(워크스페이스). pnpm은 현재 최고의 구현을 가지고 있어요.
- 디스크 공간이 제한적이거나 같은 머신에 여러 프로젝트(개발 노트북, CI 재사용)가 있을 때. 전역 store가 문자 그대로 기가바이트를 절약해요.
- 일부 네이티브 의존성이나 까다로운 타사 도구에서 100% Node 호환성이 필요할 때.
bun을 선택할 때
- 기존 도구와의 호환성 제약 없이 scratch부터 프로젝트를 시작할 때.
- 패키지 매니저, 번들러, 테스트 러너, 런타임을 하나의 바이너리로 원할 때. 툴체인에 도구가 적을수록 설정도 적어요.
- 성능을 중시할 때 : bun은 공개 벤치마크에서 다른 두 도구보다 훨씬 빠르게 설치하고, 런타임도 보통 Node보다 빠르게 실행돼요.
- 약간의 위험을 감수할 때 : bun은 빠르게 발전 중이고, 일부 네이티브 패키지나 매우 특수한 도구는 아직 문제가 있을 수 있어요.
npm을 유지해야 할 때
새 프로젝트에서는 선택하지 말아요. 하지만 다음 경우에는 유지해요 :
- npm으로 잘 작동 중이고 마이그레이션이 의미 있는 이득을 가져다 주지 않는 기존 프로젝트.
- 다른 걸 지원하지 않는 매우 오래된 CI/CD 환경. 오늘날에는 드물어요.
- npm만 아는 사람이 대다수이고 다른 걸 배울 여유가 없는 팀의 온보딩 상황.
우리의 권장사항
2026년 개인 프로젝트나 팀 프로젝트라면 :
- 기본값은 pnpm : 성숙도, 모노레포, 디스크 절약. Blokby와 내부 도구에서 사용 중이에요.
- 단순함을 원하면 bun : 모든 것을 위한 하나의 도구, 눈에 띄게 더 나은 성능, 약간 덜 범용적인 호환성.
- npm은 하위 호환성에만 : 작동 중인 프로젝트는 급하게 마이그레이션할 필요 없지만, 새로 시작하는 기본값으로는 선택하지 않아요.
더 알아보기
- pnpm 공식 문서 : pnpm.io
- bun 공식 문서 : bun.sh
- npm 공식 문서 : docs.npmjs.com