Codex Skills와 Plugins 실전 가이드: 팀 워크플로를 재사용 가능한 역량으로 만들기

같은 코드 리뷰 체크리스트가 5개 저장소에 복사되어 있습니다. PR마다 여전히 “실패한 테스트부터 다시 돌리기”, “권한 경계 확인하기”, “changelog 누락하지 않기”를 손으로 상기시켜야 합니다. 문제는 prompt가 짧아서가 아닙니다. 이 절차가 아직 재사용 가능한 형태가 아니기 때문입니다.

Codex Skills와 Plugins는 이 반복을 정리하기 위한 도구입니다. 팀의 반복 워크플로를 임시 prompt와 점점 길어지는 AGENTS.md에서 꺼내 재사용 가능한 역량으로 남깁니다. Skill은 재사용 워크플로의 작성 형식입니다. Plugin은 설치 가능한 배포 단위입니다. 둘은 프로젝트 규칙을 대체하지 않습니다. 항상 적용되는 규칙은 AGENTS.md에 두고, 여러 단계 절차, 예시, 스크립트, 긴 참고 자료는 Skill로 옮기며, 팀 배포가 필요해지면 Plugin으로 묶습니다.

먼저 판단표 하나로 Skill, Plugin, MCP, AGENTS.md, Subagent 중 무엇을 써야 하는지 구분합니다. 그다음 최소 Skill 파일 트리에서 시작해 role-specific plugin 분해 방식, 팀 배포 경로, 권한 경계 체크리스트까지 이어갈 수 있습니다.

1. 복사되는 팀 절차: 문제는 prompt가 아닙니다

코드 리뷰, 릴리스 전 점검, 테스트 절차, 문서 업데이트는 팀 안에서 대체로 고정된 형식이 있습니다. 매 PR 리뷰마다 Codex에 “changelog가 빠졌는지, 테스트 커버리지가 떨어졌는지, API docs를 업데이트해야 하는지 확인해”라고 붙여 넣고 있을 수 있습니다. 문제는 금방 드러납니다.

• 관리 위치가 흩어집니다. 체크리스트가 바뀌면 5개 프로젝트의 .github/PULL_REQUEST_TEMPLATE.md나 각자의 prompt 파일을 수정해야 합니다.
• 실행 품질이 흔들립니다. Codex가 매번 절차를 처음부터 이해해야 하므로 “실패한 테스트를 먼저 돌린다” 같은 중요한 단계를 빠뜨리기 쉽습니다.
• 역할 기준이 섞입니다. 프론트엔드, QA, 보안, 문서의 기준이 한 prompt에 쌓이면 Codex가 어떤 기준을 적용해야 할지 판단하기 어렵습니다.

이 규칙을 모두 AGENTS.md에 넣는 팀도 있습니다. 하지만 그러면 또 다른 문제가 생깁니다. 프로젝트 규칙 파일이 점점 길어지고, 항상 필요한 빌드 명령, 디렉터리 규칙, 임시 프로세스 안내가 한데 섞입니다. 이는 원래의 “지속적인 프로젝트 제약”이라는 역할을 넘어섭니다.

Codex에서는 더 명확히 나눌 수 있습니다. AGENTS.md는 지속 규칙, Skills는 재사용 워크플로, Plugins는 배포입니다. 중요한 것은 각 계층에 무엇을 둘지 판단하는 것입니다.

2. Skill, Plugin, MCP, AGENTS.md를 판단표로 구분하기

Skill은 재사용 워크플로의 작성 형식입니다. 보통 SKILL.md 파일과 선택적 scripts, references, assets로 구성됩니다. Plugin은 Codex에서 설치할 수 있는 배포 단위이며 Skills, app integrations, MCP servers, assets를 묶을 수 있습니다. MCP는 외부 도구와 컨텍스트를 연결하는 프로토콜로, Codex가 서드파티 문서, 브라우저, Figma, GitHub 등을 다룰 수 있게 합니다. AGENTS.md는 지속적인 프로젝트 제약을 두는 파일입니다. 빌드 명령, 디렉터리 규칙, 리뷰 기대치가 여기에 해당합니다. Subagent는 시끄럽거나 전문적인 작업을 위임하는 역할입니다.

