Dependabot·Renovate로 npm·pnpm·Docker·GitHub Actions 의존성을 주 단위로 흡수하는 실무 체크리스트다. 봇 선택, groups·packageRules, 락파일 재현 설치, npm audit·required checks, 메이저 분리, 자동 머지·롤백 루틴 약 40항목. 개발자 CI/CD·보안 패치·공급망 대응과 Cloud & DevOps 운영에 바로 붙일 수 있다.
의존성 업데이트를 “언젠가 PR 한 방”으로 미루면, 취약점 공개 후 며칠 안에 핫픽스가 쌓이거나, 메이저 버전 한 번에 묶여 빌드가 며칠 멈춥니다. 주 단위로 봇이 PR을 열고, 테스트·감사·락파일이 통과한 것만 머지하는 루틴이 잡히면 보안 패치와 기능 버전 모두 예측 가능해집니다.
점검 순서는 봇 선택 → 그룹·스케줄 → 락파일·레지스트리 → npm audit·CI 게이트 → 메이저 분리 → 머지·롤백입니다. 약 40개 항목이며, Node.js·Python·컨테이너 베이스 이미지 공통으로 쓸 수 있습니다. 시크릿 노출 방어는 시크릿·환경변수 체크리스트, 이미지 스캔은 컨테이너 이미지 보안 스캐닝과 짝으로 두세요.
분기마다 “의존성 정리 스프린트”를 잡는 팀은 많습니다. 문제는 그 사이 CVE가 뜨고, 락파일이 반년 묵으면 한 PR에 200개 패키지가 섞인다는 점입니다. 리뷰어는 변경 이유를 못 읽고, CI는 한 번에 깨지며, 결국 전체 리버트로 끝납니다.
| 운영 방식 | 패치 반영 속도 | 리뷰 부담 | 적합 |
|---|---|---|---|
| 완전 수동 | 느림 (분기~반년) | 한 번에 폭주 | 레거시 고정 환경 |
| 봇 + 자동 머지 없음 | 중간 (PR 적체 가능) | 주 단위 분산 | 소규모·초기 |
| 봇 + 패치/마이너 자동 머지 | 빠름 | 메이저·깨진 CI만 | CI 신뢰 가능 팀 |
| 봇만 켜고 테스트 없음 | 빠름·위험 | 장애로 전가 | 비권장 |
목표는 “최신 버전 숭배”가 아니라 보안 패치는 빠르게, 깨질 수 있는 메이저는 분리해서 흡수하는 파이프라인입니다. 배포 직전 게이트와 맞추려면 프로덕션 배포 체크리스트의 롤백·헬스체크 항목과 같은 주기에 맞춰 두는 편이 안전합니다.
시작 한 줄 — 오늘은 봇 설정 파일 하나만 추가하고, 패치·마이너만 주 1회 PR로 제한하세요. 메이저 자동 머지는 끄고, CI가 초록일 때만 사람이 승인하는 규칙을 먼저 고정합니다.
깃허브(GitHub) 저장소라면 디펜다봇(Dependabot)이 기본에 가깝고, 그룹핑·모노레포·커스텀 스케줄이 복잡해지면 레노베이트(Renovate)를 쓰는 팀이 많습니다. 둘 다 “PR을 열어 주는 봇”이고, 품질은 CI·락파일·그룹 규칙에서 갈립니다.
| 항목 | Dependabot | Renovate |
|---|---|---|
| 설정 위치 | .github/dependabot.yml | renovate.json 등 |
| 진입 난이도 | 낮음 | 중간 (옵션 많음) |
| 그룹 PR | 지원 (groups) | 강함 (packageRules) |
| 자동 머지 | GitHub 규칙·앱 조합 | 내장 옵션 풍부 |
| 적합 신호 | 단일 앱·빠른 시작 | 다패키지·세밀 정책 |
선택이 끝나면 설정 파일을 메인 브랜치에 넣고, 첫 주는 “PR만 열고 머지는 사람”으로 둡니다. 노이즈 패턴을 본 뒤 그룹·스케줄을 조이면 리뷰 피로가 줄어듭니다.
최소 구성은 이코시스템·디렉터리·스케줄 세 줄입니다. 그다음 열어 둘 PR 개수, 그룹, 무시 목록을 붙입니다. 공식 문서는 깃허브 Docs의 Dependabot 옵션 목록을 기준으로 맞추세요.
.github/dependabot.yml 최소 예시version: 2 updates: - package-ecosystem: "npm" directory: "/" schedule: interval: "weekly" day: "monday" time: "09:00" timezone: "Asia/Seoul" open-pull-requests-limit: 5 groups: production-patches: dependency-type: "production" update-types: - "patch" dev-minor: dependency-type: "development" update-types: - "minor" - "patch" ignore: - dependency-name: "some-legacy-sdk" versions: [">=3.0.0"] - package-ecosystem: "github-actions" directory: "/" schedule: interval: "weekly" - package-ecosystem: "docker" directory: "/" schedule: interval: "weekly"
레노베이트는 extends 프리셋으로 빠르게 시작하고, packageRules로 세밀 제어합니다. 앱 설치(GitHub App) 또는 셀프 호스트 중 운영 방식을 먼저 정하세요.
renovate.json 최소 예시{ "$schema": "https://docs.renovatebot.com/renovate-schema.json", "extends": ["config:recommended"], "timezone": "Asia/Seoul", "schedule": ["after 9am on monday"], "prConcurrentLimit": 5, "prHourlyLimit": 2, "rangeStrategy": "bump", "lockFileMaintenance": { "enabled": true, "schedule": ["before 6am on monday"] }, "packageRules": [ { "matchUpdateTypes": ["patch", "minor"], "matchDepTypes": ["devDependencies"], "groupName": "dev non-major" }, { "matchUpdateTypes": ["major"], "dependencyDashboardApproval": true }, { "matchPackageNames": ["typescript"], "extends": ["schedule:weekly"] } ] }
봇 PR에서 가장 흔한 실패는 “로컬에선 되는데 CI에서만 깨짐”입니다. 원인은 락파일 미커밋, 매니저 버전 불일치, 레지스트리 미러 차이인 경우가 많습니다. 패키지 매니저 자체 선택은 pnpm·npm·Yarn 비교를 참고하고, 여기서는 업데이트 파이프라인만 고정합니다.
버전 숫자만 올리고 테스트를 안 돌리면 봇은 위험 증폭기입니다. 최소 게이트는 설치 재현 → 유닛/타입체크 → (가능하면) e2e 스모크 → 감사 심각도 정책입니다. 로그·시크릿이 테스트 출력에 새지 않는지도 같이 봅니다.
| 게이트 | 패치/마이너 | 메이저 |
|---|---|---|
| frozen lock 설치 | 필수 | 필수 |
| 유닛·타입체크 | 필수 | 필수 |
| e2e 스모크 | 가능하면 | 권장 |
| 감사 high+ | 차단 | 차단 |
| 사람 리뷰 | 자동 머지 가능 시 생략 가능 | 필수 |
| 스테이징 카나리 | 선택 | 권장 |
메이저 버전은 변경 로그·마이그레이션 가이드를 읽어야 합니다. 봇이 열어 준 PR을 그대로 머지하기보다, 이슈 하나로 묶어 작업 브랜치에서 고치는 편이 안전합니다.
패치 자동 머지를 켜더라도 “프로덕션 즉시 배포”와 “메인 반영”을 구분하세요. 메인이 초록이어도 카나리·프리뷰에서 한 사이클 보는 팀이 장애가 적습니다. 구조화 로그가 있으면 버전 필드(release)로 회귀를 추적하기 쉽습니다. 로그 필드는 구조화 로깅 체크리스트를 맞추면 됩니다.
운영 리듬 예시 — 월요일 봇 PR 생성 → 화·수 패치/마이너 머지 → 목요일 메이저 1건 작업 → 금요일 신규 메이저 머지 금지. 온콜 주간에는 자동 머지를 잠시 끄는 옵션도 팀에 맞게 둡니다.
바이브코딩으로 생성한 코드베이스도 의존성 봇을 처음부터 켜 두는 편이 낫습니다. AI가 고른 패키지 버전이 몇 달 뒤 방치되기 쉽습니다. 출시 전 점검은 보안·시크릿 쪽 체크리스트와 같이 돌리세요.
깃허브 단일 앱이고 설정 시간을 아끼려면 디펜다봇으로 시작하세요. 모노레포·세밀한 그룹·자동 머지 정책이 필요해지면 레노베이트로 이전하는 팀이 많습니다. 둘을 동시에 켜 두면 PR이 중복됩니다.
required checks(설치·테스트·감사)가 안정적으로 초록일 때만 권합니다. UI 스냅샷·E2E가 없는 백엔드 API는 상대적으로 수월하고, 디자인 시스템·메이저 프레임워크 패치도 “항상 무해”는 아닙니다. 첫 달은 사람 승인 후 패턴을 보고 범위를 넓히세요.
open PR 상한을 낮추고, 패치 그룹·dev 그룹으로 묶으세요. 스케줄을 주 1회로 줄이고, 무시 목록에 만료일을 달아 레거시만 빼 두세요. 적체 자체보다 “보안 패치가 뒤로 밀리는지”를 주간 지표로 봅니다.
실패 원인을 먼저 나눕니다. 실제 사용 경로의 high/critical인지, dev 도구만의 이슈인지, 수정 버전이 아직 없는지. 우회가 필요하면 allowlist에 만료일과 티켓을 남기고, 무시한 채 상시 빨간 CI로 두지 마세요. 빨간 상태 고정은 다른 실패도 무시하게 만듭니다.
디펜다봇은 directory 항목을 여러 개 둘 수 있습니다. 레노베이트는 경로 매칭 규칙으로 한 파일에서 처리하는 경우가 많습니다. 워크스페이스 루트 락 하나에 의존한다면 루트만 구독해도 됩니다. 패키지별 배포 주기가 다르면 directory를 쪼개는 편이 리뷰가 쉽습니다.
가능합니다. 읽기 토큰을 저장소 시크릿·호스트 규칙으로 주입하고, 설정 파일에 토큰을 평문으로 쓰지 마세요. 토큰 권한은 해당 스코프 read로 최소화하고, 유출 시 로테이션 절차를 시크릿 체크리스트와 동일하게 둡니다.
