MCP가 대체 뭐고 API랑 뭐가 다른가

얼마 전 동료 개발자랑 MCP 얘기를 했다. 다들 MCP를 써봤고 느낌은 아는데, “MCP가 뭐야? API랑 뭐가 달라? 서버는 왜 있어?”라고 물으면 시원하게 답하는 사람이 없었다. 쓸 줄은 아는데 설명을 못 하는 거다. 그래서 그 질문에 답하는 글을 쓴다.

이거 우리만 헷갈리는 게 아니다

처음엔 나랑 동료만 이해를 못 하나 싶었다. 찾아보니 아니었다. MCP가 나온 뒤로 개발자 커뮤니티엔 “MCP는 그냥 API 래퍼 아니냐”는 논쟁이 끝도 없이 올라온다. 전 세계가 똑같이 헷갈린다.

이유는 두 가지다.

첫째, 이름이 함정이다. “프로토콜”이라는 단어 탓에 HTTP나 REST 같은 거랑 같은 층위라고 착각한다. 실제로는 API 위에 얹히는 한 단계 높은 레이어인데도.

둘째, “모른다”고 말하기 민망해서다. 다들 아는 척 넘어가니까, 100% 이해 못 한 채로 그냥 쓰게 된다. 그래서 느낌은 아는데 설명은 못 하는 상태가 업계 기본값이 됐다.

그러니 설명을 못 한다고 자책할 필요 없다. 한 번도 제대로 짚고 넘어간 적이 없을 뿐이다. 지금 짚으면 된다.

한 문장으로

MCP(Model Context Protocol)는 AI가 외부 도구·데이터를 발견하고 사용하는 방식을 표준화한 규약이다. 앤트로픽이 2024년 말에 공개한 오픈 표준이고, 지금은 Claude·ChatGPT·VS Code·Cursor가 다 지원한다.

공식 문서가 드는 비유가 정확하다. AI 앱의 USB-C 포트다. USB-C가 나오기 전엔 기기마다 충전 단자가 제각각이었다. USB-C 하나로 통일되니 케이블 하나로 다 꽂힌다. MCP가 AI와 외부 시스템 사이에서 그 역할을 한다.

USB-C 비유는 “표준 단자”라는 결론만 준다. 정작 안에서 무슨 일이 벌어지는지는 안 보인다. 그래서 식당으로 한 번 더 풀어본다.

식당으로 비유하면

AI를 손님, 외부 도구(DB·파일·외부 서비스)를 주방이라고 하자.

MCP가 없으면 손님이 직접 주방에 들어가야 한다. 가스레인지 켜는 법, 재료 위치, 칼 쓰는 법을 다 알아야 요리를 받는다. 주방이 바뀌면 처음부터 다시 배운다. 개발자가 매번 “AI야, 이 API는 이렇게 호출해”라고 코드로 가르치는 게 정확히 이 짓이다.

MCP가 있으면 손님은 주방에 안 들어간다. 점원한테 묻는다. “뭐 돼요?” 하면(tools/list) 점원이 메뉴판을 준다. 메뉴 보고 주문한다(tools/call). 요리법은 몰라도 된다. 주방이 신메뉴를 내면 점원이 “오늘 이거 추가됐어요”라고 알려준다(notification).

여기서 점원이 MCP 서버다. 손님(AI)과 주방(실제 도구) 사이에 서서, 뭐가 되는지를 표준 메뉴판으로 알려주고 주문을 받아 전달한다. 손님은 주방 내부를 몰라도 되고, 주방은 손님이 누구든 — Claude든 GPT든 Gemini든 — 똑같이 응대한다.

이 비유를 머리에 깔고 아래를 읽으면 나머지는 다 따라온다.

가장 흔한 오해부터 깨자

“MCP가 API를 대체한다” — 틀렸다. 이 오해가 모든 혼란의 출발점이다.

MCP는 API를 대체하지 않는다. API 위에 얹히는 레이어다. MCP 서버 내부를 까보면 결국 REST나 GraphQL API를 호출한다. 기존 REST 엔드포인트를 그대로 MCP 도구로 노출할 수도 있다.

그러니까 “MCP vs API”는 애초에 대립 구도가 아니다. 둘은 다른 레이어의 물건이다.

API: 서비스끼리 데이터를 주고받는 규약 (사람이 통합 코드를 짠다)
MCP: AI 모델이 그 API들을 발견하고 호출하는 방식의 규약 (모델이 런타임에 알아서 한다)

