MCP vs. Agent Skills: 차이점은 무엇이며 무엇이 필요한가?

AI 에이전트(AI agents)가 기본적인 채팅 인터페이스를 넘어 완전히 자율적인 시스템으로 진화함에 따라, 개발자들은 동일한 아키텍처 결정 문제에 직면하고 있습니다. 즉, 에이전트가 할 수 있는 일을 실제로 어떻게 확장할 것인가 하는 문제입니다.

현재 그 논의를 지배하고 있는 두 가지 개념은 **Model Context Protocol (MCP)**와 **AI Agent Skills (SKILL.md)**이며, 이들은 마치 서로 경쟁하는 옵션인 것처럼 흔히 논의됩니다. 하지만 이들은 경쟁 관계가 아닙니다. 이들은 멀리서 보면 비슷해 보일 뿐, 서로 다른 두 가지 문제를 해결합니다. 작업에 맞지 않는 잘못된 선택을 하는 것은 팀이 현실과 단절되어 있거나, 연결된 후 무엇을 해야 할지 모르는 에이전트를 구축하느라 스프린트(sprint)를 허비하게 만드는 가장 흔한 방법 중 하나입니다.

다음은 실제 차이점과 각 개념이 내부적으로 어떻게 작동하는지, 그리고 다음 에이전트 구축 시 어떤 것(또는 둘 다)이 실제로 필요한지 판단하기 위한 프레임워크입니다.

핵심 개념: 배지(badge) 대 플레이북(playbook)

팀에 새로운 개발자를 채용한다고 상상해 보세요:

• MCP는 그들의 출입 배지(access badge) 및 권한입니다. 이는 데이터베이스, Slack 채널, GitHub 리포지토리(repos), 클라우드 인프라에 연결할 수 있는 기술적 능력을 부여합니다.
• AI Agent Skills는 그들의 **표준 운영 절차 (Standard Operating Procedures, SOP)**입니다. 이는 당신의 팀이 코드를 어떻게 포맷팅하고, 풀 리퀘스트(pull requests)를 어떻게 작성하며, 운영 환경의 장애(production incidents)를 어떻게 분류(triage)하는지 알려주는 플레이북입니다.

플레이북이 없는 배지는 기술적으로는 모든 시스템에 접근할 수 있지만, 당신의 팀이 실제로 일을 어떻게 처리하기를 원하는지 전혀 모르는 신입 사원을 얻는 것과 같습니다. 그래서 그들은 매번 즉흥적이고 일관성 없게 행동합니다. 배지가 없는 플레이북은 무엇을 해야 할지는 정확히 알지만 아무것도 건드릴 수 없는 사람을 얻는 것과 같습니다. 프로덕션급(Production-grade) 에이전트에는 둘 다 필요하며, 당신이 실제로 어떤 격차를 메우려 하는지 아는 것이 잘못된 해결책을 찾는 것을 방지해 줍니다.

                    "이 에이전트를 어떻게 확장할 것인가?"
                                │
              ┌──────────────────┴──────────────────┐
...

MCP (Model Context Protocol)란 무엇인가?

MCP는 LLM(Large Language Models)이 외부 도구, 데이터베이스 및 API에 연결되는 방식을 표준화하기 위해 설계된 개방형 표준 (open standard)입니다.

MCP 이전에는 에이전트 (agent)를 Postgres나 GitHub와 같은 시스템에 연결하려면 제공업체마다 맞춤형 API 통합을 수행하거나 별도의 함수 호출 (function-calling) 스키마를 작성해야 했습니다. 새로운 도구가 추가될 때마다 새로운 어댑터 (adapter)가 필요했고, 새로운 모델이 나올 때마다 해당 제공업체의 함수 호출 API가 요구하는 형식에 맞춰 어댑터를 다시 작성해야 했습니다. MCP는 이를 범용 브리지 (universal bridge)로 대체합니다. MCP 서버 (MCP server)로서 연결을 한 번만 구축하면, 특정 제공업체 전용의 글루 코드 (glue code) 없이도 모든 MCP 호환 클라이언트 (MCP-compatible client)가 이를 사용할 수 있습니다.

