Dependabot PR triage 자동화: 매일 쌓이는 보안 업데이트를 Copilot으로 분류하는 방법

Dependabot은 보안 업데이트를 자동으로 올려주지만, PR이 쌓이기 시작하면 개발팀은 금방 피로해진다. patch 업데이트는 바로 merge해도 될 것 같고, minor 업데이트는 대개 안전하지만, major 업데이트는 breaking change가 숨어 있을 수 있다. GitHub는 Copilot app automations를 이용해 Dependabot PR을 매일 분류하고 CI 상태를 확인한 뒤 요약을 받는 흐름을 소개했다.

이 글의 목표는 “Copilot으로 Dependabot을 자동 merge하자”가 아니다. 더 현실적인 목표는 첫 번째 triage를 자동화해 사람이 중요한 결정에만 시간을 쓰게 만드는 것이다. 보안 업데이트는 빠를수록 좋지만, 무작정 자동 merge하면 장애가 난다. 반대로 사람이 모든 PR을 하나씩 열어보면 업데이트가 밀린다. 중간 지점이 필요하다.

Dependabot PR이 방치되는 이유

방치의 원인은 게으름이 아니다. 대부분 우선순위 문제다. 제품 기능 개발, 장애 대응, 고객 요청, 배포 준비가 먼저 온다. 의존성 업데이트는 중요하지만 당장 눈앞의 기능처럼 보이지 않는다. 게다가 PR마다 판단 기준이 조금씩 다르다.

예를 들어 lodash patch 업데이트와 React major 업데이트는 같은 Dependabot PR이지만 위험도가 다르다. 테스트가 충분한 패키지도 있고, 거의 커버되지 않는 영역도 있다. 런타임 의존성인지 dev dependency인지도 다르다. CI가 통과했더라도 실제 운영 경로와 연결된 패키지라면 추가 확인이 필요하다.

이 판단을 매번 사람이 처음부터 하면 시간이 많이 든다. 그래서 Copilot automation이 맡을 수 있는 일은 “결정”이 아니라 “정리”다. 어떤 PR이 안전 후보인지, 어떤 PR은 더 봐야 하는지, 어떤 PR은 CI부터 고쳐야 하는지 분류하는 것이다.

자동화가 해야 할 일과 하지 말아야 할 일

GitHub 예시는 Daily Dependabot Triage라는 자동화를 만들고, open Dependabot pull request를 검토해 risk별로 그룹화하고, safe patch/minor update를 식별하고, CI 통과 여부를 확인하고, 다음 액션 요약을 제공하는 방식이다. 이 정도 범위는 현실적이다.

자동화가 해야 할 일은 다음과 같다.

열려 있는 Dependabot PR 목록 수집.
patch, minor, major 업데이트 분류.
runtime dependency와 dev dependency 구분.
CI 상태 확인.
보안 취약점 패치 여부 확인.
lockfile만 바뀐 PR과 코드 수정이 필요한 PR 분리.
사람이 봐야 할 PR을 상단에 배치.

하지 말아야 할 일도 명확하다.

major 업데이트를 자동 merge하지 않는다.
테스트가 없거나 CI가 실패한 PR을 “안전”으로 표시하지 않는다.
릴리즈 노트 확인 없이 breaking change 여부를 단정하지 않는다.
인증, 결제, 데이터베이스, 빌드 시스템 관련 패키지를 낮은 위험으로 묶지 않는다.

이 경계를 지켜야 자동화가 팀의 신뢰를 얻는다.

Copilot automation 프롬프트 예시

자연어로 작업을 정의할 수 있다는 점은 장점이지만, 프롬프트가 모호하면 결과도 모호하다. 다음처럼 출력 형식을 강제하는 편이 좋다.

Review all open Dependabot pull requests in this repository.
Group them into: safe to merge after CI, needs manual review, blocked by failing CI, and high-risk major upgrade.
For each PR, include package name, version change, dependency type, CI status, files changed, and recommended next action.
Do not recommend merging a major version update without manual review.
Do not mark a PR safe if CI is failing or missing.
Return a concise markdown summary.

