인사이트리포트

들어가며: 1세대 MCP의 성장세 하락 조짐

한때 MCP는 AI 기술의 한 축을 담당하는 가장 각광 받던 기술 중 하나로 평가되었다. 많은 MCP repository 혹은 marketplace들이 난립했고, 각 repository마다 수천, 수만을 헤아리는 MCP 아이템들이 등록되었으며, 이 적재수는 무척 빠르게 증가하고 있었다. 거의 모든 서비스 프로바이더들은 뒤질세라 발 빠르게 기존 자사 서비스들을 MCP 어댑터로 만들어서 배포하는 것에 혈안이 되어 있었다. 향후 AI 기술과 MCP 커플링은 당연한 그림으로 그려졌다.

그런데 지금은 어떤가? 한번 기억을 더듬어 보자. 현재 자신이 사용 중인 AI 서비스에 등록 된 MCP의 갯수는 몇개인지, 마지막으로 MCP repository를 방문했던 것이 언제인지 말이다. 이는 특정 개인만의 지엽적인 경험이 아니다. 실제 데이터가 증명하고 있는데, 최근 트렌드 지표를 보면 MCP 토픽은 미미하게 언급되고 있고, 한때 유망했던 MCP repository 사이트의 일평균 MCP 등록수나 방문자수는 하락 일변도를 걷고 있고 일부는 폐쇄되기까지 했다. 심지어 많은 개발자들이 최근 개발 툴에 아예 MCP를 등록하지 않고 사용하는 경우도 많았다.

그림 1. Google Trends 기준 MCP 검색 관심도 추이와 지역별 관심도 (2024.8~2026.9)

도대체 어쩌다가 MCP는 이런 상황을 맞게 된 것일까? 향후 이를 타계할만한 반등의 계기는 존재하는 걸까?

1. Pre-MCP: 파편화된 개발 툴체인 생태계

일단, MCP는 도대체 어떻게 그렇게 폭발적인 인기를 끌었는가 상기해 볼 필요가 있다.

LLM이 처음 출현할 당시, 일찍부터 이를 개발툴에 적용하려는 시도가 있어 왔다. AI를 탑재한 새로운 개발툴들이 쏟아져 나왔고, 전통적인 개발툴들 역시 앞다퉈 AI Code Assist 기능들이 add-on으로 탑재하는 것이 유행이 되었다. 행여 이를 등한히 한 툴들은 시대에 뒤떨어진 것으로 취급받았다. 비록 이런 시도들이 나름 의미 있는 성과를 내긴 했지만, 시간이 지나며 처음의 놀라움이 가실 때 즈음 냉정하고 가혹한 평가들이 내려지기 시작했다. 생성 된 코드의 품질이 기대에 미치지 못 했던 것이다. 이의 원인을 분석한 결과 기존에 개발 된 코드와 자원을 유기적으로 이용하지 못 해서라는 결론으로 이어졌다. 완성도 높은 개발을 수행하려면 단순히 현재의 소스코드만 작성하고 수정하는데 그치지 않고, 기존 코드들을 종합적으로 파악하고 AI 스스로 직접 빌드 도구를 실행해 컴파일 오류를 분석하고, 테스트 러너를 가동하며, 프로젝트의 변경 이력(Git)이나 소스 구조(AST)를 실시간으로 들여다볼 수 있어야 한다.

몇몇 발빠른 AI 개발툴들은 이런 문제들을 극복하기 위한 자체적인 솔루션들을 탑재하기 시작했고, 이것은 그들의 명확한 경쟁력으로 평가받을 수 있었다. 하지만 이는 각 개발툴들이 자신만의 규격으로 각개전투를 하는 것을 의미했고, 당연히 다음의 문제들을 연쇄적으로 낳았다.

