OpenAI Codex Plugins: 에이전트 기능이 마켓플레이스가 되는 순간

OpenAI Codex Plugins · Agent Marketplace · Skills/MCP/App Manifest

OpenAI의 openai/plugins 저장소가 흥미로운 이유는 “Codex용 플러그인 예제가 올라왔다”가 아니다. 더 큰 변화는 에이전트 기능이 이제 프롬프트 조각이나 개인 설정 파일을 넘어, 설치·인증·버전·권한·UI 메타데이터를 가진 배포 단위로 정리되고 있다는 점이다.

OpenAI Codex Plugins cover

2026-06-06 기준 openai/plugins 저장소는 GitHub Trending에 올라왔고, GitHub API상 2026-06-05에 최근 push가 있었다. 저장소 README는 이 프로젝트를 “curated collection of Codex plugin examples”라고 설명한다. 그런데 내부 구조를 보면 단순 샘플보다 훨씬 더 선명한 방향성이 보인다. 각 플러그인은 plugins/<name>/ 아래에 .codex-plugin/plugin.json 매니페스트를 두고, 필요에 따라 skills/, .app.json, .mcp.json, agents/, commands/, hooks.json, assets/를 함께 가진다.

기준 시점: 이 글은 2026-06-06에 확인한 openai/plugins README, GitHub API, repository tree, .agents/plugins/marketplace.json, plugin-json-spec.md, 그리고 Figma/Notion/Remotion 플러그인 매니페스트를 기준으로 썼다. Codex 플러그인 형식과 정책은 빠르게 바뀔 수 있으니 실제 도입 전 공식 저장소를 다시 확인하는 편이 좋다.

핵심은 “확장 기능”이 아니라 “에이전트 능력의 패키징”이다

지금까지 많은 에이전트 워크플로는 느슨했다. 팀별로 프롬프트를 복사하고, 도구 설정을 숨은 파일에 넣고, MCP 서버를 따로 붙이고, 문서화는 README 어딘가에 남겼다. 작을 때는 괜찮다. 문제는 에이전트가 실제 업무 시스템에 붙는 순간이다.

이 기능을 누가 만들었는가?
어떤 앱과 데이터에 접근하는가?
설치 시 인증이 필요한가?
어떤 버전이 배포되어 있는가?
사용자는 어떤 시작 프롬프트와 UI 설명을 보게 되는가?
업데이트가 들어왔을 때 소비자는 어떻게 감지하는가?

openai/plugins는 이 질문들을 플러그인 구조 안으로 밀어 넣는다. GitHub tree를 기준으로 fixture를 제외한 .codex-plugin/plugin.json 매니페스트가 172개, SKILL.md 파일이 551개 잡힌다. 루트의 .agents/plugins/marketplace.json도 172개 플러그인을 “Codex official”이라는 표시 이름 아래에 나열한다. 즉 이것은 한두 개 데모가 아니라, 꽤 큰 단위의 공식 큐레이션 표면이다.

plugin.json은 에이전트 시대의 package.json에 가깝다

Codex plugin manifest anatomy

plugin-json-spec.md가 보여주는 매니페스트 구조는 꽤 노골적이다. 상단에는 name, version, description, author, homepage, repository, license, keywords가 있다. 개발자가 익숙한 패키지 메타데이터다. 하지만 여기서 끝나지 않는다.

중요한 필드는 그 아래다.

skills: 플러그인이 제공하는 절차 지식과 작업법
hooks: 특정 이벤트에 붙는 자동화 설정
mcpServers: 외부 도구와 데이터에 접근하는 MCP 서버 설정
apps: 앱 통합을 설명하는 manifest
interface: 사용자에게 보이는 이름, 설명, 카테고리, capability, 시작 프롬프트, 아이콘, 로고, 스크린샷

이 구조는 “모델에게 더 좋은 프롬프트를 준다”보다 넓다. 플러그인은 모델의 행동 지침, 외부 도구 연결, 앱 통합, 사용자 경험 메타데이터를 하나의 패키지로 묶는다. 그래서 plugin.json은 단순 설정 파일이라기보다 에이전트 기능을 유통하기 위한 계약서에 가깝다.

