두 매니저의 기능을 나열할 수 있는지가 아니라, 모듈 해석 모델이 다르다는 점과 그 차이가 빌드·에디터·CI에 어떻게 번지는지를 그리는 사람인지를 가른다. 후속 질문은 보통 유령 의존성·PnP 호환성·Zero Install 운영으로 이어진다.
pnpm은 전역 content-addressable store에 패키지 실체를 한 번만 받아두고, 프로젝트 node_modules 안에는 심볼릭 링크로 끌어다 쓰는 방식이다. 그래서 같은 버전의 패키지가 여러 프로젝트에 깔려도 디스크는 한 번만 차지하고, 평탄화하지 않은 트리 구조로 만들어 선언하지 않은 의존성(유령 의존성)도 함께 차단한다. Yarn Berry는 한 발 더 나가 node_modules 자체를 안 만들고, .pnp.cjs라는 인덱스로 "이 패키지는 디스크 어디에 있다"를 직접 매핑하는 PnP 모델을 쓴다. 둘 다 모노레포·워크스페이스를 지원한다는 점은 같지만, pnpm은 "기존 node_modules 구조를 더 효율적으로 다듬는 쪽", Yarn Berry는 "Node의 모듈 해석 자체를 바꿔치우는 쪽"이라는 점에서 결이 다르다.
npm에서 pnpm으로 옮겨 설치 시간이나 도커 이미지 크기가 줄어든 경험이 있다면 측정 수치와 그 이면의 해석 모델 차이로 답을 연결할 수 있다
유령 의존성 때문에 빌드는 되는데 다른 환경에서 깨진 경험이 있다면 두 매니저가 어떻게 그 길을 막는지로 끌고 갈 수 있다
Yarn Berry PnP 환경에서 특정 라이브러리가 안 돌아 unplugged·patch-package 같은 회피책을 쓴 경험이 있다면 호환성 이야기를 구체적으로 풀 수 있다
모노레포 워크스페이스에서 패키지 간 의존성 경계를 정리한 경험이 있다면 "어떤 매니저가 그 경계를 더 자연스럽게 강제하는가"로 답을 한 단계 깊게 만들 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.