Claude & Codex #6 Skill, MCP, Plugin, Subagent는 언제 필요할까?

전편까지 Claude Code가 구현하고 Codex가 Pull Request를 검토하는 Workflow를 만들었다. 하나의 Agent가 구현부터 Review까지 모두 맡게 하지 않고, 구현과 검토를 서로 다른 Agent에게 분리한 구조다.

flowchart LR
    ISSUE["GitHub Issue"]:::github
    CLAUDE["Claude Code<br/>코드 구현"]:::agent
    PR["Pull Request"]:::github
    CI["GitHub Actions<br/>Build · Test · Lint"]:::github
    CODEX["Codex<br/>Code Review"]:::agent
    FIX["Claude Code<br/>Review 수정"]:::agent
    HUMAN["Human<br/>Review & Approval"]:::human
    MERGE["Merge"]:::success

    ISSUE --> CLAUDE
    CLAUDE --> PR
    PR --> CI
    CI -->|통과| CODEX
    CODEX --> FIX
    FIX --> HUMAN
    HUMAN -->|승인| MERGE

이 Workflow를 실제로 반복하자 다음 문제가 보이기 시작했다. Codex Review가 끝날 때마다 Claude Code에게 비슷한 수정 절차를 다시 설명해야 했고, GitHub에 있는 Review 내용을 사람이 Claude Code에게 전달하는 과정도 남아 있었다. Backend와 Android처럼 작업 범위가 넓어지면 하나의 Agent가 읽고 유지해야 하는 Context도 계속 커진다.

이번에는 이 지점에 Skill, MCP, Plugin, Subagent를 넣는다. 다만 네 기능을 순서대로 도입하는 것이 목적은 아니다. 각각 어떤 문제를 해결하는지 구분한 뒤, 지금 Workflow에서 실제로 필요한 기능만 선택한다.

Workflow가 먼저 돌아가야 자동화할 지점도 보인다

처음부터 Skill이나 Subagent를 만들 필요는 없었다. Issue를 만들고 Claude Code가 구현한 뒤 Pull Request를 올리고, GitHub Actions와 Codex Review를 거쳐 사람이 최종 Merge하는 흐름부터 정상적으로 돌아가야 했다.

Workflow가 없으면 무엇이 반복 작업인지 판단하기 어렵다. 그래서 몇번 프로젝트를 진행하다 보면 같은 흐름을 반복하게 되고 개발자가 계속 개입하는 위치를 찾을 수 있다.

반복해서 발생하는 문제	검토할 기능
같은 작업 절차를 계속 설명한다	Skill
GitHub 정보를 사람이 복사해서 전달한다	Integration / MCP
하나의 Agent가 너무 많은 역할과 Context를 가진다	Subagent
만든 확장 기능을 여러 프로젝트에 배포하고 싶다	Plugin

Skill, MCP, Plugin, Subagent는 서로 다른 축이다

네 기능을 먼저 짧게 구분하면 이후 구조가 단순해진다.

기능	해결하려는 문제	현재 Workflow에서의 예
Skill	반복되는 작업 방식과 판단 기준 재사용	Review 확인 → 수정 → Test → Lint
MCP	외부 Tool과 Data에 접근	GitHub PR, Review, Actions 조회
Plugin	여러 확장 기능을 설치·공유 가능한 형태로 배포	Skill, Agent, MCP 설정 등을 묶어 배포
Subagent	독립된 역할과 Context로 작업 분리	Backend / Android 작업 분리

Skill을 사용한다고 MCP가 필요한 것도 아니고, Subagent가 Skill보다 더 발전된 형태인 것도 아니다. Main Agent 하나가 Skill과 MCP만 사용할 수도 있고, Subagent가 특정 Skill을 사용할 수도 있다.

Plugin은 더 다르다. Agent가 작업하는 새로운 단계라기보다 이미 만든 확장 기능을 다른 프로젝트나 사용자도 설치해서 사용할 수 있도록 묶는 배포 단위에 가깝다.

