MCP·스킬·서브에이전트를 하나로 묶는 설계: AI 도구를 조합해 쓰는 실전 구조

2026-09-01 · AI & 바이브코딩

💡 3줄 요약

- 세 가지는 경쟁 관계가 아니라 층이 다릅니다. MCP는 외부 도구 연결, 스킬은 절차 지식, 서브에이전트는 작업 위임과 컨텍스트 격리를 담당합니다.

- 앤트로픽 공식 표현은 "스킬이 MCP 서버를 보완한다"이며, 스킬이 절차를 가르치고 MCP가 도구를 연결하는 구도입니다.

- 서브에이전트 정의 파일에 MCP 서버를 인라인으로 붙이면, 그 도구 설명이 메인 대화의 컨텍스트를 먹지 않습니다. 이것이 실무에서 가장 값어치 있는 결합입니다.

■ 1. 세 단어가 헷갈리는 이유

MCP, 스킬, 서브에이전트. 셋 다 "AI를 확장한다"고 설명되기 때문에 무엇을 언제 써야 하는지가 흐려집니다. 하지만 공식 문서를 나란히 놓고 보면 세 가지는 다른 층에 있습니다.

비유하자면 MCP는 연장, 스킬은 작업 지시서, 서브에이전트는 하도급 인력입니다. 연장이 있어도 지시서가 없으면 우리 방식대로 하지 않고, 지시서가 있어도 일이 너무 많으면 한 사람이 다 못 합니다.

■ 2. MCP — 도구를 연결하는 층

MCP 서버가 클라이언트에 제공하는 것은 공식적으로 세 가지입니다.

- Tools: 모델이 실행하는 함수. 제어 주체는 모델입니다.

- Resources: 컨텍스트와 데이터. 제어 주체는 애플리케이션입니다.

- Prompts: 템플릿화된 메시지와 워크플로. 제어 주체는 사용자이며, 명시적 호출이 필요합니다.

주요 메서드는 tools/list, tools/call, resources/list, resources/read, prompts/list, prompts/get 등입니다. 전송 방식은 stdio와 Streamable HTTP 두 가지가 표준이고 그 외는 custom transports로 허용됩니다.

여기서 실무자가 알아야 할 사실이 하나 있습니다. MCP 서버를 붙이면 그 서버의 도구 설명이 대화 컨텍스트를 차지합니다. 도구가 40개인 서버를 셋 붙이면 도구 설명만으로 상당한 토큰이 나갑니다. 이것이 뒤에 나올 결합 설계의 출발점입니다.

■ 3. 스킬 — 절차를 가르치는 층

스킬의 공식 설명은 "절차적 지식(procedural knowledge)과 회사·팀·사용자 고유 컨텍스트를 이식 가능한 버전 관리 폴더에 패키징"하는 것입니다. 제공하는 가치는 도메인 전문성, 반복 가능한 워크플로, 제품 간 재사용입니다.

프롬프트와의 차이도 공식 문서가 명확히 규정합니다. "일회성 작업을 위한 대화 수준 지시인 프롬프트와 달리, 스킬은 필요할 때 로드되므로 같은 안내를 대화마다 반복할 필요가 없습니다."

■ 앤트로픽이 밝힌 MCP와의 관계

엔지니어링 블로그의 문장이 관계를 정확히 규정합니다. "스킬은 외부 도구와 소프트웨어가 관여하는 더 복잡한 워크플로를 에이전트에게 가르침으로써 MCP 서버를 보완할 수 있습니다."

즉 둘은 대체재가 아닙니다. MCP가 "깃허브에 접근할 수 있다"를 만들고, 스킬이 "우리 팀은 PR을 이런 기준으로 리뷰한다"를 만듭니다.

■ 4. 서브에이전트 — 일을 떼어 주는 층

서브에이전트는 격리된 컨텍스트 윈도우, 자체 시스템 프롬프트, 개별 도구 접근 권한, 독립적 권한 설정으로 실행됩니다. 작업을 마치면 요약만 메인 대화로 반환합니다.

컨텍스트 격리의 내용은 구체적입니다. 각 서브에이전트는 신선한 컨텍스트로 시작하며, 다음을 보지 못합니다.

- 사용자의 대화 이력

- 이미 호출된 스킬

- 메인 AI가 이미 읽은 파일

대신 자체 시스템 프롬프트와 환경 정보, 위임 태스크 메시지, 프로젝트 메모리, git 상태 스냅샷, 지정된 preload 스킬을 받습니다. 예외는 fork로, 부모 대화와 도구 세트를 그대로 상속합니다.

공식 문서가 밝힌 용도는 다섯 가지입니다. 컨텍스트 보존, 제약 강제(도구 제한), 설정 재사용, 동작 특화, 그리고 비용 통제(더 빠르고 저렴한 모델로 라우팅).

■ 5. 결합 방법 다섯 가지

여기서부터가 실제 설계입니다. 공식 문서에 근거가 있는 결합만 정리합니다.

■ 결합 A — 서브에이전트에 스킬을 미리 넣기

서브에이전트 정의의 skills 필드로 시작 시점에 스킬 본문을 주입합니다. 공식 예시는 다음과 같습니다.

```

name: api-developer

skills: [api-conventions, error-handling-patterns]

```

주의할 점이 있습니다. skills는 preload 대상을 정할 뿐 접근 제한이 아닙니다. 서브에이전트는 런타임에 다른 스킬을 발견해 호출할 수 있습니다. 완전히 막으려면 tools에서 Skill을 빼거나 disallowedTools에 넣어야 합니다.

