MCP 7월 개정판, 초기화 없애고 요청별 정보로 원격 운영 간소화

MCP 프로젝트가 2026년 7월 28일 공개한 안정판은 초기화 절차와 HTTP의 프로토콜 세션 식별자를 없애고, 각 요청에 프로토콜 버전과 클라이언트 기능 정보를 싣도록 바꿨습니다. Hiraoku.dev의 해설은 이 변화가 원격 서버의 분산 운영 부담을 줄였지만, 도구 설명의 지연 로딩과 검색 결과 축소는 AI 앱과 도구 서버의 구현에 달렸다고 설명합니다.

MCP와 CLI가 맡는 일

MCP는 AI 앱과 외부 서비스를 연결하는 공통 규약입니다. 서비스 측 MCP 서버가 사용할 수 있는 작업과 인수를 제공하면, AI 앱의 호스트가 그 설명을 모델에 전달합니다. 모델은 실행할 작업과 인수를 고르고, 앱 안의 MCP 클라이언트가 서버에 요청을 보냅니다. 서버는 기존 API나 데이터베이스를 이용해 서비스를 조작하고 결과를 앱으로 돌려줍니다. 예를 들어 고객지원 시스템에서 미처리 문의를 찾을 때 모델은 검색 도구와 조건을 고르고, 서버는 해당 시스템에서 기록을 가져옵니다.

CLI가 대안으로 거론된 이유는 에이전트가 필요한 명령의 도움말만 읽고, 실행 결과는 jq 같은 도구로 추린 뒤 최종 결과만 모델에 돌려줄 수 있기 때문입니다. 여러 작업을 스크립트로 엮거나 이미 설치된 명령줄 도구를 재사용하기도 쉽습니다. 반면 MCP를 쓰는 AI 앱이 검색에 쓰지 않을 도구 설명까지 한꺼번에 모델에 제시하거나, 검색 결과 원문을 매번 그대로 돌려주면 컨텍스트에 불필요한 정보가 쌓일 수 있습니다.

요청마다 필요한 정보를 담는 설계

이전 MCP는 먼저 initialize로 프로토콜 버전과 지원 기능을 정한 뒤 작업을 요청했습니다. 2026년 7월 개정판은 initialize와 초기화 완료 알림을 없앴습니다. 대신 각 요청의 메타데이터에 프로토콜 버전과 클라이언트 기능 정보를 담습니다. 클라이언트 이름과 버전은 클라이언트가 스스로 밝히는 권장 정보이며, 이용자 인증에는 쓰이지 않습니다. HTTP에서 서버가 발급할 수 있었던 Mcp-Session-Id도 새 사양에서 빠졌습니다. 구버전에서도 이 세션 ID 발급은 선택 사항이었습니다.

서버는 이제 같은 연결에서 앞서 처리한 요청을 바탕으로 다음 요청의 버전이나 기능을 추론하지 않습니다. 요청마다 필요한 정보가 담기므로, 앞선 요청을 받은 인스턴스와 다른 서버가 다음 요청을 처리해도 프로토콜 상태를 이어받을 필요가 없습니다. 여러 서버에 요청을 분산할 때 같은 이용자의 모든 호출을 한 인스턴스로 보내야 하는 부담도 줄어듭니다.

상태가 없어지는 범위는 MCP 통신입니다. 문의 기록이나 장바구니처럼 서비스가 관리하는 업무 데이터는 그대로 남습니다. 여러 요청에 걸쳐 이어갈 업무 상태는 서비스 데이터베이스 등에 보관하고, 다음 요청에서 문의 ID나 장바구니 ID 같은 식별자를 명시해 참조할 수 있습니다.

사용자 확인이 필요한 작업도 요청을 나눠 처리할 수 있습니다. 다만 AI 앱이 사용자에게 질문을 전달하는 Elicitation 기능을 지원하고, 요청에서 그 기능을 알린 경우에 가능합니다. 예를 들어 담당자가 문의 20건의 상태를 일괄 변경하려 하면 서버는 첫 요청에서 곧바로 기록을 바꾸는 대신 확인 질문을 응답으로 보냅니다. AI 앱이 담당자의 답을 받아 새 요청에 담으면, 서버는 답과 권한을 검증한 뒤 상태를 변경합니다. 담당자가 답할 때까지 첫 요청의 통신을 붙잡아 두지 않아도 되고, 후속 요청은 다른 인스턴스가 맡을 수 있습니다.

CLI의 장점을 MCP에서 재현하려면

MCP 개정판은 통신의 초기화와 세션 의존을 바꿨지만, 모델이 읽는 도구 설명과 검색 결과의 양을 자동으로 줄이지는 않습니다. 필요한 도구 설명만 골라 모델에 보여주는 지연 로딩은 AI 앱 호스트가 구현합니다. 검색 단계에서 상태나 우선순위, 필요한 필드를 인수로 받는 일은 도구 서버의 설계에 달려 있습니다. 여러 서비스의 데이터를 대조하거나 집계한 뒤 필요한 요약만 모델에 돌려주는 작업은 호스트의 코드 실행 환경에서 처리할 수 있습니다.

따라서 도구가 검색 조건을 받지 않고 긴 원문을 반환한다면 새 사양을 적용해도 결과가 저절로 작아지지는 않습니다. 반대로 호스트가 필요한 도구만 제시하고 서버가 검색 단계에서 결과를 추리면, CLI 파이프처럼 모델이 읽는 중간 데이터를 줄일 수 있습니다. 모델의 도구 선택 능력, 앱의 도구 노출 방식, 서버의 검색 설계는 서로 다른 층위의 변화입니다.

클라우드 환경에서는 이 구분이 운영에도 이어집니다. 개인 PC에는 이미 설치된 CLI와 설정이 있을 수 있지만, 여러 이용자가 쓰는 단기 컨테이너에서 같은 환경을 마련하려면 도구와 의존성을 배포하고 갱신해야 합니다. 원격 MCP는 서비스별 도구 구현을 서버 측에 두고 여러 AI 앱이 공통 클라이언트로 연결하는 방식을 제공합니다. 인증과 이용자별 권한 확인은 여전히 필요합니다. 기존 CLI를 없애기보다 로컬 파일 작업에는 CLI를 쓰고, 여러 앱에 제공하는 서비스 연결에는 원격 MCP를 두는 구성도 가능합니다. 이 해설은 클라우드에서 공통 서비스 연결을 운영할 때 통신 상태 관리 부담이 줄어든 점을 MCP 재평가의 이유로 짚습니다.