npm이란? Node.js 패키지 설치·관리 방법을 초보자도 쉽게 이해하기

“AI 개발 도구 설치 방법을 보고 있는데, 왜 자꾸 ‘npm install’을 입력하라고 할까요?”

Node.js를 처음 설치했거나, REA처럼 개발 환경이 필요한 AI 도구를 사용하려고 하면 npm이라는 이름을 만나게 됩니다.

낯선 영어 약자라서 어려워 보이지만, 실제로는 프로그램 개발에 필요한 부품을 찾고 설치하고 관리하도록 도와주는 도구라고 생각하면 쉽습니다.

npm은 자바스크립트 개발에 사용하는 패키지와 그 의존 관계를 관리하는 도구이자, 패키지를 공유하는 서비스·저장소를 포함한 생태계입니다.

좀 더 정확히 말하면 npm 공식 문서는 npm을 웹사이트, 명령줄 도구(CLI), 패키지 저장소(Registry)라는 세 구성요소로 소개합니다.

따라서 npm은 단순히 하나의 설치 명령어만을 뜻하지 않습니다.

이번 글에서는 npm이 필요한 이유, 어떤 파일이 만들어지는지, 설치 전에 확인할 사항과 실무에서 자주 보는 오류까지 초보자 눈높이로 설명하겠습니다.

자체 제작 개념도.

이 글의 순서

• 1. npm은 ‘프로그램 부품 창고와 관리 담당자’에 가깝습니다
• 2. npm은 웹사이트인가요, 프로그램인가요?
• 3. npm과 Node.js는 무엇이 다른가요?
• 4. npm install은 어떤 일을 하나요?
• 5. package.json은 무엇을 기록하는 파일인가요?
• 6. package-lock.json과 node_modules는 왜 생기나요?
• 7. npm ci는 npm install과 어떻게 다른가요?
• 8. npm run은 무엇을 하는 명령인가요?
• 9. npm에 저장된 패키지는 모두 안전할까요?
• 10. npm audit를 실행하면 보안 문제가 모두 해결되나요?
• 11. REA 같은 AI 개발 도구에는 npm이 왜 필요할까요?
• 12. npm 명령이 작동하지 않을 때 먼저 확인할 것은?
• 13. AI에게 npm 사용법을 물어볼 때는 이렇게 요청해 보세요
• 자주 묻는 질문
• 마무리: npm은 개발에 필요한 부품을 체계적으로 관리하는 도구입니다

1. npm은 ‘프로그램 부품 창고와 관리 담당자’에 가깝습니다

책상을 직접 만든다고 생각해 보겠습니다.

나무판과 나사, 경첩처럼 필요한 모든 부품을 처음부터 직접 제작할 수도 있겠지만 실제로는 이미 만들어진 부품을 구매해 사용하겠죠.

소프트웨어도 비슷합니다.

웹사이트를 만들다 보면 날짜를 처리하거나, 데이터를 정리하거나, 특정 기능을 구현하기 위해 다른 개발자가 만들어 둔 코드를 활용하고 싶을 수 있습니다.

이때 재사용 가능한 프로그램 코드를 일정한 형식으로 묶어 배포한 것을 보통 패키지(Package)라고 부릅니다.

npm은 그런 패키지를 찾고 내려받아 설치하며 프로젝트에서 어떤 버전을 사용하는지 관리하는 데 활용됩니다.

이 비유를 나누면 다음과 같습니다.

• 패키지: 미리 만들어 둔 프로그램 부품
• npm 저장소(Registry): 여러 패키지가 등록된 창고
• npm 명령줄 도구: 원하는 부품을 설치하고 관리하는 담당자
• 프로젝트: 이런 부품을 활용해 만드는 실제 소프트웨어 여기서 꼭 기억할 것이 있습니다.

npm으로 내려받은 패키지는 누군가 작성한 코드이며, 단순한 이미지나 문서가 아닐 수 있습니다. 출처가 불분명하면 보안상 위험할 수 있으므로 무작정 설치하면 안 됩니다.

2. npm은 웹사이트인가요, 프로그램인가요?