어떤 방식을 선택할지

콘텐츠 유형	적합한 방식	전형적인 상황	쓰지 않는 편이 좋은 경우
빌드 명령, 테스트 스크립트 경로, 디렉터리 규칙	AGENTS.md	”새 컴포넌트는 모두 src/components/에 둔다”, “테스트는 npm run test:unit으로 실행한다”	다단계 절차, 예시, 외부 도구 호출
예시, 스크립트, 참고 자료가 필요한 다단계 워크플로	Skill	10단계 코드 리뷰, 7항목 릴리스 체크, API docs 생성 흐름	한 줄 규칙이나 단일 명령
팀 배포, app/MCP 설정 패키징	Plugin	4개 리뷰 Skills와 Figma connector를 포함한 프론트엔드 역할 Plugin	단일 저장소에서만 반복하고 공유가 필요 없는 흐름
외부 도구 호출, 서드파티 컨텍스트	MCP	Figma 설계 스펙 가져오기, GitHub API로 issue 목록 읽기	외부 데이터가 필요 없는 순수 워크플로 정의
시끄럽거나 전문적인 작업 위임	Subagent	테스트 진단이나 로그 분석을 전용 agent에 맡기기	메인 대화에서 바로 처리할 수 있는 단순 절차

AGENTS.md에서 Skill로 빼야 하는 시점

다음 상황이면 절차가 프로젝트 규칙 파일의 범위를 넘어선 것입니다. Skill로 만드는 편이 좋습니다.

• 같은 체크리스트가 여러 PR에서 반복되고 매번 손으로 복사됩니다.
• 절차가 여러 단계이고 예시, 스크립트, 외부 참고 자료가 필요합니다.
• “릴리스 전 실행”, “Pull Request 리뷰 때 실행”처럼 명확한 트리거가 있습니다.
• 역할별 기준이 달라 하나의 파일에 모두 넣기 어렵습니다.
• 절차에 버전 관리와 변경 기록이 필요하고, 매번 프로젝트 규칙을 직접 고치고 싶지 않습니다.

Skill에서 Plugin으로 올리는 시점

Skill은 단일 저장소나 개인 워크플로에서 반복하는 동안 충분합니다. 다음 요구가 생기면 Plugin으로 묶습니다.

• 개인 디렉터리나 단일 저장소가 아니라 팀 전체에 공유해야 합니다.
• Figma, GitHub, CI/CD 도구 같은 app integration 또는 MCP server 설정을 함께 배포해야 합니다.
• Skill 폴더를 복사하는 방식이 아니라 version, changelog, upgrade 흐름이 필요합니다.
• Codex App의 Plugin Directory를 통해 workspace members에게 배포해야 합니다.
• 자주 바뀌는 실험 절차가 아니라 안정된 패키지로 공개하려 합니다.

실무 순서는 단순합니다. 저장소 규칙은 AGENTS.md에 고정합니다. 맞는 기존 Plugin이 있으면 설치합니다. 없으면 Skill을 만듭니다. 팀 배포가 필요해지면 Plugin으로 묶습니다. 외부 시스템이 필요할 때만 MCP를 붙입니다. 시끄럽거나 전문적인 작업은 Subagent에 위임합니다.

3. 최소 Skill 실전: 코드 리뷰부터 시작하기

최소 Skill 파일 트리

Skill에 최소한 필요한 구성은 다음과 같습니다.

.agents/skills/code-review/
├── SKILL.md
├── references/
│   └── security-checklist.md
└── scripts/
    └── run-failed-tests.sh

디렉터리 이름과 SKILL.md frontmatter의 name은 일치해야 합니다. 형식은 lowercase alphanumeric + hyphen입니다.

SKILL.md 예시: 코드 리뷰 Skill

---
name: code-review
description: Use for pull request reviews in frontend projects. Checks changelog, test coverage, security boundary, and API docs. Do not use for backend-only changes or infrastructure PRs.
---

# Code Review Checklist

## Before Starting
1. Run failed tests first: `npm run test:failed`
2. Check if PR has clear description and scope

## Review Steps
1. Changelog: Does `CHANGELOG.md` need update?
2. Test Coverage: Did coverage decrease? Check report in `coverage/`
3. Security: Review changes in `src/auth/`, `src/api/`, and `src/middleware/`
4. API Docs: If API changed, update `docs/api.md`

## Security Boundary Checks
See `references/security-checklist.md` for detailed items.

## Failed Test Runner
Use `scripts/run-failed-tests.sh` to rerun previously failed tests.

description 트리거 설계: before/after

Codex는 description을 보고 Skill을 암시적으로 호출할지 판단합니다. 너무 모호하면 잘못 호출되거나 호출되지 않습니다.

Before（오탐하기 쉬움）	After（더 안정적）
“Code review skill for frontend projects"	"Use for pull request reviews in frontend projects. Checks changelog, test coverage, security boundary, and API docs."
"Help review code"	"Use when reviewing PRs with frontend changes. Do not use for backend-only changes or infrastructure PRs."
"Review checklist"	"Trigger on: PR reviews, code audit requests. Exclude: backend changes, config-only updates.”

핵심은 “Use when…”과 “Do not use when…”을 분명히 쓰는 것입니다. pull request, review, frontend 같은 트리거 단어는 앞부분에 두는 편이 좋습니다. 긴 description은 잘릴 수 있기 때문입니다. 명시 호출만 원한다면 allow_implicit_invocation: false를 설정합니다.

Skill 저장 위치와 범위

위치	범위	적합한 상황	주의점
저장소 루트의 .agents/skills/	현재 저장소	팀 프로젝트의 리뷰, 테스트, 릴리스 절차	Git에 커밋해 팀과 공유
$HOME/.agents/skills/	개인, 여러 프로젝트	개인 코드 스타일, 자주 쓰는 명령 습관	저장소에 자동 동기화되지 않음
/etc/codex/skills/	조직 수준	조직 공통 보안 리뷰, 규정 준수 점검	admin 권한 필요
System bundled	시스템 내장	Codex 기본 제공 $skill-creator, $skill-installer	수정 불가

같은 이름의 Skill은 병합되지 않습니다. 우선순위는 보통 repo > user > admin > system이지만, 구체적인 동작은 공식 문서를 기준으로 확인해야 합니다.

Progressive disclosure 설계 원칙

모든 내용을 최상위 SKILL.md에 넣지 않는 편이 좋습니다. Codex의 progressive disclosure는 3단계입니다.

1. Metadata: 처음에는 name, description, file path만 봅니다.
2. Instructions: Skill이 선택된 뒤에 전체 SKILL.md를 읽습니다.
3. Resources: references/, scripts/, assets/는 필요할 때만 읽습니다.

설계 기준은 메인 SKILL.md를 500줄 이내로 유지하는 것입니다. 긴 참고 자료는 별도 파일로 분리합니다. 테스트 실행기나 커버리지 검사처럼 결정적으로 실행할 수 있는 검증은 scripts/에 둡니다. 자세한 체크리스트, 배경 문서, 과거 사례는 references/에 둡니다. 템플릿과 예시 스크린샷은 assets/에 둡니다.

명시 호출과 암시 호출

명시 호출은 $code-review 또는 /skills 선택으로 합니다. 암시 호출은 Codex가 description을 보고 현재 작업에 Skill이 맞는지 판단합니다. 암시 호출을 끄려면 agents/openai.yaml에 allow_implicit_invocation: false를 설정합니다.

암시 호출은 PR 리뷰처럼 자주 발생하고 경계가 명확한 흐름에 적합합니다. 분기별 보안 감사처럼 빈도가 낮고 사람의 판단이 필요한 작업은 명시 호출이 더 안전합니다. Skill에 외부 스크립트나 민감한 작업이 포함된다면 명시 호출을 우선합니다.

