지난 7월 28일, MCP(Model Context Protocol) 스펙의 새 버전 2026-07-28이 확정됐습니다. MCP 공개 이후 가장 큰 개정으로, 변경 이력(changelog)에 굵직한 변경만 9건이 올라와 있습니다. 클로드 코드(Claude Code)나 커서(Cursor) 같은 코딩 에이전트에 MCP 서버를 붙여 쓰는 환경에 직접 해당하는 내용들입니다.

다행히 오늘 당장 MCP 설정을 바꾸지 않는다고 해서 기존 동작에 문제가 생기는 건 아닙니다. 공식 발표도 “기존 클라이언트와 서버는 오늘도, 7월 28일에도 문제없이 동작한다(nothing breaks today, and nothing breaks on July 28 either)”라고 분명하게 밝혔습니다.

하지만, 변경의 폭이 넓어 스테이트리스(stateless) 전환이라는 헤드라인 하나만 보고 넘어가면 중요한 내용들을 놓치기 쉽습니다. 그런 만큼 이 글에서는 이번 개정의 변화 전체를 6개로 나누어 하나씩 설명하고, 지금 MCP를 쓰고 있는 사용자라면 무엇을 알아두고 무엇을 결정해야 하는지 정리해 보겠습니다.

MCP 개편 항목 한눈에 보기

우선 공식 변경 이력의 항목들을 성격에 따라 다음 6가지로 구분하여 표로 정리해 볼 수 있습니다.

스테이트리스 코어를 중심으로 통신 방식·인프라·인증·확장 프레임워크·기능 정리 6개 카드로 나눈 MCP 개정 요약 카드형 다이어그램 — *2026-07-28 개정의 변화 전체: 6가지 분류 <출처: 작가>*

참고로 MCP는 앤트로픽(Anthropic)이 만들었고 2025년 12월부터 리눅스 재단 산하 AAIF(Agentic AI Foundation, 에이전틱 AI 재단)에 기부되어 중립 재단 아래에서 관리되고 있습니다. 이번 릴리스는 그 체제에서 나온 첫 대규모 개정이며 릴리스 후보(RC, Release Candidate)가 5월 21일에 나와 10주의 검증 기간을 거쳐 확정됐습니다.

그러면 6가지 주요 변화를 하나씩 함께 보겠습니다.

1. 스테이트리스 코어: 세션이 사라진 이유와 방식

가장 큰 변화로, 이로 인해 나머지 변화들이 생겼다고 볼 수 있습니다.

기존 핸드셰이크 구조의 문제

기존 MCP에서 클라이언트(코딩 에이전트)와 서버(도구 제공자)는 요청을 주고받기 전에 확인 절차부터 거쳤습니다. 즉, 클라이언트가 initialize 요청으로 “나는 이런 기능을 지원한다”라고 알리면 서버가 세션(session) ID를 발급해 돌려주는 핸드셰이크(handshake) 구조였습니다. 이후 모든 요청에는 Mcp-Session-Id 헤더로 발급받은 세션 ID를 함께 보내야 했습니다.

물론 이 구조를 쓴다 해도 로컬에서 서버를 1개 띄웠을 경우에는 문제가 되지 않습니다. 하지만 원격에 여러 대로 늘려 운영하는 순간, 문제가 생깁니다. 세션이 특정 서버에 묶여 있다 보니 요청 분배와 장애 복구에서 문제가 일어날 수 있습니다. 특히, 같은 클라이언트의 요청은 세션을 기억하는 서버 인스턴스로만 보내야 하므로 일반 로드밸런서(load balancer)의 라운드로빈 분배 대신 스티키 세션(sticky session) 같은 장치가 필요했습니다. 결국 그 인스턴스가 죽으면 세션도 함께 사라졌습니다.

여기에 세션을 만들고 관리하고 나중에 정리하는 코드까지 서버 개발자가 직접 구현해야 하다 보니 버그와 메모리 누수로 이어지는 경우도 많았습니다. 스펙 개선 제안 문서인 SEP-2575(Specification Enhancement Proposal)를 보면, 이러한 문제들이 많이 등장합니다.