• 독점적 규격의 폐쇄성: 흔히 쓰는 AI 내장형 IDE나 개발 프레임워크들은 Custom-tool 연동을 위한 표준 통로가 없었다. 특정 회사에서 이들 툴에 사내 자원을 이용할 수 있게 해 주거나 자체적인 코드 분석기나 쿼리 검사기를 IDE에 붙이고 싶어도, IDE 내부 명세가 비공개여서 직접적인 주입이 불가능했다.
• 터미널 명령어를 엮어 쓰던 한계: 기존의 여러 컴파일러나 린터(Linter)를 에이전트와 통신하게 하려면 터미널 출력(stdout)에 나타난 raw 메시지를 그대로 긁어다 클립보드를 통해 프롬프트에 흘려보내는 번거롭고 불안정한 수작업에 의존해야 했다. 에러 서식이나 줄바꿈 하나만 달라져도 구문 해석에 지장이 발생하는 상당히 취약한 연동 방식이었다.
• 중복 개발로 인한 연동 비용 증가: 자체적으로 유용한 빌드 피드백 수집 도구를 하나 개발하더라도, 이를 특정 IDE에 보급하려면 해당 플랫폼이 요구하는 독자적인 API 규격에 맞춰 어댑터를 개발해야 했다. 만약 다양한 다른 개발 툴들에 널리 배포하고 싶다면 모든 툴에서 요구하는 규격에 맞는 어댑터를 3번, 4번씩 매번 다시 개발해야 했다.

2. Model Context Protocol (MCP): 툴체인 통합의 시작

이러한 파편화 문제를 해결하기 위해, 앤트로픽(Anthropic)은 2024년 하반기에 오픈 표준인 Model Context Protocol (MCP)을 공식 발표했다. 앤트로픽이 제안한 이 사상은 개발 도구 내부 소스코드에 연동 어댑터를 강결합하는 대신, 독립적인 프로세스로 구동되는 전용 서버를 띄워 규격화된 프로토콜로 소통하게 하자는 무척 간결한 규격이었다. 사실 이는 AI 개발툴 생태계 전체를 위해 마련한 규격이라기보다는 자사 툴에서 사용하기 위해 제공한 규격에 가까웠다. 하지만 무척 느슨하고 특정 툴에 종속되는 특성들을 배제한 덕에 아주 유연하다는 장점이 있었고, 이는 AI 개발 생태계에 크게 호평을 받아 빠르게 퍼져나가기 시작했다.

• 한 번 개발해서 어디서나 붙여 쓰는 편리함: 이제 개발자는 코드 포맷터, 디버거, 빌드 스크립트 등 나만의 개발 도구를 원하는 언어로 한 번만 구축하면 된다. 이 MCP 서버는 표준 규약을 따르므로, MCP를 지원하는 모든 에디터와 코드 한 줄 수정 없이 간편하게 연동된다.
• 개발 컨텍스트의 체계적 통합: 단순히 컴파일러를 기동하는 기능 실행(Tools)뿐만 아니라, 정적 코드 자원(Resources)과 도구 제어용 프롬프트 가이드라인(Prompts)까지 단일 규격으로 통합하여 에이전트에게 풍부한 개발 맥락을 주입한다.
• 로컬 stdio 통신을 활용한 안전성: 외부 네트워크 엔드포인트를 열 필요 없이, 로컬 표준입출력(stdio) 파이프라인을 그대로 이용한다. 에디터 하위 프로세스에서 linter나 디버거 세션을 로컬 샌드박스 내부처럼 안전하고 지연 없이 제어하는 구조다.

기존의 문제를 깨끗이 해결해 준 이런 장점으로 인해 MCP는 많은 개발자와 사용자에게 호평을 받았고, 극히 짧은 시간 안에 업계 표준으로 정착될 수 있었다. 그에 따라 폭발적인 성장은 물로, AI 툴의 능력을 기존에 비해 한층 끌어올리는 기폭제가 되었다.

3. 1세대 MCP: 상시 세션 연결의 약점