npm 공식 문서는 세 가지로 구성된다고 설명합니다.

npm의 구성	쉽게 설명하면	어떤 일을 하나요?
웹사이트	패키지를 찾아보는 안내 공간	패키지 정보·제작자·설명 확인
명령줄 도구	설치·관리 명령을 실행하는 프로그램	패키지 설치·업데이트·검사
레지스트리(저장소)	패키지와 관련 정보가 등록된 곳	필요한 패키지 파일 제공

그래서 “npm에서 패키지를 찾았다”와 “npm 명령어를 실행했다”는 문장은 서로 다른 상황을 뜻합니다.

예를 들어 어떤 개발 도구를 소개하는 글에서 패키지 이름을 확인했다면, 아직 여러분의 컴퓨터에 설치된 것은 아닙니다.

패키지가 npm 저장소에 등록돼 있다는 것과 내 프로젝트에 실제 설치돼 있다는 것도 별개입니다.

또 하나, npm에 공개돼 있는 모든 패키지가 npm 운영사의 공식 제작품인 것은 아닙니다. 여러 개발자와 조직이 패키지를 공개할 수 있습니다. 따라서 패키지 이름이 유명한 제품과 비슷하다는 이유만으로 제공자를 신뢰하면 안 됩니다.

3. npm과 Node.js는 무엇이 다른가요?

이 둘은 자주 함께 설치되지만 역할이 다릅니다.

Node.js는 자바스크립트로 작성한 프로그램을 실행할 수 있게 하는 실행 환경입니다.

npm은 프로젝트에서 사용할 패키지를 찾아 설치하고 버전과 의존 관계를 관리하는 패키지 관리 도구입니다.

한 줄로 구분하면 다음과 같습니다.

Node.js는 프로그램을 실행하는 기반이고, npm은 그 프로그램에 필요한 부품을 관리하는 도구입니다.

Node.js의 일반적인 배포판에는 npm 명령줄 도구가 함께 제공되는 경우가 많습니다.

그래서 Node.js를 설치한 뒤 다음처럼 입력해 npm이 있는지 확인할 수 있습니다.

npm --version

이 명령은 설치된 npm 명령줄 도구의 버전을 확인하는 예시입니다.

다음 명령과는 서로 확인하는 대상이 다릅니다.

node --version

이 명령은 Node.js 실행 환경의 버전을 확인합니다.

둘 다 버전 번호가 표시될 수 있지만 같은 번호여야 하는 것은 아닙니다.

또한 npm만 있으면 웹사이트가 자동으로 만들어진다거나 Node.js가 실행 중이라는 뜻도 아닙니다. 실제 프로젝트의 설치·실행·검증은 별도의 작업입니다.

4. npm install은 어떤 일을 하나요?

설치 안내에서 다음과 같은 명령을 보았다고 가정해 보겠습니다.

npm install

이 명령을 Node.js 프로젝트의 올바른 폴더에서 실행하면 npm은 프로젝트에 기록된 필요한 패키지를 설치하려고 합니다.

패키지 이름을 지정해 다음처럼 실행할 수도 있습니다.

npm install lodash

이것은 lodash라는 이름의 패키지를 현재 프로젝트에 추가 설치하도록 요청하는 예시입니다. 설명을 위해 알려진 공개 패키지 이름을 사용했지만, 실제 설치하거나 사용할 필요는 없습니다.

이 명령을 읽는 방법은 간단합니다.

• npm: 패키지 관리 프로그램
• install: 설치 작업
• lodash: 설치 대상으로 지정한 패키지 이름 하지만 주의할 점이 있습니다. npm install은 단순히 목록을 보여 주는 읽기 전용 명령이 아닙니다.

프로젝트의 파일을 만들거나 수정할 수 있고, 외부 패키지 저장소에 접속해 필요한 파일을 다운로드할 수 있습니다. 패키지와 npm 버전·설정에 따라 설치 과정에서 프로그램의 스크립트가 실행될 수도 있습니다.

따라서 무슨 패키지를 설치하는지, 어떤 프로젝트 폴더인지, 패키지 제공자가 신뢰할 만한지 확인한 다음 실행해야 합니다.

