MCP vs Skill — AI 에이전트에게 일 시키는 두 가지 방법

AI 코딩 에이전트를 쓰다 보면 한 가지 근본적인 질문에 부딪힌다. "이 놈한테 어떻게 일을 시키지?"

프롬프트를 잘 쓰는 것도 중요하지만, 에이전트가 외부 도구를 쓰고, 규칙을 따르고, 워크플로우를 수행하려면 그보다 한 단계 위의 구조가 필요하다. 지금 그 역할을 두고 경쟁하는 두 가지 접근법이 있다. MCP(Model Context Protocol)와 Skill이다.

이 글은 두 방식을 실제로 써본 경험을 바탕으로, 각각 뭘 잘하고 뭘 못하는지, 언제 뭘 써야 하는지를 정리한 것이다.

MCP가 뭔데

MCP는 Anthropic이 2024년 11월에 공개한 오픈 프로토콜이다. AI 에이전트가 외부 도구, 데이터소스, 서비스에 접근하는 방식을 표준화한 것이다. 한 마디로 AI 에이전트용 USB 포트 같은 거다.

구조는 이렇다. MCP 서버가 도구(tool) 목록을 정의하고, 클라이언트(에이전트)가 이 서버에 연결해서 도구를 호출한다. 2025년 3월에는 OpenAI도 공식 채택했고, Google DeepMind, Cursor, Figma, Replit, Zapier, Playwright까지 지원하면서 사실상 업계 표준이 됐다.

예를 들어 Vercel MCP 서버를 연결하면, 에이전트가 공식 문서를 검색하거나, 프로젝트 목록을 조회하거나, 배포 로그를 확인할 수 있게 된다.

// Claude Code에서 Vercel MCP 서버 연결
claude mcp add --transport http vercel https://mcp.vercel.com
 
// 연결 후 에이전트가 사용할 수 있는 도구들:
// - Vercel/Next.js/AI SDK 공식 문서 검색
// - 프로젝트, 배포 목록 조회 및 상세 정보
// - 빌드 로그, 함수 실행 로그 조회
// - 도메인, 환경변수 목록 확인
// - 팀 멤버 및 설정 조회

Playwright MCP 서버를 연결하면 브라우저 자동화가 가능해지고, GitHub MCP 서버를 연결하면 PR 생성이나 이슈 관리를 할 수 있다. 2026년에는 이미지, 비디오, 오디오 같은 멀티미디어 지원도 로드맵에 올라와 있다.

Skill이 뭔데

Skill은 조금 다른 접근이다. 도구를 연결하는 게 아니라, 에이전트의 행동 지침을 마크다운 파일로 정의하는 방식이다. "언제 이 지침을 적용하고, 어떤 순서로 작업하고, 무엇을 주의해야 하는지"를 문서 하나에 담는다.

Anthropic이 2025년 10월에 Claude Skills를 출시했고, 2026년 3월 기준으로 공식 Skills 저장소가 GitHub에서 87,000+ 스타를 받으며 빠르게 성장하고 있다. Anthropic은 MCP처럼 Skills도 오픈 표준으로 공개했다 — 같은 Skill이 Claude뿐 아니라 다른 AI 플랫폼에서도 동작할 수 있도록.

각 Skill은 SKILL.md 파일로 정의된다. Claude는 3단계로 Skill을 처리한다.

1. 메타데이터 (이름 + 설명, ~100 토큰) — 항상 컨텍스트에 로드. 이걸로 관련성 판단.

2. 파일/명령어 패턴 매칭 — 개발자가 특정 파일을 열거나 명령어를 실행하면 자동 주입.

3. 전체 지침 로드 — 매칭되면 SKILL.md의 전체 내용이 컨텍스트에 들어감.

---
name: nextjs
filePattern: ["**/app/**/*.tsx", "**/next.config.*"]
bashPattern: ["next (dev|build|start)"]
priority: 90
---
 
# Next.js App Router Expert
 
