nvm으로 Node.js 버전 변경하기: 윈도우(nvm-windows)·맥·리눅스 설치와 nvm 인식 안 됨 오류 해결

왜 Node.js 버전을 바꿔야 하는 상황이 생기는가

Node.js는 대략 1년에 두 번 메이저 버전이 나오고, 짝수 버전이 LTS(장기 지원)가 됩니다. 문제는 프로젝트가 만들어진 시점의 Node 버전에 맞춰 의존성이 고정된다는 점입니다. 3년 전에 만든 사내 프로젝트는 Node 16에서만 빌드되고, 새로 시작한 프로젝트는 최신 LTS가 아니면 설치조차 거부하는 일이 흔합니다. package.json의 engines 필드에 "node": ">=20" 같은 조건이 걸려 있으면 다른 버전에서 경고나 오류가 납니다.

공식 설치 프로그램으로 Node를 깔면 컴퓨터에 버전이 딱 하나만 존재합니다. 다른 버전이 필요할 때마다 지우고 다시 설치하는 것은 번거롭고, 그 과정에서 전역 패키지와 PATH 설정이 꼬이기 쉽습니다. 버전 관리자는 여러 버전을 나란히 설치해 두고, 명령 한 줄로 “지금 node라고 치면 실행될 버전”을 바꿔 줍니다.

기준 환경: Windows 11(PowerShell), macOS(기본 셸 zsh), Ubuntu 24.04(bash). nvm-windows 1.2 계열, nvm-sh 0.40 계열을 기준으로 설명합니다. 두 도구 모두 꾸준히 업데이트되므로 설치 전에 각 저장소의 README에서 최신 버전 번호를 확인하세요.

nvm-windows와 nvm-sh는 다른 프로그램이다

이 부분을 모르고 시작하면 검색해서 찾은 명령이 내 컴퓨터에서 안 먹는 이유를 한참 헤매게 됩니다.

구분	nvm-sh (nvm-sh/nvm)	nvm-windows (coreybutler/nvm-windows)
대상 OS	macOS, 리눅스, WSL	윈도우(네이티브)
구현	POSIX 셸 스크립트(셸 함수)	Go로 만든 실행 파일
버전 전환 방식	현재 셸의 PATH를 바꿈	고정 경로의 심볼릭 링크를 다른 버전 폴더로 바꿈
전환 범위	그 터미널 창에서만	시스템 전체(열려 있는 모든 터미널)
관리자 권한	필요 없음	nvm use 때 필요(기본 설정)
.nvmrc 자동 읽기	nvm use, nvm install 인자 생략 시 읽음	기본적으로 지원하지 않는다고 보는 편이 안전
기본 버전 지정	nvm alias default 22	마지막으로 nvm use한 버전이 유지됨

가장 큰 차이는 “전환 범위”입니다. 맥에서 터미널 두 개를 열고 한쪽에서 nvm use 20을 하면 다른 창은 그대로 22를 씁니다. 셸 함수가 그 셸의 PATH만 바꾸기 때문입니다. 반면 윈도우에서 nvm use 20을 하면 C:\nvm4w\nodejs나 C:\Program Files\nodejs(설치한 버전과 설정에 따라 다름) 같은 고정 경로의 링크 대상이 바뀌므로, 이미 열려 있던 다른 PowerShell 창의 node -v도 20으로 바뀝니다. 윈도우에서 프로젝트 두 개를 서로 다른 버전으로 동시에 띄우기 어려운 이유가 이것입니다.

또 nvm-windows의 문서도 스스로 “nvm-sh의 포트가 아니다”라고 밝히고 있습니다. 그래서 nvm alias, nvm exec, --reinstall-packages-from 같은 nvm-sh 명령은 nvm-windows에 없거나 다르게 동작합니다. 블로그나 Stack Overflow 답변을 볼 때는 그 답이 어느 쪽 nvm 기준인지 먼저 확인하세요.

