MCP(Model Context Protocol)란?

MCP는 AI 애플리케이션이 개별 맞춤 통합 대신 하나의 프로토콜로 외부 툴과 데이터에 연결할 수 있게 하는 개방형 표준입니다. 2024년 11월 Anthropic이 발표하고 1년 만에 업계 표준이 된 MCP는, 공통 포트가 주변 기기에 해 준 일을 대략 AI 에이전트에 해 줍니다. 모든 해설 글이 꺼내 드는 “AI를 위한 USB-C”라는 비유가 바로 이것입니다. 백엔드 개발자에게는 더 정확한 관점이 있습니다. MCP 서버는 API 어댑터입니다. 기존 백엔드는 이미 요청에 응답하는 방법을 알고 있습니다. MCP는 그 백엔드를 직접 작성한 클라이언트 코드가 아니라 AI 모델이 발견하고 호출할 수 있게 만드는 방법입니다.

핵심 요약

이미 있는 백엔드를 감싸는 MCP 서버

// JavaScript / Node.js — an MCP server wrapping an existing backend API
import { McpServer } from '@modelcontextprotocol/server';
import { z } from 'zod';

const server = new McpServer({ name: 'tasks', version: '1.0.0' });

// A tool is a described, discoverable wrapper over the API you already have
server.registerTool(
  'query_tasks',
  { description: 'List tasks by status', inputSchema: z.object({ status: z.string() }) },
  async ({ status }) => {
    const res = await fetch(`${BASE}/classes/Task?where=${q({ status })}`, {
      headers: { 'X-Parse-Application-Id': APP_ID, 'X-Parse-REST-API-Key': KEY },
    });
    return { content: [{ type: 'text', text: await res.text() }] };
  }
);
// The agent discovers this tool at runtime and decides when to call it —
// same backend, same ACLs and rate limits; just a new kind of client.

// Flutter / Dart — Back4app Flutter SDK
// One backend, two kinds of consumers: your app via the SDK…
final tasks =
    await QueryBuilder<ParseObject>(ParseObject('Task')).query();
// …and AI agents via an MCP server wrapping the SAME REST/GraphQL API,
// exposing "query_tasks" and "run_function" as tools the model can call.
// Same data, same ACLs, same rate limits — a new client type, not a new backend.

// iOS / Swift — Back4app Swift SDK
// One backend, two kinds of consumers: your app via the SDK…
let tasks = try await Task_.query().find()
// …and AI agents via an MCP server wrapping the SAME REST/GraphQL API,
// exposing "query_tasks" and "run_function" as tools the model can call.
// Same data, same ACLs, same rate limits — a new client type, not a new backend.

// Android / Kotlin — Back4app Android SDK
// One backend, two kinds of consumers: your app via the SDK…
val tasks = ParseQuery.getQuery<ParseObject>("Task").find()
// …and AI agents via an MCP server wrapping the SAME REST/GraphQL API,
// exposing "query_tasks" and "run_function" as tools the model can call.
// Same data, same ACLs, same rate limits — a new client type, not a new backend.

JavaScript 탭의 15줄에 핵심 아이디어가 모두 담겨 있습니다. query_tasks 툴은 백엔드가 이미 제공하는 REST 호출을 설명이 붙고 발견 가능한 형태로 감싼 래퍼입니다. 에이전트는 런타임에 설명을 읽고, 이 툴이 맞는 상황인지 판단한 뒤 호출합니다. 이때 앱이 거치는 것과 똑같은 엔드포인트, ACL, 속도 제한을 거칩니다. 새로운 백엔드가 아니라 새로운 종류의 클라이언트입니다.

MCP가 N×M 통합 문제를 해결하는 방식

MCP 이전에는 N개의 AI 클라이언트를 M개의 툴에 연결하려면 최대 N × M개의 맞춤 통합이 필요했습니다. 공유 프로토콜은 이를 N + M으로 줄입니다. 각 클라이언트와 각 서버가 MCP를 한 번씩만 구현하면 됩니다. 공식 아키텍처는 세 가지 역할을 정의합니다. Host는 AI 애플리케이션이고, 연결마다 Client를 하나씩 생성하며, 각 Server가 기능을 제공합니다. 통신은 JSON-RPC로 이루어지며, 같은 머신에 있는 로컬 서버에는 stdio를, 원격 서버에는 Streamable HTTP를 씁니다(초기의 HTTP+SSE 전송 방식은 현재 지원 중단되었습니다).

세 가지 프리미티브

데이터베이스 서버 하나가 보통 세 가지를 모두 노출합니다. query 툴, schema 리소스, 자주 하는 요청을 위한 퓨샷(few-shot) prompt입니다. “내가 할 수 있는 일, 내가 아는 것, 나에게 요청하는 방법”을 알려 주는 셈입니다.

MCP vs. API vs. 함수 호출

두 비교는 명확하게 정리됩니다. API와 비교하면: MCP는 API를 대체하지 않고 감쌉니다. 런타임 발견을 더해 애플리케이션 코드가 아니라 모델이 호출을 선택하게 합니다. 함수 호출과 비교하면: 함수 호출은 모델이 구조화된 요청을 내보내는 것이고, MCP는 그 요청을 여러 앱과 제공업체에 걸쳐 발견하고 실행하는 방식을 표준화합니다. MCP가 더하는 것은 기능이 아니라 표준화와 이식성입니다. MCP가 하는 일은 무엇이든 통합 하나에 한해서는 맞춤 함수 호출로도 할 수 있습니다. MCP는 그것을 다시 작성하지 않고도 어디서나 작동하게 만듭니다.

보안 공격 표면, 솔직하게