MCP 코어 메인테이너인 MS 개발자 케이티 맥카프리(Caitie McCaffrey)의 릴리스 직후 인터뷰에 따르면, 호스트마다 세션 기능의 구현 방식이 제각각이거나 아예 올바르지 않아 상태 유지가 프로토콜에서 제대로 작동한 적이 없었다고 합니다. 실제 사용 사례의 약 90%는 그 기능을 쓰지도 않았다고 합니다. 그래서 이번 2026-07-28 개정이 이 문제들을 해결했습니다.

새로운 스펙이 문제를 해결한 방법

그렇다면 새로운 스펙은 이 문제를 어떻게 풀었을까요?

답은 “처리에 필요한 정보를 요청 하나에 전부 담는다(self-contained)”입니다. 매 요청의 _meta 필드에 프로토콜 버전과 클라이언트 기능 목록이 필수로 실립니다. 어떤 서버 인스턴스가 받아도 그 요청 하나만 보고 독립적으로 처리하도록 했습니다. 서버 정보가 궁금하면 server/discover라는 요청으로 지원 버전과 기능을 물어볼 수 있고, 이 요청은 모든 서버가 반드시 지원하게 됩니다.

좌측은 클라이언트가 initialize로 세션ID를 받아 서버 1에만 요청을 보내는 구조, 우측은 매 요청에 _meta를 담아 로드밸런서가 서버 1·2·3에 독립 처리하는 구조를 도식화 — *세션 기반(구 스펙) 요청 흐름과 스테이트리스(신 스펙) 요청 흐름 비교 <출처: 작가>*

변경에 따른 두 가지 오해

두 가지 오해를 짚고 넘어가는 게 좋겠습니다. 첫째, 세션이 없어졌다고 해서 상태 자체가 금지된 것은 아닙니다. 장바구니처럼 여러 호출에 걸친 상태가 필요한 서버는, 생성 도구가 basket_id 같은 명시적 핸들(handle)을 돌려주고 이후 호출마다 그 식별자를 인자로 받는 방식으로 바뀌게 됩니다. 기존에는 이러한 상태가 전송 계층에서 세션으로 관리되어 모델이 그 존재를 보기 어려웠습니다. 그러나 이제는 핸들 방식으로 변경되면서 도구의 인자와 반환값처럼 모델이 직접 볼 수 있는 데이터 형태로 오갑니다.

둘째, 끊긴 스트림을 이어받는 재개(resumability) 기능도 함께 사라졌습니다. 스트림을 이어받으려면 서버가 직전까지 보낸 내용을 기억하고 있어야 하는데, 상태를 남기지 않는다는 새 원칙과 맞지 않기 때문입니다. 응답 스트림이 끊기면 클라이언트는 새 요청으로 다시 시도해야 하고, 오래 걸리는 작업은 뒤에서 설명할 Tasks 확장이 담당하게 됐습니다.

왜 기존 방식과 호환되는 방식을 선택하지 않고 전면적인 개정으로 진행하게 되었을까요? 두 상호작용 모델을 병행하면 프로토콜과 모든 구현체가 두 벌의 로직을 만들고 유지해야 해서 복잡도와 버그 여지가 커집니다. 그래서 메인테이너들은 한 번에 정리하는 쪽이 생태계 전체에 낫다고 판단했습니다. (보다 상세한 내용은 SEP-2575 문서에 기록되어 있으니 참고하시기 바랍니다.)

2. 통신 방식 변경: 서버가 더 이상 클라이언트를 호출하지 않음

세션이 사라지면서 서버가 클라이언트와 연결을 계속 유지한다는 전제도 사라졌기 때문에, 통신 방식도 함께 달라졌습니다.

기존에는 서버가 역으로 클라이언트에 요청을 보낼 수 있었습니다. 도구 실행 중에 사용자 입력을 요청하는 엘리시테이션(elicitation)이 대표적입니다. 신 스펙에서 서버는 JSON-RPC 요청을 시작할 수 없도록 했고 이런 상호작용은 MRTR(Multi Round-Trip Requests, 다중 왕복 요청)이라는 패턴으로 바뀌었습니다. 서버가 클라이언트를 직접 호출하는 대신 “추가 입력이 필요하다”는 중간 결과를 돌려주면 클라이언트가 입력을 채워 원래 요청을 다시 보내는 방식입니다. 이때 서버는 진행 상태를 requestState라는 문자열로 내보내고 클라이언트가 그대로 돌려줍니다.

