세션을 버린다는 것이 무슨 의미일까. AI 에이전트 연계의 기반인 MCP(Model Context Protocol)가 조용하지만 결정적으로 설계 사상을 변경했다.
2026년 7월 28일, Model Context Protocol (MCP)의 새로운 사양 2026-07-28이 공개되었다. 본 기고 작성 시점(2026년 8월 3일)으로 아직 일주일도 지나지 않았다.
제목만 따라가면 '스테이트리스가 되었다'로 끝난다. 하지만 이것은 단순한 최적화가 아니다. MCP라는 프로토콜의 전제가 양방향 스테이트풀(stateful)에서 요청/응답 기반의 스테이트리스(stateless)로 반전된 이야기다. 에이전트를 인프라에 올려 운영해 온 입장에서 보면, '드디어 손을 대는구나' 하는 감회와 '기존 서버 구현은 다시 써야 하겠네'라는 현실감이 동시에 밀려온다.
본 기고에서는 이 사양 변경을 '무엇이 바뀌었는지'뿐만 아니라 '왜 바뀔 필요가 있었는지', 그리고 '실무의 배포 및 운영에 어떻게 적용되는지'까지, 금융권 웹을 주 전장으로 삼아 온 엔지니어의 시점에서 깊이 파헤친다.
⚠️ 본 기고는 공개 직후의 1차 정보(MCP 공식 블로그 · Anthropic/Claude 공식 블로그)를 기반으로 작성되었습니다. 사양의 세부 사항은 향후 드래프트 업데이트로 변경될 수 있으므로, 구현 전에 반드시 공식 사양의 최신 버전을 확인해 주십시오. 헤더 이름 및 필드명은 본 기고 작성 시점의 기재에 근거합니다.
애초에 MCP란 무엇인가 (30초 복습)
MCP는 AI 모델(Claude 등)과 외부 툴/데이터 소스를 연결하기 위한 표준 프로토콜이다. 2024년 말 Anthropic이 공개했으며, 'AI 분야의 USB-C'에 비유되곤 한다.
Tools: AI가 호출할 수 있는 함수 (예: DB 검색, 티켓 생성)
Resources: AI가 읽을 수 있는 데이터 (예: 파일, 레코드)
Prompts: 재사용 가능한 프롬프트 템플릿
이들을 'MCP 서버'로 구현해 놓으면, 대응하는 AI 클라이언트로부터 통일적인 방식으로 호출할 수 있다. 이제 커넥터 생태계는 거대하며, Claude의 커넥터 디렉토리만 해도 950개 이상의 MCP 서버가 늘어서 있다.
문제는 그 통신의 기반이 스테이트풀(stateful)이었다는 점이다. 여기가 이번 이야기의 주인공이다.
구 사양에서 '무거운' 부분이 무엇이었나
2026-07-28
이전 MCP는 양방향·스테이트풀(stateful) 프로토콜이었다. 구체적으로 다음과 같은 전제가 있었다.
클라이언트와 서버는 먼저 initialize / initialized의 핸드셰이크로 세션을 확립한다. 이후 요청은 Mcp-Session-Id 헤더로 해당 세션에 연결된다.
- 서버에서 클라이언트로 능동적으로 호출하는 작업(
sampling/createMessage나 elicitation/create)을 위해 양방향 스트림을 열어둘 필요가 있다.
이것은 '1클라이언트 ⇔ 1서버 프로세스가 대화 내내 연결되어 있는' 모델이다. 로컬의 stdio 연결이나 단일 프로세스로 구동한다면 아무 문제가 없다.
하지만, 이것을 클라우드에서 본격적으로 운영하려 하는 순간 치명적인 약점이 드러난다.
금융권 웹 서비스를 다루다 보면, 가용성(Availability)을 위해 애플리케이션은 반드시 여러 인스턴스로 이중화된다. 로드 밸런서 뒤에 같은 서버가 몇 대나 늘어서게 된다. 여기서 스테이트풀한 세션이 있으면 다음과 같은 문제가 발생한다.
- 요청 A는 1호기에서
initialize했다 → 이후 요청도 1호기에 계속 분배되어야 한다 (Sticky Session) - 또는 세션 상태를 Redis 등의 공유 스토어에 옮긴다 → 공유 스테이트 관리 인프라가 늘어난다 - 서버를 스케일 인/아웃하면, 살아있는 세션이 함께 사라진다.
- 서버리스(Lambda 등)나 엣지(Edge)에 올리고 싶은데, '연결 유지'가 전제라면 올릴 수 없다.
즉, 구 MCP는 '12-Factor App의 스테이트리스 원칙'과 정면으로 충돌하는 구조였다. 에이전트를 본격적인 프로덕션 환경으로 가져가려는 각 기업들이 여기서 발목을 잡히고 있었다.
공식 표현을 빌리자면, “어떤 요청이든 라운드 로빈 로드 밸런서(round-robin load balancer)를 거쳐 어떤 인스턴스에 떨어져도 좋다”는 것입니다. 공유 스토리지나 상태 관리 인프라가 필요 없습니다. 이것이 가져오는 구체적인 변경 사항들을 순서대로 살펴보겠습니다.
변경 1: 세션 폐지
initialize / initialized의 핸드셰이크 교환과, Mcp-Session-Id 헤더가 완전히 제거되었습니다.
그렇다면 기존에 세션 확립 시 교환하던 “프로토콜 버전”, “클라이언트의 정체성”, “클라이언트의 capability”는 어떻게 될까요? 각 요청이 스스로 그것들을 운반하게 되었습니다. 요청마다 _meta 필드에 담아 매번 휴대하는 형태입니다.
【구】 initialize로 세션 확립 → 이후는 Mcp-Session-Id로 연결
(상태는 서버 측 또는 공유 스토어가 보유)
【신】 각 요청이 protocol version / client identity / capabilities를
...
서버 측에서 문맥 정보가 필요할 경우, 트랜스포트 계층의 숨겨진 세션이 아니라, 툴이 반환하는 명시적인 핸들(식별자)을 사용하는 방침으로 바뀌었습니다. 여기서 설계적으로 흥미로운 지점이 있습니다. 핸들이 명시적이게 되면서, AI 모델 자체가 그 식별자를 보고 함수 호출 사이에서 전달할 수 있게 된 것입니다. ‘상태를 숨기는 것’을 멈추고 ‘상태를 값(value)으로 보여주는’ 방향으로 방향을 틀었다는 의미입니다.
변경 2: 헤더 기반 라우팅
Mcp-Method / Mcp-Name 두 개의 헤더가 추가되었습니다. (Streamable HTTP 요청에)
| 헤더 | 역할 |
|---|
Mcp-Method | 작업의 종류(tools/call 등)를 나타냄 |
Mcp-Name | 대상 툴 이름/리소스 이름을 나타냄 |
MCP-Protocol-Version | 2026-07-28처럼 프로토콜 버전을 운반 |
이것의 장점은 무엇일까요? 게이트웨이나 방화벽이 JSON 본문을 파싱하지 않고, 헤더만으로 라우팅과 인증 판단을 할 수 있게 된다는 것입니다.
금융권에서는 여기가 효과적입니다. WAF나 API 게이트웨이 계층에서 페이로드를 열어보지 않고도 “이 툴 호출은 허용, 저건 거부”를 제어할 수 있습니다. 본문의 JSON 파싱을 여러 곳에서 할 필요가 없다는 것은 성능 면에서도 보안 면에서도 당연히 환영할 만한 부분입니다.
변경 3: MRTR — 양방향 스트림 압축
기존 사양에서 양방향 스트림이 필요했던 “서버 측 호출”—사용자에게 추가 입력 요구(elicitation/create)나, 서버로부터의 LLM 호출(sampling/createMessage)—이 MRTR(Multi Round-Trip Requests) 이라는 메커니즘으로 대체되었습니다.
흐름은 다음과 같습니다.
1. 클라이언트 → 서버: 툴을 호출한다
2. 서버 → 클라이언트: resultType:
매개변수）에 대응합니다. 권한 응답이 어느 인증 서버에서 왔는지 검증하여 mix-up 공격을 방지하고, 자격 정보를 특정 인증 서버에 **바인딩**합니다. 동적 클라이언트 등록(DCR) 방식에서 **CIMD(Client ID Metadata Documents)** 기반의 등록으로 전환됩니다.
공식 블로그의 표현으로는, 인증이 “실제 OAuth 2.0 / OIDC 배포 환경과 일치하게” 되었다고 합니다. Entra나 Okta 같은 기존 IdP에 적용하기 쉬워졌다는 이야기입니다. 사내 인증 기반 시설과 MCP 서버를 연결할 때, 이 부분이 표준화되어 있는지 여부는 결재가 통과되기 쉬운 정도와 직결됩니다. 지엽적이지만 실무에서는 큰 문제입니다.
## 비권장(Deprecation) 기능과의 관계 설정
파괴적인 변경이 발생하는 이상, 마이그레이션 유예 기간도 명문화되었습니다. **최소 12개월의 비권장 기간**이라는 정책이 정해졌습니다.
비권장으로 표시된 것은 **Roots / Sampling / Logging / DCR**이며, 레거시인 **HTTP+SSE 전송 방식**입니다. 이들은 당분간 계속 작동하겠지만, **신규 구현에서는 채택해서는 안 됩니다.**
여기서 시니어로서 한마디하겠습니다. “작동하기 때문에” 비권장 기능에 의존한 구현을 새로 늘리는 것은 12개월 후의 나(또는 후임자)에게 빚을 지는 것일 뿐입니다. 마이그레이션 기간은 ‘아직 사용할 수 있는 기간’이 아니라 ‘안전하게 이탈하기 위한 유예’로 읽어야 합니다. 기존 자산은 재고 조사하여, 비권장 목록에 오른 것부터 우선적으로 대체 계획을 세우는 것이 옳다고 생각합니다.
## SDK와 확장 프레임워크
Tier 1의 4가지 SDK인 **TypeScript / Python / Go / C#**가 `2026-07-28`에 대응 완료되었습니다. **Rust**는 베타 지원입니다.
더불어, 코어 로직을 건드리지 않고 기능 추가가 가능한 **버전 관리된 확장 프레임워크**로서 **MCP Apps**(인라인 UI 렌더링)와 **Tasks**(장시간 실행)가 정리되었습니다. 코어는 스테이트리스하고 가볍게 유지하고, 풍부한 기능은 확장을 통해 쌓아 올리는 분리는 건전합니다. 프로토콜의 수명을 연장하는 설계 판단으로서 호감이 갑니다.
## Claude로의 전개
Anthropic은 이 `2026-07-28`을 **Claude 제품군에 “곧” 전개**할 것이라고 밝히고 있습니다(본 기사 작성 시점에는 구체적인 날짜 미발표). 앞서 언급했듯이 커넥터 디렉토리에는 950개가 넘는 MCP 서버가 있으며, 더불어 MCP Apps, 엔터프라이즈 관리 인증, 개발자를 위한 가시성(Observability) 대시보드, 프라이빗 네트워크 연결을 위한 **MCP 터널** 같은 주변 기능들도 갖춰지고 있습니다.
“스테이트리스한 HTTP 워크로드로서, 세션 관리 회피책 없이 일급 시민으로 올릴 수 있게 되었다”—제공자 측이 이렇게 말할 수 있게 된 것이 에코시스템 전체의 운영 난이도를 낮춥니다.
## 실무에 미치는 영향, 레이어별로 정리하기
제가 지금 관여하고 있는 프로젝트에 빗대어 영향을 재고 조사해보니 다음과 같습니다.
| 관점 | 이전 (Stateful) | 현재 (Stateless) | 실무 임팩트 |
|---|---|---|---|
| 배포 | 스티키 세션 필수 | 라운드 로빈으로 충분 | LB 설정이 단순화됨. 이중화가 자연스러워짐 |
| ... |
가장 효과적인 것은 의심할 여지 없이 **배포와 스케일의 단순화**입니다. 이전에는 MCP 서버를 운영 환경에 배치할 때, 늘 마음 한구석에 “세션을 어떻게 처리할까”라는 고민이 있었습니다. 그 부분이 사라집니다. 에이전트를 ‘특별한 연결 유지 프로세스’가 아니라, **단순한 HTTP 워크로드**로 다룰 수 있게 된 의미는 큽니다.
## 마이그레이션 체크리스트 (나를 위한 초안)
기존 MCP 서버를 가지고 있다면, 당분간 이런 관점에서 살펴볼 생각입니다.
-
`initialize`/`initialized`
전제 로직을 파악한다 -
`Mcp-Session-Id`에 의존한 상태 유지가 없는지 확인한다 -
세션에 담아두었던 문맥(Context)을, **도구가 반환하는 명시적 핸들**로 설계 변경할 수 있을지 검토한다 -
`sampling`/`elicitation`
을 사용하고 있는 부분을 **MRTR**로 이전한다 -
목록형 응답에 `ttlMs`/`cacheScope`
를 부여하고, 클라이언트의 캐시 효율을 높인다 - 인증을 CIMD / RFC 9207에 맞춘다 (DCR 의존성에서 이탈)
- 레거시 HTTP+SSE 전송(トランスポート) 의존성을 비권장 창 내에서 대체한다
-
사용 SDK를
`2026-07-28`
대응 버전으로 업데이트합니다
## 요약 — '에이전트가 성숙해지기' 위한 사양
MCP의 스테이트리스(stateless)화는 화려하지 않다. 하지만 **AI 에이전트를 '데모'에서 '실제 분산 시스템'으로 끌어올리기 위한, 현실적인 변경**이다.
양방향 스테이트풀(stateful)은 1대1로 대화할 때는 자연스러운 모델이었다. 그러나 가용성(availability), 스케일(scale), 인증 같은 엔터프라이즈가 당연하게 요구하는 비기능적 요구사항 앞에서는 무거웠다. 이번 반전은 **프로토콜을 웹의 방식(스테이트리스한 HTTP, 헤더를 이용한 라우팅, 표준적인 OAuth/OIDC)에 맞추는** 매우 합리적인 방향 전환이라고 생각한다.
새로운 기능에 뛰어들기 전에, 먼저 '우리 기존 자산 중 어디가 스테이트풀을 전제로 했었는지'를 정리하는 것이 중요하다. 파괴적 변경의 순간이야말로 시니어의 역할이 '마이그레이션(移行) 지도를 그리는 것'임을 다시 한번 느끼고 있다.
## 참고 링크
- The 2026-07-28 Specification — Model Context Protocol Blog
- Bringing MCP 2026-07-28 to Claude — Anthropic / Claude Blog
- Model Context Protocol 공식 사이트
- Introducing the Model Context Protocol — Anthropic
*본 기사는 2026년 8월 3일자 공개 정보를 기반으로 작성되었습니다. 사양은 업데이트될 수 있으므로, 구현 전에 일차 정보의 최신 버전을 확인해 주십시오. 고유명사, 버전 번호, 필드 이름은 반드시 공식 사양과 대조하는 것을 강력히 권장합니다.*
### 토론(Discussion)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
