01. 왜 MCP인가 — M×N 통합 문제와 해법

충전기 서랍 이야기

서랍에 케이블이 한 뭉치 있다고 해봅시다. 옛날에는 기기마다 충전 단자가 달라서, 새 기기를 살 때마다 전용 케이블이 따라왔습니다. 기기가 M개, 충전기 종류가 N개면 서랍은 금세 엉망이 됩니다. USB-C가 등장하면서 이 문제가 정리됐죠. 기기도 충전기도 "USB-C라는 한 규격"만 지키면, 어떤 조합이든 그냥 꽂힙니다.

LLM 애플리케이션 세계에도 똑같은 일이 있었습니다. AI 앱(M개)과 외부 도구·데이터 소스(N개)를 잇는데, 조합마다 전용 연결 코드를 써야 했습니다. 이것이 Anthropic이 지적한 "N × M 통합 문제"로, Slack·GitHub·데이터베이스 같은 N개의 도구를 ChatGPT·Gemini·Claude 같은 M개의 모델 프런트엔드와 통합할 때, 표준이 없으면 모델과 도구의 조합마다 고유한 어댑터가 필요해 N×M개의 맞춤 통합이 우후죽순 생긴다는 문제입니다.

flowchart LR
    subgraph BEFORE["MCP 이전 — M×N개의 맞춤 연결"]
        A1["앱 1"] --- T1["도구 A"]
        A1 --- T2["도구 B"]
        A1 --- T3["도구 C"]
        A2["앱 2"] --- T1
        A2 --- T2
        A2 --- T3
        A3["앱 3"] --- T1
        A3 --- T2
        A3 --- T3
    end
    classDef app fill:#fde68a,stroke:#b45309,color:#000;
    classDef tool fill:#5eead4,stroke:#0f766e,color:#000;
    class A1,A2,A3 app;
    class T1,T2,T3 tool;

위 그림에서 선이 9개(3×3)입니다. 앱과 도구가 늘면 선은 곱셈으로 폭발합니다. 각 선은 누군가 작성·유지·보안 점검해야 하는 코드입니다.

MCP는 가운데에 표준 규격을 하나 끼워 넣습니다:

flowchart LR
    A1["앱 1"] --> M{{"MCP\n(표준 인터페이스)"}}
    A2["앱 2"] --> M
    A3["앱 3"] --> M
    M --> T1["도구 A 서버"]
    M --> T2["도구 B 서버"]
    M --> T3["도구 C 서버"]
    classDef app fill:#fde68a,stroke:#b45309,color:#000;
    classDef tool fill:#5eead4,stroke:#0f766e,color:#000;
    classDef proto fill:#bfdbfe,stroke:#1d4ed8,color:#000;
    class A1,A2,A3 app;
    class T1,T2,T3 tool;
    class M proto;

이제 각 앱은 "MCP를 말할 줄 아는 클라이언트"만 갖추면 되고, 각 도구는 "MCP를 말하는 서버"로 한 번만 구현하면 됩니다. 연결 수가 M×N에서 M+N으로 줄어듭니다. 표준화된 발견(호스트가 tools/list로 도구를 자동으로 찾음), 재사용 가능한 서버(한 번 만들면 MCP 호환 호스트 어디서나 동작), 정의된 보안 모델(OAuth·TLS·샌드박싱·동의 흐름)이 핵심 이점입니다.

MCP는 무엇인가 (정확히)

MCP는 개방형 표준 프로토콜입니다. MCP는 JSON-RPC를 사용해 메시지를 인코딩하며, JSON-RPC 메시지는 반드시 UTF-8로 인코딩됩니다. 즉 MCP 자체는 "어떤 모양의 메시지를, 어떤 순서로, 어떤 통로로 주고받는가"에 대한 약속이지, 특정 회사의 제품이나 라이브러리가 아닙니다.

MCP는 2024년 11월 Anthropic이 처음 공개했고, 지금은 GitHub의 오픈소스 스펙으로 유지됩니다. 이 안내서는 2025-11-25 리비전을 기준으로 합니다.