명령어를 입력했다고 설치가 성공한 것으로 단정하지 마세요. 실제 출력이나 실행 결과를 확인해야 합니다.

5. package.json은 무엇을 기록하는 파일인가요?

npm을 사용하는 프로젝트를 살펴보면 package.json이라는 파일이 있는 경우가 많습니다.

이 파일은 프로젝트가 사용하는 패키지와 기본 설정 등을 기록하는 문서라고 생각하면 됩니다.

예를 들어 다음은 이해를 돕기 위한 간단한 가상 파일입니다.

{
  "name": "my-first-project",
  "version": "1.0.0",
  "private": true,
  "scripts": {
    "check": "node hello.js"
  },
  "dependencies": {
    "lodash": "^4.17.21"
  }
}

이 내용을 조금씩 살펴보겠습니다.

name은 프로젝트 또는 패키지의 이름입니다.

version은 해당 프로젝트에서 표시하는 버전입니다.

private: true는 실수로 이 프로젝트를 npm 저장소에 공개 게시하는 일을 방지하는 설정에 활용됩니다.

scripts는 개발자가 자주 실행하는 명령을 이름으로 등록하는 부분입니다.

dependencies는 프로젝트에 필요한 외부 패키지 목록과 허용 버전 범위를 기록하는 부분입니다.

여기 있는 ^4.17.21처럼 버전 앞에 붙은 기호는 패키지의 허용 업데이트 범위를 지정하는 방법 가운데 하나입니다. 이것이 모든 버전으로 마음대로 업데이트해도 된다는 뜻은 아닙니다.

package.json은 현재 프로젝트가 필요로 하는 구성 정보를 기록하지만, 그 파일에 이름이 있다는 것만으로 패키지가 이미 설치됐다는 의미는 아닙니다.

패키지 설치와 프로젝트 실행은 다시 별도로 확인해야 합니다.

6. package-lock.json과 node_modules는 왜 생기나요?

초보자가 npm을 사용하면서 처음 당황하는 부분이 있습니다.

프로젝트 폴더에 처음에는 없던 파일과 폴더가 생기기 때문입니다.

대표적인 예가 다음 두 가지입니다.

package-lock.json

프로젝트가 어떤 버전의 패키지를 실제로 설치 대상으로 결정했는지 등 자세한 의존 관계를 기록하는 파일입니다.

node_modules

일반적인 로컬 설치에서 실제 패키지 코드가 저장되는 폴더입니다.

이것을 아파트 건축에 비유해 볼 수 있습니다.

package.json은 필요한 부품의 종류와 허용 기준을 적은 목록입니다.

package-lock.json은 실제로 선택한 정확한 부품과 연결 관계를 기록한 내역에 가깝습니다.

node_modules는 현장에서 사용하려고 받아 놓은 실제 부품들에 가깝습니다.

항목	주요 역할	초보자가 기억할 점
package.json	프로젝트 설정·필요한 패키지 선언	어떤 패키지가 필요한지
package-lock.json	실제 해결된 버전·의존 관계 기록	같은 구성 재설치에 도움
node_modules	설치한 패키지 파일 보관	실제 코드가 들어 있는 폴더

물론 npm 설정과 프로젝트 구조에 따라 실제 파일이 만들어지는 방식은 다를 수 있습니다.

특히 package-lock.json을 단순한 임시 파일이라고 생각해 무조건 삭제해서는 안 됩니다. 프로젝트 구성의 재현 가능성에 중요한 역할을 하기 때문입니다.

반대로 node_modules 안의 파일을 하나씩 직접 수정하면 다음 설치 때 변경 내용이 사라질 수 있으므로 주의해야 합니다.

7. npm ci는 npm install과 어떻게 다른가요?

개발 프로젝트의 설치 안내에서 가끔 다음 명령도 보게 됩니다.

npm ci

이 명령은 특히 자동 테스트나 배포 환경에서 정해진 패키지 구성을 다시 설치할 때 사용합니다.

차이점을 간단하게 비교해 보겠습니다.