Figma 플러그인 매니페스트를 보면 이 방향이 더 분명하다. 설명은 “design implementation, Code Connect templates, design system rule generation”을 다루고, capabilities에는 Interactive, Read, Write가 들어간다. Notion 플러그인은 research synthesis, meeting preparation, knowledge capture를 말한다. Remotion 플러그인은 React 기반 programmatic video creation을 다룬다. 서로 다른 앱이지만 공통점은 같다. “앱 하나 연결”이 아니라 특정 업무 흐름을 에이전트가 반복 실행할 수 있게 패키징한다.

마켓플레이스 파일이 말하는 것: 에이전트 확장은 결국 운영 정책 문제다

Codex plugin governance

루트의 .agents/plugins/marketplace.json은 단순 목록처럼 보이지만, 실무적으로는 더 중요하다. 각 엔트리는 source, policy.installation, policy.authentication, category를 가진다. 예를 들어 설치 가능 여부는 AVAILABLE, 인증 정책은 ON_INSTALL 같은 식으로 표현된다.

이건 왜 중요할까? 에이전트 확장은 브라우저 확장보다 더 민감하다. 브라우저 확장은 사용자의 화면과 웹 데이터에 접근한다. 에이전트 플러그인은 거기에 더해 파일을 읽고, 업무 앱을 호출하고, 코드를 수정하고, 티켓을 만들고, 문서를 업데이트하고, 회의 노트를 요약할 수 있다. 따라서 “쓸 수 있다”보다 “어떤 조건으로 쓸 수 있는가”가 핵심이다.

기업 팀이 이 흐름을 본다면 마케팅 문구보다 아래 항목을 먼저 봐야 한다.

설치 정책 — 전사 기본 제공인지, 팀별 허용인지, 개인 설치인지
인증 시점 — 설치 시 인증인지, 최초 실행 시 인증인지, 중앙 관리인지
권한 범위 — 읽기 전용인지, 쓰기 가능한지, 외부 API 호출이 있는지
버전 업데이트 — 플러그인 매니페스트 버전이 어떤 소비 시스템의 refresh 신호가 되는지
감사 가능성 — 어떤 skill, MCP, app manifest가 실제로 들어있는지 리뷰할 수 있는지

최근 커밋 중 하나도 이 포인트를 잘 보여준다. 2026-06-05 커밋 메시지는 Google Drive 플러그인의 매니페스트 버전을 0.1.3에서 0.1.4로 올리며, 다운스트림 시스템이 플러그인 버전을 보고 콘텐츠 refresh 또는 rollout을 감지할 수 있다고 설명한다. 이건 작은 버전 bump처럼 보이지만, 실제로는 플러그인이 운영 시스템의 배포 단위로 취급된다는 신호다.

OpenAI, Anthropic, Cursor가 같은 문제를 향해 수렴하고 있다

Agent plugin ecosystems

이 흐름은 OpenAI만의 이야기가 아니다. 최근 몇 주 사이에 Claude Code 플러그인, Cursor plugins, GitHub Copilot SDK 같은 주제가 계속 등장했다. 이름과 파일 구조는 다르지만 방향은 비슷하다.

에이전트에게 특정 도메인의 절차 지식을 넣는다.
외부 도구와 앱 연결을 선언적으로 묶는다.
사용자가 설치하고 발견할 수 있는 마켓플레이스/디렉터리 표면을 만든다.
팀이 검토할 수 있도록 매니페스트와 버전 정보를 노출한다.

차이는 있다. Claude 쪽 플러그인은 .claude-plugin/plugin.json, commands, agents, skills, MCP를 중심으로 읽힌다. Cursor는 .cursor-plugin/plugin.json과 marketplace 구조를 드러낸다. OpenAI Codex 플러그인은 .codex-plugin/plugin.json, skills, .app.json, .mcp.json, marketplace policy를 한 저장소 안에서 대규모로 보여준다.

