새 MCP 사양 도입 후 연동과 검수에서 확인해야 할 사항

MCP의 변화는 모델에 도구를 보여 주는 단계에서, 도구 연동을 장기적으로 유지 관리할 수 있는 서비스로 만드는 단계로 옮겨가고 있습니다. 개발자에게 가장 가치 있는 작업은 설정의 프로토콜 날짜를 최신으로 바꾸는 것이 아니라, 클라이언트, 서버, 중간 네트워크가 실제로 어떤 동작을 지원하는지 확인하는 것입니다.

이 글은 MCP 2026-07-28 사양과 이후 공개된 로드맵을 분석합니다. 자료 확인 기준일은 2026년 9월 5일입니다. 이 글은 EveryInfra의 업그레이드 공지가 아니며, 본문에 언급된 변경 사항이 EveryInfra나 사용 중인 클라이언트에 이미 적용되었다는 뜻도 아닙니다.

먼저 구분할 것: 이미 공개된 사양과 로드맵상의 계획

MCP 메인테이너는 7월 28일 릴리스 공지에서 2026-07-28 버전을 공식 발표했으며, 상태 비저장(stateless) 프로토콜 코어가 주요 변경 사항 중 하나입니다. 이는 서비스가 마이그레이션을 마쳤다는 것과는 다릅니다. 사양은 구현자가 따라야 할 기준을 알려 주고, 서비스의 버전 노트와 실제 응답은 사용자가 지금 쓸 수 있는 것을 알려 줍니다.

