MCP API 차이가 안 잡히는 이유 — 클로드 스킬까지 셋은 같은 층에 있지 않습니다

API는 프로그램끼리 정해진 방식으로 요청하고 답을 받는 창구입니다. MCP는 AI 앱을 바깥 도구에 꽂는 공통 규격이고요. 클로드 스킬은 그 도구로 무엇을 어떻게 하라고 적어 둔 매뉴얼입니다.

세 정의를 나란히 놓고 보면 셋 중 하나를 고르는 문제가 아니라는 게 보입니다. 창구, 연결 규격, 매뉴얼. 셋은 경쟁 관계가 아니라 다른 층에 놓인 물건이에요.

근거는 두 갈래로 댑니다. 하나는 공식 문서의 정의이고, 다른 하나는 제가 영상에서 카드 문자 24통을 가계부에 넣으라고 똑같은 한 줄을 네 번 시킨 결과예요. API 문서만 줄 때, MCP만 붙일 때, 스킬만 넣을 때, 둘 다 붙일 때. 넷 중 두 번은 21건이 들어갔는데 분류가 제멋대로였고, 한 번은 0건이었고, 끝까지 된 건 한 번뿐이었습니다.

API란 무엇인가 — 창구, 잇는 코드는 따로

API(Application Programming Interface)는 화면 뒤에서 프로그램끼리 서로 여는 문이에요. 무엇을 어떤 모양으로 물으면 어떤 모양으로 답이 오는지가 미리 정해져 있고, 사람이 보는 화면과는 별개예요.

쓰려면 문서가 필요합니다. 어디로 보낼지 주소, 통과할 때 대는 비밀번호(키), 보낼 때 맞춰야 하는 양식. 제가 영상에서 쓴 가계부 API 문서도 이 세 줄이 전부였습니다. 이 세 줄을 사람이 챙겨 두고, 문서를 보고 잇는 코드를 누군가 짜야 시작이 돼요. 사람이 짜도 되고 AI가 짜도 됩니다.

실측은 이랬습니다. 문서 한 장만 폴더에 두고 같은 한 줄을 시켰더니 클로드가 코드를 짜서 가계부에 21건을 넣었어요. 네 번 중 왕복이 가장 적은 5턴이었습니다. 대신 분류 아홉 개를 자기가 만들어 붙였고, 로그에는 이렇게 남았습니다.

규칙 파일이 없고 API 문서만 있어서, 기본 규칙을 제가 정해 적용했습니다.

여기서 경계가 하나 생깁니다. API는 넣는 통로이지 결과를 어떻게 정리할지 정하는 규칙이 아닙니다. 그래서 MCP가 그냥 API 아니냐는 말도 절반은 맞아요. API만으로도 넣기까지는 되니까요. 남는 건 문서와 키가 사람 몫이라는 것, 그리고 다음에 시키면 코드를 또 짠다는 것입니다.

MCP란 무엇인가 — AI가 도구 목록을 보고 스스로 고르는 규격

MCP(Model Context Protocol)는 AI 앱을 바깥 시스템에 연결하는 오픈소스 표준입니다. 앤트로픽이 2024년 11월 25일 공개했고, 공식 소개 문서는 원문에서 "AI 애플리케이션의 USB-C 포트"라고 직접 비유합니다. 어느 회사 도구든 같은 규격으로 꽂는다는 뜻이에요.

연결을 맡는 건 MCP 서버라고 부르는 작은 프로그램입니다. 서버가 내놓는 건 세 가지예요. AI가 부르는 기능(도구), 읽을 자료, 미리 써 둔 요청문. 기능마다 이름과 설명이 붙어 있어서, 클로드 같은 AI 앱이 그 목록을 받아 두었다가 일이 들어오면 그중 하나를 스스로 골라 부릅니다.