이 구분을 먼저 해두면 기능을 많이 붙이는 것과 Workflow를 개선하는 것을 혼동하지 않을 수 있다.

같은 작업을 반복해서 설명한다면 Skill로 분리한다

Codex가 Review를 남기면 Claude Code에게 대체로 비슷한 요청을 하게 된다.

Codex Review를 확인해.

모든 지적을 그대로 수정하지 말고
실제 코드와 비교해서 타당한 지적인지 먼저 확인해.

AGENTS.md와 Architecture 규칙도 확인하고,
필요한 변경만 적용해.

관련 Test와 Lint를 실행하고 결과를 정리해.
Review와 관계없는 Refactoring은 하지 마.

한두 번이라면 Prompt로 전달해도 문제가 없다. 하지만 Pull Request가 생길 때마다 같은 작업 순서와 판단 기준을 다시 적고 있다면 그때부터는 내가 왜 이작업을 하고 있지? 라는 생각을 가지게 된다.

이때 반복되는 절차를 Skill로 분리할 수 있다.

PR Review를 처리하는 Skill

현재 Workflow에서는 resolve-code-review 같은 Skill을 생각할 수 있다.
Claude Code의 프로젝트 Skill이라면 다음처럼 둘 수 있다.

.claude/
└── skills/
    └── resolve-code-review/
        ├── SKILL.md
        ├── references/
        └── scripts/

SKILL.md에는 Review를 처리할 때 따라야 할 절차와 판단 기준을 적는다.

---
name: resolve-code-review
description: Codex Review 지적을 검증하고 필요한 수정과 검증을 수행한다.
disable-model-invocation: true
---

1. Review의 각 지적을 실제 코드와 비교한다.
2. 적용되는 AGENTS.md와 Architecture 규칙을 확인한다.
3. 타당한 지적만 수정한다.
4. Review와 관계없는 Refactoring은 수행하지 않는다.
5. 관련 Test와 Lint를 실행한다.
6. 수정한 항목과 수정하지 않은 항목, 검증 결과를 정리한다.

이후에는 긴 지시를 매번 다시 작성하는 대신 Skill을 직접 호출할 수 있다.

/resolve-code-review

Skill은 단순히 자주 사용하는 Prompt 한 문장을 저장하는 기능으로 보는 것보다 반복되는 작업 방식과 판단 기준을 프로젝트 자산으로 만드는 방법으로 이해하는 편이 정확하다.

Claude Code 역시 공식 문서에서 같은 지시나 Checklist, 여러 단계의 절차를 반복해서 붙여 넣고 있다면 Skill로 만드는 것을 권장한다. Skill이 실제로 사용될 때만 본문을 불러오기 때문에 CLAUDE.md에 모든 절차를 계속 넣는 것과도 차이가 있다. Claude Code Skills 공식 문서

AGENTS.md와 Skill에는 다른 내용을 둔다

여기서 기존에 작성한 AGENTS.md, CLAUDE.md와 역할이 겹쳐 보일 수 있다.
하지만 두 문서에서 정보가 겹치면 안된다.

AGENTS.md / CLAUDE.md
        ↓
프로젝트에서 계속 지켜야 하는 규칙

Skill
        ↓
특정 작업을 수행하는 절차

예를 들어 다음은 프로젝트 규칙이다.

Provider 인증은 Android에서 처리한다.
Backend에 Provider Token을 저장하지 않는다.
외부 I/O와 DB Transaction을 섞지 않는다.
File과 FileLocation 역할을 혼합하지 않는다.

반면 다음은 Review라는 작업을 수행하는 절차다.

Review를 읽는다.
지적이 실제 문제인지 검증한다.
필요한 부분만 수정한다.
Test와 Lint를 실행한다.
결과를 정리한다.

