포터블 플러그인을 맹목적으로 설치하지 마라 — Agent Plugins 1.0이 옮긴 신뢰 경계

Agent Plugins 1.0은 스킬과 MCP를 한 번에 포장하는 열린 표준이다. 포터블해졌다는 말은 어디든 설치해도 안전하다는 뜻이 아니다. 패키징만 표준화했고, 설치·검수·샌드박스·시크릿 정책은 여전히 클라이언트와 조직의 몫이다.

왜 지금 중요한가

2026년 8월 6일 Agent Plugins Specification 1.0.0이 공개됐고, 8월 12일 GitHub는 VS Code·Copilot CLI·Copilot SDK·Copilot 앱에서 1.0 지원을 GA로 올렸다. 런치 시점의 호환 클라이언트 목록에는 Cursor, ChatGPT/Codex, Kiro, VS Code도 포함된다. AWS·Anysphere·Microsoft·OpenAI·Vercel이 스펙을 다듬었고, Google도 같은 날 코어 메인테이너로 합류했다.

이 타이밍이 중요한 이유는 단순하다. 지난 한 해 팀은 “Cursor용 스킬”, “Copilot용 플러그인”, “각자 mcp.json”을 따로 관리해 왔다. 이제 같은 skills/ + mcp.json 묶음을 여러 에이전트 클라이언트에 올릴 수 있다. 배포 비용은 줄고, 잘못된 플러그인의 확산 반경은 커진다.

무엇이 바뀌었고, 무엇이 그대로인가

Cursor는 이중 트랙이다. Agent Plugins(루트 plugin.json, 스킬+MCP)와 Cursor Plugins(.cursor-plugin/plugin.json, rules·agents·commands·hooks·variables까지)를 함께 지원한다. “플러그인”이라는 같은 단어가 두 포맷을 가리킬 수 있으니, 팀 문서에 포맷을 적어 두는 편이 안전하다.

Copilot 쪽은 기존 플러그인을 강제 마이그레이션하지 않는다. 1.0을 타깃하려면 $schema를 plugin.json에 넣고, Copilot 전용 파일은 com.github.copilot/으로 옮기라는 가이드가 있다. Business/Enterprise는 이미 쓰던 enabledPlugins / extraKnownMarketplaces / strictKnownMarketplaces가 Agent Plugins 1.0에도 그대로 적용된다. 별도 Agent Plugins 정책은 없다 — 기존 플러그인 통제가 곧 1.0 통제다.

최소 플러그인 + Copilot 엔터프라이즈 설정 예시

최소 유효 플러그인:

hello-plugin/
├── plugin.json
└── skills/
    └── greet/
        └── SKILL.md

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "hello-plugin",
  "version": "1.0.0",
  "description": "Portable greeting skill for Agent Plugins 1.0 clients"
}

---
name: greet
description: Greet the user and offer concrete next steps.
---

사용자를 짧게 인사한 뒤, 저장소 컨텍스트를 보고 다음에 할 일을 한 가지 제안한다.
비밀·토큰·내부 URL을 출력하지 않는다.

MCP를 같이 실을 때는 루트 mcp.json에 서버를 선언한다. Google 측 설명대로 엔트리마다 transport type을 명시하고, 한 MCP가 실패해도 스킬 로딩은 독립적으로 유지되는 쪽이 스펙의 의도다.

Copilot Business/Enterprise 기준선 예시 (managed-settings.json 개념):

{
  "enabledPlugins": {
    "hello-plugin@awesome-copilot": true,
    "shadow-exfil@random-market": false
  },
  "extraKnownMarketplaces": [],
  "strictKnownMarketplaces": [],
  "allowedMcpServers": [
    { "serverUrl": "https://mcp.example.com/*" }
  ]
}

strictKnownMarketplaces를 빈 배열로 두면 완전 잠금에 가깝게 동작한다는 GitHub 문서 설명이 있다. 팀 오버라이드에서 enabledPlugins와 extraKnownMarketplaces는 가산(additive) 이므로, 엔터프라이즈 기본값을 느슨하게 두면 팀이 구멍을 더 열 수 있다.

실무에서 바로 할 일

1. 인벤토리: 팀 레포에 흩어진 스킬·MCP 설정을 “포터블 코어” vs “클라이언트 전용”으로 나눈다.
2. 한 개만 포장: 내부용 최소 플러그인 하나를 plugin.json + skills/로 만들고 Cursor와 Copilot(또는 VS Code)에서 각각 로드해 본다.
3. 정책 먼저: Copilot이면 enabledPlugins / strictKnownMarketplaces / MCP allowlist를 플러그인 마켓 개방보다 먼저 고정한다. Cursor면 공식 마켓 vs cursor.directory 커뮤니티 경로를 문서에 구분한다.
4. 실패 모드 테스트: MCP URL을 일부러 깨뜨려 스킬만 남는지, 스킬에 시크릿을 넣었을 때 클라이언트가 어떻게 막는지 확인한다.
5. 소유권: 플러그인 이름·버전·홈페이지·라이선스를 매니페스트에 채우고, 누가 업데이트하는지 CODEOWNERS에 적는다.

