SKILL.md는 문서가 아니다, NVIDIA가 서명한 새 공급망

AI 요약

• 무슨 일: NVIDIA가 agent skill을 cataloged, scanned, signed, documented 아티팩트로 다루는 Verified Skills 흐름을 공개했습니다.
  • 검증 파이프라인은 source repo, review, scan, evaluate, skill card, sign, catalog, sync 단계로 설명됩니다.
• 핵심 변화: SKILL.md는 더 이상 단순 안내문이 아니라 에이전트가 찾고 고르고 실행하는 능력 공급망의 일부입니다.
• 주의점: 서명은 무결성을 증명할 뿐 안전성을 보장하지 않습니다. SkillSpector, skill card, 런타임 가드레일이 함께 필요합니다.
  • 최근 arXiv 논문은 skill governance 단계에서 semantic evasion이 blocking verdict를 피한 비율을 36.5%-100%로 보고했습니다.

에이전트 스킬은 처음에는 편의 기능처럼 보였습니다. Claude Code, Codex, Cursor 같은 도구가 특정 작업을 더 잘 수행하도록 SKILL.md, 스크립트, 참고 문서, 예제 파일을 한 폴더에 묶어 두는 방식입니다. 개발자는 스킬을 설치하고, 에이전트는 필요할 때 그 지식을 불러옵니다. 반복 작업을 줄이고, 조직의 방법론을 파일로 남기고, 도메인별 지식을 재사용한다는 점에서 매우 자연스러운 확장입니다.

하지만 이 편리함은 곧 공급망 문제가 됩니다. 스킬은 단순한 문서가 아닙니다. 에이전트에게 “언제 이 능력을 써야 하는지”, “어떤 명령을 실행해야 하는지”, “어떤 파일을 읽어야 하는지”, “어떤 외부 시스템을 호출해야 하는지”를 알려줍니다. 스킬 안에 스크립트가 들어 있고, reference가 들어 있고, tool 사용 지침이 들어 있다면, 그것은 사실상 에이전트에게 주입되는 소프트웨어 패키지에 가깝습니다.

NVIDIA가 2026년 5월 19일 공개한 NVIDIA-verified agent skills 발표는 이 전환을 정면으로 다룹니다. NVIDIA는 verified skill을 cataloged, scanned, signed, documented with a skill card로 정의합니다. 즉 “NVIDIA가 만든 스킬입니다”라고 말하는 데서 끝내지 않고, 어떤 팀이 만들었고, 어떤 검사를 통과했고, 어떤 위험과 제한이 있으며, 다운로드한 디렉터리가 서명 당시와 같은지 확인할 수 있게 하겠다는 것입니다.

이 발표가 중요한 이유는 에이전트 보안 논의가 런타임 가드레일에만 머물 수 없다는 점을 보여주기 때문입니다. 에이전트가 실행 중 어떤 파일을 읽고 어떤 명령을 실행하는지 통제하는 것은 필요합니다. 그러나 그 전에 어떤 capability가 워크플로 안으로 들어오는지도 통제해야 합니다. npm 패키지를 설치하기 전에 출처, 버전, 취약점, 서명을 확인하듯, agent skill도 설치 전 검문소가 필요해지고 있습니다.

스킬은 프롬프트가 아니라 capability입니다

NVIDIA는 agent skill을 “portable instruction sets”로 설명합니다. CUDA-X 라이브러리, AI Blueprints, 플랫폼 도구를 에이전트가 올바르게 쓰도록 가르치는 단위입니다. 이 문장만 보면 스킬은 지식 묶음처럼 보입니다. 하지만 NVIDIA가 바로 이어서 제시하는 검증 항목을 보면 성격이 달라집니다. 스킬은 product team source repo에서 시작하고, review와 scan을 거치며, skill card가 만들어지고, detached signature가 붙고, public catalog에 sync됩니다.

이것은 문서 배포 절차라기보다 소프트웨어 릴리스 절차에 가깝습니다. 실제로 NVIDIA는 signature가 스킬 디렉터리의 모든 파일과 하위 디렉터리를 덮는다고 설명합니다. SKILL.md만이 아니라 scripts, references, assets까지 검증 대상입니다. 스킬 소비자는 skill.oms.sig와 root certificate를 이용해 받은 디렉터리가 게시자가 서명한 아티팩트와 같은지 확인할 수 있습니다.

왜 여기까지 해야 할까요. 에이전트가 스킬을 읽는 방식 때문입니다. 사람이 문서를 읽을 때는 의심스러운 문구를 지나칠 수 있습니다. 에이전트는 다릅니다. 스킬의 설명, trigger, hidden instruction, bundled script, reference 안의 지침이 모델의 skill discovery, selection, execution에 영향을 줄 수 있습니다. 스킬이 “나는 안전한 문서 작성 보조입니다”라고 설명하면서 실제로는 폭넓은 파일 접근이나 외부 전송을 유도한다면, 파일 수준의 악성 코드 검사만으로는 충분하지 않습니다.