프로젝트 전체에서 유지되어야 할 설계 규칙을 Skill마다 복사하기 시작하면 어느 파일이 현재 기준인지 다시 관리해야 한다. 프로젝트 규칙은 Context에 남기고, 반복해서 실행하는 절차를 Skill로 분리하는 것이 현재 구조에는 더 잘 맞는다.

Documentation이나 Release 과정도 같은 조건이 만들어지면 Skill 후보가 될 수 있다. 다만 아직 반복되는 실제 Workflow가 없다면 미리 만들기보다 같은 절차를 여러 번 수행하게 되었을 때 분리하는 편이 낫다.

Skill이 작업 방법을 알아도 GitHub를 읽을 수 있는 것은 아니다

resolve-code-review Skill을 만들었다고 GitHub의 Pull Request와 Review를 자동으로 읽을 수 있게 되는 것은 아니다.
Skill이 알고 있는 것은 다음과 같은 처리 방법이다.

Review 검증
→ Architecture 확인
→ 코드 수정
→ Test
→ Lint
→ 결과 정리

그런데 실제 Review 내용은 GitHub에 있다.

"어떻게 처리하지?"
        ↓
      Skill

"Review는 어디에서 가져오지?"
        ↓
 Integration / MCP

여기서 Skill과 MCP의 역할이 나뉜다.

이전에 GitHub를 사용했다고 MCP를 사용한 것은 아니다

전편에서는 GitHub Pull Request에서 다음과 같이 Codex Code Review를 사용했다.

flowchart LR
    A["Pull Request"] --> B["@codex review"]:::agent --> C["Codex"]:::agent --> D["GitHub PR Review"]:::github

이 흐름은 Codex가 제공하는 GitHub Code Review Integration을 사용한 것이다. 별도의 GitHub MCP Server를 구성해서 만든 Workflow는 아니다. Codex GitHub Code Review 공식 문서

제품이 직접 제공하는 Integration과 MCP는 구분해서 볼 필요가 있다.

구분	제품 Integration	MCP
목적	특정 제품과 서비스를 직접 연결	외부 Tool과 Data를 표준화된 방식으로 연결
현재 사례	Codex ↔ GitHub Code Review	Claude Code ↔ GitHub MCP Server
사용할 수 있는 기능	제품에서 지원하는 범위	MCP Server가 제공하는 Tool
설정 방식	제품의 Integration 설정	MCP Client와 Server 연결
적합한 상황	필요한 기능이 이미 제공될 때	다른 Agent에서도 외부 기능이 필요할 때

즉 GitHub를 사용한다는 이유만으로 GitHub MCP를 추가할 필요는 없다.
Codex Review는 기존 Integration으로 이미 해결되어 있다. 문제는 그다음이다.

flowchart LR
    A[Codex Review]:::agent --> B[개발자]:::human --> C[Claude Code]:::agent

GitHub에 Review가 이미 있는데도 사람이 내용을 다시 Claude Code에게 전달하고 있다면, 이 구간에서는 외부 Tool 연결을 검토할 이유가 생긴다.

MCP는 사람이 옮기던 외부 정보를 Agent가 직접 가져오게 한다

MCP(Model Context Protocol) 는 AI Application과 외부 Tool·Data Source를 연결하기 위한 Protocol이다.

Claude Code에서도 MCP Server를 연결하면 Issue Tracker, Database, API 같은 외부 시스템에 직접 접근할 수 있다. 공식 문서도 다른 Tool의 내용을 계속 Chat에 복사하고 있다면 MCP 연결을 검토할 상황으로 설명한다.

현재 Workflow에 GitHub MCP를 연결한다면 Claude Code가 다음 정보를 직접 조회할 수 있다.

Issue
Pull Request
Review Comment
GitHub Actions 상태
Repository 정보

GitHub는 공식 GitHub MCP Server도 제공하고 있다. GitHub MCP Server / Claude Code MCP 공식 문서