붙이는 방법은 공식 규격에 두 가지뿐입니다. 서버 프로그램을 내 컴퓨터에서 돌리는 방법(Stdio)과, 남이 켜 둔 서버에 인터넷 주소로 붙는 방법(Streamable HTTP). 앞쪽은 설정 파일에 어떻게 켤지만 적어 두면 클로드가 필요할 때 켜고, 뒤쪽은 설치할 게 없고, 붙을 때 로그인 절차나 토큰 한 줄이 따라와요. 그리고 도구를 실제로 쓸 땐 사람에게 허락을 묻게 하라는 게 공식 문서의 정의에 들어 있어요.

실측입니다. API 문서를 빼고 MCP만 붙인 채 같은 한 줄을 시켰더니, 클로드가 도구 목록에서 셋 중 하나를 골라 21건을 넣었습니다. 사람이 문서를 챙겨 줄 일은 없어졌어요. 그런데 분류는 열 개가 제멋대로였고, 로그엔 가계부 규칙 파일이 없어 통상 기준으로 처리했다고 적혀 있었습니다.

MCP가 이긴 건 속도가 아니라 도구를 스스로 찾는다는 점입니다. 왕복은 28턴으로, API 문서만 줬을 때의 다섯 배가 넘었어요. 문서와 키를 사람이 안 챙겨도 된다는 게 MCP가 덜어 주는 몫이고, 결과를 우리 식으로 정리하는 일은 여전히 남습니다.

MCP가 API를 대신하지 못하는 이유

MCP는 API를 없애는 게 아니라 API 위에 얹히는 포장입니다. 이건 제 해석이 아니라 공식 예제가 그렇게 생겼어요.

