2024년 하반기, MCP(Model Context Protocol) 열풍이 불었습니다. Anthropic이 주도하고 오픈소스로 공개한 이 프로토콜은 "AI계의 USB-C"라는 별명과 함께 빠르게 퍼져나갔죠. 개발자분들은 MCP 서버 만드는 법을 공부하고, JSON-RPC 스펙을 들여다보고, Transport 인터페이스를 구현해 보셨을 겁니다. 비개발자분들은 "이 MCP 깔면 성능 올라간다더라" 하면서 더 좋은 MCP를 찾아다니셨을 거고요. Cursor에 MCP 연결하고, Claude Desktop에 MCP 세팅하고, 다들 한 번쯤은 해보셨을 겁니다.

그런데 어느 순간 이상한 생각이 들었습니다. "잠깐, LLM은 자연어를 이해하는 모델 아닌가? 그런데 왜 이렇게 정형화된 프로토콜이 필요하지?" 이 질문이 이 글의 출발점입니다. 결론부터 말씀드리면, MCP의 근본적인 전제에 의문을 제기하고 싶습니다. 그리고 그 대안으로 떠오르고 있는 '클로드 스킬(Claude Skills)'이 왜 더 LLM의 본질에 맞는 접근인지 이야기해 보려고 합니다.

지금은 바이브 코딩 시대입니다. AI와 함께 무언가를 만드는 것이 더 이상 개발자만의 영역이 아니죠. 이 시대에 진짜 필요한 건 복잡한 프로토콜을 설치하는 게 아니라, 자신만의 워크플로를 자유롭게 만들어내는 능력입니다.

이 글을 끝까지 읽으시면 다음을 얻어가실 수 있습니다.

MCP가 무엇이고, 왜 한계가 있는지
클로드 스킬이 어떻게 다른 접근을 취하는지
실제로 스킬을 만들어 활용하는 실전 팁들

그럼 시작해 보겠습니다.

MCP, 그래서 정체가 뭔가요?

MCP를 이해하려면 먼저 'Function Call'이라는 개념부터 알아야 합니다. 원래 LLM은 텍스트만 생성하는 모델이었습니다. 질문하면 답변하고, 글을 써달라면 글을 쓰고. 그런데 어느 순간부터 LLM이 "도구"를 쓸 수 있게 됐습니다. 날씨를 물어보면 실제 날씨 API를 호출하고, 파일을 읽어달라면 진짜 파일을 읽어오는 식으로요.

이게 바로 Function Call입니다. LLM에 "너 이런 도구들 쓸 수 있어"라고 알려주면, LLM이 상황에 맞게 적절한 도구를 골라서 호출하는 거죠. 사용자가 "서울 날씨 어때?"라고 물으면, LLM이 스스로 판단해서 날씨 API를 호출하고 그 결과를 바탕으로 답변합니다.

그런데 문제가 있었습니다. 각 서비스마다 도구를 연결하는 방식이 다 달랐던 거죠. A 서비스는 이렇게, B 서비스는 저렇게... 표준이 없으니 매번 새로 배워야 했습니다. MCP는 이 문제를 해결하려고 등장했습니다. "도구 목록을 가져오는 방법"과 "도구를 실행하는 방법"을 하나의 규격으로 통일한 거죠. 쉽게 말해 MCP 서버에 "너 뭐 할 수 있어?"라고 물으면 도구 목록을 알려주고, "이거 실행해 줘"라고 하면 실행해 주는 방식입니다.

그래서 "AI계의 USB-C"라고 불렸습니다. USB-C가 충전기, 모니터, 외장하드를 하나의 포트로 연결하듯이, MCP는 다양한 외부 도구를 하나의 방식으로 연결할 수 있게 해준다는 거였죠. 여기까지만 보면 완벽해 보입니다. 그런데 정말 그럴까요?

MCP에 대한 흔한 오해들

MCP 열풍이 불면서 몇 가지 오해도 함께 퍼졌습니다.

첫 번째 오해는 "MCP를 달면 성능이 올라간다"는 것입니다. 커뮤니티에서 "이 MCP 설치하니까 훨씬 좋아졌어요"라는 후기를 많이 보셨을 겁니다. 하지만 MCP는 마법의 성능 부스터가 아닙니다. MCP는 그저 LLM과 외부 도구를 연결하는 '규격'일 뿐이에요. USB-C 케이블을 샀다고 컴퓨터 성능이 올라가지 않는 것과 같습니다.

