MCP는 AI 플랫폼이다

AI를 프로덕션 환경에 배포하는 대부분의 팀은 여전히 2023년에 설계된 스택 위에서 구축하고 있습니다. 커스텀 채팅 UI (Custom chat UIs), 오케스트레이션 프레임워크 (Orchestration frameworks), RAG 파이프라인 (RAG pipelines), 벡터 데이터베이스 (Vector databases), 에이전트 관측성 레이어 (Agent observability layers), 그리고 이 모든 것을 계속 실행하기 위한 AI 플랫폼 팀까지 말이죠. Warmtebouw에서 우리는 이 모든 과정을 건너뛰고, ERP, BIM, 차량 관리 (fleet), 에너지, 운영 시스템 전반에 걸쳐 비기술적 비즈니스 사용자를 위한 9개의 MCP 서버를 3개월 만에 출시했습니다.

이것은 MCP가 당신의 AI 플랫폼의 일부가 아니라, MCP 자체가 당신의 AI 플랫폼이라는 사례를 보여줍니다. 그 위의 대부분의 레이어는 미드마켓 (mid-market) 규모에서 필요하지 않은 오버헤드 (overhead)일 뿐입니다.

모델이 에이전트다. 프레임워크는 오버헤드다.

"에이전트 프레임워크 (agent framework)가 필요하다"라는 프레임은 더 단순한 진실을 가립니다. 바로 모델이 곧 에이전트라는 사실입니다. 모델은 도구 설명을 읽습니다. 어떤 도구를 호출할지 선택합니다. 호출 순서를 정합니다. 결과를 해석합니다. 이것은 MCP를 지원하는 모든 프런티어 모델 (frontier model)에 내장된 교과서적인 에이전트적 동작 (agentic behaviour)입니다.

기업들이 그 위에 판매하는 것은 "에이전트를 둘러싼 프레임워크 (framework around the agent)"입니다. 즉, 오케스트레이션 로직 (orchestration logic), 검색 파이프라인 (retrieval pipelines), 프롬프트 관리자 (prompt managers), 관측성 레이어 (observability layers) 등입니다. 각 제품은 특정 맥락에서 실제 문제를 해결하고 있습니다. 하지만 파악 가능한 중요 데이터 소스 세트를 가진 중소기업의 경우, 그러한 맥락은 대부분 적용되지 않습니다.

내가 사용하는 것	내가 건너뛰는 것
프런티어 모델 (내 경우 Claude; 필요에 따라 교체 가능)	LangChain + LangGraph + LangSmith 스택
...

오른쪽의 각 행은 유료 제품 카테고리입니다. 왼쪽의 각 행은 모델, 프로토콜, 또는 한 번 수행하여 재사용할 수 있는 작업입니다.

실무에서 "MCP를 위해 구축한다"는 것은 어떤 모습인가

잘 설계된 MCP 서버는 모델에게 데이터의 의미를 "파악"하라고 요구하지 않습니다. 대신 도구 설명 자체에서 데이터의 의미가 무엇인지 모델에게 알려줍니다.

이러한 대조는 모든 수준에서 나타납니다. 나쁜 도구는 다음과 같이 말합니다: "ERP에서 데이터를 쿼리하세요." 좋은 도구는 다음과 같이 말합니다: "항상 summaryOnly=true로 시작하세요. 활성 프로젝트는 수천 개의 레코드를 축적합니다. 타입 코드(Type codes)가 어떤 필드가 채워질지를 결정합니다. 계획된 비용에는 get_budget을 사용하고, 실제 비용에는 이 도구를 사용하세요."

첫 번째 버전은 모델이 호출할 때마다 쿼리 전략 (query strategy)을 스스로 만들어내도록 강요합니다. 두 번째 버전은 호출할 때마다 모델에게 쿼리 전략을 직접 전달합니다. 실제 운영 환경에서 이 두 서버의 차이는 비즈니스 사용자가 실제로 그 결과를 사용하느냐 아니냐의 차이입니다.

이것이 바로 팀들이 프레임워크 (frameworks)를 찾을 때 건너뛰는 작업입니다. 복잡성은 대부분 스스로 초래한 것입니다. 도구가 무엇을 의미하는지 아무도 기록하지 않았기 때문에 발생합니다. 동일한 격차로 인해 운영 환경에서 분석된 MCP 도구 설명의 97%가 최소 하나 이상의 심각한 결함(critical smell)을 포함하고 있습니다.

