MCP 2026-07-28은 AgentCore 운영을 어떻게 바꾸나

원격 MCP 서버는 HTTP 위에서 동작했지만 평범한 API처럼 확장하기는 어려웠다. 요청 사이의 문맥 일부가 연결에 묶여 있었기 때문이다. 인스턴스를 수평 확장하려면 같은 클라이언트를 같은 서버로 보내거나 모든 서버가 공유하는 세션 저장소가 필요했다.

2026년 7월 28일 공개된 MCP 2026-07-28은 이 전제를 바꿨다. 이제 요청 하나가 사용하는 버전과 호출 기능, 필요한 클라이언트 정보를 직접 설명한다. 서버 능력을 미리 알아야 하는 클라이언트만 별도 탐색 기능을 호출한다. MCP를 연결 수명주기보다 HTTP 요청을 중심으로 운영할 수 있게 된 셈이다.¹

AgentCore 기반 에이전트도 영향을 받는다. 전송 계층이 stateless가 됐다고 해서 에이전트의 실행 상태와 업무 상태까지 없어지는 것은 아니다. 이번 변경을 배포 관점에서 이해하려면 어떤 상태가 사라지고 어떤 상태가 자리를 옮기는지부터 나눠 봐야 한다.

사라진 것은 상태가 아니라 전송 세션이다

AgentCore에서 상태는 적어도 세 층으로 나뉜다.

이번 스펙이 없앤 것은 첫 번째 층이다. Runtime의 세션 격리나 Memory까지 없애는 변경이 아니다. 여러 호출에 걸친 작업은 job_id나 browser_id 같은 핸들을 발급하고 다음 도구 호출의 인수에 다시 담아 이어간다.

예전에는 처리 상태가 연결 뒤에 숨어 있었고 서버가 문맥을 찾아냈다. 이제 모델과 애플리케이션이 상태 식별자를 직접 다룬다. 운영 인프라는 단순해지지만 핸들의 만료와 소유자는 애플리케이션의 설계 몫으로 남는다. 재사용 권한과 멱등성도 마찬가지다. 결제·삭제·외부 전송처럼 되돌리기 어려운 도구라면 부담이 더 크다.

Payload는 세션 정보 대신 요청 정보를 담는다

운영 구조를 이해하는 데 세부 필드를 외울 필요는 없다. 실제 전환에서는 요청이 어떻게 달라지는지만 한 번 비교하면 충분하다. 이전 버전의 후속 도구 호출은 서버가 발급한 세션 식별자를 되돌려 보냈다.

POST /mcp HTTP/1.1
Mcp-Session-Id: <session-id>
Content-Type: application/json
Accept: application/json

{"jsonrpc":"2.0","id":41,"method":"tools/call","params":{"name":"continue_job","arguments":{"job_id":"job_01"}}}

2026-07-28 요청은 버전과 호출 의도를 헤더에 드러내고 클라이언트 정보는 요청 본문에 담는다. Gateway나 WAF 같은 HTTP 중간 계층은 본문을 열지 않고도 어떤 작업인지 판별한다. 본문은 여전히 최종 기준으로 남는다.

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: continue_job
Content-Type: application/json
Accept: application/json,text/event-stream

{"jsonrpc":"2.0","id":41,"method":"tools/call","params":{"name":"continue_job","arguments":{"job_id":"job_01"},"_meta":{"io.modelcontextprotocol/clientInfo":{"name":"agentcore-agent","version":"1.0"}}}}

여기서 job_id는 MCP 세션의 대체품이 아니다. 업무 시스템이 소유하는 상태 핸들이다. 도구는 첫 응답에서 핸들을 반환하고 에이전트는 다음 요청의 인수로 돌려준다.

{
  "name": "continue_job",
  "arguments": {
    "job_id": "job_01",
    "approval_id": "approval_07"
  }
}

이 구분은 보안 경계에도 영향을 준다. Gateway는 호출 주체와 도구 권한을 검사하고 target은 job_id가 그 주체에게 허용된 값인지 다시 확인한다. 핸들의 만료와 재사용, 중복 요청 처리도 target이나 업무 저장소가 책임진다.

