MCP는 죽지 않았습니다: 최신 MCP 업데이트가 메모리 서버에 의미하는 것

요약 (TL;DR)

Claude Code의 4월 릴리스를 통해 도구별 MCP 출력 제한이 500,000자로 상향되었고, 동시 서버 연결 (concurrent server connections) 기능이 추가되었으며, 도구 검색 (Tool Search) 및 지연 로딩 (lazy loading) 기능이 출시되었습니다.
대부분의 MCP 서버 (Slack, GitHub, filesystem)에게 이는 사용 편의성(quality-of-life)의 향상입니다.
메모리 서버의 경우, 이 네 가지 변화가 결합되어 시너지를 냅니다. 이는 설계 문제를 "우리가 담을 수 있는 가장 작은 유용한 응답은 무엇인가?"에서 "모델이 실제로 사용할 가장 풍부한 페이로드 (payload)는 무엇인가?"로 전환시킵니다.

Claude에게 메모리를 노출하는 MCP 서버를 운영해 보았다면, 그 압박을 느껴보았을 것입니다.

도구들은 토큰 예산 (token budget)을 두고 싸웁니다. 모델은 한 턴당 한두 개의 메모리 항목을 선택한 뒤 공간이 부족해집니다. 서버에서 더 많은 정보를 반환할 수는 있지만, 프롬프트 (prompt)가 수용할 수 있는 양에는 한계가 있어 어시스턴트가 내용을 무시하기 시작합니다. 컨텍스트 (context)를 적게 보내거나, 유용성이 떨어지는 컨텍스트를 보내거나, 둘 중 하나를 선택해야 했습니다. 제3의 선택지는 없었습니다.

4월의 업데이트는 그 계산법을 바꾸어 놓았습니다. 네 가지 업데이트가 짧은 간격으로 출시되었습니다. 각각의 업데이트만 놓고 보면 리트윗할 만한 대단한 릴리스 노트는 아닐 수 있습니다. 하지만 이들이 쌓이면 세션 내에서 메모리 서버가 실제로 할 수 있는 일을 재정의합니다. 제가 본 대부분의 글은 이 업데이트들을 메모리 서버에 특화된 승리가 아닌, 일반적인 개발자 측면의 승리로만 다루고 있습니다.

무엇이 변했는지, 각각의 변화가 특히 메모리 서버에 어떤 의미를 갖는지, 그리고 이번 주에 적용할 만한 설정 조정 사항은 무엇인지 설명하겠습니다.

출시된 기능

도구별 MCP 출력 제한이 500,000자로 상향되었습니다. 이것이 핵심입니다. 기존 제한 때문에 메모리 서버는 정보를 공격적으로 잘라내야(truncate) 했습니다.
동시 MCP 서버 연결 (Concurrent MCP server connections). 한 턴 내에서 여러 서버를 병렬로 쿼리할 수 있습니다. 이전에는 대기열(queue)을 사용해야 했습니다.
MCP 도구 검색 (MCP Tool Search). Claude는 모든 도구 설명을 시스템 프롬프트 (system prompt)에 담아두는 대신, 등록된 도구들을 검색합니다.
지연 로딩 (Lazy loading). 도구 스키마 (tool schemas)가 세션 시작 시점이 아닌, 필요할 때 로드됩니다.

이 중 두 가지는 서버가 전달할 수 있는 내용을 변화시킵니다. 나머지 두 가지는 서버를 등록하기 위해 지불해야 했던 프롬프트 예산을 확보해 줍니다. 이 기능들은 서로 결합되어 효과를 발휘합니다.

이것이 메모리 서버에 구체적으로 의미하는 바

MCP 내부에서 메모리 서버는 다루기 까다로운 형태를 띱니다. 대부분의 서버는 반환해야 할 데이터에 자연스러운 한계(Ceiling)가 있습니다. Slack 커넥터는 최근 메시지를 반환하고, GitHub MCP는 파일을 가져오며, 파일 시스템(Filesystem) MCP는 디렉터리를 나열합니다. 하지만 메모리는 명확한 한계가 없습니다. 가장 유용한 응답은 종종 "질문과 관련된 모든 것"이며, 2025년 기준으로 이는 "절단 예산(Truncation budget) 내에 담을 수 있는 모든 것"을 의미했습니다.

도구 호출(Tool call)당 500,000자라는 수치는 그 한계를 변화시킵니다.

이제 다음과 같은 것들을 반환할 수 있습니다:

단일 행 요약이 아닌, 타임스탬프와 참조가 포함된 전체 대화 요약 (Full conversation summaries)
추출된 사실과 함께 출처가 명시된 원본 문서 발췌본 (Original document excerpts with provenance)
에이전트가 네 번의 호출을 강제당하는 대신, 한 번의 호출로 수행하는 다중 소스 합성 (Multi-source synthesis)
규칙 이름뿐만 아니라 예시가 포함된 기술 또는 규칙 메모리 (Skill or rule memories)

