MCP는 모델의 기능이 아닙니다. 당신의 도구를 위한 전원 콘센트입니다.

테크 리드(Tech lead)가 Slack으로 당신에게 메시지를 보냅니다: "우리 Claude 연동 방식을 MCP로 옮겨야 해요."

당신은 현재 어떤 상태인지 묻습니다. 지난 8개월 동안 프로덕션(Production)에서 실행되어 온, 함수 호출 (Function calling)을 통해 연결된 4개의 커스텀 도구(Custom tools)가 있습니다. 당신은 무엇이 문제인지 묻습니다.

"아무 문제 없어요. 하지만 이제 MCP가 표준(Standard)이니까요."

Agent SDK와 똑같은 함정입니다. "표준이다"라는 문구는 이 자리에 있는 그 누구도 MCP가 무엇을 해결하기 위한 것인지 명확히 설명하지 못했다는 사실을 숨기고 있습니다. 그리고 무엇을 해결하려는지 모른다면, 아무런 이득 없이 마이그레이션(Migration)을 하게 됩니다.

MCP는 함수 호출 (Function calling)을 대체하는 것이 아닙니다. MCP는 도구가 어떻게 '호출'되는지가 아니라, 도구가 어떻게 '노출(Exposed)'되는지를 표준화합니다.

실제로 작동하는 비유

MCP는 새로운 모델이 아닙니다. 오케스트레이션 프레임워크 (Orchestration framework)도 아닙니다. 함수 호출 (Function calling) 2.0도 아닙니다.

MCP는 당신의 도구를 위한 표준화된 전원 콘센트입니다.

콘센트는 장치가 하나뿐이고 벽이 하나뿐이라면 무용지물입니다. 하지만 동일한 전력이 필요한 여러 장치가 생기는 순간 가치를 발휘합니다.

MCP도 마찬가지입니다. 하나의 Claude 앱이 두 개의 커스텀 도구를 호출하나요? 그들 사이에 표준 계약(Standard contract)은 필요하지 않습니다. 필요한 것은 함수(Function)와 반환 값(Return value)뿐입니다.

세 개의 팀이 세 개의 서로 다른 클라이언트(Client)를 통해 동일한 데이터 소스에 접속하고 싶어 하는 날, 당신은 자신만의 프로토콜(Protocol)을 발명하거나 Anthropic이 내놓은 프로토콜을 채택해야만 합니다.

열풍 뒤에 숨겨진 수학

MCP 이전에는 통합(Integration) 규모가 N×M으로 늘어났습니다. N개의 클라이언트와 M개의 도구가 있다면, 모든 쌍마다 개별적인 연결 작업이 필요했습니다. 클라이언트 5개, 도구 10개라면 유지보수해야 할 통합 작업은 50개가 됩니다.

MCP를 사용하면 이는 M+N이 됩니다. 각 도구는 하나의 MCP 서버(Server)를 노출합니다. 각 클라이언트는 MCP를 한 번만 사용하면 됩니다. 끝입니다.

이 수학적 계산이야말로 MCP를 채택해야 하는 유일하고 정직한 이유입니다. 그 외의 모든 것("현대적이다", "대형 기술 기업($BIG_TECH)이 사용한다")은 소음일 뿐입니다.

MCP가 제 역할을 하는 순간

세 가지 구체적인 시나리오입니다.

하나의 도구, 여러 개의 LLM 클라이언트. Claude Desktop을 사용하는 PM들. Claude Code를 사용하는 개발자들. 당신이 API로 구축한 내부 앱을 사용하는 지원 팀. 이 세 그룹 모두 동일한 제품 데이터베이스에 접근해야 합니다. MCP가 없다면, 당신은 세 개의 커넥터(Connector)를 유지하며 그들의 스키마(Schema)를 영원히 동기화해야 합니다. MCP가 있다면, 당신은 단 하나의 서버(Server)만 작성하면 됩니다.

생태계 활용하기. GitHub, Notion, Slack, Postgres, Linear, Stripe를 위한 서버는 이미 존재합니다. 설치하고, 자격 증명(Credentials)을 설정하고, 연결하기만 하면 됩니다. 주말 동안 직접 코딩하는 것은 괜찮습니다. 하지만 업스트림 API(Upstream APIs)가 진화함에 따라 이를 유지 관리하는 것은 팀원 중 누구도 원치 않는 부업이 될 것입니다.

