AI 지침도 복사해 두면 낡습니다, Dependabot이 에이전트 패키지 업데이트를 맡습니다

에이전트에게 주는 지침도 업데이트 대상입니다

AI 에이전트의 스킬이나 프롬프트를 외부 저장소에서 가져다 쓴다면, 처음 설치하는 일보다 나중에 무엇이 바뀌었는지 알아보는 일이 번거로울 수 있습니다. GitHub는 11월 3일 Dependabot의 버전 업데이트에 Agent Package Manager(APM)를 추가했습니다. apm.yml로 관리하는 지원 대상 Git 의존성에 새 버전이 생기면 업데이트 PR을 제안하는 방식입니다. 공식 발표

외부 지침도 낡을 수 있습니다: 외부 지침 apm.yml로 선언, 새 버전 지원 Git 의존성, 업데이트 PR 변경을 검토할 입구 — AI 생성 개념 이미지

GitHub.com의 모든 요금제에서 정식 제공하며, GitHub Enterprise Server는 3.24에서 지원할 예정이라고 발표했습니다. 모든 AI 지침 파일을 자동으로 찾아 관리하는 기능은 아닙니다. 공식 발표

지원 범위를 먼저 확인: GitHub.com 모든 요금제 정식 제공, GHES 3.24 지원 예정, 모든 지침 파일? 자동 검색 대상 아님 — AI 생성 개념 이미지

바뀐 것은 지침을 검토하는 입구입니다

APM을 사용하는 저장소에서는 스킬·프롬프트·지침의 의존성을 파일로 선언합니다. Dependabot은 지원되는 선언을 읽어 업데이트를 제안합니다. 핵심은 새 지침을 무조건 실행하는 것이 아니라, 변경 내용을 PR이라는 검토 경로로 가져오는 데 있습니다.

복사에서 검토로: APM 선언 의존성 관리, Dependabot 변경 제안, PR 검토 자동 실행 · 승인 아님 — AI 생성 개념 이미지

실무에서는 외부 지침을 복사한 뒤 잊어버리는 방식보다 변경 이력과 승인 과정을 남기기 쉬워집니다. 이는 기능의 운영상 의미에 대한 해석입니다. 지침 내용의 타당성이나 우리 업무에 맞는지까지 Dependabot이 대신 판단한다는 뜻은 아닙니다.

변경 이력이 남는 운영: 기존 지침 어디에서 가져왔나, 변경 비교 무엇이 바뀌었나, 업무 적합성 팀이 직접 판단 — AI 생성 개념 이미지

잠금 파일이 없으면 자동으로 만들어주지 않습니다

공식 문서에 따르면 dependencies.apm과 devDependencies.apm의 Git 의존성이 대상입니다. 버전 태그, 40자리 커밋 SHA, 브랜치 등 고정 방식에 따라 업데이트 동작이 달라집니다. 지원 문서

고정 방식마다 다른 동작: 버전 태그 버전 기준, 40자리 SHA 커밋 기준, 브랜치 잠금 파일 조건 — AI 생성 개념 이미지

특히 브랜치를 가리키는 항목은 기존 apm.lock.yaml이 있어야 업데이트할 수 있습니다. 이때 브랜치 이름이 적힌 선언 파일은 그대로이고 잠금 파일이 바뀝니다. Dependabot은 존재하는 잠금 파일을 재생성하지만, 없는 잠금 파일을 새로 만들지는 않습니다. 지원 문서

브랜치를 쓰면 잠금 파일 확인: 브랜치 선언 선언은 그대로, 기존 잠금 파일 apm.lock.yaml 필요, 잠금 파일 갱신 없는 파일 생성 안 함 — AI 생성 개념 이미지

GitHub Docs의 APM 지원과 잠금 파일 조건 — GitHub Docs 실제 화면 · © GitHub 및 기여자 · CC BY 4.0 · 내용 변경 없음 · 2026.11.04 확인