WSL 안의 우분투에서 Node를 쓴다면 윈도우가 아니라 리눅스 쪽 절차(nvm-sh)를 따릅니다. 윈도우에 깐 nvm-windows와 WSL 안의 nvm은 서로 완전히 독립적입니다. WSL 설치 자체는 WSL2로 윈도우에 우분투 설치하기를 참고하세요.

윈도우: nvm-windows 설치 전에 기존 Node.js부터 지운다

nvm-windows 설치에서 가장 많은 문제가 생기는 지점은 설치 자체가 아니라 이미 설치되어 있던 Node.js입니다. 공식 MSI로 설치한 Node는 C:\Program Files\nodejs에 들어가고 그 경로가 시스템 PATH에 등록됩니다. nvm-windows도 PATH에 자기 링크 경로를 넣는데, 두 경로가 PATH에 함께 있으면 먼저 나오는 쪽이 이깁니다. 그 결과 nvm use 20이 “Now using node v20…”이라고 출력해도 node -v는 계속 예전 MSI 버전을 보여 주는 상황이 생깁니다.

그래서 설치 순서는 다음과 같습니다.

1. 설정 → 앱 → 설치된 앱에서 “Node.js”를 제거합니다.
2. 제거 후에도 남는 폴더를 지웁니다. C:\Program Files\nodejs가 남아 있으면 삭제합니다. 사용자 전역 패키지 폴더인 %AppData%\npm과 캐시 폴더 %LocalAppData%\npm-cache도 이전 버전의 전역 도구가 남아 혼란을 주므로 지우는 것을 권장합니다(필요한 전역 패키지 목록은 미리 npm ls -g --depth=0으로 적어 둡니다).
3. 환경 변수 PATH에 C:\Program Files\nodejs나 %AppData%\npm 항목이 남아 있으면 정리합니다. PATH 편집 방법은 윈도우 PATH 환경 변수 설정에 정리해 두었습니다.

이 단계를 건너뛰면 아래 “exit status 145”나 “버전이 안 바뀐다” 증상의 원인이 됩니다.

설치

GitHub의 coreybutler/nvm-windows 저장소 Releases에서 nvm-setup.exe를 받아 실행하거나, winget을 씁니다.

winget install CoreyButler.NVMforWindows

설치 마법사는 두 경로를 묻습니다. 하나는 nvm과 각 Node 버전이 저장될 위치(NVM_HOME), 다른 하나는 “현재 활성 버전”을 가리킬 심볼릭 링크 위치(NVM_SYMLINK)입니다. 특별한 이유가 없으면 기본값을 그대로 둡니다. 다만 경로에 공백이나 한글이 들어가지 않게 하는 것이 좋습니다. 사용자 폴더 이름이 한글인 PC에서 NVM_HOME을 C:\Users\<한글이름>\AppData\... 아래에 두었다가 설치나 전환이 실패했다는 보고가 꾸준히 있어 왔습니다.

설치가 끝나면 열려 있던 터미널을 모두 닫고 새로 엽니다. 설치 프로그램이 바꾼 환경 변수는 새로 시작한 프로세스에만 반영되기 때문입니다.

nvm version

버전 번호가 나오면 설치가 된 것입니다.

버전 설치와 전환

# 설치 가능한 버전 목록 보기
nvm list available

# 특정 버전 설치 (메이저 번호만 쓰면 그 계열의 최신 버전)
nvm install 22
nvm install 20.18.1

# 설치된 버전 목록 (* 표시가 현재 버전)
nvm list

# 전환: 관리자 권한 PowerShell에서 실행
nvm use 22.11.0

# 확인
node -v
npm -v

nvm install lts, nvm install latest처럼 별칭을 받는 기능도 최근 버전에는 있지만, 설치된 nvm-windows 버전에 따라 동작이 달라 팀 문서에 적을 때는 버전 번호를 명시하는 편이 확실합니다. nvm use에도 메이저 번호만 줄 수 있으나, 같은 계열이 여러 개 설치되어 있으면 어떤 것이 선택될지 헷갈리므로 전체 버전을 쓰는 습관이 안전합니다.

전환이 끝나면 관리자 창이 아닌 평소 터미널에서도 새 버전이 보입니다. 링크 하나가 바뀌었을 뿐이기 때문입니다.

맥·리눅스: nvm-sh 설치와 셸 설정 파일

nvm-sh는 설치 스크립트로 설치합니다. 버전 번호(아래의 v0.40.3)는 README에 적힌 최신 값으로 바꿔서 실행하세요.

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash

이 스크립트가 하는 일은 두 가지입니다. ~/.nvm에 nvm 저장소를 받아 두고, 셸 설정 파일(~/.bashrc, ~/.zshrc, ~/.profile, ~/.bash_profile 중 존재하는 것) 끝에 다음 줄을 추가합니다.

export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # This loads nvm
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"  # This loads nvm bash_completion

nvm은 실행 파일이 아니라 nvm.sh를 읽어 들여 생기는 셸 함수입니다. 그래서 위 줄이 실행된 셸에서만 nvm 명령이 존재합니다. 설치 직후 같은 터미널에서 nvm을 치면 아직 이 줄이 실행되지 않았으므로 command not found가 나는 것이 정상이며, 새 터미널을 열거나 source ~/.zshrc(bash라면 source ~/.bashrc)를 실행하면 됩니다.

확인은 which nvm이 아니라 command -v nvm으로 합니다. which는 PATH에서 실행 파일을 찾는 명령이라 셸 함수인 nvm은 찾지 못하고 아무것도 출력하지 않습니다. 이것을 보고 설치가 실패했다고 오해하는 경우가 많습니다.

command -v nvm
# nvm  ← 이렇게 나오면 정상

macOS에서 Homebrew로 brew install nvm을 하는 방법도 돌아다니지만, nvm-sh README는 Homebrew 설치를 지원하지 않는다고 명시합니다. 문제가 생겼을 때 공식 문서의 해결법이 맞지 않으므로 설치 스크립트를 쓰는 것을 권장합니다.

버전 설치와 기본 버전 지정

# 원격에서 설치 가능한 버전 (LTS만 보기)
nvm ls-remote --lts

# 최신 LTS 설치
nvm install --lts

# 특정 메이저 버전 설치
nvm install 22
nvm install 20

# 현재 셸에서 전환
nvm use 20

# 새 터미널을 열 때 기본으로 쓸 버전
nvm alias default 22

# 설치된 버전과 별칭 확인
nvm ls
nvm current

nvm alias default를 빠뜨리면 흔히 이런 일이 생깁니다. nvm use 20으로 바꾸고 작업을 잘 하다가 다음 날 터미널을 열면 다시 다른 버전이 나옵니다. nvm use는 현재 셸에만 적용되고, 새 셸은 default 별칭이 가리키는 버전으로 시작하기 때문입니다. 처음 nvm install한 버전이 자동으로 default가 되므로, 나중에 주력 버전을 바꿨다면 별칭도 바꿔 줘야 합니다.

.nvmrc로 프로젝트별 버전을 고정하기

팀원이 여럿이면 “이 프로젝트는 Node 몇 버전”을 말로 전달하는 대신 저장소 루트에 .nvmrc 파일을 둡니다. 내용은 버전 문자열 한 줄입니다.

echo "22" > .nvmrc
# 또는 정확한 버전: v22.11.0, 또는 별칭: lts/*

nvm-sh에서는 버전 인자 없이 nvm use나 nvm install을 실행하면 현재 디렉터리부터 위로 올라가며 .nvmrc를 찾아 그 버전을 씁니다.

cd my-project
nvm install   # .nvmrc 버전이 없으면 설치
nvm use       # .nvmrc 버전으로 전환

