MCP는 왜 필요한가: AI의 지능이 아니라 소프트웨어 연결의 표준

1. 이미 다 되던 일인데, 왜 굳이 프로토콜인가?

Codex나 Cursor 같은 최신 AI 코딩 도구를 일상적으로 써온 개발자에게, "MCP(Model Context Protocol)"라는 단어는 오히려 낯설고 모호하게 다가온다.

우리는 이미 AI에게 수많은 작업을 시키고 있다. AI는 프로젝트 폴더 안의 소스 코드를 읽고, 터미널 명령어를 실행해 테스트를 돌리며, Git 커밋 로그를 뒤지고, 브라우저를 띄워 문서를 검색한다. 이미 손발이 달린 것처럼 외부 세계와 상호작용하고 있는데, 어느 날 안트로픽(Anthropic)이 MCP라는 새로운 기술을 발표하며 이것이 에이전트 시대의 새로운 혁신이라고 강조한다.

자연스럽게 근본적인 의문이 솟구친다. "이거 원래 API랑 함수 호출(Function Calling)로 다 하던 거잖아? 왜 굳이 또 새로운 프로토콜을 만들어서 난리를 치는 걸까? 새로운 마케팅 사기인가, 아니면 진짜 필요한 표준인가?"

결론부터 말하자면, 사용자 입장에서 "AI가 도구를 쓰는 경험" 자체는 이전과 크게 다르지 않다. MCP가 등장했다고 해서 AI 모델의 추론 능력이 비약적으로 똑똑해지거나, 기존에 불가능했던 완전히 새로운 기능이 기적처럼 생겨나는 것은 아니다.

MCP의 본질은 AI의 지능에 있는 것이 아니라, 서로 다른 AI 도구와 외부 소프트웨어를 연결하는 상호운용성(Interoperability)의 표준화에 있다.

2. N × M의 지옥: 에디터가 겪었던 일을 AI가 겪다

소프트웨어의 역사를 돌이켜보면, 완전히 새로운 기술이 아니라 "연결 규약의 표준화"만으로 생태계의 판도를 바꾼 결정적인 사건들이 있었다. 가장 대표적인 사례가 바로 마이크로소프트가 주도한 LSP(Language Server Protocol)다.

과거에는 VS Code, IntelliJ, Sublime Text, Vim 같은 수많은 코드 에디터(N개)가 존재했고, 파이썬, 러스트, 고, 타입스크립트 같은 프로그래밍 언어(M개)가 존재했다. 에디터마다 자동 완성, 문법 오류 검사, 정의로 이동 같은 기능을 지원하려면, 에디터 개발사가 각각의 언어에 맞는 전용 플러그인을 하나하나 새로 개발해야 했다.

결과는 N × M개의 파편화였다. 5개의 에디터가 10개의 언어를 온전히 지원하려면 무려 50개의 개별 플러그인을 만들고 유지보수해야 했다.

LSP는 이 문제를 단숨에 해결했다. 에디터와 언어 분석기 사이에 공통 언어(LSP)를 정의한 것이다. 언어 개발팀은 단 하나의 LSP 서버만 만들면 되었고, 에디터 개발사는 단 하나의 LSP 클라이언트만 구현하면 끝났다. 50번의 작업이 (5 + 10 = 15)번으로 줄어들었다.

오늘날 AI 에이전트 시장이 마주한 혼란이 바로 10년 전 에디터 시장과 완벽하게 똑같다. 한쪽에는 Codex, Claude Code, Cursor, Windsurf, ChatGPT 같은 수많은 AI 애플리케이션(Host)이 있다. 다른 한쪽에는 GitHub, Sentry, Notion, PostgreSQL, Slack 같은 수많은 외부 서비스와 데이터베이스(Service)가 있다.

MCP가 없다면 어떻게 될까? GitHub 기능을 Cursor에서 쓰기 위해 전용 플러그인을 짜고, 똑같은 기능을 Claude Code에서 쓰기 위해 또 다른 플러그인을 짜고, Codex를 위해 또다시 맞춤형 연동 코드를 작성해야 한다. 연결해야 할 서비스가 100개이고 AI 도구가 10개라면, 세상의 개발자들은 1,000벌의 전용 코드를 짜느라 막대한 시간과 비용을 낭비해야 한다.

