Renovate vs Dependabot, 컨테이너 이미지 업데이트 관점에서

컨테이너 이미지 업데이트를 자동화하려고 이것저것 붙여본 지 꽤 됐다. GitHub 표준인 Dependabot을 쓰다가, 결국 Renovate로 옮겨온 팀들이 주변에도 늘고 있다. 두 도구는 언뜻 비슷해 보이지만 컨테이너 이미지 관점에서 뜯어보면 결이 꽤 다르다. 이번 글은 지금 우리 팀이 어떤 기준으로 골랐고, 왜 그런 결정을 했는지 정리한 것에 가깝다.

우리가 원했던 것

시작은 단순했다. 사내 서비스 20여 개, Helm chart 60여 개, GitHub Actions 워크플로 100개 이상에서 쓰이는 이미지 태그를 자동으로 최신화하고 싶었다. 규모가 커지면서 수작업 업데이트가 자꾸 밀렸고, 오래된 base image 하나가 CVE 리포트에 걸려서 리뷰가 늘어나는 일이 반복됐다.

그리고 원한 건 세 가지였다.

첫째, semver 태그와 digest를 함께 관리하고 싶었다. 태그만 올려두면 언제 실제 이미지가 바뀌었는지 알기 어렵다. 반대로 digest만 관리하면 major/minor 업데이트가 파묻힌다. 둘 다 필요했다.

둘째, PR 홍수를 막고 싶었다. Grafana 이미지 하나 올렸다고 40개 리포지토리에 PR이 하루에 다 열리면, 리뷰 큐가 터진다.

셋째, private registry(ECR, Harbor)와 커스텀 태그 규칙에 유연하게 대응하고 싶었다. 어떤 팀은 1.2.3-hotfix.4 같은 태그를 쓰고, 어떤 팀은 date-based 태그를 쓴다.

Dependabot 쪽에서 본 그림

Dependabot의 장점은 명확하다. GitHub에 내장돼 있고, .github/dependabot.yml 하나만 두면 바로 돈다. 조직 정책 관리, security update 자동화, GitHub Advisory 연동 같은 부분은 잘 붙어 있다.

컨테이너 이미지 관점에서 Dependabot이 지원하는 매니저는 실질적으로 docker(Dockerfile), github-actions(container jobs), 그리고 helm/kustomize 정도다. Dockerfile의 FROM 지시자를 잡아서 semver 태그를 올리는 건 잘 된다. 문제는 그 이상 나아가지 못한다는 것이다.

몇 가지 답답했던 지점.

FROM ghcr.io/foo/bar:1.2.3@sha256:abcd... 같이 digest까지 pinning된 경우, Dependabot은 태그가 바뀌었을 때만 PR을 연다. 태그는 그대로인데 리마스터된 이미지(예: patched base로 재빌드된 1.2.3)는 감지하지 못한다. 보안 패치가 태그를 유지한 채 조용히 반영되는 경우가 실무에선 꽤 흔한데, 이걸 놓친다.

또 하나. Helm chart values.yaml 안에 박혀 있는 image.tag, image.repository 같은 필드는 표준 방식으로 커버되지 않는다. Dependabot 입장에서는 그냥 YAML의 어떤 문자열일 뿐이니 어쩔 수 없다.

마지막으로 Docker Compose. compose.yaml의 image 필드는 Dependabot이 아직 매니저로 다루지 않는다. 우리 팀은 로컬 개발 스택을 compose로 관리해서, 이게 은근히 아쉬웠다.

Renovate가 잘 해내는 지점

Renovate는 방향이 다르다. "어디에 있든 버전 문자열을 찾아 올린다"에 가깝다. 매니저(manager)라는 개념이 30개가 넘고, 커스텀 매니저를 정규식으로 정의할 수도 있다.

컨테이너 관점에서 Renovate가 잘 하는 것들.

Digest pinning + 태그 업데이트 동시 관리. pinDigests: true로 두면 모든 이미지 참조에 @sha256:... 를 붙여준다. 그리고 그 digest가 원본 registry에서 바뀌면(태그가 리마스터되면) 별도 PR을 연다. 우리는 이걸 updateTypes: ["digest"]로 잡아 주 1회 배치 PR로 묶었다.

{
  "packageRules": [
    {
      "matchDatasources": ["docker"],
      "matchUpdateTypes": ["digest"],
      "groupName": "container digest updates",
      "schedule": ["before 4am on monday"],
      "prPriority": -1
    },
    {
      "matchDatasources": ["docker"],
      "matchUpdateTypes": ["major"],
      "dependencyDashboardApproval": true
    }
  ]
}

