최신 소식: Node.js v24과 npm의 진화
Node.js 개발 환경이 계속 진화하고 있습니다. 2026년 현재 Node.js의 최신 버전은 v24(Current)이며, 안정성을 중시하는 개발자라면 LTS(Long-Term Support) 버전을 선택할 수 있습니다. npm도 단순한 패키지 설치 도구를 넘어 워크스페이스 지원, CI/CD 최적화 등의 기능을 갖춘 완성된 패키지 관리 시스템으로 발전했습니다. 특히 개별 프로젝트를 관리하던 방식에서 모노레포 구조로 여러 프로젝트를 한 곳에서 관리하는 트렌드가 생기면서 npm의 워크스페이스 기능이 주목받고 있죠.
Node.js 설치, 어떤 버전을 선택할까?
많은 초보 개발자들이 처음 Node.js를 다운로드할 때 가장 먼저 마주치는 고민이 바로 이겁니다. LTS 버전을 설치할까, 아니면 최신 Current 버전을 설치할까? 저도 처음에는 무작정 최신 버전이 좋다고 생각했는데, 실제 프로젝트를 진행하다 보니 선택 기준이 명확해졌어요.
LTS 버전은 짝수 번호(18.x, 20.x, 22.x 등)로 부여됩니다. 이 버전들은 최소 18개월 이상 유지보수되므로 프로덕션 서버나 장기 유지 프로젝트에 최적입니다. 반면 Current 버전(홀수 버전)은 최신 기능을 먼저 경험할 수 있지만 업데이트가 자주 발생하고 API가 변경될 가능성이 높습니다. 개인 프로젝트나 빠른 프로토타이핑을 할 때는 Current 버전이 좋지만, 팀 프로젝트나 오래 유지해야 하는 프로젝트라면 LTS 버전을 추천합니다.
공식 웹사이트에서 직접 다운로드하기
가장 간단한 방법은 nodejs.org에 접속해서 설치 파일을 다운로드하는 것입니다. 윈도우 사용자라면 .msi 파일을, 맥 사용자라면 .pkg 파일을 다운로드하면 됩니다. 다운로드한 파일을 실행하면 설치 마법사가 나오는데, 대부분 기본값 설정으로 진행해도 문제없습니다. 설치가 완료된 후 터미널이나 커맨드 프롬프트에서 node -v와 npm -v 명령어를 입력하면 설치 여부와 버전을 확인할 수 있습니다.
제 경험상 이 방법은 처음 개발을 시작하는 사람에게 가장 무난합니다. 별도의 설정 없이도 바로 개발을 시작할 수 있거든요. 다만 여러 프로젝트를 동시에 진행하면서 각 프로젝트마다 다른 Node.js 버전이 필요한 경우는 나중에 버전 관리자를 설치하는 것이 좋습니다.
여러 버전을 관리하고 싶다면? NVM과 n
프로젝트가 많아지다 보면 어떤 프로젝트는 Node 18 버전이 필요하고, 어떤 프로젝트는 최신 버전이 필요한 상황이 생깁니다. 매번 설치하고 제거하는 것은 너무 번거롭죠. 이럴 때 사용하는 도구가 NVM(Node Version Manager)과 n입니다.
NVM은 기능이 많고 설정도 세세하게 할 수 있지만 초기 설정이 조금 복잡합니다. Mac과 Linux 사용자라면 한 줄의 스크립트로 설치할 수 있지만, Windows 사용자는 nvm-windows를 따로 설치해야 합니다. n은 더 간단하고 가벼워서 빠른 테스트에 적합합니다. 저 같은 경우 개발 초기에는 NVM의 복잡함이 부담스러워서 직접 설치와 제거를 반복했는데, 이제는 NVM을 사용하니 훨씬 편합니다.
NVM으로 설치하려면 먼저 nvm install latest를 입력하면 최신 버전이 설치되고, nvm list로 설치된 버전들을 확인할 수 있습니다. 특정 버전으로 전환하려면 nvm use 18.17.0 같은 식으로 입력하면 됩니다. 프로젝트별로 다른 버전을 사용해야 한다면 .nvmrc 파일을 프로젝트 루트에 만들고 원하는 버전 번호를 적어두면, 해당 디렉토리에 들어왔을 때 자동으로 버전이 전환됩니다.
npm 초기 설정: package.json 만들기
Node.js를 설치하면 npm도 함께 설치됩니다. npm으로 할 수 있는 일은 생각보다 훨씬 많습니다. 가장 기본적인 작업은 새로운 프로젝트를 시작하는 것인데, 이때 npm init 명령어를 사용합니다. 이 명령어를 입력하면 프로젝트 이름, 버전, 설명, 진입점, 테스트 명령어 등을 입력하는 과정이 진행됩니다. 모든 항목에 대해 기본값을 사용하고 싶다면 npm init -y를 입력하면 한 번에 package.json 파일이 생성됩니다.
package.json은 프로젝트의 메타정보와 의존성을 담는 파일입니다. 이 파일이 있으면 다른 개발자나 배포 서버에서 npm install만 입력하면 동일한 개발 환경을 구축할 수 있습니다. 저는 이 파일을 프로젝트의 ‘설계도’라고 생각합니다. 누가 이 프로젝트를 받아도 이 파일만 보면 어떤 패키지가 필요한지, 프로젝트가 어떻게 실행되는지 알 수 있거든요.
패키지 설치하기: npm install의 다양한 활용법
Node.js 개발에서 가장 자주 사용하는 명령어가 npm install입니다. npm install 또는 짧게 npm i라고 입력하면 package.json에 명시된 모든 패키지가 node_modules 디렉토리에 설치됩니다. 하지만 npm install의 사용법은 훨씬 다양합니다.
npm install react 또는 npm i react라고 입력하면 react 패키지만 설치되고 package.json에 자동으로 추가됩니다. 개발할 때만 필요한 패키지(예: webpack, babel 등)는 npm install –save-dev express 또는 npm i -D express 같이 입력합니다. 이렇게 설치하면 package.json의 devDependencies 항목에 추가되어 프로덕션 배포할 때 포함되지 않습니다. 패키지 크기를 줄이고 싶을 때 유용합니다.
저도 처음엔 모든 패키지를 그냥 설치했는데, 어느 날 프로덕션 배포 후 용량을 확인해보니 엄청 컸어요. 이후로는 webpack, jest, eslint 같은 개발 도구는 항상 -D 옵션으로 설치합니다. 이렇게 하면 나중에 CI/CD 파이프라인에서 npm ci 명령어를 사용할 때 더 빠르게 빌드됩니다.
package-lock.json이 중요한 이유
npm install을 실행하면 package.json 외에 package-lock.json이라는 파일도 생깁니다. 처음엔 이 파일이 무엇인지 모르고 무시했는데, 팀 프로젝트를 진행하면서 그 중요성을 깨달았습니다. package-lock.json은 설치된 모든 패키지의 정확한 버전과 의존성을 기록합니다.
예를 들어 package.json에 “react”: “^18.0.0″이라고 적혀있으면 npm install을 할 때마다 18.0.0 이상 19.0.0 미만의 최신 버전이 설치될 수 있습니다. 어떤 개발자가 18.5.0으로 설치하고, 다른 개발자가 18.3.0으로 설치한다면 코드는 같은데 환경이 다를 수 있다는 뜻입니다. 이런 “내 컴퓨터에서는 작동하는데 왜 서버에서는 안 되지?” 문제를 방지하기 위해 package-lock.json을 git 저장소에 올려야 합니다.
저는 과거에 이 파일을 .gitignore에 추가해서 관리했는데, 덕분에 팀원들 간에 버전 차이로 인한 버그가 여러 번 발생했습니다. 지금은 package-lock.json을 항상 git에 커밋합니다. 이 파일이 있으면 팀의 모든 개발자와 배포 서버가 동일한 패키지 버전으로 작업할 수 있거든요.
npm ci: CI/CD 파이프라인의 최적화 도구
npm install과 비슷하지만 다른 명령어가 npm ci입니다. ci는 “clean install”의 약자로, package-lock.json을 기반으로 정확하게 설치합니다. npm install은 package.json에서 버전을 먼저 읽고 이미 설치된 패키지가 있으면 그걸 활용하려고 시도합니다. 반면 npm ci는 항상 깨끗한 상태에서 package-lock.json 기준으로만 설치합니다.
배포 서버나 CI/CD 파이프라인에서는 항상 npm ci를 사용해야 합니다. npm install보다 2배 이상 빠르고, 더 안정적입니다. 저도 처음에는 npm install을 어디서나 사용했는데, 배포 속도를 개선하려고 npm ci로 바꾼 후 상당한 시간을 절약했습니다. 특히 대규모 프로젝트에서 차이가 눈에 띕니다.
패키지 업데이트하기: 안전하게 진행하는 방법
프로젝트를 운영하다 보면 패키지를 업데이트해야 하는 경우가 생깁니다. npm update를 입력하면 package.json에 정의된 범위 내에서 최신 버전으로 업데이트됩니다. npm outdated를 입력하면 어떤 패키지가 업데이트 가능한지 확인할 수 있습니다.
다만 주의해야 할 점이 있습니다. 패키지 업데이트는 생각보다 큰 변화를 가져올 수 있습니다. 특히 major 버전이 올라가면 API가 완전히 달라질 수 있으니까요. 저는 항상 먼저 로컬에서 업데이트하고 테스트를 충분히 한 후에 배포합니다. npm audit으로 보안 취약점도 확인하고, npm audit fix로 자동 수정할 수 있습니다.
npm 스크립트: 반복 작업 자동화하기
package.json의 scripts 섹션을 활용하면 자주 사용하는 명령어를 단축할 수 있습니다. 예를 들어 webpack을 사용한다면 “build”: “webpack –mode production”이라고 정의해두고 npm run build라고 입력하면 웹팩 명령어가 실행됩니다.
“start”, “test”, “dev” 같은 일반적인 스크립트는 npm run을 생략하고 npm start, npm test 같이 직접 실행할 수 있습니다. 저는 프로젝트별로 다양한 스크립트를 정의해둡니다. 개발할 때 사용하는 dev 스크립트, 테스트 스크립트, 빌드 스크립트, 배포 전 전처리 스크립트 등을 조합하면 개발 생산성이 크게 향상됩니다.
npm 워크스페이스: 모노레포 시대에 필수 기능
npm 7부터는 워크스페이스 기능을 지원합니다. 이 기능은 여러 개의 패키지를 하나의 저장소에서 관리할 수 있게 해줍니다. 모던 웹 개발에서는 프론트엔드, 백엔드, 공용 유틸리티 등을 별도의 폴더로 나누면서도 하나의 git 저장소로 관리하는 모노레포 구조를 많이 사용합니다.
루트 package.json에 “workspaces”: [“packages/api”, “packages/web”, “packages/utils”]라고 정의하면, npm install을 한 번만 실행해도 모든 패키지의 의존성이 설치됩니다. 특정 워크스페이스에만 패키지를 설치하려면 npm install -w packages/api express처럼 입력하면 됩니다. 저는 최근 진행하는 프로젝트마다 워크스페이스를 활용합니다. 관련 코드를 한 곳에서 관리할 수 있어서 유지보수가 훨씬 쉬워집니다.
npm 캐시 관리와 문제 해결
때로 npm install을 해도 패키지가 제대로 설치되지 않는 경우가 있습니다. 이럴 때는 npm cache clean –force로 캐시를 비우고 다시 시도해봅니다. node_modules 폴더가 손상된 경우도 있으니 rm -rf node_modules && npm install로 완전히 재설치하는 것도 도움이 됩니다.
npm ci를 사용할 때는 –prefer-offline –no-audit –progress=false 옵션을 추가하면 훨씬 빠르고 안정적입니다. 저는 배포 스크립트에 이 옵션들을 항상 포함합니다. 문제가 발생했을 때는 npm list 명령어로 설치된 패키지의 의존성 트리를 확인하고, npm audit으로 보안 문제를 점검합니다.
npm 설정 파일: .npmrc 활용하기
.npmrc 파일을 프로젝트 루트에 생성하면 npm의 동작을 세밀하게 조절할 수 있습니다. 예를 들어 private npm 레지스트리를 사용한다면 registry 주소를 지정할 수 있고, npm 인증 토큰도 여기에 저장할 수 있습니다. legacy-peer-deps=true 같은 옵션으로 버전 호환성 문제도 해결할 수 있습니다.
저는 팀 프로젝트마다 .npmrc 파일을 만들어서 팀의 표준 설정을 공유합니다. 이렇게 하면 누가 프로젝트를 받아도 동일한 npm 환경에서 작업할 수 있습니다.
마무리: Node.js와 npm 생태계의 미래
2026년 현재 Node.js와 npm은 단순한 서버 사이드 자바스크립트 런타임과 패키지 매니저를 넘어섰습니다. 워크스페이스, 향상된 성능, 보안 기능 등을 갖춘 완성도 높은 개발 플랫폼이 되었습니다. 처음 Node.js를 배우는 초보자도, 대규모 프로젝트를 관리하는 개발자도 그들의 필요에 맞는 도구를 찾을 수 있습니다.
제 경험상 Node.js를 잘 활용하려면 npm의 기본 개념을 충분히 이해하는 것이 중요합니다. package.json의 의미, package-lock.json의 역할, 워크스페이스의 활용 같은 기본을 탄탄히 하면 나중에 더 복잡한 프로젝트에서도 자신감 있게 대응할 수 있습니다. 지금 시작하는 프로젝트에서 이 글의 내용들을 차근차근 적용해보길 권장합니다. 처음에는 관행처럼 느껴질 수 있지만, 프로젝트가 커질수록 이런 습관들이 얼마나 중요한지 깨달을 것입니다.