시니어 엔지니어 관점

포터블 표준은 “한 번 만들고 여러 곳에”라는 엔지니어링 욕망을 충족한다. 하지만 보안 리뷰 관점에서는 공격면이 곱셈이 된다. 어제까지는 Cursor에만 깔린 수상한 MCP가 오늘은 Copilot CLI 기본 마켓을 타고 온보딩 머신까지 따라올 수 있다.

그래서 기본 자세는 이렇다.

• 마켓플레이스 배지 ≠ 내부 승인.
• 스킬 마크다운은 코드리뷰 대상이다. 프롬프트 인젝션·데이터 유출 지시가 들어간다.
• MCP는 네트워크 경계다. 플러그인 allow와 MCP allow를 한 쌍으로 본다.
• Cursor Plugin(훅/룰이 있는 쪽)과 Agent Plugin(포터블 코어)을 섞어 팔지 말고, 배포 파이프라인을 분리한다.

“표준이 나왔으니 거버넌스는 나중에”는 이번 분기에서 가장 비싼 문장이다.

Cursor에서 쓰기

Cursor 문서 기준으로 Agent Plugins는 Customize/마켓 경로로 설치·관리하고, Cursor Plugins는 .cursor-plugin/plugin.json으로 rules·hooks 같은 IDE 밀착 기능을 담는다. 실무 추천은 단순하다.

• 여러 도구에 공유할 스킬·MCP → Agent Plugins (plugin.json)
• Cursor 에이전트 루프·훅·커맨드까지 → Cursor Plugins (.cursor-plugin/)
• 한 Git 레포에 둘 다 둘 수는 있어도, README에 “어느 매니페스트가 SSOT인지”를 못 박는다.

클라우드 에이전트나 팀 환경을 쓰는 경우, 플러그인이 끌어오는 MCP가 환경 egress allowlist와 충돌하는지를 먼저 본다. 포터블 패키지가 로컬에서는 되고 클라우드에서는 조용히 실패하는 패턴이 흔하다.

막혔던 순간

처음엔 plugin.json만 보고 “이제 끝”이라고 생각했다. 같은 폴더를 Cursor와 Copilot 쪽에서 열어 보니, Copilot 전용 커맨드·훅을 루트에 남겨 둔 채라 포터블 코어와 클라이언트 확장의 경계가 흐려졌다. com.github.copilot/으로 옮기고 나서야 “이 디렉터리는 다른 클라이언트가 무시해도 된다”는 문장이 몸으로 와닿았다. 그다음 막힌 지점은 엔터프라이즈 설정이었다. 플러그인은 막아 두고 MCP URL은 열어 둔 채라, 스킬 없는 채로도 도구 호출 경로가 남아 있었다. allowlist를 쌍으로 맞춘 뒤에야 리뷰 체크리스트가 닫혔다.

FAQ

Agent Plugins 1.0은 MCP를 대체하나?

아니다. MCP 서버 설정을 함께 포장·발견하는 방법일 뿐이다. MCP 프로토콜 자체를 재정의하지 않는다.

기존 Copilot 플러그인을 당장 옮겨야 하나?

GitHub는 기존(비-1.0) 플러그인을 계속 지원하며 강제 마이그레이션은 없다고 명시했다. 새 공유 패키지부터 1.0 레이아웃을 쓰는 편이 비용 대비 효과가 크다.

Cursor Plugin과 Agent Plugin 중 무엇을 고르나?

공유 스킬+MCP만이면 Agent Plugins. Cursor 전용 rules/hooks/commands/variables가 필요하면 Cursor Plugins. 둘 다 필요하면 포터블 코어와 Cursor 확장을 분리해 관리한다.

엔터프라이즈에서 가장 먼저 켤 설정은?

Copilot 기준: strictKnownMarketplaces로 마켓을 잠그고, enabledPlugins로 허용 목록을 명시하며, MCP allowlist를 같이 검토한다. “일단 Awesome 마켓 전체 개방”은 기본값으로 두지 않는 편이 낫다.

앞으로의 전망

앞으로 몇 달은 “누가 스펙을 지원하느냐”보다 누가 포터블 악성/부주의 플러그인의 확산을 먼저 막느냐의 경쟁이 될 가능성이 크다. 클라이언트마다 마켓 리뷰 깊이가 다르고, 스펙은 그 차이를 일부러 표준화하지 않았다. 우리 팀의 기본 전략은 변하지 않는다. 포장 표준은 채택하되, 설치 기본값은 닫아 두고, 승인된 플러그인만 파이프라인으로 공급한다.

참고 자료

• Introducing Agent Plugins (Vercel)
• Agent Plugins 1.0.0 changelog (Vercel)
• Agent Plugins 1.0 in VS Code, Copilot CLI, and the Copilot app (GitHub Changelog, 2026-08-12)
• agentplugins/agent-plugins-spec
• Google Developers Blog — Agent Plugins
• Cursor Docs — Plugins
• GitHub Docs — Configure enterprise managed settings