의존성 업그레이드: 한 번에 몰아치기 vs 조금씩 밀기
dep upgrade 는 전략이다. 타이밍과 단위를 틀리면 롤백도 못 한다.
한 번에 몰아치면 생기는 일
보통은 분기 말에 몰아서 한다. PR 하나에 npm-audit fix —force, pip install —upgrade 전부. 막상 올려보면 세 개 정도가 조용히 breaking change 를 들고 온다. 로그엔 아무것도 없다. 증상은 이틀 뒤 프로덕션에서 나온다.
경험상 패턴은 이렇다:
- 한 PR 에 12개 패키지 → 어느 것이 터진 건지 이분탐색해야 함
- 테스트 통과 → 런타임 직렬화 오류 (특히 pydantic v1→v2 류)
- 롤백 시도 → lock file 이 이미 꼬여 있음
조금씩 밀 때의 현실
느리다. 귀찮다. PR 리뷰어가 “또 dep PR이냐” 한다.
그래도 2026년 기준 내가 쓰는 방식:
- patch/minor 는 주 1회, 자동 PR — Renovate 봇이 올려주면 CI 녹색이면 머지. 리뷰 시간 5분 이하.
- major 는 한 패키지씩, 별도 브랜치 — CHANGELOG 읽고, 영향 범위 주석 달고, 스테이징 하루 굴린 뒤 머지.
- security fix 는 즉시, 나머지 변경 없이 — 다른 업그레이드와 절대 섞지 않는다. 추적이 안 된다.
핵심은 단위다. 패키지 하나가 터졌을 때 git bisect 없이 “아 그 PR” 하고 바로 찾을 수 있어야 한다.
실제로 올해 major 업그레이드 12건 중 롤백은 1건. 그 1건도 10분 안에 되돌렸다. 이전 방식이었으면 반나절 삽질이었을 거다.
다음 한 가지
Renovate 없이 수동으로 올리고 있다면, 이번 주에 설정 파일 하나만 커밋한다.
🛒 이 글과 어울리는 추천 상품
위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.