여기서 흔한 오해가 하나 있습니다. nvm-sh는 디렉터리에 들어가는 것만으로 버전을 바꿔 주지 않습니다. 자동 전환을 원하면 README의 “Deeper Shell Integration” 항목에 있는 zsh용 load-nvmrc 훅이나 bash용 cd 래퍼를 셸 설정에 추가해야 합니다. 이 훅은 디렉터리를 바꿀 때마다 .nvmrc를 확인하므로, 셸이 체감될 만큼 느려졌다고 느끼는 사람도 있습니다. 자동 전환이 꼭 필요하다면 아래에서 소개하는 fnm처럼 그 기능을 기본 제공하는 도구가 더 가볍습니다.

.nvmrc에 22처럼 메이저 버전만 적으면 각자의 PC에 설치된 22 계열 최신 버전이 선택되므로 팀원마다 패치 버전이 다를 수 있습니다. 대부분은 문제가 없지만, 빌드 결과까지 완전히 같아야 하는 프로젝트라면 v22.11.0처럼 전체 버전을 적고 CI에서도 같은 파일을 읽게 합니다. GitHub Actions의 actions/setup-node는 node-version-file: '.nvmrc' 옵션으로 이 파일을 읽을 수 있습니다.

윈도우의 nvm-windows는 .nvmrc를 자동으로 읽는 기능을 기본으로 기대하기 어렵습니다. PowerShell에서는 파일 내용을 직접 넘기는 방식으로 같은 효과를 낼 수 있습니다.

nvm use (Get-Content .nvmrc)

.nvmrc에 22처럼 메이저 번호만 있으면 nvm-windows에서는 해당 계열이 설치되어 있어야 전환되므로, 윈도우 사용자가 섞인 팀이라면 전체 버전 번호를 적어 두는 쪽이 덜 헷갈립니다.

‘nvm’ is not recognized: 윈도우에서 nvm 명령을 못 찾을 때

명령 프롬프트(cmd)에서는 이렇게 나옵니다.

'nvm' is not recognized as an internal or external command,
operable program or batch file.

PowerShell에서는 이렇게 나옵니다.

nvm : The term 'nvm' is not recognized as the name of a cmdlet, function, script file, or operable program.

한국어 윈도우에서는 'nvm'은(는) 내부 또는 외부 명령, 실행할 수 있는 프로그램, 또는 배치 파일이 아닙니다.로 표시됩니다. 원인은 거의 항상 PATH입니다. 순서대로 확인합니다.

1. 터미널을 새로 열었는가. 설치 전부터 열려 있던 터미널, VS Code, Windows Terminal은 예전 환경 변수를 그대로 갖고 있습니다. VS Code나 Windows Terminal은 창 하나만이 아니라 프로그램 전체를 종료한 뒤 다시 실행해야 합니다.

2. 환경 변수가 등록되었는가. 새 PowerShell에서 다음을 실행합니다.

   $env:NVM_HOME
   $env:NVM_SYMLINK
   $env:Path -split ';' | Select-String nvm

   NVM_HOME이 비어 있으면 설치가 중간에 실패했거나 다른 사용자 계정으로 설치된 것입니다. PATH 목록에 %NVM_HOME%과 %NVM_SYMLINK%(또는 그 실제 경로)가 없으면 시스템 환경 변수 편집 창에서 추가합니다.

3. PATH 길이 제한에 걸리지 않았는가. 오래 쓴 PC는 PATH가 매우 길어서 설치 프로그램이 항목을 추가하지 못하는 경우가 있습니다. 쓰지 않는 항목을 정리한 뒤 nvm-windows를 재설치합니다.

exit status 1: Access is denied — nvm use가 실패할 때

nvm use를 실행했는데 다음과 같이 나오는 경우입니다.

exit status 1: Access is denied.