다만 Tool을 연결할 때는 무엇을 할 수 있게 할지도 같이 결정해야 한다.
현재 목적이 Review와 CI 결과를 조회하는 것이라면 처음부터 Repository 수정 권한까지 열 이유는 없다. GitHub MCP Server는 Read-only Mode와 Toolset 제한을 지원하므로 필요한 기능부터 좁게 제공한 뒤 실제 Workflow에 따라 범위를 넓히는 편이 안전하다.

GitHub MCP Server가 정상적으로 열렸을 때

MCP가 정보를 가져오고 Skill이 처리 방법을 정한다

두 기능을 같이 놓으면 차이가 훨씬 분명해진다.

flowchart LR
    HUMAN["Human<br/>PR Review 처리 요청"]:::human
    CLAUDE["Claude Code"]:::agent
    MCP["GitHub MCP Server"]
    GITHUB["PR · Review · CI"]:::github
    SKILL["resolve-code-review<br/>Skill"]
    RESULT["코드 수정 · Test · Lint"]

    HUMAN --> CLAUDE
    CLAUDE -->|조회| MCP
    MCP --> GITHUB
    GITHUB --> MCP
    MCP --> CLAUDE
    CLAUDE --> SKILL
    SKILL --> RESULT

MCP는 필요한 정보와 기능에 접근하는 방법을 제공하고, Skill은 그 정보를 어떤 순서와 기준으로 처리할지 정의한다.
그래서 Skill 안에 GitHub API 호출 방법까지 전부 집어넣거나, 반대로 MCP Tool 하나에 Review 처리 기준까지 몰아넣을 이유가 없다.

예를 들어 사람의 요청은 여기까지 줄어들 수 있다.

PR #12 Review 처리해.

그러면 Agent는 GitHub에서 Review를 가져오고, resolve-code-review에 정의한 기준으로 지적을 검증한 뒤 수정과 Test, Lint를 수행하는 구조를 만들 수 있다.

이전에는 작업 방법과 작업에 필요한 정보 모두 사람이 전달했다면, 이제 둘을 각각 Skill과 MCP가 담당하게 된다.

Plugin은 Agent 실행 단계가 아니라 배포 단위다

Plugin은 MCP의 다른 이름도 아니고, Skill 다음 단계도 아니다.

Plugin은 여러 확장 기능을 설치하고 공유할 수 있는 형태로 묶는 단위다. Claude Code Plugin 공식 문서

Claude Code 기준으로 Plugin에는 Skill뿐 아니라 Agent, Hook, MCP Server 설정 등을 함께 포함할 수 있다.

github-development/
├── .claude-plugin/
│   └── plugin.json
├── skills/
│   ├── resolve-code-review/
│   │   └── SKILL.md
│   └── prepare-pr/
│       └── SKILL.md
├── agents/
│   └── reviewer.md
├── hooks/
│   └── hooks.json
└── .mcp.json

여기서 한 가지 주의할 부분도 있다. Plugin이라는 이름을 사용하더라도 Claude Code와 OpenAI의 구체적인 Plugin 구조가 완전히 같은 것은 아니다.

그래서 Plugin = Skill + MCP + Subagent라는 고정된 공식을 외우기보다 각 제품의 확장 요소를 설치·공유 가능한 단위로 패키징한다는 역할을 기준으로 이해하는 편이 낫다.

현재 개인 프로젝트에서는 Plugin이 없어도 충분하게 개발할 수 있는 상태이다.

한 프로젝트에서만 사용
        ↓
Project Skill / 설정

여러 프로젝트에서 반복 사용
        ↓
공통화 검토

팀이나 다른 사용자에게 설치 형태로 배포
        ↓
Plugin

지금은 resolve-code-review 같은 Skill을 프로젝트 안에서 안정적으로 사용하는 것이 먼저다. 실제로 여러 Repository에서 같은 Skill과 MCP 설정을 반복해서 복사하게 되었을 때 Plugin으로 묶어도 늦지 않다.

Agent 하나가 너무 많은 Context를 가지면 Subagent를 검토한다

