다른 작가가 작성한 에이전트 스킬(Agent Skills)을 프로젝트에 통합하는 것은 매우 빠릅니다. 단순히 .claude/skills/ 또는 .github/skills/ 디렉터리에 SKILL 파일을 복사하여 붙여넣기만 하면 됩니다. 하지만 두 달간 사용 주기를 거치면서 문제가 드러나기 시작합니다. 상위 시스템에서 API를 변경했거나, 보안 그룹(Security Group)이 보안 검사 규칙을 수정하면서 일부 누락되는 상황이 발생하며, 이때 이미 이 스킬을 여러 프로젝트 저장소에 복사해 놓았고 심지어 동료들 중 일부는 추가적인 내부 수정을 진행한 상태일 수 있습니다.
크로스-저장소(cross-repository)의 지속적인 업그레이드를 해결하기 위해 GitHub은 2026년 11월 3일에 Dependabot이 Microsoft의 Agent Package Manager (APM)를 공식 지원한다고 발표했습니다. 마치 저장소 루트 디렉터리에 apm 설정 파일과 잠금 파일(lock file)을 두고 로봇에게 주기적으로 PR을 생성하여 버전을 업그레이드하도록 하는 것이 프론트엔드에서 npm과 Dependabot을 사용하는 것과 똑같아 보입니다. 하지만 실제로 코드 패키지를 관리하던 방식을 그대로 에이전트 스킬 관리에 적용하면 네 가지 근본적인 차이를 발견하게 됩니다:
- 호스트 편집기(Host Editor)는 패키지 매니저의 캐시 디렉터리를 인식하지 못하며, node_modules를 로드할 때처럼 런타임에 동적으로 가져오지도 않습니다. 따라서 공식적으로는 설치가 전개된 .claude/ 또는 .github/ 디렉터리 자체를 Git 저장소에 직접 커밋하는 것이 권장됩니다.
- 스킬 패키지에는 프롬프트(Prompt) 외에도 실행 가능한 스크립트, MCP 서비스 설정 및 생명주기 훅(Lifecycle Hooks)이 자주 포함되어 있습니다. 코드 패키지는 하드 드라이브에 다운로드만 하고 호출하지 않으면 죽은 코드(dead code)이지만, 스킬과 훅 파일이 목표 디렉터리에 놓이는 순간, 파일 시스템을 감시하는 편집기는 즉시 컨텍스트를 읽어오거나 심지어 직접 실행을 트리거합니다.
- 코드 라이브러리는 함수 매개변수(function parameter)를 통해 동작을 커스터마이징할 수 있지만, 자연어 설명서에는 매개변수 인터페이스가 없습니다. 팀이 외부 스킬이 내부 규범에 충분히 맞지 않다고 느낄 경우 가장 손쉬운 방법은 스킬 파일을 열어 사설 테이블 이름이나 아키텍처 금지 사항 두 줄을 직접 삽입하는 것입니다. 이로 인해 공적인 규칙과 사적인 규칙이 같은 파일에 섞여버려, 무작정 덮어쓰며 업그레이드할 수 없게 됩니다.
- 자연어에는 컴파일러나 단위 테스트(Unit Test)의 안전망이 없습니다. 상위 시스템에서 프롬프트를 완전히 다르게 수정하더라도 Markdown 문법은 항상 유효하며, 비즈니스 단일 테스트(business unit test)로는 스킬 디렉터리를 테스트할 수 없습니다. CI(Continuous Integration)에서 녹색 불빛으로 병합된 다음 날, 팀 전체의 에이전트 출력 스타일이 완전히 달라져 있을 수 있습니다.
바로 이 네 가지 차이점 때문에 npm과 Dependabot을 그대로 가져와 사용하면 세 군데에서 연속적으로 실패하게 됩니다:
첫째, PR(Pull Request) 병합 버튼을 클릭하면 장부(ledger)는 업그레이드되었지만, 저장소 내 실제 스킬 파일은 업그레이드되지 않습니다. Dependabot은 백그라운드에서 apm lock 명령을 호출하며, 공식 문서를 기준으로 볼 때 이는 잠금 파일의 버전 번호와 해시만 업데이트할 뿐이며, 안전 검사를 명확히 건너뜁니다. 또한 새로운 파일을 .github/ 또는 .claude/ 디렉터리에 복사하지도 않습니다. 만약 병합을 직접 클릭하면, 잠금 파일은 최신으로 업그레이드되지만, 프로그래밍 도우미가 매일 읽는 것은 여전히 이전 파일입니다. 공식적인 관행에 따라 CI에서 apm audit 드리프트 검사 게이트(drift check gate)를 설정하더라도, 로봇이 생성한 모든 PR은 작업 트리 파일이 업데이트되지 않아 바로 빨간불이 켜집니다. 심지어 Microsoft의 공식 저장소조차도 올해 6월 파이프라인에서 드리프트 검사를 건너뛰면서, 메인 브랜치에 커밋된 스킬 파일이 장기간 이전 버전 상태로 남아있었고, 상위 시스템 대비 성능 검토 역할이 하나 부족했음에도 CI는 계속 녹색 불빛을 유지했습니다.
둘째, 만약 스킬 선택(selective skill), 별칭 변경(alias change), 도구 서비스 연결(tool service configuration)과 같은 고급 설정을 사용했다면 Dependabot은 완전히 혼란에 빠집니다. 많은 오픈 소스 스킬 라이브러리에는 수십 개의 스킬이 하나의 저장소에 있습니다. 만약 두 개만 설치하거나, 충돌을 피하기 위해 스킬 이름을 변경하거나, 설정 파일에서 MCP 도구 서비스를 선언하려면 옵션이 포함된 다중 행 구성 블록으로 작성해야 합니다. 하지만 GitHub 공식 문서는 명확하게 Dependabot이 현재 가장 간단한 단일 라인 저장소 주소 표기법만 인식한다고 설명합니다. 다중 행 구성 블록, MCP 선언 또는 기업 사설 소스(private source)를 만나면 아무 말 없이 건너뛰며, 오류도 발생시키지 않고 PR을 생성하지 않습니다.
셋째, 안전 공고(security announcement)를 읽거나 콘텐츠 보안 검사를 할 수 없습니다. Dependabot이 APM 지원을 병합한 핵심 저장소 커밋을 보면, 작성자가 당시 GitHub의 안전 공고 데이터베이스에 APM 패키지가 아예 없었기 때문에 전체 안전 공고 분석 모듈을 임시로 삭제했습니다. 더 은밀한 문제는 누군가가 Glassworm 공격처럼 육안으로 보이지 않는 유니코드 제어 문자를 공유 규칙 파일 안에 숨겨 악성 명령어를 삽입하는 것입니다. APM은 설치(install) 단계에서 실제로 숨겨진 문자 보안 검사를 하지만, Dependabot은 apm lock을 사용하기 때문에 이 단계를 우회합니다.
이것이 바로 Microsoft와 GitHub 내부가 올해 동시에 두 가지 다른 해결책을 발표한 이유입니다. 하나는 대규모 다중 편집기 팀을 위한 중앙 조정 도구인 APM이고, 다른 하나는 GitHub CLI 팀이 4월에 출시한 gh skill입니다. 이는 상위 주소, 버전 번호 및 디렉터리 트리 해시를 각 스킬 문서의 최상단 YAML 헤더 정보에 직접 작성하여 단일 파일 자가 포함(self-contained)을 구현함으로써, 잠금 파일과 실제 파일이 분리되는 위험을 완전히 회피합니다.
팀에서 에이전트 스킬의 의존성 관리와 자동 업그레이드를 실제로 적용하는 가장 실용적인 세 가지 경로는 다음과 같습니다: 중소 규모 프로젝트 또는 단일 편집기 팀은 gh skill install --pin을 사용하여 단일 파일 내장 잠금(single-file embedded lock)을 구현합니다. 고도로 다중 호스트 환경의 팀은 APM과 Dependabot을 결합하여, CI에서 반드시 apm install을 자동으로 실행하고 수정한 내용을 브랜치에 되돌린 후, 이어서 apm audit를 수행하는 부수적 작업을 진행해야 합니다. 가장 중요한 점은 공적인 규칙과 사적인 규칙을 물리적으로 격리(physical isolation)하는 것을 엄격히 지키고, 설치된 외부 스킬은 무조건 읽기 전용 블랙박스(read-only black box)로 취급하며, 팀 자체의 테이블 이름 약속 및 비즈니스 규칙은 프로젝트 자체의 로컬 규칙 파일에 겹쳐서 적용해야 합니다.
완전한 메커니즘 분석 및 비교는 본문 전체에서 확인하세요:
