제가 실무에서 보는 대부분의 MCP 서버들은 레벨 1 또는 2 단계에 머물러 있습니다. 이들은 단순히 API를 래핑(wrap)하고 몇 가지 도구(tools)를 노출하는 데 그칩니다. 그 결과, 기술적으로는 시스템을 호출할 수 있지만 실제로는 사용자의 도메인(domain)을 이해하지 못하는 에이전트가 만들어집니다.

중견 엔지니어링 기업에서 ERP, BIM, 차량 관리(fleet), 에너지 및 운영 시스템 전반에 걸쳐 9개의 MCP 서버를 출시하면서 하나의 패턴이 나타났습니다. MCP 서버가 도달할 수 있는 정교함에는 6가지의 뚜렷한 단계가 있으며, 대부분의 팀이 출시하는 기본값인 레벨 2와 에이전트가 실제로 도메인을 이해하는 레벨 4 사이의 격차에 대부분의 가치가 존재합니다.

그 단계는 다음과 같습니다.

MCP 서버의 6단계 수준

대부분의 MCP 서버는 동일한 작업을 수행합니다. API를 래핑하고, 한 문장짜리 설명과 함께 도구(tools)를 노출하며, 모델이 나머지를 알아서 파악하기를 기대합니다. 이전 포스트에서 저는 이것이 왜 기업용 데이터(enterprise data)에서 실패하는지 설명했습니다. 여기 9개의 API에 걸쳐 52개의 도구를 가진 9개의 프로덕션 서버를 구축한 후 나타난 성숙도 사다리가 있습니다.

레벨 1: API 매퍼 (API Mapper) (~서버의 70%)

엔드포인트(endpoint)당 하나의 도구. 한 문장짜리 설명. 도메인 컨텍스트(domain context) 없음. 모델은 도구 이름만 보고 모든 것을 스스로 파악해야 합니다. _"예산을 초과하여 진행 중인 프로젝트는 무엇인가요?"_라고 물으면, 모델은 기꺼이 필터를 임의로 만들어내고, 비어 있는 엔드포인트를 호출한 뒤, 모든 것이 괜찮다고 말할 것입니다.

레벨 2: 기능적 (Functional) (~20%)

도구들이 합리적으로 그룹화되어 있습니다. 설명이 더 길어집니다. 누군가가 인간이 이를 어떻게 사용할지 고민했습니다. 하지만 여전히 도메인 지식, 도구 간 참조(cross-tool references), 쿼리 전략(query strategies)은 없습니다. 이것이 오늘날 대부분의 상용 MCP 구현이 목표로 하는 한계치입니다.

레벨 3: 메타데이터 풍부 (Metadata-Rich) (~8%)

지식 그래프 (Knowledge graphs), 용어 사전 (glossaries), 데이터 카탈로그 (data catalogs). 메타데이터는 실제로 존재하지만, 도구 내부에 있는 것이 아니라 도구 옆에 머물러 있으며, 일반적으로 몇 주 또는 몇 달에 걸쳐 수동으로 큐레이션되었습니다. 실제로 수동 큐레이션은 확장성이 없으며, 에이전트는 우연히 적절한 메타 도구를 호출할 때만 이를 읽습니다. 저는 이러한 레이어를 두 개(MCP Resources 및 매개변수가 없는 "가이드" 도구) 구축했으나 테스트 후 모두 제거했습니다. 어떤 Claude 클라이언트도 먼저 요청하지 않았습니다.

레벨 4: 자기 학습형 (Self-Teaching) (<2%)

도메인 지식은 에이전트가 매 호출 시마다 신뢰할 수 있는 유일한 채널인 도구 설명(tool description)과 입출력 스키마(input/output schemas) 안에 들어 있습니다. 그리고 그 지식은 문서를 훑어보는 인간이 작성한 것이 아닙니다. 실제 데이터를 조사하는 AI에 의해 발견되고, 신뢰 수준(confidence levels)이 표시된 후, 도메인 전문가에 의해 검증되었습니다. 저는 이 패턴을 **성찰적 컨텍스트 엔지니어링 (Introspective Context Engineering)**이라고 불렀습니다.