한국어 윈도우에서는 exit status 1: 뒤의 메시지가 인코딩 문제로 알아볼 수 없는 글자로 깨져서 출력되기도 합니다. 깨진 글자 때문에 다른 문제로 착각하기 쉽지만 같은 “액세스가 거부되었습니다” 오류입니다.

원인은 심볼릭 링크 생성 권한입니다. nvm-windows는 버전을 바꿀 때 NVM_SYMLINK 위치의 링크를 지우고 새 버전 폴더를 가리키도록 다시 만드는데, 윈도우는 기본적으로 관리자에게만 심볼릭 링크 생성을 허용합니다. 해결은 다음 중 하나입니다.

• 시작 메뉴에서 PowerShell(또는 Windows Terminal)을 마우스 오른쪽 → 관리자 권한으로 실행한 뒤 nvm use를 실행합니다. 가장 확실한 방법입니다.
• 링크 경로(NVM_SYMLINK)에 백신이나 회사 보안 프로그램이 쓰기 잠금을 걸고 있는 경우도 있습니다. 관리자 권한으로도 같은 오류가 나면 보안 프로그램 로그를 확인합니다.
• 다른 프로세스가 현재 Node 실행 파일을 쥐고 있으면 링크 교체가 실패할 수 있습니다. 실행 중인 개발 서버, VS Code의 TypeScript 서버 등을 종료한 뒤 다시 시도합니다.

비슷한 증상으로 다음 오류도 자주 보입니다.

exit status 145: The directory is not empty.

이것은 NVM_SYMLINK 위치에 링크가 아니라 진짜 폴더가 이미 있을 때 납니다. 대표적으로 MSI로 설치한 Node를 지우지 않고 링크 경로를 C:\Program Files\nodejs로 잡은 경우입니다. nvm-windows는 그 자리에 링크를 만들어야 하는데 실제 파일이 든 폴더가 있으니 지울 수 없습니다. 앞에서 설명한 대로 기존 Node를 제거하고 해당 폴더를 삭제한 뒤 다시 nvm use를 실행합니다.

nvm use가 성공했다고 출력하는데 node -v가 그대로라면 PATH에서 다른 node.exe가 먼저 잡히는 것입니다.

Get-Command node -All | Select-Object Source

결과에 NVM_SYMLINK 경로가 아닌 위치(예: C:\Program Files\nodejs\node.exe, 다른 도구가 번들한 Node)가 먼저 나오면 그 항목을 PATH에서 빼거나 순서를 뒤로 옮깁니다.

nvm: command not found — 맥·리눅스에서 설치 직후

zsh: command not found: nvm

nvm: command not found

앞에서 설명했듯 대부분은 셸 설정 파일이 아직 다시 읽히지 않은 것이므로 새 터미널을 여는 것으로 해결됩니다. 새 터미널에서도 같다면 설정 파일에 초기화 줄이 들어갔는지 봅니다.

grep -n NVM_DIR ~/.zshrc ~/.bashrc ~/.profile ~/.bash_profile 2>/dev/null

아무것도 안 나오는 대표적인 경우가 macOS에서 ~/.zshrc 파일이 아예 없었던 경우입니다. 설치 스크립트는 존재하는 설정 파일에만 줄을 추가하므로, 새로 산 맥처럼 ~/.zshrc가 없으면 zsh가 읽지 않는 파일에 줄을 넣거나 아무 데도 넣지 못합니다. 해결은 간단합니다.

touch ~/.zshrc
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash
source ~/.zshrc

설치 스크립트를 다시 돌리는 대신 위의 export NVM_DIR=... 세 줄을 직접 ~/.zshrc 끝에 붙여 넣어도 됩니다.

리눅스에서 bash를 쓰는데 SSH로 접속했을 때만 nvm이 없다면, 로그인 셸은 ~/.bashrc가 아니라 ~/.bash_profile이나 ~/.profile을 읽기 때문입니다. 우분투 기본 ~/.profile은 ~/.bashrc를 불러오도록 되어 있지만, 누군가 ~/.bash_profile을 만들어 두면 ~/.profile이 무시되어 이 연결이 끊깁니다. ~/.bash_profile에 [ -f ~/.bashrc ] && . ~/.bashrc 한 줄을 넣어 해결합니다.

