MCP vs Skills: AI 에이전트의 '손발'과 '뇌', 왜 지금 분리해야 하는가?

AI 에이전트에 도구를 연결했을 때, 생각보다 불안정해서 당황했던 경험이 있지 않은가.

의도하지 않은 도구 호출이 발생하거나, 동일한 처리를 반복하거나, 기대한 응답이 돌아오지 않는 등의 문제 말이다.

내부적으로는 둘 다 Function Call (함수 호출)일 텐데, 왜 제대로 활용하기 어려운 것일까?

나의 경우, 도구군 (MCP)과 실행 로직 (Skills)을 나누어 정리했더니 동작이 상당히 안정되었다. 최근 커뮤니티의 프레임워크에서도 이러한 '능력과 전략의 분리'를 설계 원칙으로 삼는 것들이 등장하고 있다.

이 기사에서는 MCP와 Skills가 각각 무엇을 해결하는지 정리한다.

결론부터 말하자면, MCP는 AI의 '무엇을 할 수 있는가'를 결정하고, Skills는 '어떻게 하는가'를 결정한다.

퀵 레퍼런스: MCP와 Skills의 차이

1. 공통의 토대: Function Call

차이점을 말하기 전에 공통점을 짚고 넘어가자.

MCP와 Skills는 모두 **Function Call (함수 호출)**이라는 메커니즘 위에 세워져 있다.

원래 '다음 단어를 예측하는 것'뿐이었던 LLM이 Function Call을 통해 외부 세계로 손을 뻗을 수 있게 되었다. 메커니즘은 다음과 같다:

• 개발자가 '호출할 수 있는 함수'의 정의(이름·설명·인수의 타입)를 JSON 스키마로 모델에 전달한다.
• 사용자의 입력에 대해, 모델이 '이 함수를 이 인수로 호출해야 한다'라고 판단하여 구조화된 JSON을 출력한다.
• 애플리케이션 측이 해당 JSON을 받아 실제 함수를 실행한다 (모델 스스로 실행하는 것이 아니다).
• 실행 결과를 모델에 반환하면, 모델이 이를 바탕으로 최종 답변을 생성한다.

캘린더 확인, 메일 전송, 파일 읽기…… 모든 것이 이 흐름으로 움직인다.

MCP는 이 Function Call을 표준 프로토콜로 승화시킨 것이다. Skills는 Function Call을 통해 호출되는 도구군을 어떻게 조합할지를 정의하는 것이다. 관계 방식은 다르지만, 뿌리는 같은 기술 기반 위에 서 있다.

2. MCP란 무엇인가: AI 연결의 'USB 규격'

**MCP (Model Context Protocol)**를 한마디로 정의하면, 'AI를 위한 외부 연결 표준화 프로토콜'이다.

지금까지 Claude나 ChatGPT, 로컬 OSS 모델에 도구를 연결할 때마다 각각 전용 어댑터를 작성해야 했다. 모델을 교체하면 도구 측도 다시 작성해야 했다. 은근히 손이 많이 가는 작업이었다.

MCP는 이러한 바퀴의 재발명을 끝내기 위해 태어났다. PC의 USB 규격을 상상하면 이해하기 쉽다. MCP 사양에 따라 Server를 하나 만들어 두면, 대응하는 AI 클라이언트라면 무엇이든 플러그 앤 플레이 (Plug and Play)로 연결할 수 있다.

MCP가 제공하는 3가지 프리미티브 (Primitives)

MCP는 단순한 '도구 연결'만이 아니다. 사양상 다음과 같은 세 종류의 프리미티브가 정의되어 있다:

통신에는 JSON-RPC 2.0이 사용되며, 로컬 연결 (stdio)과 원격 연결 (Streamable HTTP + OAuth 2.1) 모두를 지원한다.

구체적인 예시:

AI에게 GitHub의 Issue 목록을 읽게 하고 싶은 경우. GitHub MCP Server를 개발하여, Issue 취득을 Tool (도구)로, 리포지토리 정보를 Resource (리소스)로 공개한다. Agent (에이전트)의 기반을 어떻게 교체하더라도, 이 Server (서버)는 그대로 재사용할 수 있다.