- 기본은 Server Component. use client는 필요할 때만.
- proxy.ts는 middleware.ts를 대체함 (Next.js 16+)
- 모든 request API는 async: await cookies(), await headers()
- Cache Components로 정적/동적 혼합 가능
...

개발자가 app/page.tsx를 열면, 파일 패턴이 매칭되어 Next.js Skill이 자동 주입된다. 프롬프트를 매번 붙여넣는 것과 달리, Skill은 한 번 저장하면 관련 작업마다 자동으로 로드된다. 2025년 12월부터는 팀 전체에 워크스페이스 단위로 배포하는 것도 가능해졌다.

핵심 차이: 도구 vs 지침

가장 근본적인 차이는 이거다.

MCP는 "뭘 할 수 있는지"를 정의하고, Skill은 "어떻게 해야 하는지"를 정의한다. DB를 조회하려면 MCP가 필요하고, "DB 조회할 때 인덱스 힌트를 꼭 확인해"라는 규칙은 Skill이 담당한다.

MCP의 장점과 한계

장점

• 업계 표준 — Anthropic, OpenAI, Google이 모두 채택. 한 번 만든 MCP 서버를 Claude, ChatGPT, Cursor 어디서든 사용 가능.

• 실시간 데이터 접근 — DB 조회, API 호출, 파일시스템 접근, 브라우저 자동화 같은 런타임 동작이 가능.

• 인증/권한 내장 — OAuth 2.1 지원으로 보안이 프로토콜 수준에서 해결됨.

• 풍부한 생태계 — GitHub, Slack, PostgreSQL, Playwright 등 수백 개의 공개 MCP 서버가 이미 존재.

한계

• 도구 선택의 불확실성 — 도구 목록을 동적으로 던져주면, AI가 언제 어떤 도구를 써야 할지 판단 품질이 들쭉날쭉하다. 10개 넘어가면 체감된다.

• 인프라 오버헤드 — 서버 프로세스를 띄우고, 연결을 유지하고, 에러 핸들링을 해야 한다. 단순한 규칙 하나 전달하려고 서버를 띄우는 건 과하다.

• 워크플로우 정의 부재 — "1번 하고 2번 하고, 실패하면 3번 해"같은 순서 있는 작업 흐름을 정의하기 어렵다. 도구는 있지만 레시피가 없는 느낌.

Skill의 장점과 한계

장점

• 제로 인프라 — 마크다운 파일 하나면 끝. 서버도 프로세스도 없다. 배포할 것도 없다.

• 자동 매칭 — 파일 패턴, 명령어 패턴으로 필요한 순간에 자동 주입. 개발자가 의식적으로 호출할 필요 없다. 프롬프트를 매번 붙여넣는 것과 근본적으로 다르다.

• 워크플로우 정의 가능 — 체크리스트, 단계별 프로세스, 조건 분기까지 자연어로 정의 가능. "테스트 먼저 작성하고, 구현하고, 빌드 확인하고, 커밋"같은 흐름을 문서 하나에 담을 수 있다.

• 팀 지식 축적 — 코딩 컨벤션, 아키텍처 결정, 삽질 기록을 Skill로 남기면, 새로운 에이전트 세션에서도 같은 실수를 반복하지 않는다. 워크스페이스 단위 배포로 팀 전체가 공유 가능.

한계

• 런타임 동작 불가 — API를 호출하거나 DB를 조회하는 건 Skill로 안 된다. 그건 도구(Tool)의 영역.

• 컨텍스트 윈도우 소비 — Skill이 많아지면 에이전트의 컨텍스트 윈도우를 잡아먹는다. 한 번에 3개까지만 주입하는 제한을 두는 이유다.

• 표준화 진행 중 — MCP만큼 범용적이진 않다. Anthropic이 오픈 표준으로 공개했지만, 아직 플랫폼별 구현 차이가 있다. Claude Code의 Skill과 Cursor의 Rule은 비슷하지만 100% 호환은 아니다.

