MCP가 무상태(Stateless)로 전환되었습니다: 세션 간 에이전트 메모리를 유지하는 방법 (2026)

프로토콜 레이어에서 세션 제거

initialize/initialized 교환이 폐기되었습니다. 서버는 기능 탐색을 위해 새로운 server/discover RPC를 선택적으로 구현할 수 있지만 필수 사항은 아닙니다. 요청 경로의 그 어떤 것도 사전 핸드셰이크를 전제하지 않으며, 네트워크상에서 이전 요청과 다음 요청을 연결하는 고리도 없습니다.

사양은 이것이 의미하는 바와 의미하지 않는 바를 직접적으로 설명합니다. "프로토콜 수준의 세션을 제거한다고 해서 애플리케이션이 무상태가 되어야 하는 것은 아닙니다. 서버가 호출 간에 상태를 유지해야 하는 경우, 도구에서 명시적인 핸들(handle)을 생성하고 모델이 이를 인수로 다시 전달하도록 하십시오."

이 문장을 두 번 읽어보세요. 프로토콜은 상태 관리의 책임을 여러분에게 돌려주었으며, 그 메커니즘으로 '모델이 전달하고 애플리케이션이 이해하는 명시적인 핸들'을 제시했습니다. 핸들은 포인터입니다. 그 포인터가 가리키는 대상이 무엇이든, 그것을 구축하는 것은 여전히 여러분의 몫입니다.

무상태성과 관련하여 추가된 사항

이번 릴리스가 단순히 기능을 뺀 것만은 아닙니다:

• 다중 왕복 요청(Multi Round-Trip Requests, MRTR)을 통해 서버는 지속적인 연결 없이도 실행 도중에 클라이언트로 다시 요청을 보낼 수 있습니다.
• Mcp-Method 및 Mcp-Name을 통한 헤더 기반 라우팅 덕분에 게이트웨이는 JSON 본문을 파싱하지 않고도 필터링 및 라우팅을 수행할 수 있습니다.
• 캐시 가능한 목록 결과는 목록 및 읽기 응답에 ttlMs 및 cacheScope를 추가하여, 클라이언트가 서버가 허용하는 기간 동안 tools/list를 캐시할 수 있도록 합니다.
• 태스크(Tasks)는 실험적 코어에서 벗어나 AWS의 기여로 폴링 기반 작업을 통한 안정적인 장기 실행 작업을 지원하는 공식 확장 기능으로 승격되었습니다.
• MCP Apps도 동일한 공식 확장 프레임워크에 합류했습니다.
• 이제 최소 12개월의 지원 중단(deprecation) 유예 기간이 적용되며, Roots, Sampling, Logging, Dynamic Client Registration이 지원 중단 절차에 들어갔습니다.
• TypeScript, Python, Go, C# 등 티어 1 SDK가 업데이트되어 출시되었으며, Rust SDK는 베타 버전입니다.

Claude에는 이미 적용되었습니다

Anthropic은 같은 날 Claude 앱, Claude 플랫폼 및 API, Claude Code 전반에 걸쳐 새 사양에 대한 지원을 출시했습니다. 이와 함께 대화형 UI를 위한 MCP Apps, Entra 및 Okta 같은 ID 제공업체와 연동되는 OAuth 2.0/OIDC 기반의 기업 관리형 인증, 게시된 커넥터용 관측 가능성 대시보드, 연구 프리뷰 단계인 MCP 터널도 함께 공개되었습니다. Claude의 커넥터 디렉터리에는 이제 950개 이상의 MCP 서버가 등록되어 있습니다.

즉, 이 사양은 그냥 지나가기를 기다릴 수 있는 것이 아닙니다. 에이전트가 Claude Code나 커넥터와 통신하고 있다면, 무상태 코어는 이미 에이전트가 발을 딛고 있는 현실입니다.

세션은 결코 메모리가 아니었습니다

MCP 세션은 연결이 유지되는 동안(몇 분, 때로는 몇 초)만 지속되었습니다. 에이전트의 기억 상실은 완전히 다른 시간 단위로 작동합니다. 내일 아침, 다음 스프린트, 혹은 팀원이 동일한 고객에 대해 세 번째로 질문할 때처럼 말이죠. 과거의 상태 유지 방식에서도 클라이언트를 닫으면 세션이 알고 있던 모든 정보가 사라졌습니다.