1세대 MCP의 대표적인 특성은 현재의 인스턴스와 강한 연결성을 갖는다는 것이다. 인스턴스의 프로세스 자원 생성 단계에서 함께 초기화가 이루어지기에 실질적인 동작에 앞서 이미 MCP의 인스턴스 역시 함께 생성된다. 이런 강한 커플링으로 인해 MCP는 해당 프로세스와 라이프 사이클을 공유한다. 이 말의 의미는 처리 태스크의 갯수가 많아지면 그만큼 MCP의 인스턴스도 동일한 갯수로 늘어난다는 의미이다. 등록 된 MCP가 복수개면 거기에 태스크의 갯수를 곱한 NxM 갯수의 MCP 인스턴스가 생성되어 초기화까지 이루어진다는 것이다. MCP 한개의 자원 점유율이 높다면 이는 심각한 시스템 부하로 이어질 수밖에 없다. 마치 WWW 초창기 시절 CGI를 연상케 하는 상황이다. 다만 MCP는 사용하지 않고 단지 등록되어 존재하는 것만으로도 시스템 자원을 소모한다는 점에서 CGI보다 더 안 좋은 상황이라 할 수 있다.

초기 AI 개발툴들은 기껏해야 1개의 단일한 태스크가 모든 작업을 도맡는 경우가 많았다. 사용자의 요청과 처리와 결과를 보여주고 다음 지시를 받는 순차적인 인터랙션이 일반적이었다. 이때 시스템에 걸리는 부하는 MCP의 갯수에 1:1로 비례했다. 하지만 최근 개발툴들은 에이전틱한 처리가 주를 이루고 있다. 즉, 사용자의 지시를 단발성으로 처리하고 바로 결과를 보여주는 것이 아닌, 사용자의 직접적인 작업 지시가 아니라 최종 요구사항만 받고, 이를 바탕으로 워크플로우를 설계하여 처리를 완성할 때까지 Loop를 형성시키는 처리가 일반화 된 것이다. 이때는 태스크의 갯수는 특정하기 힘들다. 보통은 수개에서 십수개 이상의 태스크가 동시에 생성되어 동작하는 경우가 다반사이다. 태스크 한개당 모든 MCP 갯수만큼의 부하가 걸리기에 이럴 때 시스템에 걸리는 부하는 NxM이 된다. 다수의 MCP를 이용하던 사람들이 갑자기 시스템이 급격히 느려지는 경험을 많이 했을 것이다. 인프로세스(in-process) MCP의 경우엔 기계적으로 시스템 부하를 증가시킬테고, 리모트 서비스 MCP의 경우엔 환경적인 요인 때문에 레이턴시가 지연을 발생하시켜, 아예 시스템이 멈추는 듯한 경우까지도 자주 발생한다.

이를 만약 개발툴이 아니라 서비스에 MCP를 활용했을 경우, 심각한 서비스 품질의 저하까지 유발하게 되며 시스템 요구량을 폭증시켜 인프라 비용을 증가시키게 된다. 최근 인프라 추세에 맞는 서버리스 환경인 FaaS(Function as a Service)에 이식이 불가능하다는 구조적인 문제까지 낳고 있다.

그림 2. 1세대 MCP의 강한 결합 구조와 태스크 증가에 따른 N×M 부하

이 모든 상황이 MCP의 실질적인 사용 여부와 상관 없이 단순히 등록되어 활성화 되어 있는 것만으로도 모든 AI 작업 전역적으로 발생하는 문제이기에 더욱 심각하다. 때문에 최근의 툴에는 등록 된 모든 MCP를 전역적으로 적용하기보다는, 개별 세션 단위로 사용할 예정인 MCP의 목록을 개별적으로 켜고 끄거나, 에이전트 별로 사용할 MCP의 목록을 등록하여 관리하는 기능이 탑재되어 있는 경우도 있다.

4. MCP의 대안

MCP로 인해 발생하는 부하가 문제가 되자 이를 해결하기 위한 몇가지 해결책들이 제시되고 있었는데, 앞서 언급한 MCP의 적용 범위를 조절하는 방법 외에도 아예 좀 더 근원적인 부분에서도 해결책이 나오기 시작했다. 바로 MCP와 동등한 역할을 하되, MCP의 형식을 사용하지 않는 것이다. 어차피 MCP는 그냥 LLM의 Tool-calling을 패키징한 어댑터의 형식 중 하나에 불과하기 때문이다.

