본문 바로가기
최신 IT·개발 소식

Dependabot 3일 쿨다운: 일반 업데이트와 보안 업데이트 차이, 설정법까지

by 쑥쑥자라나라 2026. 7. 16.
728x90

2026. 7. 16 (목) · 약 9분

새 패키지가 공개됐다는 알림은 빠를수록 좋아 보인다. 그러나 릴리스 직후에는 깨진 배포나 악성 패키지 신호가 아직 드러나지 않았을 수 있다. GitHub이 Dependabot의 일반 버전 업데이트에 기본 3일의 관찰 창을 넣은 이유와, 보안 업데이트는 왜 기다리지 않는지 실제 설정 흐름으로 살펴본다.

새 패키지 공개부터 3일 관찰 창과 업데이트 PR 검토까지 보여주는 Dependabot 쿨다운 도식

오늘의 핵심뉴스

심층 분석 · GitHub Changelog · 2026. 7. 14

Dependabot 기본 3일 쿨다운, 무엇이 바뀌었나

Dependabot의 일반 버전 업데이트 PR은 새 릴리스가 레지스트리에 공개된 뒤 기본적으로 최소 3일을 기다린다. 취약점 해결을 위한 보안 업데이트는 지연되지 않으며, 저장소 특성에 맞춰 버전 단계별 대기 기간을 조정할 수 있다.

정확히 무엇이 바뀌었나

GitHub은 2026년 7월 14일부터 Dependabot의 일반 버전 업데이트에 기본 패키지 쿨다운을 적용했다. 새 버전이 패키지 레지스트리에 등록되면 곧바로 업데이트 PR 후보가 되는 대신 최소 3일을 기다린다. 별도 설정이 없는 github.com 저장소의 지원 생태계에 적용되며, GitHub Enterprise Server에서는 3.23부터 제공된다.

여기서 3일은 Dependabot이 저장소를 확인하는 주기를 뜻하지 않는다. schedule은 업데이트를 찾는 시점을 정하고, cooldown은 패키지가 공개된 뒤 PR 대상으로 삼기까지의 최소 나이를 정한다. 매일 확인하도록 설정해도 공개된 지 하루 된 일반 버전은 쿨다운이 끝날 때까지 건너뛸 수 있다.

Dependabot 업데이트 흐름의 변화
구분 이전 흐름 현재 기본값
일반 버전 업데이트 새 버전 확인 후 일정에 따라 PR 레지스트리 공개 후 최소 3일을 기다린 뒤 PR 후보
보안 업데이트 취약점 알림에 따라 즉시 PR 변함없이 즉시 PR

왜 하필 3일을 기다리나

릴리스 직후의 패키지는 실제 사용자에게 설치되면서 비로소 문제 신호가 모이기 시작한다. 잘못 배포된 파일, 호환성 오류, 탈취된 유지관리자 계정, 악성 코드 신고가 뒤늦게 확인될 수 있다. 짧은 관찰 창은 이런 신호가 이슈·보안 데이터베이스·새 수정 버전에 나타날 시간을 벌어준다.

OpenSSF가 OSV API를 다룬 글도 많은 악성 패키지가 공개 후 첫 3일 안에 분류된다는 관찰을 바탕으로 최소 릴리스 연령을 두는 방식을 권한다. 다만 3일은 통계적 관찰 창일 뿐 안전 인증이 아니다. 잠복한 악성 동작이나 특정 환경에서만 생기는 오류는 더 늦게 발견될 수 있다.

일반 버전 업데이트와 보안 업데이트는 다르게 움직인다

일반 버전 업데이트와 보안 업데이트 비교
확인 항목 일반 버전 업데이트 보안 업데이트
목적 최신 기능·버그 수정·유지보수 알려진 취약점 해결
PR이 열리는 계기 설정한 schedule에 따른 버전 확인 기본 브랜치의 취약한 의존성 감지
기본 쿨다운 새 릴리스 공개 후 최소 3일 적용하지 않음
우선 확인 릴리스 노트·호환성·잠금 파일 취약점 범위·패치 버전·회귀 테스트

보안 PR이 즉시 열린다는 말은 즉시 병합하라는 뜻이 아니다. 공격 가능성이 있는 시간을 줄이기 위해 검토를 먼저 시작하되, CI와 회귀 테스트를 거쳐야 한다. 일반 버전 PR도 3일을 기다렸다는 이유만으로 자동 병합하기보다 변경 범위와 저장소의 위험도를 확인해야 한다.

728x90
일반 버전 업데이트의 3일 관찰 경로와 보안 업데이트의 즉시 처리 경로 비교
일반 버전 업데이트는 3일 관찰 창을 거친 뒤 PR이 열리고, 보안 업데이트는 취약점 감지 후 즉시 PR이 열린다. 두 경로 모두 테스트와 사람 검토가 필요하다.