중요한 건 누가 파일명을 이기느냐가 아니다. 개발자 도구 시장의 경쟁축이 모델 호출 API에서 에이전트 능력의 공급망으로 이동하고 있다는 점이다. 앞으로 팀은 “어느 모델이 더 똑똑한가”만 보지 않는다. “우리 조직의 업무 앱, 보안 정책, 배포 체계, 리뷰 프로세스에 맞는 에이전트 확장 생태계를 누가 제공하는가”를 보게 된다.

개발자와 빌더에게 주는 실무 해석

Codex 플러그인을 지금 당장 제품에 넣을 수 있느냐보다 더 중요한 질문은 따로 있다. 우리 팀의 에이전트 기능을 플러그인처럼 다룰 준비가 되어 있는가?

작은 팀이라면 아래 정도부터 시작할 수 있다.

반복 업무별로 skill 문서를 분리한다.
도구 연결을 코드 안에 숨기지 말고 manifest 또는 설정 파일로 드러낸다.
읽기/쓰기 권한을 기능별로 나눈다.
플러그인 또는 워크플로 단위로 버전을 붙인다.
설치·인증·업데이트 정책을 README가 아니라 구조화된 파일로 남긴다.

플랫폼 팀이라면 더 엄격하게 봐야 한다.

사내 플러그인 registry를 둘 것인가?
외부 플러그인을 어떤 기준으로 승인할 것인가?
MCP 서버와 앱 인증을 누가 관리할 것인가?
어떤 플러그인이 파일 수정, 티켓 생성, 배포, 결제, 고객 데이터 접근을 할 수 있는가?
에이전트가 실패했을 때 로그와 재현 정보를 어디에 남길 것인가?

여기서 openai/plugins의 가치는 “이 저장소를 그대로 쓰자”가 아니다. 더 정확히는, OpenAI가 Codex 생태계에서 어떤 단위를 표준화하려 하는지 보여주는 공개 샘플이라는 데 있다. 이 저장소를 보면 에이전트 기능이 앞으로 어떻게 검색되고, 설치되고, 인증되고, 업데이트될지 감이 잡힌다.

SEO 관점에서도 이 주제는 꽤 중요하다

한국어 검색에서는 아직 “Codex plugin”, “OpenAI plugins”, “AI agent marketplace”, “MCP plugin”, “에이전트 플러그인” 같은 키워드가 충분히 정리되어 있지 않다. 하지만 개발자들이 곧 검색하게 될 질문은 분명하다.

Codex 플러그인은 무엇인가?
.codex-plugin/plugin.json은 어떤 구조인가?
Codex plugin과 MCP는 어떻게 연결되는가?
Claude Code plugin, Cursor plugin, OpenAI Codex plugin은 무엇이 다른가?
기업에서 AI agent plugin을 도입할 때 무엇을 검토해야 하는가?

이 질문들은 단순 뉴스 요약보다 오래 간다. 모델 릴리스는 빨리 지나가지만, 에이전트 확장 방식과 운영 정책은 팀의 개발 프로세스에 오래 남는다. 그래서 이 주제는 단기 트렌드이면서 동시에 장기 SEO 자산이 될 가능성이 있다.

결론: Codex Plugins는 “에이전트 앱스토어”보다 더 운영적인 신호다

openai/plugins를 보고 “OpenAI도 플러그인 마켓을 하려나?” 정도로만 해석하면 절반만 본 것이다. 더 중요한 신호는 에이전트 기능이 이제 파일·버전·권한·인증·UI·도구 연결을 가진 운영 가능한 패키지로 바뀌고 있다는 점이다.

앞으로의 에이전트 경쟁은 모델 성능만으로 끝나지 않는다. 누가 더 좋은 업무별 skill을 만들고, 누가 더 안전하게 MCP와 앱 권한을 묶고, 누가 더 신뢰할 수 있는 플러그인 공급망을 제공하는지가 중요해진다.

Codex Plugins의 핵심은 확장 기능이 아니라, 에이전트 능력을 배포하고 통제하는 방식의 표준화다.