MCP·Skills·Tools·Subagents 차이는? 2026 AI Agent 개발 스택의 변화

결론부터: Tools, MCP, Skills, Subagents는 서로 바꿔 쓸 수 있는 네 제품명이 아니라, 2026년 Agent 스택의 네 계층이다. Tools는 모델이 보는 호출 가능 계약(이름 + JSON Schema)이다. MCP는 Host와 외부 도구 프로세스 사이의 발견·호출 프로토콜이다. Skills는 필요할 때 올리는 절차형 플레이북(일을 어떻게 할지)이다. Subagents는 자체 컨텍스트를 가진 위임 에이전트이다. 한 유행어로 뭉개면 틀린 계층을 디버깅하게 된다.

2026년 9월 11일 기준. 본 사이트는 이미 MCP란 무엇인가, Agent JSON 데이터 흐름, 계약으로서의 JSON Schema를 다뤘다. 이 글은 각 계층이 무엇을 담당하는지, 어떻게 쌓이는지, 2026 스택이 어디로 수렴하는지만 답한다.

네 계층 한눈에

사람들이 “에이전트에 도구를 추가한다”고 말할 때, 실제로는 네 가지를 가리키는 경우가 많다. 아래 표에 맞춰 보면 된다:

한 문장으로: Tools는 “무엇을 호출할 수 있는가”; MCP는 “도구가 어디서 오는가”; Skills는 “이 일을 어떻게 하는가”; Subagents는 “누가, 어떤 컨텍스트에서 하는가”이다. JSON Schema는 Tools와 MCP를 가로지르고, Skills와 Subagents는 주로 프롬프트·정책·세션 경계를 다룬다.

Tools: 모델 앞의 호출 계약

Tool(또는 Function)은 모델이 보는 최소 호출 단위다. 벤더 이름은 다르다 — OpenAI Tools / Function Calling, Anthropic Tool Use, Gemini Function Declarations — 형태는 같다: 도구를 선언하면 모델이 구조화된 tool_calls를 반환하고, Host가 실행한 뒤 결과를 대화에 다시 쓴다.

도구 정의는 보통 이런 모양이다:

{
  "type": "function",
  "function": {
    "name": "validate_json",
    "description": "Validate JSON text and return parse errors.",
    "parameters": {
      "type": "object",
      "properties": {
        "text": { "type": "string" }
      },
      "required": ["text"],
      "additionalProperties": false
    }
  }
}

행동을 실제로 묶는 것은 JSON Schema다: 필드 이름, 타입, required, additionalProperties. 모델은 바뀌어도 Schema는 따라 흔들리면 안 된다. 검증 규율은 Tool Calling이 JSON Schema에 의존하는 이유를 보라. 여기서의 요지는 단순하다: Schema 없는 자연어 도구 설명은 2026년 생산 계약으로 부족하다.

Tools 계층의 경계는 분명하다: 구현이 같은 프로세스인지 원격인지는 정하지 않고, 다단계 작업을 어떻게 쪼갤지도 정하지 않는다. 그건 MCP와 Skills / Subagents의 몫이다.

MCP: 프로세스 간 도구 소켓

MCP(Model Context Protocol)는 Host 프로세스 밖에서 도구와 컨텍스트를 어떻게 발견·호출하는지를 답한다. 메시지는 JSON-RPC 2.0이고, 흔한 메서드는 tools/list, tools/call, 그리고 Resources / Prompts다. Host(Cursor, VS Code, Claude Desktop 등) 안의 MCP Client가 MCP Server에 연결하고, 노출된 도구를 모델이 이해하는 Tools 배열로 번역한다.

올바른 스택은 이렇다:

1. MCP Server가 각 tool을 inputSchema(역시 JSON Schema)로 기술한다;
2. Host가 tools/list를 호출하고 결과를 모델 Tool 선언으로 매핑한다;
3. 모델이 tool_calls를 낸다;
4. Host가 Server에 tools/call을 보내고 result를 대화에 다시 쓴다.

