MCP와 API 비교 — MCP가 있어도 API가 필요한 이유

AI 요약

MCP(Model Context Protocol)가 빠르게 확산하면서 API를 대체할지 묻는 사람이 늘었습니다. 글의 답은 “아니요”입니다. MCP 서버는 대개 기존 REST·GraphQL·gRPC API를 호출하고, 그 기능을 LLM이 알아보고 안전하게 실행하도록 번역하는 얇은 어댑터입니다. AI가 호출자가 아니라면 일반 API를 쓰고, LLM 에이전트가 호출한다면 MCP가 더 적합할 수 있습니다.

API는 미리 알고 호출하는 계약입니다

일반적인 API는 HTTP 엔드포인트, 요청·응답 형식, 인증 방법을 정한 계약입니다. 개발자는 문서를 읽고 정해진 URL과 매개변수로 요청을 만드는 코드를 작성합니다. 호출할 대상과 입력값이 미리 정해져 있으며, 인증 정보도 호출하는 쪽에서 관리합니다. 호출자는 사람이 작성한 결정론적 코드입니다.

MCP는 호출자가 사람이 아니라 LLM인 상황에 맞춘 클라이언트·서버 프로토콜입니다. JSON-RPC 2.0으로 통신하며, 세 역할로 구성됩니다. Host는 Claude나 IDE 같은 AI 애플리케이션입니다. Host가 서버마다 Client를 만들고, Server는 도구(tools), 읽을 수 있는 자료(resources), 재사용 가능한 템플릿(prompts)을 내놓습니다. 각 기능은 자연어 설명과 JSON Schema를 갖춰 모델이 사람이 문서를 읽지 않아도 기능과 인자를 파악하도록 돕습니다.

같은 API를 다른 호출자에게 맞춥니다

예를 들어 날씨 조회를 MCP 도구로 감싸도 실제 날씨 API 호출은 그대로입니다. 달라지는 점은 모델에 API 키나 임의의 엔드포인트를 직접 보여주지 않는다는 것입니다. 모델은 도구 이름과 설명, 스키마만 받습니다. 자격 증명과 요청 구성은 서버 안에 남습니다. 이를 통해 모델이 키를 노출하거나 잘못된 매개변수를 만들어내는 위험을 줄입니다.

전통적인 API는 사람이 문서를 읽고 기능을 골라 호출하는 방식입니다. MCP는 tools/list로 도구 이름과 설명, 스키마를 알아내고 모델이 실행 시점에 무엇을 부를지 선택합니다. API마다 REST, GraphQL, SOAP, gRPC처럼 형식이 다르지만 MCP는 JSON-RPC 패턴을 공통 인터페이스로 씁니다. API에서는 호출자가 인증을 직접 처리하지만, MCP에서는 서버가 자격 증명을 보관합니다. API 호출은 코드가 정해진 대로 실행되는 반면, MCP에서는 모델이 도구와 인자를 비결정적으로 선택합니다. MCP는 도구별 입력 제한과 검증, 로깅을 패턴에 포함할 수 있습니다. 반면 HTTP API는 캐시와 CDN 활용에 유리하고, 초기 MCP는 세션 상태와 전송 방식에서 제약을 겪었습니다.

빠른 확산과 해결되지 않은 운영 문제

글은 Anthropic이 2024년 11월 MCP를 공개한 뒤 OpenAI, Google DeepMind, Microsoft도 채택했고, PulseMCP 목록에 서버가 5,500개 넘게 올라왔다고 설명합니다. 2025년 5월 이후 원격 MCP 서버 배포도 약 4배 늘었다고 합니다. 동시에 프로토콜은 계속 바뀌고 있습니다. 본문은 2026년 7월 28일 릴리스에서 초기화 핸드셰이크와 고정 세션 ID를 없애 와이어 수준에서 무상태(stateless)가 됐다고 설명합니다. 그 결과 로드 밸런서 뒤의 여러 서버 인스턴스가 요청을 나눠 처리할 수 있습니다. 확장 프레임워크와 MCP Apps, OAuth 2.0·OIDC에 맞춘 인증 변경도 포함됐다고 덧붙입니다.

