에이전트에 붙일 스킬을 하나 만들면, 도구마다 폴더 구조가 달라 같은 걸 여러 번 포장해야 했습니다. 이번 주 공개된 표준은 그 포장 규격을 하나로 맞췄죠.
Vercel이 제안하고 AWS, Cursor를 만든 Anysphere, GitHub, Microsoft, OpenAI가 함께 다듬은 Agent Plugins 1.0.0이 공개됐습니다. 스킬(Agent Skills)과 MCP 서버를 하나의 디렉터리 규격으로 묶어, 호환되는 클라이언트라면 어디서든 같은 방식으로 찾아 읽게 하자는 표준이죠. ChatGPT와 Codex, Cursor, GitHub Copilot, Kiro, VS Code가 공개 시점부터 지원합니다.
출처:
- Agent Plugins – Agent Plugins 명세
- Introducing Agent Plugins – Vercel
폴더 하나에 매니페스트 한 개
규격 자체는 단순합니다. 플러그인은 디렉터리 하나고, 루트에 plugin.json이 놓이죠. 스킬은 skills/ 아래에, MCP 서버 설정은 mcp.json에 들어갑니다.
매니페스트에 반드시 있어야 하는 값은 두 개뿐입니다. 어떤 명세 버전을 따르는지, 그리고 플러그인 이름이 무엇인지. 나머지 약속은 폴더 구조 자체가 대신하죠.
클라이언트는 루트의 plugin.json을 먼저 확인합니다. 스킬을 지원하면 skills/를, MCP를 지원하면 mcp.json을 읽죠. 둘 중 하나만 지원해도 됩니다. 구성 요소를 각각 따로 검증하기 때문에, 하나가 잘못돼도 나머지까지 같이 멈추지 않는 구조.
일부러 작게 만들었다
이 표준이 정의하지 않는 것이 오히려 많습니다. 설치와 배포, 권한, 샌드박싱, 사용자 경험, 마켓플레이스는 전부 클라이언트 몫으로 남겼죠. 커맨드나 훅, 서브에이전트 같은 다른 구성 요소도 1.0에는 들어가지 않았습니다.
클라이언트별 기능은 역도메인 이름을 딴 네임스페이스 폴더에 넣습니다. com.example.client/ 같은 형태죠. 다른 클라이언트는 그 폴더를 그냥 무시합니다. 특정 회사의 기능이 공용 규격 안으로 새어 들어오지 못하게 막는 장치인 셈.
경계를 좁게 그은 건 도입 문턱을 낮추기 위해서입니다. 스킬과 MCP는 이미 각자 명세와 사용자를 갖고 있으니, Agent Plugins는 그 둘을 어떻게 한 묶음으로 찾아낼지만 정하죠.
얇은 표준이라는 반론
모두가 반긴 건 아닙니다. SST 개발자 도구를 만드는 댁스 라드는 매우 반대한다는 입장을 밝히며, 얇은 표준이라 쓸 만한 부분은 결국 클라이언트별 확장으로 빠질 거라고 봤죠. 반대편에는 여러 도구 사이에서 스킬을 들고 다니고 싶었던 개발자들의 환영이 있었습니다.
남겨둔 문제 중 무거운 쪽은 신뢰입니다. 플러그인을 실행해도 되는지 판단하는 일은 여전히 클라이언트 각자의 몫이죠. 올해 초 가짜 Agent Skill이 보안 스캐너를 통과해 2만 6천 개 에이전트에 퍼진 사건이 있었던 터라, 포맷이 통일된다고 이 문제까지 함께 풀리지는 않습니다.
내가 만든 스킬은 어디까지 따라오나
개인 입장에서 이 표준의 값어치는 재사용 범위에 있습니다. 하루를 들여 다듬은 스킬이 지금 쓰는 도구 안에서만 살아 있다면, 도구를 바꾸는 순간 그 시간은 사라지죠. 도구를 여러 개 병행하다 스킬이 흩어져 관리 앱까지 만들게 된 사례를 얼마 전에 다뤘습니다.
표준이 생기면 그 흩어짐의 일부가 정리됩니다. 다만 정리되는 건 어디에 두느냐까지죠. 무엇을 허용하느냐는 여전히 도구마다 다릅니다. 스킬을 옮기기는 쉬워져도, 옮긴 스킬이 같은 권한으로 돌아갈지는 별개의 문제.
경쟁 구도에도 양면이 있습니다. 작은 개발자가 포맷 하나로 주요 에이전트 전부에 닿을 수 있다는 게 한쪽이죠. 이미 사용자를 확보한 소수 클라이언트가 표준의 수혜를 더 크게 가져간다는 게 다른 쪽입니다. 배관은 합의됐고, 그 위에 놓일 마켓플레이스와 신뢰를 두고는 이제 시작인 셈.
참고자료:
답글 남기기