Node.js 설치 및 NPM 사용 가이드 (2026 최신)

Node.js 설치는 자바스크립트 개발에 입문하면서 누구나 처음 마주치는 관문이다. 막 시작했을 때 다들 한 번은 막힌다. 분명 자바스크립트는 브라우저에서 도는 언어라고 배웠는데, 왜 터미널에 명령어를 치고 패키지를 깔라고 하는지 감이 안 잡힌다. 바로 그 답이 Node.js다. Node.js 설치는 자바스크립트를 브라우저 밖으로 꺼내 서버와 빌드 도구의 세계로 들어가는 첫 단추다. 이 글에서는 설치부터 NPM 사용법까지, 입문자가 한 번에 따라올 수 있게 2026년 기준으로 다시 정리한다.

Node.js가 대체 뭔가

Node.js는 한마디로 자바스크립트 실행 환경이다. 크롬에 들어가는 V8 자바스크립트 엔진을 떼어내, 브라우저 없이도 자바스크립트를 돌릴 수 있게 만든 런타임이다. 런타임이란 프로그래밍 언어가 실제로 구동되는 환경을 말한다.

예전에는 자바스크립트가 브라우저 안에서만 살았다. 웹페이지를 움직이는 게 전부였다. 그런데 Node.js가 나오면서 이 한계가 깨졌다. 서버를 돌리고, 파일을 읽고, 빌드 도구를 만드는 일까지 전부 자바스크립트 하나로 가능해졌다. 엔진과 런타임이 정확히 어떻게 다른지 궁금하다면 자바스크립트 엔진과 런타임의 차이점 이해하기를 먼저 읽고 오면 이 글이 훨씬 쉽게 읽힌다.

어떤 일에 강한가

Node.js의 성격을 정리하면 이렇다.

자바스크립트를 서버에서도 쓸 수 있게 만든 프로그램이다.
V8 엔진 위에서 도는 자바스크립트 런타임이다. 언어가 아니라 환경이다.
확장성 있는 네트워크 프로그램을 만들려고 설계됐다.

그래서 동시에 수많은 요청을 받아내야 하고, 빠른 응답과 빠른 개발이 필요한 비동기 서비스에 잘 맞는다. 실시간 채팅, 스트리밍, 알림 서버 같은 게 대표적이다. 반대로 한 번의 계산이 오래 걸리는 무거운 작업에는 약하다. Node.js는 기본적으로 싱글 스레드로 돌기 때문이다. 처리 하나가 길게 늘어지면 그 뒤에 줄 선 요청들이 다 같이 막힌다.

실제로 큰 회사들이 Node.js로 서비스를 굴린다. Netflix, LinkedIn, PayPal, Uber, Meta가 잘 알려진 사례다. 특히 프론트엔드 개발과 궁합이 좋다. 이유는 셋이다.

최신 스펙으로 개발: 브라우저의 지원 속도는 자바스크립트 표준보다 늘 늦다. 그 간극을 메우려고 Vite나 NPM 같은, Node.js 기술로 만든 도구가 필요하다.
빌드 자동화: 코드는 그대로 브라우저에 올리지 않는다. 압축하고, 난독화하고, 폴리필을 더한 뒤 배포한다. 이 과정을 Node.js 기반 도구가 일관되게 처리한다.
개발환경 커스터마이징: Vue CLI나 React 템플릿 같은 도구로 프로젝트를 손쉽게 시작하고, 필요하면 환경을 직접 짜맞출 수도 있다.

Node.js 설치: LTS와 Current 중 뭘 깔아야 하나

Node.js 공식 사이트에 들어가면 다운로드 버튼이 두 개 보인다. LTS와 Current다.

Node.js 설치를 위한 공식 홈페이지의 LTS와 Current 다운로드 화면

차이는 단순하다. Current는 가장 최신 기능을 먼저 담은 버전이다. 새로운 걸 빨리 써볼 수 있지만, 안정화가 덜 됐다. 기능이 패치를 거치며 바뀌거나 사라질 수 있어, 코드를 다시 손봐야 하는 일이 생긴다. LTS(Long Term Support)는 장기 지원 버전이다. 보안 패치와 개선이 일정 기간 보장되고, 같은 코드는 언제나 같은 동작을 한다. 그래서 특별한 이유가 없다면 LTS를 깔면 된다.

2026년 6월 현재 기준으로 보면, 활성 LTS는 Node.js 24 라인이고, Node.js 22는 유지보수 LTS로 아직 지원된다. Node.js 26은 그해 10월 LTS 승격을 앞둔 Current 라인이다. 한 가지 알아둘 변화가 있다. Node.js 팀은 릴리스 일정 개편을 예고했다. 2026년 10월부터는 메이저 버전을 1년에 한 번, 매년 4월에 내고 10월에 LTS로 올린다. 홀수/짝수로 나누던 구분도 사라져, 앞으로는 모든 메이저가 LTS가 된다. 처음 출시부터 지원 종료까지 36개월을 보장한다. 정리하면, 입문자는 고민할 것 없이 사이트가 추천하는 LTS를 받으면 된다.

