빠른 답변

AI 코딩 어시스턴트(AI coding assistant)가 npm 패키지를 제안할 때, 생성된 코드가 그럴듯해 보인다는 이유만으로 설치를 승인하지 마세요. 패키지 설치를 권한이 부여된 작업(privileged operation)으로 취급해야 합니다.

npm install을 실행하기 전에 다음 다섯 가지를 확인하세요:

1. 패키지 이름이 올바른 생태계(ecosystem)에 존재하는가.
2. 유지 관리자(maintainer), 저장소(repository), 릴리스 기록(release history), 그리고 목적이 예상과 일치하는가.
3. 패키지가 의외의 설치 스크립트(install scripts), 바이너리(binaries), 또는 관련 없는 의존성(dependencies)을 숨기고 있지 않은가.
4. 출처(Provenance), 레지스트리 서명(registry signatures), 취약점 데이터(vulnerability data), 그리고 악성코드 경고(malware alerts)에서 명백한 위험 신호가 나타나지 않는가.
5. 해당 기능이 추가되는 의존성 표면(dependency surface)의 가치가 있는가.

인디 앱(indie app)의 경우, 실질적인 기본 원칙은 간단합니다. AI가 제안한 의존성은 자동으로 설치되지 않습니다. 에이전트(agent)가 패키지를 제안할 수는 있지만, 반드시 사람이나 스크립트가 먼저 이를 검증해야 합니다.

대상 독자

이 가이드는 Codex, Claude Code, Cursor, Copilot 또는 기타 AI 코딩 에이전트(AI coding agents)를 사용하여 개발하는 1인 창업자 및 소규모 팀을 위한 것입니다. 특히 에이전트가 다음과 같이 말할 때 유용합니다:

작은 패키지를 설치하여 이 문제를 해결할 수 있습니다:
npm install 

그 제안이 괜찮을 수도 있습니다. 하지만 그 제안은 오래되었거나, 불필요하거나, 환각(hallucinated)되었거나, 타이포스쿼팅(typosquatted)되었거나, 슬롭스쿼팅(slopsquatted)되었거나, 방치되었거나, 혹은 악의적일 수도 있습니다. 핵심은 npm을 두려워하라는 것이 아닙니다. 텍스트 제안이 실행 가능한 제3자 코드(third-party code)로 변할 때 속도를 늦추라는 것입니다.

무엇이 변했고 왜 지금인가

AI 코딩 도구는 의존성 결정 방식을 바꾸어 놓았습니다. 기존의 개발자는 패키지를 검색하고, README를 읽고, 저장소를 확인한 다음 설치를 진행했습니다. 하지만 에이전트 워크플로우(agent workflow)에서는 모델이 의존성을 선택하고, import 문을 작성하고, 코드를 수정하고, 설치 명령어를 실행한 뒤 계속 진행할 수 있습니다.

이러한 압축(compression)은 취약점을 만듭니다. 패키지 환각(package hallucinations)에 관한 연구에 따르면, 코딩 모델은 존재하지 않는 패키지 이름을 추천할 수 있습니다. 가짜 이름이 예측 가능해지면, 공격자가 이를 등록하고 개발자나 에이전트가 설치하기를 기다릴 수 있습니다. 이를 흔히 슬롭스쿼팅(slopsquatting)이라고 부릅니다.

npm 생태계 또한 더욱 명확한 공급망 (supply-chain) 검사 기능을 추가하고 있습니다. npm은 패키지 출처 (provenance) 및 npm audit signatures를 문서화합니다. GitHub은 2026년에 npm 의존성에 대한 Dependabot 악성코드 경고 기능을 추가했습니다. OSV-Scanner와 OpenSSF Scorecard는 알려진 취약점 및 리포지토리 (repository) 상태에 대한 실질적인 검사를 제공합니다. 그 어떤 것도 판단력을 완전히 대체할 수는 없지만, 이들을 함께 사용하면 "AI가 설치하라고 했다"는 말을 검토 가능한 결정으로 바꿀 수 있습니다.

15분 패키지 도입 워크플로우 (package intake workflow)

1. 패키지가 왜 필요한지 질문하기

에이전트가 의존성 (dependency)의 필요성을 정당화하도록 하는 것부터 시작하세요:

설치하기 전에, 문제 상황, 대안, 패키지 식별 정보,
설치 스크립트 (install scripts) 또는 바이너리 (binaries),
변경되는 파일, 그리고 다음 명령어를 설명하세요.
아직 설치하지 마세요.

만약 답변이 모호하다면 설치를 거부하세요. 사소한 기능 하나마다 또 다른 제3자 패키지를 추가하게 되면 작은 앱일수록 배포하기가 더 어려워집니다.

