AI 에이전트를 개발하는 개발자들은 반복되는 결정에 직면합니다: 에이전트가 코드 이상의 기능 — 웹 검색, 이미지 생성, 비디오, 스토리지 — 이 필요할 때, 어떻게 추가해야 할까요?
세 가지 접근 방식이 논의를 주도하고 있습니다: MCP 서버, Skills, 그리고 Capability Runtime입니다. 이들은 종종 경쟁자로 포지셔닝되지만, 실제로는 그렇지 않습니다. 스택의 서로 다른 계층에서 서로 다른 문제를 해결합니다.
선택하는 방법을 알아보겠습니다.
세 가지 계층, 정의하기
MCP 서버: 전송 계층
MCP(Model Context Protocol)는 AI 에이전트가 외부 도구에 연결하는 방식을 정의하는 개방형 표준입니다. MCP 서버는 검색, 데이터베이스 쿼리, 파일 작업 등 MCP 호환 에이전트가 호출할 수 있는 도구 세트를 노출하는 경량 프로그램입니다.
MCP는 연결 문제를 해결합니다: 에이전트가 외부 도구를 어떻게 발견하고 호출할까요? 인터페이스를 표준화합니다. 각 도구가 고유한 프로토콜을 갖는 대신, 모두 MCP를 사용합니다.
Skills: 지침 계층
Skills(에이전트 스킬 또는 SKILL.md 파일이라고도 함)는 에이전트에게 도구를 어떻게 사용하거나 작업을 수행하는지 가르치는 마크다운 문서입니다. Skill은 "CLI 설치 방법, 사용 가능한 명령어, 오류 발생 시 대처법"을 알려줍니다.
Skills는 지침 문제를 해결합니다: 에이전트가 도구에 연결된 후 무엇을 해야 하는지 어떻게 알 수 있을까요? Skill이 없으면 에이전트는 도구를 볼 수는 있지만 작업 흐름을 이해하지 못합니다.
Capability Runtime: 번들링 계층
Capability Runtime은 이미지 생성, 비디오, 웹 검색, 클라우드 스토리지, 퍼블리싱 등 여러 기능을 하나의 엔드포인트 뒤에 번들로 묶는 단일 CLI(또는 API)입니다. 5개의 별도 MCP 서버를 구성하는 대신, 하나의 도구만 설치하면 됩니다.
Capability Runtime은 통합 문제를 해결합니다: 설정, 자격 증명, 토큰 오버헤드에 빠지지 않으면서 에이전트에 많은 기능을 어떻게 제공할 수 있을까요?
계층 다이어그램
┌─────────────────────────────────────────────┐
│ 당신의 AI 에이전트 │
│ (Claude Code, Cursor, Codex, Windsurf) │
├─────────────────────────────────────────────┤
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────────┐ │
│ │ MCP │ │ Skills │ │ Capability │ │
│ │ 서버 │ │ (SKILL) │ │ Runtime │ │
│ │ │ │ │ │ │ │
│ │ 도구 │ │ 에이전트│ │ 기능 │ │
│ │ 연결 │ │ 지침 │ │ 번들링 │ │
│ └─────────┘ └─────────┘ └─────────────┘ │
│ │
│ 전송 지침 통합 │
│ 계층 계층 계층 │
└─────────────────────────────────────────────┘
이 계층들 중 어느 것도 다른 것을 대체하지 않습니다. 실제로 이들은 함께 사용할 때 가장 효과적입니다:
- MCP는 연결합니다 — 에이전트를 Capability Runtime에 연결
- Skills는 가르칩니다 — 에이전트에게 Runtime 명령어 사용법을 교육
- Runtime은 번들링합니다 — 연결하고 가르칠 대상이 하나뿐이도록 기능을 통합
각 계층의 사용 시점
MCP 서버만 사용하는 경우:
잘 관리되는 MCP 서버가 있는 한두 개의 특정 도구가 필요할 때입니다. 예를 들어, 커스텀 MCP 서버를 통해 회사 내부 데이터베이스에 에이전트를 연결하거나, 기존 MCP 서버를 통해 GitHub 통합을 추가하는 경우입니다.
MCP만으로 충분한 경우:
- 정확히 1~2개의 기능만 필요할 때
- 기능이 특화되어 있을 때 (내부 데이터베이스, API, Jira)
- 서버 구성을 유지 관리할 DevOps 지원이 있을 때
- 1~2개 서버의 토큰 오버헤드가 무시할 만할 때
Skills를 사용하는 경우:
에이전트가 단순히 도구에 접근하는 것이 아니라 작업 흐름을 이해하기를 원할 때입니다. Skill은 단순히 명령어를 나열하지 않습니다 — 설치, 인증, 구성, 검증, 사용의 순서를 가르칩니다.
Skills가 필수적인 경우:
- 도구에 다단계 설정 과정이 있을 때
- 오류 처리가 중요할 때 ("X 오류가 발생하면 Y를 시도하세요")
- 에이전트가 도구로 자립적으로 작업하기를 원할 때
- 작업 흐름을 팀 전체에 공유하려 할 때
Capability Runtime을 사용하는 경우:
4개 이상의 기능이 필요하고 구성 오버헤드가 감당할 수 없을 정도가 될 때입니다. 개인 개발자와 소규모 팀에게 가장 흔한 시나리오입니다.
Capability Runtime이 적합한 경우:
- 에이전트가 이미지, 비디오, 검색, 스토리지, 퍼블리싱이 필요할 때
- 6개의 API 키와 5개의 MCP 서버 구성을 관리하고 싶지 않을 때
- 여러 서버의 토큰 오버헤드가 에이전트 성능에 영향을 미칠 때
- 하나의 설치, 하나의 자격 증명, 하나의 출력 형식을 원할 때
하이브리드 접근법 (대부분의 팀이 실제로 사용하는 방식)
실제로 최고의 설정은 보통 하이브리드입니다:
MCP 서버(특화 도구) + Capability Runtime(공통 기능) + Skills(작업 흐름 지침)
에이전트는 다음에 연결됩니다:
- 1~2개의 MCP 서버 — 내부 또는 특화 도구용 (데이터베이스, Slack, Jira)
- 1개의 Capability Runtime — 공통 기능용 (이미지, 비디오, 검색, 스토리지, 퍼블리싱)
- 1개의 Skill 파일 — 에이전트에게 Runtime 사용법을 가르침
이 방식은 고유한 요구사항에는 최고의 도구를, 나머지에는 최소한의 오버헤드를 제공합니다.
토큰 현실
하이브리드 접근법은 개념적으로 더 깔끔할 뿐만 아니라 측정 가능한 영향을 미칩니다. 각 MCP 서버는 에이전트의 컨텍스트에 도구 설명을 추가합니다. 5개의 MCP 서버를 사용하면 도구 설명만으로 15,000~40,000 토큰을 소모합니다.
2개의 MCP 서버 + 1개의 Capability Runtime을 사용하는 하이브리드 설정은 이를 약 8,00014,000 토큰으로 줄입니다. 실제 작업에 사용할 수 있는 컨텍스트가 1015% 더 확보되는 셈입니다.
흔한 실수들
실수 1: MCP만으로 충분하다고 생각하기
MCP는 도구를 연결합니다. 번들링하거나, 자격 증명을 관리하거나, 토큰 오버헤드를 줄이지 않습니다. 5개 이상의 MCP 서버를 실행 중이라면, 에이전트는 각 서버마다 비용을 지불하고 있습니다.
실수 2: Skills가 도구를 대체한다고 생각하기
Skills는 작업 흐름을 가르칩니다. 기능을 제공하지는 않습니다. Skill은 에이전트에게 이미지 생성 방법을 알려줄 수 있지만, 에이전트는 여전히 그 뒤에 실제 이미지 생성 도구가 필요합니다.
실수 3: Runtime이 MCP를 대체한다고 생각하기
Capability Runtime은 공통 기능을 통합합니다. 특화된 통합의 필요성을 대체하지는 않습니다. 에이전트는 여전히 내부 데이터베이스나 Jira에 연결하기 위해 MCP가 필요합니다. Runtime은 대부분의 에이전트가 공유하는 일반적인 기능을 처리합니다.
한 표로 보는 의사결정
| 필요하다면... | 사용하세요... |
|---|---|
| 1~2개의 특화 도구 | MCP 서버 |
| 에이전트가 작업 흐름을 이해해야 할 때 | Skills |
| 4개 이상의 공통 기능 | Capability Runtime |
| 위의 모든 것 | 하이브리드: MCP + Runtime + Skills |
결론
MCP vs Skills vs Capability Runtime 논쟁은 핵심을 놓치고 있습니다. 이들은 세 가지 경쟁 접근법이 아니라, 동일한 스택의 세 가지 계층입니다.
MCP는 USB-C 포트입니다. Skills는 사용 설명서입니다. Capability Runtime은 연결되는 기기입니다.
에이전트에는 세 가지 모두 필요합니다. 질문은 '어느 것'이 아니라 '각각 얼마나'입니다.
마지막 업데이트: 2026년 5월