현장에서는 Skill을 아직 프롬프트 폴더로 취급한다. MCP server도 편의 기능 묶음으로 본다. 그래서 배포는 빠른데, 사고가 나면 누가 만들었고, 무엇을 포함했고, 어떤 권한으로 실행됐는지 추적하지 못한다. 운영 자산이 아니라 공유 드라이브 파일처럼 굴러다닌다.
Anthropic은 2025년 10월 Agent Skills를 폴더 기반 지식·스크립트·리소스 패키지로 공개했고, Claude Code 문서는 SKILL.md, supporting files, allowed-tools, hooks, subagent 실행을 명시한다. MCP도 2025-11-25 명세에서 외부 데이터와 도구를 연결하는 표준 프로토콜로 자리 잡았고, 공식 Registry는 server.json metadata가 npm, PyPI, Docker 같은 실제 패키지를 가리키는 구조를 쓴다. 이 구조에서는 Skill과 MCP bundle을 소프트웨어 공급망으로 다뤄야 한다.
Skill bundle은 문서가 아니라 배포물이다
Skill은 모델이 읽는 지침이지만, 그 안에는 실행 스크립트와 권한이 붙는다. Claude Code의 allowed-tools는 Skill 활성 시 승인 없이 쓸 수 있는 도구 범위를 정의한다. project skill을 신뢰하면 broad tool access가 따라올 수 있다는 경고도 문서에 있다. 이 말은 단순하다. Skill은 prompt가 아니라 permissioned artifact다.
Skill supply-chain attestation의 목적은 신뢰를 선언하는 것이 아니라, 실행 전 거부할 수 있는 증거를 만드는 것이다.
AX Ops에서는 bundle을 네 덩어리로 고정한다.
| 구성 | 포함 내용 | 없으면 차단 |
|---|---|---|
| provenance | repo, commit, builder, workflow, signer identity | 출처 불명 |
| SBOM | scripts, dependencies, model/tool adapters, license | 구성 불명 |
| 권한 manifest | allowed tools, scopes, network, filesystem, secrets | 과권한 |
| tamper check | hash, signature, Sigstore bundle, transparency log | 변조 의심 |
manifest는 권한 계약서다
권한 manifest는 보안팀 보고서가 아니다. 런타임이 읽는 계약서다. Skill이 Bash를 쓰는지, MCP server가 CRM API를 호출하는지, 외부 네트워크가 필요한지, secret 접근이 필요한지 기계가 판단할 수 있어야 한다.
최소 필드는 이렇다.
- artifact: bundle name, version, digest
- publisher: 조직, repo, signer, release workflow
- permissions: tool allowlist, API scope, filesystem path, network egress
- runtime: model family, client, MCP transport, sandbox profile
- policy: 승인자, 만료일, 재검증 조건
여기서 핵심은 least privilege가 아니라 diff 가능성이다. 운영팀은 v1.0.3에서 tool description이 바뀌었는지, allowed-tools가 늘었는지, Docker image digest가 바뀌었는지를 배포 전에 봐야 한다. 사람이 읽는 릴리즈 노트로는 늦다.
서명은 시작이고 정책 검증이 끝이다
SLSA v1.2는 2025년 11월 공개됐고 provenance와 VSA 같은 attestation format을 다룬다. GitHub Artifact Attestations도 build provenance와 SBOM attestation 생성을 지원한다. Sigstore bundle은 artifact signature 검증에 필요한 verification material과 signature content를 묶는다.
그렇다고 서명이 곧 안전은 아니다. SLSA 커뮤니티가 2026년 5월 정리한 Mini Shai-Hulud 사례는 이 점을 선명하게 보여준다. 유효한 provenance가 있어도 빌드 파이프라인 자체가 오염되면 증거는 정확하지만 산출물은 틀릴 수 있다. 그래서 검증 게이트는 네 단계를 모두 통과해야 한다.
- digest가 manifest와 일치한다.
- signer identity와 builder가 allowlist에 있다.
- SBOM이 취약·금지 dependency 정책을 통과한다.
- 권한 manifest가 업무별 runtime policy를 넘지 않는다.
이 게이트는 배포 시점에 한 번만 돌리면 부족하다. Skill과 MCP server는 외부 API, registry, 모델 클라이언트 변화에 영향을 받는다. 재배포, 권한 변경, dependency 변경, registry metadata 변경 시 다시 attest해야 한다.
정착은 검증 루프에서 끝난다
AX Ops에서 Skill 공급망은 개발팀 업무가 아니라 운영 설계다. 작성자는 bundle을 만들고, 플랫폼팀은 attest하고, 보안팀은 policy를 관리하고, 현업 리더는 어떤 업무에 어떤 권한 bundle을 허용할지 결정한다. 이 역할 분리가 없으면 모든 Skill은 예외 승인으로 흘러간다.
참고:
- Anthropic, Introducing Agent Skills, 2025-10-16: https://claude.com/blog/skills
- Claude Code Docs, Extend Claude with skills, 확인일 2026-06-22: https://code.claude.com/docs/en/skills
- Model Context Protocol Specification 2025-11-25: https://modelcontextprotocol.io/specification/2025-11-25
- MCP Registry Quickstart, server.schema.json 2025-12-11 예시: https://modelcontextprotocol.io/registry/quickstart
- SLSA v1.2 announcement, 2025-11-24: https://slsa.dev/blog/2025/11/announce-slsa-v1.2
- GitHub Docs, Artifact Attestations: https://docs.github.com/en/actions/how-tos/secure-your-work/use-artifact-attestations/use-artifact-attestations
- Sigstore Bundle Format: https://docs.sigstore.dev/about/bundle/
- SLSA, Mini Shai-Hulud boundary analysis, 2026-05-15: https://slsa.dev/blog/2026/05/mini-shai-hulud-what-slsa-can-and-cannot-do
지금 필요한 일은 새 Skill을 더 만드는 것이 아니라, 이미 쓰는 Skill과 MCP bundle을 운영 자산 목록에 올리고 검증 게이트를 붙이는 일이다. 그 설계가 AX Ops의 일이다. AX Ops 방법론 →