2. 패키지 식별 정보 검증하기

설치 전에 npm 메타데이터 (metadata)를 사용하세요:

npm view <name> version description repository homepage bugs license
npm view <name> maintainers time dist-tags
npm view <name> scripts dependencies optionalDependencies peerDependencies bin

누락되었거나 관련 없는 리포지토리, 일치하지 않는 유지 관리자 (maintainers), 성숙함을 주장하지만 매우 최신인 패키지, 실제 패키지의 편리한 변형처럼 보이는 이름, 그리고 작업 규모에 비해 너무 큰 scripts, bin, 또는 의존성들을 살펴보세요. 다운로드 횟수는 신뢰 신호가 아닙니다. 패키지의 정체성이 상식적으로 납득이 가야 합니다.

3. 실행하지 않고 타르볼 (tarball) 검사하기

설치하기 전에 npm이 가져올 내용을 검사하세요:

npm pack <name>@latest --dry-run
npm pack <name>@latest
tar -tf <name>-*.tgz | sed -n '1,8p'

아주 작은 유틸리티라면, 패키지에 예상치 못한 바이너리, 자격 증명 (credential)처럼 보이는 파일, 거대한 벤더드 (vendored) 폴더, 또는 postinstall 작업이 과도한 스캐폴딩 (scaffolding)이 포함되어서는 안 됩니다. 만약 설치 스크립트가 있다면, 로컬에서 실행될 수 있다고 가정하세요.

더 안전한 첫 설치가 필요할 때는 다음을 사용하세요:

npm install <name> --ignore-scripts

그것이 악성 패키지를 안전하게 만든다는 의미는 아니지만, 첫 검토 시 라이프사이클 스크립트가 실행되는 것을 방지합니다.

4. 서명(signatures), 출처(provenance), 알려진 위험 여부 확인하기

일회용 브랜치나 샌드박스에 설치한 후 다음 명령을 실행하세요:

npm audit signatures
osv-scanner scan -r .

npm audit signatures는 레지스트리 서명과 사용 가능한 출처 증명(provenance attestations)을 확인합니다. OSV-Scanner는 의존성 데이터를 OSV 취약점 기록과 비교하여 검사합니다. 공개 GitHub 저장소의 경우, OpenSSF Scorecard는 보안 정책, 의존성 업데이트, CI, 브랜치 보호 및 빌드 관행 전반에 걸쳐 유지 관리자의 상태 신호(maintainer-health signal)를 추가합니다.

패키지가 귀하의 GitHub 저장소에 들어오게 되면 Dependabot 알림과 npm 악성코드 알림을 활성화하세요. 이렇게 하면 나중에 경고가 나타날 때 후속적인 가시성을 확보할 수 있습니다.

5. 의존성 예산(dependency budget)으로 결정하기

간단한 규칙을 사용하세요:

설치해야 하는 경우:
- 실제 문제를 해결하는 경우;
- 신원, 저장소, tarball, 스크립트 및 검사가 허용되는 경우;
...

개인 프로젝트의 경우, 설치 중에 코드를 실행하는 또 다른 의존성을 추가하는 것보다

npm audit만으로 충분할까요?

아니요. npm audit 및 OSV 스타일의 스캔은 알려진 문제(known issues)를 찾아냅니다. 하지만 패키지 이름이 실제인지, 필요한 것인지, 잘 유지 관리되고 있는지, 또는 위험한 설치 동작(install behavior)으로부터 안전한지는 증명하지 못합니다.

AGENTS.md에 무엇을 작성해야 하나요?

다음 내용을 추가하세요: "이유, 패키지 정체성, 스크립트 위험성 및 대안을 설명하지 않고는 새로운 npm 패키지를 설치하지 마십시오. 작은 작업의 경우 기존 의존성(dependencies)이나 네이티브 API (native APIs)를 우선적으로 사용하십시오." 만약 저장소(repo)에서 이미 공유된 에이전트 규칙을 사용 중이라면, 이를 더 광범위한 AGENTS.md 설정 가이드와 결합하여 사용하십시오.

출처

• npm: 패키지 출처 확인하기 (Viewing package provenance): https://docs.npmjs.com/viewing-package-provenance/
• GitHub Changelog: Dependabot이 이제 npm 의존성 내의 멀웨어(malware)를 감지합니다: https://github.blog/changelog/2026-03-17-dependabot-now-detects-malware-in-npm-dependencies/
• OSV-Scanner 문서: https://google.github.io/osv-scanner/
• OpenSSF Scorecard: https://scorecard.dev/
• USENIX: 패키지 환각(Package hallucinations) 및 소프트웨어 공급망 위험: https://www.usenix.org/publications/loginonline/we-have-package-you-comprehensive-analysis-package-hallucinations-code