2026년 8월 22일 공개된 새 로드맵(https://blog.modelcontextprotocol.io/posts/mcp-roadmap/)은 에이전트 신원, 결과 표현, 점진적 도구 탐색 등 이후 방향을 제시했습니다. 이 방향을 모두 "최신 MCP가 지원하는 기능" 목록에 넣으면 연동 담당자가 잘못 판단하게 됩니다. 로드맵은 프로젝트가 나아갈 방향을 이해하는 데 도움이 되지만, 아직 출시되지 않은 클라이언트 기능을 대신할 수는 없습니다.

이 로드맵을 둘러싼 Hacker News 토론(https://news.ycombinator.com/item?id=49399591)에서도 서비스가 새 요구 사항을 얼마나 구현할지, 점진적 도구 로딩은 어떻게 될지에 대한 질문이 나왔습니다. 이는 가치 있는 논의 단서이지만 생태계 도입 현황 조사는 아닙니다. 저희가 더 관심을 두는 것은 실무적인 질문입니다. 둘 다 MCP를 지원한다고 밝힌 두 엔드포인트가 실제로 같은 프로토콜 언어를 쓰고 있을까요?

상태 비저장은 프로토콜 세션을 없앨 뿐, 비즈니스 책임은 남는다

공식 변경 내역(https://modelcontextprotocol.io/specification/2026-07-28/changelog)에 따르면 새 버전은 기존 초기화 핸드셰이크와 프로토콜 수준의 세션 식별자를 제거했습니다. 호출 간에 상태를 유지해야 하는 애플리케이션은 명시적인 비즈니스 핸들을 사용할 수 있습니다. 즉, 프로토콜은 더 이상 연결에 숨겨진 세션에 의존해 모든 컨텍스트를 기억하지 않으며, 애플리케이션은 여전히 자체 작업, 리소스, 상태를 가질 수 있습니다.

연동 설계에서 얻을 시사점은 활성 연결로 명확한 작업 소유권을 대신하지 말라는 것입니다. 시간이 오래 걸리는 작업이라면 최소한 누가 시작했는지, 어떤 사용자가 조회 권한을 갖는지, 현재 상태는 무엇인지, 네트워크가 끊긴 뒤 결과를 어떻게 확인하는지에 답할 수 있어야 합니다.

가상의 시나리오를 생각해 보겠습니다. 에이전트가 보고서 생성 작업을 시작했는데 클라이언트 연결이 끊겼습니다. 다시 연결한 사용자에게 필요한 것은 재연결 가능 여부만이 아니라 원래 보고서가 생성되었는지 여부입니다. 작업 식별자와 결과 조회 방법이 없으면 프로토콜 연결이 단순해지더라도 사용자가 같은 작업을 다시 제출할 수 있습니다.

따라서 프로토콜 요청 번호, 비즈니스 작업 식별자, 중복 실행 방지 메커니즘은 각각 따로 설계할 것을 권장합니다. 서로 연관될 수는 있지만, 하나가 있다고 해서 나머지 두 문제가 해결된 것은 아닙니다. 이는 애플리케이션 계층의 설계 판단이며, MCP가 모든 비즈니스에 자동으로 멱등성을 보장한다는 뜻이 아닙니다.

HTTP 관리가 쉬워져도 요청 헤더만으로는 충분하지 않다

새 버전의 Streamable HTTP 사양(https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http)은 Mcp-Method 같은 요청 메타데이터 헤더를 정의하고, 해당하는 메서드에서는 Mcp-Name을 사용합니다. 헤더와 본문의 대응 필드는 일치해야 합니다. 사양은 여전히 요청 범위의 SSE 응답을 허용하므로, 이 변경을 "MCP가 더 이상 스트리밍 응답을 쓰지 않는다"로 단순화할 수 없습니다.

이러한 설계 덕분에 미들웨어가 요청을 구분하기 쉬워졌지만, 사용자는 여전히 두 가지를 확인해야 합니다. 첫째는 프로토콜 검사로, 헤더 누락, 지원하지 않는 버전, 헤더와 본문 불일치에 대해 명확한 오류를 반환하는지 확인합니다. 둘째는 비즈니스 검사로, 도구 호출로 식별된 뒤 현재 사용자에게 이 도구를 실행하고 이 객체에 접근할 권한이 있는지 확인합니다.

조회 전용 계정이 요청 헤더에는 조회 작업을 지정하면서 본문에서는 수정 작업을 요청한다고 가정해 보겠습니다. 미들웨어와 애플리케이션 계층이 서로를 어설프게 신뢰하면 시스템 동작이 일관되지 않을 수 있습니다. 실제 테스트에서는 올바른 요청 헤더가 통과하는지만 확인할 것이 아니라, 이런 불일치를 포함한 무해한 요청을 만들어 거부되는지 확인해야 합니다.

마찬가지로 HTTP 200은 응답을 정상적으로 받았다는 뜻일 뿐, 목표한 비즈니스 작업이 완료되었다는 뜻은 아닙니다. 도구는 비즈니스 오류를 반환하거나, 입력을 기다리거나, 단계별 결과를 출력할 수 있습니다. 모든 응답을 일괄적으로 성공으로 표시하기보다 이러한 상태를 사용자에게 그대로 전달하는 것이 더 중요합니다. 오류 분류 설계에 대해서는 사이트의 API 오류 처리와 자가 복구 방법(https://everyinfra.com/build/api-errors-self-healing)을 참고하세요.

카탈로그는 캐시할 수 있지만 권한을 캐시로 추정해서는 안 된다

새 사양은 카탈로그 응답에 ttlMs와 cacheScope를 도입해 각각 최신성 힌트와 공유 캐시 범위를 나타냅니다. 구체적인 적용 대상은 변경 내역의 캐시 관련 노트(https://modelcontextprotocol.io/specification/2026-07-28/changelog)에 나와 있습니다. 이는 불필요한 중복 탐색을 줄이는 데 도움이 되지만, 도구 목록이 절대 바뀌지 않는다는 약속은 아닙니다.

연동 담당자는 카탈로그를 타임스탬프와 적용 대상 신원이 표시된 지도로 다룰 수 있습니다. 지도는 모델이 도구를 고르는 데 도움이 되지만, 최종 실행 시에는 권한과 파라미터 검사를 다시 거쳐야 합니다. 사용자가 도구를 한 번 보았다고 해서 영구적인 사용 권한이 생기는 것은 아닙니다.

별도로 검증할 만한 시나리오가 있습니다. 사용자 권한이 취소된 뒤에도 클라이언트가 이전 카탈로그를 계속 보유하는 경우입니다. 바람직한 사용자 경험은 도구가 조용히 사라지거나 호출이 아무 설명 없이 실패하는 것이 아니라, 실행 엔드포인트가 명시적으로 거부하고 클라이언트가 이유를 설명하며 적절한 시점에 카탈로그를 갱신하는 것입니다. 캐시 시간을 늘려 권한 변경을 가리지 마세요.

자체 기능 카탈로그를 구축하고 있다면, 실시간 기능 카탈로그에 검증 가능성이 필요한 이유(https://everyinfra.com/build/live-capability-catalog)도 함께 읽어 보세요. 이 사이트 내 글은 카탈로그와 실제 동작의 관계를 다루며, 새 캐시 메커니즘을 모두 구현했다는 뜻은 아닙니다.

연결되었다고 해서 신원 문제가 가려지지는 않는다

인가 서버 신원 검증은 이번 사양 변경에 포함됩니다. RFC 9207(https://www.rfc-editor.org/info/rfc9207/)은 iss 파라미터를 정의하며, 클라이언트가 인가 응답이 예상한 발급자로부터 왔는지 확인하고 인가 서버 혼동을 방지하도록 돕습니다.

제품 관점에서 신원에는 적어도 세 가지 별개의 질문이 있습니다. 지금 활성 상태인 사용자는 누구인지, 사용자가 이번 실행에서 어떤 작업을 허용했는지, 작업 실행 중 서비스가 실제로 어떤 권한을 노출하는지입니다. 사용자가 로그인을 마쳤다고 해서 이후의 모든 외부 전송, 삭제, 리소스 구매에 동의한 것은 아닙니다.

영향이 큰 액션은 실행 전에 핵심 대상과 결과를 다시 보여 줄 것을 권장합니다. 예를 들어 설정을 수정할 때는 어느 환경의 어떤 필드인지, 메시지를 보낼 때는 수신자와 내용을 명시해야 합니다. 모델은 작업 준비를 도울 수 있지만, 권한 부여가 모호한 도구 설명 뒤에 숨어서는 안 됩니다.

이것이 서비스에 OAuth가 있다는 것, 클라이언트가 MCP를 지원한다는 것, 도구 목록을 조회할 수 있다는 것 중 어느 하나만으로는 프로덕션 연동 검수 결과가 될 수 없는 이유입니다. 프로토콜 탐색, 신원 인가, 비즈니스 완료는 각각 검증 가능한 근거를 갖춰야 합니다.

업그레이드 전, 작고 명확한 검수 매트릭스부터 만들기

공식 버전 및 호환성 노트(https://modelcontextprotocol.io/specification/2026-07-28/basic/versioning)를 기준으로 구현을 검증할 때는 "MCP 지원"을 한 줄로 등록하지 말고 실제 사용 조합을 각각 따로 나열하세요. 각 행에는 클라이언트와 버전, 서버가 지원하는 프로토콜 버전, 사용하는 전송 및 인증 방식, 검증된 작업, 검증되지 않은 기능을 기록합니다.

첫 라운드에서 모든 도구를 테스트할 필요는 없지만, 배포 여부 판단을 바꿀 수 있는 시나리오는 반드시 포함해야 합니다:

• 읽기 전용 작업이 현재 사용자와 대상에 해당하며 이해할 수 있는 결과를 반환합니다.
• 지원하지 않는 버전, 잘못된 파라미터, 만료된 자격 증명은 성공한 것처럼 보이는 빈 결과로 처리되지 않고 명시적으로 거부됩니다.
• 사용자가 영향이 큰 작업을 거부하면 서비스는 해당 액션을 실행하지 않습니다.
• 요청이 중단되어도 원래 작업의 상태를 확인할 수 있으며, 결과를 알 수 없을 때 부수 효과가 있는 작업을 자동으로 반복하지 않습니다.
• 권한이 변경된 뒤에는 이전 카탈로그나 연결로 취소된 권한을 계속 사용할 수 없습니다.

이 항목들은 저희가 제안하는 연동 검수 항목이며, 특정 제품에 대해 완료한 테스트 보고서가 아닙니다. EveryInfra의 기존 접속 안내는 원격 MCP 접속 검수(https://everyinfra.com/build/remote-mcp-setup)에서 확인할 수 있습니다. 읽을 때는 구체적인 버전과 테스트 범위를 염두에 두고, 이를 2026-07-28 호환성의 증거로 간주하지 마세요.

업그레이드 여부는 결국 구체적인 질문으로 돌아가 판단해야 합니다. 새 버전이 현재 배포나 사용에서 명확한 문제를 해결하는가, 그리고 주요 클라이언트 조합이 안정적으로 동작하는가입니다. 답이 불분명하다면 먼저 호환성 검증을 마치고, 분명하다면 마이그레이션과 롤백 계획을 세우세요. 프로토콜 날짜 업데이트는 출발점이며, 사용자가 꾸준히 작업을 완료하는 것이 결과입니다.