AgentCore에서 실제로 바뀌는 범위

변화의 크기는 AgentCore의 어느 계층을 운영하는지에 따라 다르다.

AgentCore Gateway는 Lambda 함수나 OpenAPI·Smithy API를 MCP 도구로 변환한다. 이 구성에서 바뀌는 범위는 작다. MCP 버전은 개별 target이 아니라 Gateway 속성이다. supportedVersions에 2026-07-28을 추가해도 Lambda와 기존 API의 입력 계약은 그대로 둘 수 있다.²

에이전트 쪽에서는 MCP 클라이언트 SDK가 새 버전을 실제로 선택하는지 확인한다. 프레임워크가 SDK를 내부에 감추는 경우에는 패키지 버전만 보고 판단하지 말고 Gateway 접근 로그에서 요청 버전을 확인하는 편이 안전하다.

Gateway 뒤에 자체 MCP 서버를 연결했다면 검증 범위가 넓어진다. AgentCore Gateway는 일반 도구 호출을 구버전과 새 버전 사이에서 변환하지만 2025 계열 클라이언트가 2026 서버의 Elicitation이나 Sampling을 호출하는 경로는 변환 대상이 아니다. 클라이언트, Gateway, 대상 서버가 같은 capability를 지원하는지 전체 경로로 시험한다.²

AgentCore Gateway의 버전 지원은 다음처럼 단계적으로 열 수 있다. 먼저 현재 설정을 읽고 구버전과 새 버전을 모두 담은 전체 목록으로 갱신한다.

aws bedrock-agentcore-control get-gateway \
  --gateway-identifier <gateway-id>

aws bedrock-agentcore-control update-gateway \
  --name <gateway-name> \
  --role-arn <gateway-role-arn> \
  --protocol-type MCP \
  --authorizer-type <gateway-authorizer-type> \
  --gateway-identifier <gateway-id> \
  --protocol-configuration '{
    "mcp": {
      "supportedVersions": ["2025-11-25", "2026-07-28"]
    }
  }'

함정이 하나 있다. UpdateGateway는 버전 목록에 새 값을 덧붙이지 않고 전달받은 목록 전체로 교체한다. 현재 구성을 읽지 않고 새 버전 하나만 보내면 구형 클라이언트를 끊을 수 있다. 버전 헤더를 생략한 요청은 2025-03-26으로 처리되므로, 명시적인 버전 전송도 회귀 테스트에 넣는다.

운영 인프라가 얻는 이점

가장 직접적인 이점은 수평 확장이다. 요청이 특정 인스턴스의 프로토콜 세션에 묶이지 않아 라운드로빈 로드 밸런싱과 서버리스 실행 환경을 쓰기 쉬워진다. 기존 업무 상태가 별도 저장소에 남더라도 MCP 때문에 필요했던 sticky routing과 공유 세션 저장소는 제거 후보가 된다.

Mcp-Method와 Mcp-Name을 사용하면 Gateway, WAF, rate limiter가 JSON-RPC 본문을 열지 않고 요청 성격을 구분한다. 도구별 제한, 라우팅, 비용 배분, 지연 지표도 표준 HTTP 계층에서 만들 수 있다. 서버는 헤더와 본문이 다르면 요청을 거부하므로 중간 계층이 헤더만 믿는 오류도 줄어든다.

도구와 리소스 목록에는 ttlMs와 cacheScope가 생겼다. 자주 바뀌지 않는 tools/list를 반복 호출하지 않아도 되고 재연결 뒤에도 도구 순서가 안정돼 상위 prompt cache가 흔들리는 일을 줄인다. W3C Trace Context도 _meta에 표준화돼 MCP host에서 Gateway와 target 서비스까지 같은 trace를 잇기 쉬워졌다.

분산 추적과 경보를 어느 수준까지 운영할지는 옵저버빌리티 성숙도 모델의 평가 기준으로 이어서 점검할 수 있다.

오류도 HTTP 계층과 애플리케이션 계층으로 나뉜다. 지원하지 않는 버전은 HTTP 400과 -32022, 헤더와 본문 불일치는 HTTP 400과 -32020, 알 수 없는 메서드는 HTTP 404로 나타난다. 모니터링 시스템은 JSON-RPC 본문을 파싱하지 않고도 배포 오류와 애플리케이션 실패를 구분한다.

