지난 4년 동안 현대적인 웹 애플리케이션을 구축해 온 프론트엔드 및 풀스택 개발자로서, 저는 셀 수 없이 많은 REST 및 GraphQL 엔드포인트를 연결해 왔습니다. 페이로드(payload)를 최적화하고, 상태(state)를 관리하며, Swagger 문서를 읽는 법을 잘 알고 있습니다.

하지만 지난 1년 동안 산업계가 결정론적인(deterministic) 웹 앱 구축에서 자율적인 AI 에이전트 배포로 전환됨에 따라, 저는 좌절스러운 트렌드를 발견했습니다. 우리가 검증해 온 API들이 우리의 AI 에이전트를 느리고, 비싸고, 놀라울 정도로 취약하게 만들고 있다는 점입니다.

우리는 LLM을 단순히 데이터를 가져오기 위한 API 엔드포인트만 있으면 되는 인간 프론트엔드 개발자처럼 취급해 왔습니다. 이는 근본적인 아키텍처 설계 오류입니다.

**Model Context Protocol (MCP)**가 등장했습니다. 이는 원래 Anthropic에 의해 도입되었으며 현재 Linux Foundation의 지원을 받는 개방형 표준입니다. 만약 여러분이 여전히 전통적인 REST 엔드포인트를 커스텀 글루 코드(glue code)로 수동으로 감싸서 AI 기능을 구축하고 있다면, 여러분은 기술 부채(technical debt)를 쌓고 있는 것입니다. 왜 전통적인 API가 AI 에이전트에게 실패하고 있는지, 그리고 왜 MCP가 우리가 실제로 필요로 하는 범용 어댑터인지 그 이유를 설명하겠습니다.

근본적인 문제: $N \times M$ 통합의 악몽

전통적인 앱을 구축할 때, 프론트엔드나 백엔드가 GitHub, Slack, Jira와 통신하기를 원한다면 세 개의 별도 통합 계층을 작성해야 합니다. 각 서비스의 커스텀 JSON 페이로드를 매핑하고, 특정 인증 방식을 처리하며, 실행 경로를 하드코딩합니다.

이 방식이 작동하는 이유는 사람이 작성한 코드가 결정론적(deterministic)이기 때문입니다.

하지만 AI 에이전트는 추론(reasoning)과 의도(intent)를 기반으로 작동합니다. 만약 5개의 서로 다른 LLM 프레임워크(LangChain, LlamaIndex 또는 커스텀 에이전트 설정)가 있고, 이들이 5개의 서로 다른 엔터프라이즈 도구와 상호작용하기를 원한다면, 갑자기 $5 \times 5 = 25$개의 커스텀 커넥터를 작성하고 유지 관리해야 하는 상황에 처하게 됩니다.

이것이 전형적인 $N \times M$ 통합 문제입니다.

MCP는 이를 $N + M$ 아키텍처로 축소시킵니다. 모든 도구는 하나의 MCP 서버를 구현합니다. 모든 AI 에이전트 프레임워크는 하나의 MCP 클라이언트를 구현합니다. 이 프로토콜은 범용 어댑터, 즉 LLM을 위한 USB-C 포트 역할을 합니다.

전통적인 API가 AI 에이전트에게 실패하는 3가지 이유

왜 새로운 프로토콜이 필요한지 이해하려면, LLM이 API를 소비하는 주체일 때 전통적인 REST/GraphQL API가 어떤 부분에서 부족한지 살펴보아야 합니다.

1. API는 정적이지만, 에이전트는 런타임 탐색(Runtime Discovery)을 필요로 합니다

REST API를 대상으로 코드를 작성할 때, 우리는 엔드포인트를 하드코딩합니다: GET /api/v1/users/{id}. 애플리케이션은 이 경로에서 벗어날 수 없습니다.

반면, AI 에이전트는 상황을 살펴보고, 옵션을 평가하며, *런타임(runtime)*에 어떤 도구를 사용할지 결정해야 합니다.

• REST 방식: 어떤 엔드포인트가 존재하는지 알 수 있도록 API 스키마(schema) 전체를 LLM의 시스템 프롬프트(system prompt)에 입력해야 합니다. 새로운 엔드포인트를 추가하거나 파라미터(parameter)를 업데이트하면, 프롬프트나 코드를 수정하고 다시 배포해야 합니다.
• MCP 방식: MCP는 동적 탐색(dynamic discovery) 기능을 갖추고 있습니다. MCP 클라이언트가 MCP 서버에 연결하면 tools/list 요청을 보냅니다. 서버는 사용 가능한 기능, 자연어 설명, 구조적 제약 조건이 포함된 기계 판독 가능한(machine-readable) 목록으로 응답합니다. 에이전트는 즉석에서(on the fly) 자신이 무엇을 할 수 있는지 찾아냅니다.

2. "토큰 세금(Token Tax)"과 컨텍스트 팽창(Context Bloat)

