여섯 회사가 폴더 하나에 도장을 찍었어

2026년 8월 6일, 버셀·OpenAI·AWS·커서(Anysphere)·깃허브·마이크로소프트가 같은 날 같은 문서를 가리키며 발표를 냈어. 이름은 Agent Plugins 1.0.0. 한 문장으로 줄이면 이거야. "AI 에이전트한테 새 능력을 붙이는 확장 꾸러미를, 폴더 구조 하나로 통일하자." 폴더 맨 위에 plugin.json을 두고, 그 옆에 skills/ 디렉터리와 mcp.json 파일을 놓으면 끝. 그 폴더를 챗GPT에 넣든, Codex에 넣든, 커서에 넣든, 깃허브 코파일럿에 넣든, VS Code에 넣든, AWS의 Kiro에 넣든 똑같이 읽힌다는 게 이 표준의 전부야.

"그게 뭐가 대단해?"라는 반응이 정상이야. 폴더 규칙 하나 정한 게 무슨 뉴스냐 싶지. 그런데 지난 1년 반 동안 에이전트 도구를 실제로 만들어본 사람들은 이 지점에서 정확히 피를 봤어. 스킬(에이전트한테 절차를 알려주는 SKILL.md 묶음)은 앤스로픽이 만든 포맷을 다들 가져다 썼고, MCP 서버(에이전트를 외부 도구·데이터에 연결하는 규약) 역시 앤스로픽이 2024년 11월에 공개한 걸 업계가 통째로 받아들였어. 문제는 그 둘을 한 덩어리로 배포하는 방법이 클라이언트마다 다 달랐다는 거야. 커서에 넣으려면 .cursor-plugin/plugin.json, 클로드 코드에 넣으려면 .claude-plugin/plugin.json, 제미나이 CLI에 넣으려면 또 다른 확장 파일. 스킬 내용은 똑같은데 포장지만 여섯 번 다시 만들어야 했던 거지.

Agent Plugins가 손대는 건 딱 그 포장지야. MCP를 대체하는 게 아니고, 스킬 포맷을 새로 만드는 것도 아니야. 규격 원문 7.1절은 "Agent Skills는 Agent Skills 명세를 따라야 한다(MUST)"고 못 박고, 7.2절은 "MCP 명세가 MCP의 와이어 동작과 생명주기 의미론을 정의한다"고 명시해. Agent Plugins가 정의하는 건 그 둘이 어디에 놓여야 발견되는지, 그리고 클라이언트가 그걸 어떻게 로딩해야 하는지뿐이야. npm으로 치면 자바스크립트 언어를 바꾼 게 아니라 package.json을 정한 셈이고, 도커로 치면 리눅스를 바꾼 게 아니라 이미지 레이아웃을 정한 셈이지.

그런데 여기서 이 뉴스의 진짜 이상한 점이 보여. 스킬 포맷과 MCP를 만든 앤스로픽이 이 여섯 곳 명단에 없어. 구글도 없고. 저장소의 MAINTAINERS.md를 직접 열어보면 기술운영위원회(TSC) 코어 메인테이너는 정확히 다섯 명이야. Clare Liguori(아마존), Roshan Sadanani(커서), Harald Kirschner(마이크로소프트), Gav Verma(OpenAI), Jonathan Hefner(버셀). 리드 코어 메인테이너는 버셀의 Jonathan Hefner. 앤스로픽이 깔아놓은 두 장의 레일 위에, 앤스로픽 없이 화차를 얹은 모양새인 거야. 이 기사에서 제일 오래 붙잡고 볼 대목이 바로 여기야.

제안자는 버셀, 도장 찍은 건 다섯 — 이 조합이 낯선 이유

먼저 버셀 얘기부터. 버셀은 Next.js를 만들고 프런트엔드 배포 플랫폼을 파는 회사야. 규모로 보면 이 명단에서 제일 작아. AWS도 마이크로소프트도 OpenAI도 아닌 버셀이 제안을 주도했다는 게 처음엔 좀 의아하게 들려. 그런데 버셀은 원래 이런 자리를 잘 잡는 회사였어. 프레임워크와 배포 사이의 접착제, SDK와 런타임 사이의 접착제 — 남들이 각자 자기 물건 만드느라 신경 못 쓰는 "사이"를 표준으로 만들어서 그 위에 자기 제품을 얹는 게 버셀의 오래된 패턴이거든. AI SDK가 그랬고, 이번 Agent Plugins도 정확히 같은 자리야.

