npm 패키지 해킹 사건으로 보는 오픈소스 공급망 보안: 스타트업 개발팀이 당장 해야 할 것

2026년 3월 31일, 주간 다운로드 수 1억 건을 넘는 npm 패키지 Axios에 악성코드가 심어진 사건이 발생했어요. 수백만 개의 프로젝트가 영향을 받을 수 있는 대형 사건이었는데, 이 사건은 단순한 해킹 뉴스가 아니라 스타트업 개발팀이 반드시 알아야 할 구조적 문제를 드러내고 있어요. 오픈소스 공급망 보안이란 무엇이고, 우리 팀은 지금 당장 뭘 해야 할까요?

오픈소스 공급망 공격(Supply Chain Attack)이란 무엇인가?

오픈소스 공급망 공격은 우리가 신뢰하는 외부 라이브러리나 패키지를 통해 악성코드가 배포되는 방식이에요. 마치 슈퍼마켓에서 믿고 사는 제품의 공장에서 오염이 일어난 것처럼, 개발자가 쓰는 라이브러리 자체가 해킹당하는 거죠.

2026년 3월 한 달에만 이런 사건이 5건 이상 발생했어요:

• 3월 19일: 보안 스캐너 Trivy의 설정 파일을 통한 공격
• 3월 31일: Axios npm 패키지에 크로스플랫폼 RAT(원격 접근 트로이목마) 삽입
• 기타 3건의 소규모 패키지 오염 사건

특히 Axios는 거의 모든 JavaScript·TypeScript 프로젝트에서 HTTP 요청에 사용하는 패키지예요. 여러분의 프로젝트 node_modules에도 분명히 들어있을 확률이 높아요.

왜 스타트업이 특히 위험한가?

대기업은 보안팀이 따로 있고, 소프트웨어 구성 요소 분석(SCA) 도구를 상시 운영해요. 하지만 스타트업은 그런 여력이 없죠. 그래서 오픈소스 의존성이 많을수록, 보안 점검 인력이 부족할수록 취약합니다.

일반적인 스타트업 프로젝트의 node_modules 폴더에는 직접 설치한 패키지 50~100개 외에도, 그 패키지들이 의존하는 패키지까지 합치면 1,000개 이상의 패키지가 있어요. 이 모두를 수동으로 관리하는 건 현실적으로 불가능합니다.

지금 당장 할 수 있는 5가지 기본 보안 조치

1. npm audit를 정기적으로 실행하세요

npm에 내장된 취약점 검사 도구예요. 완벽하진 않지만 기본 중에 기본입니다.

• npm audit — 취약점 목록 확인
• npm audit fix — 자동 수정 가능한 것은 자동 수정
• CI/CD 파이프라인에 포함시켜 PR마다 자동 실행하도록 설정

2. package-lock.json을 절대 .gitignore에 넣지 마세요

lock 파일은 정확히 어떤 버전의 패키지를 설치할지 고정해줘요. 이게 없으면 같은 package.json이라도 설치할 때마다 다른 버전이 들어올 수 있고, 악성 업데이트가 몰래 들어올 수 있습니다.

3. Dependabot 또는 Renovate Bot을 설정하세요

GitHub Dependabot은 무료로 사용할 수 있어요. 의존성 업데이트가 필요할 때 자동으로 PR을 만들어주고, 알려진 취약점이 발견되면 즉시 알림을 보내줍니다. 설정은 5분이면 됩니다.

4. SBOM(소프트웨어 구성 요소 목록)을 생성해두세요

SBOM은 프로젝트에 들어있는 모든 소프트웨어 컴포넌트 목록이에요. 공격이 발생했을 때 "우리 프로젝트에 영향받는 패키지가 있나?"를 즉시 확인할 수 있어요. cyclonedx-npm 같은 도구로 쉽게 생성할 수 있어요.

5. npm 패키지 설치 시 출처 확인 습관을 들이세요

비슷한 이름의 가짜 패키지(타이포스쿼팅)가 엄청나게 많아요. axios인지 axois인지 구분하기 어렵죠. npm에서 패키지를 새로 설치할 때는 다운로드 수, 마지막 업데이트 날짜, GitHub 저장소 링크를 반드시 확인하세요.

조금 더 나아간다면: 고급 보안 도구들

Socket.dev — 실시간 공급망 위협 탐지

Socket은 패키지를 설치할 때 해당 패키지가 최근에 의심스러운 변경이 있었는지, 악성 동작 패턴이 있는지를 실시간으로 분석해줍니다. GitHub Actions와 통합하면 PR 단계에서 위험한 패키지를 자동으로 차단해줘요.

Snyk — 상업용 보안 플랫폼

스타트업에게 무료 플랜도 제공하는 보안 플랫폼이에요. 코드, 컨테이너, 인프라까지 전반적인 보안 취약점을 스캔해줍니다.

AI 시대에 오픈소스 보안이 더 중요해진 이유

AI 코딩 도구의 확산으로 오히려 오픈소스 공급망 보안 리스크가 더 커졌어요. AI가 코드를 생성할 때 실제로 존재하지 않는 패키지를 "환각"해서 추천하는 경우가 있는데, 공격자들은 이미 이를 악용하고 있어요. AI가 추천한 패키지를 검증 없이 설치하면 악성 패키지를 설치하게 될 수 있습니다.

실제로 포텐랩 R&D 팀에서도 이런 리스크를 고려해 AI 생성 코드에 대한 보안 검토 프로세스를 표준화하고 있어요. 개발 속도와 보안은 트레이드오프가 아니라 함께 가야 합니다.

자주 묻는 질문 (FAQ)

Q. Axios 해킹 사건, 우리 프로젝트도 영향받나요?

영향받은 버전을 직접 설치했거나, 의존 패키지를 통해 해당 버전이 설치됐다면 영향받을 수 있어요. npm audit로 확인하고 최신 안전 버전으로 업데이트하세요.

Q. 개발 인력이 2~3명인 스타트업도 이걸 다 해야 하나요?

최소한 1, 2, 3번은 꼭 해야 해요. Dependabot 설정은 5분이면 되고 이후엔 자동으로 알려줍니다. 보안은 팀 규모와 상관없이 최소한의 기준이 있어야 해요.

Q. 오픈소스 대신 직접 만들면 더 안전한가요?

그렇지 않아요. 직접 구현한 코드는 검증이 덜 된 코드예요. 잘 관리된 오픈소스는 수천 명의 눈이 검토하죠. 문제는 오픈소스 자체가 아니라 관리 안 된 의존성입니다.

IT 프로젝트 보안 설계나 개발 프로세스에 대한 고민이 있다면, 포텐랩 R&D 서비스에서 상담받아보세요.