예를 들어, MCP가 등장하던 초창기에 해당 기술을 소개할 때 가장 빈번하게 소개되는 샘플이 바로 FileSystem MCP였다. 이로 인해 LLM이 로컬 시스템 상의 파일을 읽고 쓰는 것을 가능하게 해 주었다. 이 기능은 너무도 유용하여 MCP의 위력을 빠르게 체감시켜주는데 효과적이었고, 이후 거의 모든 AI 툴에 필수적으로 사용되는 MCP로 정착되었다. 하지만 이 유용함은 역으로 FileSystem MCP를 더욱 빨리 퇴출시키는 역효과를 내고 말았다. 유용한만큼 사용빈도가 높았고, 그만큼 시스템에 많은 부하를 주고 있다는 것을 깨달은 AI 툴 제작자들이 아예 해당 기능을 자사의 툴에 built-in으로 내장해 버리기 시작한 것이다. 그 효과는 즉각적인 성능 향상으로 증명되었고, 뒤어어 FileSystem만큼이나 유용하고 사용 빈도가 높은 웹 검색이나 RestAPI call, shell 실행 MCP 등도 차례로 거의 모든 AI 툴들에 built-it 기능으로 흡수되는 수순으로 이어졌다. 실시간으로 변경되는 스펙 문서를 참조하는 Context7 정도만 여전히 활발히 사용되는 MCP라 할 수 있을 듯 하다.

이러한 경향성을 결정적으로 가속화한 계기는 주요 에디터와 개발 프레임워크들이 내장형으로 탑재하기 시작한 하네스(Harness) 기술의 급격한 성장이었다. 굳이 외부에 별도의 MCP Server 프로세스를 띄우고 JSON-RPC 규격으로 소통하는 무거운 이중 미들웨어 레이어를 통하지 않더라도, 하네스 자체의 내장툴(built-in tool)이 자체 터미널 세션을 직접 가동하고, 작업 영역의 소스코드를 고속으로 인덱싱하며, 로컬 linter나 formatter의 실행 피드백을 에이전트 컨텍스트에 즉각적으로 흘려보내는 가벼운 직결식 통신을 완벽히 구현해 냈기 때문이다.

이러한 하네스는 프로토콜 번역이나 불필요한 직렬화/역직렬화 오버헤드가 없어 왕복 지연 시간(RTT)을 무영향 수준으로 극소화했다. 이는 실시간 코드 작성 과정에서 에디터의 빠른 초저지연 반응성을 보장하는 강력한 성능적 우위로 작동했다. 또한 외부 독립 프로세스인 MCP 서버와의 연결 유실이나 세션 끊김 상태를 늘 감시해야 하는 불안정성이 사라졌다. 에디터 자체 하네스가 OS 수준의 프로세스 시그널을 직접 통제하므로 컴파일러 에러나 터미널 프로세스 타임아웃 상황이 발생하더라도 지연(Hang) 없이 즉각적으로 장애를 인지하고 복구 사이클을 가동할 수 있었다.

사용자 경험(DX)의 질도 완전히 달랐다. 별도의 실행 환경(Node.js, Python 등)을 유저 PC에 수동 설치하고, 개별 MCP 서버 포트를 연동하고 파이프를 관리하는 긴 설정 지연이 필요 없었다. 빌트인 된 툴이기에 하네스와 고도로 결합하여 제로 컨피그(Zero-Config)로 작동하므로, 에이전트 도구 활용의 거대한 장벽이었던 세팅의 난도를 무화했다. 결국 터미널 제어나 소스 탐색 등 대다수의 상식적인 로컬 개발 핵심 동작들이 하네스 단독으로도 완벽히 다뤄지면서, 외부 매개체인 MCP는 오히려 거추장스러운 미들웨어 레이어라는 인식을 피하기 힘들게 되었고 이는 1세대 명세의 쇠퇴를 크게 촉진하는 자극제가 되었다.

5. 2세대 Stateless MCP: 무상태 요청 명세의 구조

