MCP와 API 차이 완벽 정리: 실행 계층·디스커버리, 언제 MCP를 써야 하나

핵심 메시지

• MCP는 API를 대체하는 것이 아니라, 기존 API 앞에 놓여 AI 애플리케이션을 향하는 표준 계층 역할을 한다.
• 핵심 비밀은 '모델은 API를 직접 호출하지 않는다'는 것이다. 모델은 무엇을 할지 텍스트로 정할 뿐, 실제 호출은 모델 바깥의 '실행 계층'이 수행한다.
• 앱이 늘고 연결할 서비스가 늘면 직접 통합은 앱 수×서비스 수만큼 불어난다. MCP는 앱마다 클라이언트, 서비스마다 서버를 두어 이를 앱 수＋서비스 수로 줄인다.
• MCP 클라이언트는 각 서버에 '어떤 동작이 가능한지' 물어보는 디스커버리를 하고, 그 메뉴를 모델에 보여 모델이 작업에 맞는 동작을 고르게 한다. 더 이상 모든 결정을 하드코딩하지 않아도 된다.
• 단일 앱에서 익숙한 API 몇 개만 부른다면 직접 통합이 합리적이다. MCP는 여러 AI 앱이 같은 시스템을 공유해야 할 때 비로소 값어치를 한다.

쉽게 이해하기

'MCP가 모든 것을 바꾼다'는 쪽과 '이미 API가 있는데 왜 새 것이 필요하냐'는 쪽이 늘 부딪힌다. API는 두 프로그램이 대화하는 방식이다. 예컨대 슬랙은 특정 URL 엔드포인트를 노출하고, 내 프로그램이 그 URL로 요청을 보내면 슬랙이 데이터를 응답한다. 깔끔하고 예측 가능하다. 문제는 개발자가 이런 통합을 서비스마다 직접 만들고, 언제 어떤 API를 부를지 규칙까지 손으로 짜야 한다는 점이다. 실제 앱은 슬랙 하나가 아니라 이메일·이슈 트래커·문서·데이터베이스 등 열 개 서비스와 이야기하고, 각각에 대해 인증·호출·오류 처리·재시도를 반복해서 작성한다.

여기에 LLM을 붙이면 상황을 보고 무엇을 할지 모델이 판단하게 할 수 있다. 그런데 결정적으로, 모델은 API를 직접 호출하지 않는다. 모델은 '슬랙의 이 채널에 이런 메시지를 보내라'처럼 무엇을 원하는지 텍스트로 쓸 뿐이고, 실제 호출은 개발자가 만든 일반 코드가 한다. 즉 모델을 더해도 열 개의 API 통합은 그대로 남는다. 모델은 어떤 호출을 할지 고를 뿐, 그 호출 자체는 여전히 사람이 만든 것이다. 두 번째 앱을 만들면 같은 열 개 통합을 처음부터 또 짜야 해서 두 앱이면 20개, 이듬해 세 번째 앱이면 30개로 불어난다.

MCP의 발상은 '이 API 호출들을 앱마다 하드코딩하지 말자'는 것이다. 각 앱은 표준 부품인 MCP 클라이언트를 갖고, 각 서비스에는 그 옆에 붙는 작은 프로그램인 MCP 서버를 둔다. 클라이언트와 서버는 하나의 공통 언어로 말하므로 어떤 클라이언트든 어떤 서버와도 통한다. 앱 두 개면 클라이언트 두 개, 서비스 열 개면 서버 열 개로, 20개의 개별 통합 대신 약 12개 부품으로 줄어든다. 게다가 슬랙처럼 인기 있는 제품은 공식 MCP 서버가 이미 존재해 그대로 재사용할 수 있고, 사내 도구나 자체 DB만 직접 서버를 만들면 된다. 클라이언트조차 대부분 AI 프레임워크에서 가져온다.

한 MCP 서버는 여러 동작을 제공할 수 있다. 클라이언트는 열 개 서버에 접속해 '어떤 동작이 가능한지' 물어보는데, 이것이 디스커버리다. 앱은 그 동작 목록을 모델에 보여주고 모델이 작업에 맞는 것을 고른다. 라벨이 붙은 도구 상자를 건네고 모델이 집게 하는 식이다. 한 번의 왕복은 이렇다. 사용자가 문의를 보내면 앱은 그 메시지와 디스커버리로 얻은 동작 목록을 모델에 전달하고, 모델은 '이슈를 생성하라'는 텍스트를 쓴다. 앱은 이를 MCP 클라이언트에 넘기고, 클라이언트는 해당 MCP 서버로 보내며, 그 서버만이 실제로 기존 API를 호출해 티켓을 만든다. 결과는 서버→클라이언트→앱을 거쳐 다시 모델 앞에 평문으로 놓이고 모델이 최종 답을 쓴다. 모델은 결정과 응답만, 클라이언트·서버는 메시지 전달만, 실제 일은 예전 그대로의 API가 한다.

그렇다면 그냥 모델에 OpenAPI 명세를 주면 되지 않을까? 실제로 가능하고 작동도 한다. 다만 명세는 에이전트에게 어떤 API가 있는지 '알려줄' 뿐, 자격증명을 쥐고 요청을 보내고 실패를 처리해 결과를 되돌리는 '실행 계층'을 만들어 주지는 않는다. MCP가 주는 것은 바로 그 표준 실행 계층이다. 또한 원시 API 메서드는 개발자를 위해 잘게 쪼개져 있어 여러 번 엮어야 하지만, MCP 서버는 이를 이름이 분명한 하나의 동작으로 감싸고, 밑단 API가 바뀌어도 한 곳만 고치면 된다. 웹 API만 기술하는 OpenAPI와 달리 로컬 파일·터미널·데이터베이스에도 MCP 서버를 붙일 수 있다. 주의점도 있다. 모든 동작을 한꺼번에 불러오면 컨텍스트 비용이 커지므로 필요한 동작만 검색해 싣는 편이 좋고, API 키는 비밀번호와 같아 모델이 절대 보지 못하게 실행 계층이 보관해야 한다. 결론적으로 단일 앱이라면 직접 통합이 더 단순할 수 있고, 같은 기능을 여러 AI 앱과 시스템이 공유해야 할 때가 바로 MCP가 필요한 지점이다.

주요 인사이트

• MCP는 모델에 새 능력을 주지 않는다. 밑단은 여전히 평범한 API와 코드이며, MCP가 주는 것은 열 개 앱이 하나의 실행 계층을 공유하게 하는 '표준'이다.
• '모델은 API를 직접 부르지 않는다'는 한 문장이 전체 그림의 핵심이다. 결정은 모델이, 실행·자격증명·오류 처리는 모델 바깥의 실행 계층이 맡는다는 분리를 이해하면 MCP도 자연스럽다.
• 직접 통합은 앱 수×서비스 수로 늘지만 MCP는 앱 수＋서비스 수로 늘어난다. 이 곱셈과 덧셈의 차이가 앱이 여러 개일 때 MCP가 값어치를 하는 이유다.
• OpenAPI 명세를 주는 것과 MCP는 다른 층의 문제다. 명세는 '무엇이 있는지' 가르쳐 줄 뿐이고, 실제로 자격증명을 쥐고 호출·실패 처리·결과 반환을 하는 실행 계층은 별도로 필요하다.
• MCP가 만능은 아니다. 단일 앱·일회성 작업이거나 쓸 만한 서버가 없으면 직접 통합이 더 합리적이며, 컨텍스트 비용과 키 관리 같은 보안 설정은 여전히 개발자의 몫이다.

자주 묻는 질문

관련 AI 소식