세션 상태는 전송 계층의 장부 기록에 불과했습니다. 메모리는 작업의 누적된 결론입니다. 이 둘을 혼동했기 때문에 많은 팀이 애초에 보장된 적이 없는 레이어에서 지속성을 기대했던 것입니다.

실제로 작동이 중단되는 부분

세션 상태에 진정으로 의존했던 패턴은 우려하는 것보다 범위가 좁습니다. 도구 호출 사이에 메모리에 중간 상태를 누적하던 서버, 세션 ID를 키로 사용하는 핸드셰이크 기반 캐시, 클라이언트를 특정 워커에 고정하기 위해 고정 세션(sticky sessions)이 필요했던 게이트웨이 등이 이에 해당합니다. 이러한 패턴은 재작업이 필요합니다. 이제 원격 서버는 단순한 라운드 로빈 로드 밸런싱 뒤에 위치할 수 있게 되었는데, 이는 장점이기도 합니다.

작동이 중단되지 않는 부분: 연결 외부의 영구 저장소에 이미 상태를 저장하고 있던 모든 것들입니다. 지식이 데이터베이스, 파일 저장소 또는 메모리 서비스에 있었다면, 7월 28일의 변경 사항은 회복력에 아무런 영향을 미치지 않으며 오히려 배포를 더 단순하게 만들었습니다.

이제 메모리가 위치해야 할 곳

'핸들을 생성하고 모델이 이를 다시 전달하게 하라'는 사양의 답변은 정확하지만 불완전합니다. 이는 상태를 참조하는 방법을 알려줄 뿐, 상태가 어디에 살아야 하는지, 어떤 형태를 취해야 하는지, 혹은 서로 다른 세 가지 모델을 사용하는 다섯 개의 에이전트가 이를 어떻게 공유해야 하는지는 알려주지 않습니다. 이 레이어는 이제 여러분이 직접 구축해야 하는 영역이며, 우연히 해결하기보다는 의도적으로 설계할 가치가 있습니다.

더 커진 컨텍스트 창

최신 프론티어 모델들은 수백만 토큰에 달하는 컨텍스트 창을 광고하며, 이를 메모리로 취급하고 싶은 유혹을 불러일으킵니다. 하지만 이는 메모리가 아닙니다. 컨텍스트 창은 모델이 이번 턴에 읽을 수 있는 분량일 뿐입니다. 매 턴마다 무엇을 넣을지 결정해야 하고, 매번 토큰 비용을 지불해야 하며, 다음번에는 다시 빈 상태로 시작해야 합니다. 검색(retrieval)에 적용되는 동일한 차이점에 대해서는 왜 RAG가 메모리가 아닌가를 참조하세요.

각 도구의 내장 메모

Claude, ChatGPT 및 대부분의 에이전트 프레임워크는 이제 자체 메모리 기능을 제공합니다. 각각은 정말 유용하지만, 철저히 격리되어 있습니다. 코딩 에이전트가 배포 파이프라인에 대해 학습한 내용은 장애 보고서를 작성하는 어시스턴트에게 전달되지 않으며, 작업을 더 저렴한 모델로 라우팅할 때 그 어떤 정보도 따라오지 않습니다.

핸들과 직접 구축한 데이터베이스의 조합

이것이 사양이 가리키는 경로이며, 일부 팀에게는 올바른 선택일 수 있습니다. 하지만 이는 추출, 저장, 검색 순위 지정, 범위 지정, 만료, 다중 에이전트 액세스 제어를 직접 개발하고, 주변 프로토콜이 계속 발전하는 동안 이를 유지 관리해야 함을 의미합니다. 메모리 자체가 제품이라면 가치 있는 일입니다. 하지만 메모리가 제품으로 가는 길목의 배관 작업에 불과하다면 비용이 많이 드는 일입니다.

사양이 권장하는 방식을 영구적으로 구현하는 방법은 세션, 재시작, 모델 교체에 영향을 받지 않는 서비스에 메모리를 두는 것입니다. MemoryLake는 정확히 이 역할을 위해 구축되었습니다. 현재 어떤 클라이언트가 연결되어 있는지와 관계없이, 에이전트가 MCP 또는 API를 통해 읽고 쓸 수 있는 단일 메모리 레이어입니다.

1단계: API 키 생성

키를 생성하고 약 30초 만에 첫 번째 요청을 보낼 수 있습니다. 이 단계의 그 어떤 것도 세션에 의존하지 않으며, 이것이 바로 핵심입니다.

2단계: 첫 번째 메모리 업로드