어느새 MCP는 효용성에 큰 회의감을 불러 오게 되었고 한정된 영역에서만 유용성을 인정 받아 겨우 명목을 이어가는 상황이 되고 말았다. 아예 무용하다라는 수준까진 아니지만 그 효용성에 비해 소모하는 시스템 자원이 너무 크기에 어지간하면 다른 기술로 대체되는 경우가 점점 많아지고 있었다. MCP가 처음 발표된 것이 2024년 11월이었으나 주목을 받기 시작한 것이 2025년 중반 즈음이었던 것을 감안하면, 일반인이 접하게 된지 겨우 년도 안 된 남짓한 시간이 지났을 뿐인데, 신기술이었다가 대세 기술로 전성기를 누렸다가 쇠퇴하여 구시대의 유물 취급을 받는 흥망성쇠를 모두 겪게 된 것이다. AI의 경이로운 기술 발전 속도를 반증하는 하나의 예이다.

이대로 점점 신기술들은 밀려서 사라지는 수순을 밟는 것 아닌가 하는 느낌이 들던 차에, MCP의 운명을 뒤바꿀 또다른 사건이 발생한다. 최근 앤트로픽은 기존의 MCP의 단점을 해결한 새로운 2세대 MCP 규격을 발표한 것이다. 공식명칭은 2026-07-28 MCP라는 다소 딱딱한 명칭인데, 일명 Stateless MCP로 불리고 있다. (이와 구분하기 위해 1세대 MCP는 Stateful MCP라는 새로운 별칭을 갖게 되었다.) 이 새로운 규격은 기존의 MCP의 가장 큰 문제로 지적받던 번거로운 세션 동기화와 핸드셰이크 절차를 과감히 생략하고, 클라이언트가 단일 요청만으로 필요한 도구를 가볍게 기동해 호출하도록 프로토콜을 개정한 것이다. 사실 이것 외에 그리 크게 눈에 띄는 차이는 별로 없다. 애초에 MCP 자체가 그리 복잡한 스펙이 아니기 때문이다. 하지만 이 작은 차이 덕에 그동안 MCP를 기피하게 만든 가장 치명적인 문제가 깨끗이 해결될 수 있었다.

이러한 구조적 단순화를 실현한 핵심 기술은 바로 _meta 필드의 도입이다. 요청 패킷(JSON-RPC params) 자체에 필요한 메타데이터를 압축해 송신하는 방식이다.

{
  "jsonrpc": "2.0",
  "method": "notifications/tools/list_changed",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/subscriptionId": "<original listen request id>"
    }
  }
}

매 요청이 자가 설명적(Self-Describing) 성격을 띠면서 서버는 상태를 전혀 남기지 않고도 독립적으로 검증을 마치고 응답을 반환할 수 있게 되었다. W3C 표준 분산 트레이싱 식별자(w3cTraceContext)가 동봉되면서, 서버가 여러 분산 노드로 유연하게 라우팅되더라도 모니터링과 에러 원인 추적이 한층 원활해졌다.

Architecture: Stateful MCP vs Stateless MCP

두 아키텍처의 패러다임 차이와 통신 메커니즘의 특성은 아래와 같이 요약할 수 있다.

그림 3. Stateful MCP와 Stateless MCP의 서버 구성 비교

6. 무엇을 계승하고, 무엇을 버렸는가

이 전환 과정에서 2세대 Stateless MCP는 1세대의 성공적인 철학은 계승하고, 인프라의 발목을 잡던 구조적 무거움은 배제하는 실용적인 정리를 선택했다.

계승한 것: ‘도구 통합의 약속과 안전함’

• 도구 정의의 규칙: AI가 이해할 수 있게 행동 양식(Tools), 정적 파일(Resources), 프롬프트 가이드(Prompts)를 하나의 세트로 정의하여 제공하는 편리한 규칙은 그대로 유지했다.
• 두뇌와 손발의 영리한 역할 분담: 똑똑한 AI 모델(두뇌)과 실제 명령을 수행하는 로컬 개발 도구(손발)를 완벽히 분리해, 한쪽이 바뀌어도 다른 쪽에 영향을 주지 않는 영리한 역할 분담 방식은 철저히 이어받았다.
• 로컬의 안전한 샌드박스: 외부 인터넷 연결 없이 내 컴퓨터 내부(stdio)에서만 안전하게 데이터를 주고받던 확실한 보안 연동 가치도 버리지 않고 챙겼다.

배제한 것: ‘상시 연결에 따르는 자원 낭비와 제약’