MCP를 “또 다른 Function Calling”이라고 부르는 것은 2025–2026년 가장 흔한 오해다. Function Calling은 모델 API 경계에 있고, MCP는 Host ↔ Server 경계에 있다. 현행 스펙은 2026-07-28: 세션 핸드셰이크 없음; 요청이 _meta를 실어 나른다. 세부: MCP 가이드와 마이그레이션 가이드.

MCP가 필요 없을 때: 단일 프로세스, Host에 도구가 고정, 앱 간 재사용 없음 — Tool Calling만으로 충분하다. 필요할 때: 같은 Server를 IDE / 데스크톱에서 재사용, 프로세스 격리, 동적 도구 발견.

Skills: 재사용 가능한 실행 플레이북

Skill은 또 다른 tool이 아니라, 에이전트가 필요할 때 로드하는 절차 지식이다: 언제 켤지, 어떤 단계를 따를지, 무엇을 검사할지, 어떤 도구를 써도 되는지. 엔지니 형태로는 보통 저장소의 SKILL.md(또는 동등한 규칙 팩): 제목, 트리거 조건, 체크리스트, 금지 사항, 관련 스크립트 경로.

Tools / MCP와의 대비:

2026년 IDE 에이전트는 Skills를 일등 시민으로 다룬다: 짧은 작업은 내장 기능; 긴 흐름·팀 규범·운영 플레이북은 Skills에 두어 매번 시스템 프롬프트에 핸드북 전체를 붙이지 않는다. Skill은 어떤 Tools를 호출할지 유도하고 “제출 전에 JSON 검증” 같은 게이트를 걸 수 있다 — 다만 보통 JSON-RPC 메서드는 아니다.

흔한 혼동: 패키징된 shell 스크립트를 Skill이자 Tool이라고 부르는 경우. 경험 법칙 — 모델이 Schema로 한 번 호출해 구조화된 결과를 받으면 Tool; 문서가 에이전트에게 “이 다섯 단계를 따르고, 필요할 때 도구를 호출하라”고 하면 Skill.

Subagents: 격리된 컨텍스트로 위임

Subagent는 부모가 위임하는 자식 세션이다: 보통 자체 컨텍스트 창, 더 좁은 시스템 프롬프트, 더 빡센 도구 허용 목록, 부모에게 돌려주는 요약이 있다. “함수 하나 더”가 아니라 컨텍스트 오염을 막고 병렬 탐색을 가능하게 한다.

전형적 용도:

• 격리 검색 — 자식이 저장소·로그를 파고, 부모는 결론만 남긴다.
• 병렬 작업 — 프론트엔드 변경, 테스트, 카피 번역이 하나의 컨텍스트를 놓고 싸우지 않는다.
• 좁은 역할 — 보안 리뷰, 코드 탐색, CI 진단이 각각 다른 프롬프트와 도구를 갖는다.

실무에서 Subagent는 종종 부모에게 특수 Tool로 노출된다(예: Task / spawn_agent): 인자는 작업 설명과 유형, 반환은 자식의 최종 답이다. 그렇다고 Subagent = Tool은 아니다. Tool은 호출 표면이고, Subagent는 또 하나의 상태 있는 추론 루프다.

Skills와의 경계: Skill은 “어떻게”를 말하고, Subagent는 “다른 세션을 열어 한다”를 결정한다. Skill이 “복잡한 트리아지는 CI Subagent를 반드시 띄운다”고 요구할 수 있고, 그 Subagent는 자신의 Skills와 Tools를 다시 로드한다.

네 계층이 어떻게 쌓이는가

실제 작업은 네 계층을 자주 함께 쓴다. 예: “블로그를 쓰고 배포한다”(예시일 뿐, 이 사이트의 비공개 프로토콜은 아님):