운영 위험도 짚습니다. 일부 구현은 관련성과 관계없이 모든 도구 스키마를 매 요청마다 모델 컨텍스트에 넣습니다. GitHub MCP 서버 초기화에 약 5만 토큰이 든 사례와, 도구가 100개 넘는 데이터베이스 서버가 사용자 질의 전에 컨텍스트 창의 최대 81%를 낭비한 측정 결과를 소개합니다. 보안 측면에서는 조사 대상 MCP 구현의 43%에서 명령 주입 취약점이 발견됐고, 인터넷에 노출된 서버 약 2,000개가 인증 없이 운영됐다는 스캔 결과를 언급합니다. mcp-remote의 심각도 9.6 취약점과 Anthropic Inspector 도구의 원격 코드 실행(RCE) 사례도 듭니다. 초기 설계에서 리소스 서버와 인증 서버 역할을 혼동한 점도 문제로 지적합니다. 초기 MCP의 상태 유지 방식은 서버가 멈췄을 때 한 요청이 아니라 세션 전체에 장애를 일으킬 수 있었습니다.

따라서 버전을 고정하고 도구 권한을 좁게 설정하며, 실제 인증 없이 MCP 서버를 인터넷에 공개하지 말라고 권합니다. 컨텍스트 낭비를 줄이려면 모든 스키마를 한꺼번에 노출하기보다 검색이나 기능 목록 도구를 먼저 제공하고, 현재 작업에 필요한 스키마만 불러오는 점진적·지연형 공개 방식이 대안으로 언급됩니다.

어떤 경우에 무엇을 쓸까요?

호출자가 직접 통제하는 결정론적 코드라면 API를 유지하는 편이 낫습니다. HTTP 캐싱과 CDN, 로드 밸런서를 활용해야 하거나 공개 개발자 플랫폼과 SDK를 제공하는 경우, 백엔드 내부 서비스 간 통신도 일반 API가 어울립니다. 반대로 LLM이나 에이전트가 실행 시점에 쓸 기능을 골라야 하거나, 사람이 문서를 읽지 않아도 기능을 발견하게 만들려는 경우 MCP 서버를 API 위에 추가할 수 있습니다. 모델에 원본 자격 증명 대신 제한되고 감사 가능한 접근 권한을 주려는 경우에도 MCP를 고려합니다. 실무에서는 API를 실행 계층으로 두고, 모델이 쓸 일부 기능만 골라 MCP 어댑터로 노출하는 구성이 일반적이라는 설명입니다.

dev.to 반응

• @mthburnsbarberweb — “호출자는 사용 가능한 기능과 올바르고 안전한 호출 방법을 즉석에서 알아내야 하는 LLM입니다”라는 문장이 MCP와 API 차이를 한 줄로 설명합니다. GitHub MCP 서버 초기화에 드는 5만 토큰은 컨텍스트 사용량을 측정하지 않고 MCP 서버를 만드는 팀에 보여줘야 할 수치입니다. 도구가 100개 넘는 데이터베이스 서버에서 컨텍스트의 81%를 낭비한다는 통계는 더 놀랍습니다. API는 “원하는 걸 알고 호출”하고 MCP는 “동적으로 알아내 호출”하므로 둘은 공존합니다.
  • @thesnehamk — 그 문장이 잘 전달돼서 기쁩니다. 5만 토큰과 81% 수치는 큰 MCP 서버를 연결하기 전에 모든 팀이 봐야 할 통계입니다. 요즘 효과를 보는 방식은 점진적·지연형 도구 공개입니다. 먼저 작은 “도구 검색”이나 “기능 목록” 기능만 노출하고 현재 작업에 필요한 스키마만 불러옵니다. 매번 전체 목록을 컨텍스트에 넣는 대신 낭비되는 공간을 줄이는 방법이며, 아직 보편적이지는 않아도 몇몇 구현이 이 방향으로 가고 있습니다. “호출자가 다르면 계약도 다르다”는 표현도 좋습니다. GraphQL이 REST를 대체하느냐고 묻지 않는 것과 같은 맥락입니다.