두 번째 특징은 덩치 큰 회사들이 이번엔 순순히 남의 제안에 올라탔다는 거야. 보통 이런 표준은 제일 큰 회사가 자기 포맷을 던지고 나머지가 따라오는 식인데, 이번엔 반대로 갔어. AWS 오픈소스 블로그(Libby Clark 수석 오픈소스 전략가, James Ward 수석 개발자 애드보킷 공동 집필, 8월 6일자)는 자사를 "창립 멤버"라고만 쓰고, 거버넌스가 "어느 한 회사의 제품 로드맵이 포맷의 방향을 좌우하지 않도록" 설계됐다는 점을 강조해. 실제로 기술 헌장은 **"모든 거버넌스 역할은 조직이 아니라 개인이 보유한다", "특정 회사를 위해 예약된 자리는 없다", "어떤 단일 벤더도 코어 메인테이너 과반을 점할 수 없다"**를 명문으로 박아놨어.

세 번째는 커서의 위치야. 커서를 만드는 Anysphere는 2026년 2월 17일 커서 2.5에서 자체 플러그인 시스템을 이미 출시했어. 스킬·서브에이전트·MCP 서버·훅·룰을 한 번에 설치하는 포맷이었고, 마켓플레이스에는 Amplitude·AWS·Figma·Linear·Stripe 같은 초기 파트너가 붙었지. 자기 포맷이 굴러가고 있는 회사가 6개월도 안 돼서 공용 규격에 합류한 셈이야. 커서 문서를 보면 지금은 두 포맷이 공존해. 루트 plugin.json이면 이식 가능한 Agent Plugin, .cursor-plugin/plugin.json이면 커서 전용 플러그인. 후자는 룰·에이전트·커맨드·훅까지 되지만 전자는 스킬과 MCP 서버만 돼.

네 번째는 명단에 깃허브와 마이크로소프트가 따로 들어가 있다는 점이야. 둘은 같은 회사인데 발표문에서는 따로 세어져. 이유는 단순해. 깃허브 코파일럿(코파일럿 CLI·앱 포함)과 VS Code가 서로 다른 클라이언트로 이 규격을 구현하기 때문이야. VS Code 문서를 보면 chat.plugins.enabled 설정으로 기능을 켜고 끄고, 확장 뷰에서 @agentPlugins 필터로 찾거나 "Chat: Install Plugin From Source"로 깃 저장소에서 바로 설치할 수 있어. 조직 단위로 이 설정을 관리할 수 있게 해둔 것도 눈여겨볼 만해.

마지막으로 AWS. AWS는 Kiro의 "Kiro Powers"가 규격을 네이티브로 지원하고, Agent Toolkit for AWS를 출시 시점에 호환시켰어. 이 툴킷은 Lambda·S3·DynamoDB·CDK 같은 서비스를 아우르는 30개 이상의 스킬을 묶어놓은 물건이야. AWS 입장에서 이건 자선이 아니야. 개발자가 어떤 에이전트를 쓰든 "AWS를 쓰는 방법"이 그 에이전트 안에 기본으로 들어가 있게 만드는 게 목표거든. 포맷이 하나면 배포 비용은 6분의 1이 되고, 그 절약분은 전부 배포 범위로 바뀌어.

plugin.json 안에는 생각보다 적은 게 들어있어

규격을 실제로 열어보면 제일 놀라운 건 필수 필드가 딱 두 개라는 거야. $schema와 name. 끝. $schema는 https://agent-plugins.org/schemas/1.0.0/plugin.schema.json이라는 정해진 문자열이어야 하고, 이 값이 곧 그 플러그인이 어느 버전의 규격을 겨냥하는지를 선언해. name은 1~64자, 소문자 알파벳·숫자·하이픈·마침표만, 첫 글자와 끝 글자는 영숫자, 하이픈이나 마침표가 연달아 오면 안 돼. my-plugin이나 acme.tools는 되고 My-Plugin, -start, has--double은 안 돼.

