Dependabot APM 지원: AI 스킬·프롬프트도 PR로 업데이트하기

AI 스킬·프롬프트의 버전 변경을 잠금 파일과 코드 리뷰로 연결하는 흐름을 표현한 AI 생성 일러스트.

AI 코딩 에이전트에게 주는 스킬과 지침도 계속 바뀐다. 팀이 사용하는 리뷰 규칙이나 테스트 절차를 다른 저장소에서 가져온다면, 어느 버전이 들어왔고 무엇이 달라졌는지 추적할 방법이 필요하다.

GitHub는 2026년 11월 3일 Dependabot의 Agent Package Manager(APM) 지원을 공개했다. 이제 지원되는 Git 의존성을 대상으로 업데이트 PR을 받고, 기존 잠금 파일도 함께 갱신할 수 있다. github.com의 모든 요금제에 정식 제공되며 GitHub Enterprise Server는 3.24에서 제공될 예정이다. 이번 지원은 버전 업데이트다. APM의 취약점을 찾아 보안 업데이트를 만들어 주는 기능으로 해석하면 안 된다. GitHub 공식 발표

왜 프롬프트에도 의존성 관리가 필요할까

예를 들어 팀 공통 코드 리뷰 스킬에 “테스트 명령을 실행하고 실패 내용을 설명한다”는 규칙이 있다고 하자. 새 버전이 실행 명령, 참조 문서, 사용할 도구를 바꾸면 애플리케이션 소스가 그대로여도 에이전트의 작업 과정은 달라질 수 있다. 이 예시는 변경 검토가 필요한 이유를 설명하기 위한 가정이다.

APM은 스킬·프롬프트·지침 등을 apm.yml에 선언하고 지원되는 에이전트 환경에 배치하는 의존성 관리 도구다. 잠금 파일은 정확한 버전과 콘텐츠 해시를 기록한다. 다만 APM 자체가 다루는 전체 기능과 Dependabot이 갱신할 수 있는 항목은 같지 않다. APM 개요

이번 변화의 실무 가치는 외부 스킬을 몰래 최신 상태로 바꾸는 데 있지 않다. 업데이트 후보가 PR로 모이면 팀이 변경 이력과 테스트 결과를 보고 채택 시점을 정할 수 있다. 기존 코드 의존성 리뷰에 에이전트의 작업 규칙까지 포함하는 방식이다.

설정은 apm.yml의 위치부터 맞춘다

루트 디렉터리에 apm.yml이 있는 저장소라면 .github/dependabot.yml에 다음 항목을 넣는다. 이미 npm이나 GitHub Actions 설정이 있다면 파일을 덮어쓰지 말고 기존 updates 목록에 APM 항목을 추가한다.

directory는 Dependabot 설정 파일의 위치가 아니라 APM 매니페스트가 있는 디렉터리다. 예를 들어 /tools/review-agent/apm.yml을 관리한다면 /tools/review-agent로 바꾼다. 이 파일을 기본 브랜치에 반영하면 해당 위치의 업데이트를 확인한다. 포크 저장소는 설정 파일만으로 자동 활성화되지 않으므로 Dependabot 활성화 여부도 확인해야 한다. 설정 방법

위 YAML은 로컬에서 파싱해 버전 값, APM 식별자, 디렉터리와 주간 일정 구조를 확인했다. 실제 GitHub 저장소에서 업데이트 작업이나 PR 생성을 실행한 결과는 아니다.

태그·커밋·브랜치는 업데이트 방식이 다르다

Dependabot은 dependencies.apm과 devDependencies.apm 아래 지원되는 Git 참조를 읽는다. 참조 방식에 따라 변경되는 파일과 의미가 달라진다.

SemVer 태그: org/skills#v1.0.0처럼 버전을 붙이면 최신 SemVer 태그로 갱신한다. 패키지별 태그도 이름 규칙을 충족해야 한다.

40자리 커밋 SHA: 최신 정식 annotated 릴리스 태그가 가리키는 커밋으로 갱신하며 태그 이름을 주석으로 남긴다.

브랜치: org/skills#main은 매니페스트 문자열을 유지하고 잠금 파일의 커밋만 갱신한다. 기존 apm.lock.yaml이 필요하다.

잠금 파일이 있으면 Dependabot이 apm lock으로 재생성한다. 없던 잠금 파일을 새로 만들어 주지는 않는다. 따라서 브랜치 의존성에 PR이 오지 않는다면 일정만 기다리지 말고 잠금 파일이 커밋되어 있는지 먼저 본다. 지원되는 APM 참조와 동작