공식 "서버 만들기" 튜토리얼의 날씨 서버는 코드 첫 부분에 미국 기상청 API 주소(https://api.weather.gov)를 두고, 그 API를 불러온 결과를 get_alerts·get_forecast 두 도구로 내놓습니다. 우리가 쓴 가계부 MCP 서버의 파일 안에도 가계부 API 주소와 키가 그대로 들어 있고요.

그러니까 창구는 그대로고, 잇는 쪽이 사람에서 AI로 바뀐 겁니다. API가 없으면 MCP 서버가 감쌀 것도 없어요. "API 대 MCP"가 아니라 "API 위의 MCP"로 읽으면 두 개념이 충돌하지 않습니다.

MCP는 지금 누가 관리하나

2025년 12월 9일부터 MCP는 앤트로픽 소유가 아닙니다. 리눅스재단 산하 Agentic AI Foundation(AAIF)의 창립 프로젝트로 넘어갔어요. MCP 공식 블로그에 따르면 공동 창립은 앤트로픽·Block·OpenAI, 지원사는 구글·마이크로소프트·AWS·클라우드플레어·블룸버그입니다.

그래서 클로드만이 아니라 ChatGPT, VS Code, 커서가 같은 규격을 씁니다. "MCP는 앤트로픽 전용"이라는 전제로 판단하고 있었다면 그 전제부터 고치면 됩니다.

MCP를 많이 붙이면 왜 무거워지는가

기본 설정에선 붙여 놓은 도구의 설명이 대화마다 통째로 실립니다. 쓰든 안 쓰든 목록을 들고 있어야 AI가 고를 수 있으니까요.

2025년 11월 4일 앤트로픽 엔지니어링 블로그는 이 방식을 코드 실행으로 바꾼 예시에서 도구 설명 비용이 150,000에서 2,000토큰으로(98.7%) 줄었다고 밝혔습니다. 토큰은 AI가 글을 읽는 단위이고 비용도 이걸로 세요. 거꾸로 읽으면, 연결을 열 개 붙이면 열 개분 설명을 매번 지고 다닌다는 뜻입니다.

붙이는 개수를 늘리기 전에 그 연결이 지금 막힌 일을 실제로 뚫어 주는지부터 보면 돼요.

클로드 스킬이란 무엇인가 — SKILL.md 한 장

클로드 스킬은 일에 관련될 때 클로드가 꺼내 읽는 지시와 자료를 담아 둔 폴더입니다. 앤트로픽이 2025년 10월 16일 발표했고, 최소 구성은 SKILL.md 파일 한 장이에요.

핵심은 그 파일 맨 위 두 줄입니다. 이름(name, 64자 이내)과, 무엇을 하는 규칙이며 언제 쓰는지 적는 설명(description, 1,024자 이내). 클로드는 평소에 이 두 줄만 보고 꺼낼지 말지 정합니다. 언제 쓰는지를 안 적으면 있어도 잘 안 꺼내 봐요.

제가 영상에서 쓴 가계부 규칙의 맨 위는 이렇게 생겼습니다. 아래 두 줄이 클로드가 평소에 들고 있는 전부예요.

name: household-ledger
description: <무엇을 하는 규칙인지> + <어떤 요청이 오면 꺼내는지>

실제 파일의 설명 줄엔 카드 문자를 가계부에 넣을 때 쓴다는 것과, "가계부 정리해줘" 같은 요청이 오면 이 규칙을 따르라는 말을 한 문장으로 적어 두었습니다.

본문은 필요할 때만 읽힙니다. 평소 짐은 스킬당 약 100토큰이고, 관련 일이 들어오면 본문을 읽는데 5,000토큰 미만을 권해요. 백 장을 깔아도 평소 짐은 만 토큰 정도라, 안 쓰는 규칙 때문에 대화가 무거워지진 않습니다. MCP의 상시 비용과 정반대 구조예요.

본문엔 분류는 여섯 개만, 똑같은 문자가 두 통 오면 하나만 넣기, 취소는 결제까지 빼기, 끝나면 보고 세 줄. 전부 한국어 문장으로 적었고 코딩은 한 줄도 없습니다.

실측입니다. 연결을 다 떼고 이 한 장만 넣었더니 분류·중복·취소 처리가 전부 규칙대로였습니다. 그런데 가계부 쪽은 0건이었어요. 로그엔 가계부 연결이 없어 정리한 표를 파일로 저장했다고 남았습니다.

경계는 분명합니다. 스킬은 매뉴얼이지 손발이 아닙니다. 규칙만 있고 연결이 없으면 정리된 표 한 장에서 멈춰요.

클로드 스킬은 클로드 전용인가

아닙니다. 2025년 12월 오픈 표준으로 공개됐고, agentskills.io 쇼케이스에는 2026년 9월 기준으로 46개 제품이 이 형식을 읽는다고 올라와 있습니다. ChatGPT와 코덱스, 깃허브 코파일럿, VS Code, 커서, 제미나이 CLI가 한 목록에 있어요.

한 번 써 둔 규칙 한 장을 다른 AI 도구에서 그대로 쓴다는 뜻입니다. 클로드 코드 안에서만 되는 단축 명령이나 보조 에이전트와 다른 지점이 여기예요. 규칙을 어디에 적을지 고민 중이라면 스킬 형식으로 적어 두면 도구를 옮길 때 다시 안 써도 됩니다.

셋은 왜 같은 층이 아닌가 — 한 표로

	정체	누가 잇나	평소 짐	이것만 있을 때 결과(실측)
API	프로그램끼리의 창구	문서를 챙긴 사람이나 AI가 코드로	없음(매번 코드를 다시 짬)	21건, 분류 9개 제멋대로
MCP	AI가 스스로 찾아 쓰는 연결 규격	AI가 도구 목록에서 고름	도구 설명이 대화마다 실림	21건, 분류 10개 제멋대로
클로드 스킬	뭘 어떻게 할지 적은 매뉴얼	사람이 한국어로 한 장	두 줄, 약 100토큰	0건, 정리는 전부 규칙대로

표에서 볼 곳은 마지막 열입니다. 연결이 있는 두 줄은 들어가긴 하는데 우리 것이 아니고, 매뉴얼만 있는 줄은 우리 것인데 못 들어갑니다. 서로 빠진 것을 채우는 관계예요.

앤트로픽이 Skills explained(2026년 3월 5일)에 쓴 한 줄도 같습니다. MCP는 클로드를 데이터에 연결하고, 스킬은 그 데이터로 뭘 할지 알려 주니 둘을 같이 쓰라고요.

그래서 연결과 규칙을 둘 다 붙이고 같은 한 줄을 시켰습니다. 우리가 정한 여섯 분류 그대로 21건이 가계부에 들어갔고, 중복 한 건과 취소 한 건이 규칙대로 빠졌고, 보고가 세 줄로 나왔어요. 네 번 중 끝까지 간 건 이 한 번이었습니다.

정리하면 셋은 대체 관계가 아니라 층입니다. 하나를 골라 깔 게 아니라, 빠진 층이 어디인지 보고 그 층을 채우면 됩니다.

처음 만든 편은 버렸습니다

이 글의 바탕이 된 영상은 두 번째 판입니다. 처음엔 실험 장면이 많을수록 잘 남을 줄로 알았는데, 첫 판은 네 번 시킨 실험 장면이 본편의 64%를 차지했고 다 보고 나면 화면은 기억나는데 셋의 정의는 안 남았습니다.

원인은 하나였어요. 예시가 개념을 증명하는 게 아니라 개념이 예시를 설명하고 있었습니다.

그래서 2026년 9월 15일에 첫 판을 버리고 개념을 기준으로 다시 짰습니다. 정의를 먼저 놓고, 공식 출처를 붙이고, 실측은 각 개념 끝에 결과 한 줄로만. 이 글도 같은 순서예요. 개념 셋에 실측 넷을 한 줄씩만 달면 됩니다.

내 일엔 무엇을 먼저 붙이나 — 판정 세 줄

먼저 쓸 건 우리 규칙 한 장(스킬)입니다. 결과가 우리 것으로 나온 실행은 규칙이 든 두 번이 전부였으니까요. 코딩 없이 한국어로 적으면 됩니다.

연결(MCP)은 그다음이고, 내 일이 실제로 막히는 데부터 하나씩 붙입니다. 추천 목록부터 까는 습관이 셋을 헷갈리게 만드는 흔한 이유예요.

한 번 쓰고 버릴 일이면, 또는 코드를 짜 줄 동료가 곁에 있으면 API로 충분합니다. IBM 기준으로는 실시간 자료를 권한 관리해 가며 가져와야 할 때 MCP를 쓰고, 되풀이해 쓸 기능 하나 붙이는 정도면 스킬을 씁니다.

남이 만든 MCP를 붙일 때 확인할 것

출처입니다. 도구를 쓸 때 사람이 확인하는 게 공식 권고이긴 한데, 2025년 7월 공개 시연에선 지원 게시판 글 안에 숨겨 둔 명령을 AI가 진짜 지시로 알아들어 비공개 표가 바깥으로 새어 나갔어요. 읽으라고 준 글과 시키는 말을 AI가 늘 구분하지는 못합니다.

MCP를 붙인다고 모델이 똑똑해지는 것도 아닙니다. 공식 문서도 MCP는 컨텍스트를 주고받는 규격에만 관여하고, AI 앱이 모델을 어떻게 쓰는지는 정하지 않는다고 못 박아요. 프로그램 하나 설치할 때만큼 따져 보고 붙이는 게 맞습니다.

다 읽었으면 두 줄만 써 보세요

지금 반복하는 일 하나를 골라 SKILL.md 맨 위 두 줄만 적어 보시면 됩니다. 이름 한 줄, 언제 쓰는지 한 줄. 그 두 줄이 있어야 클로드가 꺼내 보니까요.

네 번 시킨 화면과 로그 원문은 영상에 있고, 정리표·판정표·가계부 규칙 파일 원문은 오픈톡방(https://open.kakao.com/o/picxsxwi)에 올려 뒀습니다. 두 줄을 쓰다 막힌 지점이 있으면 거기에 남겨 주세요.