4. Plugin 패키징과 팀 배포: 로컬 Skill에서 팀용 suite로

Plugin 최소 구조

Plugin은 Skill 디렉터리 이름만 바꾼 것이 아닙니다. 설치 가능한 패키지이며, 최소한 .codex-plugin/plugin.json manifest가 필요합니다.

.agents/plugins/frontend-review/
├── .codex-plugin/
│   └── plugin.json
├── skills/
│   ├── code-review/
│   │   └── SKILL.md
│   ├── accessibility-check/
│   │   └── SKILL.md
│   └── performance-lint/
│       └── SKILL.md
├── assets/
│   └── templates/
└── README.md

plugin.json 필수 필드

{
  "name": "frontend-review",
  "version": "1.0.0",
  "description": "Frontend team code review and accessibility check skills",
  "skills": "./skills/",
  "assets": "./assets/",
  "author": "frontend-team",
  "repository": "https://github.com/org/frontend-review-plugin"
}

선택 필드에는 Figma용 .app.json 같은 app integration을 묶는 apps, .mcp.json 같은 MCP server 설정을 묶는 mcpServers, 권한과 데이터 공유 정책을 나타내는 policy가 있습니다. 모두 workspace admin policy의 제약을 받습니다.

marketplace 구조: 팀 Plugin 디렉터리

Plugin marketplace는 Plugin 경로를 가리키는 JSON 목록입니다.

.agents/plugins/marketplace.json

{
  "plugins": [
    {
      "source": "local",
      "path": "./frontend-review"
    },
    {
      "source": "github",
      "owner": "openai",
      "repo": "role-specific-plugins",
      "ref": "main",
      "path": "plugins/data-analytics"
    }
  ]
}

local은 아직 공개하지 않은 내부 Plugin에 적합합니다. github는 공개 Plugin이나 여러 팀이 공유하는 패키지에 적합합니다.

Plugin 배포 명령 체크리스트

CLI 명령은 바뀔 수 있으므로 공식 문서를 기준으로 확인해야 합니다.

# 새 Plugin scaffold
codex plugin create frontend-review

# Plugin을 marketplace에 추가
codex plugin marketplace add owner/repo --ref main --sparse

# 설치된 Plugin 목록
codex plugin marketplace list

# Plugin 업그레이드
codex plugin marketplace upgrade frontend-review

# Plugin 제거
codex plugin marketplace remove frontend-review

Codex App에서는 Plugin Directory에서 Curated by OpenAI, Shared with you, Created by you를 볼 수 있습니다. Local plugin은 workspace members나 groups에 공유할 수 있습니다. Workspace admins는 plugin sharing을 비활성화하거나 managed requirements를 설정할 수 있습니다.

workspace에 공유하는 것과 공개 배포는 다릅니다. 외부 app 연결과 MCP servers는 여전히 인증이 필요하고, approval settings도 계속 적용됩니다.

팀 marketplace 구성 제안

저장소 전용 Plugin은 $REPO_ROOT/.agents/plugins/marketplace.json에 둡니다. 조직 공통 Plugin은 $HOME/.agents/plugins/marketplace.json이나 GitHub organization repo에 두면 좋습니다. 버전은 plugin manifest의 version에 명시합니다. README에는 changelog를 유지하고, 업그레이드 전 테스트 환경에서 검증합니다. 보안 리뷰나 규정 준수 확인처럼 민감한 Plugin은 조직 수준 marketplace에 두어 무심코 설치되지 않게 합니다.

처음에는 local skill로 반복하고, 안정된 뒤 Plugin으로 묶어 배포하는 편이 좋습니다. 처음부터 Plugin을 만들면 흐름을 바꾸기 어려워질 수 있습니다.

5. Role-specific Plugin 설계: 프론트엔드, QA, 문서 역할 고정하기

OpenAI의 role-specific-plugins 저장소에는 Sales, Data Analytics, Product Design, Financial Markets 템플릿이 있습니다. 개발팀이 세일즈나 금융 흐름을 그대로 가져올 필요는 없습니다. 다만 분해 방식은 참고할 만합니다. 하나의 역할에서 출발해 3~5개의 작은 Skill로 나누고, 이를 Plugin으로 묶는 방식입니다.

