MCP vs Skills: 왜 Skills가 컨텍스트 토큰을 절약하는가

MCP는 유용하지만, 대부분의 경우 실제로 필요하지는 않습니다. MCP는 에이전트(Agent)에게 도구(Tools)를 발견하고, API를 호출하며, 외부 시스템과 작업할 수 있는 깔끔한 방법을 제공합니다. 실제로 Skill 파일은 전체 MCP 표면(Surface)을 컨텍스트(Context)로 끌어들이지 않고도 동일한 사용 경로를 설명할 수 있습니다.

하지만 MCP는 공짜가 아닙니다. MCP 자체보다는, 세션의 실제 내용이 무엇인지와 상관없이 모든 세션에 거대한 MCP 표면을 로드하는 습관이 진짜 문제입니다. Claude Code나 Codex 실행 시 한꺼번에 많은 서버를 불러오면, 작업이 단순히 문서를 작성하거나 작은 버그를 수정하는 것일지라도 모델은 즉시 해당 도구 정의(Tool definitions)를 보게 됩니다. 바로 여기서 낭비가 시작됩니다.

항상 켜져 있는 MCP의 숨겨진 비용

모든 MCP 서버는 도구 이름, 설명, 인자 스키마(Argument schemas), 중첩된 파라미터(Nested parameters), 열거형(Enums), 예시, 그리고 때로는 프롬프트(Prompts)나 리소스(Resources)와 같은 메타데이터를 함께 가져옵니다. 유용하긴 하지만, 이 역시 컨텍스트입니다.

소수의 가벼운 도구들을 연결한다면 오버헤드(Overhead)가 짜증스럽긴 해도 관리할 수 있는 수준입니다. 하지만 실제 서비스 스택을 연결하게 되면 비용은 빠르게 복리로 증가합니다.

실제로 다음과 같은 비용을 지불하게 됩니다:

작업 시작 전 도구 발견(Tool discovery)
모델이 사용하지 않을 수도 있는 스키마 텍스트
관련 없는 세션 간의 반복적인 로딩
실제 작업을 밀어내는 추가적인 컨텍스트 압박

마지막 포인트는 사람들이 생각하는 것보다 더 중요합니다. 컨텍스트는 모델이 추론(Reasoning)하는 데 사용하는 활성 작업 세트(Active working set) 역할을 합니다. 정적인 도구 카탈로그(Tool catalogs)에 더 많은 컨텍스트를 소모할수록, 사용자 요청, 저장소 상태(Repo state), 이전 추론, 그리고 실제 답변을 위한 공간은 줄어듭니다.

Anthropic은 이미 MCP의 맥락에서 이 문제를 직접 언급한 바 있습니다. MCP 호출을 통한 코드 실행에 관한 그들의 엔지니어링 포스트는 도구 정의 비대화(Tool-definition bloat)를 지적하며, 모델이 실제 작업을 시작하기도 전에 직접적인 도구 호출이 얼마나 많은 컨텍스트를 소비할 수 있는지를 보여줍니다. 도구 목록은 단순한 설정 노이즈가 아닙니다. 그것은 세션 비용의 일부입니다.

Skills가 더 저렴한 이유

Skills는 다른 경로를 택합니다. Skill 파일은 항상 로드되는 부분을 아주 작게 유지합니다. 보통 이는 프론트매터 (frontmatter)에 기술된 스킬 이름과 짧은 설명만을 의미합니다. 상세한 지침은 SKILL.md에 머물러 있으며, 모델이 실제로 필요할 때만 로드됩니다. 이러한 점진적 공개 (progressive disclosure)가 핵심 비결입니다:

모델은 처음에 가벼운 스킬 이름과 설명을 봅니다.
작업이 일치하면, 스킬 파일을 로드합니다.
스킬에 지원 파일이 필요한 경우, 해당 파일들은 필요할 때만 읽힙니다.

반복되는 운영 지식의 경우, 이는 모든 세션에 전체 MCP 도구 표면 (tool surface)을 쏟아붓는 것보다 훨씬 더 나은 절충안 (tradeoff)입니다. 중요한 순간에만 가이드를 얻고, 그렇지 않을 때는 토큰을 낭비하지 않습니다.

이것이 Skills가 다음과 같은 항목에 더 나은 기본값인 이유입니다:

팀별 특정 절차 (team-specific procedures)
프롬프트 템플릿 (prompt templates)
리뷰 체크리스트 (review checklists)
내부 컨벤션 (internal conventions)
재사용 가능한 작업 지침 (reusable task instructions)
"여기서는 이렇게 합니다" 식의 지식

Skills는 실시간 통합 (live integrations)이 되려는 것이 아닙니다. 저렴하고 재사용 가능한 컨텍스트 (context)가 되려는 것입니다.

