Agent Plugins

https://vercel.com/blog/introducing-agent-plugins

Agent Skills와 MCP 서버를 배포 가능한 플러그인으로 묶는 공통 포맷

오늘 Agent Plugins 1.0.0이 공개되었습니다. Agent Plugins는 AI 에이전트를 확장하는 플러그인을 위한, 특정 벤더에 종속되지 않는 개방형 표준입니다.

Agent Skills는 AI 에이전트가 재사용할 수 있는 지침과 리소스를 제공합니다. MCP 서버는 에이전트를 도구와 서비스에 연결해 줍니다. 둘 다 여러 클라이언트에서 재사용할 수 있지만, 클라이언트마다 패키징하고 찾아내는 방식이 제각각인 경우가 많습니다.

Agent Plugins는 호환 클라이언트에 공통 포맷을 제공합니다. plugin.json 매니페스트와 구성 요소별 고정 위치를 갖춘 디렉터리가 그것입니다. 이 포맷은 의도적으로 작고 구현하기 쉽게 설계되었으며, 설치, 배포, 정책, 사용자 경험, 클라이언트 고유 기능은 각 클라이언트의 몫으로 남겨 둡니다.

이식 가능한 부분을 하나의 패키지로

확장 기능을 만드는 사람은 같은 구성 요소를 여러 클라이언트 포맷에 맞춰 고쳐 담는 일이 잦습니다. 바탕이 되는 Skill이나 MCP 서버는 동일한데도, 클라이언트마다 기대하는 최상위 메타데이터, 탐색 경로, MCP 설정이 다르기 때문입니다.

Agent Plugins는 이렇게 공유되는 구성 요소에 예측 가능하고 구조화된 자리 하나를 마련해 줍니다.

my-plugin/
├── plugin.json
├── skills/
│   └── summarize/
│       ├── SKILL.md
│       ├── scripts/
│       └── references/
├── mcp.json
└── com.example.client/

최소한의 JSON 매니페스트(plugin.json)로 명세 버전을 밝히고 플러그인 이름을 지정합니다.

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "my-plugin"
}

매니페스트에 반드시 있어야 하는 필드는 이 두 개뿐이고, 계약의 나머지 부분은 디렉터리의 파일 구조 자체로 표현됩니다. 재사용 가능한 구성 요소를 클라이언트마다 다시 패키징해야 할 이유는 없어야 하므로, 이 포맷은 클라이언트가 내부 구성 요소를 찾아 로드하는 데 필요한 것만 규정합니다.

호환되는 클라이언트는 모두 플러그인 루트에서 plugin.json을 확인합니다. Skills를 지원하는 클라이언트는 skills/ 아래에서 스킬을 찾고, MCP 서버를 지원하는 클라이언트는 mcp.json에서 설정을 읽습니다. 클라이언트는 두 구성 요소 유형 중 하나만 지원해도 되고 둘 다 지원해도 됩니다. 클라이언트가 매니페스트를 검증한 뒤에는 구성 요소를 각각 독립적으로 검증하므로, 한 구성 요소가 잘못되었다고 해서 무관한 다른 구성 요소까지 비활성화되지는 않습니다.

플러그인 작성자 입장에서는 같은 구성 요소를 두고 신경 써야 할 클라이언트별 관례가 줄어듭니다. 클라이언트 구현자 입장에서는 탐색, 검증, 로딩을 다루는 작고 명확한 계약이 명세로 정의됩니다.

의도적으로 작게

Agent Plugins는 플러그인의 이식 가능한 계약만 정의하고, 클라이언트의 동작은 각 클라이언트에 맡깁니다.

버전 1은 이 계약을 Agent Skills와 MCP 서버라는 두 가지 구성 요소 유형에 집중합니다. 둘 다 이미 자체 명세를 갖추고 의미 있는 수준으로 채택되어 있으므로, Agent Plugins가 이를 다시 정의하려 하지 않습니다. Agent Plugins가 제공하는 것은 배포 가능한 플러그인 안에 함께 담긴 구성 요소들을 클라이언트가 어떻게 찾아내는지에 대한 공통 정의입니다.

커맨드, 훅, 에이전트 같은 다른 구성 요소는 클라이언트 영역으로 남습니다. 의미가 수렴하고 이식성에 대한 필요가 실제로 확인되면, 기술 운영 위원회(Technical Steering Committee)가 향후 버전에서 구성 요소 유형 추가를 검토할 수 있습니다.

경계를 작게 유지하면 포맷을 구현하기 쉬워지고, 이식 가능한 영역을 더 넓히기 전에 생태계가 수렴할 여지도 생깁니다.

클라이언트는 유연성을 유지합니다

공유 포맷이 발전하는 동안에도 클라이언트는 자유롭게 혁신할 수 있어야 하므로, Agent Plugins에는 클라이언트 고유의 데이터와 파일을 위한 네임스페이스 기반 확장 메커니즘이 포함되어 있습니다.

이 확장은 이식 가능한 계약 바깥에 머뭅니다. 각 클라이언트가 자기 네임스페이스를 정의하고, 다른 클라이언트는 이를 무시합니다. 덕분에 클라이언트 고유 동작이 공통 포맷으로 새어 들어가거나 공유 구성 요소의 채택을 가로막는 일이 없습니다. 클라이언트 고유 기능은 표준화할 이유와 합의가 생기기 전까지는 그대로 클라이언트 고유 기능으로 남아 있으면 됩니다.

여러 벤더가 함께하는 개방형 프로젝트

이 제안은 Vercel이 처음 시작했고, Amazon Web Services(AWS), Anysphere, GitHub, Microsoft, OpenAI, Vercel의 대표자들이 함께 다듬어 Agent Plugins 1.0.0으로 완성했습니다.

초대 기술 운영 위원회에는 AWS, Cursor, Microsoft, OpenAI, Vercel 소속의 핵심 메인테이너들이 참여합니다.

프로젝트는 개방형 라이선스를 따르며, 메인테이너, 기여 절차, 기술적 의사결정이 모두 공개되어 있습니다. 어느 한 회사의 제품 로드맵이 포맷의 방향을 정하지 않습니다.

Agent Plugins 1.0.0으로 만들어 보세요

명세와 JSON 스키마, 그리고 플러그인 작성자와 클라이언트 구현자를 위한 가이드는 agent-plugins.org에서 볼 수 있습니다. 거버넌스와 기여 절차는 GitHub의 Agent Plugins 명세 저장소에서 관리됩니다.

에이전트 확장 기능을 만든다면 이 명세를 활용해 Skills와 MCP 서버를 이식 가능한 매니페스트 하나로 패키징할 수 있습니다. 에이전트 클라이언트를 만든다면 명세의 적합성 체크리스트에서 Agent Plugins를 찾아 로드하기 위한 최소 요건을 확인할 수 있습니다.

출시 시점에 Agent Plugins를 지원하는 클라이언트는 다음과 같습니다.

ChatGPT와 Codex
Cursor
GitHub Copilot
Kiro
VS Code

플러그인 작성자가 구성 요소를 한 번만 패키징하면, 그 플러그인은 지원 클라이언트 사이를 그대로 옮겨 다닙니다.