“설정했는데 PR이 안 온다”면 일정만 볼 것이 아니라 선언 형식과 잠금 파일부터 확인해야 합니다. 로컬 경로, ref가 없는 항목, 축약 SHA, mcp 항목 등 지원되지 않는 경우도 있습니다. 전체 예외는 공식 지원 문서와 대조하는 편이 안전합니다. 지원 문서

PR이 안 온다면: 선언 형식 경로와 ref 확인, 잠금 파일 기존 파일 확인, 지원 예외 공식 문서와 대조 — AI 생성 개념 이미지

버전 관리와 보안 검사는 구분해야 합니다

이번 발표는 APM 버전 업데이트 지원입니다. 새로운 버전이라는 이유만으로 안전하거나 더 좋은 지침이라고 판단하면 안 됩니다. PR이 열리는 것과 조직이 승인하는 것은 별개의 단계입니다.

새 버전이 안전의 증거는 아닙니다: 새 버전 업데이트 소식, 검토할 변경 안전성 보장 아님, 승인 결정 조직의 판단 — AI 생성 개념 이미지

가령 고객 문의를 분류하는 에이전트 스킬을 갱신한다고 가정해 보겠습니다. 문구만 바뀌었는지, 외부 서비스 호출이 추가됐는지, 입력 자료를 더 넓게 읽도록 바뀌었는지를 살펴야 합니다. 이 예시는 실제 운영 성과가 아니라 검토 방법을 설명하기 위한 가정입니다.

스킬 업데이트를 검토하는 예: 문구 변경 분류 지침의 차이, 외부 호출 새 전송 경로가 있나, 입력 범위 더 넓게 읽는가 — AI 생성 개념 이미지

기존의 대표 입력 몇 개로 변경 전후 결과를 비교하고, 필요하지 않은 도구 권한이나 데이터 전송이 새로 요구되는지도 확인하는 편이 좋습니다. 자동 병합을 먼저 켜기보다 누가 무엇을 확인하고 승인할지 정하는 것이 우선입니다.

자동 병합보다 먼저: 대표 입력 기존 작업으로 시험, 전후 비교 결과 차이 확인, 권한 · 전송 필요한지 검토 — AI 생성 개념 이미지

오늘 확인할 것은 세 가지입니다

먼저 현재 저장소가 APM의 apm.yml을 실제로 쓰는지 확인합니다. 단순히 지침 문서를 복사해 둔 저장소라면 이번 기능이 그대로 적용되지는 않습니다.

첫 단계: APM 사용 여부: 저장소 실제 구성 확인, apm.yml 의존성 선언 존재, 지원 적용 단순 복사와 구분 — AI 생성 개념 이미지

다음으로 각 항목의 고정 방식과 기존 잠금 파일을 확인합니다. 이후 .github/dependabot.yml에서 apm 생태계, 대상 디렉터리, 업데이트 주기를 공식 안내에 맞춰 설정하는 흐름입니다. 공식 발표 지원 문서

설정은 순서대로: 고정 방식 각 의존성 확인, 잠금 파일 존재와 상태 확인, 업데이트 설정 apm · 디렉터리 · 주기 — AI 생성 개념 이미지

마지막으로 업데이트 PR의 검토 담당자와 시험할 대표 작업을 정합니다. 지침을 가져오는 속도보다 바뀐 지침을 이해하고 되돌릴 수 있는지가 운영 품질을 가릅니다. 업데이트 제안은 자동화하되, 업무 판단까지 자동 승인하지 않는 구분이 필요합니다.

자동 제안과 사람의 승인: 변경 제안 자동화할 부분, 담당자 검토 대표 작업을 시험, 되돌릴 경로 운영 판단은 별도 — AI 생성 개념 이미지

이어서 읽어볼 만한 뉴스

배포 코드는 그대로인데 실행 내용이 바뀐다면? GitHub Actions에 잠금 파일이 생겼습니다