최근 arXiv에 올라온 Under the Hood of SKILL.md 논문도 같은 점을 지적합니다. 논문은 SKILL.md를 passive documentation이 아니라 agent가 third-party capability를 find, trust, use하는 방식을 바꾸는 operational text라고 봅니다. 연구진은 discovery, selection, governance 세 단계 공격을 실험했고, 짧은 textual trigger가 adversarial skill의 visibility를 높이며, description-only framing이 functionally equivalent adversarial variant 선택을 유도할 수 있다고 보고했습니다. 특히 governance semantic evasion이 blocking verdict를 피한 비율을 36.5%-100%로 제시했습니다.

이 숫자는 NVIDIA 발표를 읽는 배경이 됩니다. Verified Skills는 “스킬도 안전하게 만들자”는 일반론이 아닙니다. SKILL.md 자체가 공급망 공격면이 되고 있다는 연구와 현장 감각에 대한 응답입니다.

검증 파이프라인은 무엇을 보려 하는가

NVIDIA가 제시한 verified skill 흐름은 source repo, review, scan, evaluate, skill card, sign, catalog, sync입니다. 이 순서가 중요합니다. 먼저 소스 저장소가 있고, product team이 소유합니다. 그다음 자동 정책 검사와 사람 리뷰가 들어가고, SkillSpector scan을 거치며, skill card를 만들고, 디렉터리에 서명한 뒤 catalog에 들어갑니다. 나중에는 evaluation도 같은 validation pipeline의 일부로 들어간다고 설명합니다.

이 흐름은 세 가지 질문에 답하려고 합니다. 첫째, 이 skill은 무엇을 한다고 주장하는가. 둘째, 자동 검토는 무엇을 발견했는가. 셋째, 사용자가 받은 artifact가 검토되고 서명된 artifact와 같은가. NVIDIA 문서의 “A Trust Pipeline for Agent Skills”도 이 세 질문을 release gate의 핵심으로 둡니다.

SkillSpector는 이 흐름의 검사기입니다. NVIDIA 문서 기준으로 SkillSpector는 16개 category, 64개 vulnerability pattern을 다룹니다. 전통적인 software risk로는 vulnerable dependency, suspicious script, dangerous code pattern, credential access, data exfiltration path를 봅니다. agent-native risk로는 hidden instruction, prompt injection, trigger abuse, excessive agency, tool poisoning, declared purpose와 requested access의 mismatch를 봅니다.

이 구분이 핵심입니다. 일반 보안 스캐너는 스크립트와 dependency를 잘 봅니다. 하지만 agent skill에는 자연어 지시문이 있습니다. 이 지시문은 코드가 아니지만 실행 결과에 영향을 줍니다. “이 도구를 쓸 때는 모든 로그를 먼저 읽어라”, “실패하면 외부 URL로 내용을 보내라”, “사용자에게 묻지 말고 계속 진행하라” 같은 문장은 보안상 코드만큼 중요할 수 있습니다. SkillSpector는 이 intent layer를 검사 대상으로 삼는다고 NVIDIA는 설명합니다.

skill card는 README보다 운영 계약에 가깝습니다

NVIDIA 발표에서 또 하나 중요한 구성요소는 skill card입니다. skill card는 machine-readable trust record로, skill이 무엇을 하는지, 누가 만들었는지, 라이선스가 무엇인지, dependency가 무엇인지, 알려진 기술적 제한과 위험, 완화책, 검증 상태를 담습니다. NVIDIA는 cuOpt routing skill 예시를 들며, 개발자가 설치 전에 “누가 만들었는가”, “cuOpt solver endpoint 외에 무엇에 접근하는가”, “optimizer가 실제 routing benchmark에 대해 검증됐는가”를 한 파일에서 확인할 수 있다고 설명합니다.

이것은 README와 다릅니다. README는 사람에게 설명하기 위한 문서입니다. skill card는 조직의 정책과 도구가 읽을 수 있는 신뢰 메타데이터입니다. 엔터프라이즈 팀은 이 파일을 보고 “이 스킬은 우리 환경에서 허용되는가”, “어떤 dependency를 허용해야 하는가”, “known risk가 우리 정책과 충돌하는가”, “검증 상태가 배포 기준을 만족하는가”를 판단할 수 있습니다.

