작성자 Stateless MCP 서버 변경 사항 및 운영 가이드
MCP 2026-07-28 개정으로 initialize 핸드셰이크와 세션 개념이 완전히 제거되었습니다. 변경된 프로토콜 사양에 맞춰 리버스 프록시, 헬스 체크, 타임아웃 및 인증 로직을 어떻게 수정해야 하는지 상세히 설명합니다.
Stateless MCP 서버란 무엇인가
Stateless MCP 서버는 요청 간에 클라이언트별 상태를 유지하지 않습니다. 모든 요청에는 프로토콜 버전, 클라이언트 기능, 서버가 응답하는 데 필요한 자격 증명이 포함되므로, 어떤 머신의 어떤 프로세스든 요청에 응답할 수 있습니다. 에이전트가 도구에 접근하기 위해 사용하는 와이어 형식인 MCP(Model Context Protocol)는 2026-07-28 개정판에서 이를 규칙으로 정했으며, 이 과정에서 initialize 핸드셰이크와 그 기반이 되었던 HTTP 세션이 제거되었습니다.
이것이 운영상의 핵심입니다. 클라이언트별로 아무것도 유지하지 않는 서버는 세션 고정(session affinity)이 없는 일반적인 로드 밸런서 뒤에 배치할 수 있고, 배포 중에 재시작해도 클라이언트 연결이 끊기지 않으며, 하나의 프로세스 대신 4개의 동일한 프로세스로 실행할 수 있습니다. 세션 지향 서버는 추가적인 장치 없이는 이러한 작업을 수행할 수 없습니다.
Model Context Protocol은 stateless 프로토콜입니다. 요청을 처리하는 데 필요한 모든 정보는 요청 자체에 포함되어 있습니다. 서버는 각 요청을 독립적으로 처리하며, 동일한 연결이나 스트림을 통한 이전 요청이라 하더라도 그로부터 상태를 추론해서는 안 됩니다.
Stateless라고 해서 서버가 아무것도 저장하지 않는다는 의미는 아닙니다. 데이터베이스, 큐, 캐시는 여전히 존재합니다. 이는 프로토콜이 연결상에 상태를 전달하지 않는다는 의미이며, 따라서 서버는 연결, 프로세스 또는 열린 소켓을 "대화 중인 특정 클라이언트"를 대신하는 것으로 취급해서는 안 됩니다.
2026-07-28 개정에서 제거된 사항
2026-07-28은 2026년 8월 기준 해당 사양의 최신 개정판입니다. 2025-11-25과 비교했을 때, 세션을 지원하기 위해 존재했던 다음 다섯 가지 항목이 제거되었습니다.
initialize요청 및notifications/initialized알림. 핸드셰이크 과정이 완전히 제거되었습니다(SEP-2575).Mcp-Session-Id헤더 및 HTTPDELETE를 통한 세션 종료(SEP-2567).- 서버가 알림을 푸시하던 독립형 HTTP
GET스트림. 이는 응답이 장기 지속 스트림인 일반 POST 요청인subscriptions/listen로 대체되었습니다. - SSE(server-sent events) 스트림 재개 기능.
Last-Event-ID헤더와 이벤트별 ID가 제거되었으므로, 스트림이 끊기면 진행 중이던 요청은 유실되며 클라이언트는 새로운 요청 ID를 사용하여 새 요청으로 다시 시도해야 합니다. ping,logging/setLevel및notifications/roots/list_changed. 로그 레벨은 이제_meta내의io.modelcontextprotocol/logLevel라는 요청별 필드로 관리됩니다.
한 가지 메서드가 추가되었으며, 모든 서버는 이를 구현해야 합니다. server/discover은 서버가 지원하는 프로토콜 버전, 기능 및 식별 정보를 한 번의 호출로 반환합니다. 이는 남아있는 핸드셰이크와 가장 유사한 기능이지만, 클라이언트가 이를 호출하는 것은 선택 사항입니다.
세션 전송 방식을 운영 환경에서 실행하기 어려웠던 이유
2025-11-25 및 이전 버전에서는 서버가 초기화 시점에 세션 ID를 생성하고 InitializeResult를 통해 Mcp-Session-Id 헤더로 반환할 수 있었습니다. 클라이언트는 이후 모든 요청에 해당 헤더를 포함해야 했습니다. 협상된 프로토콜 버전과 클라이언트의 기능은 해당 ID를 키로 하여 서버 메모리에 저장되었습니다. 이러한 방식은 각각 운영상 비용을 발생시켰습니다.
- 서버를 재시작하면 세션 테이블이 삭제되었습니다. 사양에 따라 서버는 유효하지 않은 세션 ID를 포함한 요청에 대해
404 Not Found로 응답해야 했으며, 클라이언트는 새로운InitializeRequest으로 다시 시작해야 했습니다. 이로 인해 모든 배포 작업이 연결된 모든 클라이언트의 재연결 이벤트가 되었습니다. - 두 번째 복제본은 첫 번째 복제본의 세션 정보를 알 수 없었습니다. 따라서 확장을 하려면 로드 밸런서에서 고정 세션(sticky routing)을 사용하거나, 모든 복제본이 요청마다 읽어오는 공유 세션 저장소가 필요했습니다.
- 세션 테이블은 유휴 상태인 클라이언트가 늘어날수록 메모리를 점유했습니다.
DELETE은 선택 사항이었기에, 이를 보내지 않고 종료한 클라이언트의 정보가 서버에 그대로 남았습니다. - 연결마다 목록 결과가 달라질 수 있었으므로 서버 앞단에 캐시를 두는 것은 안전하지 않았습니다.
세션을 제거하면 이 네 가지 문제가 동시에 해결됩니다. 설정을 변경하기 전에 반드시 이해해야 할 변화입니다.
모든 요청에 포함되는 정보
MCP 엔드포인트로 보내는 각 POST 요청은 독립적으로 처리됩니다. 프로토콜 버전과 클라이언트 기능은 요청 본문의 _meta 필드에 포함되며, 중개자가 JSON을 파싱하지 않고도 라우팅할 수 있도록 선택된 필드들이 HTTP 헤더로 복제됩니다.
POST /mcp HTTP/1.1
Content-Type: application/json
Accept: application/json, text/event-stream
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: get_weather
Authorization: Bearer <access token>
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "get_weather",
"arguments": {"location": "Seattle, WA"},
"_meta": {
"io.modelcontextprotocol/protocolVersion": "2026-07-28",
"io.modelcontextprotocol/clientInfo": {"name": "ExampleClient", "version": "1.0.0"},
"io.modelcontextprotocol/clientCapabilities": {}
}
}
}io.modelcontextprotocol/protocolVersion와 io.modelcontextprotocol/clientCapabilities은 모든 요청에 필수입니다. clientInfo은 필수는 아니지만 클라이언트가 전송하는 것을 권장합니다. 필수 필드가 누락된 요청은 잘못된 형식이므로, 서버는 JSON-RPC 오류 -32602와 HTTP 400 Bad Request으로 응답하여 거부해야 합니다.
Mcp-Method 헤더는 모든 요청에 필수입니다. Mcp-Name는 tools/call, resources/read, prompts/get 요청 시 필수입니다. 헤더 값은 본문 내용과 일치해야 하며, 본문을 처리하는 서버는 불일치 발생 시 400 Bad Request 및 오류 코드 -32020, HeaderMismatch로 거부해야 합니다. 이 규칙은 헤더를 기반으로 라우팅하는 로드 밸런서와 본문을 실행하는 서버가 서로 다른 진실의 원천(source of truth)이 될 수 있기 때문에 존재합니다. 이 헤더들을 사용하여 라우팅하거나 속도 제한(rate-limiting)을 적용하는 경우, 먼저 MCP-Protocol-Version를 확인하십시오. 이전 버전에서는 헤더와 본문의 일치 여부를 검증하지 않았으므로, 해당 버전들의 헤더 값은 신뢰할 수 없습니다.
버전 불일치는 이제 핸드셰이크 실패가 아닌 일반적인 요청 단위 오류로 처리됩니다. 요청된 버전을 구현하지 않는 서버는 오류 -32022, UnsupportedProtocolVersion와 함께 400 Bad Request으로 응답하며, 지원하는 버전 목록을 data.supported에 포함합니다. 클라이언트는 해당 목록에서 하나를 선택하여 재시도합니다.
상태가 이동한 위치: 토큰, 커서, 구독
상태는 사라지지 않았습니다. 확인하고 로그를 남길 수 있는 곳으로 이동했을 뿐입니다.
자격 증명은 모든 요청에 포함됩니다. 신원을 연결할 세션이 없으므로, 액세스 토큰은 각 HTTP 호출에 실려 매번 검증됩니다. 자세한 내용은 아래 인증 섹션에 있습니다.
커서는 자신의 위치 정보를 직접 담아야 합니다. tools/list, resources/list, prompts/list, resources/templates/list에서의 페이징은 불투명한 커서 문자열을 사용하며, 클라이언트는 이를 파싱하거나 수정해서는 안 됩니다. 단일 프로세스 서버에서는 세션을 키로 하여 오프셋을 메모리에 유지하는 것이 일반적이었습니다. 세션이 없는 환경에서는 어떤 복제본(replica)이라도 목록 조회를 재개할 수 있도록 커서가 충분한 정보를 담아야 합니다. 따라서 위치 정보를 커서 내부에 인코딩하고 서명하거나, 모든 복제본이 공유하는 저장소에 보관하십시오. 유효하지 않은 커서가 들어오면 -32602을 반환해야 합니다. 불투명한 커서라도 클라이언트가 제공한 입력값을 코드가 디코딩하여 신뢰하는 것이므로 반드시 서명하십시오.
구독은 연결이 아닌 요청에 속합니다. 변경 알림을 원하는 클라이언트는 원하는 유형을 지정한 필터와 함께 subscriptions/listen를 보냅니다: toolsListChanged, promptsListChanged, resourcesListChanged, resourceSubscriptions. 서버는 notifications/subscriptions/acknowledged로 응답하고 해당 응답 스트림을 열어 둡니다. 스트림이 끊기면 서버는 아무것도 유지하지 않으며, 클라이언트는 subscriptions/listen을 다시 보내 복구합니다.
호출 간 애플리케이션 상태는 명시적인 핸들이 됩니다. 서버가 호출 사이의 정보를 반드시 기억해야 할 경우, 사양에서 제시하는 해결책은 서버가 생성한 식별자를 일반 도구 인자로 전달하는 것입니다. 이 식별자는 도구 스키마에 나타나며 로그로 남길 수 있고, 연결 상태에 암묵적으로 의존하지 않습니다. 자체 호스팅 MCP 이메일 서버와 같이 사용자별 데이터를 다루는 서버는 세션 대신 이 패턴을 사용합니다. 메일함이나 초안 식별자가 도구 인자로 전달되므로 어떤 복제본이라도 다음 호출을 처리할 수 있습니다. 많은 도구는 핸들이 전혀 필요하지 않습니다. 자체 SearXNG 인스턴스를 기반으로 하는 검색 도구는 쿼리를 받아 결과를 반환할 뿐이며, 다음 호출을 위해 재개할 상태가 없으므로 어떤 복제본이 응답했는지 신경 쓸 필요가 없습니다.
배포: 리버스 프록시, 타임아웃, 상태 확인
MCP 엔드포인트는 POST 요청을 수신하는 하나의 경로입니다. 대부분의 트래픽은 짧은 요청과 JSON 응답으로 구성되며, 이는 어떤 프록시로도 처리할 수 있습니다. 예외는 스트리밍 응답이며, 이때는 프록시의 기본 설정이 오히려 방해가 됩니다. 이 부분은 노트북에서 데모를 실행하다가 VPS에서 MCP 서버를 운영하는 환경으로 전환할 때 변경되는 지점입니다.
location /mcp {
proxy_pass http://127.0.0.1:8080;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_buffering off;
proxy_read_timeout 1h;
proxy_send_timeout 1h;
}proxy_buffering off는 중요합니다. Nginx는 기본적으로 프록시 응답을 버퍼링하므로, 버퍼가 가득 차거나 응답이 종료될 때까지 SSE 이벤트를 붙잡아 두기 때문입니다. 명세에 따르면 서버는 SSE 응답에 X-Accel-Buffering: no을 전송해야 하며, Nginx는 이 헤더를 준수합니다. 따라서 올바르게 구현된 서버는 프록시에 적절한 지시를 내립니다. 이 지시어를 직접 설정하는 것은 사용자가 제어할 수 있는 부분입니다.
proxy_read_timeout의 기본값은 60초입니다. 60초 이상 조용한 subscriptions/listen 스트림은 서버가 아닌 Nginx에 의해 종료됩니다. 이 경우 로그에는 프로세스가 정상으로 기록되지만, 클라이언트에서는 스트림이 끊긴 것으로 나타납니다. 이 설정은 서버 전체가 아닌 MCP 위치(location)에만 높게 설정하십시오. 또한 서버는 조용한 기간 동안 keep-alive 용도로 SSE 주석 라인(콜론으로 시작하는 라인)을 전송하는 것이 권장됩니다. 이를 통해 중간 매개체가 스트림을 타임아웃시키는 것을 방지할 수 있습니다.
Caddy는 설정이 덜 필요합니다. Caddy는 네트워크 효율성을 위해 기본적으로 부분 버퍼링을 수행하며, 응답에 Content-Type: text/event-stream이 포함되면 즉시 플러시하므로 추가 지시어 없이도 스트리밍이 정상 작동합니다.
mcp.example.com {
reverse_proxy 127.0.0.1:8080 {
health_uri /healthz
health_interval 10s
}
}상태 확인(health check)이 어디를 가리키는지 주의하십시오. MCP 엔드포인트에 GET를 사용하여 활성 상태 확인을 수행하지 마십시오. 이 버전을 구현하는 서버는 GET 및 DELETE 요청에 대해 405 Method Not Allowed로 응답하며, Caddy의 기본 상태 확인 방식은 GET이기 때문입니다. 이 경우 프록시는 정상적으로 작동 중인 백엔드를 다운된 것으로 간주합니다. 프록시를 위해 /healthz와 같은 단순한 경로를 제공하고, 프로토콜 확인은 별도의 POST 요청으로 수행하십시오.
curl -sS https://mcp.example.com/mcp \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
-H 'MCP-Protocol-Version: 2026-07-28' \
-H 'Mcp-Method: server/discover' \
-d '{"jsonrpc":"2.0","id":"health-1","method":"server/discover","params":{"_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28","io.modelcontextprotocol/clientCapabilities":{}}}}'supportedVersions 목록을 포함하는 200 응답은 프로세스가 실행 중이며 프로토콜을 준수하고 있음을 의미합니다. JSON-RPC 오류 -32601을 포함하는 404 응답은 프로세스는 실행 중이지만 모든 2026-07-28 서버가 구현해야 하는 server/discover를 제공하지 않음을 의미합니다. -32022을 포함하는 400 응답은 확인자가 현재 빌드에서 지원하지 않는 버전을 요청했음을 의미하며, 이는 의존성 업그레이드 후 반드시 확인해야 할 사항입니다. 오픈 소스 Nginx는 활성 상태 확인 기능을 제공하지 않으므로, 업스트림에서 수동 max_fails 및 fail_timeout를 사용하고 모니터링 도구에서 프로토콜 확인을 수행하십시오.
이제 롤링 재시작을 수행하면 진행 중인 요청 외에는 손실이 발생하지 않습니다. 기존 요청을 처리(drain)하고, 열려 있는 POST 요청이 완료되기를 기다린 뒤, 새 프로세스를 시작하면 클라이언트는 실패한 요청을 다시 시도합니다. 여전히 끊길 수 있는 유일한 것은 열려 있는 subscriptions/listen 스트림입니다. 해당 스트림은 특정 프로세스와의 실시간 연결이기 때문입니다. 상태 비저장(statelessness)은 세션 친화성(session affinity)을 제거했지만, 현재 열려 있는 스트림에 대한 연결 친화성까지 제거한 것은 아니며, 어떤 라우팅 규칙으로도 이를 해결할 수 없습니다. 클라이언트는 이를 구분할 수 있습니다. 빈 subscriptions/listen 결과로 종료된 스트림은 정상적으로 닫힌 것이며, 그렇지 않고 종료된 스트림은 끊긴 것으로 간주하여 재연결을 시도할 수 있습니다.
이제 캐싱이 처음으로 가능해집니다. 목록 메서드의 결과에는 ttlMs 및 cacheScope이 포함되며, cacheScope: "public"는 공유 중간 매개체에 응답을 캐시해도 좋다는 신호를 보냅니다. 이는 세션 제거의 직접적인 결과로, 목록 결과가 연결마다 달라지지 않기 때문에 안전합니다.
세션이 없을 때 인증 방식이 변경되는 이유
세션을 사용할 때는 initialize에서 한 번만 인증하고 이후의 모든 요청에 대해 세션 ID를 증명 수단으로 사용하는 방식이 흔했습니다. 이러한 방식으로 사용되는 세션 ID는 수신자(audience) 제한, 만료 기한, 취소 경로가 없는 베어러 자격 증명(bearer credential)이며, 서버가 직접 발행합니다. 세션을 제거하면 이러한 지름길이 사라지며, 대체되는 방식은 더 엄격해집니다.
보호된 MCP 서버는 OAuth 2.1 리소스 서버로 동작합니다. 클라이언트가 보내는 모든 HTTP 요청에는 Authorization: Bearer <access token>이 포함되어야 하며, 서버는 요청마다 토큰을 검증합니다. 검증 과정에는 수신자 확인이 포함됩니다. 서버는 RFC 8707(Resource Indicators for OAuth 2.0)에 따라 해당 토큰이 자신을 위해 발행되었는지 확인해야 하며, 다른 대상을 위해 발행된 토큰을 수락하거나 전달해서는 안 됩니다. 클라이언트는 서버의 정식 URI를 resource 매개변수로 전송하여 올바른 수신자를 요청합니다.
검색(Discovery)은 챌린지 방식으로 진행됩니다. 유효한 토큰이 없는 요청이 들어오면 서버는 401 Unauthorized로 응답합니다.
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
scope="files:read"클라이언트는 resource_metadata를 읽고 해당 문서(MCP 서버가 반드시 구현해야 하는 RFC 9728, OAuth 2.0 Protected Resource Metadata)를 가져온 뒤, 권한 부여 서버를 찾아 흐름을 실행합니다. 권한이 부족한 유효 토큰의 경우 error="insufficient_scope"과 해당 작업에 필요한 스코프(scopes)를 포함하여 403 Forbidden 응답을 보냅니다.
이 방식은 운영 측면에서 두 가지 결과를 가져옵니다. 첫째, 토큰 검증이 세션당 한 번이 아니라 모든 요청마다 수행됩니다. 따라서 호출할 때마다 인트로스펙션(introspection) 엔드포인트로 네트워크 왕복이 발생하면 지연 시간이 늘어날 수 있습니다. 서명, 수신자, 만료 기한을 기준으로 로컬에서 검증할 수 있는 토큰을 사용하거나, 토큰을 키로 하여 검증 결과를 짧은 시간 동안 캐싱하는 것이 좋습니다. 둘째, 신원을 유지하는 세션이 없으므로 권한 부여는 매 호출 시 토큰을 기반으로 계산되어야 합니다. 이는 기존 세션 모델보다 더 투명한 방식이며, 자격 증명을 에이전트 프로세스 외부에 보관하는 일반적인 관행과도 부합합니다. 이에 관한 내용은 AI 에이전트에서 비밀 정보 분리하기에서 다룹니다.
이 개정판의 적용 범위와 그렇지 않은 범위
위의 모든 내용은 개정판 2026-07-28에 관한 설명입니다. MCP의 영구적인 사양을 설명하는 것이 아니며, 작년에 배포한 서버에 대한 설명도 아닙니다.
2025-11-25 이하의 클라이언트와 서버는 여전히 핸드셰이크 모델을 사용합니다. 사양서에서는 해당 개정판들을 레거시(legacy)로 분류하고, 요청별 메타데이터를 사용하는 개정판들을 모던(modern)으로 분류합니다. 이 개정판만 지원하는 서버가 구형 클라이언트를 만날 경우, MCP 엔드포인트에서 405 Method Not Allowed를 GET 또는 DELETE으로 응답해야 합니다. 또한 Mcp-Session-Id 헤더를 생성하거나 반향하지 않고 무시해야 하며, 스트림 재개가 불가능하므로 Last-Event-ID도 무시해야 합니다. 듀얼 에라(dual-era) 서버는 하나의 엔드포인트에서 두 방식을 모두 처리할 수 있습니다. 모던 _meta를 포함한 요청은 상태 비저장(stateless) 방식으로 처리되고, initialize 요청은 기존의 세션 의미론을 선택합니다.
따라서 이 내용을 신뢰하기 전에 개정판 문자열을 먼저 확인하십시오. 사용 중인 SDK가 여전히 initialize을 전송한다면, 배포 환경에서 세션은 여전히 유효하며 위에서 언급한 세션 관련 문제들을 직접 관리해야 합니다. 클라이언트 측도 마찬가지입니다. VPS에서 코딩 에이전트 실행하기와 같이 로컬 환경에서 실행되는 에이전트 프로세스는 사용하는 라이브러리가 모던 개정판을 지원할 때만 이 맥락에서 상태 비저장 방식으로 동작합니다. 런타임이 협상하는 버전을 확인한 다음, 해당 버전에 맞는 사양서를 참조하십시오. 이 페이지는 프로토콜 전반이 아닌 특정 개정판 하나를 설명하는 것으로 간주해야 합니다.
FAQ
상태 비저장(stateless) MCP 서버라면 아무것도 저장할 수 없다는 뜻입니까?
아닙니다. 상태 비저장은 프로토콜을 설명하는 용어이지 애플리케이션을 의미하지 않습니다. 데이터베이스, 큐, 캐시는 이전과 동일하게 작동합니다. 변경되는 점은 여러 호출에 걸쳐 유지되어야 하는 상태를 클라이언트가 각 요청마다 전달하는 명시적 식별자(예: 도구 인자 내의 서버 생성 핸들)로 참조해야 한다는 것입니다. 연결 상태로부터 컨텍스트를 추론해서는 안 됩니다. 명세에 따르면 서버는 기능, 프로토콜 버전, 클라이언트 식별을 위해 동일한 연결상의 이전 요청에 의존해서는 안 됩니다. 모든 요청이 _meta 내에 해당 정보를 포함하기 때문입니다.
로드 밸런서에서 여전히 고정 세션(sticky sessions)이 필요합니까?
일반적인 요청에는 필요하지 않습니다. 2026-07-28 개정판에서는 각 POST 요청이 자체 프로토콜 버전, 기능, 자격 증명을 포함하므로 모든 복제본이 어떤 요청이든 처리할 수 있으며 라운드 로빈 방식도 문제없습니다. 유일하게 장기 유지되는 것은 subscriptions/listen 응답 스트림이며, 이는 단일 프로세스에 대한 단일 열린 연결입니다. 해당 프로세스가 종료되면 스트림도 종료되며, 클라이언트는 subscriptions/listen를 다시 전송하여 연결을 재설정합니다. 이는 세션 친화성(session affinity)이 아닌 연결 수명에 관한 문제이며, 어떤 라우팅 규칙으로도 이를 방지할 수 없습니다.
Mcp-Session-Id와 HTTP GET 스트림은 어떻게 되었습니까?
두 가지 모두 SEP-2567 및 SEP-2575에 따라 2026-07-28 개정판에서 제거되었습니다. 이 개정판만 구현하는 서버는 MCP 엔드포인트에서 405 Method Not Allowed, GET, DELETE에 응답해야 하며, Mcp-Session-Id 헤더를 다시 에코(echo)하지 말고 무시해야 합니다. 서버가 시작하는 변경 알림은 이제 독립적인 GET 스트림 대신 subscriptions/listen 요청의 응답 스트림을 통해 전달됩니다. 이전 클라이언트를 계속 지원해야 하는 서버는 이전 개정판의 동작을 현재 개정판과 함께 구현해야 합니다.
핸드셰이크가 없는 MCP 서버의 상태 확인은 어떻게 합니까?
두 단계로 나누어 수행하십시오. 프록시의 활성 상태 확인은 애플리케이션이 제공하는 일반 HTTP 경로를 대상으로 하십시오. MCP 엔드포인트에 대한 GET은 405를 반환하여 정상적인 백엔드를 비정상으로 표시할 수 있기 때문입니다. 그 후 모든 2026-07-28 서버가 구현해야 하는 server/discover를 POST하여 프로토콜 자체를 확인하고, 응답이 HTTP 200이며 클라이언트가 사용하는 프로토콜 버전을 포함하는지 확인하십시오. JSON-RPC 오류 -32601를 포함한 404은 프로세스는 실행 중이지만 해당 메서드를 제공하지 않음을 의미하며, -32022을 포함한 400은 요청한 버전이 해당 빌드에서 지원되지 않음을 의미합니다.