그런데 이 값은 클라이언트를 거쳐 돌아오기 때문에, 서버가 보낸 그대로라는 보장이 없습니다. 그래서 스펙은 이 값을 믿지 말고 외부에서 온 입력처럼 검증하도록 명시합니다. 인가나 비즈니스 로직에 영향을 준다면 HMAC(Hash-based Message Authentication Code, 해시 기반 메시지 인증 코드) 같은 무결성 보호가 필수입니다. SDK가 이를 위한 도구를 제공합니다.

[노트] 엘리시테이션(elicitation)이 무엇인가요?

서버가 도구를 실행하다가 사용자에게 추가 입력이나 확인을 요청하는 기능입니다.
예를 들어 배포 도구가 실행 도중에 “어느 환경에 배포할까요?”라고 물어보고 답을 받아 이어가는 상호작용이 여기에 해당합니다.

서버에서 클라이언트로 가는 통신에는 응답을 요구하는 요청 말고도 일방적으로 알려주기만 하는 알림이 있는데, 이 알림 채널도 하나로 합쳐졌습니다. 기존에는 알림을 받는 통로가 2개여서, 서버가 보내는 일반 알림은 클라이언트가 HTTP GET으로 열어 둔 상시 연결로 받고 리소스 변경 알림은 별도의 구독 요청으로 신청했습니다. 게다가 서버가 아무 때나 일방적으로 알림을 보낼 수 있어서 클라이언트는 쓰지도 않을 알림까지 받아서 처리해야 했습니다. 서버도 어느 클라이언트가 듣고 있는지를 세션 상태로 관리해야 했습니다.

신 스펙은 이 둘을 subscriptions/listen이라는 단일 스트림으로 통합하고 받고 싶은 알림 종류(도구 목록 변경 등)를 클라이언트가 명시적으로 신청하는 옵트인 방식으로 정리했습니다. 이제 클라이언트는 신청한 알림만 받고, 서버는 신청받은 알림만 처리해서 보냅니다.

3. 인프라 친화적 개선: HTTP 헤더와 캐시 표준화로 운영 부담을 줄임

운영하는 쪽에 이득이 집중된 변화입니다. 이제 Streamable HTTP 요청에는 어떤 메서드인지(Mcp-Method), 어떤 도구를 호출하는지(Mcp-Name)가 HTTP 헤더로 필수로 실리도록 했습니다. 게이트웨이나 로드밸런서가 요청 본문(JSON)을 뜯어보지 않고도 특정 도구 호출만 골라서 다른 경로로 보내거나 차단하거나 기록하는 일을 할 수 있게 된 것입니다. 실제로 깃허브(GitHub)는 자사 MCP 서버를 신 스펙으로 옮기면서 본문 검사(deep packet inspection) 없이 헤더 기반 라우팅으로 바꿨다고 밝혔습니다.

캐시 규칙도 표준화됐습니다. 도구 목록(tools/list) 같은 조회 결과에는 캐시 유효 시간 힌트인 ttlMs와 공유 캐시 허용 여부인 cacheScope가 필수로 붙게 됐습니다. 목록이 연결마다 달라지는 것도 금지되어 같은 서버라면 누가 물어도 같은 목록이 나오는 캐시 가능한 구조를 전제로 삼았습니다. 여기에 요청이 여러 구성 요소를 거칠 때 하나의 흐름으로 이어서 추적하는 분산 추적도 오픈텔레메트리(OpenTelemetry) 기준으로 연동 방법이 문서화됐습니다. 이제 MCP 트래픽을 일반 웹 트래픽처럼 관리 도구로 다룰 수 있습니다.

4. 인증과 보안 강화: OAuth 실전 배포에 맞게 다듬음

원격 MCP 서버의 인증 계층도 여러 곳이 수정되었습니다. 고친 항목 하나하나는 작은 기술적 수정이지만 기업의 실제 OAuth·OIDC(OpenID Connect) 배포 환경에서 통용되게 만든다는 점에서는 모두 동일한 방향성을 가지고 있습니다.

특히, 인가 응답에 발급자(issuer) 정보를 실어, 응답을 보낸 인가 서버가 클라이언트 자신이 요청했던 서버와 같은지 확인하게 하는 요건이 더해졌습니다. 공격자가 서로 다른 인가 서버의 응답을 뒤섞어 인가 코드를 가로채는 경로를 막기 위한 것입니다. 또한 클라이언트 자격 증명은 발급한 서버에만 쓸 수 있게 묶어 다른 서버에 재사용하지 못하게 했습니다.

사실 가장 눈에 띄는 변화는 클라이언트 등록 방식입니다. 그동안 쓰이던 동적 클라이언트 등록(DCR, Dynamic Client Registration)은 더 이상 사용을 권고하지 않는 상태(deprecated)로 변경되었습니다. 당장 지원이 끊기는 것은 아니고 기존 환경과의 호환을 위해 당분간 유지되지만 새로 만드는 구현에서는 쓰지 말라는 뜻입니다. 그 대신 HTTPS URL 자체가 클라이언트 ID가 되는 CIMD(Client ID Metadata Documents, 클라이언트 ID 메타데이터 문서)가 권장 방식으로 지정됐습니다. 클라이언트가 자기 메타데이터를 URL로 게시하면 어떤 인가 서버에서든 재등록 없이 통하는 방식입니다.

개인이 로컬에서 stdio 방식으로 서버를 쓰는 경우에는 이 인가 스펙이 적용되지 않으니, 원격 HTTP 서버를 만들거나 운영하는 쪽에서 대응해야 하는 내용이라고 보면 됩니다.

5. 확장 프레임워크: 코어는 작게, 나머지는 확장으로

이번 개정의 설계 방침이 잘 드러나는 변화입니다. 코어 프로토콜에는 extensions 필드가 추가되어 클라이언트와 서버가 각자 지원하는 확장을 이 필드로 알립니다. 코어에 지금 담지 않기로 한 기능들은 공식 확장으로 분리하고 버전을 따로 매겨 관리하는 형태가 되었습니다. 쿠버네티스가 코어 API 밖에서 Gateway API 같은 프로젝트를 별도 버전으로 발전시켜 온 것과 비슷한 관리 방식이라고 볼 수 있습니다.

Tasks: 오래 걸리는 작업 처리가 코어의 실험 기능에서 공식 확장(io.modelcontextprotocol/tasks)으로 이동했습니다. 서버가 작업 핸들을 돌려주면 클라이언트가 폴링(polling, 주기적으로 상태를 물어보는 방식)으로 진행 상황을 확인하고 접속이 끊겼다 돌아와도 결과를 받아갈 수 있습니다. 스트림 재개가 사라진 부분을 대신하는 기능이기도 합니다.
MCP Apps: 서버가 채팅 화면 안에 렌더링되는 대화형 UI를 제공할 수 있게 하는 확장입니다.
EMA(Enterprise-Managed Authorization, 기업 관리형 인가): 이번 개정과 묶여 자주 언급되는 기업용 인증 확장인데, 실제로는 이번 코어 스펙의 일부가 아니라 별도 확장으로 이미 6월에 안정화됐습니다. 이 구분이 매우 중요한 이유는, 스펙을 따라가는 일과 EMA를 도입하는 일이 서로 별개의 결정이기 때문입니다. 이를테면 직원이 회사의 IdP(Identity Provider, Okta 같은 신원 제공 서비스)에 한 번 로그인하면 서버마다 개별 동의 화면을 거치지 않고 회사가 승인한 MCP 서버들이 연결되는 방식입니다. IdP·클라이언트·서버 삼자가 모두 지원해야 동작하는 옵트인 기능이기에, 개인 사용자와는 무관합니다. 사내 MCP 접근 통제를 고민하는 조직이 지켜볼 영역입니다.

확장은 전부 선택 사항이고 기본으로 꺼져 있습니다. 코어를 가볍게 유지하면서 필요한 조직만 필요한 확장을 켜는 구조입니다.

6. 기능 정리와 수명주기: 세 기능이 제거 수순에 들어감

마지막은 기능을 덜어내는 변화입니다. Roots, Sampling, Logging 세 기능이 더 이상 사용을 권고하지 않는 상태가 됐습니다. 지금은 동작하지만 신규 구현에는 넣지 말라는 의미입니다. 각 기능이 하던 일과 스펙이 제시한 대안을 정리하면 다음과 같습니다.

제거 예정 기능 3종 비교표: Roots(작업 디렉터리 공유→도구 파라미터·설정으로 경로 전달), Sampling(서버가 클라이언트 LLM 호출 대리→LLM 제공자 API 직접 호출), Logging(프로토콜 차원 로그 전달→표준 에러 출력 또는 오픈텔레메트리)

이번에는 이렇게 기능을 정리하는 절차 자체도 정해진 규칙을 따르게 되었습니다. 기능이 이 상태로 지정되면 최소 12개월은 유지된 뒤에야 제거될 수 있다는 수명주기 정책이 정식 문서로 만들어진 것입니다. 따라서 위 세 기능은 적어도 2027년 7월 28일까지는 그대로 유지되며 실제 제거는 그 이후에 나오는 첫 리비전에서야 가능합니다. 그 시점이 되어도 자동으로 제거되는 것은 아니고 메인테이너가 릴리스를 준비하며 결정하는 것이라 더 늦어질 수도 있습니다.

그에 반해 2024년 말의 초기 전송 방식인 HTTP+SSE(Server-Sent Events)는 정리 절차가 훨씬 앞서 있습니다. 아직 이 방식을 쓰고 있다면 가장 시급한 이전 대상입니다. 그러면 구 스펙(2025-11-25) 자체는 언제까지 지원될까요? 아쉽게도, 종료일은 명시되어 있지 않습니다. 수명주기 정책이 리비전이 아니라 기능 단위로 적용되기 때문입니다.

그래서 지금, 사용자 유형별로 해야 할 일

그럼 이제부터 각자의 자리에서 무엇을 하면 되는지 정리해 보겠습니다.

MCP 서버를 붙여 쓰는 사용자

원칙적으로 할 일이 없습니다. 버전 협상, 그리고 신 스펙이 통하지 않는 상대를 만나면 기존 방식으로 자동 전환해 다시 시도하는 폴백(fallback)은 클라이언트와 SDK가 처리합니다. 깃허브도 자사 MCP 서버를 전환하면서 “사용자는 아무것도 할 필요가 없다”라고 얘기했습니다.

하지만 예외가 두 가지 있을 수 있습니다. 하나는 설정에 SSE 전송을 명시적으로 고정해 둔 경우로, 클라우드플레어(Cloudflare)는 자동 감지나 Streamable HTTP로 바꾸라고 안내됩니다. 다른 하나는 회사 내부 MCP 서버가 세션에 상태를 묶어 두는 경우입니다. 접속 시점 헤더로 받은 테넌트(tenant) 정보를 세션에 저장해 쓰는 유형의 서버라면 신 스펙 환경에서 동작이 어긋날 수 있습니다. 실제로 전환 시점 전후 이런 유형으로 추정되는 동작 이상 보고도 올라왔습니다.

추가로 이 글을 작성하는 시점(8월 5일) 기준으로도 클라이언트 쪽은 공개된 정보가 부족하다는 점을 알아두면 좋겠습니다. 서버와 플랫폼에 대한 지원과 관련된 내용은 많이 나왔지만 앤트로픽은 “클로드 제품군에 순차 적용 중”이라고만 밝혔고 커서의 변경 이력에는 관련 언급이 아직 없습니다. 오픈AI 코덱스(Codex) CLI는 기능 플래그 등록에 이어 일부 기반 코드를 넣는 단계라, 어느 클라이언트가 어느 버전부터 신 스펙을 지원하는지 정리된 표는 아직 없습니다.

서버를 만드는 개발자

마이그레이션을 실제로 계획해야 하는 시점입니다.

우선 스펙 확정과 같은 시기에 주요 SDK 안정 버전이 나왔습니다. 파이썬은 mcp 2.0.0이 릴리스 당일 나왔습니다(이제 pip install mcp가 2.x를 설치하므로, 준비가 안 된 프로젝트는 mcp>=1.28,<2처럼 상한을 거는 것이 공식 권고입니다). 타입스크립트는 기존 @modelcontextprotocol/sdk가 1.x에서 멈추고 @modelcontextprotocol/server 등 새 패키지의 2.0.0으로 나뉘었습니다. 그래서 새로 만드는 MCP 서버라면 처음부터 신 스펙(SDK 2.x)으로 시작하면 되고 구 스펙으로 새로 만들 이유는 없습니다.

다행히 세션 관리 코드는 모두 지워집니다. 실제로 깃허브 MCP 서버를 옮긴 메인테이너 샘 모로우(Sam Morrow)도 얻은 것밖에 없다고 말할 정도입니다.

대신 손이 가는 곳은 세션에 두던 상태를 핸들이나 외부 저장소로 넘기는 일, 엘리시테이션을 MRTR 패턴으로 다시 작성하는 일, 그리고 오래 걸리는 작업을 Tasks 확장으로 옮기는 일입니다. 또, 파이썬 SDK 2.0.0에는 Tasks 확장이 아직 구현되지 않았으므로 장기 작업 의존 서버는 조금 기다려야 합니다. 마지막으로 신/구 클라이언트를 모두 받는 양쪽 지원(dual-era) 운영이 SDK 기본값이므로, 아직 사용자 중에 기존 버전을 사용하는 경우가 있을 수 있으니 그대로 두는 게 더 안전합니다.

배포/운영하는 팀

이번 변경으로 운영 구성이 실제로 단순해집니다. 스티키 세션과 세션 공유 저장소가 필요 없어지고 쿠버네티스(Kubernetes) 서비스 뒤에 평범한 라운드로빈으로 레플리카를 늘리는 구성이 프로토콜 차원에서 성립합니다.

전환 전략으로는 게이트웨이를 앞에 두는 방법이 제시되어 있습니다. 오픈소스 MCP 게이트웨이인 에이전트게이트웨이(agentgateway)는 1.4.0 버전부터 신 스펙을 정식으로 지원합니다. 클라이언트를 일괄 업그레이드하지 않고 게이트웨이 뒤에서 서버만 먼저 올린 뒤 트래픽을 조금씩 옮기는 카나리(canary) 방식이 가능합니다.

마지막으로, 적용 여부를 어떻게 판단하면 될까요? 호환되지 않는 조합은 정해져 있습니다. 신 스펙 전용 클라이언트가 구 스펙 전용 서버를 만나거나 그 반대인 경우만 실패하고 한쪽이라도 양쪽을 지원하면 동작합니다. 따라서 당분간은 양쪽을 다 지원하는 구성이 안전합니다. 강제 전환 시점이 없고 유예도 넉넉하니, 이를 상황별로 정리하면 다음과 같습니다.

MCP 서버 사용자·서버 개발자·배포 운영팀 3열로 나눠 할 일·주의사항·전환 전략을 정리하고, 하단에 구형 HTTP+SSE 전송 사용자에게 최우선 전환을 안내하는 카드형 표 — *사용자 유형과 상황별 권고 정리 <출처: 작가>*

마치며

결국, 이번 개정은 대다수가 쓰지 않던 기능을 걷어내고 웹에서 오래 검증된 스테이트리스 요청 모델로 돌아온 것이 가장 핵심 변화라고 볼 수 있습니다. 이는 즉, MCP가 실험적 프로토콜에서 운영 가능한 인프라로 넘어가는 단계가 된 것이라고 생각합니다.

깃허브와 클라우드플레어는 확정일 전후로 전환을 마쳤고 AWS와 마이크로소프트도 대응 방안을 내놨으니, 방향은 이미 정해진 셈입니다. 물론 이 글은 스펙과 공식 발표, 릴리스 직후 며칠간의 생태계 반응을 기준으로 쓴 것이라, 클라이언트 지원 현황 같은 부분은 앞으로 몇 주 사이에 빠르게 갱신될 수 있습니다. 영향을 크게 받는 분들이라면 꾸준히 커뮤니티를 주목하는 것이 좋겠습니다.