apm.yml에 있다고 모두 갱신되지는 않는다

문서에 명시된 제외 항목에는 git:·path: 같은 객체 형태, mcp: 항목, ref가 없는 참조, 로컬 경로, Azure DevOps 항목, 축약 SHA가 있다. registries.default를 설정한 매니페스트에서는 짧은 저장소 표기도 제외되지만 명시적 clone URL은 지원된다. 전체 제외 조건은 공식 문서에서 확인해야 한다. APM 지원 범위

이 차이는 도입 전에 확인할 부분이다. “APM을 사용한다”는 사실만으로 전체 에이전트 구성이 자동 관리된다고 판단하면, 일부 의존성만 PR로 갱신되고 나머지는 계속 오래된 상태로 남을 수 있다. 팀의 매니페스트에서 자동화되는 항목과 별도로 관리할 항목을 구분해 두는 편이 좋다.

잠금 파일 변경과 실제 배치는 별도 단계다

PR에서 커밋 SHA가 바뀌었다고 에이전트가 읽는 파일까지 모두 바뀌었다고 가정하면 안 된다. APM의 apm lock은 의존성을 해결하고 잠금 파일을 기록하지만 .github/나 .agents/ 같은 에이전트 대상 디렉터리에 파일을 복사하거나 삭제하지 않는다. apm lock 명령

APM의 시작 문서는 매니페스트·잠금 파일과 배치된 파일을 함께 버전 관리하도록 안내한다. 따라서 업데이트 PR을 받는 단계와 팀이 사용하는 배치 파일을 다시 만드는 단계를 연결해야 한다. APM 시작하기

다음은 프로젝트에 맞게 구성할 검증 흐름의 예시다. APM이 설치되어 있고 검토 대상 패키지가 정해진 임시 작업 사본에서 실행하는 것을 전제로 한다.

--frozen은 잠금 파일의 고정 값을 사용하고 이를 다시 쓰지 않는다. 그러나 전체 명령이 읽기 전용이라는 뜻은 아니다. 패키지를 내려받고 파일을 배치할 수 있으며, 실패하더라도 앞서 쓴 모든 파일이 되돌아간다고 보장되지 않는다. 또 잠금 파일에 기록되지 않은 배치 파일 때문에 실패하면 일반 설치로 기준 상태를 만든 뒤 결과를 검토하고 커밋해야 한다. apm install의 frozen 동작

위 명령은 이 글에서 실제 실행하지 않았다. 사용하는 대상 경로가 다르면 목록을 조정해야 하고, git diff는 새 미추적 파일을 검사하지 않으므로 git status --short도 함께 확인한다. 검사 실패를 무조건 자동 커밋으로 덮기보다, 어떤 파일이 바뀌었는지 리뷰할 수 있게 만드는 것이 목적이다.

업데이트 PR에서 확인할 다섯 가지

다음은 이번 지원 범위를 바탕으로 제안하는 팀 검토 기준이다.

출처: 예상한 저장소·패키지·릴리스인가. 버전 숫자만 보지 말고 실제 커밋과 변경 내역을 확인한다.

작업 방식: 스킬이 실행하도록 요구하는 명령, 읽는 파일, 접속하는 서비스가 달라졌는가.

권한: 새 도구나 외부 전송 요구가 추가됐는가. 문서에 적힌 요청을 자동 승인으로 취급하지 않는다.

회귀: 대표 작업에서 기존 테스트를 여전히 통과하는가. 결과뿐 아니라 불필요한 파일 수정과 도구 호출도 비교한다.

복구: 문제가 있으면 이전 매니페스트·잠금 파일·배치 파일을 함께 복원할 수 있는가.

처음에는 중요도가 낮은 스킬 하나에 주간 업데이트를 적용하고, PR 생성부터 배치 파일 검토까지 한 번 완주하는 편이 낫다. 봇이 PR을 만들었다는 사실이나 최신 버전이라는 이유만으로 자동 병합하지 않는다.

Dependabot의 APM 지원은 에이전트 설정에도 검토 가능한 변경 단위를 만들어 준다. 운영에서는 업데이트 발견, 잠금 파일 고정, 실제 배치, 작업 품질 확인을 각각 확인해야 한다. 이 네 단계가 연결되어야 팀원이 바뀌거나 저장소를 새로 복제해도 같은 기준으로 에이전트를 사용할 수 있다.

기준일: 2026년 11월 5일 KST. 공식 발표와 문서를 기준으로 정리했으며, 유료 모델 호출이나 외부 저장소 설정 변경은 수행하지 않았다.