하나의 서버가 여러 소스를 구성할 수 있습니다

가장 흔한 반론("하지만 여러 시스템의 데이터를 결합하려면 오케스트레이션 (orchestration)이 필요합니다")은 오케스트레이션이 별도의 프레임워크에 존재해야 한다고 가정합니다. 그렇지 않습니다.

제가 만든 MCP 서버 중 하나는 하나의 인터페이스 뒤에서 다섯 가지의 이기종 소스 (heterogeneous sources)를 결합합니다: 제3자 미터 데이터 애그리게이터 (meter-data aggregator), 공공 날씨 API, 정부 건물 등록부, 기업 ERP, 그리고 IoT 건물 자동화 플랫폼입니다. 에이전트의 댄스 (agent dance)도, 검색 파이프라인 (retrieval pipeline)도 필요 없습니다. 각 소스가 언제 적용되는지, 그리고 소스들이 어떻게 연관되어 있는지를 설명하는 설명을 포함한 타입 도구 (typed tools)만 있을 뿐입니다.

모델은 도구 설명이 관계를 알려주기 때문에 구성을 스스로 파악합니다. 이 패턴은 ERP, BIM, 차량 관리 (fleet), 계산, 건물 자동화, 에너지, 그리고 운영 로그를 다루는 9개의 운영 서버에서 작동합니다. 사실상 한 기업의 전체 운영 영역을 도구 설명을 통해 접근 가능하게 만들며, MCP를 지원하는 어떤 모델이든 소비할 수 있게 합니다.

도구는 그 아래의 모든 것을 추상화합니다

모델은 데이터가 어떻게 가져와지는지 결코 알지 못합니다. 하나의 MCP 서버 내부에서, 개별 도구(tools)는 하부 시스템이 사용하는 방식 그대로를 호출합니다: SaaS 제품을 위한 REST, 내부 API를 위한 GraphQL, 데이터 웨어하우스(data warehouse)에 대한 직접적인 SQL, 디스크 상의 JSON 파일, 레거시 시스템을 위한 SOAP 엔벨로프(envelopes) 등입니다. 도구는 타입이 지정된 레코드(typed records)를 반환하며, 프로토콜의 이질성(heterogeneity)은 도구 내부에 머뭅니다.

이것이 바로 데이터 패브릭(data-fabric) 및 iPaaS 산업에서 프리미엄 가격을 받고 구축하는 추상화 계층(abstraction layer)입니다. MCP 도구들은 이미 중앙 파이프라인 없이도, 데이터가 실제로 존재하는 어떤 언어로든, 한 번에 하나의 도구씩 이 역할을 수행하고 있습니다. 백엔드(backend)의 선택은 전파되지 않습니다. 하부 시스템에 적합한 것을 선택하기만 하면 모델 인터페이스는 동일하게 유지됩니다.

SQL조차도 다루기 쉬워집니다. LLM으로부터 직접적인 SQL을 실행하는 것은 모델이 파괴적인 쿼리(queries)를 수행하도록 속임을 당할 수 있기 때문에 위험합니다. 하지만 타입이 지정된 MCP 도구 내부의 SQL(서버가 스키마 검증된 파라미터로부터 SQL을 생성하고, 연결이 읽기 전용 역할(read-only role)로 실행되며, 기업의 IdP가 호출 권한을 제어하는 경우)은 그저 일반적인 함수 호출일 뿐입니다. 도구의 코드가 실행되기도 전에, 도구의 JSON 스키마(JSON schema)와 일치하지 않는 모든 값은 프로토콜 경계에서 거부됩니다.

이것은 이론적인 이야기가 아닙니다. 제가 운영하는 서버 중 하나는 계산 데이터를 다루는 쿼리 엔드포인트(query endpoint) 뒤에서 100% SQL로 작동합니다. 모든 도구는 타입이 지정된 에이전트 요청을 SQL 쿼리로 변환합니다. 모델이 스키마 검증된 파라미터를 전달하면, 서버가 쿼리를 구성하고 실행하며, 타입이 지정된 레코드가 반환됩니다. 모델은 SQL을 결코 보지 못합니다. 연결은 읽기 전용 역할로 실행되며, 액세스는 다른 모든 시스템을 관리하는 것과 동일한 IdP 역할에 의해 제어됩니다.

