MCP 대 API 비교: 차이점

모델 컨텍스트 프로토콜(Model Context Protocol, MCP) 및 애플리케이션 프로그래밍 인터페이스(Application Programming Interface, API)는 모두 서로 다른 시스템을 연결하는 디지털 브리지 역할을 합니다. MCP 기능은 API를 기반으로 구축되며, API가 없다면 MCP도 존재할 수 없습니다. 

두 기술은 작동 방식과 설계 목적에 차이가 있습니다.

• MCP는 언어 모델을 외부 툴 및 데이터에 연결하여 실시간으로 적응하고 유연하게 대응하는 워크플로우를 지원합니다. 
• 전통적인 API 워크플로우는 정해진 규칙을 따릅니다. 두 시스템이 연결되면, 이후 상호작용은 개발자가 프로그래밍한 특정 작업 범위로 제한됩니다.

MCP와 API 중에서 무엇을 사용해야 하나요?

애플리케이션이 대규모 언어 모델(LLM)을 사용하지 않으면, 더 빠르고 단순한 API를 계속 사용하세요. 만약 1개의 LLM을 직접 제어하는 1개의 서비스에 연결하는 경우, LLM의 네이티브 함수 호출(모델의 출력을 실행 가능한 명령으로 변환해 주는 LLM의 내장 기능)을 통해 API를 사용할 수도 있습니다. 

여러 AI 애플리케이션 전반에서 같은 툴을 사용해 작업해야 하는 경우, 직접 빌드하지 않은 툴을 사용하는 경우 또는 모델이 런타임 시 새로운 기능을 탐색하도록 하려는 경우에는 MCP를 사용하세요. 

Red Hat AI 살펴보기

MCP는 API 애플리케이션이 외부 툴 및 데이터와 연결되는 방식을 표준화하는 오픈소스 프로토콜입니다. 기기를 액세서리에 연결하고 데이터를 전송할 수 있는 USB-C 케이블에 비유할 수 있습니다.

MCP가 도입되기 전에는 개발자가 특정 활용 사례에 맞춰 사용자 정의 API 통합을 생성해야 했습니다. 그러므로 동일한 통합을 여러 번 조금씩 다른 방식으로 재작성해야 했습니다. AI 애플리케이션과 외부 서비스 간 연결은 매번 사용자 정의에 따라 생성되었기 때문에 상당히 많은 시간이 소요되었습니다.

MCP에 대해 자세히 알아보기 

API는 제품 또는 서비스를 구현하는 방법을 몰라도 다른 제품 및 서비스와 통신할 수 있도록 지원합니다. API는 당사자 간의 합의를 나타내는 문서가 포함된 계약으로 간주되기도 합니다. 첫 번째 측에서 특정 방식으로 구조화된 원격 요청을 보내면, 이에 따라 두 번째 측의 소프트웨어가 응답하게 됩니다.

API에 대해 자세히 알아보기

실제 활용 사례에서 이 개념이 어떻게 적용될 수 있는지 살펴보겠습니다. 웹사이트를 통해 병원 진료 예약을 하는 상황을 예로 들겠습니다. 

이 시나리오에서 사용자가 목요일 오후 2시에 Dr. Wong에게 진료 예약을 시도한다고 가정해 보겠습니다. Dr. Wong은 오후 2시에 이미 진료 예약이 차 있습니다. 그러나 오후 2시 30분에는 일정이 빕니다. 그 대신 Dr. Johnson은 오후 2시에 예약할 수 있습니다. 

전통적인 API 워크플로우에서는 소프트웨어 개발자가 병원의 API에 직접 연결되는 스크립트를 작성합니다. 사용자가 Dr. Wong에게 오후 2시에 진료를 예약하려고 시도하면 애플리케이션은 API 호출을 구성하여 Dr. Wong에게 오후 2시에 예약을 요청할 수 있는지 확인합니다. 

병원의 데이터베이스는 오후 2시에 예약할 수 없다는 것을 확인하고, 오류를 반환하며 "선택하신 시간에는 예약이 불가합니다"와 같은 메시지를 표시합니다.

그 다음 단계는 사용자에게 달려 있습니다. 프로그램은 대응할 수 없으므로 사용자가 프로세스를 다시 시작해야 하고, 다른 시간 또는 다른 의사를 지정하는 새로운 예약 요청을 제출해야 합니다. 

MCP 워크플로우에서는AI 애플리케이션이 병원의 MCP 서버로 연결되고 오후 2시에 Dr. Wong에게 예약할 수 있는지를 확인합니다. AI 애플리케이션은 LLM을 기반으로 요청을 생성하기 때문에 여러 대안을 평가하고 사용자와 상호작용할 수 있습니다. 