구분	npm install	npm ci
대표 목적	패키지를 추가·관리하거나 필요한 패키지 설치	기존 기록에 맞춰 프로젝트 패키지를 새로 설치
잠금 파일	필요하면 업데이트될 수 있음	기존 잠금 파일과 설정이 일치해야 함
새 패키지 하나만 추가	가능	일반적인 용도 아님
기존 node_modules	설치 조건에 따라 처리	설치 전에 제거하고 다시 설치

npm 공식 문서는 npm ci에 대해 package-lock.json 같은 기존 잠금 파일이 필요하며, 선언된 패키지와 잠금 파일 내용이 맞지 않으면 오류를 내고 중단한다고 설명합니다.

무엇보다 중요한 안전 사항이 있습니다.

npm ci는 설치를 시작하기 전에 현재 프로젝트의 기존 node_modules 폴더를 제거합니다.

따라서 다른 사람의 명령을 보고 무작정 실행하지 말고, 현재 프로젝트와 대상 경로가 맞는지 확인하세요.

또한 npm ci가 패키지 구성을 재현하는 데 도움이 된다고 해도 그 패키지들이 반드시 안전하거나 결함이 없다는 보장은 아닙니다.

처음 npm을 배운다면 npm install의 역할을 이해한 다음, 팀 프로젝트에서 npm ci를 사용하는 이유를 구분하는 정도면 충분합니다.

8. npm run은 무엇을 하는 명령인가요?

npm은 패키지를 설치하는 일뿐 아니라 프로젝트에 등록된 작업을 실행하는 데도 사용됩니다.

예를 들어 프로젝트의 package.json에 다음 내용이 있다고 가정해 보겠습니다.

{
  "private": true,
  "scripts": {
    "hello": "node hello.js"
  }
}

이 파일에서 scripts는 개발자가 특정 작업에 붙여 둔 이름과 실행할 명령을 기록하는 부분입니다.

그 프로젝트 폴더에서 다음처럼 실행할 수 있습니다.

npm run hello

이 요청의 뜻은 다음과 같습니다.

npm아, 이 프로젝트에 등록된 hello라는 작업을 실행해 줘. 위 예시는 hello.js 파일이 실제로 있는 상황을 가정한 것입니다. 파일이 없거나 Node.js 실행에 문제가 있으면 실패할 수 있습니다.

중요한 점은 npm run이 임의의 새 기능을 알아서 만들어 주는 것이 아니라, 프로젝트에 정의된 명령을 실행한다는 것입니다.

실제 프로젝트에는 build, dev, test 같은 이름의 작업이 등록돼 있을 수 있습니다. 하지만 같은 이름이라고 모든 프로젝트에서 같은 내용으로 동작하는 것은 아닙니다.

어떤 스크립트는 파일을 빌드하거나 수정할 수 있고, 다른 스크립트는 외부 서비스를 호출할 수도 있습니다.

따라서 실행 전에 package.json의 scripts 내용을 확인하는 것이 좋습니다.

9. npm에 저장된 패키지는 모두 안전할까요?

아닙니다.

npm은 매우 큰 패키지 생태계이지만, 등록된 패키지가 모두 안전하거나 품질 검증을 통과했다는 뜻은 아닙니다.

일부 패키지에는 알려진 보안 취약점이 있을 수 있고, 악의적인 패키지가 유명한 프로그램과 비슷한 이름으로 등록될 위험도 있습니다.

또한 직접 설치한 패키지가 다시 다른 패키지에 의존할 수 있습니다.

예를 들어 A라는 패키지를 설치하려고 했는데 A가 B와 C를 필요로 한다면 npm은 그에 필요한 패키지까지 설치할 수 있습니다.

그래서 사용자는 패키지 하나를 선택해도 그 뒤에 연결된 여러 코드의 영향을 받을 수 있습니다.

초보자라면 다음을 먼저 확인해 보세요.

정확한 패키지 이름: 공식 문서의 철자와 일치하는지 확인합니다.

제작자와 출처: 실제 프로젝트에서 안내하는 제공자와 저장소가 맞는지 살펴봅니다.

지원 상태: 오랫동안 관리되지 않았거나 의심스러운 패키지인지 확인합니다.