두 번째 오해는 "MCP만 있으면 다 된다"는 것입니다. MCP 서버가 있어도, 이걸 실제로 활용하려면 '호스트 앱'이 필요합니다. 호스트 앱이란 LLM과 대화하면서 필요할 때 MCP 서버에 도구 호출을 요청하는 프로그램이에요. Claude Desktop이나 Cursor 같은 앱들이 바로 이 호스트 앱입니다.

MCP 서버가 "나 이런 도구 있어요"라고 말해줘도, 그걸 언제 어떻게 쓸지 판단하고 실행하는 건 호스트 앱의 몫입니다. 그래서 같은 MCP 서버를 연결해도 호스트 앱에 따라 결과가 달라질 수 있죠.

세 번째로 알아야 할 점이 있습니다. MCP 프로토콜 자체는 오픈소스지만, 정작 잘 만들어진 호스트 앱들은 오픈소스가 아닙니다. Claude Desktop도, Cursor도 핵심 코드는 공개하지 않고 있어요. MCP 서버는 누구나 만들 수 있지만, 그걸 제대로 활용하는 호스트 앱을 만드는 건 또 다른 문제인 거죠.

결국 MCP의 진짜 가치는 호스트 앱이 얼마나 잘 만들어졌느냐에 달려 있습니다. 그런데 여기서 더 근본적인 질문이 떠오릅니다.

잠깐, LLM에 왜 정형화된 프로토콜이 필요하죠?

여기서 한 발짝 물러서서 생각해 볼게요. LLM은 무엇에 특화된 모델인가요? 바로 비정형 데이터입니다. 자연어 처리요. "이거 해줘"라고 해도 알아듣고, "이것 좀 부탁드립니다"라고 해도 알아듣고, "해주시면 감사하겠습니다"라고 해도 알아듣습니다. 정해진 형식이 아니어도 말만 통하면 이해하는 게 LLM의 본질입니다.

그런데 MCP는 어떤가요? 정형화된 프로토콜입니다. "도구 목록을 가져오려면 tools/list 엔드포인트를 호출하세요", "도구를 실행하려면 tools/call 엔드포인트에 정해진 형식으로 요청하세요". 기존 프로그래밍처럼 특정한 형태의 요청을 특정한 주소에 보내야 특정한 응답이 나오는 구조입니다.

이상하지 않나요? 비정형 데이터를 자유자재로 다루는 LLM에게, 왜 정형화된 프로토콜을 씌우고 있는 걸까요?

사실 더 간단한 방법이 있습니다. 그냥 마크다운 파일 하나에 이렇게 쓰면 됩니다: "사용자가 날씨를 물어보면 weather.sh 스크립트를 실행해 줘" LLM은 이걸 읽고 이해합니다. 사용자가 "서울 날씨 어때?"라고 물으면, 스스로 판단해서 해당 스크립트를 실행합니다. list 엔드포인트도 필요 없고, call 엔드포인트도 필요 없습니다. 말을 알아듣으니까요.

MCP의 진짜 문제는 여기 있습니다. 정형화된 프로토콜을 만들고 유지하는 게 어렵습니다. 기존 서비스에 MCP를 붙이려면 모든 기능을 MCP 규격에 맞게 매핑하는 작업이 필요합니다. 개발자에게도 부담이고, 비개발자에게는 아예 진입장벽이 됩니다. 자연어로 "이 서비스는 이런 기능이 있고, 이렇게 호출하면 돼"라고 써두면 LLM이 알아서 이해하는데, 왜 굳이 복잡한 프로토콜을 거쳐야 할까요? 이 질문에 대한 답이 바로 '클로드 스킬(Claude Skills)'입니다.

클로드 스킬, 자연어로 워크플로를 정의하다

클로드 스킬은 Anthropic이 내놓은 새로운 접근입니다. MCP처럼 정형화된 프로토콜이 아니라, 그냥 자연어로 "이럴 때 이렇게 해줘"라고 적어두는 방식이죠. 스킬의 실체는 단순합니다. 폴더 안에 SKILL.md 파일을 만들고, 거기에 워크플로를 자연어로 설명하면 됩니다. Claude가 이 파일을 읽고 상황에 맞게 알아서 실행합니다.

예를 들어 이런 식입니다.

name: db-setup
description: D1 데이터베이스 연동 워크플로. "DB 연동", "데이터베이스 설정", "D1 추가" 등의 요청 시 트리거됩니다.