저는 이것을 하루 만에 구축했습니다. 하부 데이터를 소유한 계산 전문가가 이를 검증했으며, 이 서버는 이미 해당 팀이 필요로 하는 모든 데이터셋을 노출하고 있습니다. 일단 이 패턴을 내재화하고 나면, 이를 새로운 도메인에 적용하는 것은 분기 단위의 프로젝트가 아니라 단 하루의 작업이 됩니다.

왜 미드마켓(mid-market)이 최적의 지점인가

이러한 논리에는 한계가 있습니다. Fortune 500 규모(수백 개의 이기종 시스템, 멀티 테넌트 (multi-tenant) SaaS, 방대한 양의 비정형 문서)에서는 검색 파이프라인 (retrieval pipelines)과 오케스트레이션 (orchestration)이 필요할 수도 있습니다. 범위가 방대하기 때문에 복잡성 또한 실재하기 때문입니다.

하지만 중견 기업 (mid-sized businesses)은 Fortune 500 기업이 갖지 못한 것을 가지고 있습니다. 바로 파악 가능한 수준의 중요한 데이터 소스 집합입니다. 5개에서 20개 사이의 핵심 시스템, 그리고 데이터가 실제로 무엇을 의미하는지 오후 내내 함께 앉아 설명해 줄 수 있는 몇 명의 도메인 전문가 (domain experts)가 있습니다. 이것이 잘 구축된 MCP 서버를 위한 전제 조건의 전부입니다.

만약 귀사가 하나의 사무실 건물에 들어갈 규모이고 20개 미만의 중요한 시스템을 보유하고 있다면, 귀사가 바로 이 서비스의 대상입니다. 귀하는 AI 산업이 판매하려고 시도하는 대부분의 것들을 거의 확실히 필요로 하지 않을 것입니다.

"플랫폼"의 실제 정체

위의 표에서 무엇이 빠져 있는지 주목하십시오. 바로 플랫폼입니다. 스택 (stack) 내에 "AI 플랫폼"은 존재하지 않습니다. 오직 프론티어 모델 (frontier model), MCP 서버, 그리고 기업이 이미 비용을 지불하고 있는 기업용 ID 계층 (corporate identity layer)만이 있을 뿐입니다. 모델을 교체하더라도 (오늘은 Claude, 내일은 Gemini, 다음 분기에는 GPT), 나머지 스택은 동일하게 유지됩니다.

마지막 조각이 바로 9개의 MCP 서버를 기업이 실행할 수 있는 무언가로 바꾸어 놓는 요소입니다. AI 전용 ID 계층이 아닙니다. 기업이 이미 운영 중인 계층입니다. Microsoft 환경이라면 RBAC (역할 기반 액세스 제어)가 적용된 Entra ID일 것입니다. 다른 환경이라면 Okta, Google Cloud Identity, 또는 그 어떤 OAuth 2.1 제공자일 수도 있습니다. MCP 서버는 기존의 IdP (ID 제공자)를 통해 인증하고, 역할에 따라 도구 액세스 범위를 제한하며, 다른 모든 기업 시스템이 이미 사용 중인 동일한 감사 추적 (audit trail)에 모든 호출을 기록합니다.

그 결과는 다음과 같습니다:

현장 엔지니어는 본인의 시간 기록과 할당된 프로젝트만 볼 수 있습니다.
관리자 (controller)는 가공되지 않은 급여 데이터가 아닌, 집계된 재무 데이터를 봅니다.
게스트 사용자는 아무것도 볼 수 없습니다.

모든 작업은 다른 모든 시스템과 동일한 감사 로그 (audit log) 내에서 지정된 ID (identity)로 추적 가능합니다. 이것이 기업용 AI 보안 모델의 전부입니다. 프롬프트 방화벽 (prompt-firewall) 벤더도, AI 전용 거버넌스 (governance) 플랫폼도, 모델 게이트웨이 (model gateway)도 필요 없습니다. 그저 기업이 이미 운영 중인 액세스 제어 (access-control) 인프라를 MCP-도구 경계에서 강제할 뿐입니다. 프롬프트 인젝션 (prompt injection)조차도 제한 범위 내에 있게 됩니다. 속임수에 넘어간 모델이라 할지라도, 인증된 사용자가 이미 호출할 권한을 가진 도구만을 호출할 수 있습니다.