요구 권한: 파일 읽기·네트워크 통신·시스템 설정 변경 등이 필요한 이유를 살펴봅니다.

실행 스크립트: 패키지 설치나 실행 과정에서 무엇이 자동으로 수행되는지 확인합니다.

2026년 10월 16일에 확인한 npm 12.2.0 공식 문서는 프로젝트 의존성의 설치 스크립트가 package.json의 allowScripts 항목에서 승인됐을 때 실행된다고 설명합니다. 승인되지 않은 스크립트는 기본적으로 실행되지 않고 검토 목록에 표시되며, strict-allow-scripts를 켜면 설치 오류로 처리됩니다. 일회성 실행이나 전역 설치는 설정 방식이 다르므로 현재 사용하는 npm 버전과 프로젝트 설정을 함께 확인해야 합니다.

따라서 “npm으로 설치하면 언제나 안전하다”거나 “패키지를 설치하기만 하면 아무 코드도 실행되지 않는다”는 주장은 모두 주의해야 합니다.

10. npm audit를 실행하면 보안 문제가 모두 해결되나요?

npm에는 다음과 같은 보안 점검 명령이 있습니다.

npm audit

이 명령은 프로젝트의 의존 관계에 대해 알려진 취약점 정보를 검사하는 데 활용됩니다.

검사 결과를 읽으면 어떤 의존 패키지에서 알려진 문제가 보고됐는지, 수정 가능한 버전이 있는지 등을 살펴볼 수 있습니다.

하지만 중요한 한계가 있습니다.

npm audit 결과가 문제가 없다고 나오더라도 그 프로젝트의 모든 코드가 안전하다는 뜻은 아닙니다.

아직 알려지지 않은 취약점이나 패키지 자체의 악의적인 동작은 별도 조사와 검증이 필요할 수 있습니다.

또한 npm audit는 프로젝트의 의존 정보를 레지스트리에 보내 검사할 수 있으므로, 조직의 보안·네트워크 정책을 확인해야 할 수 있습니다.

공식 문서에는 문제 수정 요청에 쓰는 npm audit fix 명령도 있습니다.

그러나 npm audit fix는 단순한 읽기 전용 검사 명령이 아닙니다. 실제 패키지 구성을 변경할 수 있으며 내부적으로 설치 작업을 수행할 수 있습니다.

처음 사용하는 사람이 오류를 없애려는 목적으로 npm audit fix나 강제 옵션을 무작정 실행하는 것은 권장하지 않습니다.

먼저 보고서를 읽고 어떤 변경이 필요한지 확인하는 것이 중요합니다.

11. REA 같은 AI 개발 도구에는 npm이 왜 필요할까요?

REA를 비롯한 일부 AI 개발 도구의 설치 안내에는 Node.js와 npm이 등장합니다.

여기서 두 프로그램의 역할을 분리해 보면 이해하기 쉽습니다.

Node.js: 자바스크립트 기반 프로그램이 실행되는 환경

npm: 그 프로그램에 필요한 패키지와 의존 관계를 설치·관리하는 도구

예를 들어 REA 공식 설치 안내가 특정 패키지의 명령을 실행하도록 지시할 수 있습니다.

이때 npm 생태계는 필요한 패키지를 받아서 사용할 수 있게 하는 역할을 담당합니다.

하지만 npm이 설치됐다고 REA 자체가 설치·설정됐거나 분석 도구와 연결됐다는 뜻은 아닙니다.

프로젝트에서 사용할 프로그램을 설치하는 단계, 각 서비스의 접근 권한을 설정하는 단계, 실제 분석 기능을 실행하고 결과를 검사하는 단계는 모두 구분해야 합니다.

REA 원고에 등장하는 npx는 npm과 관련이 있지만 하나의 별도 개념입니다. npm이 패키지 관리 도구라면, npx는 패키지에 포함된 명령을 실행할 때 쓰는 방식이라는 점만 기억해 두면 됩니다.

npx의 자세한 구조와 사용법은 별도 설명글에서 다룰 예정입니다.