## 워크플로
1. 먼저 wrangler.toml 파일이 있는지 확인합니다.
2. D1 데이터베이스가 이미 생성되어 있는지 확인합니다.
3. 없다면 `wrangler d1 create` 명령으로 생성합니다.
4. drizzle ORM 관련 패키지를 설치합니다.
5. src/server/db 폴더에 schema.ts와 index.ts를 생성합니다.
6. drizzle.config.ts 설정 파일을 생성합니다.
7. 마이그레이션을 실행하여 테이블을 생성합니다.

## 주의사항
- 기존 DB가 있으면 덮어쓰지 않고 연결만 합니다.
- 마이그레이션 전 반드시 백업 여부를 확인합니다.

이게 전부입니다. JSON-RPC 스펙도 없고, 엔드포인트 매핑도 없습니다.

`name`은 스킬의 이름, `description`은 이 스킬이 무엇을 하고 언제 트리거 되는지를 설명합니다. "DB 연동", "데이터베이스 설정" 같은 키워드가 나오면 이 스킬이 활성화되는 거죠. 본문에는 워크플로와 주의 사항을 자연어로 적으면 됩니다.

MCP와 비교해 보면 차이가 명확합니다. MCP로 같은 기능을 구현하려면? 서버를 띄우고, tools/list에 도구 목록을 정의하고, tools/call에 각 도구의 실행 로직을 구현하고, 호스트 앱과 연결해야 합니다. 개발자도 꽤 손이 가는 작업이고, 비개발자는 시작조차 어렵습니다.

클로드 스킬로 같은 기능을 구현하려면? 폴더 만들고, SKILL.md 파일에 자연어로 적으면 끝입니다. 비개발자도 할 수 있습니다. 어떤 동작을 수행하면 좋을지를 한글로 타이핑할 뿐이니까요. 이것이 LLM의 본질에 맞는 접근입니다. 말을 알아듣는 모델에게, 말로 지시하는 거죠. MCP가 LLM을 기존 프로그래밍 패러다임에 끼워 맞추려 했다면, 클로드 스킬은 LLM의 강점을 그대로 활용합니다.

클로드 스킬, 어떻게 잘 쓸 수 있을까?

클로드 스킬을 효과적으로 사용하기 위한 공식 모범 사례가 있습니다. Anthropic에서 제공하는 문서에 자세히 나와 있는데, 간단히 핵심만 짚어보겠습니다.

첫째, 간결함이 중요합니다. Claude는 이미 똑똑합니다. PDF가 뭔지, 라이브러리가 어떻게 작동하는지 일일이 설명할 필요 없어요. 필요한 맥락만 적으면 됩니다.
둘째, 자유도를 조절하세요. 여러 접근이 가능한 작업은 느슨하게, 정확한 순서가 중요한 작업은 구체적으로 지시합니다.
셋째, 점진적 공개를 활용하세요. SKILL.md는 목차처럼 쓰고, 상세 내용은 별도 파일로 분리합니다. Claude가 필요할 때만 참조 파일을 읽어서 토큰을 절약할 수 있어요.
넷째, 그리고 가장 중요한 건 반복적으로 개선하는 것입니다.

공식 문서에서 권장하는 방식이 있습니다. Claude A(스킬 개발용)와 Claude B(테스트용)를 분리해서 사용하는 거예요. Claude A와 함께 스킬을 만들고, Claude B에서 실제로 테스트하고, 문제가 생기면 다시 Claude A로 돌아와서 개선합니다.

스킬 작성 전에 평가 시나리오를 먼저 만드는 것도 좋습니다. "이 스킬이 제대로 작동하면 어떤 결과가 나와야 하지?"를 먼저 정의해두면, 상상이 아닌 실제 문제를 해결하는 스킬을 만들 수 있습니다. 여기까지가 공식 가이드의 핵심입니다. 그런데 제가 실제로 스킬을 써보면서 발견한 팁이 하나 더 있습니다.

실전 팁: 고정된 작업은 스크립트로 분리하세요

공식 문서에서도 스크립트 활용을 권장하지만, 저는 여기서 한발 더 나아갑니다. 제가 클로드 코드를 활용한 노코드 툴을 서비스하면서 발견한 팁인데요. 반복되는 고정 작업은 아예 스크립트로 빼버리세요.

앞서 보여드린 DB 연동 워크플로를 다시 볼까요? 7단계나 되는 워크플로를 Claude가 매번 해석하고 실행합니다. 잘 되긴 하지만, 매번 토큰을 소모하고 시간이 걸리죠. 이걸 스크립트로 바꿔버리면 어떨까요? 실제로 서비스에서 사용하는 스킬입니다.

