MCP vs API: 기존 API가 AI 에이전트에게 실패하는 이유

기존 API는 AI 에이전트를 느리고 비용이 많이 들게 만듭니다.

저는 REST와 GraphQL로 웹 앱을 구축하며 수년을 보냈습니다. 상태를 관리하고 페이로드를 최적화하는 방법을 잘 알고 있습니다. 하지만 AI 에이전트를 위한 구축은 다릅니다.

우리는 종종 LLM을 인간 개발자처럼 취급합니다. API 엔드포인트를 제공하고 알아서 작동하기를 기대하죠. 이것은 실수입니다.

Model Context Protocol (MCP)가 이를 변화시킵니다. 이는 AI 연결성을 위한 개방형 표준입니다. LLM을 도구에 연결하기 위해 커스텀 글루 코드(glue code)를 작성하고 있다면, 여러분은 기술 부채를 쌓고 있는 것입니다.

기존 API가 AI 에이전트에게 실패하는 이유:

  • N x M 문제: 5개의 AI 프레임워크와 5개의 엔터프라이즈 도구가 있다면, 25개의 커스텀 커넥터를 작성해야 합니다. MCP는 이를 N + M 아키텍처로 전환합니다. 모든 도구는 하나의 MCP 서버를 사용하고, 모든 에이전트는 하나의 MCP 클라이언트를 사용합니다.
  • 정적 vs 동적: REST API는 하드코딩된 경로를 필요로 합니다. AI 에이전트는 런타임에 도구를 발견해야 합니다. MCP는 동적 탐색(dynamic discovery)을 통해 에이전트가 사용 가능한 기능을 즉시 확인할 수 있게 해줍니다.
  • 토큰 낭비: 기존 API는 종종 거대한 JSON 페이로드를 반환합니다. 큰 페이로드는 비용을 낭비하고 지연 시간을 증가시킵니다. 또한 모델이 집중력을 잃는 '컨텍스트 부패(context rot)' 현상을 유발합니다. MCP는 LLM 컨텍스트 창에 최적화된 데이터를 반환합니다.
  • 무상태성(Statelessness): REST는 무상태입니다. AI 에이전트는 사고와 행동의 연속적인 루프 속에서 작동합니다. MCP는 방대한 데이터를 다시 보낼 필요 없이 컨텍스트를 유지하기 위해 상태 유지(stateful) 세션을 사용합니다.

MCP는 세 가지 핵심 요소로 구성됩니다:

  • 도구(Tools): SQL 쿼리 실행과 같이 모델이 취하는 작업.
  • 리소스(Resources): 로그 파일이나 문서와 같은 읽기 전용 데이터.
  • 프롬프트(Prompts): 모델의 추론을 안내하는 템플릿.

MCP가 데이터베이스나 백엔드를 대체하는 것은 아닙니다. 여러분의 MCP 서버는 여전히 기존 API를 호출할 것입니다. MCP는 이러한 서비스들을 LLM에 연결하기 위해 작성하는 취약한(brittle) 코드를 대체합니다.

LLM 호출을 위해 JSON을 문자열로 변환하는 커스텀 함수를 작성하는 일을 멈추십시오. 에이전트 중심의 미래에 맞춰 확장 가능한 아키텍처를 구축하십시오.

어떻게 생각하시나요? 이미 MCP를 사용 중이신가요, 아니면 여전히 커스텀 함수 호출(function calling) 방식을 고수하고 계신가요?

Source: https://dev.to/chaudharidevam/mcp-vs-api-why-traditional-apis-are-failing-ai-agents-28m8

Optional learning community: https://t.me/GyaanSetuAi