pnpm은 JavaScript·TypeScript 프로젝트의 패키지와 실행 명령을 관리하는 도구다. package.json의 의존성을 설치하고 잠금 파일로 실제 해석된 버전을 기록한다. Node.js는 프로그램을 실행하는 환경이고 pnpm은 그 프로그램이 사용하는 패키지를 준비하는 도구이므로 역할이 다르다.
저장소와 의존성 연결
패키지 파일을 내용 주소 기반 저장소에 보관하고 프로젝트에 연결하는 구조를 사용한다. 여러 프로젝트가 같은 파일을 재사용할 수 있어 반복 설치의 디스크 사용을 줄일 수 있다. 실제 복사·링크 방식과 절감량은 파일 시스템과 설정에 영향을 받으므로 모든 환경에서 같은 수치로 빨라진다고 단정할 수는 없다.
기본 구조에서는 직접 선언한 의존성을 중심으로 접근하게 하므로 우연히 설치된 하위 패키지에 기대는 오류를 발견하기 쉽다. 여러 패키지를 한 저장소에서 관리하는 워크스페이스와 선택 실행도 장점이다. 반면 평평한 node_modules 구조를 가정한 오래된 도구는 조정이 필요할 수 있고, 패키지 관리자나 잠금 파일을 무계획하게 섞으면 재현성이 약해진다.
도서관 워크스페이스 예제
Node.js와 pnpm이 준비되어 있다고 가정한다. 가상의 catalog 앱과 공용 규칙 패키지를 관리하는 프로젝트 루트에 pnpm-workspace.yaml을 만들고 다음을 저장한다. 실제 폴더와 각 package.json도 별도로 있어야 한다.
packages:
- 'apps/*'
- 'packages/*'packages/loan-rules의 package.json 이름이 @library/loan-rules라면, apps/catalog의 package.json에는 아래처럼 의존성을 선언할 수 있다. workspace:*는 같은 워크스페이스의 패키지를 사용하겠다는 조건이며 레지스트리의 이름이 같은 패키지를 우연히 내려받는 일을 막는다.
{
"name": "catalog",
"private": true,
"dependencies": { "@library/loan-rules": "workspace:*" },
"scripts": { "test": "node --test" }
}pnpm install
pnpm --filter catalog test
pnpm install --frozen-lockfile첫 설치는 의존성 연결과 잠금 파일을 준비하고, 선택 실행은 catalog의 test 명령을 호출한다. 마지막 명령은 잠금 파일 갱신이 필요한 불일치를 허용하지 않는 설치 방식이다. package.json과 잠금 파일이 서로 맞지 않으면 실패하는 것이 기대한 동작이다.
운영과 협업에서 확인할 점
설치가 성공했다고 프로그램의 타입 검사나 테스트가 끝난 것은 아니다. 팀에서는 pnpm 버전과 Node.js 지원 범위를 함께 정하고 변경된 잠금 파일을 검토한다. 캐시는 다운로드와 재설치 비용을 줄이는 수단이며 패키지의 안전성을 증명하지 않는다. 설치 스크립트가 필요한 네이티브 패키지는 현재 pnpm의 빌드 승인 정책과 배포 환경에서의 실행 가능 여부도 확인한다.
참고 자료
웹·서버 애플리케이션 개발 도구 지도 | |
|---|---|
JavaScript 실행과 빌드 | |
화면 스타일 | |
Rust 개발과 비동기 | Rust (프로그래밍 언어) · Cargo · Tokio · Axum |
Rust 데이터 접근 | |
Java 서버 개발 | |
네이티브 빌드 | |
이미지·영상 처리 | |