NVM으로 여러 Node.js 버전을 어떻게 관리할까요? Node 18, 20, 22, 24 개발 환경 전환 방법과 자주 발생하는 문제

Node 18, 20, 22, 24는 NVM으로 각각 설치한 뒤 nvm use로 현재 터미널에 적용하면 됩니다. 새 터미널의 기본 버전은 별도로 설정하고, 프로젝트마다 버전을 고정하려면 .nvmrc를 사용하세요. 전환 뒤에도 예전 버전이 보이면 셸 설정과 명령 경로부터 확인해야 합니다.

여러 Node.js 프로젝트를 오가며 버전 충돌을 줄이려는 개발자에게 적합합니다.
오래된 프로젝트와 새 런타임의 호환성을 확인하거나, 원격 맥에서 셸 환경을 점검해야 하는 경우에도 참고할 수 있습니다.

마지막 업데이트: 2026년 10월 15일. 명령은 NVM 구현별 공식 문서를, 버전 유지 상태는 Node.js 공식 자료를 확인했습니다.

먼저 구분할 점: 맥의 NVM과 윈도우용 구현은 다릅니다

맥과 리눅스에서는 일반적으로 nvm-sh/nvm을 셸 함수로 불러옵니다. 윈도우에서 쓰는 nvm-windows는 별도 구현이므로, 설치·전환 방식과 프로젝트 파일 지원을 같은 것으로 보면 안 됩니다. 아래의 .nvmrc와 nvm alias default 절차는 맥과 리눅스의 nvm-sh/nvm을 기준으로 합니다. (github.com)

버전 번호만 보고 운영 환경의 안전성까지 판단하지 않는 것도 중요합니다. 2026년 10월 15일에 확인한 Node.js 공식 릴리스 정보에서 Node 18과 Node 20은 지원 종료, Node 22와 Node 24는 장기 지원 상태로 표시됩니다. 따라서 앞의 두 버전은 기존 서비스 재현이나 호환성 확인에 필요한 경우에 한해 사용하고, 새 운영 환경은 프로젝트 의존성과 지원 정책을 확인해 결정하는 편이 안전합니다. (nodejs.org)

선택	맞는 상황	판단
현재 터미널에서만 `nvm use`	테스트용으로 잠시 다른 버전을 실행할 때	적합도 높음
`nvm alias default` 설정	새 터미널을 열 때마다 같은 버전으로 시작해야 할 때	적합도 높음
프로젝트에 `.nvmrc` 추가	저장소마다 요구 버전이 다를 때	적합도 가장 높음
윈도우용 NVM 명령을 맥에 적용	구현을 구분하지 않고 명령을 복사할 때	부적합

Node 18, 20, 22, 24를 설치하고 현재 버전을 확인합니다

맥에서 nvm-sh/nvm을 이미 설치하고 셸 초기화까지 마쳤다면, 프로젝트에서 필요한 주 버전을 지정해 설치합니다.

nvm install 18
nvm install 20
nvm install 22
nvm install 24

이 명령은 해당 주 버전의 설치 가능한 버전을 가져옵니다. 프로젝트가 세부 버전까지 고정해야 한다면 저장소의 설정과 배포 환경을 먼저 확인하고, 필요한 전체 버전을 지정하세요. 설치된 목록은 nvm ls, 원격에서 설치 가능한 목록은 nvm ls-remote로 확인할 수 있습니다. 현재 활성 버전은 nvm current 또는 node -v로 확인합니다. 명령 형식은 NVM 공식 사용법을 따릅니다. (github.com)

현재 터미널과 새 터미널의 기본 버전을 따로 설정합니다

현재 셸에서만 바꿀 때는 원하는 버전을 지정합니다.

nvm use 18
node -v
which node

이후 같은 셸에서 node를 실행하면 선택한 버전을 사용합니다. which node로 명령 파일의 경로도 함께 보면, 출력된 버전과 실제 실행 파일이 일치하는지 확인하기 쉽습니다.

새로 여는 셸의 기본값은 별도로 설정합니다.

nvm alias default 22

이 설정은 프로젝트별 선택을 대신하지 않습니다. 새 터미널을 열어 node -v, nvm current, which node를 다시 확인하세요. 새 셸이 계속 다른 버전을 가리킨다면 기본값이 적용되지 않은 것인지, 셸 초기화 파일이 NVM을 불러오지 않는 것인지 분리해서 점검해야 합니다. (github.com)

프로젝트마다 버전을 고정하고 자동 전환 여부를 확인합니다

저장소 루트에 .nvmrc를 두면, nvm-sh/nvm은 해당 파일을 기준으로 버전을 선택할 수 있습니다. 예를 들어 프로젝트에서 Node 22를 쓰기로 결정했다면 파일에 사용할 버전을 적고 줄을 바꿉니다.

프로젝트 폴더에서 다음 명령을 실행합니다.

nvm install
nvm use
node -v