또 하나, nvm install은 되는데 그다음 nvm use가 N/A: version "v22" is not yet installed라고 나온다면 다른 셸 세션이나 다른 NVM_DIR을 보고 있는 것입니다. root로 설치하고 일반 사용자로 쓰는 식으로 계정이 섞이면 이렇게 됩니다. nvm은 사용자별로 설치하는 도구이므로 실제로 쓸 계정에서 설치해야 합니다.

버전을 바꾸니 전역 npm 패키지가 사라졌다

Node 20에서 npm install -g typescript로 tsc를 쓰다가 22로 바꾸면 이렇게 됩니다.

tsc: command not found

고장이 아니라 설계입니다. nvm은 버전마다 독립된 디렉터리에 Node를 설치하고, 전역 패키지도 그 버전의 디렉터리 안(~/.nvm/versions/node/v20.x.x/lib/node_modules, 윈도우는 NVM_HOME\v20.x.x\node_modules)에 설치됩니다. 버전마다 네이티브 모듈의 ABI가 다르기 때문에, 한 버전에서 컴파일한 전역 패키지를 다른 버전이 공유하면 오히려 더 알기 어려운 오류가 납니다.

nvm-sh에서는 새 버전을 설치할 때 이전 버전의 전역 패키지 목록을 그대로 다시 설치할 수 있습니다.

# 22를 설치하면서 20의 전역 패키지를 다시 설치
nvm install 22 --reinstall-packages-from=20

# 이미 22를 설치했다면, 현재 버전에 20의 전역 패키지 재설치
nvm reinstall-packages 20

nvm-windows에는 이 기능이 없으므로 목록을 보고 직접 설치합니다.

nvm use 20.18.1
npm ls -g --depth=0
nvm use 22.11.0
npm install -g typescript pnpm

이 문제를 근본적으로 줄이는 방법은 전역 설치 자체를 줄이는 것입니다. 프로젝트에서 쓰는 도구(TypeScript, ESLint, 빌드 도구)는 devDependencies에 넣고 npx tsc나 package.json의 scripts로 실행하면, Node 버전을 바꿔도 프로젝트 안의 버전이 그대로 쓰이고 팀원끼리 도구 버전도 맞습니다. 전역에는 어디서나 쓰는 몇 가지 CLI만 남겨 두면 버전 전환이 훨씬 덜 고통스럽습니다.

pnpm이나 Yarn을 쓰는 경우에도 같은 원리가 적용되어, Node 버전을 바꾸면 이전 버전에 전역으로 깐 pnpm이 사라집니다. 이 부분은 아래 Corepack에서 이어서 다룹니다. pnpm 자체의 사용법은 pnpm 가이드를 참고하세요.

nvm 말고 고려할 수 있는 도구

nvm이 유일한 선택지는 아닙니다. 각 도구는 설계 방향이 달라서 상황에 따라 맞는 것이 다릅니다.

