2026년 기준 신규 프로젝트의 기본 선택은 pnpm이다. npm과 Yarn Berry와의 설치 속도·디스크 사용량·node_modules 구조·모노레포 워크스페이스·CI 환경 차이를 실측 수치로 비교하고, 상황별 선택 기준과 마이그레이션 방법을 정리했다.
2026년 기준 신규 프로젝트의 기본 선택은 pnpm이다. npm은 기존 프로젝트 유지보수용, Yarn Berry는 대형 모노레포에서 PnP나 zero-install이 필요한 상황에 쓴다. 이 글은 세 패키지 매니저의 설치 속도·디스크 사용량·node_modules 구조·워크스페이스·CI 환경 차이를 수치로 비교하고, 상황별 선택 기준과 마이그레이션 방법을 정리한다.
npm은 Node.js와 함께 기본 설치되는 패키지 매니저다. 별도 설치 없이 바로 쓸 수 있고 생태계 표준이라는 점에서 진입 장벽이 없다. 문제는 node_modules 구조가 플랫(flat)하고 용량이 크며, 설치 속도가 상대적으로 느리다는 것이다.
Yarn은 2016년 Facebook이 npm의 느린 속도와 비결정적 설치를 해결하기 위해 만들었다. v1(Classic)과 v2+(Berry)는 내부 구조가 완전히 다르다. Yarn Berry는 PnP(Plug'n'Play) 방식으로 node_modules 폴더 자체를 없애는 것이 목표다.
pnpm은 2017년 등장한 패키지 매니저로, 콘텐츠 주소 저장소(content-addressable store)를 사용해 패키지를 전역 캐시에 한 번만 저장하고 하드링크로 연결한다. 동일 패키지를 10개 프로젝트에서 쓰더라도 디스크에는 딱 한 번만 저장된다.
아래 수치는 React + Next.js 프로젝트(의존성 약 120개) 기준, macOS M4 / Node.js 22 LTS 환경에서 측정한 결과다. 캐시 없는 콜드 인스톨과 캐시 활용 재설치 두 조건을 구분했다.
npm과 Yarn v1은 플랫 node_modules 호이스팅을 사용한다. 의존성의 의존성도 최상위 node_modules에 올라간다. 덕분에 패키지 A가 내부적으로 사용하는 lodash를 A를 통하지 않고 직접 require('lodash')로 불러올 수 있다. 이걸 phantom dependency(유령 의존성)라고 한다.
phantom dependency는 package.json에 명시하지 않은 패키지를 코드에서 실수로 사용하다가, 나중에 상위 패키지가 버전을 올리거나 해당 패키지를 제거하면 런타임 에러가 터지는 구조다. 대규모 프로젝트일수록 이런 문제가 실제로 발생한다.
pnpm은 각 패키지가 자신의 node_modules에 직접 의존성만 갖도록 심링크 구조를 사용한다. 선언하지 않은 패키지는 접근 자체가 불가하다. Yarn Berry의 PnP는 node_modules 폴더를 완전히 제거하고 .pnp.cjs 매핑 파일로 모듈 해석을 대체한다.
모노레포 환경에서 패키지 매니저 선택이 중요한 이유는 워크스페이스 간 의존성 관리와 필터 실행 방식이 크게 다르기 때문이다.
pnpm-workspace.yaml 기반으로 필터링·재귀 실행이 직관적이다. Turborepo, Rush, Nx와의 통합이 잘 돼 있고, 2026년 기준 Nx의 기본 권장 패키지 매니저다.pnpm-workspace.yaml — 모노레포 워크스페이스 설정packages: - 'apps/*' - 'packages/*' - '!**/node_modules/**'
pnpm 워크스페이스 필터 명령어# 특정 패키지만 빌드 pnpm --filter @myapp/web build # 변경된 패키지와 그에 의존하는 패키지 모두 빌드 pnpm --filter ...[origin/main] build # 전체 워크스페이스 병렬 테스트 pnpm -r --parallel test
CI 파이프라인에서 패키지 설치 시간은 실행 비용과 직결된다. GitHub Actions 기준으로 각 매니저의 캐시 전략이 다르고, 결과도 크게 차이난다.
npm은 actions/cache + npm ci 조합이 표준이다. package-lock.json 해시로 캐시 키를 잡는다. 구성이 단순하지만 캐시 히트 시에도 설치 시간이 다른 매니저보다 길다.
pnpm은 pnpm/action-setup을 사용해 전역 store를 캐시한다. 캐시 히트 시 설치가 거의 즉각적이다. 대형 모노레포에서 CI 시간을 40~60% 단축한 사례가 실제로 많다.
Yarn Berry PnP는 .yarn/cache를 레포에 커밋하는 zero-install 전략을 쓸 수 있다. CI에서 yarn install 단계 자체가 사라지지만, 레포 크기가 수백 MB 늘어난다는 트레이드오프가 있다. Git LFS 없이는 관리가 어려워지는 경우가 있다.
GitHub Actions — pnpm store 캐시 설정- uses: pnpm/action-setup@v4 with: version: 9 - uses: actions/setup-node@v4 with: node-version: '22' cache: 'pnpm' - name: Install dependencies run: pnpm install --frozen-lockfile
2026년 기준 신규 프로젝트 기본 선택은 pnpm이다. 설치 속도, 디스크 효율, phantom dependency 방지, 모노레포 지원 모두에서 npm보다 우위에 있다. 특별한 이유 없이 npm을 선택할 근거는 점점 없어지고 있다.
npm을 계속 쓰는 경우: 팀 전체가 npm에 익숙하고 마이그레이션 비용이 실익보다 크다고 판단될 때. 소규모 개인 프로젝트에서 별도 설치 없이 바로 시작하고 싶을 때.
Yarn Berry를 선택하는 경우: 이미 Yarn v1 기반 대형 모노레포가 있고 점진적 업그레이드가 필요할 때. PnP로 완전한 의존성 격리가 필요한 엔터프라이즈 환경. zero-install로 CI 설치 단계 자체를 없애고 싶을 때.
pnpm을 선택하는 경우: 사실상 위 두 조건이 아닌 모든 경우가 해당한다. 특히 디스크 공간이 중요한 개발 환경이나, 여러 프로젝트를 동시에 유지보수할 때 전역 store의 이점이 크다.
기존 npm 또는 Yarn 프로젝트를 pnpm으로 전환하는 과정은 비교적 단순하다. pnpm import 명령어가 기존 lockfile을 읽어 pnpm-lock.yaml을 생성하므로 의존성 버전을 유지한 채 전환할 수 있다.
npm → pnpm 마이그레이션 순서# 1. pnpm 설치 (corepack 사용 권장) corepack enable corepack prepare pnpm@latest --activate # 2. 기존 package-lock.json에서 pnpm-lock.yaml 생성 pnpm import # 3. node_modules 초기화 후 재설치 rm -rf node_modules pnpm install # 4. 기존 lockfile 제거 rm package-lock.json # 또는 yarn.lock # 5. package.json에 패키지 매니저 명시 (선택) # "packageManager": "pnpm@9.x.x"