이 장점이 곧 비용 절감을 뜻하지는 않는다. 이미 Gateway가 세션 처리를 대신했거나 업무 상태 때문에 공유 저장소가 필요했다면 제거할 인프라가 적다. 도입 효과는 없어진 구성 요소와 배포 선택지, 장애 대응 시간으로 측정한다. 실제 측정 없이 “서버리스이므로 더 싸다”고 결론 내릴 수는 없다.

단순해진 만큼 애플리케이션이 책임질 것도 늘었다

명시적인 상태 설계에는 새 부담이 따른다. 핸들이 요청에 드러나면 관측과 재현은 쉬워지지만 탈취와 재사용 위험도 커진다. 핸들은 예측하기 어렵게 만들고 인증 주체와 묶는다. 만료와 폐기, 같은 요청이 다시 왔을 때의 멱등성도 함께 정한다.

캐시 경계도 조심해야 한다. cacheScope: "private"인 도구 목록이나 리소스 결과를 다른 인증 주체와 공유하면 권한 정보나 데이터가 섞인다. 반대로 TTL을 무조건 0으로 두면 새 캐시 계약의 이점을 얻지 못한다. 도구 catalog가 사용자별로 달라지는 시스템은 인증 context를 cache key에 포함한다.

호환성 행렬은 커진다. Gateway가 두 프로토콜 버전을 동시에 제공하는 동안 클라이언트, Gateway, 대상의 버전과 확장 지원 여부를 함께 시험해야 한다. 코어 버전을 지원한다는 사실만으로 MCP Apps나 Tasks까지 지원한다고 볼 수 없다. Extension은 별도 버전과 capability 협상을 거친다.

기존 기능의 정리도 남아 있다. Roots, Sampling, Logging과 legacy HTTP+SSE transport는 deprecated 상태로 들어갔다. 바로 제거되지는 않고 최소 12개월의 유예가 있지만 새 구현은 의존하지 않는 편이 낫다. 실험 단계의 2025 Tasks API를 사용했다면 새 io.modelcontextprotocol/tasks extension의 tasks/get, tasks/update, tasks/cancel 수명주기로 다시 설계한다.¹

인증도 확인할 부분이 있다. 새 스펙은 RFC 9207의 iss 검증을 요구하고 credential을 발급 issuer에 묶는다. Dynamic Client Registration은 Client ID Metadata Documents를 향한 전환 과정에서 deprecated가 됐다. AgentCore Gateway의 기존 IAM 또는 OAuth/JWT authorizer 설정은 프로토콜 버전만 올린다고 바뀌지 않는다. 자체 MCP OAuth 클라이언트와 서버의 issuer와 등록 흐름은 별도 점검 대상이다.

Apps와 Tasks는 코어 업그레이드와 따로 판단한다

MCP Extensions가 정식 체계를 얻으면서 장기 운영의 예측 가능성이 높아졌다. MCP는 새 능력을 코어에 계속 넣어 breaking release를 만드는 대신 독립된 ID와 버전으로 협상한다. 지원하지 않는 클라이언트와 서버는 해당 확장을 사용하지 않으면 된다. AAIF도 이 변화의 의미를 기능 추가보다 enterprise infrastructure에 필요한 운영 예측성과 보안 강화에서 찾는다.³

MCP Apps는 도구 서버가 상호작용형 HTML UI를 제공하고 호스트가 sandbox iframe에서 이를 렌더링하는 확장이다. Tasks는 오래 걸리는 작업에 지속성 있는 핸들을 반환하고 클라이언트가 진행 상태를 조회·갱신·취소하는 확장이다. 연결을 오래 붙잡지 않아도 장애나 재접속 뒤 작업을 이어갈 수 있다는 점이 stateless core와 잘 맞는다.

AgentCore Gateway에 2026-07-28을 추가하는 일과 Tasks를 운영에 넣는 일은 같은 변경이 아니다. 호스트, 클라이언트 SDK, Gateway, 대상 서버가 확장을 지원해야 한다. Claude도 새 스펙 지원을 제품별로 순차 배포한다고 밝혔으므로 특정 호스트가 오늘 모든 확장을 쓴다고 가정하면 안 된다.⁴

