Renovate 자동 의존성 업데이트로 부서진 4가지 패턴

작년 6월 Renovate 를 도입했다. 6개월 후 PR 의 60% 가 자동 생성됨. 그중 95% 는 깨끗하게 머지. 5% 가 production 을 깨거나, 깨질 뻔. 이 글은 그 5% 의 4가지 패턴이다.

패턴 1 — minor 라고 표시된 breaking change

semver 가 제대로 지켜지지 않는다. major bump 가 아니라 minor 인데 동작 변경 이 있는 라이브러리가 너무 많다.

우리 사례 — 한 logging 라이브러리의 2.4.7 → 2.5.0. minor bump. release note 에 "성능 개선". 실제로는 log format 의 timestamp 위치 변경. 우리 log aggregator 의 parser 가 깨졌다. 발견까지 6시간.

방어: Renovate 의 automerge 는 patch 만. minor 도 사람 리뷰. major 는 별도 작업.

패턴 2 — transitive dependency 의 조용한 변경

Renovate 가 직접 의존성만 업데이트. transitive (의존성의 의존성) 는 lockfile 에서 따라옴. 이게 조용한 변경의 원천.

우리 사례 — 직접 의존성 A 를 minor 업데이트했더니, A 의 의존성 B 가 major bump 됨. lockfile 에는 그냥 B: 3.0.0 → 4.0.0 으로 표시. PR diff 만 보면 minor 처럼 보이지만 실제로는 major transitive.

방어: lockfile diff 에서 모든 변경 의 semver level 을 자동 분석. major transitive 가 있으면 자동 alert.

패턴 3 — test 가 통과하지만 production 에서만 다른 행동

테스트 환경에서는 모킹 이 많고, production 에서는 실제 의존성 호출. test 통과해도 production 차이가 있을 수 있음.

우리 사례 — HTTP 클라이언트 라이브러리의 connection pool default 가 5 → 100 으로 증가. test 는 single connection mock 이라 영향 없음. production 에서 우리 외부 API 의 rate limit 초과. 외부 API 가 우리 traffic 의 절반을 reject. 발견까지 9분.

방어: 의존성 업데이트 PR 은 staging 에서 24시간 soak test. test 만으론 부족.

패턴 4 — deprecation warning 누적

라이브러리가 deprecated 표시 + 1년 후 제거 패턴을 따라가면, deprecation warning 이 그동안 조용히 누적. 1년 후 제거 시점에 갑자기 깨진다.

우리 사례 — 1년 전 추가된 deprecation warning 을 눈치 못 챔. 1년 후 그 함수가 제거된 minor bump. 한 endpoint 의 모든 요청 실패. 발견까지 4분.

방어: deprecation warning 을 log level error 로 끌어올리기. 조용히 누적되는 것이 가장 비싼 패턴.

5% 의 진짜 비용

6개월 자동 PR 수:                3,847
                                 — 수동 PR 으로 환산:  3,847 × 30분 = ~1,920 시간
                                 — 자동화 절감:       ~$192,000

5% 사고 / 수정 비용:
  사고 평균 영향 시간:            12 분 (4 패턴 평균)
  사고 빈도:                      6개월에 11건
  사고당 운영 인력 시간:           평균 4 시간 (조사+롤백+postmortem)
  연간 누적 비용:                  ~$13,200
─────────────────────────────────
순 절감:                          ~$178,800 / 6개월

비용은 절감의 7%. 의미 있지만, 위 4 패턴을 모르고 도입 했으면 비용이 2~3배 가 될 수 있었다.

4 패턴의 공통점

위 4 가지의 공통점 — PR 자체는 깔끔 했다는 것. 우리가 주의 깊게 보지 않으면 통과 후 사고. 사후 가 아니라 사전 에 잡으려면 위 4 가지 방어 가 인프라에 박혀야.

Renovate 나 비슷한 자동 의존성 업데이트 도구를 도입했거나 도입하려는 팀이라면, 위 4 패턴 중 2 개 이상 의 방어가 없는 상태에서 분기에 1~2건 의 사고는 예측 가능한 결과 다.