즉, **MCP는 "AI가 외부 세계와 연결되기 위한 표준 인터페이스 (Standard Interface)"**이다.

3. Skills란 무엇인가: 베테랑의 "작업 절차서"

MCP를 통해 연결 대상은 갖춰졌다. 하지만 그것만으로는 부족하다.

초보자에게 최고급 메스를 쥐여준다고 해서 수술을 할 수 없는 것과 같은 이치다.

여기서 등장하는 것이 Skills이다.

본질은 구조화된 고도의 Prompt (프롬프트) 문서——인간이 해당 태스크 (Task)에서 쌓아온 베스트 프랙티스 (Best Practice)를 재사용 가능한 형태로 구현한 SOP (표준 작업 절차서)라고 할 수 있다.

제대로 만들어진 Skill은 "기사를 써줘"와 같은 한마디로 끝나지 않는다. 다음과 같은 요소들이 정의되어 있다:

트리거 조건 (Trigger Condition): 어떤 상황에서 이 스킬을 발동할 것인가 -
실행 단계 (Execution Step): 데이터 분석 → 자료 수집 → 초안 작성과 같은 구체적인 흐름 -
출력 포맷 (Output Format): Markdown, JSON, 특정 코드 규약 등 -
에러 발생 시 대처 (Error Handling): MCP 도구 호출이 실패했을 때의 재시도 방법이나 대체 수단 -
Few-Shot: 정답 예시와 오답 예시를 보여주어 모델의 폭주를 방지

Skills는 그 자체로 Function Call (함수 호출)을 수행하는 것이 아니다. 어디까지나 "어떤 도구를, 어떤 순서로, 어떤 조건에서 사용할 것인가"를 모델에게 전달하기 위한 설계도다. 실제 실행은 모델이 Skills의 가이드에 따라 Function Call을 통해 MCP 도구를 호출함으로써 이루어진다.

이전에 에러 처리를 Skill에 정의하는 것을 잊은 적이 있다. 그 결과, Agent가 빈 DB 테이블을 반복해서 검색하게 되어 불필요한 API 호출이 발생했다. 경계 조건 (Boundary Condition)을 Skill에 추가한 이후로는 동일한 문제가 발생하지 않고 있다.

4. 협조 관계: 부품과 조립도

Agent 설계에서 MCP와 Skills를 뒤섞어 버리면 코드는 순식간에 스파게티가 된다.

이 둘은 상하 관계에 있다:

MCP는 능력층 (부품)——표준화된 Tool (도구), Resource (리소스), Prompt Template (프롬프트 템플릿)의 제공. AI에게 "무엇을 할 수 있는지"를 부여한다. -
Skills는 전략층 (조립도)——그 부품들을 어떻게 조합하여 목적을 달성할 것인지에 대한 설계도. AI에게 "어떻게 하는지"를 가르친다. -

예를 들어 하나의 Skill 안에서, "파일 읽기 MCP (Resource)"로 정보를 취득하고, "웹 검색 MCP (Tool)"로 보충 조사를 수행하며, "메일 전송 MCP (Tool)"로 결과를 보고하는 식의 일련의 워크플로우 (Workflow)를 정의할 수 있다.

분리해 두었을 때의 가장 큰 장점은 부품의 추가 (새로운 MCP Server 개발)와 설계도의 개선 (Skills Prompt 수정)을 독립적으로 진행할 수 있다는 것이다. 한쪽을 수정해도 다른 쪽에는 영향을 주지 않는다.

요약

Prompt만으로 시스템 연동을 해결하려 하지 마라. 반대로, 업무 판단을 하드코딩 (Hard-coding)으로 끝내려 하지 마라.

인프라 측을 담당하고 있다면: MCP에 집중하라. 파일 시스템, DB, 외부 API를 표준적인 MCP Server로 공개하고, Tools / Resources / Prompts를 적절히 분류하라. -
업무 로직 측을 담당하고 있다면: Skills를 연마하라. 머릿속의 "업무 방식"을 구조화하여 AI가 헤매지 않는 실행 가이드로 구현하라. -

당신의 Agent는 지금 도구층과 전략층을 나누고 있는가? 아니면 전부 하나로 뭉쳐 있는가? 활용 기준이 있다면 댓글로 꼭 알려달라.