Skills는 MCP 레이어를 대체할 수 있습니다

Skills는 지침, 의사 결정, 그리고 실제 사용 패턴을 위한 것이며, 반면 MCP는 대개 추가적인 프로토콜 표면 (protocol surface)에 불과합니다. 실제로 이는 인간이 실제로 상호작용하는 부분에 대해서는 Skills가 MCP를 대체할 수 있음을 의미합니다. 모델은 단순히 서비스를 사용하는 방법을 알기 위해 컨텍스트 안에 전체 도구 카탈로그를 가질 필요가 없습니다.

만약 에이전트가 데이터베이스를 사용하거나, SaaS API를 호출하거나, 실시간으로 인증된 요청을 보내야 한다면, Skill은 여전히 흐름을 명확하게 설명하면서 모델이 필요한 좁은 경로를 유지하도록 할 수 있습니다.

만약 에이전트가 단지 당신의 팀이 어떻게 행동하기를 원하는지만 알면 된다면, Skill이 더 적합한 형태입니다. 대부분의 경우, 그것이 작업의 전부입니다.

실수는 Skill 파일이 훨씬 적은 컨텍스트로 동일한 작업을 수행할 수 있음에도 불구하고, 무거운 프로토콜 레이어를 계속 유지하는 것입니다.

간단한 규칙

기본적으로 Skills를 사용하세요.

MCP는 기초가 아닌 선택 사항으로 취급하세요.

당연한 소리처럼 들리겠지만, 많은 에이전트 설정들이 그 경계를 모호하게 만듭니다. 가능한 모든 도구(tool)를 모든 세션에 쑤셔 넣은 다음, 왜 모델이 더 느려지고, 비용이 많이 들며, 제어하기 어려워지는지 의아해합니다.

실제 사례에서의 모습

만약 40개 또는 50개의 MCP 도구를 노출하는 서비스가 있다면, 이를 매일 사용하는 개발자에게는 괜찮을 수 있습니다. 하지만 대부분의 세션에는 50개의 도구가 모두 필요하지 않습니다. 많은 경우, 에이전트는 사용자 조회, 레코드 업데이트, 티켓 생성, 또는 요청을 안전하게 포맷하는 것과 같이 하나의 좁은 절차(procedure)만을 필요로 합니다.

Skills는 모델에게 해당 작업을 정확히 어떻게 처리해야 하는지, 어떤 필드가 중요한지, 무엇을 하지 말아야 하는지, 그리고 어떤 예외 케이스(edge cases)를 주의해야 하는지를 알려줄 수 있습니다. 모델이 이를 잘 수행하기 위해 항상 켜져 있는 거대한 MCP 도구 카탈로그를 가질 필요는 없습니다.

이것이 진정한 토큰 절약입니다. 운영 플레이북(operating playbook)만 있으면 될 때, 전체 런타임 표면(runtime surface)에 대한 비용을 지불하는 것을 중단하게 됩니다.

MCP를 Skill로 변환하는 방법

만약 재사용 가능한 API 래퍼(wrapper)처럼 동작하는 MCP 서버를 가지고 있다면, 유용한 부분들을 Skill로 전환해야 합니다.

실제로 무엇이 필요한지 검사하는 가장 쉬운 방법은 MCPViewer 도구를 사용하는 것입니다.

워크플로우는 다음과 같습니다:

MCPViewer 도구를 엽니다.
MCP 서버 URL을 붙여넣습니다.
Analyze를 클릭합니다.
아래로 스크롤하여 Download spec을 클릭합니다.
다운로드된 JSON을 복사합니다.
이를 SKILL.md 파일에 Skill의 콘텐츠 참조(content reference)로 붙여넣습니다.
Skill 설명을 <서비스 이름> 서비스를 위한 API 사용법과 같이 설정합니다.

이 흐름은 유용한 서비스 지식을 더 가볍고 재사용 가능한 Skill로 추출하여, 모델이 모든 도구를 영구적으로 유지하려고 시도하는 대신 필요할 때만 로드할 수 있게 합니다.

서비스가 자주 변경된다면 Skill을 좁게 유지하고 API가 변경될 때 업데이트하세요. 서비스가 안정적이라면, Skill은 전체 MCP 표면보다 지침(instructions)을 위한 더 나은 장기적 저장소가 됩니다.

팀을 위한 좋은 패턴

대부분의 팀에게 가장 좋은 설정은 모든 곳에 Skill을 배치하고, 반드시 기억해야 하는 사항들에 대해 Skill 파일(skill files)을 사용하는 것입니다:

요청(requests)을 포맷팅하는 방법
출력을 검토(review)하는 방법
팀 컨벤션 (team conventions)
승인 규칙 (approval rules)
안전 운영 절차 (safe operating procedures)

만약 서비스에 여전히 실시간 실행(live execution)이 필요하다면, Skill은 전체 프로토콜 표면(protocol surface)을 모든 세션에 끌어들이지 않고도 해당 경로를 설명할 수 있습니다. 이는 절차적 지식(procedural knowledge)이 더 이상 거대한 도구 레지스트리(tool registry)에 흩어져 있지 않게 하므로, 에이전트를 가볍게 유지하고 시스템을 더 관리하기 쉽게 만듭니다.

또한 실패(failure)에 대해 추론하기가 더 쉬워집니다. 만약 Skill이 잘못되었다면 지침(instructions)을 업데이트하면 됩니다. 서비스 사용 방식을 변경해야 한다면 Skill을 업데이트하면 됩니다. 이들은 서로 다른 작업이며, 이를 분리하여 유지하는 것이 도움이 됩니다.

진짜 목표: 컨텍스트 낭비 감소

문제는 단순히 비용 측면에서의 토큰 비용만이 아닙니다. 바로 컨텍스트 낭비(context waste)입니다. 세션에 밀어 넣는 모든 추가적인 도구 정의(tool definition)는 모델이 실제 작업을 해결하는 동안 떠안아야 하는 짐이 하나 더 늘어나는 것을 의미합니다.

Skill을 사용하면 모델이 정말로 정보가 필요할 때까지 그 비용을 유예할 수 있습니다. Skill은 반복되는 워크플로(workflows), 기업 지식(company knowledge), 그리고 재사용 가능한 운영 규칙(operating rules)에 적합합니다.

만약 MCP가 운송 수단(transport)이라면, Skill은 메모리(memory)입니다.

FAQ

MCP가 나쁜가요?

MCP가 주요 문제는 아닙니다. 문제는 Skill 파일이 훨씬 적은 컨텍스트로도 충분히 해낼 수 있는 상황임에도 불구하고, 그것이 필요하지 않은 세션에 MCP를 로드하는 것입니다.

Skill이 MCP를 대체하나요?

네, 대부분의 실질적인 사례에서 그렇습니다. 목표가 에이전트에게 서비스 사용법을 가르치는 것이라면, Skill이 MCP를 대체하여 컨텍스트를 훨씬 더 작게 유지할 수 있습니다.

왜 Skill이 토큰을 절약하나요?

항상 로드되는 부분이 작기 때문에, 모델은 먼저 Skill의 이름과 설명을 확인한 다음, 해당 Skill이 관련이 있을 때만 전체 SKILL.md를 로드합니다.

어떤 종류의 콘텐츠가 Skill에 포함되어야 하나요?

재사용 가능한 지침 (Instructions), 절차 (Procedures), 체크리스트 (Checklists), 포맷팅 규칙 (Formatting rules), 그리고 팀별 가이드라인 (Team-specific guidance) 등이 해당됩니다. 만약 콘텐츠의 내용이 주로 '어떻게 행동해야 하는가'에 관한 것이라면, 그것은 Skill에 속합니다.

어떤 종류의 콘텐츠가 MCP에 포함되어야 하나요?

특별한 경우가 아니라면 매우 적습니다. 동일한 운영 지식 (Operational knowledge)은 보통 Skill에 더 적합하기 때문입니다.

동일한 서비스에 대해 MCP와 Skill을 모두 유지할 수 있나요?

네. 그것이 종종 가장 좋은 설정입니다. MCP는 런타임 연결 (Runtime connection)을 처리하고, Skill은 이를 잘 사용하기 위한 플레이북 (Playbook)을 처리합니다.

왜 mcpview.teamcopilot.ai를 사용해야 하나요?

무엇을 MCP로 남겨두고 무엇을 더 가벼운 Skill로 전환할지 결정하기 전에, 실제 MCP 표면 (Surface)을 검사할 수 있게 해주기 때문입니다. 이를 통해 전환 과정에서 추측을 줄일 수 있습니다.

MCP 스펙 (Spec)이 변경되면 어떻게 하나요?

다른 문서나 래퍼 (Wrapper)를 업데이트하는 것과 동일한 방식으로 Skill을 업데이트하세요. 만약 API가 자주 변경된다면, 유지보수가 용이하도록 Skill의 범위를 좁게 유지하세요.

변환된 Skill에 가장 적합한 짧은 설명은 무엇인가요?

<서비스 이름> 서비스를 위한 API 사용법과 같이 구체적이고 평범한 것이 좋습니다. 이러한 패턴은 불필요한 말을 낭비하지 않으면서 모델에게 해당 Skill의 용도를 정확하게 알려줍니다.