분해 프레임: 역할 → 반복 산출물 → 데이터/도구 출처 → 작은 Skills → 공유 방식

역할	반복 산출물	데이터/도구 출처	나눌 Skills	필요한 apps/MCP	검수 기준
프론트엔드 엔지니어	컴포넌트 리뷰, 성능 점검, 접근성 검증	Figma 설계 사양, 기존 Storybook 컴포넌트	component-audit, accessibility-check, performance-lint, design-system-sync	Figma connector, Storybook MCP	새 컴포넌트마다 4개 점검 완료
QA 엔지니어	테스트 커버리지 보고서, E2E suite 진단, 회귀 체크리스트	CI/CD 테스트 결과, 과거 실패 기록	test-coverage-check, e2e-suite-runner, flaky-test-diagnosis, regression-suite-builder	GitHub Actions/Jenkins 같은 CI/CD 도구 연결	실패 테스트 우선 실행, 커버리지 하락 없음
기술 문서 엔지니어	API docs 업데이트, Changelog 작성, 마이그레이션 가이드	API schema, Git commit history	api-doc-generator, changelog-builder, readme-audit, migration-guide-writer	GitHub API, Schema 도구	API 변경 시 문서도 동기화
보안 엔지니어	권한 경계 리뷰, secret 점검, 의존성 보안 스캔	의존성 목록, secret 저장 설정	auth-boundary-check, secrets-scan, dependency-security	Snyk, Dependabot MCP	매 릴리스 전 보안 체크리스트 완료

프론트엔드 역할 Plugin 분해 예시

frontend-engineer-plugin/
├── .codex-plugin/
│   └── plugin.json
├── skills/
│   ├── component-audit/
│   │   ├── SKILL.md
│   │   └── references/
│   │       └── component-template.md
│   ├── accessibility-check/
│   │   ├── SKILL.md
│   │   └── scripts/
│   │       └── axe-audit.sh
│   ├── performance-lint/
│   │   ├── SKILL.md
│   │   └── scripts/
│   │       └── lighthouse-check.sh
│   └── design-system-sync/
│       ├── SKILL.md
│       └── references/
│           └── design-tokens.md
├── assets/
│   └── templates/
│       └── component-template.tsx
└── README.md

component-audit Skill은 새 컴포넌트가 팀 규칙을 따르는지 확인합니다. 예를 들어 이름, 디렉터리, props 타입입니다. accessibility-check는 axe-core 스크립트로 접근성을 확인합니다. performance-lint는 Lighthouse로 주요 성능 지표를 봅니다. design-system-sync는 Figma 설계 사양과 구현을 맞춰봅니다.

QA 역할 Plugin 분해 예시

qa-engineer-plugin/
├── .codex-plugin/
│   └── plugin.json
├── skills/
│   ├── test-coverage-check/
│   │   ├── SKILL.md
│   │   └── scripts/
│   │       └── coverage-threshold-check.sh
│   ├── e2e-suite-runner/
│   │   └── SKILL.md
│   ├── flaky-test-diagnosis/
│   │   ├── SKILL.md
│   │   └── references/
│   │       └── flaky-test-log-analysis.md
│   └── regression-suite-builder/
│       └── SKILL.md
├── .mcp.json
└── README.md

test-coverage-check는 커버리지가 떨어졌는지 확인하고 커버되지 않은 파일을 표시합니다. e2e-suite-runner는 우선순위에 따라 E2E 테스트를 실행합니다. flaky-test-diagnosis는 과거 실패 로그를 분석해 불안정한 테스트를 찾습니다. regression-suite-builder는 변경 범위에 따라 회귀 테스트 체크리스트를 만듭니다.

connector placeholder 교체 체크리스트

공식 템플릿의 .app.json에는 placeholder connector id가 들어 있을 수 있습니다. 설치 전에 교체해야 합니다.

{
  "app_id": "figma-placeholder"
}