■ 결합 B — 서브에이전트에만 MCP 서버 붙이기 (가장 실용적)

mcpServers 필드로 메인 대화에 없는 MCP 서버를 서브에이전트에만 연결합니다. 공식 문서의 설계 근거가 핵심을 짚습니다.

"MCP 서버를 메인 대화에서 완전히 빼고 그 도구 설명이 거기서 컨텍스트를 소비하지 않게 하려면, .mcp.json이 아니라 여기에 인라인으로 정의하십시오. 서브에이전트는 도구를 얻고, 부모 대화는 얻지 않습니다."

브라우저 테스트용 서버, 데이터베이스 조회 서버처럼 가끔만 쓰는 도구를 이 방식으로 격리하면 평소 대화가 가벼워집니다. 지원 타입은 stdio, http, sse, ws입니다.

■ 결합 C — 스킬 자체를 서브에이전트로 실행

SKILL.md에 context: fork를 쓰면 그 스킬이 자체 서브에이전트 컨텍스트에서 돕니다. agent 필드로 어떤 서브에이전트 타입을 쓸지, background로 결과를 그 자리에서 기다릴지 지정합니다. 무거운 조사나 대량 파일 처리를 이 방식으로 떼면 메인 대화가 오염되지 않습니다.

■ 결합 D — 플러그인으로 한 덩어리로 묶기

플러그인은 셋을 하나의 설치 단위로 묶는 공식 패키징입니다. 플러그인 루트에 skills/(SKILL.md), agents/(서브에이전트 정의), .mcp.json(MCP 서버 설정), hooks/, settings.json 등이 함께 들어갑니다. 문서 부제가 그대로 설명합니다. "스킬, 에이전트, 훅, MCP 서버로 확장하는 커스텀 플러그인을 만드십시오."

팀에 배포할 때는 이 단위가 맞습니다. 개별 파일을 각자 복사하게 하면 버전이 어긋납니다.

■ 결합 E — 표준 차원의 통합 논의

MCP 사양의 확장(Extensions) 중 하나로 "Skills over MCP" 워킹그룹이 있습니다. MCP를 통해 에이전트 스킬을 발견·배포·소비하는 방법을 정의하는 작업입니다. 2026년 2월 관심그룹 결성, 4월 워킹그룹 전환이며 구글·데이터브릭스·깃허브·AWS·블룸버그 등이 참여합니다.

흥미로운 점은 이 워킹그룹이 명시한 범위 밖(Out of Scope) 항목입니다. "플러그인/번들 패키징: 설치 가능한 번들(스킬 + 서버 + 서브에이전트 + 설정을 하나의 아티팩트로)". 즉 셋을 한 덩어리로 묶는 수요는 표준 논의에서도 제기됐지만 아직 표준의 일부는 아닙니다.

■ 6. 실제 설계 순서

1) 먼저 무엇이 부족한지 진단합니다. AI가 바깥 데이터에 못 닿으면 MCP, 우리 방식을 모르면 스킬, 대화가 무거워 헤매면 서브에이전트입니다. 증상이 다른데 같은 처방을 쓰면 나아지지 않습니다.

2) MCP 서버는 최소한으로 붙입니다. 항상 쓰는 것만 메인에 두고 나머지는 결합 B로 격리합니다.

3) 스킬은 작게 여러 개로 나눕니다. 하나에 다 넣으면 활성화될 때마다 전부 읽힙니다.

4) 서브에이전트는 "떼어내도 요약만으로 충분한 일"에 씁니다. 중간 과정을 사람이 계속 봐야 하는 작업은 위임하면 오히려 답답해집니다.

5) 팀에 뿌릴 때는 플러그인으로 묶습니다.

■ 유의사항

공식 문서 어디에도 이 셋을 하나로 관통하는 단일 통합 가이드는 없습니다. 결합 근거는 여러 문서에 흩어져 있고, 위 다섯 가지도 각각 다른 문서에서 확인한 것입니다. 인터넷에서 "공식 통합 방법"이라고 소개되는 구성을 볼 때는 어느 문서를 근거로 하는지 확인하시기 바랍니다.

■ 7. 정리

세 가지를 다 쓸 필요는 없습니다. 대부분의 작업은 스킬 두세 개로 충분하고, MCP 서버는 정말 필요한 것만 있으면 됩니다. 서브에이전트는 대화가 실제로 무거워지기 시작했을 때 도입해도 늦지 않습니다.

조합이 강력해지는 지점은 정확히 하나입니다. 각각이 다른 문제를 풀고 있을 때입니다. 같은 문제를 세 가지 방식으로 중복해서 풀고 있다면, 그것은 조합이 아니라 낭비입니다.

■ 참고 자료 및 출처

MCP 공식 소개

https://modelcontextprotocol.io/docs/getting-started/intro

MCP 사양 2026-07-28

https://modelcontextprotocol.io/specification/2026-07-28

MCP 서버 개념

https://modelcontextprotocol.io/docs/learn/server-concepts

Skills over MCP 워킹그룹

https://modelcontextprotocol.io/community/working-groups/skills-over-mcp

Agent Skills 공식 사이트

https://agentskills.io/

Anthropic 엔지니어링 블로그

https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills

Claude Developer Platform 스킬 개요

https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview

Claude Code 서브에이전트 문서

https://code.claude.com/docs/en/sub-agents

Claude Code 플러그인 문서

https://code.claude.com/docs/en/plugins

본문의 필드명·인용문·워킹그룹 현황은 2026년 8월 31일 위 문서에서 확인한 내용입니다. 사양과 제품 문서는 갱신되므로 적용 전 원문을 다시 확인하시기 바랍니다.