MCP 서버는 요즘 개발 생태계에서 가장 뜨거운 유행어입니다. 그런데 최근 조사에 따르면, MCP 서버를 배포한 기업의 절반은 애초에 공개 API조차 갖고 있지 않았습니다.
개발자 컨설팅 그룹 Evil Martians가 지난 6월 30일, MCP 서버를 언제 만들어야 하는지 판단하는 프레임워크를 블로그에 공개했습니다. 핵심 주장은 하나입니다. API는 소프트웨어 계약이고, CLI는 실행 계약이고, MCP는 에이전트 접근 계약인데, 이 구분 없이 유행을 따라 MCP부터 만들다 보니 부실한 서버가 쏟아지고 있다는 것입니다.
출처: Most MCP servers don’t need to exist. Your case might be an exception. – Evil Martians
API도, CLI도 있는데 왜 또 MCP인가
많은 팀이 “이미 API가 있으니 에이전트를 거기 연결하면 되지 않나” 하고 생각합니다. 문제는 그 API가 애초에 데이터베이스를 다루기 위해 설계됐다는 데 있습니다. ID, 페이지네이션 커서, 상태 플래그처럼 시스템 내부 사정을 담은 값들이 뒤엉켜 있어서, 에이전트는 뭘 하기도 전에 이 구조부터 해석하느라 힘을 씁니다. 예를 들어 “이 주문을 환불한다”처럼 사람이 바로 이해할 수 있는 하나의 동작이 아니라, 주문 테이블과 결제 테이블을 각각 조회하고 상태값을 직접 조합해야 겨우 환불이 되는 식입니다. 원문은 이런 API를 두고 “능력을 노출하는 게 아니라, 이름만 그럴듯하게 붙인 데이터베이스를 노출하는 것”이라고 표현합니다.
MCP로 옮긴다고 이 문제가 사라지지도 않습니다. 도구가 여전히 데이터베이스 행(row) 모양이면, MCP는 같은 문제를 새 프로토콜로 포장할 뿐입니다. 그래서 원문은 순서를 뒤집어야 한다고 말합니다. 먼저 사람이 하려는 일 중심으로 오퍼레이션을 설계하고, 그다음에야 MCP가 필요한지 판단하라는 것이죠. 그리고 이 단계에서 종종 놓치는 선택지가 하나 더 있습니다. 바로 스킬입니다. 에이전트가 API나 CLI를 이미 쓸 줄 알지만 순서를 틀리거나 예외 상황을 놓친다면, 서버를 새로 짓는 대신 사용법 자체를 문서와 예시로 가르치는 스킬만으로 해결되는 경우가 많습니다.
MCP를 정당화하는 단 하나의 신호
원문이 꼽는 결정적 신호는 하나뿐입니다. 내가 통제하지 않는 여러 AI 클라이언트가 같은 기능을 써야 하는 상황입니다. Claude, Cursor, ChatGPT, Copilot처럼 서로 다른 곳에 사용자가 흩어져 있고, 이들 모두가 같은 제품 기능에 접근하려 할 때 MCP의 존재 이유가 생깁니다. 반대로 내가 만든 앱 안의 에이전트 하나가 내 백엔드 하나만 호출하는 구조라면, MCP는 함수 호출보다 절차만 더 많은 선택지일 뿐입니다. Sentry의 사례가 이 원칙을 잘 보여줍니다. Sentry의 API는 이슈, 이벤트, 결제, 조직 관리까지 광범위하지만, MCP 서버는 “에이전트가 프로덕션 장애를 디버깅한다”는 단 하나의 워크플로우에 맞춰 10여 개 도구만 노출합니다. 관리나 결제 기능은 API에 남겨둔 채로요. 월 5천만 건 이상의 요청을 처리하게 된 배경에는, 엔드포인트를 많이 감싸는 대신 하나의 워크플로우를 제대로 푼 선택이 있었습니다.
원문이 정리한 판단 흐름
원문은 이 판단을 여덟 개의 질문으로 좁혀 나가는데, 흐름을 요약하면 이렇습니다.
- 에이전트가 한 곳에서만, 내 통제 아래 쓰이는가 → 그렇다면 MCP 없이 직접 함수 호출로 충분합니다.
- 부족한 게 기능 자체인가, 사용법 숙련도인가 → 후자라면 서버 대신 스킬로 해결되는 경우가 많습니다.
- 3~5개의 안정적인 오퍼레이션을 이름 붙일 수 있는가 → 어렵다면 아직 준비가 안 된 상태입니다.
- 실제로 쓰일 클라이언트들이 필요한 기능(도구, 리소스, 프롬프트, 승인 흐름)을 지원하는가.
- 상태를 바꾸는 작업이라면, 승인과 감사 로그 체계가 프로토타입 단계부터 갖춰져 있는가.
- 버전이 바뀌어도 기존 클라이언트를 깨지 않고 배포할 수 있는가.
이 중 하나라도 답이 불확실하면, 아직은 이르다고 결론짓습니다.
해석
이 프레임워크가 흥미로운 지점은, MCP를 “만들지 말라”는 게 아니라 “만들 준비가 됐는지부터 확인하라”는 데 있습니다. 실제로 보안 감사 업체 Astrix가 5천 개가 넘는 MCP 저장소를 조사한 결과, 88퍼센트가 인증정보를 요구하는데 그중 절반 이상은 고정된 API 키에 의존하고 있었고, OAuth를 제대로 구현한 곳은 10퍼센트가 채 안 됐습니다. MCP가 API 보안 위에 프롬프트 주입이나 도구 오염 같은 에이전트 특유의 위험까지 더한 프로토콜이라는 점을 생각하면, 가볍게 만들고 방치할 수 있는 영역이 아니라는 걸 보여주는 수치입니다. 원문은 이 외에도 승인 절차를 우회당하는 실패 패턴이나, 클라이언트마다 지원하는 MCP 기능이 다르다는 점까지 구체적인 사례로 다루고 있습니다.
참고자료: We analyzed 1,412 MCP servers, here’s what we learned – Bloomberry
답글 남기기