• @polterguy — 왜 하나를 골라야 하나요?
  • @thesnehamk — 실제 시스템에서는 서로 배타적이지 않습니다. 기존 API를 실행 계층으로 유지하고, LLM이 필요한 일부 엔드포인트만 얇은 MCP 래퍼로 노출하면 됩니다. API의 버전 관리와 인증, 속도 제한을 유지하면서 MCP의 동적 검색 기능을 더할 수 있습니다. 다만 REST API처럼 모든 기능을 MCP에 노출하면 토큰 비용이 커집니다. 보통은 넓은 기능 범위는 API로 두고 모델에는 MCP로 선별한 좁은 범위를 제공합니다.
  • @polterguy — 도구가 너무 많으면 컨텍스트를 낭비합니다. Magic에서는 원하는 도구만 노출할 수 있고, 도구 하나로 다른 도구를 만드는 방식도 제공합니다. API 메서드 하나로 사실상 무한한 도구를 가진 에이전트를 만들 수 있습니다. Claude에서 Magic을 통해 API를 만들면 각 API 메서드가 잠재적 도구가 되어 MCP 서버에 1초 뒤 보입니다. 공개 API에서 Chuck Norris 농담을 반환하는 Hyperlambda HTTP 메서드를 만들면 1~3초 안에 API와 MCP 도구가 모두 생깁니다.
  • @thesnehamk — API와 MCP를 고르는 대신 작성 단계에서부터 엔드포인트를 둘 다로 만드는 흥미로운 설계입니다. 원하는 도구만 노출하는 방식은 글에서 지적한 컨텍스트 낭비를 직접 다룹니다. 다만 도구를 만드는 도구를 쓰면 위험의 위치가 달라집니다. 개별 도구 N개를 검토하는 대신, 메타 도구가 실행될 때마다 어떤 기능을 만들고 공개할지 맡기게 됩니다. Chuck Norris 농담 도구는 재미있는 예지만, 내부 시스템에 HTTP 메서드를 만들 수 있다면 에이전트가 호출하기 전에 누가 생성 결과를 확인하는지가 궁금합니다. 여러 팀이 쓰는 환경에서 메서드를 생성한 뒤 실제 공개하기 전에 검토·승인하는 절차가 있나요, 아니면 샌드박스가 실행 시점에 모든 것을 통제하나요?
  • @polterguy — “기능을 만들고 공개하는 메타 도구를 신뢰해야 한다”는 말이 나왔는데, 제 작업을 실제로 읽어야 합니다. 신뢰는 전혀 관련이 없습니다. 개별 함수를 화이트리스트로 관리하고, 허용된 함수 목록을 통합 RBAC 시스템에 연결합니다. CEO는 모든 데이터베이스를 읽고, CTO는 모든 데이터베이스에 전체 CRUD를 수행하며, CMO는 마케팅 데이터베이스에서 삭제를 제외한 읽기·쓰기·수정을 할 수 있습니다. CMO가 Claude에서 MCP를 통해 새 고객을 만들라고 요청하면 Magic이 생성 코드 실행 중 권한과 기능, 제약을 적용합니다. 악의적이거나 위험한 요청은 함수 호출 단계에서 막히며, “이 기능은 컨텍스트에 존재하지 않습니다”라는 응답이 나옵니다. 해당 함수가 언어 안에 실제로 있어도 마찬가지입니다. 생성기는 역할에 따라 실행이 허용되지 않은 함수를 이론상으로도 만들어낼 수 없습니다.
  • @thesnehamk — 뒤에서 생성되는 불투명한 허용 목록이 아니라, 사람이 역할을 고르고 데이터베이스·HTTP·파일·이메일 같은 기능을 체크하는 편집기라는 설명입니다. 데이터베이스 접근은 어떤 데이터베이스인지, 읽기·생성·수정·삭제·원시 SQL 중 무엇을 허용할지 더 세밀하게 고릅니다. 화면 아래 생성되는 data.connect:crm, data.read, data.create 같은 항목은 체크박스 설정을 그대로 드러냅니다. 역할별 제한과 시간 창, 타임아웃 설정으로 권한 검사와 같은 계층에서 호출을 제한하는 점도 확인했습니다. 그러면 편집기에 누가 접근할 수 있고 변경 기록이 남는지가 실제 조직에서 중요한 질문입니다. 권한을 편집하는 도구의 접근 관리가 보안 경계가 되기 때문입니다. 스크린샷 덕분에 기능 범위 제한이 구체적으로 보였고, “허용되지 않은 함수는 환각하지 않는다”는 주장이 어떻게 성립하는지도 더 명확해졌습니다.
  • @polterguy — 감사합니다. MIT 라이선스 오픈 소스이며 Docker로 5분이면 설치합니다. hyperlambda.dev와 github.com/polterguy/magic을 보세요. 주인에게도 알려주시겠어요?
  • @thesnehamk — MIT 라이선스에 Docker로 5분 설치라면 직접 살펴보기 좋은 조건입니다. 저장소를 확인해보겠습니다. Anthropic PM에게 홍보를 전달하진 않겠지만, 이 대화에서 나온 기술 내용은 그대로 전하겠습니다.
• @doushabao — 좋은 비교입니다. MCP와 API는 서로 대체하기보다 용도가 다르다고 생각합니다. API는 외부 서비스와 구조화된 데이터 접근에 여전히 필요하고, MCP는 내부 도구 오케스트레이션에 잘 맞습니다. 외부 연동에는 API를, 내부 도구에는 MCP와 비슷한 프로토콜을 쓰는 조합이 좋습니다. 문제에 맞는 추상화 계층을 고르는 것이 관건입니다.
• @howardzlh — MCP도 좋고 API도 좋습니다. 둘 다 원합니다.

원문: dev.to / 번역·요약: Trawling