Skill과 MCP를 여러 개 사용하더라도 일을 수행하는 Agent가 하나라면 여전히 Main Agent 하나를 중심으로 동작한다.

Main Agent
├── Skill
└── MCP

하지만 작업 범위가 커지면 다른 문제가 생긴다. 예를 들어 하나의 Search 기능을 구현한다고 해보자.

Search Feature

Backend
├── Search API
├── Service
├── Repository
└── Test

Android
├── API Client
├── Repository
├── ViewModel
└── UI

작은 기능이라면 Main Agent 하나가 Backend와 Android를 순서대로 구현하는 편이 단순하다. 하지만 두 영역의 파일과 규칙이 커지고 서로 독립적으로 진행할 수 있는 부분이 생기면 Main Agent 하나가 모든 Context를 계속 들고 있을 이유가 줄어든다.

이때 Subagent를 검토할 수 있다.

flowchart TD
    MAIN["Main Agent<br/>전체 요구사항 · API Contract"]:::agent
    BACKEND["Backend Subagent<br/>Spring · JPA · Test"]:::agent
    ANDROID["Android Subagent<br/>Compose · API · UI"]:::agent

    MAIN --> BACKEND
    MAIN --> ANDROID

Main Agent는 전체 요구사항과 공통 Contract를 잡고, Backend와 Android Agent는 자신의 영역에 필요한 Context를 중심으로 작업한다.

Claude Code의 Subagent는 단순히 Prompt에 "너는 Backend 담당이야"라고 쓰는 것보다 역할 분리가 명확하다. 각 Subagent는 별도의 Context Window에서 동작하고, 별도의 System Prompt와 Tool, Permission을 설정할 수 있다.

Claude Code Subagents 공식 문서

Codex 역시 현재 별도의 Subagent Workflow와 Custom Agent 구성을 제공한다. Codex Subagents 공식 문서

backend-agent 실행결과

Directory가 나뉜다고 Agent도 바로 나누는 것은 아니다

프로젝트에 backend/, android/, infra/가 있다고 세 개의 Subagent부터 만들 필요는 없다. 폴더가 분리되어 있다는 사실보다 작업과 결정의 경계가 실제로 분리되는지가 더 중요하다.

Backend Agent와 Android Agent가 동시에 API Contract를 마음대로 변경한다면 Agent 수만 늘었을 뿐 역할은 제대로 나뉘지 않은 상태다. 예를 들어 공통 API Contract를 먼저 확정한 뒤 구현을 나눈다.

          API Contract 확정
                     ↓
┌──────────┐
Backend                     Android

Backend는 Server 구현과 Test를, Android는 Client와 UI를 담당한다. 이처럼 입력과 책임이 어느 정도 분리될 때 Subagent가 의미를 갖는다.

Skill은 일을 하는 방법이고 Subagent는 그 일을 맡는 Agent다

Skill과 Subagent도 서로 대체 관계가 아니다.

Skill
= 일을 하는 방법

Subagent
= 그 일을 맡는 별도의 Agent

그래서 둘을 함께 사용할 수도 있다.

Backend Subagent
       ↓
backend-test Skill

Backend Subagent가 Backend 규칙과 코드만 읽으면서 공통 backend-test Skill에 정의된 방식으로 Test를 실행하는 식이다.

반대로 작업이 작고 Context도 크지 않다면 Main Agent가 같은 Skill을 직접 사용하면 된다. Skill을 만들었다고 Agent를 분리할 이유가 생기는 것도 아니고, Subagent를 만들었다고 반복 작업 방식이 자동으로 정리되는 것도 아니다.

이미 Codex가 Review한다면 Review Subagent부터 만들 이유는 없다

Subagent 기능이 있다고 모든 역할을 별도 Agent로 만들 필요도 없다.
현재 Workflow에는 이미 독립적인 Review 단계가 있다.

Claude Code
   ↓
코드 구현

Codex
   ↓
독립 Review