여기서는 "Dr. Wong의 오후 2시 진료 예약은 현재 불가능합니다. 예약 가능한 다음 시간은 오후 2시 30분입니다. 오후 2시 진료를 원하시면 Dr. Johnson으로 예약해 주시기 바랍니다. 어느 분으로 예약해 드릴까요?"와 같은 메시지가 표시됩니다.

사용자가 일정을 확인하고 "Dr. Johnson, 오후 2시 진료로 예약해 주세요"라고 응답합니다. 그러면 애플리케이션은 오후 2시에 Dr. Johnson에게 진료를 받는 새로운 예약 요청을 생성하여 사용자의 확인을 구합니다. 

MCP를 통해 AI 모델은 어떤 툴을 사용하고, 언제 사용하고, 결과를 어떻게 이해해야 하는지를 동적으로 결정할 수 있습니다. 다음과 같은 경우 MCP를 선택하세요.

• 애플리케이션이 LLM 또는 에이전틱 워크플로우를 기반으로 합니다. LLM이 단독으로 API를 호출하거나 코드를 실행할 수 없습니다. 모델을 실행하는 애플리케이션은 툴 호출을 통해 이 문제를 해결합니다. MCP는 이러한 툴이 설명되고 제공되는 방식을 표준화하므로, 동일한 툴이 다양한 AI 애플리케이션에 걸쳐 작동할 수 있습니다. 
• 워크플로우에 복잡한 다단계 태스크가 포함됩니다. 프로그램이 데이터베이스를 쿼리한 뒤 결과물을 요약하고 타사 애플리케이션을 업데이트하도록 하려는 경우, MCP를 통해 AI 에이전트가 이러한 단계를 연쇄적으로 처리하도록 할 수 있습니다.
• 즉흥적인 대응이 어느 정도 가능합니다. MCP 기반 애플리케이션은 대안을 평가하고 예기치 않은 장애물을 처리하고 전략을 유연하게 조정할 수 있습니다. 
• 툴 이식성이 필요합니다. 단일 MCP 서버는 모든 MCP 호환 AI 애플리케이션과 통신할 수 있습니다. 즉, 호환성을 갖추고 있다면 한 번 구축해 여러 클라이언트에 걸쳐 재사용할 수 있습니다.
• 실시간으로 기능을 추가하려 합니다. MCP를 사용하면 애플리케이션이 실행되는 동안 기능을 추가할 수 있습니다. 따라서 가능한 모든 기능을 미리 프로그래밍해둘 필요가 없습니다. 

API는 컴퓨터 코드를 다른 컴퓨터 코드에 빠르고 예측 가능하게 연결해야 할 때 여전히 표준으로 사용됩니다. 다음과 같은 경우 API를 선택하세요.

• 태스크가 단순하며 하나의 목적만 있습니다. 데이터베이스에서 숫자를 가져오는 것처럼 단순한 작업에는 MCP가 필요하지 않습니다.
• LLM이 수반되지 않습니다. 소프트웨어가 전통적인 머신 러닝이나 표준적인 비AI 백엔드 코드만 사용하면, 기존의 API로 원시 데이터를 충분히 처리할 수 있습니다. 
• 속도와 효율성이 중요합니다. 전통적인 API는 몇 밀리초 만에 응답할 수 있습니다. MCP 툴 호출도 비교적 신속하고 워크플로우도 빠른 편이지만, 그러한 워크플로우에는 모델 추론이 포함되기 때문에 응답 시간이 초 단위로 늘어납니다. 
• 시스템이 내리는 모든 결정을 완전히 제어하려 합니다. 전통적인 API는 항상 정확한 지시를 따릅니다. 

사용자 정의 코드를 사용해 LLM을 기존 API에 직접 연결하는 것은 기술적으로 가능하지만, 그만한 수고를 들일 가치는 없을 것입니다. API를 LLM에 연결하면 개발자는 지원하려는 개별 AI 애플리케이션 각각에 대해 사용자 정의 코드를 작성해야 합니다. 또한 API는 고정된 로직('A가 발생하면 B를 실행한다')을 기반으로 하므로 현대적인 에이전틱 AI가 실시간으로 태스크를 추론하는 데 필요한 유연성을 가질 수 있는 여지가 없습니다.

MCP는 AI 에이전트가 가진 강력한 기능인 동적 검색을 지원하도록 설계되었습니다. 이는 AI 에이전트가 서버에 연결하여 어떤 기능이 있는지 질문한 다음, 사람의 개입 없이 해당 기능을 즉시 사용할 수 있는 능력을 가리킵니다. 

동적 검색은 서버 기능과 기계 판독형 스키마 덕분에 가능합니다. 즉, 사람 개발자가 웹 매뉴얼을 읽는 대신 표준 JSON으로 작성된 구조화된 스키마를 통해 LLM은 툴 이름, 매개변수 요구 사항, 데이터 유형을 자체적으로 파악할 수 있습니다. 그런 다음 MCP는 이러한 서버 기능을 다음 3개 범주로 분류합니다. 