MCP는 AI 세계에 USB-C 포트를 꽂겠다는 선언이다. 서비스 제공자는 자사의 API를 감싸는 단 하나의 MCP Server만 배포하면 되고, AI 도구 개발사는 MCP Client 규약 하나만 지원하면 된다. 양쪽이 규약을 맞추는 순간, 사용자는 어떤 AI 도구를 쓰든 클릭 한 번으로 수백 개의 외부 서비스를 자유롭게 연결해 쓸 수 있게 된다.

확대

3. 세 가지 층위의 명확한 구분: API, Function Calling, 그리고 MCP

현장 실무에서 가장 흔히 발생하는 혼란은 API, Function Calling, 그리고 MCP를 같은 층위의 기술로 오해하는 데서 비롯된다. 세 가지는 경쟁 관계가 아니라 완벽하게 분리된 세 개의 계층이다.

첫째, API(Application Programming Interface)는 서비스가 외부 세상에 제공하는 고유한 기능의 원천이다. GitHub API가 없으면 GitHub에서 이슈를 가져올 수 없다. API는 비즈니스 로직과 데이터의 실제 저장소다.

둘째, Function Calling(도구 호출)은 거대언어모델(LLM)이 인간의 자연어 질문을 읽고 "지금은 search_issues라는 함수를 이러이러한 인자로 실행해야겠군"이라고 판단하여 정형화된 JSON을 출력하는 모델 자체의 인지적 선택 메커니즘이다. 모델은 함수를 선택할 뿐, 실제로 코드를 실행하는 것은 모델 바깥의 런타임 프로그램이다.

셋째, MCP(Model Context Protocol)는 그 함수 목록과 데이터를 AI 애플리케이션과 외부 서버 사이에서 어떻게 주고받을 것인가를 규정한 통신 규약이다.

기존 Function Calling에서는 개발자가 직접 프롬프트 안에 함수 이름과 매개변수 스키마를 하드코딩해서 집어넣어야 했다. 하지만 MCP 환경에서는 AI 애플리케이션이 연결된 MCP 서버에 tools/list라는 표준 메시지를 던져 "네가 지금 제공할 수 있는 도구 목록과 입력 규격이 뭐니?"라고 묻는다. 서버가 도구 목록을 응답하면, AI는 그 규격을 모델에게 넘겨주고, 모델이 특정 도구를 호출하기로 결정하면 tools/call 메시지를 서버에 전달해 실제 동작을 위임한다.

즉, API는 실제 일하는 공장이고, Function Calling은 지휘관(LLM)의 명령서이며, MCP는 명령서를 전달하고 물건을 실어 나르는 표준화된 컨테이너 규격이다.

4. MCP 아키텍처의 3대 핵심 기둥: Tools, Resources, Prompts

MCP 명세(Specification)를 살펴보면, 서버가 클라이언트에게 노출할 수 있는 원천 데이터는 크게 세 가지 프리미티브(Primitive)로 나뉜다.

1. Tools (도구): 모델이 직접 호출할 수 있는 실행 가능한 함수다. create_issue, execute_sql_query, deploy_worker 같은 도구가 여기에 해당한다. 모델의 판단에 따라 능동적으로 실행되며, 외부에 실질적인 부수 효과(Side-effect)를 일으킬 수 있다.

