GitHub Dependabot 버전 업데이트가 Agent Package Manager 지원: apm.yml에서 ref가 있는 git 의존성만 갱신하며 보안 업데이트는 제외, GHES는 3.24 대기

2026년 11월 3일 GitHub 변경 로그는 Dependabot 버전 업데이트가 Agent Package Manager(APM)를 지원한다고 발표했습니다. AI 에이전트의 스킬, 프롬프트, 지침을 최신으로 유지하기 위한 것입니다. Dependabot은 apm.yml에 선언된 지원되는 git 의존성을 갱신하는 풀 리퀘스트를 열고, apm.lock.yaml이 있으면 다시 생성합니다. 변경 로그는 이 지원이 버전 업데이트에 한하며 보안 업데이트는 포함하지 않는다고 분명히 말합니다. 이 APM 지원은 보안 업데이트 풀 리퀘스트를 만들지 않습니다. 다만 자료만으로 APM 의존성에 보안 경고가 가능한지는 확인할 수 없습니다. Dependabot은 설정한 일정에 따라 지원되는 의존성의 새 버전을 확인합니다.

켜는 방법은 간단합니다. .github/dependabot.yml에 apm 항목을 추가하고 apm.yml이 있는 디렉터리를 지정한 뒤 업데이트 일정을 고르면 됩니다. 제공 범위는 github.com에서 모든 GitHub 요금제에 정식 제공(GA)되고, GitHub Enterprise Server에서는 3.24에 제공될 예정입니다. 자체 호스팅 기업은 아직 쓸 수 없으며 시기는 업그레이드 속도에 달려 있습니다.

변경 로그는 몇 문장뿐이고 자세한 내용은 GitHub 문서의 APM 절에 있으며 그쪽이 더 엄격합니다. Dependabot은 dependencies.apm과 devDependencies.apm 아래 항목을 갱신하고, 갱신 방식은 의존성을 어떻게 고정했는지에 따라 다릅니다. SemVer 태그로 고정한 의존성은 최신 SemVer 태그로 갱신되며 일반 태그와 패키지 이름이 붙은 태그 모두 가능합니다. 패키지 이름 태그는 패키지 이름, 즉 저장소 이름이나 가상 패키지 경로의 마지막 요소로 시작해야 합니다. 커밋 SHA로 고정한 의존성은 주석이 달린 최신 비프리릴리스 릴리스 태그의 커밋으로 갱신되고 태그 이름이 주석으로 붙습니다. 브랜치로 고정한 의존성은 그 브랜치의 최신 커밋으로 갱신되는데, 이때 매니페스트는 여전히 브랜치 이름을 적고 있으므로 apm.lock.yaml만 바뀌고 기존 apm.lock.yaml이 필요합니다. 저장소에 apm.lock.yaml이 있으면 Dependabot은 apm lock을 실행해 다시 만들지만 없을 때 새로 만들지는 않습니다.

문서가 주는 구체적인 예는 규칙을 확인하는 데 도움이 됩니다. octo-org/octo-skills#v1.0.0으로 쓴 의존성은 최신 SemVer 태그로 갱신됩니다. 패키지 이름 태그는 octo-org/octo-skills/skills/review#review-v1.4.0처럼 태그가 패키지 이름 review로 시작합니다. octo-org/octo-skills# 뒤에 40자 SHA를 쓴 의존성은 주석이 달린 최신 릴리스 태그의 커밋으로 옮겨지고 “# v1.4.0” 같은 주석이 붙습니다. octo-org/octo-skills#main으로 쓴 의존성은 main의 최신 커밋으로 이동합니다. 반면 ref가 없는 octo-org/octo-skills, 로컬 경로 ./my-package, http:// 클론 URL을 쓰는 항목은 모두 건너뛰는 목록에 있습니다. 자기 매니페스트에서 쓰는 방식마다 이 목록과 대조하는 것이 변경 로그의 몇 문장을 읽는 것보다 확실합니다.

이는 문서의 내용이 아니라 우리의 해석입니다. 고정 방식이 업데이트를 얼마나 검토하기 쉬운지를 정합니다. SemVer 태그는 apm.yml에 읽을 수 있는 변경을 만들어 검토자가 릴리스 노트와 비교할 수 있게 합니다. 커밋 SHA는 재현성을 주고, Dependabot이 붙이는 태그 주석이 그 커밋이 어느 릴리스에 해당하는지 검토자에게 알려 줍니다. 에이전트 지침을 자동으로 갱신하려는 팀은 그래서 이 두 방식을 선호할 수 있고, 검토자가 거의 단서를 얻지 못하는 브랜치 고정은 이미 완전히 신뢰하는 의존성에만 남기는 편이 안전합니다. 변경마다 추적 가능한 버전 번호가 필요하다는 규칙이 있다면 주석이 달린 릴리스 태그가 더 맞습니다.

문서는 갱신하지 않는 경우도 열거하는데 확인이 필요한 곳이 바로 여기입니다. 객체 형태 항목(git, registry, id, path 맵)과 mcp 항목은 건너뜁니다. 저장소 이름만 쓴 것처럼 ref가 없는 항목, 로컬 경로 항목, Azure DevOps에 호스팅된 항목, http://나 git:// 클론 URL을 쓰는 항목, YAML 블록 스칼라나 이스케이프 시퀀스가 있는 따옴표 문자열로 쓴 항목, 줄인 커밋 SHA도 건너뜁니다. 매니페스트가 registries.default를 설정한 경우의 축약형 항목도 건너뛰지만 명시적 클론 URL을 쓰는 항목은 계속 갱신됩니다. 비공개 저장소는 dependabot.yml에 설정하는 git 레지스트리로 지원됩니다.

실제로는 모든 APM 의존성이 자동으로 추적되지는 않습니다. 많은 팀이 ref 없이 저장소 이름만 쓰거나 공유 스킬 패키지를 로컬 경로로 참조하는데, 이런 항목은 풀 리퀘스트도 없이 조용히 건너뛰어집니다. 켠 뒤에는 Dependabot 실행 로그를 한 번 보고 중요한 의존성이 인식되었는지 확인하고, 항목을 설정했다고 전부 포함되는 것은 아니라는 점을 기억하세요.

마지막 하나는 변경 로그의 내용이 아니라 우리의 판단입니다. 스킬, 프롬프트, 지침은 에이전트가 따르는 텍스트이므로 갱신은 에이전트의 동작을 바꿉니다. 변경 로그는 검토나 신뢰 통제를 논하지 않으므로 이런 풀 리퀘스트도 코드 변경처럼 사람이 직접 검토하는 편이 안전하며, 특히 브랜치로 고정한 의존성은 갱신 시 잠금 파일만 바뀌고 매니페스트에는 차이가 나타나지 않으므로 주의해야 합니다.