프론트엔드 세계에서 오버페칭(over-fetching)은 사소한 성능 저해 요소일 뿐입니다. 2개의 필드만 필요한데 JSON 페이로드(payload)가 50개의 필드를 반환하더라도, 자바스크립트(JavaScript) 객체는 이를 마이크로초 단위로 처리합니다.

AI 세계에서 토큰은 말 그대로 화폐입니다.

거대하고 비대해진 엔터프라이즈 REST 응답을 LLM에 직접 전달하면, 돈을 낭비하고 지연 시간(latency)을 증가시키며, 더 심각하게는 **컨텍스트 부패(context rot)**를 초래합니다. LLM은 무관한 메타데이터(metadata)에 파묻히면 집중력을 잃습니다. 깊게 중첩된 JSON 객체 안에 숨겨진 중요한 데이터를 놓치게 됩니다.

전통적인 API는 포괄적인 페이로드를 원하는 인간 개발자를 위해 설계되었습니다. MCP 서버는 실행 가능한 도구(executable tools), 읽기 가능한 리소스(readable resources), 그리고 *프롬프트 템플릿(prompt templates)*을 분리하여, LLM 컨텍스트 창(context window)에 최적화된 데이터를 반환하도록 특별히 설계되었습니다.

3. 무상태(Stateless) vs 상태 유지(Stateful) 아키텍처

REST API는 의도적으로 무상태(stateless)로 설계되었습니다. 각 요청은 격리된 이벤트입니다.

AI 에이전트(AI agents)는 진공 상태에서 작동하지 않습니다. 이들은 사고(thought), 행동(action), 관찰(observation), 그리고 개선(refinement)의 연속적인 루프를 통해 작동합니다.

MCP는 상태 유지(stateful) JSON-RPC 2.0 세션(로컬 도구의 경우 일반적으로 stdio를 사용하거나, 원격 서비스의 경우 WebSockets/SSE를 사용) 위에서 실행됩니다. 이를 통해 MCP 서버와 에이전트는 상태 유지 협상(stateful negotiation)을 수행할 수 있으며, 대규모 페이로드(payload)를 네트워크를 통해 계속해서 주고받을 필요 없이 컨텍스트(context)를 유지하고 후속 행동에 영향을 미칠 수 있습니다.

MCP의 아키텍처 (The Architecture of MCP)

MCP는 세 가지 핵심 프리미티브(primitives)를 통해 관심사의 명확한 분리(separation of concerns)를 정의합니다:

1. 도구 (Tools): 모델이 수행할 수 있는 실행 가능한 작업 (예: "이 git commit을 실행하세요", "이 SQL 쿼리를 실행하세요").
2. 리소스 (Resources): 모델에 원시 컨텍스트(raw context)를 제공하는 읽기 전용 데이터 소스 (예: 로그 파일, 로컬 마크다운 문서, API 응답).
3. 프롬프트 (Prompts): 모델의 추론 워크플로우(reasoning workflow)를 안내하는 데 도움이 되는 재사용 가능한 템플릿.

+-------------------------------------------------------------+
|                         호스트 앱 (Host App)                    |
|  (예: Cursor, Claude Desktop, 커스텀 에이전트 프레임워크)       |
...

중요한 설명: MCP는 여러분의 데이터베이스나 백엔드 API를 대체하는 것이 아닙니다. 여러분의 MCP 서버는 내부적으로 여전히 내부 REST API나 데이터베이스를 호출할 것입니다. MCP가 대체하는 것은 이러한 서비스들을 LLM에 노출하기 위해 우리가 작성해 온 *취약하고 맞춤화된 글루 코드(brittle, custom glue code)*입니다.

앞으로 나아가기: 래핑(Wrapping)을 멈추고 구조화(Structuring)를 시작하세요

만약 여러분이 여전히 JSON 페이로드를 문자열로 변환(stringify)하여 LLM API 호출 내의 tools 배열에 강제로 집어넣기 위해 커스텀 JavaScript나 Python 함수를 작성하고 있다면, 여러분은 나중에 갚아야 할 부채를 쌓고 있는 것입니다.

업계는 빠르게 MCP를 중심으로 통합되고 있습니다. 주요 IDE, 오케스트레이션 프레임워크(orchestration frameworks), 그리고 AI 제공업체들이 이를 표준으로 채택했습니다.

개발자로서 우리의 업무는 단순히 무언가가 작동하게 만드는 것에 그치지 않습니다. 확장 가능한 아키텍처를 구축하는 것이 우리의 역할입니다. 전통적인 API는 결정론적(deterministic)이고 인간이 작성한 소프트웨어를 위해 구축되었습니다. 반면 MCP는 확률론적(probabilistic)이고 에이전트 중심적인(agentic) 미래를 위해 구축되었습니다. 이제 우리의 스택을 업데이트할 때입니다.

여러분의 생각은 어떠신가요? 내부 도구 중 MCP로 전환한 것이 있나요, 아니면 여전히 전통적인 커스텀 함수 호출(custom function calling) 방식을 고수하고 계신가요? 아래 댓글에서 함께 논의해 봅시다!