한국어 팀이라면 요약만 한국어로 요구해도 된다. 중요한 건 “어떤 정보를 보고 판단했는지”를 결과에 남기는 것이다. 그냥 “3개는 안전, 2개는 위험”이라고 나오면 다시 PR을 열어봐야 한다. 패키지명, 버전 변화, CI, 파일 변경 범위가 있어야 아침 스탠드업 전에 빠르게 판단할 수 있다.

위험도 분류 기준 만들기

자동화 품질은 분류 기준에 달려 있다. 팀마다 다르지만 기본 기준은 다음처럼 잡을 수 있다.

낮은 위험:

patch 업데이트.
dev dependency.
CI 전체 통과.
lockfile과 manifest만 변경.
최근 30일 안에 같은 패키지 업데이트 성공 이력 있음.

중간 위험:

minor 업데이트.
runtime dependency.
테스트는 통과했지만 핵심 기능과 연결됨.
changelog 확인이 필요한 패키지.

높은 위험:

major 업데이트.
framework, bundler, ORM, auth, payment 관련 패키지.
CI 실패 또는 테스트 누락.
migration guide가 필요한 버전.
여러 패키지가 한 PR에서 동시에 바뀜.

이 기준을 자동화 프롬프트나 레포 문서에 넣어두면 결과가 일관된다.

운영 루틴으로 만드는 방법

하루 한 번 아침 전에 실행하는 방식이 가장 무난하다. GitHub 글에서도 daily schedule을 예로 든다. 매시간 실행하면 노이즈가 많고, 주 1회는 보안 패치가 늦을 수 있다.

루틴은 이렇게 잡을 수 있다.

오전 8시에 Copilot automation 실행.
결과를 팀 채널 또는 GitHub issue comment로 저장.
safe 그룹은 담당자가 한 번 확인 후 batch merge.
needs manual review 그룹은 코드 오너에게 할당.
high-risk 그룹은 별도 migration task로 전환.
failing CI 그룹은 에이전트 세션을 이어서 원인 분석.

자동화 run history를 남기는 것도 중요하다. 어떤 PR을 왜 안전하다고 봤는지 기록이 있어야 나중에 장애가 났을 때 기준을 고칠 수 있다.

작은 팀에서 특히 효과가 큰 이유

큰 조직은 보안팀이나 플랫폼팀이 의존성 업데이트를 관리한다. 작은 팀은 보통 제품 개발자가 같이 한다. 그래서 Dependabot PR은 “해야 하는데 계속 미뤄지는 일”이 된다. Copilot automation은 이 일을 완전히 없애지는 못하지만, 첫 15분을 줄여준다.

특히 solo developer나 2~5명 팀에서는 효과가 크다. 매일 아침 PR 목록을 열고 판단하는 대신, 요약을 보고 safe 후보만 처리할 수 있다. major 업데이트는 바로 기능 개발 일정에 넣을 수 있고, CI 실패는 원인 분석 세션으로 넘길 수 있다.

실행 체크리스트

Dependabot PR 자동화의 목표를 자동 merge가 아니라 triage로 잡는다.
patch/minor/major, runtime/dev dependency, CI 상태를 반드시 출력하게 한다.
major 업데이트와 핵심 인프라 패키지는 자동으로 high-risk로 분류한다.
CI 실패 또는 테스트 누락 PR은 safe 그룹에 넣지 않는다.
daily schedule로 시작하고, 결과는 팀이 보는 위치에 저장한다.
safe 후보도 최소 한 번은 사람이 확인한 뒤 merge한다.
자동화 결과와 실제 장애·성공 이력을 비교해 분류 기준을 계속 조정한다.

Dependabot PR triage 자동화의 가치는 멋진 AI 기능이 아니다. 반복적인 분류를 백그라운드로 밀어내고, 개발자가 “어떤 업데이트를 지금 처리해야 하는가”에 집중하게 만드는 것이다. 보안 업데이트는 빠르게, 위험한 변경은 조심스럽게. 이 균형을 만드는 데 Copilot automation을 쓰면 된다.