설치 자체는 어렵지 않다. 내려받은 파일을 실행하고, 사용권에 동의한 뒤 다음 버튼만 누르면 끝난다. 특별히 건드릴 설정은 없다.

Node.js 설치 마법사 진행 단계

설치가 잘 됐는지 확인하기

설치가 끝났으면 터미널을 열고 버전을 찍어본다. 윈도우라면 명령 프롬프트나 PowerShell, macOS·리눅스라면 터미널이다.

node -v

버전 숫자가 뜨면 성공이다.

NPM이란

NPM(Node Package Manager)은 자바스크립트 코드를 묶고 공유하는 도구다. 자바스크립트로 된 거의 모든 것을 패키지 단위로 관리한다. 따로 깔 필요도 없다. Node.js를 설치하면 NPM이 같이 들어온다.

성격은 이렇다.

자바스크립트를 위한 패키지 관리자이고, Node.js에서 도는 프로그램을 관리한다.
패키지는 누군가 올려둔 노드 모듈을 뜻한다. 하나의 패키지가 또 다른 패키지를 끌어다 쓸 수 있다.

Vue, React 같은 프레임워크를 쓰는 프론트엔드 프로젝트에서 NPM은 사실상 필수다. 수십, 수백 개의 외부 라이브러리를 버전까지 맞춰 관리해주기 때문이다. 다만 누구나 패키지를 올릴 수 있다 보니 그늘도 있다. 악성·스팸 패키지 문제는 NPM 생태계의 위기: 스팸 패키지의 급증과 그 영향에서 짚어둔 적이 있다. 설치 전에 패키지 이름과 다운로드 수, 관리 상태를 한 번 확인하는 습관이 안전하다.

NPM 사용 가이드

프로젝트 시작하기

새 프로젝트를 시작할 땐 초기화부터 한다.

npm init

이 명령을 실행하면 질문 몇 개에 답한 뒤 package.json 파일이 생긴다. 질문을 건너뛰고 기본값으로 빠르게 만들고 싶으면 npm init -y를 쓰면 된다. npm init과 npm create, npx가 어떻게 다른지는 자바스크립트 프로젝트 생성의 기본: npm, npx, npm create 이해하기에서 더 자세히 다룬다.

package.json은 프로젝트의 신분증이다. 구조는 다음과 같다.

{
  "name": "sample",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC"
}

여기서 scripts가 쓸모가 많다. 자주 쓰는 명령을 이름표를 붙여 등록해두는 곳이다. 위 파일에는 test 스크립트가 들어 있다. npm test를 치면 등록된 명령이 그대로 실행된다.

npm test

새 스크립트를 추가하고 싶으면 줄을 하나 더 넣는다.

"scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "msg": "echo \"Hello, World\""
},

이제 npm run msg로 실행할 수 있다. test, start처럼 약속된 이름은 run 없이도 돌지만, 직접 만든 이름은 npm run을 붙여야 한다.

버전과 명령어 확인하기

NPM 버전은 이렇게 본다.

npm -v

쓸 수 있는 명령이 궁금하면 npm만 치고 엔터를 누른다. 사용법과 전체 명령 목록이 한눈에 나온다.

npm

패키지 설치하기

패키지를 까는 방법은 두 가지다. 첫째, 이름을 직접 적는다.

npm install {package_name}

둘째, 이름 없이 npm install만 친다. 이러면 package.json에 적힌 의존성을 전부 깔아준다. 남이 만든 프로젝트를 받아 처음 돌릴 때 쓰는 방식이다.

npm install

이렇게 설치하면 현재 프로젝트 폴더 안에만 들어간다. 어느 프로젝트에서나 쓰고 싶은 도구라면 -g로 전역 설치한다.

npm install -g {package_name}

예전엔 --save 옵션을 붙여야 package.json의 dependencies에 기록됐다. npm 5부터는 그게 기본값이라 따로 안 붙여도 된다. 대신 어디에 기록할지를 옵션으로 정할 수 있다.

--save-prod: dependencies에 등록 (기본값)
--save-dev: devDependencies에 등록 (개발할 때만 쓰는 도구)
--save-optional: optionalDependencies에 등록
--no-save: 기록하지 않음

테스트 도구나 린터처럼 배포할 코드엔 안 들어가는 패키지는 --save-dev로 분리해두는 게 깔끔하다.

유의적 버전 읽는 법

dependencies를 들여다보면 버전 앞에 ^15.12.0이나 ~15.12.0 같은 기호가 붙어 있다. 이걸 유의적 버전(Semantic Versioning)이라고 한다. 자세한 규칙은 유의적 버전 공식 명세에 정리돼 있는데, 핵심만 보면 세 자리 숫자에 각각 의미가 있다.