name: db-setup
description: D1 데이터베이스 연동. "DB 연동", "데이터베이스 설정", "D1 추가" 등의 요청 시 트리거됩니다.

bash -c '.claude/skills/db-setup/scripts/setup.sh'

똑같은 작업인데, 워크플로를 자연어로 풀어쓰는 대신 스크립트 하나를 호출합니다. 토큰 소모가 줄고, 실행 속도가 빨라집니다. 왜 그럴까요?

첫째, LLM이 비정형 데이터를 잘 다루긴 하지만, 데이터양이 많아지면 느려지고 누락도 생길 수 있어요. 2+3을 Claude한테 직접 계산시켜도 되지만, 계산기 스크립트에 2와 3을 넘기면 더 빠르고 정확하잖아요? 같은 원리입니다.
둘째, 필요한 부분만 변수로 받게 하면 전체 워크플로를 에이전트에 위임하지 않아도 됩니다. 고정된 로직은 스크립트가 처리하고, Claude는 변수만 채워주는 거죠.

"그러면 그냥 쉘 스크립트 직접 호출하면 되지, 왜 스킬로 감싸야 하나요?" 좋은 질문입니다. 쉘 스크립트는 유지보수가 어렵습니다. 예외 상황도 많아서, 잘 돌아가다가도 뭔가 하나만 바뀌면 멈춰버리죠.

스킬로 감싸면 다릅니다. Claude가 스크립트 실행 중 막히면 알아서 고쳐서 실행합니다. 실제로 저도 경험한 적이 있는데요. 제가 쉘 스크립트를 잘못 짜놨는데, 한 달이 지나서야 발견했습니다. 왜 한 달이나 걸렸냐고요? Claude가 알아서 고쳐서 돌리고 있었거든요. 스크립트의 정확함과 속도, 거기에 LLM의 유연함이 더해진 겁니다.

핵심은 이겁니다. LLM의 유연함 + 스크립트의 정확함/속도. 이 조합이 최강입니다. 고정된 워크플로가 있다면 Claude한테 "이 동작 스크립트로 짜줘"라고 해보세요. 알아서 짜줍니다. 그리고 그 스크립트를 스킬에서 호출하게 만들면, 빠르고 정확하면서도 예외 상황에 유연하게 대응하는 워크플로가 완성됩니다.

그래서 MCP는 정말 죽었나요?

여기까지 읽으셨다면 "MCP는 이제 버려야 하나?"라고 생각하실 수도 있습니다. 결론부터 말씀드리면, 아닙니다. MCP도 여전히 의미가 있습니다.

첫째, 생태계입니다. MCP는 이미 거대한 오픈소스 생태계를 구축했습니다. 수많은 MCP 서버가 공개되어 있고, 다양한 서비스들이 MCP를 지원합니다. 필요한 기능이 이미 MCP로 구현되어 있다면, 굳이 새로 만들 이유가 없죠.
둘째, 공유의 용이성입니다. 클로드 스킬은 폴더 기반이라 내 컴퓨터에 파일로 존재합니다. 다른 사람과 공유하려면 파일을 직접 전달해야 해요. 반면 MCP는 설치 형태라 배포와 공유가 쉽습니다.

그래서 제 결론은 이렇습니다.

개인 워크플로, 팀 내부 자동화, 빠른 프로토타이핑에는 클로드 스킬이 압도적으로 유리합니다. 자연어로 정의하고, 스크립트로 최적화하고, Claude의 유연함으로 예외를 처리하면 됩니다.

외부 서비스 연동, 커뮤니티 공유, 대규모 배포에는 MCP가 여전히 좋은 선택입니다. 이미 구축된 생태계를 활용할 수 있으니까요.

결국 둘 다 도구입니다. 상황에 맞게 쓰면 됩니다. 다만 한 가지는 분명합니다. LLM의 본질은 자연어 이해입니다. 정형화된 프로토콜보다 자연어로 정의하는 방식이 LLM과 더 잘 맞습니다. 클로드 스킬은 그 방향으로 가는 첫걸음이고, 앞으로 이런 접근이 더 확산될 거라고 생각합니다.

바이브 코딩 시대, 복잡한 프로토콜을 외우는 대신 자신만의 워크플로를 자유롭게 만들어보세요. 생각보다 훨씬 쉽습니다.