나머지는 전부 선택이야. 다만 스키마가 additionalProperties: false로 닫혀 있다는 게 핵심이야. 규격에 없는 최상위 필드를 마음대로 넣을 수 없어. 클라이언트별 실험 데이터는 반드시 extensions 안에 com.example.client 같은 역방향 도메인 키로 넣어야 해. 설계 결정 섹션에 이유가 적혀 있는데, 닫힌 스키마여야 오타 검출과 스키마 기반 자동완성이 가능하고, 클라이언트가 최상위 이름을 선점하는 걸 막을 수 있다는 거야. 다만 알 수 없는 최상위 필드가 발견돼도 플러그인 전체를 거부하지는 않고 보고 후 무시해.

항목 값 비고
필수 필드 $schema, name 하나라도 없으면 플러그인 전체 거부
선택 메타데이터 version, description, author, homepage, repository, license, keywords author는 name/email/url만 허용
클라이언트 확장 extensions 역방향 도메인 키(com.example.client), 내용은 규격이 관여 안 함
스킬 위치 skills/ 하위 1단계 디렉터리 SKILL.md 있는 폴더만, 하위 재귀 탐색 금지
MCP 위치 mcp.json $schema + mcpServers 둘 다 필수
MCP 전송 방식 stdio, streamable-http, sse(레거시) 클라이언트는 둘 중 하나만 지원해도 적합
예약 환경변수 PLUGIN_ROOT, PLUGIN_DATA 플러그인이 env에 직접 넣으면 무효
라이선스 규격 문서 CC BY 4.0 / 스키마·코드 Apache 2.0 저장소 LICENSE.md 기준

발견 규칙도 유별나게 빡빡해. plugin.json은 위치를 바꿀 수 없고, 컴포넌트 위치도 매니페스트로 재정의할 수 없어. 스킬은 무조건 skills/ 바로 아래 한 단계 디렉터리에서만 찾고, 더 깊이 재귀 탐색하면 안 돼(MUST NOT). 대신 없어도 에러가 아니야. skills/가 아예 없으면 그냥 스킬 없는 플러그인이고, mcp.json이 파일이 아니라 디렉터리로 잡히면 그 컴포넌트 타입만 무효 처리하고 나머지는 계속 로딩해. MCP 서버 하나가 안 뜬다고 플러그인 전체가 죽지 않는다는 원칙이 11.3절과 설계 결정 마지막 항목에 명시돼 있어.

보안 쪽은 경로 봉쇄가 전부야. 플러그인이 제공하는 파일 경로는 심볼릭 링크를 다 풀고 나서도 플러그인 루트 안에 있어야 하고, 벗어나면 클라이언트가 거부해야 해. command가 ../bin/server면 무효, ./bin/server는 유효. 실행 시점 환경변수는 PLUGIN_ROOT(플러그인 루트 절대경로)와 PLUGIN_DATA(클라이언트가 관리하는 영속 데이터 디렉터리) 둘을 클라이언트가 반드시 주입하고, args·env 값·cwd에서 ${PLUGIN_ROOT}·${PLUGIN_DATA}를 한 번만, 재귀 없이 치환해. 그리고 규격은 대놓고 이렇게 써놨어. "설정된 env 값은 눈에 보이는 패키지 데이터이지 이식 가능한 비밀 관리 수단이 아니다. 플러그인은 자격증명이나 비밀을 env에 넣으면 안 된다."

여기서 1.0.0의 진짜 한계가 드러나. FUTURE_CONSIDERATIONS.md가 정직하게 나열해놨는데, 1.0.0에는 신뢰 모델도, 권한 시스템도, 샌드박싱 요구사항도 없어. 서명·출처 검증도 없고, 비밀 주입 방식도 없고, 조직용 허용/차단 정책도 없고, 설치·활성화 감사 이벤트 스키마도 없고, 플러그인 간 의존성 선언도 없고, 표준 검증 도구도 없어. VS Code 문서가 "플러그인은 당신 컴퓨터에서 코드를 실행하는 훅과 MCP 서버를 포함할 수 있으니 설치 전에 검토하라"고 굵게 경고하는 이유가 이거야. 포맷은 통일됐는데 누구를 믿을지는 아직 각자 알아서 상태인 거지.

각자 뭘 챙겼는지 계산해보면

