---
title: "npm 공급망 사고를 두고 ‘막을 방법이 없었다’고 말하는, 유독 자주 터지는 패키지 매니저"
published: 2026-05-16T00:36:02.000Z
canonical: https://jeff.news/article/2794
---
# npm 공급망 사고를 두고 ‘막을 방법이 없었다’고 말하는, 유독 자주 터지는 패키지 매니저

npm 생태계의 공급망 공격을 풍자한 글이다. 수십 단계로 중첩된 의존성, 방치된 패키지 탈취, 기본 설치 스크립트 실행 같은 구조적 위험을 ‘어쩔 수 없는 자연재해’처럼 말하는 태도를 비꼰다.

- 이 글은 npm 공급망 공격을 다룬 ‘진지한 보도’가 아니라, 자바스크립트 생태계의 익숙한 보안 리스크를 대놓고 비꼬는 풍자임
  - 설정은 샌프란시스코에서 npm 레지스트리 공급망 공격이 터져 수백만 개 기업 앱이 손상되고, 수십억 사용자 기록이 노출됐다는 식으로 잡혀 있음
  - 핵심 농담은 “이건 막을 방법이 전혀 없었다”는 반응이, 유독 npm 쪽에서만 너무 자주 나온다는 데 있음

- 풍자의 첫 타깃은 ‘40단계짜리 중첩 의존성 트리’에 기대는 현대 웹 개발 방식임
  - 글에서는 문자열 하나를 대문자로 바꾸기 위해, 검증되지 않은 익명 메인터너들이 관리하는 패키지 묶음에 의존하는 상황을 꼬집음
  - 오래 방치된 유틸 패키지를 누군가 탈취하고, 거기에 크립토마이너를 심어 전 세계 프로덕션 빌드에 퍼뜨리는 시나리오가 등장함
  - 말투는 “자연재해 같은 일이라 예측도 예방도 불가능했다”인데, 당연히 진짜 주장은 그 반대임

> [!WARNING]
> 농담처럼 쓰였지만, 의존성 탈취와 설치 스크립트 악용은 실제 CI/CD 환경에서 클라우드 키, 토큰, 내부 레지스트리 접근 권한까지 건드릴 수 있는 문제임.

- 두 번째 타깃은 사고가 터질 때마다 나오는 ‘생각과 기도’식 보안 대응임
  - 글에서는 Node.js 생태계 사람들이 DevOps 팀이 회사 AWS 키를 급히 교체하는 와중에도, 이번 원격 코드 실행이 완전히 예측 불가능한 비극이었다고 말하는 장면을 넣음
  - 여기서 웃긴 포인트는 사고 대응의 무게와 원인 분석의 가벼움이 너무 대비된다는 것임
  - 키 로테이션, 빌드 정리, 배포 중단 같은 진짜 비용은 조직이 치르는데, 생태계 차원의 책임은 흐릿해지는 구조를 찌름

- 비교 대상으로 Go, Rust, 네이티브 웹 API 생태계가 등장함
  - 글은 이쪽 생태계가 더 튼튼한 표준 라이브러리를 갖고 있어서 사소한 기능마다 서드파티 패키지를 끌어오는 압박이 상대적으로 적다고 말함
  - 또 핵심 툴체인에 암호학적 검증이 더 강하게 들어가 있다는 점도 대비됨
  - 표현은 과격함. “대학생 중퇴자의 주말 프로젝트가 글로벌 물류 인프라를 날려버린 사례가 오늘은 없었다”는 식으로 npm식 미세 패키지 의존을 후려침

- npm 쪽 대변인 역할의 문장도 제대로 비꼼이 들어감
  - “나쁜 행위자가 있는 세상에 산다는 걸 받아들여야 한다”는 식으로 말하면서도, 배경에는 로컬 머신에서 임의 설치 스크립트를 기본 실행하는 오픈소스 레지스트리가 서 있음
  - “막을 수 있는 레지스트리 정책이나 빌드 샌드박스 가드레일은 없었다”는 말도, 사실은 그런 정책과 가드레일을 더 강하게 고민해야 한다는 반어임
  - 마지막에는 “내일 아침 다음 침해 사고가 오기 전까지 회복력을 유지하자”는 식으로 끝나는데, 반복 사고를 정상화하는 태도에 대한 조롱에 가까움

- 한국 개발자 입장에서도 남 얘기가 아님
  - 프론트엔드, Node.js 백엔드, 서버리스, 내부 어드민, 디자인 시스템 빌드까지 npm이 안 들어가는 곳을 찾기가 더 어려움
  - 특히 CI에서 `npm install`이나 `npm ci`가 토큰을 가진 상태로 도는 조직이라면, 패키지 설치 단계는 이미 보안 경계 안쪽임
  - ‘작은 패키지니까 괜찮겠지’가 아니라, 작은 패키지가 빌드 그래프의 깊은 곳에서 전사 배포 파이프라인을 만질 수 있다는 게 핵심임

---

## 기술 맥락

- npm 생태계의 문제는 패키지를 많이 쓴다는 사실 자체보다, 설치와 빌드 과정에서 외부 코드가 너무 쉽게 실행된다는 데 있어요. 개발자는 라이브러리를 가져온다고 생각하지만, CI 입장에서는 신뢰 경계 밖의 코드를 실행하는 일이 되거든요.

- Go나 Rust와의 비교가 나오는 이유도 여기에 있어요. 표준 라이브러리가 더 넓고 툴체인 검증이 강하면, 사소한 기능마다 외부 패키지를 덜 끌어오게 되고 공격 표면도 줄어들어요.

- 방치된 패키지 탈취가 무서운 건 유명 패키지만 조심해서 해결되지 않기 때문이에요. 직접 설치한 패키지의 하위 의존성 어딘가에서 메인터너 계정이 넘어가거나 소유권이 바뀌면, 앱 팀은 그 변화를 바로 알아채기 어렵거든요.

- 그래서 실무에서는 잠금 파일 관리, 설치 스크립트 제한, 패키지 출처 검증, CI 권한 최소화 같은 조치가 같이 가야 해요. 풍자 글이지만, 결론은 꽤 현실적이에요.

## 핵심 포인트

- npm 생태계는 작은 유틸 패키지 하나에도 깊은 의존성 트리가 얽히는 구조라 공급망 공격 표면이 크다
- 방치된 패키지 탈취, 악성 설치 스크립트, 원격 코드 실행, 클라우드 키 교체 같은 실제 보안 리스크가 풍자의 핵심이다
- Go, Rust, 네이티브 웹 API처럼 표준 라이브러리와 검증 체계가 강한 생태계와 대비하면서 npm의 구조적 취약성을 찌른다

## 인사이트

웃긴 척하지만 꽤 아픈 얘기다. ‘현대 웹 개발의 비용’이라는 말로 넘기기엔, 의존성 실행 권한과 레지스트리 신뢰 모델은 이미 운영 보안의 일부가 됐다.