2026년 들어 코딩 에이전트 생태계에서 조용히 커지는 단어가 있습니다. 바로 agent skills입니다. AWS는 2026년 5월 6일 Agent Toolkit for AWS를 공개하며 agent skills, managed MCP server, 플러그인을 묶어 코딩 에이전트가 AWS 작업을 더 안정적으로 수행하도록 돕겠다고 설명했습니다. Contentful도 5월 20일 Contentful Skills를 공개했고, k-ID는 5월 18일 공식 Agent Skills bundle을 발표했습니다. 이제 스킬은 개인이 로컬에 적어 둔 팁 파일이 아니라, 벤더가 배포하고 팀이 공유하는 실행 지식 패키지가 되고 있습니다.

동시에 연구 쪽에서는 경고음도 나옵니다. 2026년 4월 논문 How Well Do Agentic Skills Work in the Wild는 3.4만 개 실제 스킬을 대상으로, 에이전트가 필요한 스킬을 직접 찾아 쓰는 현실 조건에서는 성능 이득이 줄어드는 문제를 다룹니다. 보안 연구인 Agent Skills in the Wild와 Malicious Agent Skills in the Wild는 스킬이 instruction bundle을 넘어 실행 코드와 권한 전제를 포함할 때 새로운 공격 표면이 된다는 점을 보여줍니다.

이 흐름을 저는 Agent Skill Supply Chain이라고 부르겠습니다. 관련 글인 Cloud Agent Toolkit, Repo-local Agent Policy, Tool Permission Manifest, Package Release Quarantine Gate와 같은 문제의식입니다. 코드 패키지가 supply chain이면, 에이전트의 행동을 바꾸는 skill도 supply chain입니다.

이 글에서 얻는 것

  • agent skill을 단순 프롬프트가 아니라 검증 가능한 의존성으로 보는 기준을 얻습니다.
  • 공식 skill, 커뮤니티 skill, 내부 skill을 서로 다른 신뢰 등급으로 관리하는 방법을 이해합니다.
  • skill registry, version pin, 권한 manifest, canary task, stale review를 어떤 순서로 도입할지 정리할 수 있습니다.
  • 스킬을 많이 설치할수록 왜 검색 품질과 보안 위험이 동시에 나빠질 수 있는지 판단할 수 있습니다.

핵심 개념/이슈

1) 스킬은 에이전트의 행동을 바꾸는 런타임 입력이다

사람이 README를 읽고 따라 하는 것과 에이전트가 skill을 로드하고 실행하는 것은 다릅니다. 사람은 이상한 명령을 보면 멈출 수 있지만, 에이전트는 skill에 적힌 절차를 신뢰하고 도구를 호출할 수 있습니다. 특히 스킬이 shell script, MCP tool, browser automation, cloud CLI, package manager를 다루면 위험 모델은 “문서"가 아니라 “실행 가능한 운영 절차"에 가까워집니다.

그래서 skill manifest에는 최소한 아래 필드가 필요합니다.

skill_id: aws-core/serverless-api
source: "aws/agent-toolkit"
version: "2026.05.06"
owner: platform-team
trust_tier: official-vendor
allowed_tools:
  - docs_read
  - iac_plan
blocked_tools:
  - cloud_apply
  - secret_read
last_verified_at: 2026-05-26
review_interval_days: 30
canary_tasks:
  - "generate plan-only S3 lifecycle policy"

핵심은 “어떤 스킬을 설치했나"보다 “그 스킬이 어떤 권한으로 무엇을 하게 만들 수 있나"입니다. 이 관점은 Tool Contract Test와 바로 연결됩니다. 스킬은 설명이 아니라 테스트 대상입니다.

2) 스킬이 많을수록 항상 좋아지는 것은 아니다

스킬의 장점은 반복 절차를 줄이고 최신 도메인 지식을 넣는 것입니다. 하지만 100개, 1,000개가 넘어가면 다른 문제가 생깁니다.

  • 에이전트가 필요한 스킬을 찾지 못한다.
  • 비슷한 스킬이 서로 다른 절차를 제안한다.
  • 오래된 스킬이 새 API나 정책과 충돌한다.
  • 스킬이 요구하는 권한이 실제 작업보다 넓다.
  • 내부 규칙보다 외부 벤더 예제가 우선되는 drift가 생긴다.

실무 기준으로는 한 repo에서 기본 로드되는 스킬을 10~20개 이하로 제한하는 편이 좋습니다. 나머지는 작업 유형별로 lazy load하거나, approved registry에서 명시적으로 선택하게 둡니다. 특히 보안, 배포, 클라우드, 데이터 마이그레이션 스킬은 자동 검색보다 allowlist 기반이 안전합니다.

3) 공식 출처와 내부 적합성은 별개다

AWS, Contentful, k-ID 같은 공식 스킬은 신뢰할 수 있는 최신 지식을 제공한다는 장점이 있습니다. 하지만 공식 스킬이 곧 내부 기준에 맞는다는 뜻은 아닙니다. 예를 들어 벤더 예제는 특정 리전을 기본값으로 쓰거나, 빠른 데모를 위해 넓은 IAM 권한을 제안하거나, 내부 비용 태그·데이터 보존·네트워크 제한을 모를 수 있습니다.

따라서 공식 스킬도 내부 policy와 결합해야 합니다. 외부 스킬은 “도메인 절차"를 제공하고, repo-local policy는 “우리 조직에서 허용되는 경계"를 제공합니다. 둘이 충돌하면 내부 policy가 이겨야 합니다.