이 구분이 머리에 안 잡혀 있으면, MCP 설명이 자꾸 “더 좋은 API”처럼 납작해진다. MCP는 더 좋은 API가 아니다. API를 AI가 쓸 수 있게 만드는 표준 어댑터다.

그럼 API랑 뭐가 다른가

핵심 차이는 “누가 통합을 하느냐”다.

항목	전통적 API	MCP
통합 주체	개발자가 코드로 직접 연결	모델이 런타임에 스스로 발견
계약 방식	고정된 엔드포인트 + 스키마	자기 기술(self-describing) 메타데이터
도구 목록	문서 보고 사람이 파악	`tools/list`로 모델이 조회
변경 대응	코드 수정·재배포	실시간 통지(notification)로 자동 반영
연결 상태	보통 무상태(stateless)	상태 유지(stateful) 연결

전통적 방식에서는 새 도구를 붙이려면 개발자가 그 API의 문서를 읽고, 어댑터를 짜고, 모델 프롬프트에 “이런 도구가 있다”고 박아 넣어야 한다.

MCP에서는 모델이 연결된 서버에 tools/list를 던져서 “너 무슨 도구 있어?”라고 직접 묻는다. 서버가 도구 이름·설명·입력 스키마를 돌려준다. 모델은 그걸 보고 알아서 호출한다. 사람이 중간에 통합 코드를 짤 필요가 없다.

이게 self-describing의 의미다. API는 “정해진 주소로 정해진 형식으로 호출해”라는 고정 계약이고, MCP는 “내가 뭘 할 수 있는지 너한테 알려줄게”라는 동적 발견이다.

동적 디스커버리, 실제로 어떻게 도나

말로만 하면 안 와닿으니 실제 메시지를 보자. MCP는 JSON-RPC 2.0 위에서 돈다.

모델 쪽(클라이언트)이 서버에 묻는다:

{ "jsonrpc": "2.0", "id": 2, "method": "tools/list" }

서버가 가진 도구를 돌려준다:

{
  "jsonrpc": "2.0", "id": 2,
  "result": {
    "tools": [{
      "name": "weather_current",
      "description": "특정 위치의 현재 날씨를 가져온다",
      "inputSchema": {
        "type": "object",
        "properties": { "location": { "type": "string" } },
        "required": ["location"]
      }
    }]
  }
}

모델은 이 응답만 보고 “아, 날씨 도구가 있고 location을 넣으면 되는구나”를 파악한다. 그리고 호출한다:

{
  "jsonrpc": "2.0", "id": 3, "method": "tools/call",
  "params": { "name": "weather_current", "arguments": { "location": "Seoul" } }
}

여기서 사람이 짠 통합 코드는 없다. 모델이 tools/list로 발견하고 tools/call로 실행했을 뿐이다. 식당 비유 그대로다. “뭐 돼요?”가 tools/list, “이거 주세요”가 tools/call이다. 서버 도구가 바뀌면 notifications/tools/list_changed가 날아온다. 점원이 “신메뉴 나왔어요” 하는 것과 같다. 모델은 목록을 다시 가져온다. 재배포 없이 실시간으로 반영된다.

plugin이랑은 뭐가 다른가

ChatGPT 플러그인을 떠올리면 된다. plugin도 AI에 도구를 붙이는 방식이다. 차이는 두 가지다.

노출하는 것이 다르다. plugin은 API 엔드포인트를 노출한다. MCP는 context를 노출한다. 어떤 도구가 있고, 어떻게 동작하고, 무엇을 안전하게 할 수 있는지까지 모델이 본다.
종속성이 다르다. plugin은 보통 특정 모델·플랫폼에 묶인다. ChatGPT 플러그인은 ChatGPT용이다. MCP는 모델 중립적이다. 같은 MCP 서버 하나를 Claude·GPT·Gemini가 다 꽂아 쓴다.

한 줄로: plugin은 플랫폼별 파편화, MCP는 한 번 만들어 어디든 꽂기.

MCP 서버는 왜 있는가

여기가 핵심이다. MCP가 푸는 문제는 M×N 통합 문제다.

AI 앱이 M개 있고, 붙이고 싶은 도구·데이터 소스가 N개 있다고 하자. 표준이 없으면 각 조합마다 통합 코드를 짜야 한다. M개 앱 × N개 도구 = M×N개의 커넥터. 도구 하나 추가하면 M개 앱 전부에 어댑터를 새로 짜야 한다.