1. 부모가 Skill을 로드한다 — “블로그 게시 체크리스트”: 본문, 로케일, sitemap, IndexNow.
2. 부모가 Subagent를 호출해 과거 기사 템플릿을 탐색하고, 수십 개 HTML이 메인 컨텍스트에 들어오지 않게 한다.
3. 메인 세션이 Tools(파일 읽기/쓰기, shell)로 프론트엔드를 수정한다; 도구가 프로세스 밖이면 발견·호출은 MCP를 탄다.
4. 구조화 파라미터가 나오는 곳마다 JSON Schema가 필드를 고정한다 — 특히 기계를 떠나는 한 번에.

데이터 흐름 한 줄:

User → Host / parent agent
      → Skills (pick the workflow)
      → Subagents (optional delegation)
      → Tool declarations (for the model)
      → optional MCP Client ↔ MCP Server
      → results written back into the dialogue

디버그 치트시트: 모델이 잘못된 도구를 호출 → Tools / Schema; 도구 프로세스가 안 붙음 → MCP; 단계가 자꾸 빠짐 → Skill; 컨텍스트가 폭주하거나 오염 → Subagent.

2026 Agent 스택에서 바뀌는 것

2024년의 “프롬프트에 함수를 쑤셔 넣기”와 비교하면, 2026은 다섯 가지 전환으로 압축된다:

또 하나의 축은 구조화 출력과 도구 인자의 합류다: 비즈니스 JSON, 도구 arguments, MCP inputSchema가 같은 Schema 규율을 공유한다. 구조화 출력이란 무엇인가와 OpenAI vs Gemini 비교를 보라.

제품 측면에서 IDE 에이전트는 더 이상 “채팅 + 자동완성”만이 아니다: 기본 스택에 tool calling, MCP 커넥터, Skills 디렉터리, 생성 가능한 서브에이전트가 있다. 빌더에게 의미하는 바는 API만 넘기는 것이 아니라 — 발견 가능한 도구(MCP/Tools) + 따를 수 있는 워크플로(Skills) + 필요할 때 위임할 수 있는 역할(Subagents)이다.

지금 무엇을 고르고 쓸 것인가

• 도구를 노출하기 전에 Schema를 먼저 써라. additionalProperties: false를 두고 required를 채운 뒤, 이 사이트의 도구로 브라우저에서 샘플 arguments를 검증하라.
• 앱 간 재사용이 필요할 때만 MCP Server로 감싸라. 한 Host에 박힌 단일 스크립트는 MCP가 필요 없다.
• 반복되는 팀 워크플로는 Skills로 코드화하라. 게시·마이그레이션·트리아지·보안 리뷰 — 단계가 안정적이면 “모델에게 또 상기시키기”에 의존하지 마라.
• 컨텍스트가 길어지면 Subagent로 쪼개라. 탐색형·읽기 전용·고노이즈 작업을 위임하고, 결정과 최종 패치는 부모에 남겨라.
• Skill로 Schema를, Subagent로 MCP를 대체하지 마라. 프로세스 ≠ 계약 ≠ 전송. 섞으면 “문서에는 검증하라”고 적혀 있는데 프로덕션에서는 검사가 한 번도 안 돈다.

로컬 JSON 검사 시 inputSchema, 모델 argument 샘플, MCP tools/call 결과 샘플을 저장한 뒤 JSON 검증기와 JSON Diff를 써라. 데이터는 브라우저를 떠나지 않는다 — 온디바이스 우선 프라이버시와 같다.

FAQ

요약

Tools는 모델이 무엇을 호출할 수 있는지 정의하고, MCP는 외부 프로세스에서 도구를 어떻게 발견·호출하는지 정의하며, Skills는 규정대로 일을 어떻게 끝내는지를, Subagents는 컨텍스트를 어떻게 격리·위임하는지를 정의한다. 2026년 Agent 스택은 “채팅창 하나 + 임시 함수 묶음”에서 이 네 계층과 JSON Schema 계약 벨트로 수렴 중이다.

스택은 안에서 밖으로 키워라. Schema와 Tools를 먼저 맞춘 뒤, 재사용·프로세스·컨텍스트 압력에 따라 MCP, Skills, Subagents를 더하라. 출시 전에 로컬에서 샘플을 검증하라 — 모델은 바뀌어도 필드 이름과 required는 바뀌면 안 된다.