Anthropic의 2026년 MCP 로드맵은 기업용 인증 및 ID 제공자 (identity-provider) 통합을 최우선으로 합니다. 프로토콜이 이 방향으로 움직이는 이유는 이 패턴이 효과적이기 때문입니다. 기업용 IdP에 대한 도구 수준의 RBAC (역할 기반 액세스 제어)는 "AI 보안 문제"를 이미 해결된 인증 문제로 바꿉니다. 사실 보안 문제는 언제나 인증 문제였습니다.

기업용 ID를 통해 MCP 서버를 연결하면, MCP는 플랫폼에 "연결되는" 것이 아닙니다. MCP가 바로 플랫폼 그 자체입니다.

중요한 작업

프레임워크 업계가 판매하는 것은 비계 (scaffolding)입니다. 실제로 결과를 만들어내는 것은 좋은 도구 설명을 작성하는 구체적이고 도메인에 특화된 작업입니다. 즉, 적절한 세분성 (granularity)을 선택하고, 어떤 도구가 어떤 질문에 적합한지 문서화하며, 쿼리 전략 (query strategies)을 추가하고, 실제 운영 사용 환경에서의 실패 모드 (failure modes)를 포착하여 다시 피드백하는 작업입니다.

이 중 그 어떤 것도 벤더에게 아웃소싱할 수 없습니다. 왜냐하면 귀사의 비즈니스 외부의 그 누구도 귀사의 데이터가 무엇을 의미하는지 알지 못하기 때문입니다. 하지만 엔지니어 한 명과 도메인 전문가 한 명이 있다면, 도메인당 몇 주 안에 이 모든 것을 달성할 수 있습니다. 이것이 바로 사람들이 존재하지 않는다고 말하는 바로 그 트레이드오프 (trade)입니다.

"어떤 프레임워크를 선택해야 할까?"를 대체하는 질문

오늘 MCP 작업을 시작한다면, 가장 유용한 질문은 "어떤 프레임워크가 필요한가?"가 아닙니다. 그것은 "이 도구가 작동했을 때 내일 당장 업무 주간이 더 나아질 단 한 사람을 위해, 내가 작성할 수 있는 가장 작고 유용한 도구는 무엇인가?"입니다.

그것을 만드세요. 그들이 사용하는 것을 지켜보세요. 그들이 시도했지만 작동하지 않았던 것들을 기록하세요. 도구 설명을 업데이트하세요. 그리고 다음 도구를 출시하세요.

실제 비즈니스 전반에 걸쳐 이를 3개월 동안 수행하면, 9개의 프로덕션 서버 (production servers)를 생성하면서도 프레임워크 의존성 (framework dependencies)은 전혀 발생하지 않습니다. 이것이 핵심입니다. 프레임워크가 나쁘다는 것이 아니라, 대부분의 중견 기업 (mid-sized companies)에게 프레임워크는 가장 먼저 해결해야 할 올바른 문제가 아니라는 것입니다.

모델 (model)이 에이전트 (agent)입니다. IDP (IdP, Identity Provider)가 보안 경계 (security boundary)입니다. MCP는 플랫폼 (platform)입니다. 플랫폼 주변이 아니라, 플랫폼을 위해 구축하십시오.

이 글은 중견 기업에서 MCP를 프로덕션 (production) 환경에 배포하는 것에 관한 시리즈의 일부입니다. 왜 이 아키텍처 (architecture)가 소규모 기업에서도 실현 가능한지에 대한 실질적인 사례를 알고 싶다면, Enterprise AI Without an Enterprise Budget를 참조하십시오. 프로덕션 환경의 MCP 서버들에서 제가 관찰한 성숙도 사다리 (maturity ladder)에 대해서는 Six Levels of MCP Servers를 참조하십시오.

원문은 davidgolverdingen.nl에 게시되었습니다. 저는 MCP 아키텍처 (architecture), 에이전트 설계 (agent design), 그리고 중견 기업의 비기술적 사용자들에게 AI를 배포하기 위해 필요한 것들에 대해 글을 씁.