트레이드오프(Trade-off)가 뒤집혔습니다. 이제 질문은 "질문에 답할 수 있는 최소한의 반환량은 무엇인가?"가 아닙니다. 대신 "모델이 구조를 무시하기 시작하기 전까지의 최대 유용 페이로드(Maximum useful payload)는 무엇인가?"가 되었습니다. 이는 훨씬 더 나은 최적화 문제입니다.

동시 연결(Concurrent connection)의 변화는 크로스 스택(Cross-stack) 설정에서 더 중요합니다. 만약 GitHub MCP, 파일 시스템(Filesystem) MCP, 웹 페치(Web-fetch) MCP와 함께 메모리 서버를 실행한다면, 메모리에 대한 회상(Recall) 작업이 다른 작업들을 차단하는 대신 모든 작업과 겹쳐서(Overlap) 진행됩니다. 엔드 투 엔드(End-to-end) 벽 시간(Wall time)은 줄어들지만, 더 중요한 효과는 모델이 추론을 시작하기 전에 메모리를 기다리지 않아도 된다는 점입니다.

새로운 동작을 선택적으로 적용하는 Claude Desktop 설정

만약 귀하의 설정이 2025년 기본값과 같다면, 새로운 여유 공간(Headroom)을 그냥 버리고 있는 것입니다. 이를 활용하는 설정의 형태는 다음과 같습니다:

{
  "mcpServers": {
    "memory": {
...

알아둘 만한 몇 가지 세부 사항은 다음과 같습니다:

순서가 예전만큼 중요하지 않습니다. 동시 연결 (Concurrent connections) 환경에서 Claude는 서버를 위에서 아래로 순차적으로 탐색하지 않습니다. 이제 설정 (Config)은 우선순위 목록이 아니라 레지스트리 (Registry) 역할을 합니다.
메모리 서버가 큰 페이로드 (Payload)를 반환한다면, 구조화하십시오. 구조화되지 않은 400K 자의 텍스트 덩어리는 새로운 용량 한계치를 낭비하게 만듭니다. 제목(Heading)이 있는 섹션, 출처 표기 (Source attribution), 타임스탬프 (Timestamps)가 포함된 데이터는 단순한 산문 형태의 텍스트보다 모델의 압축 과정 (Compression pass)을 훨씬 더 잘 견뎌냅니다.
모든 도구 (Tool)를 노출하지 마십시오. 지연 로딩 (Lazy loading)이 도움이 되긴 하지만, 도구 검색 (Tool Search)이 서버의 목록을 작성할 때 여전히 목록화 비용이 발생합니다. 서버당 5개에서 10개 사이의 잘 명명된 도구를 유지하는 것이 적절합니다. 20개는 너무 많습니다.

구조가 양보다 낫습니다

명확하지 않아서 제가 지적하고 싶은 부분은, "새로운 여유 공간을 활용하라"는 말이 "가득 채워라"는 뜻은 아니라는 점입니다. 어텐션 예산 (Attention budget)은 여전히 어텐션 예산입니다. 모델은 기술적으로 500K 페이로드를 읽을 수 있지만, 모델이 그 내용을 실제로 활용할 수 있을지는 구조가 유용한 부분을 찾기 쉽게 만들어 주느냐에 달려 있습니다.

성공적인 반환 예시:

# 회상: "이번 주에 내가 무엇을 작업했지?"

## 요약
...

실패하는 반환 예시:

이번 주에 사용자는 인증 작업이 포함된 프로젝트 X와 스키마 (Schema) 논의가 있었던 프로젝트 Y를 포함하여
매우 다양한 일들을 수행했으며, 또한 여러 슬랙 (Slack) 스레드에서 다양한...

두 가지 모두 용량 범위 내에 들어옵니다. 하지만 하나만 실제로 사용됩니다.

속도 제한 (Rate limits)이 곧 문제가 될 것입니다

만약 기존의 "턴당 한 번의 호출"이라는 가정하에 IP당 속도 제한을 설정하여 메모리 서버를 운영해 왔다면, 동시 연결 (Concurrent connections)이 당신을 당황하게 만들 것입니다.

이제 단일 턴 (Single turn)에서도 서로 다른 도구 경로를 통해 동일한 서버에 대해 3~5번의 호출이 발생할 수 있습니다. 만약 안전을 위해 제한을 5r/s로 설정했다면, 단일 에이전트 (Agent)의 일반적인 사용만으로도 이 제한에 도달하게 될 것입니다.

# 자체 호스팅되는 nginx 프런트엔드 서버용
# 제한을 높이되, 더 중요한 것은 새로운 버스트 형태 (Burst shape)를 이해하는 것입니다
limit_req_zone $binary_remote_addr zone=mcp:10m rate=20r/s;

관리형 메모리 레이어(managed memory layers)의 경우, 해당 레이어의 속도 제한(rate-limit) 정책이 동시 호출(concurrent calls)을 가정하는지 아니면 직렬 호출(serial calls)을 가정하는지 확인하십시오. 만약 문서가 4월 이전에 작성되었고 업데이트되지 않았다면, 직접 문의하십시오. (이는 벤더를 평가할 때도 유용한 정보입니다. 해당 업체가 프로토콜에 주의를 기울이고 있는지 빠르게 판단할 수 있는 신호가 됩니다.)

작은 검증(sanity-check) 워크플로우

설정 변경 사항을 배포하기 전에, 본인의 환경에서 직접 측정해 볼 가치가 있습니다:

# 1. 이전 설정, 회상(recall) 비중이 높은 쿼리
claude --config old-config.json "summarize what I worked on this week"

...

흥미로운 지표는 속도가 아니라 완성도(completeness)입니다. 속도가 빨라지는 것도 좋지만, 이는 제공업체와 부하에 따라 일관되지 않습니다. 완성도 — 즉, 응답이 실제로 당신이 포함되기를 원했던 내용들을 포함했는가 — 가 바로 서버를 재설계할 가치가 있는지를 정당화해 주는 요소입니다.

여전히 어려운 점들

4월 업데이트에서 해결되지 않은 몇 가지 사항들이 있습니다:

인증(Auth)은 여전히 서버마다 제각각(snowflake)입니다. Bearer 토큰, OAuth, 설정 시점의 API 키, 서명된 URL(signed URLs) 등 다양합니다. 만약 프로젝트별 API 키(키가 세 부분으로 구성되고 Secret은 단 한 번만 표시되는 방식)를 사용하는 메모리 서비스를 운영한다면, 여전히 모든 디렉토리 목록에 이를 글로 설명해야 합니다. MCP 명세(spec)는 4월에 이를 표준화하지 않았습니다. 아마 올해 안에도 표준화되지는 않을 것입니다.
동시 호출(Concurrent calls)은 의존성 실패를 증폭시킵니다. 만약 당신의 메모리 서버가 벡터 스토어(vector store)와 그래프 DB(graph DB)에 의존하고 있는데, 이제 5개의 동시 호출이 모두 두 가지 모두를 필요로 한다면, 실패 표면(failure surface)이 넓어진 것입니다. 서킷 브레이커(Circuit breakers)와 의존성별 예산(per-dependency budgets) 설정이 이전보다 더 중요해졌습니다.
도구 검색(Tool Search)은 세션 외부가 아닌 세션 내부의 발견을 돕습니다. 서버를 처음 발견되게 만드는 것은 여전히 공식 디렉토리(punkpeye/awesome-mcp-servers, tolkonepiu/best-of-mcp-servers, mcp.so, Glama, Smithery)에 등록되어 있는가에 달려 있습니다. 4월 릴리스는 이 부분에 대해 아무것도 바꾸지 않았습니다.

공개적으로 말할 가치가 있는 것

4월 업데이트 이면에 숨겨진 더 큰 이야기는 개별 기능이 아닙니다. 그것은 2025년 메모리 서버가 설계되던 방식을 형성했던 프롬프트 경제(prompt-economy)의 가설들이 사라졌다는 사실입니다.

이전의 제약 조건에 맞춰 구축된 서버들은 계속 작동할 것입니다. 다만 새로운 헤드룸(headroom)을 활용하지 못할 뿐입니다. 만약 여러분이 "가능한 한 가장 작은 유용한 응답"을 기준으로 회상 로직(recall logic)을 설계했다면, 이제는 "주의력(attention)을 존중하면서도 가능한 한 가장 풍부한 유용한 응답"을 중심으로 재설계할 수 있는 진정한 아키텍처적 기회가 있습니다. 이는 해결책이 다른, 완전히 다른 문제입니다.

이것이 바로 4월 릴리스(release)에서 가장 먼저 재설계(re-architecting)를 고려해야 할 부분입니다.

만약 메모리 서버(memory server)를 운영 중이라면, 지금이 바로 기존의 가설들을 재검토해야 할 시점입니다. 직접 서버를 운영하고 싶지 않다면, MemoryLake가 모델 간 호환성, 프로토콜 진화(protocol-evolution), 그리고 인증(auth) 문제를 처리해 줍니다. MCP를 통해 ChatGPT, Claude, Gemini 및 코딩 에이전트(coding agents) 전반에 걸쳐 사용되는 단 하나의 메모리를 종단간 암호화(end-to-end encrypted)된 상태로 사용자가 직접 소유하며 가져갈 수 있습니다.

2026년 AI 에이전트 메모리에 관한 시리즈 중 일부입니다. 다음 편: 4월 RCE 취약점 공개 이후 MCP 서버 보안 강화.

댓글을 통한 논의를 환영합니다 — 동시 연결(concurrent connections) 기능이 활성화된 후 여러분의 설정에서 무엇이 바뀌었나요?