AI 보안 · 2026년 7월 9일 · 약 7분

npm v12 보안 설정 사용법, install 스크립트 차단 전에 프로젝트를 점검하는 방법

npm v12가 latest로 올라오면서 설치 시 자동 실행되던 스크립트와 Git·원격 URL 의존성이 기본 차단으로 바뀌었다. 기존 JavaScript 프로젝트에서 무엇을 확인하고, 어떤 허용 목록을 남겨야 하는지 정리했다.

• npm v12
• npm 보안 설정
• allowScripts
• JavaScript 공급망 보안
• trusted publishing

출처: GitHub Changelog

GitHub가 2026년 7월 8일 npm v12를 latest로 공개했습니다. 이번 버전의 핵심은 새 기능보다 보안 기본값입니다. 지금까지 npm install 때 자동으로 실행되던 dependency lifecycle script, Git 의존성, 원격 URL 의존성이 기본 차단되고, 필요한 항목만 명시적으로 허용하는 방식으로 바뀝니다.

AI 개발 도구를 많이 쓰는 팀일수록 이 변화는 더 현실적입니다. Copilot, Codex, Claude Code 같은 도구가 패키지를 추가하거나 테스트 환경을 고칠 때 npm install을 자주 실행하기 때문입니다. 보안 기본값이 바뀌면 악성 install script 위험은 줄지만, 네이티브 모듈 빌드나 오래된 의존성 설치가 갑자기 멈출 수 있습니다. 배포 직전에 알기보다 지금 작은 브랜치에서 확인하는 편이 낫습니다.

핵심 키워드

• npm v12 보안 설정
• npm allowScripts
• npm install 스크립트 차단
• JavaScript 공급망 보안
• npm trusted publishing

무엇이 바뀌었나

GitHub Changelog에 따르면 npm v12에서는 세 가지 install-time 동작이 기본 opt-in으로 바뀝니다. 패키지 설치 과정에서 자동 실행되는 스크립트는 허용 목록에 없으면 실행되지 않고, Git 저장소나 원격 tarball에서 직접 가져오는 의존성도 기본으로 풀리지 않습니다. npm 11.16.0 이상에서는 미리 경고를 볼 수 있었고, v12에서는 이 기본값이 실제 적용됩니다.

왜 개발자가 바로 봐야 하나

JavaScript 공급망 공격은 설치 순간을 자주 노립니다. 사용자가 직접 코드를 실행하지 않아도 postinstall 같은 스크립트가 실행되면 토큰 탈취, 추가 파일 다운로드, 환경 정보 유출로 이어질 수 있습니다. npm v12의 방향은 “설치하면 자동 실행”이 아니라 “검토한 것만 실행”입니다.

영향을 받을 가능성이 큰 프로젝트

• node-gyp처럼 설치 중 네이티브 빌드가 필요한 패키지를 쓰는 프로젝트
• package.json이나 lockfile에 Git URL 의존성이 남아 있는 프로젝트
• 사내 tarball, CDN URL, 임시 registry 링크로 패키지를 가져오는 프로젝트
• CI에서 오래된 npm publish 토큰이나 2FA-bypass granular access token을 쓰는 패키지
• AI 코딩 도구가 의존성 추가와 설치 명령을 자주 실행하는 저장소

먼저 해야 할 점검 순서

바로 npm v12로 올리기보다, 별도 브랜치에서 설치 로그를 확인하고 허용 목록을 작게 만드는 순서가 좋습니다. 목표는 모든 스크립트를 다시 켜는 것이 아니라, 실제로 필요한 패키지와 이유를 남기는 것입니다.

실무 점검 체크리스트

• 로컬과 CI의 Node.js, npm 버전을 기록한다.
• npm 11.16.0 이상 또는 npm v12에서 npm install을 실행해 막히는 항목을 확인한다.
• npm approve-scripts --allow-scripts-pending으로 필요한 설치 스크립트만 검토한다.
• 생성된 allowlist가 package.json에 반영되면 코드 리뷰를 거쳐 커밋한다.
• Git URL과 원격 URL 의존성은 registry 패키지나 사내 registry로 옮길 수 있는지 먼저 본다.
• publish 자동화는 긴 수명의 토큰보다 trusted publishing 또는 staged publishing으로 옮길 계획을 잡는다.

AI 코딩 도구에 맡길 때 쓰는 요청

AI 코딩 도구에게 “npm v12 대응해줘”라고만 말하면, 막히는 패키지를 모두 허용하거나 버전을 크게 올리는 식으로 움직일 수 있습니다. 처음 요청은 읽기와 분석 중심으로 제한하세요.

복사해서 쓰는 점검 프롬프트

• 이 저장소가 npm v12 보안 기본값에서 막힐 수 있는 지점을 찾아줘. 아직 파일은 수정하지 마.
• package.json, package-lock.json, CI workflow에서 install script, Git URL 의존성, 원격 URL 의존성, publish 토큰 사용을 표로 정리해줘.
• 각 항목마다 “허용 필요”, “registry 패키지로 교체 가능”, “사람 검토 필요” 중 하나로 분류해줘.
• npm approve-scripts로 허용해야 할 후보가 있으면 패키지명, 실행되는 스크립트, 허용 이유를 따로 적어줘.
• 자동 게시가 있으면 trusted publishing 또는 staged publishing으로 옮기는 최소 변경 계획만 제안해줘.

무엇을 바꿔 넣어야 하나

위 프롬프트를 쓸 때는 저장소 상황을 구체적으로 넣어야 합니다. 특히 CI 이름, 배포 대상, 사내 registry 여부, 네이티브 모듈 사용 여부를 알려주면 결과가 훨씬 쓸모 있어집니다.

흔한 실수와 고치는 법

업그레이드 때 막히는 지점

• 설치가 실패한다고 모든 스크립트를 다시 켜지 않는다. 필요한 패키지 이름과 이유를 남긴다.
• Git URL 의존성은 임시 해결책으로 남기지 말고 버전이 고정된 registry 패키지로 옮길 수 있는지 검토한다.
• 원격 tarball URL은 출처, 해시, 배포 주체가 추적되는지 확인한다.
• CI publish 토큰은 저장소 secret에 오래 보관하지 말고 OIDC 기반 trusted publishing 전환을 우선 검토한다.
• AI 도구가 만든 수정은 lockfile diff와 CI 로그를 사람이 다시 읽는다.

이번 npm v12 변화는 귀찮은 마이그레이션처럼 보일 수 있지만, 실제로는 프로젝트의 설치 경로를 한 번 정리할 기회입니다. 오늘 바로 할 일은 큽니다. 작은 브랜치에서 npm v12 설치를 시험하고, 어떤 패키지가 설치 중 코드를 실행하려 하는지 목록으로 남겨보세요.