이미 설치된 버전이면 선택하고, 아직 없다면 nvm install이 파일에 지정된 버전을 설치합니다. 저장소 간 결과를 더 엄격하게 맞춰야 한다면 주 버전만 적을지, 세부 버전을 고정할지 팀의 개발·배포 기준에 맞춰 정해야 합니다. .nvmrc를 읽는 기능이 있다고 해서 디렉터리를 이동할 때 모든 셸이 자동 전환되는 것은 아닙니다. 자동 적용은 셸 설정이나 별도 연동에 따라 달라지므로, 직접 nvm use를 실행해 검증하는 방식이 명확합니다. (github.com)

전환이 안 될 때는 셸과 PATH를 순서대로 점검합니다

예전 버전이 계속 보이거나 nvm: command not found가 나오면 다음 순서로 확인합니다.

현재 셸이 NVM을 불러오는지 확인합니다. 맥의 기본 셸 설정과 설치한 셸이 일치하는지 살핍니다. nvm-sh/nvm 초기화 구문이 해당 셸의 시작 파일에 있어야 합니다. 공식 문서의 셸별 설치 안내와 현재 셸 설정을 대조하세요. (github.com)
설치 여부를 확인합니다. nvm ls에 목표 버전이 없다면 먼저 nvm install 22처럼 설치합니다. 설치되지 않은 버전으로 전환하려 하면 원하는 결과를 얻을 수 없습니다.
새 셸에서 기본값을 검증합니다. nvm alias default 22를 실행한 뒤 새 터미널을 열고 nvm current와 node -v를 확인합니다.
PATH에 다른 Node.js가 앞서는지 확인합니다. type -a node와 which node를 실행해 경로를 살핍니다. NVM이 관리하는 경로 대신 시스템 설치 경로가 먼저 나오면, 셸 설정에서 PATH가 만들어지는 순서나 중복 설치를 점검합니다.
실행 파일과 버전이 맞는지 대조합니다. nvm which current와 node -v를 함께 확인합니다. 터미널 앱뿐 아니라 원격 접속 셸과 개발 도구 내장 터미널도 각각 확인해야 합니다. 서로 다른 시작 방식은 서로 다른 셸 설정을 읽을 수 있습니다.

전역 패키지도 버전 전환과 함께 확인해야 합니다. npm install -g로 설치한 도구는 현재 활성 Node.js와 연결된 npm 환경에 설치될 수 있으므로, 버전을 바꾼 뒤 npm -v와 해당 도구의 실행 여부를 다시 검사하세요. 전역 명령이 사라진 것처럼 보여도 패키지가 삭제된 게 아니라 다른 버전의 환경에 설치되어 있을 수 있습니다. (docs.npmjs.com)

윈도우용 구현을 사용하는 경우에는 명령이 다릅니다. 공식 nvm-windows 안내에 나온 nvm install <버전>, nvm list, nvm use <버전>을 기준으로 확인하고, 맥용 nvm-sh/nvm의 별칭이나 셸 초기화 절차를 그대로 적용하지 마세요. (github.com)

원격 맥에서는 터미널과 프로젝트 설정을 함께 검증합니다

원격 맥에서 전환 결과를 확인할 때는 프로젝트 루트에서 먼저 .nvmrc를 읽고, nvm use를 실행한 다음 아래 항목을 기록하면 됩니다.

node -v가 프로젝트에서 정한 버전과 일치하는지 확인합니다.
npm -v가 실행되는지 확인하고, 필요한 전역 도구도 사용할 수 있는지 점검합니다.
which node와 nvm which current의 경로가 예상한 NVM 환경을 가리키는지 봅니다.
새 터미널과 원격 접속 터미널에서 같은 확인을 반복해 셸 설정 차이를 찾습니다.
Node 18, 20, 22, 24를 각각 시험해야 한다면, 버전을 바꿀 때마다 위 출력을 남겨 프로젝트별 결과와 구분합니다.

원격 환경을 새로 준비해야 한다면 원격 맥 대여 환경에서 실제 제공 조건을 확인할 수 있습니다. 셸 초기화나 터미널 설정 문제를 더 살펴보려면 맥 지원 안내를 참고하세요. 해당 환경에서 특정 Node 버전이 이미 준비되어 있다고 가정하지 말고, 접속 후 직접 설치 상태와 경로를 확인해야 합니다.

마지막으로 전환 전에는 프로젝트가 요구하는 버전, 현재 터미널의 node -v, which node 경로를 함께 확인하세요. 로컬 맥을 이미 보유하고 있고 장기간 안정적으로 개발한다면 직접 설치한 환경을 유지하는 편이 맞을 수 있습니다. 반면 로컬 장비에 맥 환경이 없거나, 호환성 검증을 위해 원격 맥을 잠시 써야 한다면 장비를 먼저 구매하는 비용과 관리 부담, 기존 윈도우·리눅스 환경에서 생기는 맥 전용 테스트의 제약을 비교할 필요가 있습니다. 그 경우 Zilmac의 맥 대여 환경을 살펴보고, 실제 이용 가능한 환경이 필요한 작업에 맞는지 확인한 뒤 선택하면 됩니다.