2026년 7월 28일, 앤트로픽이 MCP 명세를 통째로 갈아엎었습니다. 커넥션을 계속 물고 있어야 했던 스테이트풀 방식에서, REST API처럼 요청 한 번에 응답을 받는 스테이트리스 방식으로 전환된 것입니다. “MCP는 끝났다”는 분위기 속에서 나온 이번 대격변이 실무에서 MCP를 쓰는 개발자에게 무엇을 바꾸고, 무엇을 여전히 조심해야 하는지 정리해봤습니다.
이 내용은 LLM 코딩을 다루는 채널 김플립에서 제작한 영상을 바탕으로 정리했습니다.
MCP의 하입과 피로감, 그리고 새 명세 발표
MCP가 처음 나왔을 때 앤트로픽이 발표하자마자 반향이 정말 컸고, 다들 자기 제품에 MCP부터 붙이려고 하면서 하입이 어마어마했습니다. 그만큼 비판도 많았는데, 지나치게 과대평가됐다거나 명세가 너무 비대하다, 해결한 문제만큼 새로운 문제를 만든다는 지적이 이어졌고 “API가 이미 있는데 굳이 MCP를 왜 쓰냐”는 얘기가 가장 많이 나왔습니다.
실무에서 쓰는 MCP는 결국 몇 개로 줄었다는 이야기도 나옵니다. 모델 성능이 급격히 좋아지면서 번거롭게 MCP 연결을 유지할 이유가 줄었기 때문입니다. 다만 매일 확인해야 하는 구글 API 연동처럼 MCP만큼 편한 게 없는 경우도 있고, 컨텍스트7처럼 MCP에 최적화된 도구도 잘 쓰이고 있습니다. 이후 CLI 도구가 쏟아져 나오고 모델이 CLI를 잘 다루게 되면서 “MCP는 끝났다”는 얘기까지 나왔지만, MCP가 에이전트 시대에 걸맞은 도구라는 점 자체는 틀림없습니다.
이런 흐름 속에서 앤트로픽이 7월 28일 새 MCP 명세(“MCP 2026-07-28”)를 발표했습니다. MCP2처럼 직관적인 이름 대신 날짜를 붙인 점은 아쉽다는 반응도 있었지만, 사이먼 윌리슨은 이를 두고 “스테이트리스 MCP가 내 관심을 다시 되살렸다”는 글을 올리며 주목했습니다.
스테이트리스 전환과 세 가지 장점
이번 명세의 핵심은 MCP를 스테이트풀에서 스테이트리스로 바꾼 것입니다. 기존 MCP는 양방향 상태 유지 프로토콜로 커넥션이 계속 물려 있어야 했지만, 이제는 요청이 오면 그때 응답하는 요청-응답 모델, 즉 REST API와 같은 방식으로 바뀌었습니다. 이렇게 바뀌면서 생기는 장점은 세 가지입니다.
- 배포 유연성: 서버리스나 엣지 인프라처럼 실시간 연결이 필요 없는 환경에도 MCP 서버를 올릴 수 있게 됐습니다.
- 개발 단순화: MCP 서버를 만드는 과정 자체가 훨씬 간단해졌습니다.
- 확장성 향상: 사용량이 급증해도 커넥션을 유지할 필요가 없으니 서버를 늘리기가 쉬워졌습니다.
연결 유지가 문제였던 이유 — 서브 에이전트 20개와 시스폴리시티D
기존 스테이트풀 방식에서는 클라이언트와 서버가 전용 연결을 계속 유지해야 했고, 실제로 쓰든 안 쓰든 전체 과정 동안 연결이 끊기지 않고 유지돼야 했습니다. 클로드를 쓰다가 “MCP 연결이 끊겨 있다”는 메시지를 자주 보고 매번 재연결해야 했던 이유가 바로 이것입니다.
클로드 코드를 실행해 무거운 작업을 시키면 서브 에이전트가 다섯 개 생성되는데, 이때 서브 에이전트 하나마다 MCP를 물게 됩니다. MCP가 네 개 깔려 있다면 5×4, 즉 총 20개의 상태 연결이 생기는 셈입니다. 서브 에이전트 중 하나라도 MCP가 필요할 가능성이 있으니 로컬 서버 프로세스를 전부 띄워놔야 하고, 결국 서버 프로세스 20개가 돌면서 오버헤드가 어마어마해집니다.
맥을 쓰는 사람이라면 시스폴리시티D 데몬이 CPU를 잡아먹는 것을 본 적이 있을 텐데, 맥OS가 프로세스의 수상한 행동을 감시할 때 쓰는 이 서비스가 커넥션이 한꺼번에 20~30개씩 뜨는 것을 수상하게 여겨 감시하면서 CPU 점유율이 치솟는 것입니다. 스테이트리스로 전환되면 연결을 강제하지 않으니 이 문제가 해결됩니다. 과거에는 한 클라이언트가 항상 같은 서버 인스턴스로 라우팅되도록 로드 밸런스를 구성해야 했지만, 스테이트리스 환경에서는 이런 라우팅 유지가 필요 없습니다. 이는 개발자들이 MCP 서버의 신뢰성과 확장성 때문에 가장 많이 요청해온 기능 중 하나였습니다.
요청 두 번에서 한 번으로 — 사이먼의 비교
사이먼 윌리슨은 이번 릴리즈를 “스테이트리스 MCP”라고 부르며, 새 표준 덕분에 클라이언트와 서버 양쪽의 구현 복잡도가 크게 낮아졌다고 말합니다. 실제로 그는 이번 주에만 MCP를 세 개 만들었다고 언급했습니다.
과거 스테이트풀(레거시 MCP) 방식에서는 HTTP 요청이 두 번 필요했습니다. 먼저 세션을 초기화하고 아이디를 받는 요청 하나, 그다음 실제 도구 호출을 시작하는 요청 하나였습니다. 이 방식에서는 도구 호출이 올 때마다 세션 아이디가 일치해야 하고 올바른 서버로 라우팅돼야 했습니다. 반면 스테이트리스 방식은 HTTP 요청을 딱 하나만 씁니다. 세션 아이디를 추적하는 서버 상태도, 같은 세션을 받는 백엔드 머신으로 보내는 라우팅도 유지될 필요가 없어져 확장 가능한 웹에 훨씬 잘 맞습니다.
경제성과 안전성 — 서버리스 직행
명세가 비대하면 배포할 때 비싼 인프라가 필요해지고 결과적으로 실제 서비스를 운영할 가능성이 낮아집니다. 스테이트리스가 되면 일단 구현해서 출시하고 사용량이 커질 때 확장하기가 훨씬 쉬워지며, 아무도 안 쓸 때는 비용을 거의 0에 가깝게 유지할 수 있습니다. AWS 람다나 클라우드플레어 워커스 같은 서버리스 호스팅에도 쉽게 올릴 수 있어 클라우드 호스팅 측면에서도 유리합니다.
안전성 측면에서도, 에이전트가 점점 더 위험한 일을 수행하는 시대에 MCP로 에이전트가 할 수 있는 행동을 제한하는 것이 좋은 방법입니다. 에이전트에게 CLI 권한을 전부 주면 거의 무적이 되어버리는데, CLI는 특정 명령에 대해서만 권한을 세부적으로 관리하기가 어렵기 때문입니다. 옵션별로 권한을 따로 설정하려 해도 CLI의 한계상 너무 복잡해 사실상 불가능에 가깝습니다. 민감한 앱을 만들 때는 MCP를 활용하면 더 적극적이고 안전하게 에이전트를 제어할 수 있습니다.
큰 단점 — 하위 호환이 전혀 안 된다
새 표준에는 치명적인 단점이 있습니다. 레거시 MCP와 신규 MCP 간 하위 호환이 전혀 안 된다는 점입니다. 다만 그동안 쓸 만했던 MCP가 구글이나 버셀 같은 빅테크 서비스이거나 자체 매뉴얼을 MCP로 제공하는 정도가 대부분이었기 때문에 전환 자체에 큰 무리는 없을 것으로 보입니다. 지금 상황은 USB-A에서 USB-C로 세대 교체가 일어나는 과정과 비슷하며, AI 예산을 끌어오려고 급조한 API에 대충 래핑만 씌운 저품질 MCP 서버들이 난립했던 거품 시절도 있었습니다.
서버 쪽은 새 명세에 맞게 업데이트하는 것이 어렵지 않고 비용 절감 효과도 있어 전환할 업체들은 결국 움직일 것으로 보입니다. 진짜 걱정되는 것은 클라이언트 쪽입니다. 클로드 코드, 코덱스, 키미 코드, 오픈 코드, 커서, 그록 CLI 등 에이전트 클라이언트 도구가 많은데, 이 도구들이 7월 28일자 새 버전을 제대로 지원할지는 아직 의문입니다. 이전 버전과 새 버전은 명세 자체가 완전히 달라 개벽에 가까운 변화인데도 버전 표기는 여전히 날짜 하나뿐이라, 개발자가 새 명세에 맞춰 서버를 만들어도 사용자가 갱신 안 된 구형 클라이언트를 쓰고 있으면 정상 작동하지 않을 수 있습니다.
다만 LLM 덕분에 이 문제가 덜 심각해질 수 있다는 낙관적 전망도 있습니다. 예전 같으면 하루아침에 하위 호환도 안 되게 바꾼 표준이라고 비판받았겠지만, 지금은 에이전트에게 “이 명세가 작동하도록 업데이트하라. 테스트용 MCP 세 개로 전부 검증하고 스테이트리스로 호환되게 만들어라”라고 맡기면 개발은 30분이면 될 것이라는 예상입니다. 여전히 구형 레거시 MCP만 지원하는 회사가 있다면 AI 도구의 능력과 빠른 반복 개발 속도를 이해하지 못하는 곳이라는 게 드러날 것이고, 시장에서 지적받아 빠르게 고쳐질 것이라는 전망입니다.
“껍질 씌운 API 아니냐”는 지적에 대한 답
“MCP도 결국 껍질만 추가된 API 아니냐”는 지적에는 반은 맞고 반은 틀렸다고 답할 수 있습니다. 엄밀히 말하면 MCP도 API의 한 종류가 맞습니다. 밑단에서는 결국 JSON 기반 API가 돌아가고 있기 때문입니다. 하지만 MCP는 기존 API, 데이터베이스, 로컬 기능 위에 놓이는 AI 클라이언트용 표준 어댑터입니다. 예를 들어 깃허브 MCP 서버를 써도 실제 이슈 생성이나 PR 조회는 결국 깃허브 API가 처리하므로, 윗단에서는 결국 API를 호출한다는 지적은 맞습니다.
다만 이런 관점은 MCP가 해결하려는 핵심 문제를 놓치고 있습니다. MCP는 USB나 JDBC 같은 기술 스택에 비유할 수 있습니다. USB는 저장 장치 기능 자체를 만드는 게 아니라 장치 연결 방식을 통일하는 것이고, JDBC도 데이터베이스를 따로 만드는 게 아니라 접근 인터페이스를 통일하는 것처럼, MCP도 에이전트가 수십 가지 서비스마다 매번 API를 따로 구현하지 않고 통일된 인터페이스로 연결할 수 있게 해준다는 점에서 의미가 있습니다.
오픈API로도 비슷하게 쓸 수 있고 실제로 오픈API 문서를 읽어 MCP 툴로 변환하는 어댑터를 만드는 것도 가능하지만, 이 프로토콜의 진짜 의미는 에이전트에 배포되고 일관된 표준을 거친다는 것, 인증이 통일된다는 것, 그리고 승인·변경·알림까지 AI 호스트와 실제로 상호작용한다는 데 있습니다. 그중에서도 인증이 통일된다는 점이 특히 중요한 포인트입니다.
실전 가이드: 지금 무엇을 확인해야 할까
이번 명세 변경에 대응하려면 다음 순서로 점검해보길 권합니다.
- 현재 사용 중이거나 운영 중인 MCP 서버가 2026-07-28 스테이트리스 명세를 지원하는지 확인합니다. 특히 자체 매뉴얼이나 사내 API를 MCP로 감싸 제공하고 있다면, 레거시 스테이트풀 방식으로만 동작하고 있지 않은지부터 점검해야 합니다.
- 클로드 코드, 커서 등 사용 중인 에이전트 클라이언트 도구를 최신 버전으로 업데이트합니다. 클라이언트가 새 명세를 지원하지 않으면 서버를 아무리 스테이트리스로 바꿔도 정상 작동하지 않을 수 있으니, 자동 업데이트가 켜져 있는지 확인하는 것이 좋습니다.
- 직접 MCP 서버를 운영하고 있다면, 에이전트에게 “새 명세가 작동하도록 업데이트하고, 테스트용 MCP로 전부 검증해서 스테이트리스로 호환되게 만들어라”라고 맡겨 전환 작업을 위임해볼 수 있습니다. 다만 검증 결과는 반드시 재확인하는 절차를 거치는 것이 안전합니다.
비판적으로 볼 점
스테이트풀 방식이 왜 문제였는지를 서브 에이전트 20개, 시스폴리시티D CPU 점유율 같은 구체적인 실사례로 체감시켜준 점은 인상적입니다. 사이먼 윌리슨의 실제 비교 설명을 인용해 HTTP 요청이 두 번에서 한 번으로 줄어드는 구조 변화를 명확히 짚은 점도 신뢰를 더합니다.
다만 하위 호환성 문제에 대한 구체적인 마이그레이션 가이드나 클라이언트별 지원 현황까지는 다루지 않기 때문에, 실제로 어떤 도구가 언제 새 명세를 지원할지는 직접 확인해야 합니다. 또한 “새 명세 대응 개발은 30분이면 될 것”이라거나 시장이 자연스럽게 구형 지원 업체를 도태시킬 것이라는 전망은 다소 낙관적인 예측이라는 점을 감안하고 받아들일 필요가 있습니다. 슈퍼베이스나 버셀 같은 CLI를 실제 서비스에 연동해 쓰는 경우라면, 전환 과정에서의 이중 검증은 별도로 신경 써야 할 부분입니다.
핵심 요점 5가지
- 앤트로픽이 2026년 7월 28일 발표한 새 MCP 명세의 핵심은 스테이트풀에서 스테이트리스로의 전환이며, 이로 인해 배포 유연성·개발 단순화·확장성이라는 세 가지 장점이 생겼습니다.
- 기존 스테이트풀 방식은 서브 에이전트마다 MCP 연결을 유지해야 해서(예: 서브 에이전트 5개 × MCP 4개 = 20개 연결) 리소스 낭비와 시스폴리시티D의 CPU 과다 점유 같은 문제를 낳았지만, 스테이트리스 전환으로 이 문제가 해결됩니다.
- 요청-응답 구조가 HTTP 요청 두 번(세션 초기화+도구 호출)에서 한 번으로 줄면서 구현 복잡도가 크게 낮아졌고, AWS 람다나 클라우드플레어 워커스 같은 서버리스 인프라에 저비용으로 배포할 수 있게 됐습니다.
- 가장 큰 단점은 레거시 MCP와 하위 호환이 전혀 안 된다는 점으로, 서버 쪽 전환은 어렵지 않지만 클로드 코드·커서 등 클라이언트 도구가 새 버전을 언제 지원할지가 실제 도입의 관건입니다.
- MCP는 API를 대체하는 기술이 아니라 USB나 JDBC처럼 서로 다른 API·데이터·로컬 기능을 다양한 AI 애플리케이션이 공통으로 발견하고 호출하도록 만드는 표준이며, 특히 인증이 통일된다는 점이 핵심 가치입니다.
참고자료
- Simon Willison, “Stateless MCP has recaptured my interest” — https://simonwillison.net/2026/Jul/31/stateless-mcp/
- MCP 공식 블로그, “The 2026-07-28 Specification” — https://blog.modelcontextprotocol.io/posts/2026-07-28/
원본 영상 게시일: 2026-09-02 / 채널: 김플립 – LLM 코딩. 본 글은 영상 자막을 기반으로 작성되었으며, 자막에 없는 외부 정보는 추가하지 않았습니다.