dependabot.yml에서 쿨다운을 직접 조정하는 법

모든 패키지를 같은 기간 기다릴 필요는 없다. 패치 버전은 짧게, 호환성 변화가 큰 메이저 버전은 길게 두는 식으로 위험에 맞춰 조정할 수 있다. 다음 예시는 npm 의존성을 매일 확인하되 기본 5일, 메이저 30일, 마이너 7일, 패치 3일을 적용한다.

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    cooldown:
      default-days: 5
      semver-major-days: 30
      semver-minor-days: 7
      semver-patch-days: 3
cooldown에서 자주 쓰는 설정
설정 역할 확인할 점
default-days 기본 대기 기간 1~90일 범위
semver-major-days 메이저 버전 대기 기간 큰 호환성 변경에 여유 부여
semver-minor-days 마이너 버전 대기 기간 기능 추가와 호환성 확인
semver-patch-days 패치 버전 대기 기간 버그 수정의 긴급도와 균형
include / exclude 대상 패키지 포함·제외 각 목록은 최대 150개
패치 마이너 메이저 업데이트의 변경 폭과 권장 대기 기간 비교
패치·마이너·메이저 업데이트는 변경 폭이 다르다. 저장소의 테스트 수준과 장애 비용을 기준으로 대기 기간을 다르게 두는 편이 실용적이다.

3일을 기다리면 안전하다는 뜻은 아니다

쿨다운이 막아주는 것은 ‘아주 새 버전을 곧바로 받는 상황’뿐이다. 이미 오래된 버전이 뒤늦게 악성으로 판명되거나, 정상 패키지의 새 코드가 내 실행 환경에서만 문제를 일으키는 경우까지 해결하지는 못한다. NIST의 공급망 위험 관리 관점처럼 의존성의 출처·변경·배포·운영을 수명주기 전체에서 살펴야 한다.

PR에서는 릴리스 노트와 변경된 잠금 파일을 보고, 예상하지 않은 새 하위 의존성이 들어왔는지 확인한다. CI에는 단위 테스트뿐 아니라 빌드·통합 테스트·취약점 검사를 포함하고, 자동 병합은 필수 검사가 모두 통과한 작은 변경에만 제한하는 편이 안전하다. 중요한 서비스라면 패키지 출처와 서명·해시 검증, 스테이징 배포까지 추가한다.

3일 관찰 창 이후 CI와 잠금 파일 검토와 사람 승인을 거치는 검증 게이트
3일 관찰 창 뒤에도 위험은 남는다. CI, 잠금 파일과 릴리스 노트 확인, 취약점 검사, 사람 승인을 겹쳐야 실제 검증 게이트가 된다.

팀에서는 어떤 규칙으로 운영할까

  • 보안 업데이트 PR은 담당자에게 즉시 알리고 우선 검토한다.
  • 패치는 3일, 마이너는 7일, 메이저는 30일처럼 위험 등급별 기본값을 정한다.
  • 자동 병합은 필수 CI가 통과한 패치 업데이트처럼 범위가 좁은 경우로 제한한다.
  • 핵심 패키지는 릴리스 노트, 유지관리자 변경, 새 하위 의존성을 사람이 확인한다.
  • 업데이트가 몰리면 groups와 PR 개수 제한을 사용해 검토 가능한 양으로 묶는다.
3일은 안전 인증서가 아니라, 문제가 드러날 시간을 사는 관찰 창이다.

내 저장소에서 바로 확인할 체크리스트

  • .github/dependabot.yml에 cooldown을 별도로 설정했는가?
  • 일반 버전 업데이트와 보안 업데이트의 알림·검토 우선순위가 분리돼 있는가?
  • 메이저·마이너·패치별 대기 기간이 서비스 위험도와 맞는가?
  • Dependabot PR에 반드시 통과해야 할 CI 검사가 지정돼 있는가?
  • 자동 병합 전에 잠금 파일과 새 하위 의존성을 확인하는가?
  • 문제가 생기면 이전 버전으로 되돌릴 절차와 담당자가 정해져 있는가?

참고한 자료

Dependabot의 3일 쿨다운은 업데이트를 포기하는 기능이 아니라, 새 릴리스와 내 저장소 사이에 짧은 관찰 구간을 만드는 기본값이다. 보안 수정은 빠르게 검토하고 일반 버전은 위험도에 따라 기다리되, 어느 쪽도 테스트와 사람의 판단을 생략해서는 안 된다.

직접 확인해보려면저장소의 .github/dependabot.yml과 자동 병합 규칙을 함께 열어 일반 업데이트의 대기 기간, 보안 PR의 우선순위, 필수 CI 검사를 한 번에 확인한다.
728x90