이 상태에서 Claude Code 내부에 다시 Review Subagent를 만든다면 다음처럼 역할이 겹칠 수 있다.

flowchart LR
    A["Claude Code"]:::agent --> B["Review Subagent"] --> C["Codex Review"]:::agent

두 Review가 서로 다른 목적과 기준을 가지고 있다면 의미가 있을 수 있다. 하지만 같은 변경을 비슷한 기준으로 반복해서 읽는 정도라면 Agent와 Token만 늘어난다.

현재 구조에서는 Backend와 Android처럼 구현 Context를 분리하는 Subagent가 Review Agent를 하나 더 만드는 것보다 먼저 검토할 만하다. 기능이 존재한다는 이유로 Agent를 추가하기보다 현재 Workflow에 같은 역할이 이미 있는지부터 보는 편이 낫다.

Agent를 늘리면 Coordination 비용도 같이 늘어난다

Subagent를 여러 개 사용하면 Main Agent의 Context를 분리하거나 독립적인 작업을 동시에 진행할 수 있다. 반대로 Agent 사이를 조정하는 새로운 비용도 생긴다.

비용	실제로 생길 수 있는 문제
Context 중복	여러 Agent가 같은 프로젝트 규칙과 Architecture 문서를 반복해서 읽는다
변경 충돌	여러 Agent가 같은 파일이나 API Contract를 동시에 수정한다
Coordination	작업 분리, 위임, 결과 검증, 충돌 해결, 통합 과정이 추가된다
Token 비용	각 Agent가 별도의 Context와 Tool 호출을 사용한다

특히 병렬 구현에서는 어떤 결정을 누가 소유하는지가 정해져 있어야 한다.

Backend Agent
     ↓
API Response 변경

Android Agent
     ↓
기존 Response 기준 구현

이런 상황에서는 병렬로 두 Agent를 실행한 것이 오히려 수정 작업을 늘린다. Agent 수가 늘어나면 일을 나눌 수는 있지만, 그 Agent들을 서로 맞춰 주는 비용도 커진다.

Multi-Agent는 Agent 수를 늘리는 문제가 아니다. 분리해서 얻는 이점이 Coordination 비용보다 클 때 사용하는 구조다.

Subagent를 사용한다고 바로 Multi-Agent System이 되는 것은 아니다

여기서 용어도 구분할 필요가 있다.

Main Agent
├── Skill
└── MCP

Skill과 MCP를 여러 개 사용해도 Agent가 하나라면 Single-Agent Workflow다.
반면 Main Agent가 별도의 Agent에게 작업을 맡기기 시작하면 여러 Agent가 참여하는 Workflow가 된다.

Main Agent
├── Backend Subagent
└── Android Subagent

다만 Subagent 몇 개를 만든 것만으로 복잡한 Multi-Agent System이 완성되는 것은 아니다.
작업을 분석하고, Agent에게 자동으로 배분하고, 실행 상태와 실패를 추적하고, 결과를 다시 통합하는 구조까지 들어가기 시작하면 다른 문제가 생긴다.

flowchart LR
    A["요구사항"] --> B["Orchestrator"]:::agent --> C["작업 분해 · Agent 선택 · 상태 관리"] --> D["여러 Agent"]:::agent --> E["결과 검증 · 통합"]:::success

이 단계부터는 단순한 Subagent 구성보다 Orchestration과 Harness Engineering을 함께 봐야 한다.

이번 글에서는 여기까지 확장하지 않는다. 현재 단계의 목적은 Agent를 최대한 많이 만드는 것이 아니라 수동 Workflow에서 실제 비용이 발생하는 부분만 하나씩 줄이는 것이다.

자동화 범위를 늘려도 최종 승인은 사람이 한다

처음 Workflow에서는 사람이 여러 단계를 직접 연결했다.

Issue 전달
→ Claude Code 구현
→ Pull Request
→ Codex Review
→ Human이 Review 전달
→ Claude Code 수정
→ Human Approval

