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

오늘의 핵심뉴스
심층 분석 · 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 대상으로 삼기까지의 최소 나이를 정한다. 매일 확인하도록 설정해도 공개된 지 하루 된 일반 버전은 쿨다운이 끝날 때까지 건너뛸 수 있다.
| 구분 | 이전 흐름 | 현재 기본값 |
|---|---|---|
| 일반 버전 업데이트 | 새 버전 확인 후 일정에 따라 PR | 레지스트리 공개 후 최소 3일을 기다린 뒤 PR 후보 |
| 보안 업데이트 | 취약점 알림에 따라 즉시 PR | 변함없이 즉시 PR |
왜 하필 3일을 기다리나
릴리스 직후의 패키지는 실제 사용자에게 설치되면서 비로소 문제 신호가 모이기 시작한다. 잘못 배포된 파일, 호환성 오류, 탈취된 유지관리자 계정, 악성 코드 신고가 뒤늦게 확인될 수 있다. 짧은 관찰 창은 이런 신호가 이슈·보안 데이터베이스·새 수정 버전에 나타날 시간을 벌어준다.
OpenSSF가 OSV API를 다룬 글도 많은 악성 패키지가 공개 후 첫 3일 안에 분류된다는 관찰을 바탕으로 최소 릴리스 연령을 두는 방식을 권한다. 다만 3일은 통계적 관찰 창일 뿐 안전 인증이 아니다. 잠복한 악성 동작이나 특정 환경에서만 생기는 오류는 더 늦게 발견될 수 있다.
일반 버전 업데이트와 보안 업데이트는 다르게 움직인다
| 확인 항목 | 일반 버전 업데이트 | 보안 업데이트 |
|---|---|---|
| 목적 | 최신 기능·버그 수정·유지보수 | 알려진 취약점 해결 |
| PR이 열리는 계기 | 설정한 schedule에 따른 버전 확인 | 기본 브랜치의 취약한 의존성 감지 |
| 기본 쿨다운 | 새 릴리스 공개 후 최소 3일 | 적용하지 않음 |
| 우선 확인 | 릴리스 노트·호환성·잠금 파일 | 취약점 범위·패치 버전·회귀 테스트 |
보안 PR이 즉시 열린다는 말은 즉시 병합하라는 뜻이 아니다. 공격 가능성이 있는 시간을 줄이기 위해 검토를 먼저 시작하되, CI와 회귀 테스트를 거쳐야 한다. 일반 버전 PR도 3일을 기다렸다는 이유만으로 자동 병합하기보다 변경 범위와 저장소의 위험도를 확인해야 한다.
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
| 설정 | 역할 | 확인할 점 |
|---|---|---|
| default-days | 기본 대기 기간 | 1~90일 범위 |
| semver-major-days | 메이저 버전 대기 기간 | 큰 호환성 변경에 여유 부여 |
| semver-minor-days | 마이너 버전 대기 기간 | 기능 추가와 호환성 확인 |
| semver-patch-days | 패치 버전 대기 기간 | 버그 수정의 긴급도와 균형 |
| include / exclude | 대상 패키지 포함·제외 | 각 목록은 최대 150개 |
3일을 기다리면 안전하다는 뜻은 아니다
쿨다운이 막아주는 것은 ‘아주 새 버전을 곧바로 받는 상황’뿐이다. 이미 오래된 버전이 뒤늦게 악성으로 판명되거나, 정상 패키지의 새 코드가 내 실행 환경에서만 문제를 일으키는 경우까지 해결하지는 못한다. NIST의 공급망 위험 관리 관점처럼 의존성의 출처·변경·배포·운영을 수명주기 전체에서 살펴야 한다.
PR에서는 릴리스 노트와 변경된 잠금 파일을 보고, 예상하지 않은 새 하위 의존성이 들어왔는지 확인한다. CI에는 단위 테스트뿐 아니라 빌드·통합 테스트·취약점 검사를 포함하고, 자동 병합은 필수 검사가 모두 통과한 작은 변경에만 제한하는 편이 안전하다. 중요한 서비스라면 패키지 출처와 서명·해시 검증, 스테이징 배포까지 추가한다.
팀에서는 어떤 규칙으로 운영할까
- 보안 업데이트 PR은 담당자에게 즉시 알리고 우선 검토한다.
- 패치는 3일, 마이너는 7일, 메이저는 30일처럼 위험 등급별 기본값을 정한다.
- 자동 병합은 필수 CI가 통과한 패치 업데이트처럼 범위가 좁은 경우로 제한한다.
- 핵심 패키지는 릴리스 노트, 유지관리자 변경, 새 하위 의존성을 사람이 확인한다.
- 업데이트가 몰리면 groups와 PR 개수 제한을 사용해 검토 가능한 양으로 묶는다.
3일은 안전 인증서가 아니라, 문제가 드러날 시간을 사는 관찰 창이다.
내 저장소에서 바로 확인할 체크리스트
- .github/dependabot.yml에 cooldown을 별도로 설정했는가?
- 일반 버전 업데이트와 보안 업데이트의 알림·검토 우선순위가 분리돼 있는가?
- 메이저·마이너·패치별 대기 기간이 서비스 위험도와 맞는가?
- Dependabot PR에 반드시 통과해야 할 CI 검사가 지정돼 있는가?
- 자동 병합 전에 잠금 파일과 새 하위 의존성을 확인하는가?
- 문제가 생기면 이전 버전으로 되돌릴 절차와 담당자가 정해져 있는가?
참고한 자료
Dependabot의 3일 쿨다운은 업데이트를 포기하는 기능이 아니라, 새 릴리스와 내 저장소 사이에 짧은 관찰 구간을 만드는 기본값이다. 보안 수정은 빠르게 검토하고 일반 버전은 위험도에 따라 기다리되, 어느 쪽도 테스트와 사람의 판단을 생략해서는 안 된다.
'최신 IT·개발 소식' 카테고리의 다른 글
| WordPress 7.0.2 보안 업데이트: Cloudflare WAF가 있어도 패치해야 하는 이유 (0) | 2026.07.18 |
|---|---|
| Cloudflare 캐시가 대륙을 우회하는 이유: Smart Tiered Cache 리전 힌트 설정법 (0) | 2026.07.17 |
| 낮 3시간의 전기부터 패키지 업데이트까지, 자동화를 기다리게 하는 이유 (0) | 2026.07.16 |
| 250억 원 청구서부터 AI 보안 경고까지, 자동화 결과를 다시 보는 법 (0) | 2026.07.15 |
| 딥페이크 얼굴 판별, 1시간 훈련으로 정확도가 두 배 오를까? (1) | 2026.07.14 |