npm v12가 7월에 출시 – 개발자들이 지금 해야 할 일
Source: DevOps.com
수년간 npm install을 실행한다는 것은 끌어온 코드가 스스로 잘 동작할 것이라고 믿는 것이었습니다. 그 믿음은 종종 잘못된 것이었습니다. 2026년 7월부터 npm v12가 규칙을 바꿉니다. 설치 스크립트가 자동으로 실행되지 않으며, Git 저장소나 원격 URL에서 의존성을 가져오지도 않습니다. 모든 것이 선택적으로 동작하도록 바뀝니다.
이는 지난 1년 동안 JavaScript 생태계를 강타한 공급망 공격 물결에 대한 직접적인 대응입니다. 2025년 9월, 공격자는 debug, chalk 등 18개의 인기 npm 패키지를 탈취했으며, 이 라이브러리들은 거의 모든 Node.js 프로젝트에 포함되어 있습니다. 주당 26억 건이 넘는 다운로드를 기록한 이 사건은 역사상 가장 큰 npm 공격 중 하나였습니다. 2025년 한 해만 해도 공격자는 약 455,000개의 악성 npm 패키지를 배포했습니다. 공격은 아직도 멈추지 않았으며, 2026년 3월 Axios 침해 사건에서는 가장 많이 다운로드된 npm 패키지 중 하나가 자격 증명 탈취를 통해 무기로 전환되었습니다.
생태계는 단순히 스캔 도구를 개선하는 수준을 넘어서는 구조적인 해결책이 필요했습니다. npm v12가 바로 그 해결책입니다.
What’s Actually Changing
npm v12는 npm install에 세 가지 보안 관련 변화를 도입합니다. 첫째, allowScripts 기본값이 off로 바뀝니다—프로젝트에서 명시적으로 허용하지 않는 한, 의존성의 preinstall, install, postinstall 스크립트가 실행되지 않습니다. 여기에는 네이티브 node-gyp 빌드도 포함됩니다. 둘째, --allow-git 기본값이 none으로 바뀝니다—명시적으로 허용하지 않는 한, 직접 혹은 전이적인 Git 의존성이 해결되지 않습니다. 셋째, --allow-remote 기본값이 none으로 바뀝니다—명시적으로 허용하지 않는 한, HTTPS tarball 같은 원격 URL에서 의존성을 가져오지 않습니다.
이것은 단순한 설정 조정이 아니라, 수년간 방어자들이 지적해 온 공격 경로를 차단하는 것입니다. 특히 Git 의존성 변경은 중요합니다. Git 의존성의 .npmrc가 Git 실행 파일을 재정의할 수 있는 코드 실행 경로를 차단함으로써, --ignore-scripts 플래그만으로는 보호된다고 생각했던 상황을 무력화합니다. 그 플래그는 많은 팀에게 잘못된 안도감을 주었습니다.
Why This Matters Beyond the Security Team
대부분의 개발자는 공급망 보안을 남의 문제라고 생각합니다. 하지만 상황은 빠르게 변하고 있습니다. 2026년 5월 말, Microsoft Threat Intelligence는 조직 스코프 아래에 실제 내부 네임스페이스를 모방한 악성 npm 패키지를 이용한 활발한 공급망 공격을 발견했습니다. 이 패키지들은 명백히 의심스러운 것이 아니었으며, 내부 도구처럼 보였습니다.
평균 npm 프로젝트는 몇 개가 아닌 79개의 전이적 의존성을 끌어옵니다. 그 중 하나라도 악성 설치 스크립트를 포함할 수 있습니다. 현재 기본 동작에서는 npm install을 실행하는 순간 스크립트가 바로 실행됩니다. v12에서는 개발자가 명시적으로 허용하지 않는 한 실행되지 않습니다.
The Futurum Group의 소프트웨어 라이프사이클 엔지니어링 및 AI‑네이티브 소프트웨어 엔지니어링 부문 부사장 겸 실무 책임자인 Mitch Ashley는 이번 변화가 생태계 신뢰 모델의 근본적인 재고임을 강조합니다.
“패키지 설치가 암묵적인 신뢰에서 명시적인 허용 리스트로 전환되고 있습니다. 자동 스크립트 실행, Git 해석, 원격 fetch를 기본적으로 비활성화하는 것은 악성 패키지를 배포 후에 탐지하는 방식으로는 급증하는 위협을 따라잡을 수 없다는 현실을 인정하는 것입니다. 이제 엔지니어링 및 플랫폼 팀이 소스 컨트롤에 커밋된 의존성 허용 리스트를 관리하고, CI는 검토되지 않은 설치 스크립트가 있으면 빌드를 실패시키게 됩니다. 설치 시 실행되는 코드를 검증하는 것이 보안팀의 사후 작업이 아니라 엔지니어링 팀의 일상적인 의무가 됩니다.”
How to Prepare Before July
좋은 소식은 v12가 출시될 때까지 기다릴 필요가 없다는 점입니다. 세 가지 변화 모두 npm 11.16.0 이상에서 경고 형태로 제공되므로, 업그레이드 전에 미리 준비할 수 있습니다.
추천 워크플로는 다음과 같습니다.
- npm 11.16.0 이상으로 업그레이드 — 이 버전부터는 advisory mode가 활성화되어 경고는 표시되지만 아직 빌드가 깨지지는 않습니다.
npm approve-scripts --allow-scripts-pending을 실행해 정책에 아직 포함되지 않은 스크립트를 가진 패키지를 확인합니다.- 검토한 버전에 고정하고 신뢰하는 패키지를 승인한 뒤, 업데이트된
package.json을 소스 컨트롤에 커밋합니다.
먼저 읽기 전용 모드(npm approve-scripts --allow-scripts-pending --dry-run 등)로 실행하면, 어떤 패키지의 스크립트가 아직 커버되지 않았는지 전체 목록을 확인할 수 있어, 승인 작업을 시작하기 전에 전체 상황을 파악할 수 있습니다.
피해야 할 점: 경고를 없애기 위해 모든 패키지를 일괄 플래그로 승인하지 마세요. 이는 목적에 반하는 행동입니다. 핵심은 어떤 패키지가 내 머신에서 코드를 실행하는지 알고, 각각에 대해 신중히 결정하는 것입니다.
내부 HTTPS tarball이나 Git 브랜치에 고정된 모노레포를 사용하는 팀이라면, 올바른 해결책은 --allow-remote 플래그를 CI 스크립트마다 추가하는 것이 아니라 GitHub Packages, Nexus, Artifactory와 같은 정식 레지스트리로 마이그레이션하는 것입니다.
Package Maintainers Have Work to Do Too
설치 스크립트를 사용하는 패키지를 유지보수한다면, v12에서는 기본적으로 다운스트림 사용자가 해당 스크립트를 받지 못합니다. 두 가지 조치를 취하세요:
README에 npmapprove-scripts링크를 추가해 사용자가 어떻게 스크립트를 승인할 수 있는지 문서화합니다.prebuild,prebuildify,node-pre-gyp같은 도구를 활용해 사전 빌드된 바이너리를 제공하거나, 설치 후 사용자가 직접 실행하는 명시적 커맨드로 설정 과정을 옮겨 스크립트 의존성을 최소화합니다.
이는 단순히 예의가 아니라 필수적인 조치입니다. 패키지가 v12로 업그레이드된 후 조용히 동작을 멈추고 이유를 모른다면, 이는 지원 문제이자 신뢰 문제로 이어집니다.
The Bigger Picture
npm v12는 소프트웨어 공급망 전반에 걸친 큰 변화를 반영합니다. npm install을 “안전하고 일상적인 작업”으로 여기던 암묵적 신뢰 시대는 끝났습니다. 명시적 허용 리스트, 버전 고정, 지속적인 리뷰가 기본이 되고 있습니다.
2025·2026년에 발생한 Shai‑Hulud 웜, Glassworm, 그리고 연속적인 공급망 공격들은 패키지 설치에 대한 암묵적 신뢰가 더 이상 통하지 않음을 증명했습니다. npm v12가 모든 문제를 해결하진 않지만, 공격자들이 수년간 이용해 온 쉬운 경로를 차단합니다.
7월은 머지않았습니다. npm approve-scripts --allow-scripts-pending을 실행할 시점은 바로 지금입니다.