Skill과 MCP를 적용하면 여기서 같은 지시를 반복하는 작업과 필요한 정보를 찾는 작업을 줄일 수 있다.
작업 규모가 충분히 커졌을 때는 구현 Context도 Subagent로 분리할 수 있다.

전체 구조를 합치면 다음과 같다.

flowchart TD

    HUMAN["Human<br/>Issue · Approval"]:::human
    MAIN["Main Agent"]:::agent

    subgraph EXT["Agent 확장"]
        direction LR

        SKILL["Skills"]
        MCP["MCP"]
        BACKEND["Backend Subagent"]:::agent
        ANDROID["Android Subagent"]:::agent
    end

    PR["Pull Request"]:::github
    CI["GitHub Actions<br/>Build · Test · Lint"]:::github
    CODEX["Codex<br/>Code Review"]:::agent
    MERGE["Merge"]:::success

    HUMAN --> MAIN

    SKILL -.-> MAIN
    MCP -.-> MAIN

    MAIN --> BACKEND
    MAIN --> ANDROID

    BACKEND --> PR
    ANDROID --> PR

    PR --> CI
    CI --> CODEX
    CODEX --> HUMAN
    HUMAN -->|승인| MERGE

Plugin은 이 Runtime 흐름 안에 별도의 실행 단계로 넣지 않는다.

Plugin
└── Skill / Agent / MCP 설정 / Hook 등을
    설치·공유 가능한 형태로 패키징

자동화하면서 줄이려는 것은 사람이 GitHub 내용을 복사하고 같은 작업 순서를 다시 입력하는 구간이다. 반대로 Architecture 변경에 대한 판단이나 최종 Merge 같은 Control Point까지 없애려는 것은 아니다.

GitHub Actions, Codex Review, Human Approval은 서로 다른 방식으로 변경을 확인한다. 중간 전달을 자동화한다고 이 검증 단계들까지 함께 사라지는 것은 아니다.

언제 무엇을 사용해야 할까

마지막에는 기술 이름이 아니라 현재 겪고 있는 문제를 기준으로 선택하면 된다.

현재 상황	먼저 검토할 것
같은 작업 절차를 계속 설명한다	Skill
GitHub·Jira·DB 등의 정보를 사람이 계속 전달한다	기존 Integration 또는 MCP
만든 확장을 여러 프로젝트나 팀에 배포하고 싶다	Plugin
Main Agent의 Context와 역할이 지나치게 커진다	Subagent
작업을 독립적인 영역으로 나눌 수 있다	Subagent
이미 같은 역할을 다른 Agent가 맡고 있다	새 Agent를 추가하지 않는다
작은 단일 작업이다	Main Agent 그대로 사용

모든 프로젝트에 Skill, MCP, Plugin, Subagent가 전부 필요한 것은 아니다. 문제가 없다면 Main Agent 하나로 처리하는 구조가 가장 단순하다.

정리

Claude Code가 구현하고 Codex가 Review하는 Workflow를 만들어도 개발자가 중간에서 해야 할 일은 남아 있었다.

Review를 처리하는 방법을 다시 설명하고, GitHub에 있는 정보를 Agent에게 전달하고, 작업 범위가 커지면 서로 다른 Context까지 하나의 Agent가 관리해야 했다.

같은 작업 순서와 판단 기준이 반복된다면 Skill로 분리하고, 외부 시스템의 정보를 개발자가 계속 옮기고 있다면 MCP 같은 Tool 연결을 검토할 수 있다. 하나의 Agent가 서로 다른 역할과 Context까지 담당하기 어려워지면 Subagent로 역할을 나누고, 이렇게 만든 확장을 여러 프로젝트에서 반복해서 사용하게 되었을 때 Plugin으로 묶을 수 있다.

먼저 Workflow를 운영해보고, 반복되는 절차는 Skill로, 외부 정보 전달은 MCP로, 역할 분리가 필요해질 때 Subagent로 확장하면 된다.