npm을 안정적으로 운영하는 법

npm은 웬만한 실수를 받아 주는 도구라서 팀이 자신도 모르게 나쁜 습관을 쌓기 쉬워. 아래 규칙이 설치가 늘 자연스럽게 되는 팀과 격주 월요일마다 설치 문제를 붙드는 팀을 갈라.

package-lock.json은 항상 버전 관리에 넣어. 팀원이 서로 다른 lockfile을 쓰면 서로 다른 버그를 만나. 실제 설치 상태를 결정하는 파일이므로 반드시 함께 커밋해야 해.

모든 CI/CD 파이프라인에서 npm ci를 써. npm install은 더 나은 의존성 해석을 찾으면 lockfile을 바꿀 수 있어. CI의 설치 결과는 언제나 결정적이어야 해.

npm audit을 정기적으로 실행해. 심각한 취약점이 발견되면 실패하는 주간 예약 작업이나 CI 작업을 추가해. npm 생태계를 겨냥한 공급망 공격은 실제로 존재하며 위험도 커지고 있어.

한 번 쓸 도구에는 npx를 써. 전역 설치 패키지는 계속 관리해야 하지만 npx create-react-app은 한 번 실행하고 흔적을 남기지 않아.

라이브러리의 의존성은 정확한 버전으로 고정하고, 앱은 범위를 허용해. 라이브러리를 배포할 때는 소비자의 환경을 깨뜨리지 않도록 정확한 버전을 쓰고, 앱은 호환 범위 안의 보안 패치를 받을 수 있게 범위를 사용해.

운영 환경에 개발 의존성을 넣지 마. 운영용 Docker 빌드에서 npm install --omit=dev를 사용하면 이미지가 작아지고 공격 표면도 줄어.

Code

운영 의존성만 설치·bash

# Dockerfile 또는 production install 스크립트에서
npm ci --omit=dev

# 또는 옛 npm 버전
npm install --production

GitHub Actions의 표준 npm CI 단계·yaml

# .github/workflows/ci.yml
name: ci
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: 'npm'
      - run: npm ci          # NOT npm install
      - run: npm test
      - run: npm audit --audit-level=high

Exercise

프로젝트 하나를 다음 기준으로 점검해. (1) package-lock.json이 버전 관리에 포함됐는가? (2) CI가 'npm ci'를 쓰는가? (3) 마지막 'npm audit'은 언제였는가? (4) 운영 환경에 devDependencies가 설치되는가? 발견한 문제를 'npm hygiene'이라는 하나의 PR에서 모두 바로잡아.

Code

External links

Exercise

Progress

댓글 0