lockfile 변경을 리뷰하는 습관 들이기

Git에서 PR이나 commit을 리뷰할 때, lockfile 변경사항을 무시하는 건 위험하다. lockfile은 정확히 어떤 버전의 패키지를 사용할지 기록하는 파일이므로, 예상 밖의 변경이 있으면 버그나 보안 문제로 이어질 수 있다.

특히 package-lock.json이나 yarn.lock은 npm install이나 yarn install로 자동 생성되는데, 무심코 버전을 올렸다가 호환성 문제를 만드는 경우가 흔하다.

lockfile이 왜 중요한가

package.json에는 "express": "^4.17.0" 같은 느슨한 버전 제약이 있다. ^는 "4.x.x 범위에서 최신 버전"을 의미한다. 하지만 lockfile은 정확히 "4.17.3"처럼 구체적인 버전을 기록한다.

로컬 개발, 팀원들의 개발 환경, CI/CD, 프로덕션이 모두 같은 버전을 사용하도록 보장하는 게 lockfile의 역할이다.

lockfile 변경사항 확인하기

# git diff로 lockfile 변경 확인
git diff package-lock.json | head -50

# 또는 특정 패키지 버전만 확인
git diff package-lock.json | grep -A 2 -B 2 'express'

의도하지 않은 변경 찾기

# 한 번의 npm install로 정확히 어떤 변경이 생겼는지 확인
git status package-lock.json

# 혹은 commit 메시지에서 'bump' 같은 키워드 검색
# (버전 업그레이드가 의도된 경우)

의심스러운 변경 패턴

1. 예상치 못한 버전 점프: 4.17.0 → 4.20.0

   • 이유가 명확해야 한다 (security update, feature 등)

2. 많은 수의 패키지 업데이트: 간단한 npm install이 왜 수십 개 패키지를 변경했는가?

   • 누군가 의존성 트리를 큰 폭으로 수정했을 가능성

3. 특정 devDependency만 변경: 프로덕션 코드는 안 바뀌었는데 lockfile만 바뀐 경우

   • 실제로 필요한 변경인지 확인

lockfile 리뷰 체크리스트

1. 변경이 의도된 것인가?

   • commit 메시지에 설명이 있는가?
   • PR 설명에 버전 업그레이드 이유가 있는가?

2. 보안 관련 변경인가?

   • CVE(보안 취약점) 패치인가?
   • 변경 로그를 확인해보자

3. 호환성 문제는 없는가?

   • 주요 버전이 바뀐 패키지가 있는가? (e.g., React 17 → 18)
   • 있다면 관련 코드 변경도 함께 있어야 한다

4. devDependency vs dependency

   • 프로덕션 의존성이 바뀌었는가? (우려 높음)
   • 개발 도구만 바뀌었는가? (우려 낮음)

실수를 방지하는 방법

# 변경 없이 lockfile만 업데이트 필요한 경우
# (예: Node 버전 변경 후 lock 파일 재생성)
npm install --package-lock-only

# 또는 특정 패키지만 업데이트
npm install express@latest

# 나머지는 현재 lockfile 기준 유지
npm ci  # install 대신 ci 사용 (lockfile 엄격히 준수)

최종 조언

lockfile 변경은 "자동으로 생기는 것"처럼 보이지만, 사실 프로덕션 안정성에 직접 영향을 미친다. 특히 보안 업데이트가 아닌 이상, lockfile 변경만으로 PR을 승인하지 말고 변경 이유를 명확히 확인하자.