📌 핵심: MCP는 "AI 앱 ↔ 외부 세계"를 잇는 USB-C 같은 표준입니다. 표준이므로, 당신이 만든 서버는 그 표준을 따르는 모든 호스트에서 동작합니다 — 특정 한 제품에 묶이지 않습니다.

"함수 호출(function calling)과 뭐가 다른가?"

LLM의 함수 호출(tool use)을 써본 분이라면 의문이 들 수 있습니다. "모델한테 도구 스키마 주고 호출시키는 건 이미 하던 건데?"

차이는 표준화와 재사용에 있습니다. 함수 호출은 모델 API 수준의 기능이라, 도구를 어떻게 노출하고 발견하고 호출할지는 앱마다 제각각이었습니다. MCP는 그 위에 프로토콜 계층을 얹어, 도구·데이터·프롬프트를 노출하는 방식과 발견·호출·인증·알림까지 표준 메서드로 정해 둡니다. 그래서 한 번 만든 MCP 서버를 Claude Desktop, IDE, 다른 챗 앱이 그대로 발견해 쓸 수 있습니다. (자세한 비교는 03장에서.)

"쓰기"와 "만들기"

대부분의 사람은 MCP를 소비자로 먼저 만납니다. 코딩 에이전트 설정에 서버 하나를 등록해 붙여 쓰는 식이죠. 이건 충전기 서랍에서 "이미 만들어진 USB-C 케이블을 꽂는" 일에 해당합니다.

이 안내서는 그다음 단계, 제작자가 되는 길을 다룹니다. 자기 도구·데이터를 MCP 서버로 노출해서, 표준을 따르는 어떤 호스트든 쓸 수 있게 만드는 것. 그러려면 "어떻게 동작하고, 왜 그렇게 설계됐는지"를 알아야 합니다.

flowchart TD
    U1["MCP를 소비자로 사용\n(서버를 붙여 쓰기)"] --> U2["프로토콜이 어떻게\n동작하는지 이해"]
    U2 --> U3["자기 서버를 설계·구현"]
    U3 --> U4["배포·운영·보안"]
    classDef step fill:#5eead4,stroke:#0f766e,color:#000;
    class U1,U2,U3,U4 step;

🔒 보안은 처음부터: MCP 서버는 외부 시스템과 외부 입력을 잇는 통로입니다. 통로는 곧 공격 표면이기도 합니다. 그래서 이 안내서는 보안을 별도 부(7부)로 깊이 다루고, 각 장에서도 관련 위험을 그때그때 🔒 콜아웃으로 짚습니다. "동작하게 만들기"와 "안전하게 만들기"는 같은 비중입니다.

이 장에서 배운 것

• MCP는 AI 앱과 외부 도구·데이터를 잇는 개방형 표준 프로토콜이며, M×N 통합 폭발을 M+N으로 줄인다.
• MCP는 JSON-RPC 2.0 메시지를 표준 전송 통로로 주고받는 약속이다 — 특정 제품이 아니다.
• 함수 호출과 달리 발견·호출·인증·알림까지 표준화되어, 한 번 만든 서버를 여러 호스트가 재사용한다.
• 이 안내서의 목표는 소비자를 넘어 제작자가 되는 것이며, 보안을 1급 주제로 다룬다.

✍️ 확인 문제

1. 앱이 4개, 도구가 5개일 때, 표준이 없으면 최악의 경우 몇 개의 맞춤 연결이 필요할까? MCP를 쓰면 몇 개로 줄어드나?
2. "MCP는 또 하나의 라이브러리/제품이다"라는 설명은 왜 부정확한가? 한 문장으로 고쳐 보자.
3. MCP를 "소비자로 쓰는 것"과 "서버를 만드는 것"의 차이를 한 가지 예로 설명해 보자.

다음 장: 02. 핵심 구성요소: Host · Client · Server