Agent Plugins 1.0.0: MCP와 Agent Skills를 한 번에 배포하는 표준이 나온 이유

Agent Plugins 1.0.0은 AI 코딩 에이전트 생태계에서 반복되던 배포 문제를 정리하려는 표준입니다. 핵심은 거창하지 않습니다. Agent Skills, MCP 서버, 스크립트, 레퍼런스를 각 도구마다 다른 포맷으로 다시 포장하지 말고, 하나의 예측 가능한 디렉터리 구조로 묶자는 제안입니다. Google Developers Blog에 따르면 이 스펙은 Amazon, Cursor, Microsoft, OpenAI, Vercel 등이 참여한 Core Maintainers 체계에서 공개됐고, Google도 Core Maintainer로 합류했습니다.

개발팀 입장에서 중요한 포인트는 ‘새로운 에이전트 프레임워크가 하나 더 나왔다’가 아닙니다. 이미 많은 팀은 MCP 서버를 만들고, SKILL.md 같은 지침 파일을 만들고, 특정 IDE나 CLI에 맞춘 설정 파일을 따로 둡니다. 문제는 두 번째 클라이언트로 옮기는 순간 시작됩니다. 기능은 같은데 manifest가 다르고, MCP transport 추론 방식이 다르고, 디렉터리 위치가 다릅니다. 결국 같은 도구를 Cursor용, Claude Code용, Gemini CLI용으로 나눠 관리하게 됩니다. 이 표준은 그 중복을 줄이려는 쪽에 가깝습니다.

Agent Plugins가 해결하려는 실제 문제

AI 에이전트 도구를 운영해 보면 가장 먼저 부딪히는 것은 모델 성능이 아니라 배포 표면적입니다. 예를 들어 사내 리포팅 DB를 조회해서 주간 요약을 만드는 기능을 만든다고 합시다. Agent Skill에는 ‘어떤 지표를 요약할지’가 들어가고, MCP 서버에는 ‘DB를 어떻게 조회할지’가 들어갑니다. 여기에 샘플 SQL, 운영 정책, 금지 액션, 출력 포맷까지 붙습니다.

한 클라이언트에서는 잘 동작합니다. 하지만 다른 클라이언트로 옮기면 문제가 생깁니다. 어떤 쪽은 mcp.json을 루트에 기대하고, 어떤 쪽은 설정을 inline으로 넣으라고 하고, 어떤 쪽은 stdio와 HTTP transport를 자동 추론합니다. 기능이 달라서가 아니라 포장 방식이 달라서 유지보수 비용이 늘어납니다.

Agent Plugins 1.0.0은 이 지점을 단순하게 자릅니다. plugin.json은 최소 manifest 역할만 하고, skills/에는 Agent Skills를, mcp.json에는 MCP 서버 선언을 둡니다. client-specific 확장이 필요하면 reverse-domain 디렉터리, 예를 들어 com.example.client/ 같은 공간에 넣습니다. 표준 코어와 클라이언트별 혁신을 섞지 않겠다는 설계입니다.

디렉터리 표준이 중요한 이유

표준의 힘은 기능 수보다 예측 가능성에서 나옵니다. Agent Plugins 예시는 대략 이런 구조를 가집니다.

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

이 구조에서 클라이언트는 ‘어디를 봐야 하는지’를 추측하지 않습니다. skills/가 있으면 스킬을 읽고, mcp.json이 있으면 서버 선언을 읽습니다. MCP 서버 하나가 실패해도 스킬 전체를 내리지 않는 식으로 컴포넌트 실패를 분리할 수도 있습니다.

실무에서 이 차이는 큽니다. 에이전트 도구는 대부분 작은 파일 조합입니다. 지침, 스크립트, 샘플, 테스트 데이터, 권한 설명이 함께 움직여야 합니다. 위치가 매번 바뀌면 설치 문서가 길어지고, 사용자 실수도 늘어납니다. 반대로 위치가 고정되면 CI에서 검사하기 쉬워지고, 보안 스캐너도 파일을 찾기 쉬워집니다.

MCP와 Agent Skills의 역할 분리

Agent Plugins는 MCP나 Skills를 대체하지 않습니다. 이 점이 중요합니다. MCP는 도구와 서비스 연결 계약입니다. Agent Skills는 에이전트가 특정 일을 잘하도록 만드는 지침과 리소스 묶음입니다. Agent Plugins는 이 둘을 함께 운반하는 포장 형식입니다.

