# npm v12의 예정된 호환성 깨짐 변경
> Clean Markdown view of GeekNews topic #30365. Use the original source for factual precision when an external source URL is present.
## Metadata
- GeekNews HTML: [https://news.hada.io/topic?id=30365](https://news.hada.io/topic?id=30365)
- GeekNews Markdown: [https://news.hada.io/topic/30365.md](https://news.hada.io/topic/30365.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-06-11T01:40:10+09:00
- Updated: 2026-06-11T01:40:10+09:00
- Original source: [github.blog](https://github.blog/changelog/2026-06-09-upcoming-breaking-changes-for-npm-v12/)
- Points: 1
- Comments: 1
## Topic Body
- npm v12에서 `npm install`의 **보안 관련 기본값**이 자동 실행·해석에서 명시적 허용 방식으로 바뀌며, npm 11.16.0 이상에서 경고로 사전 확인 가능
- **`allowScripts` 기본값**이 꺼짐으로 바뀌어, 명시적으로 허용하지 않은 의존성의 `preinstall`, `install`, `postinstall` 스크립트와 암묵적 `node-gyp rebuild`, git·file·link 의존성의 `prepare` 스크립트 실행 차단
- `npm approve-scripts --allow-scripts-pending`로 차단될 패키지를 확인하고, `npm approve-scripts`와 `npm deny-scripts`로 허용·차단을 정한 뒤 생성된 allowlist를 `package.json`에 커밋해야 함
- **`--allow-git` 기본값**이 `none`으로 바뀌어, `--allow-git`로 명시적으로 허용하지 않은 직접·전이 Git 의존성 해석 중단
- Git 의존성의 `.npmrc`가 `--ignore-scripts` 사용 중에도 Git 실행 파일을 덮어쓸 수 있는 코드 실행 경로 차단
- **`--allow-remote` 기본값**이 `none`으로 바뀌어, `--allow-remote`로 명시적으로 허용하지 않은 https tarball 같은 원격 URL 의존성 해석 중단
- `--allow-file`과 `--allow-directory`의 기본값은 npm v12에서 변경 없음
- 준비 절차는 npm 11.16.0 이상으로 업그레이드한 뒤 일반 설치를 실행해 경고를 검토하고, 신뢰하는 패키지만 승인하며, 업그레이드 후 승인된 스크립트만 계속 실행되는 방식
- 관련 문서: [`npm approve-scripts`](https://docs.npmjs.com/cli/v11/commands/npm-approve-scripts), [`npm deny-scripts`](https://docs.npmjs.com/cli/v11/commands/npm-deny-scripts), [`allow-scripts` config](https://docs.npmjs.com/cli/v11/using-npm/config#allow-scripts)
## Comments
### Comment 59365
- Author: neo
- Created: 2026-06-11T01:40:11+09:00
- Points: 1
###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48467705)
- npm이 **GitHub에 인수**된 걸 어떻게 놓쳤는지 모르겠지만, 갑자기 많은 일이 이해되기 시작함
Node 생태계의 이렇게 중요한 부분이 들어갈 곳으로 이보다 더 나쁜 집은 잘 떠오르지 않음
- 2020년에 일어난 일로 보임
[https://github.blog/news-insights/company-news/npm-is-joinin...]()
- 인수 전에도 이미 꽤 terrible했음
- **서비스 악화와 통제**, 향후 수익 압박을 위한 전략적 포지셔닝처럼 보임
“포용, 확장, 말살”임
[https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...]()
- **postinstall 스크립트**는 오래전에 제거됐어야 했고, NPM 패키지의 암 같은 존재임
뭔가를 가져올 때 깊게 중첩된, 통제되지 않는 postinstall들이 무작위로 실행되는 게 너무 많음
누가 어느 시점에 이걸 좋은 생각이라고 봤는지 모르겠음
- post-install 스크립트 우려의 핵심을 잘 이해하지 못하겠음
보통은 패키지된 의존성 코드를 어차피 어느 시점엔 실행하고, 대개 설치 과정과 같은 권한으로 실행함
그러면 이런 설정 스크립트들은 좋든 나쁘든 진입점을 npm에서 `import`나 `require`가 일어나는 곳으로 옮기면 됨
전체 생태계가 **Deno 같은 샌드박스 환경**으로 옮겨가지 않는 한, 기껏해야 작은 걸림돌처럼 보임. 그게 계획일 수도 있겠지만
- 절대 그렇게 하면 안 되고, 쓸 만한 사례가 많음
당장 떠오르는 예로 [https://www.npmjs.com/package/patch-package]()가 있음
지금의 히스테리가 이런 식의 헛된 결정으로 이어지지 않길 바람
- 이 내용은 10년 전에 공개된 뒤로 NPM 내부에서 **수백 번은 논의**됐을 것 같음
Shai Halud 때문에 이제는 무시하기엔 너무 커졌음
- JavaScript의 역사는 사실상 **개발자식 사고방식**을 농축한 것 같아서 좋음
“곧 고칠게요”는 거의 항상 “젠장, 이제 고쳐야 하네”가 됨
- 좋음, 이제 다음은 **Python 차례**임
- 현재 LTS Node 버전들, 기억상 **22, 24, 26**이 이 보안 수정의 혜택을 받도록 번들 npm을 v12로 올릴 예정인지 궁금함
지금은 모두 npm v11을 포함하고 있음
- 과거에도 Node 중간 릴리스에서 **npm 메이저 버전 업그레이드**가 들어간 적 있음
v18.19.0[1]과 v20.10.0[2]에서 npm 9를 10으로 올렸음
[1]: [https://nodejs.org/en/blog/release/v18.19.0#npm-updated-to-v...]()
[2]: [https://nodejs.org/en/blog/release/v20.10.0]()
- 기본값 변경이라 **보안 태세 변화**로 볼 수는 있지만, 보안 수정 자체는 모두가 이미 적용 가능함
글에 나온 대로 적절한 기본값을 설정하면 끝임
이 변화의 가장 좋은 점은, 기본값이 바뀌면서 새 개발자들이 그냥 install을 실행했을 때 이런 설정이 켜져 있다고 가정하는 성가신 패키지들이 즉시 깨지는 걸 보게 된다는 것임
예를 들어 스크립트가 실행 가능하다고 기대하는 관행을 멈추게 만들 수 있음
- 글만 봐서는 명확하지 않지만, 스크립트 허용 목록이 전역 설정이 아니라 **패키지별 허용**을 지원하는 것 같음
특정 패키지에만 스크립트를 허용하는 조직 단위 규칙을 유지하기 쉬워질 듯함
이런 식으로 패키지 관리자 설정에서 안전하지 않은 기본값을 막는 데 쓸 수 있는 린터가 있는지 궁금함
- `grep`이면 되지 않나?
- 아직도 **Yarn을 쓸 이유**가 있는지 궁금함
Yarn도 공급망 공격을 막는 보호 장치를 구현했는지 모르겠음
지금까지는 pnpm만 알고 있었는데, npm도 따라온 건 좋음
- 당연히 있음
최신 Yarn 릴리스인 4.x는 지나칠 정도로 **결정적 동작**을 보장하고, 팀 전체에서 일관된 동작을 기대할 수 있음
기능 면에서는 작은 디테일들이 많고, 익숙해지면 합쳐져서 차이가 커짐
다음 메이저 릴리스도 더 나은 성능과, 그 성능 개선에 의존해서 지금까지 구현하지 못했던 기능들로 같은 방향을 계속 밀고 갈 예정임
참고로 Yarn의 리드 메인테이너임
- 초기부터 v3까지 Yarn을 쓰던 프로젝트에서 일했는데, **엄청 느리지만 동작은 함**
공급망 보호 기능도 있음
결국 참지 못하고 pnpm으로 옮겼고, CI와 로컬 개발 머신 모두에서 설치가 훨씬 빨라졌음
LLM의 도움을 받아 마이그레이션하는 데 하루 정도 걸렸음
- 차별점 중 하나는 선택 가능한 설치 전략으로, 패키지를 `node_modules`에 풀지 않고 **압축 아카이브에서 직접 실행**하는 방식임
[https://yarnpkg.com/features/pnp]()
Java에서 `.class` 파일 디렉터리 트리 대신 `.jar`를 쓰는 것과 꽤 비슷함
다만 약간 해키하고, 편집기와 도구 지원은 제각각임
작은 파일 수가 훨씬 적어서, 어쩔 수 없이 Windows에서 작업해야 한다면 특히 더 빠를 수 있음
아카이브를 git 저장소에 넣을 수도 있어서, 인터넷과 패키지 레지스트리에 대한 의존을 제거할 수 있음
- NPM이 뭘 하는지는 모르겠지만, Yarn은 NPM보다 **의존성 설치가 훨씬 빠름**
- 내 댓글에 반대표를 누르는 사람들은 질문에 답해줘도 됨
정말 답을 모름
- npm이 GitHub 소유인 줄 몰랐음
그럼 여러 가지가 설명됨
- NPM Is Joining GitHub - [https://news.ycombinator.com/item?id=22594549]() (2020년 3월 16일, 댓글 571개, 1829점) - [https://github.blog/news-insights/company-news/npm-is-joinin...]()
일부는 시간이 지나고 보니 흥미롭게 읽힘
최상단 댓글은 “Microsoft가 모든 걸 잘하는 건 아니지만 GitHub 인수는 솔직히 예상보다 훨씬 잘 흘러갔다. GitHub에 Microsoft 중심 정책을 강요하기보다 Microsoft가 제품 관점에서 GitHub의 것들을 더 많이 받아들였다. GitHub는 여전히 별도 회사처럼 운영된다”는 내용이었음
- NPM 회사는 2020년에 거의 망하기 직전이었음
벤처 투자를 받았지만 지속 가능한 사업 모델을 찾지 못했음
GitHub가 생태계를 살리려고 인수했고, 이 인수가 GitHub에 큰 이득을 준 것도 거의 없음
- 대부분은 이걸 알지만, 진짜로 많은 걸 설명해주는 이유는 **GitHub가 Microsoft 소유**라는 점임
그리고 Microsoft는 GitHub를 Azure로 옮겼음
- GitHub 소유인 건 알고 있었지만, npm 블로그가 아니라 **GitHub 블로그의 릴리스 노트**를 직접 본 건 이번이 처음임
- `package.json`의 허용 목록은 **패키지 버전까지 고정**하는 건지, 아니면 패키지 이름만 고정하는 건지 궁금함
- `allowScripts` 기본값이 꺼짐이라니 좋음
[시계 확인] **18개월** 만에 pnpm을 따라가는 셈인가?
- Java의 Maven에는 그런 게 없었고, 필요하다고 느낀 적도 없음
JavaScript 쪽에서는 이게 무슨 목적임?