도구 팀과 앱 팀의 디커플링 (Decoupling). 구조화된 조직에서는 CRM 팀이 CRM을 담당하고, LLM 앱 팀이 어시스턴트를 담당합니다. 가공되지 않은 함수 호출 (Raw function calling) 방식은 앱 팀이 CRM 스키마(Schema), 인증(Auth), 속도 제한(Rate limiting), 에러 처리(Error handling)까지 모두 책임지게 만듭니다. MCP를 사용하면 CRM 팀이 서버를 배포합니다. 명확한 계약(Contract)이 성립되며, 팀 간의 불필요한 소통이 줄어듭니다.

MCP가 순수하게 오버헤드(Overhead)가 되는 경우

MCP는 공짜가 아닙니다. 전송 단계(Transport hop)가 추가되고, 배포해야 할 서버가 생기며, 따라야 할 사양(Spec)이 생깁니다. 계산이 맞지 않는 세 가지 사례는 다음과 같습니다:

• 하나의 앱, 두 개의 자체 제작 도구. 동일한 리포지토리(Repo)를 공유하는 코드 사이에 MCP를 추가하는 것은, 이식성 이득은 전혀 없이 디버깅해야 할 네트워크 호출만 늘리는 꼴입니다.
• 재사용 경로가 없는 초특화 도구. 아무도 당신의 방식대로 사용하지 않는 레거시 ERP와의 일회성 통합 같은 경우입니다. 이럴 때는 표준화의 논거가 사라집니다.
• 초저지연 (Ultra-low-latency) 루프. 음성 에이전트, 트레이딩, 실시간 제어 등이 해당됩니다. 대부분의 워크로드에서 전송 단계는 보이지 않지만, 이러한 작업에서는 p99 지표에 영향을 미칩니다.

양측 모두가 빠지는 전형적인 함정

Agent SDK에서 나타났던 것과 동일한 안티 패턴(Anti-pattern)이 거울처럼 반대편에서 나타납니다.

한쪽: "이것이 표준이다"라는 이유로 모든 것을 MCP로 마이그레이션합니다. 단일 앱 팀이 갑자기 서버 플릿(Fleet), 배포 파이프라인, 온콜(On-call) 순번을 갖게 되며, 이 모든 과정은 이미 잘 작동하던 도구들을 다시 작성하기 위해 수행됩니다. 사용자에게 보이는 변화는 전혀 없이 몇 달간의 노력만 낭비하게 됩니다.

다른 쪽: MCP를 거부하고 자체 프로토콜을 만듭니다. 6개월 후, 당신은 사양(Spec)도, 커뮤니티도, 미리 만들어진 서버도 없는 MCP를 재발명하게 됩니다. 당신이 새로 만든 Claude Code 라이선스는 당신이 구축한 그 어떤 것과도 통신할 수 없습니다.

표준이란 여러 소비자가 존재할 것을 예상할 때 선택하는 기본값(Default)입니다. 종교가 아닙니다.

마이그레이션 전 세 가지 질문

마이그레이션 전 세 가지 질문

1. 향후 12개월 이내에 나의 도구(tools)나 데이터 소스(data sources)가 하나 이상의 LLM 클라이언트(Claude Desktop, Claude Code, 내부 앱, IDE 등)에 의해 소비될 예정인가?
2. 내가 연결하고자 하는 기능에 대해 이미 공식적이거나 커뮤니티에서 만든 MCP 서버가 존재하는가?
3. 도구를 만드는 팀과 LLM 앱을 만드는 팀을 **분리(decouple)**해야 하는가?

두 가지 질문에 '예'라고 답한다면, MCP를 도입할 가치가 있습니다. 그렇지 않다면 가공되지 않은 함수 호출 (raw function calling) 방식이 승리합니다. 인프라가 적고, 노출 면적(surface area)이 적으며, 디버깅할 것도 적기 때문입니다.

상세 분석

이것은 요약 버전입니다. 긴 버전의 포스트에서는 MCP와 에이전트 SDK (Agent SDK)의 차이점(이들은 서로 다른 계층에 위치하며, 대부분의 팀이 이를 혼동합니다), 중소기업(SMB) 규모에서의 의사결정 로직, 그리고 잘못된 선택을 했을 때의 비용에 대해 깊이 있게 다룹니다.

→ MCP Explained: Model Context Protocol for Tech Leaders

저는 Claude 스택을 전문적으로 다루는 데이터 및 AI 컨설턴트 Valentin입니다. 만약 여러분이 "마이그레이션을 해야 하는가"와 "실제로 무엇을 얻을 수 있는가" 사이에서 고민 중이라면, 긴 버전의 글이 여러분의 탐색 콜 (discovery call) 시간을 아껴줄 것입니다.