• 상시 연결을 위한 메모리 소모: 클라이언트와 서버가 연결 상태를 실시간으로 모니터링하며 지속적으로 메모리를 소비하던 무거운 관리 부담을 완전히 걷어냈다.
• 매번 거치던 동기화 핸드셰이크: 통신할 때마다 세션을 새로 열고 동기화하던 초기화 절차를 단순화하여, 요청이 있을 때 단 한 번만 요청을 날려 처리하는 구조로 개편했다.
• 백그라운드 프로세스의 상시 구동 제약: 간헐적인 AI 호출을 처리하기 위해 서버를 백그라운드에 연중무휴 기동해야 했던 구동 제약에서 벗어났다. 필요할 때만 가볍게 실행되는 서버리스 인프라에 손쉽게 얹을 수 있는 유연성을 확보했다.

7. Stateless MCP로의 마이그레이션

2세대 MCP의 성패는 기존에 작성 된 1세대 MCP들이 얼마나 빠른 속도로 2세대로 전환되는가에 달려 있을 것이다. 그런데 2세대 MCP의 가장 큰 문제는 1세대 MCP와 하위 호환성이 없다는 점이다. 1세대 MCP의 가장 큰 특징 중 하나를 제거했기에 당연한 결과이다. 그럼에도 불구하고 그 특징이 바로 가장 큰 단점의 근원적인 원인에 해당되기에 호환성을 포기하면서까지 과감히 제거할 수밖에 없었을 것이다. 이는 이전에 구축 된 생태계를 포기해야 한다는 의미이기에 앤트로픽으로선 뼈 아픈 선택이 될 수밖에 없다. 기존의 MCP들을 새 스펙에 맞춰 운영하려면, 비록 프로토콜 레벨에선 하위호환이 된다지만 구현체는 다른 컨셉을 따라 개발되었기에 실제로는 Stateless하게 구현을 전면 수정하든 호환 레이어를 만들든, 어느 쪽이든 마이그레이션 작업이 필수적으로 요구된다.

지금 당장은 새로운 Stateless MCP를 체험해 보려 해도 쉽지 않은 상황이다. AI 툴과 서비스 양쪽에서 모두 새로운 스펙에 맞춰 지원 기능을 탑재해야 하기 때문이다. 이 글을 쓰고 있는 2026년 9월 기준, 아직까진 유명 개발 툴 중에 Stateless MCP를 지원하는 것을 찾아 볼 수가 없다. 그나마 다행인 것은 몇몇 툴들의 로드맵 상에 Stateless MCP 지원이 추가되었다는 점이다. 최근의 AI 개발 툴들의 릴리즈 속도를 보건데, 아마 오래지 않아 실제로 사용이 가능할 걸로 예상된다. 물론 개발툴에 호환성 레이어를 탑재하는 방법도 존재하지만 이는 2세대 MCP의 중요한 장점을 희석시키는 것이기에 가급적 마이그레이션 쪽을 선택하는 것이 더 적절하다.

AI 개발 툴이 준비가 되었다고 해서 바로 예전 MCP와 같은 수준의 환경이 만들어지는 것이 아니다. 이후로도 2단계를 더 넘어서야 한다. 서비스 프로바이더들이 새 MCP 규격에 맞춰 기존 MCP들을 마이그레이션 해서 재배포를 해 줘야 한다. 또한 사용자 입장에서도 기존 MCP를 대체할 수 있는 새로운 MCP를 찾아서 자신의 개발 툴에 재등록 해주는 절차를 밟고 나서야 비로소 새로운 MCP를 사용해 볼 수 있는 준비가 되는 것이다.

이런 일련의 상황을 보자면 아무래도 기존 MCP를 배포했던 서비스 프로바이더 입장에서는 고민이 될 수밖에 없다. 새로운 규격의 MCP로 마이그레이션하는 것도 물론 비용이 발생하지만 기존 MCP도 함께 유지보수 해야 하기 때문에 관리 포인트가 2배로 늘어나기 때문이다. MCP의 유행이 침체되어 가는 상황에서 아무래도 새로운 MCP에 대한 확신이 없다면 선뜻 선택하기 힘든 옵션이다.

결론: Stateless MCP의 미래