MCP는 이걸 M+N으로 바꾼다. 각 AI 앱은 MCP 클라이언트 하나만, 각 도구는 MCP 서버 하나만 구현하면 된다. 표준 규약을 통하니까 아무 클라이언트나 아무 서버에 꽂힌다.

표준 없음:  앱 3개 × 도구 4개 = 커넥터 12개
MCP 사용:   앱 3개 + 도구 4개 = 구현 7개

MCP 서버가 존재하는 이유가 이거다. 서버는 “이 도구·데이터를 MCP 규약으로 노출하는 어댑터”다. 한 번 만들어 두면 MCP를 말하는 모든 AI가 가져다 쓴다. GitHub MCP 서버 하나 띄우면 Claude Code도, Cursor도, VS Code도 똑같이 GitHub을 다룬다.

구조를 까보면

용어가 헷갈리니 정리한다. MCP는 클라이언트-서버 구조다.

구성요소	정체	예시
Host	AI 앱 본체	Claude Code, Claude Desktop, VS Code
Client	Host 안에서 서버 하나당 1개씩 붙는 연결 관리자	(호스트가 자동 생성)
Server	도구·데이터를 노출하는 프로그램	filesystem, GitHub, Sentry 서버

Host 하나가 서버 여러 개에 붙을 때, 서버마다 전용 Client를 하나씩 만든다. VS Code가 filesystem 서버와 Sentry 서버에 동시에 붙으면 Client가 2개 생기는 식이다.

서버가 노출하는 것은 세 가지(primitives)다.

Tools: 모델이 호출하는 실행 함수 (파일 쓰기, DB 쿼리, API 호출)
Resources: 모델에 주는 컨텍스트 데이터 (파일 내용, DB 레코드)
Prompts: 재사용 템플릿 (정해진 작업용 프롬프트)

대부분 Tools를 떠올리지만, Resources와 Prompts까지 묶어서 노출할 수 있다는 게 plugin과 또 다른 점이다.

전송 방식(transport)은 두 가지다. 로컬은 stdio(같은 머신에서 프로세스 직통, 네트워크 오버헤드 0), 원격은 Streamable HTTP(OAuth·API 키 인증)다.

안 쓰면 뭐가 안 되고, 쓰면 뭐가 좋은가

MCP 없이도 AI는 돈다. 다만 외부 세계와 단절된 채로 돈다. 학습된 지식 안에서만 답하고, 내 파일·DB·사내 시스템은 못 본다. 붙이려면 개발자가 매번 커스텀 통합을 짜야 하고, 그 통합은 그 모델에만 묶인다. 모델 갈아타면 다시 짠다.

MCP를 쓰면 이게 바뀐다.

	MCP 없음	MCP 있음
외부 연결	매번 커스텀 통합	서버 꽂으면 끝
모델 교체	통합 재작성	그대로 재사용
도구 추가	코드 수정·재배포	서버 등록만
생태계	내가 만든 것만	공개 서버 수천 개

체감되는 차이는 생태계다. 누군가 만들어 공개한 MCP 서버를 그냥 가져다 꽂으면 된다. Notion, Slack, GitHub, Figma, 로컬 파일시스템 — 이미 다 있다. 내가 어댑터를 안 짜도 된다.

정리하면, MCP는 “AI를 내 도구들에 연결하는 표준 케이블”이다. 안 쓰면 AI가 자기 머릿속 지식만으로 일하고, 쓰면 내 실제 데이터와 시스템 위에서 일한다.

그래서 실무에서

나는 Claude Code에 MCP 서버 몇 개를 상시로 물려 쓴다. 그러면 Claude가 내 로컬 환경과 외부 서비스를 직접 다룬다. 도구를 바꿔도 — 다른 AI 클라이언트로 옮겨도 — 같은 서버를 그대로 꽂으면 된다.

이게 MCP의 진짜 가치다. 한 번 연결을 표준으로 만들어 두면, AI를 갈아끼워도 연결이 안 깨진다. 모델은 빠르게 바뀐다. 작년에 쓰던 모델 지금 안 쓴다. 그때마다 통합을 다시 짜는 건 낭비다. MCP는 그 낭비를 없앤다.

누가 또 “MCP가 뭐야?”라고 물으면 이렇게 답하면 된다. “AI랑 외부 도구를 잇는 USB-C. API를 대체하는 게 아니라, API를 AI가 알아서 발견하고 쓰게 만드는 표준.”

Sources: