Model Context Protocol의 출시 이후 가장 큰 규모의 개정판이 오늘 출시됩니다. 2026-07-28 스펙은 상태가 없는 (stateless) 프로토콜 코어를 확정하고, 장시간 실행되는 작업을 재설계된 Tasks 확장 기능으로 이동시키며, 서버 렌더링 UI를 위한 MCP Apps를 도입하고, 6개의 SEP 패키지를 통해 권한 부여 (authorization)를 강화합니다. 출시 후보(release candidate) 버전은 5월 말부터 공개되었으며, Tier 1 SDK들은 검증 기간 내에 지원이 도입될 예정입니다. 만약 원격 MCP 서버를 운영 중이라면, 여러분의 인프라는 방금 극적으로 단순해졌습니다. 더 이상 스티키 세션 (sticky sessions)이나 공유 세션 저장소 (shared session store)가 필요 없으며, 일반적인 라운드 로빈 (round-robin) 로드 밸런싱과 캐시 가능한 tools/list 응답을 사용할 수 있습니다.

이것은 진정으로 훌륭한 엔지니어링입니다. 또한 여러분이 이미 겪고 있는 문제를 훨씬 더 악화시키기 직전이기도 합니다.

상태가 없는 (stateless) 코어가 실제로 바꾸는 것

이전 스펙 하에서 원격 MCP 서버는 상태가 있는 (stateful) 것이었습니다. 세션은 고정(pinned)되어야 했고, 게이트웨이는 올바른 라우팅을 위해 심층 패킷 검사 (deep packet inspection)가 필요했으며, 수평적 확장 (horizontal scaling)을 위해서는 세션 저장소 (session-store)를 다루는 복잡한 작업이 필요했습니다. 이러한 마찰은 조직이 에이전트에게 얼마나 많은 도구 (tools)를 노출할지에 대한 자연스러운 속도 제한기 (rate limiter) 역할을 했습니다. 새로운 MCP 서버를 구축하는 것 자체가 팀들이 두 번 생각하게 만들 정도로 많은 작업이었습니다.

2026-07-28 스펙은 이러한 마찰을 거의 완전히 제거합니다. Mcp-Method 헤더를 기반으로 라우팅하고, 라운드 로빈 로드 밸런서 뒤에 위치하며, 클라이언트가 서버가 허용하는 ttlMs에 따라 도구 목록을 캐싱하는 상태가 없는 (stateless) 서버 — 이는 어떤 플랫폼 팀이라도 오후 한나절이면 실행할 수 있는 배포 시나리오입니다. 확장 기능 (Extensions) 프레임워크는 Tasks 및 Apps와 같은 기능들이 코어를 비대하게 만드는 대신 깔끔하게 구성될 수 있음을 의미합니다. 공식적인 지원 중단 (deprecation) 정책은 기업들이 발밑의 지면이 흔들릴 걱정 없이 마침내 MCP를 기반으로 구축할 수 있음을 의미합니다.

따라서 아무도 계산에 넣지 않고 있는 2차 효과는 다음과 같습니다: 도구 카탈로그 (tool catalogs)가 폭발적으로 증가할 것입니다.

서버를 배포하기 저렴하고, 상태 비저장(stateless)으로 확장 가능하며, 의존해도 안전하다면, 모든 내부 API가 MCP 서버가 됩니다. 모든 SaaS 공급업체가 하나씩 출시할 것입니다. 오늘날 15개의 도구 중에서 선택하는 에이전트는 연말에는 150개 중에서 선택하게 될 것입니다. 그리고 도구 선택 — 어떤 도구를 호출할지, 어떤 인수를 사용할지, 어떤 순서로 호출할지 결정하는 것 — 은 카탈로그가 작았을 때조차 대부분의 에이전트 시스템에서 이미 가장 약한 고리였습니다.

프로토콜 자체가 병목은 아니었다