참고로, 저는 이 중에서도 1번 항목인 스테이트리스 전환이 실제 운영 환경에서 어떤 차이를 만드는지가 궁금해졌습니다. 따라서 구 스펙 서버와 신 스펙 서버를 같은 쿠버네티스 클러스터에서 돌려 스케일아웃과 파드 교체 상황을 실측하는 실험을 준비하고 있습니다. “스티키 세션이 필요 없어졌다”는 말이 수치로는 어떻게 나타나는지, 괜찮은 측정 결과가 나온다면 또 소개해 보겠습니다.

참고 자료

MCP 2026-07-28 공식 발표: https://blog.modelcontextprotocol.io/posts/2026-07-28/
스펙 변경 이력(changelog): https://modelcontextprotocol.io/specification/2026-07-28/changelog
SEP-2575 (Make MCP Stateless): https://modelcontextprotocol.io/seps/2575-stateless-mcp
SDK 베타 발표(호환성 정책 포함): https://blog.modelcontextprotocol.io/posts/sdk-betas-2026-07-28/
Arcade.dev 메인테이너 인터뷰: https://www.arcade.dev/blog/mcp-maintainers-interview
GitHub MCP 서버 전환 안내: https://github.blog/changelog/2026-07-23-github-mcp-server-supports-the-next-mcp-specification/

작가

조훈 (CNCF&AAIF 앰버서더)

쿠버네티스 및 AI 네이티브 기술 전문가로, CNCF와 에이전틱 AI 재단(AAIF) 글로벌 앰버서더이자 Kubestronaut이다. 쿠버네티스랩을 운영하며 인프라 자동화 기술을 연구하고 공유한다. ‘IT 인프라 엔지니어 그룹’ 운영진이자 오픈소스 컨트리뷰터로 활동 중이며, 맞춤형 인프라 교육, 쿠버네티스 비용 최적화, 멀티 LLM 및 AI 에이전트 비교 검증 등 다양한 실무 PoC를 수행하고 있다. 최근 출간한 『AI 시대에 개발자가 알아야 할 인프라 구성 배포 with 클로드 코드』를 포함해 총 5권의 IT 서적을 집필했으며, 인프런 강의 및 요즘IT 기고 등 지식 공유 활동을 이어가고 있다.

심근우

LG유플러스 CTO부문에서 대고객 비즈니스 시스템의 DevOps를 담당하는 UcubeDAX팀의 팀장으로 일하고 있다. 퍼블릭 클라우드와 프라이빗 클라우드에 걸친 쿠버네티스 클러스터를 안정적으로 운영하기 위해 노력하고 있으며, 특히 주니어 DevOps 엔지니어들의 육성에 큰 관심을 가지고 있다.

문성주

체커(CHEQUER) 사의 DevOps Engineer로서 쿠버네티스의 멀티 클러스터 관리 방법론과 쿠버네티스 구현체(CAPI, OCI)에 대한 명세와 컨테이너 리소스 격리 방법에 대한 연구를 병행하고 있다. 이런 연구 활동을 기반으로 쿠버네티스 볼륨 테스트 파트에 컨트리뷰션했다. 본업은 쿠버네티스 오퍼레이터와 같은 CRD(커스텀 리소스)를 개발해 현업에서 쿠버네티스를 좀 더 편리하게 사용할 수 있도록 돕는 일이다. 또한, 페이스북 그룹 ‘코딩이랑 무관합니다만'과 ‘IT 인프라 엔지니어 그룹'의 운영진을 맡고 있다.

이성민

미국 넷플릭스(Netflix) 사의 Data Platform Infrastructure 팀에서 사내 플랫폼 팀들과 데이터 사용자들을 어우르기 위한 가상화 및 도구들을 개발하는 일들을 하고 있다. 과거 컨테이너와 쿠버네티스에 큰 관심을 두고 ingress-nginx를 비롯한 오픈 소스에 참여했으며, 현재는 데이터 분야에 일하게 되면서 stateful 한 서비스들이 컨테이너화에서 겪는 어려움을 보다 근본적으로 해결하기 위한 많은 노력을 하고 있다.