• 에이전트가 조치를 취하도록 지원하는 툴
• 에이전트에 맥락을 제공하는 리소스
• 지시 템플릿 역할을 수행하는 프롬프트

MCP의 인기가 계속 높아지면서 GitHub, Slack, Google Drive와 같은 인기 플랫폼을 위한 사전 구축된 통합, 다시 말해 즉시 사용 가능한 MCP 서버의 수도 함께 늘어나고 있습니다. 기계 판독형 스키마, 실시간 검색, 사전 구축된 툴을 함께 사용하면 에이전트가 진정한 상황 인식 AI 워크플로우를 생성할 수 있는 충분한 정보를 제공할 수 있습니다. 이는 에이전트가 실시간 환경을 지속적으로 평가하고, MCP 리소스로부터 컨텍스트를 도출하고, 해당 시점에 적합한 툴을 선택하고, 실제 피드백을 바탕으로 추론을 조정하는 프로세스입니다. 

MCP server for Red Hat OpenShift® AI 살펴보기

MCP 서버를 보호하려면 기본 인증만으로는 부족합니다. 모든 작업에 대한 정밀한 규칙, 엄격한 경계가 설정된 디지털 키, 해당 툴이 "말하는" 다양한 보안 언어를 모두 처리할 수 있는 시스템이 필요합니다.

살펴보기: MCP 게이트웨이에 대한 인증 및 권한 부여

MCP는 API를 대체하나요?

아니요, MCP는 API의 보편적인 대체품이 아닙니다. MCP는 AI 모델이 툴과 소통하는 것을 지원하도록 설계되어 있습니다. 애플리케이션이 언어 모델을 사용하지 않는다면 MCP가 필요하지 않습니다. 

기업의 경우 MCP 도입에 대한 논의는 어떻게 안전하게 적용할 것인지로 진화했습니다. MCP 서버는 AI 에이전트에 다양한 툴과 데이터에 대한 접근 권한을 부여할 수 있습니다. 그러나 거버넌스 계층이 없이는 어떤 에이전트가 무엇에 접근할 수 있는지 제어하거나, 속도 제한을 적용하거나, 보안 정책을 시행할 수 있는 일관된 방법이 없습니다. 

MCP gateway for Red Hat OpenShift에 대해 알아보기

MCP 게이트웨이란?

MCP 게이트웨이는 AI 에이전트와 해당 에이전트가 연결되는 MCP 서버 사이에 위치합니다. 이는 인프라 계층에서 트래픽 제어를 처리하며, AI 에이전트와 해당 에이전트가 사용하는 MCP 서버 간의 모든 툴 호출을 하나의 관리되는 체크포인트를 통해 라우팅합니다. 

MCP 게이트웨이를 사용하는 목적은 대규모 환경에서 MCP 서버 연결을 보호하는 데 있습니다. 구체적으로 다음을 지원합니다.

• 보안. 기업은 역할 기반 액세스 제어(Role-based Access Control, RBAC)를 시행할 수 있습니다. 이는 일종의 가드레일과 같은 역할을 합니다. 예를 들어 마케팅 에이전트가 소셜 미디어 MCP 서버에는 액세스할 수 있지만 급여 서버에는 액세스할 수 없도록 통제할 수 있습니다.
• 관측성. 게이트웨이는 중앙화된 감사 로그를 생성하여 에이전트를 시작한 사용자, 사용된 MCP 툴, 반환된 응답과 같은 정보를 기록합니다. 
• 비용. 게이트웨이는 에이전트당 토큰 소비에 대해 속도 제한을 적용하고 팀이 툴당 사용량에 따라 비용을 할당할 수 있도록 합니다. 
• 신뢰성. 게이트웨이는 서비스 장애 발생 시 툴 요청을 새로운 엔드포인트로 자동 전환할 수 있습니다. 

Red Hat® AI는 vLLM 기반 서버로 신속하고 유연하며 효율적인 추론 성능을 제공합니다. 모델과 데이터를 안정적으로 연결하여 하나의 플랫폼에서 전문 에이전트의 사용자 지정 및 개발을 통합합니다. 오픈소스 기반의 당사 제품으로 규모와 상관없이 AI 워크플로우의 모든 과정을 완전히 제어할 수 있습니다. 

Red Hat AI Portfolio에 Red Hat AI Enterprise가 포함됩니다. Red Hat AI Enterprise는 모든 인프라에서 AI 추론, 에이전틱 AI 워크플로우, AI 기반 애플리케이션을 배포, 관리, 확장할 수 있는 플랫폼입니다.

Red Hat AI 살펴보기