주 버전: 기존과 호환되지 않게 바뀐 버전
부 버전: 호환을 유지하면서 기능이 추가된 버전
수 버전: 호환을 유지하면서 버그만 고친 버전

버전 앞 기호는 “어디까지 자동 업데이트를 허용할지”를 정한다. 물결표(~)는 틸드라고 부른다. 마지막 자리 범위 안에서만 올린다.

~0.0.1: >=0.0.1 <0.1.0
~0.1.1: >=0.1.1 <0.2.0
~0.1  : >=0.1.0 <0.2.0
~0    : >=0.0   <1.0

위로 꺾인 기호(^)는 캐럿이다. 주 버전이 바뀌지 않는 선까지 폭넓게 올린다. 1.x.x 안에서는 하위 호환이 보장된다고 보고 그 범위를 다 허용한다.

^1.0.2 : >=1.0.2 <2.0
^1.0   : >=1.0.0 <2.0
^1     : >=1.0.0 <2.0

단, 1.0.0 미만은 예외다. 정식 출시 전이라 API가 수시로 바뀌니, 이때는 캐럿도 틸드처럼 좁게 동작한다. 이 둘 말고도 >1.2.3, >=1.2.3, <1.2.3 같은 직접 지정도 가능하다. 특정 패키지의 전체 버전 목록은 이렇게 본다.

npm view {package_name} versions

패키지 삭제하기

깔았던 패키지를 지울 땐 uninstall을 쓴다.

npm uninstall {package_name}

이 명령은 package.json의 의존성 기록까지 함께 정리해준다. 설치 경로나 사설 저장소 설정을 더 세밀하게 다루고 싶다면 package.json의 패키지 설치 경로 설정하기와 .npmrc 파일의 용도와 설정 방법을 참고하면 된다.

.env로 환경변수 관리하기

프로젝트를 만들다 보면 DB 접속 정보나 API 키처럼 밖으로 새면 안 되는 값이 생긴다. 이걸 코드에 직접 박아두면 곤란하다. GitHub 같은 공개 저장소에 올리는 순간 그대로 노출되고, 값을 바꿀 때마다 코드를 고쳐 다시 배포해야 한다.

시스템 환경변수로 넣는 방법도 있긴 하다.

export 환경변수명="설정할 값"
set 환경변수명="설정할 값"

위는 리눅스·macOS, 아래는 윈도우 방식이다. 그런데 서버를 옮길 때마다 다시 세팅하는 건 번거롭다. 그래서 프로젝트 루트에 .env 파일을 두고 거기서 값을 관리하는 방식을 많이 쓴다.

CLIENT_ID=Y1234567890
CLIENT_SECRET=Y0987654321

값을 불러오는 고전적인 방법은 dotenv 패키지다.

npm install dotenv

require('dotenv').config();
console.log('CLIENT_ID=' + process.env.CLIENT_ID);
console.log('CLIENT_SECRET=' + process.env.CLIENT_SECRET);

여기서 2026년 시점의 변화를 하나 짚어두자. 요즘 Node.js(20.6 버전 이후)는 .env를 읽는 기능을 자체적으로 가지고 있다. 패키지를 따로 깔 필요 없이 실행할 때 플래그만 붙이면 된다.

node --env-file=.env index.js

물론 .env는 절대 저장소에 올리면 안 된다. .gitignore에 추가하는 걸 잊지 말자. 기존 프로젝트라면 dotenv를 그대로 써도 되고, 새로 시작하는 프로젝트라면 내장 --env-file로 의존성 하나를 줄이는 선택도 좋다.

정리

여기까지 따라왔다면, 자바스크립트를 브라우저 밖에서 돌릴 준비가 끝났다. 핵심만 다시 짚어보자. Node.js는 V8 엔진 위에서 도는 자바스크립트 런타임이고, 설치는 안정적인 LTS를 받는 게 정답이다. NPM은 npm init으로 시작해 package.json으로 의존성을 관리하며, 버전 기호와 환경변수 처리까지 알아두면 웬만한 프로젝트는 막힘 없이 굴러간다.

도구는 계속 바뀐다. 같은 역할을 하는 pnpm이나 yarn으로 넘어가는 팀도 많다. 모노레포 환경이 궁금하다면 효율적인 모노레포 구성을 위한 pnpm 사용 가이드로 넘어가도 좋다. 다만 어떤 도구를 쓰든 바닥에 깔린 원리는 같다. 그 원리를 한 번 제대로 잡아두면, 다음에 새 도구가 나와도 흔들리지 않는다. 오늘 node -v가 잘 찍혔다면, 그 첫 줄에서 이미 절반은 온 셈이다.

참고 자료

Node.js, "Node.js 공식 다운로드"
Node.js, "Node.js Releases"
Tom Preston-Werner, "유의적 버전 명세 (Semantic Versioning)"