따라서 단일 MCP 서버만 배포한다면 플러그인이 과할 수 있습니다. 단일 Skill 하나만 공유한다면 Skill 폴더만으로 충분합니다. 플러그인이 의미 있는 경우는 ‘같이 설치되어야 가치가 있는 구성요소’가 있을 때입니다. 예를 들어 BigQuery 조회 MCP 서버와 데이터 분석 Skill, 비용 제한 정책 문서, 샘플 쿼리가 한 세트라면 플러그인 형태가 맞습니다.

이 분리는 운영 정책에도 영향을 줍니다. 실행 권한은 MCP 계층에서 다루고, 작업 방식은 Skill에서 다루고, 배포와 발견은 Plugin이나 Catalog 계층에서 다루는 식입니다. 한 파일에 모든 것을 넣는 방식보다 검토 포인트가 선명해집니다.

지금 당장 도입할 때 봐야 할 기준

Agent Plugins를 바로 도입할지는 팀 상황에 따라 다릅니다. 다만 다음 조건 중 2개 이상이면 검토할 만합니다.

• 같은 에이전트 도구를 여러 IDE, CLI, 내부 플랫폼에서 써야 한다.
• Skill과 MCP 서버가 항상 함께 배포된다.
• 고객사별로 같은 기능을 조금씩 포크해서 관리하고 있다.
• 보안 리뷰나 설치 검증을 자동화하고 싶다.
• 에이전트 기능을 사내 카탈로그처럼 관리하려 한다.

반대로 한 팀이 한 클라이언트에서만 쓰는 단순 자동화라면 지금은 기존 구조가 더 낫습니다. 표준을 도입하면 얻는 이익보다 문서화와 검증 비용이 더 클 수 있습니다.

보안과 배포는 아직 별도 과제

Google 글에서도 명확히 말하는 부분이 있습니다. Agent Plugins v1은 package format입니다. 설치 메커니즘, 배포 프로토콜, permission model, sandboxing, provenance verification까지 정의하지 않습니다. 이건 빠진 기능이라기보다 의도적인 경계에 가깝습니다. IDE, CLI, 엔터프라이즈 플랫폼은 사용자 승인 UX와 권한 모델이 다르기 때문입니다.

그래서 플러그인을 표준화해도 보안 검토가 끝나는 것은 아닙니다. 오히려 더 명확해집니다. plugin.json은 무엇을 싣는지 알려주고, mcp.json은 어떤 도구가 연결되는지 보여주고, skills/는 에이전트가 어떤 행동 지침을 받는지 드러냅니다. 이 상태에서 조직은 별도 정책으로 출처 확인, 정적 검사, 권한 제한, 실행 로그를 붙여야 합니다.

개발팀이 준비할 실행 액션

첫 번째 액션은 기존 에이전트 자산을 분류하는 것입니다. 단순 프롬프트인지, Skill인지, MCP 서버인지, 스크립트 묶음인지 구분해야 합니다. 두 번째는 함께 배포되어야 하는 단위를 찾는 것입니다. 세 번째는 transport와 권한 요구사항을 문서화하는 것입니다. 특히 stdio, Streamable HTTP, legacy HTTP+SSE 중 무엇을 쓰는지 명시해야 나중에 클라이언트 추론 오류를 줄일 수 있습니다.

마지막으로 작은 플러그인 하나를 만들어 보는 편이 좋습니다. 처음부터 전사 표준으로 밀지 말고, 내부 리포트 생성이나 배포 체크리스트처럼 위험이 낮고 반복성이 높은 도구를 대상으로 삼으세요. 거기서 설치 실패, 권한 안내, 문서 위치, 클라이언트별 확장 필요성을 확인하면 됩니다.

도입 전 체크리스트

• 현재 팀의 Skill, MCP 서버, 스크립트 자산 목록을 만든다.
• 같은 기능을 여러 클라이언트용으로 중복 관리하는지 확인한다.
• 플러그인으로 묶을 후보를 ‘같이 설치되어야 의미 있는 단위’로 제한한다.
• plugin.json, skills/, mcp.json 위치를 CI에서 검사한다.
• MCP transport를 명시하고 자동 추론에 기대지 않는다.
• 클라이언트별 확장은 reverse-domain 디렉터리에 둔다.
• 설치, 권한, sandbox, provenance 검증은 별도 정책으로 설계한다.
• 첫 도입은 저위험 내부 도구 하나로 시작한다.