• fnm (Fast Node Manager): Rust로 만든 단일 실행 파일이고 윈도우·맥·리눅스를 모두 지원합니다. .nvmrc와 .node-version을 읽으며, fnm env --use-on-cd를 셸 설정에 넣으면 디렉터리에 들어갈 때 자동으로 버전을 바꿉니다. PATH를 셸 단위로 바꾸는 방식이라 윈도우에서도 관리자 권한이나 심볼릭 링크가 필요 없다는 점이 nvm-windows와의 큰 차이입니다. 명령 체계가 nvm-sh와 비슷해 옮겨 가기 쉽습니다.
• Volta: package.json에 "volta": { "node": "22.11.0" } 같은 필드를 두고, 그 프로젝트 안에서 node를 실행하면 자동으로 해당 버전을 쓰는 방식입니다. 전환 명령을 칠 필요가 없다는 것이 장점입니다. 다만 최근 몇 년 사이 유지보수 상황에 대한 공지가 있었으므로 새로 도입한다면 저장소의 현재 상태를 먼저 확인하는 것이 좋습니다.
• mise, asdf: Node뿐 아니라 Python, Go 등 여러 언어 런타임을 한 도구로 관리합니다. 여러 언어를 함께 쓰는 개발자에게 편하고, .nvmrc나 .tool-versions 파일을 읽을 수 있습니다.
• Corepack: Node 버전 관리자가 아니라 패키지 매니저(pnpm, Yarn) 버전 관리자입니다. package.json의 "packageManager": "[email protected]" 필드를 읽어 프로젝트가 정한 pnpm·Yarn 버전을 자동으로 받아 실행합니다. Node 버전을 바꿔도 전역 pnpm을 다시 깔 필요가 없어지는 장점이 있습니다. Node 16.9부터 24까지는 Node에 포함되어 corepack enable로 켜면 되지만, Node 25부터는 기본 포함에서 빠져 npm install -g corepack으로 따로 설치해야 합니다.

정리하면, 이미 nvm으로 잘 쓰고 있다면 굳이 바꿀 이유는 없습니다. 윈도우에서 관리자 권한 문제나 “모든 터미널이 같이 바뀌는” 동작이 불편하다면 fnm을, 여러 언어 런타임을 한 번에 관리하고 싶다면 mise를 살펴볼 만합니다. 어떤 도구를 쓰든 두 개 이상의 Node 버전 관리자를 동시에 설치하면 PATH 우선순위 싸움이 나므로, 바꿀 때는 이전 도구를 먼저 제거하세요.

nvm을 제거하거나 다른 도구로 옮길 때

버전 관리자를 바꾸거나 공식 설치 프로그램으로 돌아가려면, 남은 흔적 때문에 새 도구가 오작동하지 않도록 깨끗이 지워야 합니다.

nvm-sh(맥·리눅스):

# 현재 nvm이 PATH에 넣은 node를 해제
nvm deactivate

# nvm 디렉터리 삭제 (설치한 모든 Node 버전과 전역 패키지가 함께 지워짐)
rm -rf "$NVM_DIR"

그다음 ~/.zshrc, ~/.bashrc 등에서 NVM_DIR로 시작하는 세 줄과, .nvmrc 자동 전환 훅을 추가했다면 그 부분도 지우고 새 터미널을 엽니다. command -v nvm과 command -v node가 아무것도 출력하지 않으면 깨끗이 지워진 것입니다.

nvm-windows:

1. 설정 → 앱에서 “NVM for Windows”를 제거합니다.
2. NVM_HOME 폴더(설치한 Node 버전들이 들어 있음)와 NVM_SYMLINK 경로에 남은 링크를 삭제합니다.
3. 시스템 환경 변수에서 NVM_HOME, NVM_SYMLINK와 PATH의 해당 항목이 지워졌는지 확인합니다.
4. %AppData%\npm에 이전 전역 패키지 실행 파일이 남아 있으면 정리합니다.

정리를 마친 뒤 새 도구를 설치하고, 새 터미널에서 Get-Command node -All(윈도우) 또는 type -a node(맥·리눅스)로 node가 한 군데에서만 잡히는지 확인하면 이후의 버전 문제를 대부분 예방할 수 있습니다.

Node 버전을 맞춘 뒤에도 npm install이 ERESOLVE unable to resolve dependency tree로 실패한다면 Node 버전이 아니라 의존성의 peer 범위 충돌 문제입니다. 이 경우는 npm ERESOLVE 오류 읽는 법과 해결 순서에서 따로 다룹니다. 권한, 네트워크, 캐시 등 다른 원인으로 설치가 실패한다면 npm install 에러 해결 10가지를 참고하세요.