.app.json의 모든 placeholder id를 확인하고, 대상 workspace에서 사용할 수 있는 실제 ID로 교체합니다. 다른 workspace의 connector id를 그대로 복사하지 마세요. 환경이나 권한 차이로 무효일 수 있습니다. MCP server 설정의 OAuth/Bearer token도 자신의 환경에 맞게 설정해야 하며, 템플릿 예시 값을 그대로 쓰는 것이 아닙니다. 교체한 뒤에는 테스트 환경에서 connector가 동작하는지 확인합니다.

공식 role-specific-plugins README는 이 Plugin 템플릿들이 사용 전에 커스터마이즈되어야 한다고 설명합니다. connector-backed plugins에는 바꿔야 할 app ID나 connector ID가 포함될 수 있습니다.

6. 보안과 유지보수: Plugin은 권한 통행증이 아닙니다

Connector / MCP 권한 경계

Plugin을 설치해도 Codex의 approval settings는 우회되지 않습니다. 외부 app과 MCP server는 여전히 인증이 필요하고, 데이터 공유도 각 정책을 따릅니다. .app.json의 placeholder id는 교체해야 하지만, 다른 workspace의 connector id를 복사해서는 안 됩니다. Figma나 GitHub 같은 외부 app은 별도 인증이 필요합니다. Plugin은 설정을 묶을 뿐, 인증 자체가 아닙니다. MCP server는 config.toml에서 enabled와 tool policy로 계속 제어할 수 있습니다. Approval mode도 적용됩니다. “suggest-only”라면 Plugin 안의 스크립트는 자동 실행되지 않습니다.

Plugin을 권한 통행증처럼 취급하지 마세요. Plugin은 워크플로, 설정, assets를 패키징하지만 권한 경계는 그대로 남아 있습니다.

스크립트 출처 리뷰

Skill/Plugin의 scripts/ 디렉터리에는 실행 파일이 들어갈 수 있습니다. 서드파티 Plugin이나 커뮤니티 marketplace의 스크립트는 반드시 리뷰해야 합니다. scripts 안의 실행 파일을 모두 확인하고 출처를 검증합니다. 검증되지 않은 저장소의 스크립트를 바로 실행하지 않습니다. 먼저 테스트 환경에서 시도하고, production에는 모르는 Plugin을 바로 설치하지 않습니다. 버전은 tag나 commit hash로 고정하고, 매번 main 최신을 가져오지 않습니다.

악성 서드파티 Skill에 적용되는 원칙은 실행 가능한 스크립트와 서드파티 Plugin에도 그대로 적용됩니다. 출처 확인, 최소 권한, 테스트 환경 검증입니다.

버전과 변경 기록

팀 협업에는 버전 관리가 필요합니다. plugin.json에 version 필드를 명확히 쓰고 업데이트마다 올립니다. README에는 changelog를 두어 추가된 Skill, 변경된 Skill, 폐기된 Skill을 설명합니다. 업그레이드 전에는 테스트 환경에서 검증하고, 모든 Skills를 실행해 보며, 스크립트가 정상 작동하고 connector가 여전히 사용 가능한지 확인합니다. marketplace에서는 ref를 tag나 commit으로 고정하고, 항상 최신 main을 당기지 않습니다.

Skill/Plugin 수가 주는 영향

Codex 초기 Skill 목록에는 컨텍스트 예산이 있습니다. 공식 문서는 initial skills list가 컨텍스트의 약 2%, 또는 컨텍스트 크기를 알 수 없을 때 8,000 characters 정도를 차지한다고 설명합니다.

실무 영향은 명확합니다. Skill description이 너무 길면 잘릴 수 있으므로 핵심 트리거 단어를 앞에 둬야 합니다. Skills를 너무 많이 로드하면 Codex가 어떤 Skill을 써야 할지 판단하기 어려워질 수도 있습니다. 자주 쓰고 경계가 명확한 Skill은 repo나 user 디렉터리에 두기 좋습니다. 자주 쓰지 않는 Skill은 항상 로드하지 말고 Plugin에 넣어 필요할 때 설치하는 편이 좋습니다.