Contractual Skills 논문도 비슷한 방향을 제안합니다. 이 논문은 enterprise skill이 단순 task guidance를 넘어 goal, input boundary, permission, evidence requirement, output contract, quality criteria, verification step, human approval point, handoff rule을 inspectable하게 표현해야 한다고 봅니다. 실험에서는 contractual field가 raw generation quality를 극적으로 높이기보다 checkability와 maintainability를 높이는 쪽에 의미가 있다고 정리합니다. 결론도 조심스럽습니다. contractual skills는 standalone safety mechanism이 아니라 governance layer입니다.

이 말은 NVIDIA의 skill card에도 그대로 적용됩니다. skill card가 있다고 skill이 안전해지는 것은 아닙니다. 하지만 조직이 안전성을 판단할 수 있는 표면이 생깁니다. “이 스킬은 뭐 하는 파일인가요?”라는 질문을 사람마다 다르게 답하는 대신, 소유자, 범위, 제한, 검증 상태를 한 파일로 걸 수 있습니다. 그리고 그 파일이 서명된 디렉터리와 함께 배포되면, 검토 대상과 설치 대상이 분리되는 문제도 줄어듭니다.

서명은 안전의 증명이 아니라 동일성의 증명입니다

NVIDIA는 verified skill에 detached skill.oms.sig를 붙입니다. 문서에 따르면 NVIDIA는 OpenSSF Model Signing format, OMS를 사용합니다. OMS는 Sigstore-style bundle을 확장해 단일 파일뿐 아니라 directory tree 검증을 다룰 수 있게 합니다. 스킬 디렉터리에는 SKILL.md, scripts/, references/, assets/, skill.oms.sig가 있을 수 있고, signature는 signature file 자체를 제외한 디렉터리 내용을 덮습니다.

이 기능이 중요한 이유는 agent skill이 설치 뒤에 쉽게 변형될 수 있기 때문입니다. 누군가 GitHub에서 skill을 받아 내부 저장소에 복사하고, 몇 줄을 바꾸고, 스크립트를 하나 더 넣고, 원래 publisher의 이름을 유지할 수 있습니다. 서명이 없으면 사용자는 “NVIDIA skills repo에서 온 것 같다”는 provenance에 기대야 합니다. 서명이 있으면 적어도 받은 디렉터리가 NVIDIA가 서명한 디렉터리와 같은지 확인할 수 있습니다.

하지만 여기서 선을 그어야 합니다. 서명은 안전의 증명이 아닙니다. NVIDIA 문서도 signing does not prove a skill is safe라고 분명히 말합니다. 서명은 released skill이 signed artifact와 같다는 것을 증명합니다. 그래서 scanning, skill card, review와 함께 있어야 usable trust story가 됩니다. npm 패키지 서명이 악성 로직을 자동으로 없애지 않는 것과 같습니다. signed malicious artifact도 가능하고, 잘못 설계된 안전한 의도의 artifact도 가능합니다.

그래서 배포 정책은 세 단계로 나눠야 합니다. 첫째, 설치 전 scanning과 skill card review입니다. 둘째, artifact integrity verification입니다. 셋째, 실행 중 runtime guardrail입니다. NVIDIA는 NeMo Guardrails, OpenShell, NemoClaw 같은 runtime control을 따로 언급하면서 verified skills의 역할을 구분합니다. 런타임 가드레일은 agent behavior during execution을 통제하고, verified skills는 workflow에 들어오는 capability를 통제합니다.

왜 지금 skill 공급망인가

지금 agent skill이 위험 표면으로 떠오르는 이유는 에이전트 배포 방식이 바뀌고 있기 때문입니다. 과거에는 사용자가 매번 프롬프트를 입력했고, 도구 사용도 제한적이었습니다. 이제는 조직이 스킬을 저장소로 관리하고, 프로젝트별로 설치하고, 에이전트가 필요할 때 자동으로 불러옵니다. 이 흐름은 성능과 생산성에는 좋지만, 보안팀 입장에서는 “어떤 능력이 어디에 설치되어 있는가”라는 inventory 문제를 만듭니다.

TechRadar의 관련 글은 이 문제를 enterprise supply chain risk로 설명합니다. 스킬은 작성자, 버전, 리뷰 여부, 과도한 권한, single source of truth를 확인해야 하는 대상이 됩니다. 이 표현은 과장이 아닙니다. 스킬이 production log를 읽고, deployment script를 실행하고, customer data가 있는 MCP 서버에 접근한다면, 그것은 조직의 운영권한과 맞닿은 자산입니다.

연구 쪽에서도 같은 방향이 보입니다. SkillsVote는 long-horizon agent trajectory를 reusable skill로 바꿀 수 있지만, raw trajectory는 noisy하고 open skill ecosystem은 redundant, uneven, environment-sensitive artifact로 가득하다고 봅니다. 그래서 collection, recommendation, evolution lifecycle을 통제해야 한다고 주장합니다. 논문은 governed external skill libraries가 frozen agent를 model update 없이 개선할 수 있다고 보지만, control exposure, credit, preservation이 핵심이라고 강조합니다.