중립적인 페이지는 건너뛰고 보안 벤더는 과장하는 부분입니다. 위협은 프로토콜이 아니라 신뢰 모델에 있습니다. 프롬프트 인젝션은 툴 출력을 타고 들어옵니다. 툴이 반환한 문서에 모델이 그대로 따르는 지시가 들어 있을 수 있습니다. 툴 포이즈닝은 악의적인 지시를 툴의 설명에 숨깁니다. 모델은 사람이 보기도 전에 이 설명을 읽으며, 이 공격은 현재 OWASP에 등재되어 있습니다. 러그 풀: 한 번 승인된 서버가 나중에 툴 정의를 바꿀 수 있습니다. 그리고 조용한 위험인 커뮤니티 서버 공급망이 있습니다. 서버는 수천 개가 있고, 하나를 설치하면 에이전트의 컨텍스트에 발판을 내주게 됩니다. 완화 방법은 새로운 공격 표면에 적용하는 평범한 보안 원칙입니다. 서버별 최소 권한 범위, 실제 동작을 수행하는 툴 호출에 대한 사람의 승인(human-in-the-loop), 신뢰하는 서버의 버전 고정과 허용 목록 관리, 원격 서버의 제대로 된 인증, 그리고 작업에 필요한 것보다 넓은 자격 증명을 MCP 서버에 절대 넘기지 않는 것입니다.

현재의 명세

MCP는 빠르게 변하며, 대부분의 해설 글은 2025년 중반에 멈춰 있습니다. 최신 상태로 유지할 가치가 있는 내용입니다. 전송 방식은 Streamable HTTP로 통합되었고(HTTP+SSE는 지원 중단), 원격 서버는 OAuth 방식의 인증으로 표준화되었습니다. 2026-07-28 개정판은 프로토콜을 무상태(stateless)로 바꾸었습니다. 핸드셰이크와 세션이 없어지고, 요청별 메타데이터와 server/discover 호출이 도입되었으며, Roots, Sampling, Logging은 지원 중단되었습니다. 더 큰 신호는 거버넌스입니다. 2025년 말 이 프로토콜은 벤더 중립적인 오픈소스 재단에 기증되었습니다. 한 벤더의 관례가 아니라 진짜 표준임을 보여 주는 구조적 표지입니다. 개발자를 위한 실용적인 결론은 이렇습니다. 특정 명세 버전에 고정하고, 업그레이드 전에 변경 이력을 읽고, “MCP”를 핵심은 안정적이지만 계속 움직이는 목표로 다뤄야 합니다.

일반적인 사용 사례

• 코딩 에이전트: IDE 어시스턴트가 맞춤 플러그인 대신 서버를 통해 저장소, 데이터베이스, 이슈 트래커에 접근합니다.
• 엔터프라이즈 데이터 채팅: 어시스턴트가 사내 시스템을 쿼리하며, 각 시스템은 권한이 설정된 MCP 서버로 감싸져 있습니다.
• 백엔드 노출: 기존 REST/GraphQL API를 다시 만들지 않고 에이전트가 호출할 수 있는 툴로 바꿉니다.
• 데스크톱 및 워크플로 자동화: 로컬 stdio 서버가 한 머신 안에서 모델을 파일과 애플리케이션에 연결합니다.
• 다중 제공업체 이식성: 서버 하나가 MCP를 지원하는 모든 Host를 상대하므로, 통합이 특정 모델 선택보다 오래 살아남습니다.

MCP를 사용해야 할까? 결정 매트릭스

한계와 트레이드오프

• 움직이는 표준입니다. 명세가 빠르게 진화하므로 통합에는 버전 고정과 변경 이력에 대한 주의가 필요합니다. “MCP 지원”이라는 말에는 늘 시점이 따라붙습니다.
• 신뢰 모델이 새롭습니다. 툴 설명과 출력은 공격 표면이며, 검증되지 않은 서버에 기대어 동작하는 에이전트는 이 시대의 curl \| bash입니다.
• 손익분기점 아래에서는 오버헤드입니다. 통합이 하나뿐이라면, 함수 호출로 충분한 곳에 MCP는 프로토콜과 서버 프로세스를 더합니다.
• 발견은 제어권을 모델로 옮깁니다. 런타임 툴 선택은 강력하지만 하드코딩된 호출보다 예측하기 어렵습니다. 감사와 승인은 덜 중요해지는 것이 아니라 더 중요해집니다.
• 감쌀 뿐, 고치지는 않습니다. 보안이 허술한 API 위에 MCP 서버를 올리면 그 API가 에이전트에 더 빨리 노출될 뿐입니다. 실제 일은 여전히 기반의 권한이 합니다.

Back4app에서의 MCP

Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다. API 어댑터라는 관점은 여기서 자연스럽게 들어맞습니다. Back4app 앱은 MCP 서버가 감싸는 인터페이스를 이미 노출하고 있습니다. 모든 클래스에 대한 REST와 GraphQL, 그리고 Cloud Code 함수입니다. 따라서 에이전트가 접근할 수 있게 만드는 일은, 코드 탭이 스케치한 것처럼 find objects, run function, read schema를 툴 정의에 매핑하는 문제입니다. 보안 섹션의 내용은 구체적인 지침이 됩니다. MCP 서버에는 마스터 키가 아니라 범위가 제한된 키를 주어야 합니다. 플랫폼의 ACL과 클래스 수준 권한이 앱의 호출을 제한하는 것과 똑같이 에이전트의 호출이 건드릴 수 있는 범위도 제한하게 하고, 되돌릴 수 없는 동작은 원시 테이블 접근 대신 자체 검사를 갖춘 Cloud Function 뒤에 두어야 합니다. 에이전트는 이미 거절하는 법을 아는 백엔드의 또 하나의 클라이언트가 됩니다.