OpenAI가 챙긴 건 배포 채널이야. OpenAI 개발자 문서를 보면 플러그인을 "챗GPT와 Codex에서 발견하고, 설치하고, 공유하고, 게시하는 패키지"로 정의하고, 두 제품이 하나의 플러그인 디렉터리를 공유한다고 밝혀. 즉 OpenAI는 소비자용 챗GPT와 개발자용 Codex를 같은 확장 생태계로 묶으려는 거고, 그 생태계에 들어올 물건을 남들(커서·VS Code·Kiro)이 만들어 놓은 것까지 그대로 흡수할 수 있게 된 거야. 2023년 챗GPT 플러그인이 실패했던 걸 생각하면, 이번엔 자기 포맷을 강요하지 않고 공용 포맷에 올라탔다는 게 전략 변화의 핵심이야.

마이크로소프트와 깃허브가 챙긴 건 기업 통제권이야. VS Code는 chat.plugins.enabled를 조직 정책으로 관리할 수 있게 해뒀고, 코파일럿 CLI에 설치된 플러그인을 자동으로 인식해. 엔터프라이즈 IT가 "우리 회사 개발자들이 쓰는 에이전트 확장"을 한 곳에서 통제하려면 포맷이 하나여야 하거든. 규격 자체에는 조직 정책이 없지만, 포맷이 통일되면 그 위에 정책 계층을 얹는 건 각 벤더의 몫이 되고 — 그건 마이크로소프트가 20년 넘게 제일 잘해온 일이야.

AWS는 유통을 챙겼어. Agent Toolkit for AWS의 30개 이상 스킬은 결국 "AWS를 올바르게 쓰는 법"을 에이전트 머릿속에 심는 장치야. 서비스 선택, CDK·CloudFormation 같은 IaC, 서버리스, 컨테이너, 데이터베이스, 스토리지, 관측성, 과금, SDK 사용, 배포까지 도메인이 촘촘해. 개발자가 커서를 쓰든 Codex를 쓰든 VS Code를 쓰든 같은 플러그인이 들어간다면, AWS는 "어떤 에이전트가 이기는가"에 베팅하지 않아도 돼. 클라우드 회사한테는 이게 가장 싸게 이기는 방법이야.

커서와 버셀은 포지션을 챙겼어. 커서는 자체 포맷의 확장성(룰·에이전트·커맨드·훅)을 유지하면서 이식 가능한 부분만 공용 규격으로 열었어. 마켓플레이스에 오픈소스 코드와 수동 보안 검토를 요구하고, 팀·엔터프라이즈 플랜에는 비공개 팀 마켓플레이스를 붙였지. 즉 포맷은 개방하고 유통은 잠그는 구조야. 버셀은 리드 코어 메인테이너 자리를 가져갔어. 회사 크기로는 제일 작은데 규격의 최종 기술 결정권을 개인 자격으로 쥔 셈이고, 이건 오픈소스 세계에서 시가총액보다 오래 가는 종류의 지분이야.

그럼 플러그인을 만드는 개발자는? 표면적으로는 제일 크게 챙겼어. 여섯 클라이언트에 한 번에 배포할 수 있게 됐으니까. 다만 냉정하게 보면 챙긴 건 작성 비용 절감이지 유통 채널이 아니야. 규격은 레지스트리를 정의하지 않아. 어디에 올려야 사람들이 찾는지는 여전히 커서 마켓플레이스, 챗GPT 플러그인 디렉터리, VS Code 확장 뷰가 각자 정해. 포장 규격이 통일된 다음 벌어지는 싸움은 항상 진열대 싸움이었고, 이번에도 그럴 거야.

표준이 이겼던 순간과 죽었던 순간

성공 사례부터. 언어 서버 프로토콜(LSP)은 마이크로소프트가 2016년에 공개했어. 그전까지 "N개 에디터 × M개 언어" 조합마다 통합을 따로 만들어야 했던 문제를, 프로토콜 하나로 N+M으로 바꿔놨지. 지금 LSP는 VS Code뿐 아니라 Neovim·Emacs·젯브레인스 계열까지 사실상 업계 기본이야. LSP가 이긴 이유는 명확해. 범위가 좁았고(에디터-언어 도구 사이의 통신만), 레퍼런스 구현이 있었고, 제안한 회사가 자기 주력 제품에 먼저 넣어서 증명했어. Agent Plugins의 구조가 이것과 상당히 닮았어 — 좁은 범위(스킬과 MCP만), 여섯 클라이언트의 동시 출시, 공개 스키마.

두 번째 성공 사례는 OpenTelemetry야. 2019년, 구글 계열의 OpenCensus와 CNCF 산하 OpenTracing이 합쳐지면서 관측성 계측 표준이 하나로 정리됐어. 두 진영이 이미 각자 사용자를 갖고 있던 상태에서 합병했다는 게 핵심인데, 그래서 초기에는 사양이 방대해지고 언어별 구현 성숙도가 들쭉날쭉했지. 그럼에도 결국 이긴 건 벤더들이 "계측은 표준으로, 경쟁은 백엔드에서" 하기로 합의했기 때문이야. Agent Plugins도 같은 논리를 쓰고 있어. 포장은 공용, 경쟁은 에이전트 품질과 마켓플레이스에서.

브라우저 확장은 절반의 성공이야. 크롬 확장 포맷이 사실상 표준이 되자 파이어폭스가 2015년부터 WebExtensions로 수렴했고, 엣지·오페라도 따라왔어. 확장 개발자는 코드 대부분을 재사용할 수 있게 됐지. 그런데 여기엔 함정이 있었어. 표준이 한 회사의 구현을 따라간 결과, 그 회사가 포맷을 바꾸면 나머지가 끌려갔다. 매니페스트 V3 전환에서 그 비용이 그대로 드러났지. Agent Plugins가 개인 자격 메인테이너·벤더 과반 금지를 헌장에 못 박은 건 이 학습의 결과로 읽혀.

실패 사례는 더 교훈적이야. 챗GPT 플러그인이 대표적이야. 2023년 3월 OpenAI가 열었고, 1년 뒤 GPTs와 Actions로 대체되며 사실상 정리됐어. 실패 이유는 포맷이 나빠서가 아니라 단일 벤더 유통 채널에 묶여 있었고, 사용자가 플러그인을 켜고 끄는 경험이 번거로웠고, 개발자가 얻는 수익이 없었기 때문이야. 더 오래된 사례로는 WAP이 있어. 1999년 통신사 연합이 만든 모바일 웹 규격인데, 진짜 웹이 휴대폰에 들어오자마자 사라졌지. 사용자가 원하는 것보다 사업자가 통제하기 편한 걸 표준화하면 그렇게 돼. PWA를 앱스토어처럼 유통하려던 여러 시도, 2007년 구글 주도의 OpenSocial도 비슷한 길을 갔어.

그래서 Agent Plugins가 성공할 조건을 구체적으로 적어보면 이렇게 돼. ① 1.0.0에 없는 신뢰 모델을 1.x에서 빨리 채울 것 — 서명·출처 검증·권한 선언이 없으면 기업은 사내 배포를 막고, 그러면 진짜 물량이 안 들어와. ② 레지스트리 파편화를 방치하지 말 것 — 포맷은 하나인데 진열대가 여섯 개면 개발자 체감 이득은 절반으로 깎여. ③ v1이 빼둔 훅·커맨드·서브에이전트를 언제 어떻게 넣을지 로드맵을 낼 것 — 지금은 이 부분이 전부 클라이언트 전용 확장으로 빠져 있어서, 실제 유용한 플러그인일수록 이식성이 떨어지는 역설이 생겨. ④ 앤스로픽·구글을 끌어들일 것. 이건 다음 섹션 주제야.

명단에 없는 두 회사가 이 표준의 운명을 쥐고 있어

앤스로픽이 빠진 게 왜 이상하냐면, 이 표준이 포장하는 내용물 두 개가 다 앤스로픽 것이기 때문이야. MCP는 앤스로픽이 2024년 11월에 공개해서 업계 표준이 됐고, Agent Skills의 SKILL.md 포맷도 앤스로픽에서 나와 지금은 agentskills.io에서 별도 규격으로 관리돼(레퍼런스 예제 저장소는 여전히 github.com/anthropics/skills야). 즉 Agent Plugins는 앤스로픽이 만든 두 레일 위에 얹힌 포장 계층인데, 정작 레일 주인은 TSC에 자리가 없어. 클로드 코드는 여섯 개 출시 클라이언트 명단에도 없고, 자체 포맷인 .claude-plugin/plugin.json을 계속 쓰고 있어.

이걸 어떻게 읽어야 할까. 두 가지 해석이 가능해. 관대한 해석은 "앤스로픽은 이미 MCP와 스킬이라는 상위 레이어를 갖고 있으니 포장 계층은 남들이 알아서 하도록 뒀다"는 거야. 실제로 앤스로픽은 이 표준을 거부한다고 밝힌 적이 없어. 냉정한 해석은 "패키징을 쥐면 유통과 기본값을 쥔다"는 거지. 어떤 폴더 구조가 표준이 되느냐는 곧 어떤 마켓플레이스가 기본값이 되느냐로 이어지고, 앤스로픽 입장에서는 자기가 만든 레일의 상업적 과실을 다섯 회사가 나눠 갖는 구도로 보일 수 있어. 어느 쪽이 맞는지는 앤스로픽이 루트 plugin.json을 읽어주기 시작하는지로 판가름 날 거야.

구글의 부재는 성격이 좀 달라. 제미나이 CLI는 이미 자체 확장 포맷을 갖고 있고, 프롬프트·MCP 서버·커스텀 커맨드·테마·훅·서브에이전트·에이전트 스킬까지 한 번에 묶어. 기능 범위로 보면 Agent Plugins 1.0.0보다 넓어. 갤러리와 gemini extensions install 같은 설치 경로도 이미 굴러가고 있고. 구글이 지금 공용 규격에 합류하면 자기 확장 생태계의 넓은 기능 집합을 좁은 공통분모에 맞춰야 하는데, 그 교환이 지금 시점에 유리하다고 판단할 이유가 약해. 다만 반대로, 엔터프라이즈 고객이 "표준 안 따르는 도구는 안 산다"고 말하기 시작하면 계산은 하룻밤에 바뀌어.

메타와 딥시크는 또 다른 축이야. 메타는 8월 5~6일 사이 첫 코딩 에이전트 Muse Code를 공개했어. 터미널 기반이고, 여러 서브에이전트를 격리 환경에서 병렬로 굴려 대형 저장소를 다루는 걸 내세웠지. 딥시크는 같은 주에 Harness를 비공개 베타로 돌리기 시작했고, "모델 + 하네스 = 에이전트"라는 내부 명제를 공개적으로 밀고 있어. 이 신규 진입자들한테 Agent Plugins는 사실 선물이야. 생태계를 처음부터 만들 필요 없이 규격을 구현하기만 하면 남들이 만든 플러그인을 그대로 흡수할 수 있거든. 표준의 최대 수혜자는 종종 표준을 만든 회사가 아니라 늦게 들어온 회사야.

카운터 플레이의 형태는 대략 세 가지로 갈릴 거야. 첫째, 포용 후 확장 — 규격을 지원하되 자기 전용 확장(com.vendor.client)에 진짜 기능을 몰아넣어 이식성을 형식적으로만 남기는 방식. 커서가 이미 그 경계에 서 있어. 둘째, 상위 레이어로 회피 — 패키징 대신 레지스트리·신뢰·결제 계층을 선점해서 포맷 표준화를 무의미하게 만드는 방식. 셋째, 정면 대응 — 앤스로픽이 자기 플러그인 포맷을 별도 거버넌스로 개방하고 MCP의 권위를 등에 업는 방식. 셋 중 뭐가 나오든, 8월 6일 이후 이 시장의 축은 "모델 성능"에서 "확장 생태계"로 한 칸 옮겨갔어.

그래서 뭐가 달라지는데

플러그인을 만드는 개발자한테는 당장 오늘부터 달라져. 지금까지 스킬 하나 배포하려면 클라이언트별 설치 안내를 네댓 개 써야 했는데, 이제 루트에 plugin.json 하나 두고 skills/와 mcp.json을 규격 위치에 놓으면 끝이야. 주의할 건 세 가지. 스키마가 닫혀 있으니 임의 필드를 넣지 말 것, 스킬은 skills/ 바로 아래 한 단계에만 놓을 것(더 깊이 넣으면 안 찾아줘), 그리고 env에 API 키를 절대 넣지 말 것. 마지막 건 규격이 명시적으로 금지한 항목이야.

기업 의사결정자한테는 좋은 소식 반, 숙제 반이야. 좋은 소식은 사내 표준 스킬(코드 리뷰 규칙, 배포 런북, 보안 체크리스트)을 한 번 만들어 팀마다 다른 에이전트에 배포할 수 있게 됐다는 거고, 숙제는 1.0.0에 권한·샌드박싱·서명·감사 로그가 전부 없다는 거야. 플러그인은 당신 회사 노트북에서 코드를 실행해. 그러니 사내 도입 전에 최소한 이건 정해둬야 해. 어떤 출처의 플러그인만 허용할지, 설치 승인은 누가 하는지, MCP 서버가 외부로 뭘 보내는지. VS Code의 chat.plugins.enabled 조직 관리나 커서의 비공개 팀 마켓플레이스가 당분간 현실적인 통제 지점이야.

투자자한테는 밸류에이션 논리가 한 칸 바뀌는 사건이야. 확장 포맷이 회사별 해자였다면 이제 그 해자는 얕아졌어. 대신 가치가 몰리는 곳은 세 군데로 재배치돼. 레지스트리와 큐레이션(누가 진열대를 갖는가), 신뢰와 컴플라이언스(서명·감사·정책을 누가 파는가), 그리고 에이전트 실행 품질(같은 플러그인을 누가 더 잘 굴리는가). 에이전트 보안·거버넌스 쪽에 최근 자금이 몰리는 흐름과도 방향이 맞아. 반대로 "우리는 클라이언트별 통합을 다 지원한다"를 세일즈 포인트로 삼던 미들웨어는 차별점이 줄어들 위험이 커.

일반 사용자한테는 아직 체감이 거의 없어. 챗GPT에서 플러그인 하나 켜는 경험 자체가 극적으로 바뀌지는 않아. 다만 6~12개월 뒤 효과는 나타날 거야. 같은 도구 연동이 여러 앱에서 동시에 지원되기 시작하고, "이 기능은 커서에만 있어요" 같은 말이 줄어들지. 그리고 부작용도 같이 와. 설치가 쉬워질수록 검증 안 된 확장이 늘고, 1.0.0에 서명 검증이 없다는 사실은 그때부터 진짜 문제가 돼. 지금은 "누가 만들었는지 확실한 플러그인만 설치한다"가 유일한 방어선이야.

정리하면, 8월 6일에 일어난 일은 기술적으로는 작고 전략적으로는 커. 폴더 규칙 하나를 여섯 회사가 같이 쓰기로 한 것뿐인데, 그 합의는 확장 생태계의 주도권이 어디로 갈지를 정하는 첫 단추거든. 그리고 그 단추를 채운 자리에 MCP와 스킬을 만든 회사가 없다는 사실이, 앞으로 몇 달간 이 이야기의 가장 흥미로운 변수로 남을 거야.

🥄 남은 궁금증 세 가지

— 그래서 나랑 무슨 상관이야? 에이전트 도구를 안 쓰면 당장은 상관없어. 다만 회사에서 코파일럿이나 커서를 쓰고 있다면, 앞으로 "이 플러그인 깔아도 되나요?"를 묻는 일이 늘어날 거야. 그때 기준이 될 신뢰 체계가 아직 규격에 없다는 게 진짜 포인트야.

— MCP는 이제 필요 없어진 거야? 정반대야. Agent Plugins는 MCP를 포장하는 계층이지 대체재가 아니야. 규격 원문도 MCP 명세가 통신 규약의 원본이라고 명시하고, mcp.json은 서버를 어떻게 찾아 연결할지만 정해. MCP가 없어지면 이 표준도 쓸 데가 없어.

— 앤스로픽이 결국 합류할까? 단정하긴 일러. 거부 의사를 밝힌 적은 없고, 헌장상 특정 회사 자리가 예약돼 있지도 않으니 들어오려면 개인 자격 메인테이너로 들어와야 해. 판단 기준은 하나야. 클로드 코드가 루트 plugin.json을 그냥 읽어주기 시작하는지 지켜보면 돼.

참고 자료

수치는 발표 시점 기준이라 바뀔 수 있어.