설치 문서를 따라갈 때는 Node.js 지원 버전, npm 사용 가능 여부, 대상 패키지의 정확한 이름, 설치 중 변경되는 설정을 확인하세요.

이 글은 npm의 원리를 설명하며, 특정 REA 프로그램의 실제 설치·연동 테스트 결과를 제시하는 글은 아닙니다.

12. npm 명령이 작동하지 않을 때 먼저 확인할 것은?

처음 npm을 사용하다 보면 비슷한 오류를 만날 수 있습니다. 오류 메시지는 문제를 좁히는 단서이지, 그 자체로 원인을 확정해 주는 답은 아닙니다.

'npm 명령을 찾을 수 없습니다'

npm 명령줄 도구가 설치되지 않았거나, 명령줄 프로그램이 npm의 실행 경로를 인식하지 못할 수 있습니다.

확인: Node.js 설치 방법과 함께 npm이 제공됐는지, 현재 사용하는 셸이 어떤 실행 파일을 찾는지 확인합니다.

패키지 이름을 찾을 수 없습니다

패키지 이름이 잘못됐거나 지정한 버전을 사용할 수 없거나, 저장소 접근 문제가 있을 수 있습니다.

확인: 공식 프로젝트 문서의 패키지 이름·버전, 사용 중인 npm 저장소 주소, 인터넷 연결과 인증 상태를 확인합니다.

접근 권한 관련 오류가 발생합니다

설치할 폴더나 파일에 대한 권한이 부족할 수 있습니다.

확인: 정확히 어떤 경로에서 문제가 생겼는지 살피고, 이유 없이 관리자 권한을 높여 실행하지 않습니다.

의존 관계 충돌이 발생합니다

여러 패키지가 서로 다른 버전 요구사항을 갖고 있어 설치 구성을 맞추지 못할 수 있습니다.

확인: 오류의 패키지 이름과 요구 버전을 확인하고, 프로젝트의 공식 설치 지침과 기존 잠금 파일을 살펴봅니다. 무조건 강제 설치 옵션을 사용하는 것은 좋은 출발점이 아닙니다.

npm ci가 잠금 파일 오류로 중단됩니다

package.json과 package-lock.json의 내용이 서로 맞지 않을 수 있습니다.

확인: 팀에서 관리하는 공식 프로젝트 변경사항과 잠금 파일의 동기화 상태를 검토합니다. 파일을 무작정 삭제하거나 강제로 맞추기 전에 왜 달라졌는지 확인하세요.

13. AI에게 npm 사용법을 물어볼 때는 이렇게 요청해 보세요

AI 코딩 도구를 처음 사용하는 사람이라면 설치부터 맡기기보다 먼저 설명과 변경 영향 분석을 요청하는 것이 좋습니다.

npm을 처음 사용하는 비전공자야.

내 운영체제는 [Windows 또는 macOS]이고, 작업하려는 프로젝트는 [프로젝트 이름]이야.

먼저 npm이 어떤 역할을 하는지 짧게 설명해 줘.

프로젝트의 공식 설치 문서와 package.json, package-lock.json을 실제로 읽을 수 있다면 확인해 줘.

사용할 명령어가 어떤 패키지를 설치하고 어떤 파일을 변경하는지, 외부 코드를 실행할 수 있는지 설명해 줘.

읽기 전용으로 확인할 수 있는 정보부터 제안하고, 설치·업데이트·삭제는 내가 승인하기 전까지 실행하지 마.

설치를 수행하게 된다면 실제 실행한 명령·결과·변경 파일·실패 또는 미검증 항목을 구분해서 알려 줘. 이 요청은 AI가 무조건 모든 명령을 안전하게 처리해 준다는 보증이 아닙니다.

하지만 어떤 부분을 조사했고 어떤 부분에 실제 변경이 발생했는지 확인하는 데 도움이 됩니다.

자주 묻는 질문

Q. npm은 프로그래밍 언어인가요?

아닙니다. npm은 자바스크립트 프로젝트의 패키지를 설치·관리하는 도구와 관련 저장소·서비스를 포함하는 생태계입니다. 새로운 프로그래밍 언어가 아닙니다.

Q. npm과 Node.js는 같은 프로그램인가요?