실무 적용

1) skill registry를 패키지 registry처럼 운영한다

처음부터 큰 플랫폼을 만들 필요는 없습니다. approved-skills.yaml 하나로 시작해도 충분합니다.

skills:
  - id: contentful/nextjs-migration
    source_url: "https://www.contentful.com/blog/introducing-contentful-skills/"
    pinned_ref: "2026-05-20"
    trust_tier: official-vendor
    allowed_repos: ["web-storefront", "marketing-site"]
    allowed_tools: ["file_read", "file_write", "test_run"]
    denied_tools: ["external_write", "secret_read"]
    owner: "web-platform"
    expires_at: "2026-06-30"

이 목록에 없는 스킬은 기본 차단하거나 read-only 실험으로만 허용합니다. 설치 요청에는 source, 목적, 필요한 도구 권한, 예상 변경 범위, canary task가 있어야 합니다. 커뮤니티 스킬은 최소 2472시간 quarantine window를 두고, 내부 task corpus 35개로 smoke를 돌린 뒤 승인하는 편이 안전합니다.

2) skill CI를 만든다

스킬도 테스트해야 합니다. 좋은 테스트는 모델 성능 전체를 평가하는 것이 아니라, 스킬이 절대 깨면 안 되는 계약을 좁게 확인합니다.

  • 금지된 도구를 호출하지 않는가
  • 내부 policy와 충돌하는 권한을 요구하지 않는가
  • 최신 API 문서 링크가 살아 있는가
  • 예제 명령이 dry-run 또는 plan-only로 끝나는가
  • 실패 시 사람 승인으로 멈추는가
  • 출력에 비밀값, 내부 URL, 고객 데이터가 섞이지 않는가

지표는 단순합니다. skill_canary_pass_rate는 95% 이상, forbidden_tool_call은 0건, stale_skill_count는 전체의 10% 이하를 목표로 잡습니다. 30일 이상 검증되지 않은 외부 스킬은 자동으로 warning, 60일 이상이면 기본 로드에서 제외하는 방식이 현실적입니다.

3) 스킬 산출물도 artifact로 남긴다

스킬이 실제 작업에 영향을 줬다면 결과에 흔적이 남아야 합니다. PR 본문이나 agent receipt에 skill_id, skill_version, loaded_at, allowed_tools, canary_status 정도를 남기면 나중에 문제를 추적하기 쉽습니다. 이 구조는 Agent Artifact Registry와 잘 맞습니다.

예를 들어 클라우드 설정 PR에서 문제가 났을 때 “Codex가 만들었다"는 정보는 거의 쓸모가 없습니다. 어떤 AWS skill 버전이 로드됐고, 어떤 내부 policy와 함께 실행됐고, dry-run 결과가 어디에 남았는지가 필요합니다.

트레이드오프/주의점

첫째, 스킬 검증을 너무 엄격하게 만들면 팀이 우회합니다. 모든 외부 스킬을 보안팀 승인으로 묶으면 개인 로컬 폴더에 복사해 쓰는 문화가 생길 수 있습니다. 읽기 전용, plan-only, 내부 repo 한정처럼 낮은 위험 경로를 열어 두고, 쓰기 권한부터 강하게 막는 편이 낫습니다.

둘째, 스킬을 많이 깔수록 retrieval noise가 늘어납니다. 에이전트가 매번 50개 스킬 중 하나를 고르게 만들면 실패 가능성이 커집니다. 기본 로드 스킬은 작게 유지하고, 작업 라벨이나 repo metadata로 후보를 줄여야 합니다.

셋째, 공식 스킬은 lock-in을 만들 수 있습니다. 벤더가 제공하는 절차는 빠르고 최신이지만, 내부 추상화가 모두 특정 벤더 용어로 굳으면 나중에 다른 클라우드나 다른 CMS로 이동할 때 비용이 커집니다. 핵심 정책은 내부 형식으로 남기고, 벤더 스킬은 adapter처럼 쓰는 편이 좋습니다.

넷째, 에이전트가 스킬을 자동 생성하는 기능은 편하지만 더 위험합니다. 자동 생성 스킬은 초안으로만 두고, 팀 공유 registry에 올리기 전에는 owner review와 canary task를 반드시 거쳐야 합니다.

체크리스트 또는 연습

  • 팀에서 사용하는 agent skill 목록과 설치 위치를 한 곳에서 볼 수 있다.
  • 외부 스킬은 source, pinned ref, owner, allowed tools, review interval을 가진다.
  • 기본 로드되는 스킬은 repo당 10~20개 이하로 제한한다.
  • cloud, deploy, security, data migration 스킬은 allowlist 기반으로만 로드한다.
  • 스킬별 canary task와 forbidden tool call 테스트가 있다.
  • 30일 이상 검증되지 않은 외부 스킬은 stale 후보로 표시한다.
  • PR/receipt에 사용된 skill id와 version이 남는다.

연습으로 현재 사용하는 코딩 에이전트의 skill 폴더를 열고, 스킬 5개를 공식 벤더 / 내부 제작 / 커뮤니티 / 자동 생성으로 분류해 보세요. 각 스킬에 대해 “이 스킬이 잘못되면 어떤 도구를 잘못 호출할 수 있는가”, “누가 업데이트하는가”, “마지막으로 실제 task에서 검증한 날짜가 언제인가"를 적어 보면 바로 우선순위가 나옵니다. 답이 없는 스킬은 제거 대상이 아니라, 먼저 quarantine과 검증 대상입니다.