이 차이는 미묘하지 않습니다. 레벨 1 서버는 *"ERP에서 데이터를 쿼리하세요."*라고 말합니다. 레벨 4 서버는 *"항상 summaryOnly=true로 시작하세요. 활성 프로젝트는 수천 개의 레코드를 축적합니다. 타입 코드(Type codes)가 어떤 필드가 채워질지를 결정합니다. 계획된 비용에는 get_budget을 사용하고, 실제 비용에는 이 도구를 사용하세요. 마찰이 발생하면 report_problem을 통해 보고하세요."*라고 말합니다. 이것은 같은 제품이 아닙니다. 같은 카테고리도 아닙니다.

레벨 5: 인터랙티브 앱 (Interactive App) (부상 중)

서버는 단순히 데이터만 반환하지 않습니다. **렌더링된 UI (rendered UI)**를 반환합니다. 인터랙티브 차트, 정렬 가능한 테이블, 클릭 가능한 지도, 타입이 지정된 양식 등 모든 것이 서버에 의해 그려져 대화창 내에 인라인으로 표시됩니다. 에이전트는 조정(coordinate)하고, 서버는 표현(presentation)을 제어합니다.

마크다운 코드 블록에 있는 400행짜리 테이블은 읽을 수 없습니다. 렌더링되고 정렬 및 필터링이 가능한 테이블은 비즈니스 사용자가 실제로 사용할 수 있는 도구입니다. 레벨 5는 인터페이스가 사용자가 있는 곳에서 사용자를 만나는 단계입니다.

레벨 6: 보안 쓰기 앱 (Secure Write App) (최전선)

서버는 단순히 읽기만 하는 것이 아니라, 신중하게 쓰기(write)를 수행합니다. 여기에는 두 가지 패턴이 있습니다. 표준 도구를 통해 저위험 변이(low-risk mutations, 피드백, 점수 등)를 수행하는 **에이전트 주도 제한적 쓰기 (agent-initiated bounded writes)**와, 검증된 MCP App 상호작용을 통해 비즈니스 핵심 데이터를 처리하는 **사용자 주도 보안 쓰기 (user-initiated secure writes)**입니다. 저는 이를 **쓰기 의도 패턴 (WriteIntent pattern)**이라고 부릅니다. 에이전트가 문을 열면, 사용자가 그 문을 통해 걸어 들어가고, 서버는 모든 단계를 확인합니다.

아직 이곳에 도달한 곳은 거의 없습니다. 대부분의 개발자들은 MCP 서버에 쓰기 권한을 부여하는 것 자체에 여전히 불안함을 느끼고 있으며, 레벨 6의 패턴이 존재하기 전까지는 그러한 태도를 유지하는 것이 맞습니다.

발전 단계

데이터 노출 (1) → 도구 정리 (2) → 도메인 이해 (3) → 데이터와 피드백으로부터 학습 (4) → 인터랙티브 앱을 통한 제시 (5) → 보안 쓰기를 통한 실행 (6).

현재 공개된 MCP 생태계의 대부분은 1단계와 2단계 사이에 머물러 있습니다. MCP가 끝난 것이 아닙니다. 대부분의 MCP 서버가 비어 있을 뿐입니다. 다른 전송 방식(transport)을 도입한다고 해결되지 않습니다. 도구 인터페이스를 실제 도메인 지식으로 채워 넣어야 해결됩니다.

만약 여러분이 오늘 MCP 서버를 구축하고 있다면, 가장 유용한 질문은 _"어떤 프레임워크를 선택해야 할까?"_가 아닙니다. _"내 서버는 몇 단계이며, N+1 단계는 어떤 모습인가?"_가 되어야 합니다.

이 글은 원래 davidgolverdingen.nl에 게시되었습니다. 저는 MCP 아키텍처, 에이전트 설계, 그리고 중견 기업의 비기술적 사용자들에게 AI를 배포하기 위해 필요한 것들에 대해 글을 씁니다. 여러분도 비슷한 패턴을 겪고 있다면, 여러분의 이야기를 듣고 싶습니다.