장시간 작업이라는 이유만으로 Tasks를 바로 채택하지 않아도 된다. 이미 Step Functions, SQS, EventBridge나 업무 시스템의 job API로 검증된 비동기 수명주기가 있다면 Tasks는 실행 계층을 대체하기보다 표준 MCP 표면을 제공하는 편이 맞다. task handle을 내부 job ID에 매핑하고 취소를 전파하고 보존 기간을 정한다.

지금 도입할지 판단하는 기준

새 스펙을 채택하기 좋은 시스템은 상태가 없는 시스템이 아니다. 전송 상태와 업무 상태의 경계가 이미 분명한 시스템이다.

전환은 네 단계면 충분하다

출발점은 의존성 조사다. 코드와 인프라에서 initialize, initialized, Mcp-Session-Id, logging/setLevel, -32002, Roots, Sampling, 구형 Tasks API를 찾는다. 사용 중인 에이전트 프레임워크와 MCP SDK가 2026-07-28을 실제로 지원하는지도 확인한다.

그다음 Gateway에 구버전과 새 버전을 함께 게시한다. 새 버전을 요청하는 canary 클라이언트만 2026 경로를 쓰게 하고 기존 클라이언트는 그대로 둔다. Gateway 설정과 클라이언트 배포를 같은 날 강제로 묶을 이유가 없다.

이제 인스턴스를 바꿔 가며 검증한다. 같은 상태 handle로 후속 요청을 다른 인스턴스에 보내고 결과가 이어지는지 본다. 도구별 rate limit, trace 연결, cache 격리, 재시도와 중복 실행도 함께 확인한다. Elicitation과 Sampling이 있다면 구버전과 새 버전 조합별 실패를 별도 시나리오로 둔다.

마지막은 구버전 종료다. 모든 클라이언트가 새 버전을 명시하고 fallback이 검증된 뒤에만 supportedVersions에서 구버전을 뺀다. 목록 교체 전 현재 값을 기록하고 문제가 생기면 이전 전체 목록으로 되돌린다. 일반적인 AI 운영 전환과 마찬가지로 출시보다 롤백 기준과 증거를 먼저 정하는 게이트가 필요하다.

MCP가 평범한 HTTP에 가까워졌다는 의미

MCP 2026-07-28의 가장 큰 변화는 기능 수가 아니다. initialize와 Mcp-Session-Id가 사라지면서 프로토콜이 인프라에 요구하던 두 가지 숨은 계약이 없어졌다. 이 관점은 일본어권 해설에서도 “세션 관리에서의 졸업”이라는 표현으로 잘 압축됐다.⁵

AgentCore Gateway가 Lambda와 API를 MCP로 바꾸는 구성이라면 새 버전 도입은 비교적 얇은 경계 변경으로 끝날 수 있다. 자체 MCP 서버가 세션에 문맥을 숨겨 왔다면 얘기가 다르다. 애플리케이션이 명시적 상태와 권한 설계로 그 복잡성을 떠안는다.

그래서 이번 업그레이드의 질문은 “stateless가 더 좋은가”가 아니다. 어떤 상태를 프로토콜이 대신 들고 있었고 그 상태를 이제 누가 책임질지 묻는 일이다. 답이 분명하다면 서버리스와 수평 확장, 표준 관측성의 이점을 얻는다. 답이 흐리다면 버전 플래그를 켜기 전에 상태부터 정리한다.

웹사이트가 MCP endpoint를 발견하고 사용하는 앞단의 준비는 에이전트 준비도를 직접 구현한 과정에서 다뤘다. 이 글은 다음 단계인 운영 프로토콜과 배포 경계를 다룬다.

AgentCore Gateway와 MCP 서버의 버전 전환, 권한 경계, 배포 구조를 함께 설계해야 한다면 클라우드 & 인프라에서 시작할 수 있다. 에이전트의 도구·평가·업무 흐름까지 연결하는 작업은 AX 컨설팅으로 이어진다.

참고 자료