원문 : https://pavel-romanov.com/5-node-version-managers-compared-which-is-right-for-you#heading-volta
목차
여러분이 Node.js 프로젝트에 참가했다고 가정해 봅시다. 프로젝트를 살펴보려고 하는데 오류가 발생했습니다. 무엇이 문제일까요? 시간을 들여 확인한 끝에 당신의 컴퓨터에서 사용 중이던 Node.js 버전이 프로젝트에서 필요로 하는 버전과 다르다는 것을 알게 되었습니다.
이는 매우 흔하고 성가신 상황입니다. 저도 여러 번 겪었습니다. 이러한 문제를 피하기 위해 똑똑한 사람들은 "노드 버전 관리자"라는 도구를 개발했습니다. 이는 Node.js 버전을 쉽게 전환할 수 있도록 도와주는 셸 도구입니다.
이 글에서는 Node.js 버전 관리자 시장에 초점을 맞추려고 합니다. 이들이 서로 어떻게 다른지 그리고 어떤 것을 고려해야하는 지 확인하실 수 있습니다.
기준
보다 쉽게 비교하기 위해 다음의 몇 가지 기준을 세우겠습니다.
- 크로스 플랫폼 : 크로스 플랫폼을 지원하는가?
- 사전 설정 : 초기 설치에 얼마나 큰 노력이 필요한가?
- 노드 버전 소스 : 어떤 소스에서 Node.js 버전을 파싱하는가?
- 일상적인 사용성 : 버전 관리자를 얼마나 쉽고 원활히 사용할 수 있는가?
후보
비교
위에서 정의한 기준을 바탕으로 각각의 후보를 더 자세히 살펴보겠습니다.
Node Version Manager (NVM)
노드 버전 관리를 위한 가장 인기 있는 솔루션입니다(적어도 GitHub 리포지토리 스타 기준, 75.2k). 왜냐하면 초기에 등장했기 때문입니다. 최초 혹은 최초에 가까운 Node.js 버전 관리자 중 하나였으며 커뮤니티에서 큰 인기를 얻었습니다.
크로스 플랫폼을 지원할까요? 딱히 그렇지는 않습니다. 완전한 Windows 지원을 제공하지 않습니다. GitBash (MSYS), Cygwin, 그리고 WSL(Windows Subsystem for Linux) 와 같은 일부 경우에만 동작합니다. nvm-windows라는 Windows를 위한 별도의 패키지가 있지만 NVM 자체는 아닙니다.
또 다른 한계점은 bash 또는 zsh과 같은 POSIX 셸만을 지원한다는 것입니다. 따라서 Fish와 같이 다른 셸의 사용자들은 사용하기가 어렵습니다.
NVM을 설치하는 가장 간단한 방법은 다음의 명령어를 실행하는 것입니다.
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bashNVM을 사용하여 서로 다른 Node.js 버전 간에 전환하는 방법은 다음과 같습니다.
user@machine:~/project node -v
v21.7.2
user@machine:~/project cat .nvmrc
18.19.1
user@machine:~/project nvm use
user@machine:~/project node -v
v18.19.1NVM은 .nvmrc파일을 통해 어떤 버전의 Node.js를 사용할지 파악할 수 있습니다. 버전을 전환하기 전에 이 파일을 생성하거나 nvm use 18.10과 같이 전환할 Node.js 버전을 명시적으로 선언해야 합니다.
nvm use 명령어를 실행하면 현재 셸의 Node.js 버전이 설정된다는 점에 유의해야 합니다. 이게 무슨 뜻일까요? 보고있던 프로젝트 폴더를 나와서 다른 프로젝트를 탐색하더라도 nvm use 명령어를 다시 실행하기 전까지 Node.js 버전은 동일하게 유지된다는 의미입니다.
현재 셸에서 사용하는 Node.js 버전과 특정 프로젝트에서 필요한 버전을 항상 알고 있어야 하므로 워크플로에 더 많은 마찰이 발생하고 인지 부하가 커집니다.
가능한 모든 Node.js 버전을 수동으로 관리하는 것보다는 낫지만 원활한 통합과는 거리가 멉니다.
N
N은 또 다른 인기 있는 Node.js 버전 관리자입니다(18.5k GitHub 스타).
크로스 플랫폼을 지원하지 않고 NVM보다도 제약 사항이 많습니다. PowerShell과 같은 Microsoft Windows의 기본 셸, Windows 용 Git Bash 또는 Cygwin DLL에서는 작동하지 않습니다.
N은 NPM을 통해 바로 설치할 수 있습니다. npm install -g n을 실행하세요. 또한 macOS에서는 Brew를 이용하거나 sh 스크립트를 다운로드하여 설치할 수 있습니다.
curl -L https://bit.ly/n-install | bashN의 큰 장점 중 하나는 "engines" 섹션을 통해 Node 버전을 직접적으로 추적할 수 있다는 것입니다. 다음과 같은 package.json 구조를 갖고 있다고 가정해 봅시다.
{
"name": "project",
"version": "1.0.0",
"main": "index.js",
"engines": {
"node": "18.17.0"
},
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"keywords": [],
"license": "ISC"
}engines 섹션에 명시한 대로 N은 "18.17.0" 버전을 설치할 것입니다.
그러나 N은 NVM과 비슷한 문제가 있습니다. 서로 다른 프로젝트에서 특정한 Node.js 버전을 사용하려면 계속해서 사용자가 직접 추적해야 합니다.
게다가 N은 이 문제를 더욱 복잡하게 만듭니다. N을 사용한다는 것은 "전역" Node.js 버전을 관리한다는 것입니다. 따라서 셸을 닫은 후에도 최근 프로젝트에서 사용한 노드 버전이 유지되기 때문에 최상의 경험이라고 할 수 없습니다.
Fast Node Manager (FNM)
FNM은 Rust로 작성된 노드 버전 관리자로 N만큼 인기가 있습니다(15.2k GitHub 스타).
FNM은 소개한 후보들 중에서 최초의 크로스 플랫폼 노드 버전 관리자입니다. Windows에서도 추가 패키지를 설치할 필요 없이 잘 동작합니다.
설치 과정은 명확하고 직관적입니다.
# macOS
brew install fnm
# rust의 패키지 관리자 cargo를 사용
cargo - cargo install fnm
# windows에서 winget을 사용
winget - winget install Schniz.fnmUnix 기반의 OS에서는 bash 스크립트를 사용합니다.
curl -fsSL https://fnm.vercel.app/install | bashFNM은 셸마다 Node.js 버전을 관리하며 N처럼 전역 버전 관리를 통해 기본 워크플로를 구축하려고 하지 않습니다. 전역으로 설정된 "기본" 버전이 있으며 이는 Node.js 버전을 명시하지 않은 일부 프로젝트에 대해 폴백(fallback) 역할을 합니다.
FNM의 또 다른 멋진 기능은 현재 위치한 폴더에 기반하여 자동으로 Node.js 버전을 전환하는 것입니다. 그러나 이를 위해 설정을 추가해야 합니다.
다음과 같은 방식으로 자동 전환이 동작합니다. 만약 18.17.0 버전을 사용하는 한 프로젝트에서 20.12.1 버전을 사용하는 다른 프로젝트로 전환한다고 가정하면, 새로운 프로젝트 폴더로 전환한 이후에 FNM은 자동으로 Node.js 버전을 전환합니다.
user@machine:~ node -v
V21.7.2
user@machine:~ cd project-1
Using Node.js v18.17.0
user@machine:~/project-1 cat .node-version
18.17.0
user@machine:~/project-1 cd ..
user@machine:~ node -v
V18.17.0
user@machine:~ cd project-2
Using Node.js V20.12.1
user@machine:~/project-2 cat .node-version
v20.12.1두 프로젝트 사이를 전환하면 프로젝트 내의 .node-version 파일에 따라 노드 버전이 자동으로 변경됩니다.
자동 전환이 잘 동작하려면 필요한 버전의 Node.js를 반드시 설치해 놓아야 합니다.
또 한 가지 기억해야 할 점은 프로젝트 내의 추가 파일(.node-version 또는 .nvmrc)에서만 노드 버전을 감지할 수 있다는 것입니다.
Volta
Volta는 버전 관리자 세계에서 떠오르는 샛별입니다(10k개 GitHub 스타).
Rust로 작성되었으며 크로스 플랫폼을 지원합니다.
Unix 기반의 시스템에서는 설치 프로세스가 원활히 진행됩니다.
curl https://get.volta.sh | bashWindows는 별도의 설치 프로그램이 있습니다.
Volta의 Node.js 버전을 구성할 때 별도의 파일을 생성할 필요가 없습니다. Volta는 package.json의 구성을 사용합니다.
{
"name": "project",
"version": "1.0.0",
"main": "index.js",
"engines": {
"node": "18.17.0"
},
}이러한 구성의 이점은 engines 섹션이 Volta 구성의 바로 옆에 있다는 것입니다. 이를 통해 손쉽게 동기화 상태를 유지할 수 있습니다. 별도의 파일에 위치해있다면 각각의 버전을 동기화하는 것을 잊어버리기 쉽습니다.
또 다른 큰 특징은 툴체인(toolchain) 관리 기능입니다. 무슨 뜻일까요?
패키지 관리자로 Yarn을 사용한다고 가정해봅시다. 다른 Node.js 버전 관리자는 오직 Node.js 버전만을 관리할 수 있습니다. 이와 동시에 Yarn 버전은 프로젝트마다 달라질 수 있습니다.
여기에서 Volta가 빛을 발합니다. Node.js 버전뿐만 아니라 Yarn 버전도 동적으로 변경할 수 있습니다. "volta" 구성 섹션에 Yarn 버전을 추가하기만 하면 됩니다.
"volta": {
"node": "18.17.0",
"yarn": "1.22.22"
}설치 명령어를 입력할 때마다 Volta는 선언된 Node.js 및 Yarn 버전이 일치하는 것을 보장합니다. 놀랍지 않나요?
PNPM
놀라지 마세요. PNPM은 일반적으로 패키지 관리자인 NPM과 Yarn의 대체제로 잘 알려져 있습니다. 하지만 이들과 다르게 PNPM은 Node.js 버전 또한 관리할 수 있습니다.
PNPM은 크로스 플랫폼을 지원하며 모든 플랫폼에서 동일한 Node.js 버전 관리 환경을 제공합니다.
하지만, PNPM을 노드 버전 관리자로 사용하는 데는 네 가지 단점이 있습니다.
첫 번째로 PNPM은 본질적으로 노드 버전 관리자가 아닙니다. Node.js 버전을 관리할 수 있는 패키지 관리자입니다. NPM 또는 Yarn과 같은 다른 패키지 관리자와는 쉽게 사용할 수 없습니다.
두 번째는 PNPM을 사용하여 설치한 Node.js에서는 Corepack이 함께 제공되지 않는다는 것입니다. 다음은 공식 문서의 설명입니다.
PNPM 환경에는 Corepack용 바이너리가 포함되어 있지 않습니다. 다른 패키지 관리자를 설치하기 위해 Corepack을 사용하고 싶다면 별도로 설치해야 합니다 (ex. PNPM add -g corepack).
세 번째로 PNPM은 Node.js 버전을 전역으로만 관리할 수 있습니다. 셸마다 구성하는 것은 불가능합니다. 만약 --global 플래그 없이 설치하려고 시도한다면 다음과 같은 에러 메시지가 표시됩니다.
"pnpm env use <version>" 은 현재로선 "--global" 옵션과 함께만 사용할 수 있습니다.
프로젝트를 이동할 때 Node.js 버전을 동적으로 변경해주지 않습니다. 즉, 스스로 Node.js 버전을 추적하여 프로젝트에서 요구하는 버전과 일치하는지를 확인해야 한다는 뜻입니다.
결론
지금까지 Node.js 버전 관리자는 먼 길을 걸어왔습니다. NVM은 최초이자 오랜 기간 가장 인기 있는 솔루션이고 지금도 여전히 그렇습니다.
하지만 생태계는 발전하고 있습니다. 시간이 지나면서 N, FNM, 그리고 Volta와 같은 다른 도구가 등장했습니다. 모두 각각의 장단점을 갖고 있습니다.
현재 시점에서 Volta가 가장 기능이 풍부하고 완전한 Node.js 버전 관리자로 보입니다. 크로스 플랫폼을 지원하며, 일상적인 사용 환경에서 원활한 경험을 제공하고 프로젝트에서 사용하는 다른 도구도 함께 관리할 수 있습니다.
asdf는 논외일까요?