MCP가 무엇을 해결하고 무엇을 해결하지 못하는지에 대해 정확하게 아는 것이 중요합니다. MCP는 에이전트가 도구를 발견하고 호출하는 _방식_을 표준화합니다: 와이어 형식(wire format), 핸드셰이크(handshake), 기능 협상(capability negotiation)입니다. 이것은 에이전트가 올바른 도구를 호출하는지에 대해서는 아무것도 말해주지 않습니다.

이러한 구분은 프로토콜 마일스톤을 둘러싼 흥분 속에서 묻히기 쉽습니다. 저는 팀들이 MCP 통합이 엔드투엔드로 작동하는 것을 축하하다가, 실제 운영 환경에서 자신들의 에이전트가 다음과 같은 상황에 처해 있음을 조용히 발견하는 것을 지켜봤습니다:

• 사용자가 인보이스(invoices)에 대해 물었는데도 search_orders 도구를 호출하는 경우. 이는 도구 설명이 중복되고 모델이

여기 불편한 부분이 있습니다. 오늘날의 최첨단 모델(frontier models)에서 함수 호출 및 도구 사용 기능은 주로 작고 깨끗한 도구 세트—예를 들어, 소수의 잘 구별되는 함수가 있는 BFCL 변형 벤치마크, 합성 API 환경, 선별된 데모—로 학습되고 평가되었습니다. 이러한 데이터는 모델에게 도구 사용의 _문법(syntax)_을 매우 잘 가르쳤습니다. 현대의 모델들은 이제 잘못된 형식의 도구 호출을 거의 내보내지 않습니다.

하지만 이 데이터가 가르치지 못한 것, 즉 대규모로 존재하기 어려운 것은 _대형 카탈로그 내 근접 중복 도구 간의 구별 능력_입니다. MCP 클라이언트가 수십 개의 서버를 집계하여 모델에게 모두

2. 도구 호출 후보(tool-call candidates)에 대한 선호도 데이터. 파인튜닝(fine-tuning)이나 RLHF 스타일의 최적화를 위해서는 쌍별 판단(pairwise judgments)이 필요합니다. 즉, 주어진 컨텍스트에서 tool_A(args_x)를 호출하는 것이 tool_B(args_y)보다 나은지 여부를 판단해야 합니다. 이러한 판단은 종종 도메인 전문 지식을 요구합니다. 귀사의 청구 시스템을 이해하지 못하는 라벨러는 해당 시스템에 대한 도구 호출 순위를 매길 수 없습니다. 일반적인 크라우드소싱으로는 이 부분이 어렵습니다. API 스키마를 읽고 부작용(side effects)에 대해 추론할 수 있는 주석 작성자(annotators)가 필요합니다.

3. 실제 카탈로그를 반영하는 평가 세트. 공개 벤치마크는 귀사의 150개 도구, 귀사만의 명명 규칙, 그리고 귀사 고유의 중복 기능을 가진 에이전트가 어떻게 작동할지 알려주지 못합니다. 자체 도구 정의로부터 구축된 비공개 평가 세트(held-out eval sets)가 필요합니다. 여기에는 근접 중복 도구를 포함한 적대적 사례(adversarial cases), 명세가 불충분한 사용자 요청, 그리고 최적으로 알려진 경로를 가진 다단계 워크플로우가 포함됩니다. 이러한 항목들을 대규모로 일관되게 점수화하는 것 자체가 하나의 전문 분야입니다. 즉, 루브릭 설계, 주석 작성자 간 합의(inter-annotator agreement), 모델 버전 전반에 걸친 회귀 추적(regression tracking) 등이 해당합니다. 이것이 바로 모델 평가 및 QA가 일회성 출시 전 연습이 아니라 성숙한 에이전트 팀에서 필수적인 기능이 된 이유입니다.

마이그레이션 기간을 위한 실질적인 시사점

만약 2026-07-28 사양으로의 이동을 계획하고 있다면, 표준 마이그레이션 체크리스트에 다음 내용을 추가할 것을 제안합니다:

도구 호출(tool calls)뿐만 아니라 도구 선택 결정(tool-selection decisions)을 기록하세요. 대부분의 원격 측정(telemetry)은 에이전트가 무엇을 호출했는지 포착합니다. 에이전트가 무엇을 호출할 수 있었는지 — 즉, 각 단계에서 제시된 전체 후보 세트를 기록해야 합니다. 이것 없이는

도구 설명을 프롬프트처럼 감사(Audit)하세요. 왜냐하면 실제로 프롬프트이기 때문입니다. 캐싱 가능한 tools/list 응답을 통해, 귀하의 설명은 대규모로 소비될 것입니다. 거의 중복되는 설명은 선택 오류(selection errors)의 가장 큰 원인입니다. 적대적(adversarially)으로 작성하세요. 만약 두 설명이 동일한 요청에 그럴듯하게 매칭될 수 있다면, 모델은 결국 이들을 혼동할 것입니다.

단순한 구축이 아니라, 수정을 위한 예산을 책정하세요. 팀들은 MCP 서버를 구축하는 데는 정기적으로 엔지니어링 예산을 할당하지만, 에이전트가 이를 잘 사용하게 만드는 어노테이션(annotation) 작업에는 예산을 전혀 할당하지 않습니다. 저희가 확인한 합리적인 시작 비율은 다음과 같습니다: 10개의 도구를 노출할 때마다, 첫 분기에 수백 개의 프로덕션 궤적(production trajectories)을 검토하는 예산을 책정하십시오. 이를 앞당겨 수행하십시오. 사용자가 에이전트를 불신하게 됨에 따라 선택 오류는 복리로 쌓이게 됩니다.

Tasks 확장을 평가 표면(eval surface)으로 취급하세요. 장시간 실행되는 작업(long-running operations)은 침묵하는 실패(silent failures)가 숨어 있는 곳입니다. 작업이 Tasks로 이동하면, "에이전트가 태스크 상태를 올바르게 폴링(poll), 재개(resume), 그리고 조정(reconcile)했는가"가 기존 평가(evals)에는 존재하지 않았던 새로운 실패 클래스가 됩니다. 사용자가 직접 찾아내기 전에 이를 위한 테스트 케이스를 구축하십시오.

매력적이지 않은 결론

프로토콜 표준화는 생태계가 확장되는 방식이며, 2026-07-28 스펙은 MCP가 성장했음을 보여줍니다: 상태 비저장(stateless), 확장 가능(extensible), 엔터프라이즈 준비 완료(enterprise-ready).

하지만 배관(plumbing) 작업이 쉬워질 때마다, 차별화 요소는 스택의 상위 계층으로 이동합니다. 2024년에는 모델을 도구에 연결하는 것 자체가 어려운 부분이었습니다. 2025년에는 오케스트레이션(orchestration)이 문제였습니다. 오늘날 기준으로, 연결과 오케스트레이션은 대체로 해결된 문제입니다. 이는 데모가 잘 되는 에이전트와 실제로 출시되는 에이전트 사이의 격차가 이제 거의 전적으로 그 뒤에 있는 데이터, 즉 수정된 궤적(corrected trajectories), 전문가 선호도 레이블(expert preference labels), 그리고 프로덕션과 유사한 평가 세트(evaluation sets)의 함수라는 것을 의미합니다.

프로토콜은 완성되었습니다. 데이터셋은 아직 아닙니다.

저는 SyncSoft.AI에서 근무하고 있으며, 이곳의 베트남 팀은 AI 연구소와 제품 팀을 위한 추론 (reasoning), 인간 피드백 (human-feedback), 그리고 평가 데이터셋 (evaluation datasets)을 구축합니다. 만약 이번 분기 로드맵에 도구 사용 (tool-use) 품질이 포함되어 있다면, 언제든 의견을 나누고 싶습니다. 편하게 연락하시거나 저희의 사례 연구 (case studies)를 살펴보시기 바랍니다.