Dependabot 쿨다운: 의존성 업데이트를 3일 기다리는 이유

출처: https://github.blog/security/supply-chain-security/the-case-for-a-cooldown-why-dependabot-now-waits-before-issuing-version-updates/

GitHub는 Dependabot 버전 업데이트 pull request의 기본 리듬을 바꾸었습니다. 일반 업데이트는 PR을 열기 전에 기본 3일 쿨다운을 거칩니다. 이 짧은 지연은 악성 릴리스, 깨진 패키지, 보안 공지가 수많은 저장소로 퍼지기 전에 발견될 시간을 만듭니다. BTTC 독자는 BTTC 소프트웨어 디렉터리와 BTTC 블로그에서도 같은 기준으로 도구를 비교할 수 있습니다.

핵심 요약: 느린 자동화가 더 안전할 수 있다

쿨다운은 업데이트를 무시하라는 뜻이 아닙니다. 긴급 보안 수정과 일반 업그레이드를 분리하라는 뜻입니다. 3일 동안 커뮤니티 검증, 스캐너 경고, 유지관리자의 수정 릴리스가 나올 수 있습니다. 모든 새 릴리스가 즉시 PR로 쏟아지면 리뷰어는 피로해지고 무심한 병합이 늘어납니다.

지금 이 기본값이 중요한 배경

현대 애플리케이션은 거대한 오픈소스 패키지 그래프에 의존합니다. 직접 의존성, 전이 의존성, 빌드 플러그인, 테스트 프레임워크, 배포 도구가 함께 움직입니다. 악성 패키지, 탈취된 유지관리자 계정, 우발적 breaking change는 순수한 속도만으로 부족하다는 점을 보여주었습니다.

3일 창이 제공하는 실제 이점

쿨다운은 상위 릴리스와 하위 채택 사이에 완충 구간을 둡니다. 이슈, 보안 공지, 레지스트리 제거, 패치 릴리스가 드러날 시간이 생깁니다. critical CVE는 빠른 경로가 필요하지만, 일반 변경과 알려진 위험 감소는 다르게 다루어야 합니다.

의존성 정책을 어떻게 바꿀까

업데이트를 경로별로 나눕니다. critical fix는 빠른 경로, patch와 minor는 쿨다운, major는 릴리스 노트와 호환성 검토를 포함합니다. CI 통과, 운영 의존성의 사람 리뷰, 인증·암호화·빌드·배포 패키지의 추가 승인을 요구합니다.

개발 도구 평가에서 볼 항목

의존성 관리, CI, 코드 리뷰 도구를 고를 때 쿨다운, 그룹 규칙, 심각도 라우팅, 감사 로그, allowlist, 만료되는 ignore 규칙을 확인합니다. 다른 소프트웨어에도 같은 원칙이 적용됩니다. 좋은 제품은 편의성과 통제를 함께 제공합니다.

이번 주 점검 목록

봇이 어떤 생태계를 다루는지, 얼마나 자주 실행되는지, 누가 리뷰하는지, 보안 업데이트와 일반 업데이트가 분리되어 있는지 확인합니다. 사고 대응 절차도 확인하세요. 봇 중지, 버전 고정, 롤백, 캐시 정리, 토큰 폐기는 미리 연습되어 있어야 합니다.

자주 묻는 질문

쿨다운이 프로젝트를 덜 안전하게 만드나요?

그렇지 않습니다. 일반 업데이트는 늦추지만 긴급 보안 수정은 빠른 경로로 처리할 수 있습니다.

자동 병합을 사용해도 되나요?

테스트가 강하고 롤백이 쉬운 낮은 위험 업데이트에만 제한적으로 사용하는 것이 좋습니다.

가장 좋은 쿨다운 길이는 얼마인가요?

3일은 실용적인 기본값이지만 중요도, 테스트 범위, 생태계 속도에 맞게 조정해야 합니다.

마무리

Dependabot 쿨다운은 성숙한 자동화가 단지 빠른 것이 아니라 위험을 이해해야 한다는 메시지입니다.

도입할 때 추가로 볼 점

이미 Dependabot이나 비슷한 봇을 쓰는 팀은 한 저장소에서 먼저 쿨다운을 시험하고 PR 수, 실패율, 롤백 횟수, 리뷰 시간을 기록하는 것이 좋습니다. 보안 팀은 인증, 암호화, 배포, 빌드, 텔레메트리와 관련된 핵심 패키지 목록도 문서화해야 합니다. 그러면 자동화는 단순한 반복 작업 절감이 아니라 리뷰어가 진짜 위험한 변경에 집중하도록 돕는 장치가 됩니다.

운영에서 놓치기 쉬운 부분

쿨다운을 설정해도 소유자가 없는 PR은 계속 쌓입니다. 패키지별 담당자, 릴리스 노트 확인 기준, 테스트 실패 처리 방식, 예외적으로 빠르게 병합할 조건을 정해야 합니다. 이렇게 해야 속도와 안전성 논의가 감이 아니라 증거에 기반한 판단으로 바뀝니다.

지표와 거버넌스

쿨다운은 설정만으로 끝나지 않습니다. 평균 업데이트 시간, critical vulnerability 수정 시간, 자동 병합 비율, 실패한 빌드 수, 롤백 횟수를 추적해야 합니다. 이런 지표가 있어야 정책이 실제로 위험을 줄였는지, 아니면 단순히 큐를 느리게 만들었는지 판단할 수 있습니다.

작은 팀을 위한 조언

작은 팀은 복잡한 플랫폼을 만들 필요가 없습니다. 먼저 기본 쿨다운을 사용하고, 중요한 패키지의 소유자를 정하며, 보안 알림만 빠른 경로로 보냅니다. 그다음 PR 템플릿에 changelog, 테스트 결과, 롤백 방법을 넣습니다. 이 정도만으로도 리뷰 품질이 좋아집니다.

도구 선택과의 관계

이번 발표는 개발 도구를 비교할 때 policy 기능을 봐야 한다는 점을 보여줍니다. 저렴한 도구라도 audit log나 severity rule이 없으면 나중에 운영 비용이 커질 수 있습니다. 편의성, 안전성, 설명 가능성을 함께 보아야 합니다.

추가 운영 기준

팀은 보안 수정과 일반 업데이트를 분리하고, 중요한 패키지마다 담당자를 지정해야 합니다. 또한 실패한 빌드와 롤백 사례를 기록하면 다음 정책 조정 때 더 나은 근거를 확보할 수 있습니다.