대부분의 MCP 서버는 에이전트 아키텍처가 아니라 시기상조의 제품 인터페이스다. 이 글은 MCP 서버가 정말 필요한지 판단하는 프레임워크와, 필요하다면 무엇을 고려해야 하는지 설명한다.
대부분의 MCP 서버는 에이전트 아키텍처가 아니라 시기상조의 제품 인터페이스입니다. 첫 번째 과열된 유행의 물결은 너무 많은 반쯤 완성된 구현을 만들어냈는데, 많은 제품이 애초에 MCP 서버를 필요로 하지 않기 때문입니다. 대신 어떤 경우에는 직접 API 호출이면 충분합니다. 어떤 경우에는 CLI가 일을 해냅니다. 또 다른 경우에는 스킬이 저렴한 실험이 됩니다. 이 글은 MCP가 정말 그만한 가치가 있는지 판단하기 위한 프레임워크를 제시하고, 그렇다면 무엇을 염두에 두어야 하는지도 설명합니다.
시작하자마자 이것부터 생각해 보세요: Bloomberry의 1,412개 MCP 서버 분석에 따르면, 이를 배포한 회사들 중 대략 절반은 공개용 API가 아예 없습니다. API 없이 MCP를 배포한다는 것은 외부 소비자를 위한 안정적이고 의도 수준의 작업을 아직 정의하지 않았다는 뜻입니다.
요약판은 여기 체크리스트를 보세요.
기억할 만한 축약형: API는 소프트웨어 계약입니다. CLI는 실행 계약입니다. MCP는 에이전트 접근 계약입니다. 스킬은 에이전트가 이들 중 어떤 것이든 잘 사용하도록 가르치는 방법입니다. 따라서 MCP 서버는 제품의 세 번째 인터페이스입니다. 일관된 첫 번째와 두 번째가 없으면, 세 번째는 설 자리가 없습니다.
성공적으로 MCP 서버를 배포하는 팀은 그것을 제품의 다른 모든 구성요소처럼 다룹니다. 범위를 좁게 유지하고, 분명한 관점을 담고, 계속 동작하도록 필요한 일을 합니다. 이 팀들은 충분히 많은 사람들이, 충분히 다양한 곳에서, 실제로 그것을 필요로 할 때 구축할 가치가 있다고 판단합니다.
이 글의 나머지 부분은 그것이 바로 당신의 경우인지, 아니면 다른 방향이 더 나은지 파악하는 방법입니다.
팀이 제품을 에이전트 대응 가능하게 만드는 방법을 생각할 때, 보통 CLI 문제가 등장합니다. “CLI를 배포해야 할까요?” 잘못된 질문입니다. 코딩 에이전트는 이미 하나를 갖고 있습니다. 대신 이렇게 물어야 합니다. “우리가 이미 배포하고 있는 CLI가 에이전트가 구동할 만큼 충분히 규율 잡혀 있는가?”
여기서 “규율 잡혀 있다”는 뜻은 제품 의도에 맞춰진 안정적이고 비대화형인 명령, 구조화된 출력, 그리고 인간만을 위한 패턴이 없다는 것을 말합니다. 예를 들어 stdout에 진행 막대를 섞는 것 같은 방식 말입니다. 이런 특성은 인간, CI, 에이전트 모두에게 동시에 도움이 됩니다.
팀이 제품을 에이전트 대응 가능하게 만들고 싶을 때, 다음 본능은 “우리는 이미 API가 있는데, 에이전트를 거기에 연결할 수 있을까?”입니다.
이것도 잘못된 질문입니다. 하지만 당신이 짐작할 이유 때문은 아닙니다! 문제는 너무 많은 클라이언트가 너무 많은 도구에 연결된 것이 아닙니다. 당신의 API는 누군가가 무엇을 하려는지 가 아니라 데이터가 어떻게 저장되는지 를 중심으로 형태가 잡혀 있습니다.
내부 API는 장부 정리로 가득합니다: ID, 페이지네이션 커서, 상태 플래그, 라이프사이클 상태, 중첩된 객체를 설명하는 중첩 객체. 이런 형태가 존재하는 이유는 데이터베이스가 그것을 필요로 하기 때문입니다. 이것을 에이전트에게 건네면, 모델은 유용한 일을 하기 전에 제한된 주의력을 당신의 데이터 모델을 이해하는 데 소모해 버립니다.
그러므로 당신은 기능을 노출하는 것이 아닙니다. 사실상 더 그럴듯한 이름을 붙인 데이터베이스를 노출하고 있을 뿐입니다.
MCP로 전환한다고 해서 근본적인 API 문제가 해결되지는 않습니다. 도구가 여전히 데이터베이스 행처럼 생겼다면, MCP는 같은 문제를 새 프로토콜로 감쌀 뿐입니다. 대신 해결은 한 단계 앞에서 이루어져야 합니다: 사람들이 무엇을 하려는지에 맞춰 작업을 설계한 다음, 그 후에 MCP가 올바른 선택인지 결정하세요.
MCP는 접근 을 다룹니다. 스킬은 운용 규율 을 다룹니다. 즉, 지침, 예시, 참고 파일, 템플릿, 또는 때로는 에이전트가 다른 곳에서 노출된 기능을 사용하는 방법을 가르치는 보조 스크립트를 뜻합니다. 다음과 같은 경우에는 MCP 이전에 스킬을 선택하세요:
스킬은 에이전트에게 API, CLI, 로컬 파일, 또는 MCP 서버를 사용하는 방법을 가르칠 수 있고, 결정적인 보조 작업을 위한 스크립트를 포함할 수도 있습니다. 하지만 테넌트 범위, 원격 접근, 권한 부여, 감사, 또는 프로세스 간 거버넌스를 제공하지는 않습니다. 이런 기본 요소가 제품 인터페이스에 속한다면, 스킬만으로는 부족하고 외부 경계가 필요합니다. 예를 들어 MCP 같은 것입니다.
이 글의 나머지 부분에서 그 경계가 어떤 모습인지 살펴보겠습니다.
MCP 서버를 만들지 결정할 때 찾아야 할 가장 큰 신호는 하나입니다: 당신이 통제하지 않는 AI 클라이언트들이 동일한 작업을 소비한다는 것입니다.
예를 들어, 사용자가 Claude, Cursor, ChatGPT, Copilot, 고객이 만든 에이전트 같은 클라이언트에 있고, 그곳에서 당신의 제품을 사용 가능하게 하기를 원한다고 해봅시다.
이것이 사실이 아니라면, MCP는 대체로 함수 호출이 이미 제공하는 것 위에 얹힌 추가 프로토콜일 뿐입니다. 단일 앱 내 에이전트가 단일 백엔드에 접근하는 경우라면 OpenAI Responses API나 Anthropic tools API를 사용해 동일한 작업을 호출할 수 있고, 절차도 더 단순합니다.
클라이언트 간 수요가 있다면, 하나의 관리된 계약을 운영하는 비용이 제각각 표류하는 N개의 클라이언트별 통합보다 나을 수 있습니다. 이것이 Linear, Sentry, Resend, Cloudflare, Stripe가 공식 MCP 표면을 배포한 이유입니다. 어떤 것은 원격이며 중앙 호스팅이고, 다른 것은 로컬 또는 자체 운영 서버로 배포되지만, 모두 제품 기능을 AI 클라이언트에 제공하도록 설계되었습니다.
아래 항목 각각은 함수 호출로 애플리케이션 계층에서 해결할 수 있습니다. 어느 것도 단독으로 MCP를 정당화하지는 않습니다. 하지만 위의 핵심 신호가 실제라고 판명되면, 즉 클라이언트 간 수요가 있다면, 다음 요소들이 필요성을 더 분명하게 만들고 서버에 무엇이 들어가야 하는지 형태를 잡아 줍니다.
당신의 서비스가 에이전트와 다른 프로세스에서 실행됩니다: 제삼자 SaaS, 다른 팀의 서비스, 에이전트가 네트워크를 통해 접근하는 원격 시스템 같은 경우입니다. AI 클라이언트 소비자에게 MCP는 점점 더 네이티브 커넥터, 함수 호출, IDE별 확장과 함께 공통 프로토콜이 되고 있습니다.
원시 데이터나 저수준 호출을 의도 수준의 작업으로 바꾸는 결정적 처리: 집계, 필터링, 정규화, 조합입니다. 다섯 번의 CI 호출과 수동 결합 대신 find_flaky_tests. 사용자, 워크스페이스, 청구 상태, 사고를 모델이 스스로 조인하게 하는 대신 get_customer_context. 이는 어느 계층에서든 좋은 도구 설계이며, MCP는 그 계층이 클라이언트 간일 때 그것을 배포하는 위치일 뿐입니다.
문맥에 담기지 않을 만큼 큰 코드베이스, 문서 집합, 또는 데이터셋. 에이전트는 모든 것을 한꺼번에 건네받는 대신 검색하고, 가져오고, 필터링합니다. 이런 가져오기 패턴 자체는 함수 호출에도 일반적이며, MCP는 동일한 가져오기 표면을 여러 클라이언트에서 발견 가능하게 만듭니다.
거버넌스가 필요한 쓰기 가능 자동화. 에이전트가 상태를 바꿀 수 있게 되면, 그 작업에는 범위, 승인, 감사가 필요합니다. 강제 집행은 여전히 백엔드의 책임입니다. MCP는 elicitation을 지원하는 클라이언트를 통해 사용자 입력이나 확인을 드러내는 데 도움을 줄 수 있지만, 지원은 고르지 않으므로 가장 약한 대상 클라이언트에 맞춰 이런 흐름을 설계해야 합니다.
문맥 수집은 MCP에 속합니다. 사용자 목표를 결정하는 일은 그렇지 않습니다. 롤백 미리보기를 준비하는 일은 MCP에 속합니다. 그 롤백이 올바른 비즈니스 판단인지 선택하는 일은 그렇지 않습니다.
서버 안에 무엇이 속하는지 명확히 설명할 수 없다면, 아직 서버를 만들 준비가 되지 않은 것입니다. 규칙은 짧습니다: 워크플로가 아니라 작업을 캡슐화하세요.
이 규칙에는 잘 보여주는 예시 하나와 알아둘 가치가 있는 예외 하나가 있습니다.
성공 사례: Sentry의 API는 이슈, 이벤트, 릴리스, 성능 데이터, 알림, 청구, 조직 관리를 아우릅니다. 그 MCP는 약 열두 개의 도구를 노출하는데, 모두 하나의 워크플로를 중심으로 합니다: 프로덕션 이슈를 디버깅하는 코딩 에이전트입니다. 관리 기능, 팀 관리, 청구는 API에 남겨 둡니다. 이 서버는 하나의 워크플로를 잘 해결함으로써 월 5천만 건이 넘는 요청 규모로 확장됐습니다. 이는 가장 많은 엔드포인트를 감싼 결과가 아니라, 제약을 보존하는 최소한의 작업을 선택한 결과입니다.
예외는 의도 수준 도구로는 다 담을 수 없을 만큼 큰 표면입니다. 어떤 제품은 소수의 의도 수준 도구로 환원될 수 없습니다. 예를 들어 Cloudflare의 API는 약 2,500개의 엔드포인트에 걸쳐 있습니다. 엔드포인트마다 하나의 도구를 두면 첫 메시지 전에 스키마만으로 백만 개가 넘는 토큰을 태우게 됩니다. 그들의 MCP는 대신 두 개의 도구(search와 execute)만 배포하고, 에이전트가 샌드박스 안에서 타입이 있는 명세를 바탕으로 코드를 작성하게 합니다. 이것이 codemode 패턴이며, 표면 크기와 무관하게 약 1,000 토큰 정도입니다. 이는 프로그래밍 가능한 플랫폼과 코드를 잘 쓰는 모델을 전제하므로 모두에게 맞는 방식은 아니지만, 수천 개 엔드포인트 규모의 표면에서는 땅을 다 덮지 못하는 의도 도구를 억지로 큐레이션하는 것보다 낫습니다.
MCP는 당신의 백엔드, 평가, 관측성, 권한 설계를 대체하지 않습니다. 에이전트는 여전히 다음에 무엇을 할지 결정합니다. 복잡성을 숨기되, 책임을 숨기지는 마세요.
문맥 예산. Anthropic은 다섯 개 서버와 58개 도구로 이루어진 구성에서 첫 메시지 전에 대략 55K 토큰이 소비되었고, 최적화 전 내부 사례에서는 첫 메시지 전에 134K 토큰에 이르렀다고 보고했습니다. 도구 카탈로그는 프롬프트의 일부입니다. 이름, 설명, 스키마 필드 하나하나가 문맥을 먹습니다. Tool Search와 지연 로딩은 호스트나 모델 플랫폼이 이를 지원하는 경우 완화책이 될 수 있지만, 상류의 나쁜 도구 설계를 고치지는 못합니다. MCP 서버 설계는 곧 프롬프트 설계입니다. 나쁜 인터페이스 설계는 지연 시간, 비용, 그리고 낮은 도구 선택 정확도로 이어집니다.
운영 비용. MCP 서버는 당신이 운영해야 하는 소프트웨어입니다: 배포, 가동 시간, 버전 관리, 하위 호환성, 관측성, 사고 대응. Portkey 같은 MCP 게이트웨이 제품이 존재한다는 사실 자체가, 즉 클라이언트와 서버 사이에서 인증, 접근 제어, 감사, 속도 제한을 제공하는 제품이 존재한다는 사실 자체가, 프로토콜 자체에는 포함되지 않은 거버넌스 인프라가 프로덕션 MCP에 필요하다는 점을 시장이 아키텍처와 똑같이 말해 주고 있다는 뜻입니다.
보안 부채. Astrix의 5,205개 MCP 저장소 감사에 따르면 88%가 자격 증명을 요구하고, 53%는 정적 API 키 또는 PAT에 의존하며, OAuth를 구현한 곳은 8.5%뿐입니다. 위협은 그저 일반적인 API 위생 문제만은 아닙니다. MCP는 API 보안과 에이전트 특유의 위험을 결합합니다: 공유 레지스트리에서의 도구 오염, 도구 출력으로 인한 프롬프트 인젝션, 테넌트 간 혼동된 대리인 문제, npm 또는 pip를 통해 배포되는 stdio 서버의 공급망 위험. MCP를 “그냥 또 하나의 어댑터”로 취급하는 태도가 깔끔한 경계를 사고로 바꾸는 원인입니다.
승인 세탁. 이름 붙일 가치가 있는 실패 유형이 하나 있습니다. 무해한 미리보기 뒤에 사용자가 이미 고개를 끄덕였다는 이유로 파괴적인 호출이 이어지는 경우입니다. 파괴적인 단계가 자체적인 동의를 요구하도록 설계하는 일은, 즉 미리보기의 동의를 상속하지 않도록 하는 일은 클라이언트에만 맡길 수 없습니다. 서버가 그 경계를 강제해야 합니다. Resend의 MCP가 가지는 넓은 범위, 즉 이메일 전송, 연락처 관리, 도메인 검증, 수신 메일 읽기 같은 기능이 바로 왜 범위, 승인, 감사 로그, 철회 기능이 선택 사항이 될 수 없는지를 보여 줍니다. 에이전트가 고객 대상 커뮤니케이션 인프라를 바꿀 수 있게 되는 순간, 기준은 높아지고 계속 높게 유지되어야 합니다.
클라이언트 파편화. “하나의 서버, 많은 클라이언트”는 프로덕션에서 팀들을 놀라게 하는 단서 하나를 달고서만 참입니다. MCP 명세에는 도구, 리소스, 프롬프트가 포함되지만, 클라이언트는 서로 다른 부분집합을 구현합니다. GitHub Copilot의 cloud agent는 현재 MCP 도구는 노출하지만 리소스나 프롬프트는 노출하지 않고, 아직 원격 서버용 OAuth 흐름을 받지 않으며, 매 호출 전에 승인을 요청하지 않고 사용 가능한 도구를 자율적으로 사용합니다. Cursor는 도구, 프롬프트, 리소스, 루트, elicitation, 앱을 지원합니다. Gemini CLI는 프롬프트를 슬래시 명령처럼 다룹니다. 프로토콜은 하나입니다. 클라이언트는 그렇지 않습니다. 가장 약한 대상을 기준으로 설계하세요. 그렇지 않으면 서버는 사용자 절반에게 프로덕션에서 동작을 멈춥니다.
아래 질문들은 빠른 평가를 위해 예 또는 아니오로 걸러집니다.
1번이나 2번에 예라고 답하면 더 작은 경계로 돌아가야 합니다. 3번에서는 빠진 조각이 사용 규율이라면 스킬로 시작하세요. 기능이나 접근이라면 계속 진행하세요. 4번에 아니오라면 너무 이릅니다. 5–8 중 어느 하나라도 아니오라면 아직 아닙니다.
서버를 망가뜨리는 흔한 MCP 실패는 무엇을 봐야 하는지 모르면 놓치기 쉽습니다.
notification-send-user와 notification-send-channel 같은 이름은 더 이상 구분에 도움이 되지 않고, 모델은 잘못 선택합니다.getUser, updateUser, deleteUser 같은 것들입니다. 이름만 봐도 알 수 있습니다.이 모든 것은 같은 결말로 이어집니다: 도구는 너무 많고, 사용량은 적고, 통합 부담은 사라지지 않은 채 API에서 MCP로 옮겨졌을 뿐입니다.
시스템이 당신의 제품 도메인이 아니라면 공식 서버를 기본 선택으로 삼으세요.
Stripe 위에 얇은 래퍼를 두는 것은 인프라입니다. Stripe, 제품 사용량, 지원 티켓, 사고, 계약 조건을 결합하는 get_customer_risk_context 도구는 제품 표면입니다.
성숙한 통합은 결국 하나 이상의 계층을 배포합니다: 기반으로서의 API, 로컬 환경을 위한 CLI, 사용 규율을 위한 스킬, 그리고 클라이언트 간 에이전트 접근을 위한 MCP 서버입니다. 이들 중 MCP는 운영 비용이 가장 크므로, 아키텍처 신호, 프로덕션 시나리오, 비용이 모두 테이블 위에 올라와 있고, 그럼에도 답이 여전히 예 일 때 구축하세요.