2. Resources (자원): 파일 내용, 데이터베이스 스키마, 시스템 로그처럼 모델에게 배경 맥락(Context)으로 읽혀야 하는 데이터다. URI(file:///, postgres://) 형태로 식별되며, 모델이 직접 실행하기보다는 AI 애플리케이션이 필요에 따라 읽어와 컨텍스트 창에 주입한다.

3. Prompts (프롬프트 템플릿): 서버 측에서 미리 정교하게 깎아둔 재사용 가능한 지침 템플릿이다. 코드 리뷰 전용 프롬프트나 인시던트 장애 분석 템플릿처럼, 사용자가 슬래시 명령어 등을 통해 의도적으로 호출할 수 있는 사전 정의된 상호작용이다.

flowchart TD
  User["사용자의 자연어 요청"] --> Host["AI Host 애플리케이션: Codex / Cursor / Claude Code"]

  subgraph MCP_Boundary["MCP 프로토콜 통신 계층"]
    Host <-->|tools/list: 도구 목록 발견| MCPServer["외부 서비스 전용 MCP Server"]
    Host <-->|resources/read: 맥락 주입| MCPServer
  end

  Host -->|도구 스키마 + 프롬프트 전달| LLM{"거대언어모델: LLM 추론 엔진"}
  LLM -->|Function Calling 판단: 도구와 인자 선택| Host

  Host -->|tools/call: 실행 위임| MCPServer
  MCPServer -->|인증된 실제 요청| ExternalAPI["실제 서비스 및 데이터베이스: GitHub / DB / Sentry"]
  ExternalAPI -->|결과 반환| MCPServer
  MCPServer -->|결과 JSON 반환| Host
  Host --> LLM
  LLM --> FinalAnswer["최종 사용자 응답 도출"]

5. 빛 뒤에 숨은 그림자: 토큰 낭비, 컨텍스트 오염, 그리고 보안

MCP의 표준화가 가져다주는 장점은 명확하지만, 실무적인 관점에서는 결코 만병통치약이 아니다. 오히려 무분별하게 도입했을 때 치명적인 병목과 위험을 초래한다.

첫째는 컨텍스트 창의 낭비와 프롬프트 오염(Context Bloat)이다. MCP 서버를 대여섯 개만 연결해도, 각 서버가 노출하는 수십 개의 도구 설명(Description)과 JSON 스키마가 모델의 시스템 프롬프트에 고스란히 적재된다. 도구 설명만으로 수천, 수만 개의 토큰을 잡아먹게 된다. 더 심각한 문제는 모델의 집중력 분산이다. 쓸데없이 도구가 너무 많이 주어지면, 정작 사용자가 원하는 단순한 코딩 작업에서도 엉뚱한 외부 도구를 호출하려 들거나 판단 속도가 급격히 느려지는 추론 저하 현상이 발생한다.

둘째는 보안과 공격 표면(Attack Surface)의 급증이다. 로컬 환경에서 구동되는 MCP 서버는 대개 npx나 바이너리를 통해 개발자의 터미널 권한을 그대로 쥐고 실행된다. 출처가 불분명한 오픈소스 MCP 서버를 무턱대고 설치하는 것은, 검증되지 않은 외부 실행 파일을 루트 권한으로 실행하는 것과 다를 바 없다.

더욱이 외부 데이터(이슈 본문, 웹 문서, 슬랙 메시지) 속에 악의적인 명령을 숨겨두는 간접 프롬프트 인젝션(Indirect Prompt Injection) 공격이 유입될 경우, 모델이 악성 지시문을 정상 명령으로 착각하여 MCP 서버를 통해 사용자의 비공개 API 키나 데이터베이스를 외부에 유출할 위험이 상존한다. 따라서 성숙한 엔지니어링 환경에서는 아무 MCP나 연결하는 것이 아니라, 반드시 읽기 전용(Read-only) 격리, 실행 승인 단계(Human-in-the-loop), 최소 권한 원칙을 엄격하게 세워야 한다.

확대

6. 왜 몰라도 지금까지 아무 문제가 없었을까?

글을 시작하며 던졌던 가장 솔직한 질문으로 돌아가 보자. "나는 지금까지 MCP라는 걸 전혀 신경 쓰지 않고도 AI 코딩을 훌륭하게 해왔는데, 왜 몰라도 상관없었을까?"

그것은 진짜 잘 만들어진 인프라일수록 사용자의 눈에 띄지 않기 때문이다. 우리가 웹 브라우저를 열어 인터넷을 서핑할 때 TCP/IP 패킷의 삼방향 핸드셰이크(3-way handshake)나 TLS 암호화 인증서의 교환 과정을 일일이 알지 못해도 아무런 지장이 없는 것과 같다.

Codex나 Cursor 같은 훌륭한 도구들은 이미 로컬 파일 시스템을 읽고 쓰는 자체적인 내장 도구를 갖추고 있다. 단일 도구 안에서 내 컴퓨터의 코드만 편집하는 닫힌 환경에서는 굳이 외부 MCP 서버를 엮을 필요가 없다.

하지만 당신의 개발 조직이 GitHub의 이슈와 Sentry의 장애 로그, 그리고 사내 PostgreSQL 데이터베이스의 스키마를 하나의 AI 환경에서 매끄럽게 연결해야 할 때, 그리고 그 기능을 특정 에디터 하나에 종속시키지 않고 사내의 모든 개발자가 쓰는 다양한 도구에 공통으로 배포해야 할 때, 비로소 MCP는 대체 불가능한 위력을 발휘한다.

결국 MCP는 AI가 생각하는 방식을 바꾸는 지능의 혁명이 아니다. AI가 이미 가지고 있던 판단력을 우리가 지난 수십 년간 쌓아 올린 견고한 소프트웨어 세계와 가장 마찰 없이 연결해 주는, 지극히 실용적이고 조용한 배관(Plumbing)의 표준화다.