요약 : npm이 나쁜 건 아니에요. 하지만 15년 전에 설계되었고, 그때는 프로젝트 의존성이 다섯 개 수준이었고 디스크 중복을 신경 쓰는 사람이 없었어요. 지금은 두 경쟁자(pnpm과 bun)가 같은 일을 더 빠르게, 적은 디스크 공간으로, 더 안전하게 해요. 2026년에 새 프로젝트에서 npm을 선택할 이유는 거의 없어요.
npm의 역사적 문제
프로젝트에서 npm install을 실행하면 :
- npm이 각 의존성을 다운로드해요. 프로젝트마다
node_modules/에 한 번씩. - 각 하위 의존성도 다운로드되고 복사돼요. 다른 패키지들이 약간 다른 버전으로 참조하면 여러 번 복사될 수도 있어요.
- 디스크에서 중간 규모 프로젝트의
node_modules/는 300MB에서 1GB가 돼요. 프로젝트가 열 개면 열 배예요.
실질적인 결과 : 설치에 5분이 걸리는 node_modules/ 폴더, SSD에서 수 기가바이트, 보통 나머지 프로젝트 전체보다 더 무거운 폴더.
두 번째 문제 : 허용적인 의존성 해결
기본적으로 npm은 의존성을 "평탄화"해요. 패키지 A가 패키지 B에 의존하는 경우, 다른 패키지가 설치한 패키지 C에도 접근할 수 있어요. 내 프로젝트가 명시적으로 C에 의존하지 않더라도요. 이걸 팬텀 의존성(phantom dependency) 문제라고 해요.
결과 : 로컬에서는 작동하다가, 어느 날 패키지 업데이트로 팬텀 의존성이 제거되면, 코드를 건드리지 않았는데 프로덕션 빌드가 깨져요. 진단도 어렵고, 재현도 고통스러워요.
세 번째 문제 : 속도
npm은 많은 작업을 직렬로 실행해요. 100개 의존성 프로젝트의 초기 설치는 쉽게 30~60초가 걸리고, 느린 연결에서는 훨씬 더 걸려요. 매 빌드마다 재설치하는 CI에서는 실제 시간과 탄소 낭비예요.
pnpm과 bun이 하는 것
- pnpm은 각 패키지의 복사본 하나를 전역 store(
~/.local/share/pnpm/store또는 동등한 경로)에 보관하고,node_modules/에 하드링크를 생성해요. 디스크에서 파일 하나가 열 개 프로젝트에서 사용돼요. - bun은 더 급진적이에요 : Zig로 작성된 바이너리, 공격적인 병렬화, 공개 벤치마크에서 npm보다 5~20배 빠른 설치.
- 두 도구 모두 기본적으로 엄격한 의존성 해결을 적용해요 : 패키지는 선언된 의존성에만 접근할 수 있어요. 팬텀 의존성 버그가 불가능해져요.
npm을 유지해야 할 때
- npm으로 잘 작동 중인 기존 프로젝트에서 팀이 이미 익숙하고
package-lock.json이 정상 작동 중일 때. 급하게 마이그레이션할 필요 없어요. - 매우 제한적인 환경 : 일부 아주 오래된 호스팅 서비스는 npm만 지원해요. 2026년에는 점점 드물어요.
- 타사 도구가
node_modules/구조에 대한 가정을 하는 경우. 역시 드물어요.
이런 경우 외에는, 새 프로젝트에 npm을 선택할 이유가 없어요. 다음 레슨에서 pnpm과 bun의 차이를 자세히 비교해서 둘 중 하나를 선택할 수 있게 해드릴게요.