Stateless MCP가 비록 기존 MCP의 문제를 해결하기 위한 효과적인 해법을 제시한 것은 사실이지만, 사실 과거의 영광을 다시 차지할 수 있을까 하는 전망에 대해서는 다소 복합적인 의견이 나오고 있다. 왜냐하면 새로운 MCP 스펙이 제안되기 전에 이미 다른 대안들이 제시되어 시장에서의 영향력을 선점하고 있는 상태이기 때문이다. Stateless MCP가 1세대 MCP의 지위를 되찾기 위해서는 먼저 넘어야 할 산이 남아 있다. 현재 에이전트 도구 생태계는 저마다의 뚜렷한 쓰임새와 강점을 바탕으로 세 진영이 팽팽한 균형을 이루고 있다.

• 로컬 빌트인 플러그인 (Native Skill): 실시간 파일 수정이나 로컬 터미널 명령어 실행처럼, 0.1초의 지연도 용납하지 않는 초고속 반응성이 필요한 영역이다. 네트워크의 미세한 딜레이조차 배제하기 위해 에디터 내장 플러그인 형태로 직접 구동한다.
• OpenAPI (Swagger) 직결: 이미 널리 구축된 표준 웹 API 자산을 활용하는 가장 빠른 길이다. LLM의 독해력이 진화함에 따라 굳이 MCP 레이어를 새로 만들지 않고 기존 Swagger 명세서를 모델에게 직접 주입해 스스로 호출하도록 유도한다.
• 1세대 MCP: 아이러니하게도 새로운 MCP가 시장에 안착하기 위해 넘어야 할 가장 큰 장벽 중 하나는 과거에 이미 널리 퍼진 1세대 MCP이다. 새 MCP는 하위 호환을 사실상 포기했기 때문에 이들의 존재는 발판이 아니라 오히려 경쟁자에 가깝다. 과도한 시스템 부하라는 약점에도 불구하고 1세대 MCP는 충분히 기능하고 있기에 당장 이를 버려야 하는 당위성을 찾기 힘든 경우도 많다. 아이러니하게도 MCP의 사용량이 줄어듦에 따라 MCP로 유발되는 부하도 함께 줄어들어서 MCP의 퇴출 의지마저도 자연스럽게 줄어드는 의외의 결과로 이어졌다.

새로운 MCP 스펙이 나왔다고는 하나, 엄연히 이는 앤트로픽 주도로 추진하고 있는 규격일 뿐이다. MCP가 처음 제안되었던 시기와 지금은 상황이 많이 다르다. 그때는 시장에 이의 대체제가 없던 시기였기에 시장의 필요와 맞아떨어져 폭발적인 관심을 받을 수 있었다. 하지만 지금은 여러 대안이 나와 있는 상태이다. 당장 OpenAI나 Google 등 경쟁 빅테크 진영이 앤트로픽 주도의 이 명세를 표준으로 받아들일지 불투명하다. 또한 모델 성능 향상으로 Swagger 명세서를 직결해 쓰는 경향이 짙어질수록 MCP의 입지는 좁아질 수밖에 없다.

그럼에도 이전 규격의 문제를 해결한 새로운 MCP의 등장을 마냥 부정적으로 생각할 필요까지는 없을 듯 하다. 결국 미래의 도구 연동 환경은 단일 표준의 지배가 아닌, 각 상황 별 최적화된 툴이 분업하는 하이브리드체계로 수렴할 공산이 크기 때문이다. 이를테면 초저지연 성능이 생명인 로컬 제어는 빌트인 툴이 전담하고, 트레이싱 추적이 필요한 클라우드 연동 브릿지는 Stateless MCP가 미들웨어 역할을 수행하며, 이미 탄탄히 구축된 대량의 레거시는 표준 OpenAPI 규격 자체를 다이렉트로 매개하는 비대칭적 공존 구도가 그려진다. Stateless MCP는 보편적 표준이 되기까지 많은 과제를 안고 있으나, 아키텍처적 유연성과 무상태의 가벼움을 무기 삼아 하이브리드 인프라의 한 축을 담당할 잠재력은 충분하다 말할 수 있을 듯 하다.