서로 밀접하게 연결돼 있지만 역할이 다릅니다. Node.js는 자바스크립트 실행 환경이고, npm은 패키지 관리 도구입니다.

Q. npm을 설치하면 AI 모델도 설치되나요?

그렇지 않습니다. npm으로 특정 패키지를 설치할 수는 있지만 npm 자체가 AI 모델은 아닙니다. 어떤 프로그램을 설치하게 되는지는 실제 패키지와 명령에 달려 있습니다.

Q. npm install은 언제나 안전한가요?

아닙니다. 외부 코드 다운로드·파일 변경·설치 스크립트 실행 등이 가능할 수 있습니다. 신뢰할 수 있는 출처와 명령의 효과를 확인해야 합니다.

Q. package.json을 삭제해도 되나요?

무조건 삭제하면 안 됩니다. 프로젝트의 설정과 의존 패키지 목록이 들어 있을 수 있어 정상 설치·실행이 어려워질 수 있습니다.

Q. package-lock.json도 반드시 보관해야 하나요?

일반적인 npm 프로젝트에서는 패키지 버전과 의존 관계를 일관되게 재현하는 데 중요한 역할을 합니다. 팀의 프로젝트 관리 원칙을 확인하고 임의 삭제하지 않는 편이 좋습니다.

Q. npm install과 npm ci 중 무엇을 사용해야 하나요?

목적에 따라 다릅니다. 설치·패키지 추가·의존 관계 조정에는 npm install을, 잠금 파일에 맞춰 깨끗한 설치가 필요한 자동화나 팀 작업에는 npm ci를 사용할 수 있습니다. 단 npm ci는 기존 node_modules를 제거하므로 먼저 확인해야 합니다.

Q. npm 패키지는 모두 무료인가요?

npm에는 공개 패키지가 많지만, 개별 패키지의 라이선스와 서비스 이용 조건, 유료 API·비공개 패키지 비용 등이 다를 수 있습니다. npm이 있다는 이유만으로 모든 서비스가 무료인 것은 아닙니다.

Q. npm audit에 문제가 없으면 프로그램도 안전한가요?

그렇게 단정할 수 없습니다. 알려진 취약점을 검사하는 데 도움이 되지만 모든 위험이나 아직 발견되지 않은 문제를 보증하지는 않습니다.

Q. npm은 인터넷 없이도 사용할 수 있나요?

어떤 기능은 로컬에 있는 파일이나 이미 보관된 자료만으로 사용할 수 있습니다. 하지만 저장소에서 새로운 패키지를 내려받는 작업은 일반적으로 해당 저장소에 접근할 수 있어야 합니다.

마무리: npm은 개발에 필요한 부품을 체계적으로 관리하는 도구입니다

npm은 자바스크립트 개발에 필요한 패키지를 찾고 설치하며, 프로젝트가 어떤 패키지에 의존하는지 관리하도록 돕는 도구와 생태계입니다.

프로그램의 실행 환경인 Node.js와 함께 자주 등장하지만 같은 뜻은 아닙니다.

처음에는 npm 명령을 전부 외울 필요가 없습니다.

첫째, npm은 패키지와 의존 관계를 관리하는 도구입니다.

둘째, npm install은 실제 파일과 설치 상태를 바꿀 수 있는 명령입니다.

셋째, 설치 전에 출처·현재 프로젝트·권한·예상 변경을 확인하는 것이 중요합니다.

이 세 가지를 이해하면 REA 같은 AI 개발 도구의 설치 문서를 볼 때도 “왜 이 명령을 입력해야 하는지”를 훨씬 명확하게 판단할 수 있습니다.

함께 읽으면 좋은 글

• REA란? GitHub에서 화제인 AI 리버스 엔지니어링 도구, 코딩 몰라도 쓸 수 있을까? — AI 개발 도구의 설치 안내에서 npm이 맡는 역할을 확인합니다.
• 코드란 무엇일까? HTML·CSS·JavaScript와 AI 코딩 쉽게 이해하기 — 패키지에 포함될 수 있는 프로그램 코드의 기본 개념을 알아봅니다.