작동 방식

MCP는 JSON-RPC를 기반으로 하는 클라이언트-서버 (client-server) 아키텍처에서 작동합니다:

┌────────────┐        MCP (JSON-RPC)        ┌──────────────────┐
│  AI Agent  │ ◄──────────────────────────► │  MCP Server      │
│  (client)  │                              │ (e.g. GitHub,    │
...

MCP 서버는 연결된 모든 클라이언트에 세 가지 기본 요소 (primitives)를 노출합니다:

• 리소스 (Resources) — 모델이 컨텍스트 (context)로 가져올 수 있는 구조화된 읽기 전용 데이터 (파일, 데이터베이스 행, 티켓 등)
• 도구 (Tools) — 모델이 실제로 호출할 수 있으며 부수 효과 (side effects)를 동반하는 함수 (PR 생성, 쿼리 실행, 메시지 전송 등)
• 프롬프트 (Prompts) — 서버가 클라이언트에 제공하는 재사용 가능한 매개변수화된 프롬프트 템플릿 (prompt templates)

에이전트를 GitHub MCP 서버에 연결하기 위한 최소한의 클라이언트 설정은 다음과 같습니다:

{
  "mcpServers": {
    "github": {
...

연결이 완료되면, 에이전트는 열려 있는 이슈를 나열하거나, 리포지토리 (repo)에서 파일을 읽거나, 풀 리퀘스트 (pull request)를 생성할 수 있습니다. 이는 에이전트가 GitHub의 REST API를 암기했기 때문이 아니라, MCP 서버가 GitHub의 API 표면 (API surface)을 에이전트가 이미 구사할 줄 아는 표준 인터페이스로 번역해주었기 때문입니다.

MCP는 실시간으로 변하는 상태 (live, changing state)에 접근하는 것이 문제일 때 적합한 계층 (layer)입니다: 현재의 재고 수량, 오늘의 지원 티켓, 매분 데이터가 기록되는 데이터베이스 등이 이에 해당합니다. 이러한 데이터는 기록하는 순간 이미 오래된 정보가 되기 때문에, 프롬프트나 정적 파일에 포함할 수 없습니다.

AI 에이전트 스킬 (AI Agent Skills)이란 무엇인가?

MCP가 시스템에 "연결(connecting)"하는 것에 관한 것이라면, 스킬(Skills)은 "전문 지식을 인코딩(encoding expertise)"하는 것에 관한 것입니다. 스킬은 일종의 폴더입니다. 일반적으로 SKILL.md 파일과 선택적인 스크립트, 템플릿 또는 참조 문서로 구성되며, 에이전트에게 귀하의 팀이 원하는 방식대로 특정하고 반복 가능한 작업을 수행하는 방법을 가르칩니다.

---
name: pr-review-checklist
description: 승인 전 풀 리퀘스트(pull request)를 검토할 때 사용합니다. 테스트, 보안 및 롤백 안전성에 대한 이 팀의 표준을 다룹니다.
...

작동 방식: 점진적 공개 (progressive disclosure)

스킬의 배후에 있는 아키텍처 개념은 점진적 공개(progressive disclosure)입니다. 에이전트는 모든 스킬의 전체 내용을 항상 컨텍스트(context)에 로드하지 않습니다. 그렇게 하면 현재 사용하지 않는 절차에 토큰을 낭비하게 됩니다.

항상 컨텍스트에 유지:              요청 시에만 로드: 
┌─────────────────────┐         ┌──────────────────────────┐
│ pr-review: description │  ───► │ Full SKILL.md body      │
...

기본적으로는 이름과 설명(각각 한두 줄 정도)만 상주합니다. 작업이 스킬의 설명과 일치할 때 전체 본문이 로드됩니다. 만약 스킬이 번들로 포함된 스크립트를 참조한다면, 해당 스크립트는 실제로 필요할 때만 로드됩니다. 이것이 스킬을 저렴하게 축적할 수 있는 이유입니다. 커밋 컨벤션(commit conventions), 장애 대응 런북(incident-triage runbook), 데이터 시각화 스타일 가이드 등 수십 개의 스킬을 현재 사용 중이지 않은 것에 대한 컨텍스트 윈도우(context-window) 비용 부담 없이 쌓아둘 수 있습니다.

문제가 반복 가능하고 정적인 지식(절차, 스타일 가이드, 체크리스트 등)일 때 스킬이 적합한 계층입니다. 이 중 어떤 것도 매분 매초 변하지 않으며, 실시간 연결도 필요하지 않습니다. 단지 한 번 가르쳐지면 일치하는 작업이 나타날 때마다 신뢰성 있게 적용되기만 하면 됩니다.

MCP vs. 스킬: 주요 차이점

이들은 경쟁 관계가 아닙니다 — 함께 작동합니다

가장 흔한 실수는 이를 '이것 아니면 저것(either/or)'의 문제로 취급하는 것입니다. 실제 운영 환경(production)에서 가장 강력한 에이전트들은 동일한 작업의 서로 다른 절반을 수행하기 위해 이 두 가지를 모두 사용합니다.

환불 요청을 처리하는 지원 에이전트(support agent)를 예로 들어보겠습니다:

• MCP 서버는 에이전트에게 Stripe(실제 결제 내역), Zendesk(실제 티켓), 그리고 주문 데이터베이스(실제 이행 상태)에 대한 실시간 액세스 권한을 부여합니다.
• **기술 (Skill)**은 에이전트에게 귀사 팀의 실제 환불 정책을 제공합니다. 즉, 어떤 상황이 전액 환불 대상인지 아니면 스토어 크레딧 대상인지, 어떤 어조를 사용해야 하는지, 자동 해결 대신 언제 사람에게 에스컬레이션(escalate)해야 하는지 등을 알려줍니다. 기술 (Skill)을 제거하면 에이전트는 완벽한 시스템 액세스 권한은 갖지만 정책이 없게 되어, 매번 일관성 없이 즉흥적으로 행동하게 됩니다. MCP를 제거하면 정책은 완벽하게 알고 있지만 결제가 실제로 이루어졌는지 확인할 수 없습니다.

┌───────────────────────────────────────────────────────┐
│                     Support Agent                        │
│                                                          │
...

의사결정 프레임워크: 실제로 무엇이 필요한가?

이 작업이 실시간 외부 시스템으로부터의 정보나 동작을 필요로 합니까? 변경되는 데이터베이스, 호출해야 하는 API, 전송해야 하는 메시지 등은 MCP의 영역입니다.

이 작업이 외부 시스템에서 오지 않는 지식을 바탕으로 매번 동일하고 구체적인 방식으로 수행되어야 합니까? 서식 규약(formatting convention), 체크리스트, 도메인 특화 절차 등은 기술 (Skill)의 영역입니다.

둘 다 필요합니까? 대부분의 실제 운영 에이전트들은 둘 다 필요로 합니다. 시스템 액세스와 절차적 지식에 대해 두 개의 별개 질문으로 답하는 것이, 모든 것을 하나의 거대한 프롬프트(prompt)에 쑤셔 넣는 대신 아키텍처를 깔끔하게 유지하는 방법입니다.

핵심 요약 (Key Takeaways)

• MCP는 _접근(access)_을 표준화합니다. 즉, 제공자별로 일회성 통합(one-off integrations)을 수행하는 대신, 공통 클라이언트-서버 프로토콜을 통해 에이전트(agent)를 실시간 외부 시스템에 연결합니다.
• 에이전트 스킬(Agent Skills)은 _지식(knowledge)_을 표준화합니다. 이는 반복 가능한 절차를 파일로 패키징하여, 점진적 공개(progressive disclosure) 방식을 통해 에이전트가 관련이 있을 때만 로드하도록 합니다.
• MCP는 실행 가능한 인프라(서버, 인증, 네트워크 연결)를 필요로 합니다. 반면 스킬(Skills)은 단순한 파일일 뿐이며, 인프라가 필요하지 않고 매우 쉽게 이식(portable)할 수 있습니다.
• 이 두 가지는 동일한 문제의 서로 다른 측면을 해결합니다. 가장 강력한 프로덕션 에이전트(production agents)는 두 가지를 모두 결합합니다. 즉,