죽어가던 MCP 심폐소생 시작됐나? - Stateless에 주목해야 할 이유.

한 줄 핵심

새로 바뀐 Stateless MCP는 연결 유지 오버헤드와 배포 제약을 크게 줄여 MCP를 다시 실용적인 에이전트 표준으로 만들 수 있지만, 하위 호환성 붕괴라는 큰 전환 비용도 함께 안고 있다.

시간별 요약

0:00
MCP, 한때는 대단했죠 MCP는 초기에 큰 화제를 모았지만, 과대평가·복잡성·API 대체 필요성에 대한 비판도 함께 받았다. 그럼에도 구글 API처럼 자주 쓰는 도구를 에이전트에 붙일 때는 여전히 편리했으며, CLI 도구의 확산으로 한때는 끝났다는 평가까지 나왔지만 에이전트 시대에 맞는 도구라는 점 자체는 유지됐다.
1:15
앤트로픽이 명세를 갈아엎었다 — Stateless MCP 새 명세는 MCP를 Stateless 방식으로 바꾸며 인증과 공식 확장 기능도 함께 정리했다. 이 변화는 MCP를 단순한 CLI 대체가 아니라 실제 제품과 도구에 통합할 만한 표준으로 끌어올릴 가능성을 만든다.
2:15
Stateless란 무엇인가 기존 MCP의 상태 유지형 연결을 요청-응답 방식으로 바꿔, 커넥션을 계속 붙잡지 않아도 되게 만든 것이 핵심이다. 그 결과 서버리스·엣지 같은 환경에 올리기 쉬워지고, 서버 구현이 단순해지며, 사용량 증가 시 확장도 훨씬 수월해졌다.
3:13
커넥션 유지가 문제였던 이유 — 연결 20개와 SyspolicyD 상태 유지형 구조는 사용 중이 아니어도 연결을 계속 살려야 해서 리소스를 낭비했고, 서브 에이전트가 늘어나면 MCP 연결이 기하급수적으로 불어나 오버헤드가 커졌다. macOS의 SyspolicyD가 CPU를 잡아먹는 현상처럼, 다수의 지속 연결은 시스템 입장에서도 수상한 동작으로 보이기 쉬웠다.
5:48
요청 두 번이 한 번으로 이전 방식은 세션 초기화와 실제 도구 호출을 위해 HTTP 요청이 두 번 필요했지만, Stateless 방식은 한 번의 요청으로 끝난다. 덕분에 세션 ID 추적, 라우팅, 상태 공유 같은 복잡한 관리가 사라져 웹 표준과 더 잘 맞는 구조가 됐다.
7:06
경제성과 안전성 — 서버리스 직행 Stateless화는 운영 비용을 낮추고, AWS Lambda나 Cloudflare Workers 같은 서버리스 환경에 바로 올리기 쉽게 만들어 실제 서비스화 가능성을 높인다. 또한 CLI처럼 광범위한 권한을 한 번에 넘기기보다, MCP로 에이전트의 행동을 더 세밀하고 안전하게 통제할 수 있다.
8:33
근데 큰 단점 — 하위 호환이 없다 새 명세는 기존 MCP와 하위 호환이 없어 전환 과정의 충격이 크다. 서버는 비교적 쉽게 바꿀 수 있지만, Claude Code, Codex, Cursor 같은 클라이언트 도구들이 새 명세를 얼마나 빨리 제대로 지원하느냐가 실제 도입의 관건이 된다.
13:02
"껍질 씌운 API 아니냐"에 대한 답 MCP는 밑단에서는 API를 호출하지만, 단순한 래퍼가 아니라 AI 클라이언트가 공통으로 발견하고 호출할 수 있는 표준 어댑터에 가깝다. 특히 인증, 승인, 변경, 알림까지 일관된 방식으로 다룬다는 점에서 USB나 JDBC처럼 인터페이스를 통일하는 가치가 크다.
15:20
결론 — MCP는 API를 대체하지 않는다 MCP는 API를 대체하는 기술이 아니라, 서로 다른 API·데이터·로컬 기능을 AI 애플리케이션이 공통 표준으로 발견하고 호출하게 만드는 계층이다. 이번 Stateless 개편은 MCP의 실용성을 크게 높였지만, 동시에 생태계 전체의 빠른 적응이 필요해졌다.

실무 인사이트

MCP를 도입할 때는 기능 추가보다 먼저 연결 유지 비용, 서버리스 적합성, 클라이언트 호환성을 함께 점검해야 한다.
에이전트용 인터페이스는 API 자체보다 인증·권한·승인 흐름을 표준화할 때 실무 가치가 커진다.
기존 MCP 서버를 운영 중이라면 Stateless 명세 대응 여부를 우선순위로 두고, 클라이언트 도구별 호환성 테스트를 자동화하는 것이 좋다.