Skills vs MCP: How AI tools have evolved
Eighteen months ago, MCP was the thing. Every demo and chatbot connector was running on MCP under the...
개요 #
불과 1년 반 전만 해도 MCP는 그 자체로 화두였다. 눈에 띄는 데모와 챗봇 연동 뒤에는 거의 예외 없이 MCP가 돌아가고 있었다. 그런데 요즘은 이야기의 중심이 Skills로 옮겨갔다. 그렇다면 MCP와 Skills는 서로 경쟁하는 기술일까, 아니면 같은 문제를 다른 각도에서 바라본 것일까? 이번 글은 그 질문을 정리한 것이다.
MCP가 실제로 하는 일 #
MCP의 역할은 생각보다 단순하다. 자연어를 매개로 모델에게 API와 파일 시스템을 프로그래밍적으로 다룰 권한을 넘겨주는 것이다. 모델이 외부 세계에 손을 뻗을 수 있게 해주는 배선 역할인 셈이다.
문제는 비용이다. MCP를 붙이면 수백 줄에 달하는 도구 정의(tool definition)가 컨텍스트에 통째로 올라간다. 정작 이번 작업에서 쓰지도 않을 도구들의 명세까지 전부 로딩되면서 컨텍스트가 불필요하게 부풀어 오른다. 도구가 많아질수록 이 부담은 눈덩이처럼 커진다.
Photo by RDNE Stock project on Pexels
Skill이란 무엇인가 #
Skill의 정체는 다소 김이 빠질 만큼 소박하다. 재사용 가능한 프롬프트를 담은 마크다운 파일, 그게 전부다. 거창한 프레임워크가 아니라 "이럴 땐 이렇게 하라"는 지침을 글로 적어둔 문서에 가깝다.
여기서 핵심은 **점진적 공개(progressive disclosure)**다. 에이전트는 20개의 Skill이 "존재한다"는 사실만 알고 있으면 되고, 각 Skill의 전체 지침을 처음부터 전부 읽어들일 필요가 없다. 실제로 그 Skill이 필요한 순간에만 상세 내용을 펼쳐본다. MCP가 도구 명세를 몽땅 올려두느라 컨텍스트를 잡아먹던 것과 정반대의 접근이다.
둘은 경쟁자가 아니다 #
그래서 MCP와 Skills는 서로를 대체하는 관계가 아니다. 오히려 층위가 다르다. Skill은 에이전트에게 MCP 도구를 어떻게 써야 하는지까지 가르칠 수 있다. MCP가 연결을 담당한다면, Skill은 그 연결을 언제 어떻게 활용할지에 대한 안내서 역할을 한다.
원문에서 가장 인상적인 문장은 이것이다. "지금 가장 뜨거운 프로그래밍 언어는 영어다." Skill 덕분에 개발자가 아닌 사람도 지침을 직접 쓰고, 고치고, 팀 전체와 공유할 수 있다. 코드 한 줄 없이도 팀의 모든 에이전트를 더 빠르게 만들 수 있다는 뜻이다.
이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.