Codex가 자주 잘못된 Skill을 호출하거나 필요한 Skill을 호출하지 못한다면 먼저 description을 확인하세요. Skill 수를 늘리는 것은 좋은 해결책이 아닙니다.

7. 관련 기술과 비교

Claude Code Skills와 비교

BetterLink에서는 이전에 Claude Code Skill 메커니즘도 다뤘습니다. 사고방식은 비슷하지만 제품은 다릅니다. 둘 다 Agent Skills 공개 형식과 SKILL.md 파일을 사용합니다. 둘 다 name, description, 선택적 scripts/, references/, assets/를 가집니다. 둘 다 metadata → instructions → resources라는 progressive disclosure를 지원합니다.

차이도 중요합니다. 경로는 Codex가 .agents/skills/, Claude Code가 .claude/skills/입니다. 호출 방식은 Codex가 $skill-name 또는 /skills, Claude Code가 /skill 명령입니다. Plugin 배포에서는 Codex Plugin에 marketplace, CLI 명령, workspace sharing이 있습니다. Claude Code에는 현재 공식 Plugin marketplace가 없습니다. 내장 도구도 다릅니다. Codex에는 $skill-creator, $skill-installer, @plugin-creator가 있고, Claude Code에는 다른 내장 명령이 있습니다.

Claude Code Skills를 써 본 적이 있다면 사고방식은 재사용할 수 있습니다. 하지만 경로와 호출 문법을 그대로 복사하지 말고, 각 제품의 공식 문서를 기준으로 맞춰야 합니다.

MCP와의 분담

MCP, 즉 Model Context Protocol은 외부 도구와 컨텍스트를 연결하기 위한 것입니다. Skill이나 Plugin의 대체물이 아닙니다. Skill은 워크플로를 정의합니다. MCP는 Figma, GitHub, CI/CD system 같은 외부 도구를 연결합니다. Plugin은 MCP server 설정을 묶을 수 있지만, MCP server 자체는 계속 config.toml로 제어됩니다.

예를 들면, 프론트엔드 리뷰 Skill은 “컴포넌트가 디자인 시스템에 맞는지 확인하는” 절차를 정의합니다. Figma MCP server는 설계 파일에 접근하는 능력을 제공합니다. 프론트엔드 Plugin은 리뷰 Skill과 Figma MCP 설정을 묶지만, Figma OAuth는 여전히 별도로 인증해야 합니다.

여기서는 경계만 정리합니다. Codex MCP tools 실전은 별도 글에서 더 자세히 다룰 수 있습니다.

결론

Codex Skills와 Plugins의 가치는 팀의 반복 절차를 복사한 prompt와 과도하게 커진 AGENTS.md에서 꺼내 재사용 가능한 역량으로 남기는 데 있습니다. 기준은 단순합니다. 지속 규칙은 AGENTS.md, 여러 단계 절차는 Skill, 패키징과 배포는 Plugin, 외부 시스템 연결은 MCP입니다. description에는 트리거 조건을 분명히 쓰고, 먼저 local skill로 검증한 뒤 실제 배포가 필요할 때 Plugin으로 묶습니다. 서드파티 Plugin의 scripts, connector id, MCP 설정은 여전히 리뷰해야 합니다.

처음에는 최소 Skill 하나로 충분합니다. 팀의 코드 리뷰나 테스트 절차를 SKILL.md로 만들고 몇 번 실행해 트리거가 안정적인지 확인합니다. 팀에 프론트엔드, QA, 보안, 문서 역할이 있다면 OpenAI role-specific-plugins의 분해 방식을 참고해 역할별로 3~5개의 작은 Skill을 만들고, 이를 역할 Plugin으로 묶습니다.

BetterLink 관련 글:

• Codex 입문 완전 가이드
• AGENTS.md 프로젝트 규칙
• Codex 보안 경계와 권한 관리
• Codex MCP tools 실전
• Claude Code Skill 비교
• MCP 프로토콜 기초