Major 업데이트는 대시보드에서 승인해야만 PR이 열리게 뒀다. 자동으로 3.x → 4.x가 열려서 실수로 머지되는 게 무서웠기 때문이다.

커스텀 매니저. 우리는 사내 툴이 K8s manifest에 이런 라인을 박아둔다.

# renovate: datasource=docker depName=harbor.internal/svc/api
- name: api
  image: harbor.internal/svc/api:2026.08.15-a3f2c1

주석 한 줄로 Renovate에게 "이건 harbor의 이 이미지야"라고 알려주면, 우리 date-based 태그 규칙에 맞는 새 태그가 올라온 걸 잡아준다. 정규식 매니저(customManagers)를 쓰면 아예 # APP_VERSION=1.2.3 같은 걸 스캔하게도 만들 수 있다.

PR 폭주 컨트롤. prConcurrentLimit, prHourlyLimit, schedule, groupName 조합이 굉장히 세밀하다. 우리 팀은 prConcurrentLimit: 6, prHourlyLimit: 2, 그리고 코어 이미지(Redis, Postgres, base image)만 별도 그룹으로 묶었다. 태그가 한꺼번에 밀려도 리뷰 큐가 안 넘친다.

Private registry. Renovate는 hostRules로 registry 별로 인증을 분리해서 걸 수 있다. ECR은 IAM role로, Harbor는 robot account로. Self-hosted Renovate를 EKS에 CronJob으로 돌리는 경우 IRSA로 ECR 인증을 넘길 수 있다.

그럼 Dependabot은 이제 쓸모없나

그건 또 아니다. 실제로 우리도 몇 군데엔 그대로 두고 있다.

리포지토리가 아주 단순한 경우 — 예를 들어 그냥 Node.js 앱 하나에 Dockerfile 하나 — 는 Dependabot이 훨씬 세팅이 빠르다. dependabot.yml에 몇 줄 넣고 끝. Renovate는 self-hosted면 CronJob이나 GitHub App 세팅부터 필요하고, mend/renovate 클라우드는 요금제 고민이 붙는다.

그리고 GitHub Advisory 기반 security update. Dependabot은 GHSA와 native 연동이 돼 있어서, CVE가 뜨면 즉시 patch PR을 열어준다. Renovate도 vulnerabilityAlerts를 지원하긴 하는데 신뢰도와 즉각성 면에서 Dependabot 쪽이 여전히 앞선다는 느낌이다.

최근에 바뀐 것들

올해 초쯤 Renovate 쪽에 컨테이너 관련해서 변화가 좀 있었다. Datasource로 OCI artifact를 다루는 부분이 안정화됐고, ORAS로 push된 Helm chart, WASM 모듈, SBOM artifact 같은 것도 버전 추적이 되기 시작했다. 우리는 아직 실운영엔 안 넣었지만, 사내 helm-oci 마이그레이션 때 활용해볼 계획이다.

Dependabot도 GitHub 쪽에서 grouped updates가 GA로 넘어오면서 예전만큼 PR 폭주는 심하지 않다. 다만 컨테이너 이미지에 대해서는 그룹 규칙이 여전히 단순해서, Renovate만큼 세밀하진 않다.

그래서 우리는

정리하면 이렇다. 리포지토리가 10개 넘어가고, Helm/Kustomize/커스텀 매니페스트가 섞여 있고, private registry 인증과 태그 규칙이 다양하면 Renovate가 낫다. 반대로 단일 리포에 표준 Dockerfile만 있고, security patch 자동화가 최우선이면 Dependabot 유지가 편하다.

우리 팀은 결국 이렇게 갈랐다. 인프라/플랫폼 리포는 전부 Renovate self-hosted(EKS CronJob), 서비스 팀 개별 리포는 팀 선택에 맡기되 Dependabot을 기본값으로. 두 도구가 같은 리포지토리에서 동시에 도는 건 피했다. PR 충돌이 벌어지기 시작하면 리뷰 코스트가 오히려 커진다.

혹시 date-based 태그나 사내 커스텀 태그 스키마 쓰는 팀은 Renovate customManagers 문서를 한번 정독해보길 권한다. 정규식만 잘 짜두면 웬만한 태그 규칙은 다 커버된다.