아키텍처 노트, 런북, 고객 컨텍스트, 이전 결정 사항 등 에이전트가 계속해서 필요로 하는 문서, 이미지, 파일을 업로드하세요. 이것이 바로 핸들이 가리켜야 할 상태입니다.

3단계: AI 및 에이전트 연결

Claude, Codex, OpenClaw 및 기타 에이전트가 MCP 또는 API를 통해 해당 메모리에 액세스할 수 있도록 하세요. 2026-07-28 코어 사양에서는 각 호출이 자체 식별자를 전달하고 동일한 메모리에 도달하므로, 고정 라우팅이나 세션을 유지할 필요가 없습니다. 클라이언트별 가이드는 Claude Code에 메모리를 추가하는 방법을 참조하세요. 서버를 직접 작성하는 개발자라면 무상태 MCP 서버를 위한 메모리에서 구현 측면을 다루고 있으며, MCP Tasks를 위한 메모리에서는 장기 실행 작업을 다룹니다.

반복 설명에 드는 비용을 계산해 보겠습니다. 기술 스택, 컨벤션, 현재 우선순위, 이미 내려진 결정 등 고정 컨텍스트가 2,000토큰이고, 사용자나 에이전트가 이를 하루에 20번 다시 전송한다고 가정해 보겠습니다. 이는 매일 40,000토큰, 한 달에 약 120만 토큰을 이미 했던 말을 반복하는 데 소비하는 것입니다. 토큰 비용은 사소한 부분에 불과합니다. 실제로 체감하는 비용은 매 세션이 시작될 때마다 4~5분 동안 다시 브리핑해야 하는 번거로움과, 아무도 브리핑하지 않았을 때 에이전트가 저지르는 실수입니다.

영구 메모리 레이어는 이러한 매 세션마다 지불해야 하는 세금을 일회성 쓰기 비용으로 전환합니다. 또한 다중 에이전트 작업을 일관되게 만듭니다. 두 에이전트가 대화 기록 대신 메모리를 공유하면, 두 번째 에이전트는 첫 번째 에이전트의 결론에서부터 작업을 시작할 수 있습니다. 이 문제는 다중 에이전트 메모리에서 별도로 읽어볼 가치가 있습니다.

대화 기록이 아닌 결론을 저장하세요

원시 로그는 한계 없이 늘어나며 검색 효율도 떨어집니다. "대기열 모드가 인프로세스 메모리를 손상시켰기 때문에 채팅 기록용으로 Redis 대신 Postgres를 선택했습니다"라는 결론은 보관할 가치가 있습니다. 하지만 그 결론에 도달하기까지 오간 40개의 메시지는 그렇지 않습니다.

연결이 아닌 작업에 메모리를 매핑하세요

세션은 사라졌습니다. 실수로 세션을 다시 만들지 마세요. 호출하는 클라이언트가 무엇이든 관계없이 다음 달에도 동일한 의미를 갖는 프로젝트, 리포지토리, 고객 또는 태스크 단위로 메모리 범위를 지정하세요.

의도적으로 정리하고 버전을 관리하세요

오래된 메모리는 메모리가 없는 것보다 나쁩니다. 에이전트가 이를 신뢰하기 때문입니다. 사실 정보에 소유자와 만료일을 지정하고, 새로운 결정이 이전 결정을 대체한 시점을 기록하여 두 정보가 풀에 동시에 남아 혼선을 주지 않도록 하세요.

2026년 7월 28일 MCP가 무상태로 전환되었다고 해서 에이전트의 메모리가 삭제된 것은 아닙니다. 프로토콜이 메모리를 유지하고 있다는 환상이 끝났을 뿐입니다. 세션은 전송 수단이었을 뿐 기억 장치가 아니었으며, 이제 사양은 명시적인 핸들이라는 메커니즘을 제공하면서 실질적인 내용은 여러분에게 맡김으로써 이를 명확히 하고 있습니다.

이 변화를 업그레이드로 받아들일 팀은 이미 연결 외부에서 메모리를 관리하고 있던 팀들입니다. 더 단순해진 배포, 동일한 기억력, 그리고 이전 에이전트가 멈춘 지점부터 이어서 작업하는 에이전트를 경험하게 될 것입니다. 반면 이를 손실로 느낄 팀은 세션이 대신 기억해 주기를 바랐던 팀들입니다. 이 레이어를 한 번 구축하는 것이 평생 반복 설명 세금을 내는 것보다 저렴합니다.