실전 비교: 같은 작업, 다른 접근

"Vercel에 배포할 때 환경변수 확인하고 프리뷰 배포 먼저 하기"라는 작업을 예로 들어보자.

MCP 방식

Vercel MCP 서버를 연결한다. 에이전트는 프로젝트의 환경변수 목록을 조회하고, 배포 상태를 확인하고, 빌드 로그를 읽을 수 있게 된다. 하지만 "프리뷰 먼저"라는 순서나 "환경변수 빠진 거 없는지 확인"이라는 판단 기준은 에이전트의 재량이다.

Skill 방식

배포 Skill을 만든다. "1. vercel env ls로 환경변수 확인 2. 빠진 키가 있으면 사용자에게 경고 3. vercel deploy로 프리뷰 먼저 4. 프리뷰 URL 확인 후 vercel --prod"라는 체크리스트를 정의한다. 에이전트는 이 순서를 따른다.

같이 쓰면?

실은 이게 정답이다. MCP로 Vercel 프로젝트 정보를 읽는 능력을 주고, Skill로 "이 순서대로 해"라는 지침을 준다. 도구는 MCP, 레시피는 Skill. 서로 경쟁하는 게 아니라 보완하는 관계다.

그래서 MCP가 망하는 건가?

아니다. MCP가 밀리는 건 MCP를 잘못 쓰는 영역에서다.

규칙 전달, 워크플로우 정의, 코딩 컨벤션 같은 걸 MCP 도구로 해결하려 하면 과하다. 서버 띄우고 JSON-RPC 통신해서 전달할 내용이 "TypeScript strict mode 쓰세요" 한 줄이면, 그건 마크다운 파일이면 충분하다.

반대로 외부 시스템과 실시간으로 상호작용하는 영역에서는 MCP를 대체할 게 없다. DB 조회, Git 조작, 브라우저 자동화, 클라우드 API 호출 — 이건 텍스트 지침으로 해결이 안 된다.

앞으로 어떻게 될까

개인적인 예측은 이렇다.

• MCP는 인프라 레이어로 정착한다. USB처럼, 당연히 있는 건데 의식하지 않는 존재가 된다. 2026년에는 멀티미디어 지원까지 로드맵에 올라와 있으니, 에이전트가 "보고 듣는" 시대가 온다.

• Skill은 개발 문화의 일부가 된다. README에 프로젝트 설명을 쓰듯, SKILL.md에 "이 프로젝트에서 에이전트가 지켜야 할 규칙"을 쓰게 된다. 이미 GitHub에서 87,000+ 스타를 받으며 커뮤니티가 폭발적으로 성장하고 있다.

• 결국 경계가 흐려진다. MCP 서버가 도구뿐 아니라 지침(prompts)도 제공하기 시작했고, Skill도 도구 호출을 트리거할 수 있게 진화하고 있다. 두 표준 모두 Anthropic이 오픈 소스로 공개했다는 점에서, 통합은 시간문제다.

중요한 건, 둘 다 결국 같은 문제를 풀려는 거라는 점이다. AI 에이전트가 우리가 원하는 대로 일하게 만드는 것. 도구를 주든, 규칙을 주든, 최종 목표는 같다.

결론

MCP vs Skill은 "어느 쪽이 이기나"의 문제가 아니다. 도구 연결은 MCP, 행동 지침은 Skill. 이 구분만 명확히 하면 된다.

실전에서는 대부분 둘 다 쓰게 된다. DB는 MCP로 연결하고, "쿼리 날리기 전에 explain 먼저 해"는 Skill로 정의하는 식이다. 경쟁이 아니라 레이어가 다른 거다.

AI 에이전트 시대에 개발자의 역할은 "코드를 짜는 것"에서 "에이전트가 코드를 잘 짜도록 환경을 설계하는 것"으로 확장되고 있다. MCP와 Skill은 그 환경의 두 축이다.