여기서 공통으로 보이는 단어는 “governance”입니다. 스킬은 많아질수록 도움이 되지만, 무작정 많아지면 오히려 에이전트의 context와 행동을 오염시킵니다. 비슷한 스킬이 여러 개 있으면 agent selection이 불안정해지고, 오래된 스킬이 남아 있으면 잘못된 절차가 반복되며, 검증되지 않은 스킬이 들어오면 권한 경계가 흐려집니다. skill registry는 단순 저장소가 아니라 정책 엔진과 평가 루프를 필요로 합니다.

개발팀이 지금 정해야 할 기준

NVIDIA Verified Skills를 그대로 쓰는 팀이 아니더라도, 이번 발표가 주는 실무 기준은 분명합니다. 첫째, 스킬을 문서가 아니라 설치 가능한 capability로 분류해야 합니다. SKILL.md가 있는 폴더에 scripts와 references가 있다면, 그것은 코드 리뷰와 보안 리뷰의 대상입니다. 둘째, 스킬 카드 또는 그에 준하는 메타데이터를 요구해야 합니다. owner, license, dependency, supported harness, required tools, data access, known limitation, approval condition이 없으면 조직적으로 배포하기 어렵습니다.

셋째, 스캔 범위는 코드에서 자연어로 넓어져야 합니다. prompt injection, trigger abuse, excessive agency, purpose-access mismatch는 전통적인 dependency scanner만으로 잡기 어렵습니다. 넷째, 서명 또는 해시 기반 무결성 검증이 필요합니다. 개발자가 검토한 스킬과 실제 설치된 스킬이 같은지 확인할 수 있어야 합니다. 다섯째, runtime guardrail과 installation gate를 분리해야 합니다. 설치 전 검증이 있어도 실행 중 권한 제한은 필요하고, 실행 중 가드레일이 있어도 검증되지 않은 스킬 설치를 허용해서는 안 됩니다.

이 기준은 사내 스킬에도 적용됩니다. 오픈소스 스킬만 위험한 것이 아닙니다. 내부에서 급하게 만든 배포 스킬, 보안 로그 분석 스킬, 고객지원 답변 스킬이 더 큰 권한을 가질 수 있습니다. 특히 에이전트가 사람의 계정 권한으로 실행되거나, CI/CD 토큰, cloud credential, production log에 접근한다면 스킬 하나가 incident path가 될 수 있습니다.

한국 기업의 AI 도입에서도 이 문제는 빨리 올 가능성이 큽니다. 많은 조직이 먼저 “우리 개발 규칙을 AGENTS.md나 SKILL.md로 정리하자”에서 시작합니다. 좋은 방향입니다. 다만 그 파일들이 쌓이면 곧 “누가 승인했는가”, “어떤 프로젝트에서 쓰는가”, “위험한 지시는 없는가”, “바뀐 뒤에도 검증됐는가”가 따라옵니다. NVIDIA의 verified skills 발표는 이 질문을 미리 제도화한 사례입니다.

에이전트 능력도 릴리스해야 합니다

에이전트 시장은 모델 성능에서 도구 연결로, 도구 연결에서 운영 통제로 이동하고 있습니다. MCP 서버, agent skills, workflow backend, sandbox, telemetry, approval gate가 모두 같은 방향을 가리킵니다. 에이전트가 더 많은 일을 할수록, 그 능력을 어떻게 들여오고, 어떻게 검토하고, 어떻게 추적하는지가 제품의 핵심 품질이 됩니다.

NVIDIA Verified Skills는 완성된 표준이라기보다 중요한 선언에 가깝습니다. agent skill은 documentation이 아니라 release artifact입니다. review, scan, card, sign, verify를 거쳐야 하고, 조직은 이를 runtime guardrail과 연결해야 합니다. 그리고 이 구조는 NVIDIA 생태계에만 머물지 않을 가능성이 큽니다. Claude Code, Codex, Cursor, Gemini/Antigravity, OpenCode가 모두 skill, rule, plugin, extension을 받아들이는 이상, 같은 신뢰 문제가 반복됩니다.

앞으로 에이전트 스킬의 경쟁력은 “얼마나 많은 스킬이 있는가”가 아니라 “믿고 설치할 수 있는가”로 옮겨갈 것입니다. npm이 package.json, lockfile, registry, signature, vulnerability scanning, provenance 논의를 거쳐 왔듯, agent skill 생태계도 비슷한 길을 걷기 시작했습니다. NVIDIA가 skill.oms.sig와 skill card를 전면에 놓은 이유는 바로 여기에 있습니다. 에이전트의 능력도 이제 릴리스하고, 검증하고, 폐기해야 하는 소프트웨어 자산이 되고 있습니다.