2026 MCP 로드맵에서 먼저 읽어야 할 에이전트 신원·보안 변화

MCP의 다음 변화는 새 도구 하나를 추가하는 수준이 아닙니다. 2026년 8월 22일 공개된 로드맵은 에이전트 간 메시징, HTTP 전송 통합, 에이전트 신원과 기업 보안을 다음 명세 주기의 핵심 과제로 제시합니다. 이미 배포된 기능과 앞으로 논의할 방향을 구분해야 잘못된 선행 구현을 피할 수 있습니다.

확인 기준일은 2026-08-30입니다. 로드맵은 방향을 설명하는 문서이므로 확정된 2026-07-28 명세와 향후 제안을 명확히 나누어 설명합니다.

목차

• 로드맵과 확정 명세를 먼저 구분하십시오
• 에이전트 메시징은 작업 위임과 섞지 마십시오
• HTTP 전송 통합은 호환성 시험이 핵심입니다
• 에이전트 신원을 사용자 계정과 나누십시오
• SDK 개선은 사양 적합성과 함께 보십시오
• 지금 준비할 것은 관찰 가능한 경계입니다

로드맵과 확정 명세를 먼저 구분하십시오

새 로드맵은 다음 사양 릴리스와 그 이후에 집중할 우선순위를 설명합니다. 2026-07-28 명세에 이미 들어간 기능과 로드맵의 미래 항목은 효력이 다릅니다.

MCP는 제안서인 SEP 검토와 기능 수명주기를 거쳐 사양을 발전시키는 구조를 채택했습니다. 도입 문서에 현재 지원, 시험 중, 향후 검토 세 상태를 분리해 표시하십시오.

제품 일정표에 로드맵 항목을 확정 기능처럼 넣으면 SDK와 서버 구현이 엇갈릴 수 있습니다. 명세 버전과 사용 중인 SDK 릴리스 노트, 관련 SEP 상태를 같은 날짜 기준으로 대조하십시오.

로드맵의 우선순위는 최종 문법이나 출시일을 보장하지 않습니다. 팀의 기준선은 로드맵 제목이 아니라 실제 배포한 명세 버전이어야 합니다.

첫 단계에서는 발표 문구와 실제 적용 조건을 분리해 적어야 합니다. 로드맵과 확정 명세를 먼저 구분하십시오 항목은 대상, 시작 시점, 필요한 준비를 서로 다른 칸에 기록하면 과도한 일반화를 줄일 수 있습니다. 특히 날짜나 버전이 바뀔 수 있는 정보는 확인한 날과 출처를 함께 남겨야 다음 점검에서 오래된 안내를 걷어낼 수 있습니다.

독자에게 필요한 결론은 새로운 기능의 존재가 아니라 현재 준비 상태에서 무엇을 바꿔야 하는지입니다. 도입 문서에 현재 지원, 시험 중, 향후 검토 세 상태를 분리해 표시하십시오. 이어서 명세 버전과 사용 중인 SDK 릴리스 노트, 관련 SEP 상태를 같은 날짜 기준으로 대조하십시오. 이 순서를 지키면 발표와 실제 적용 사이의 빈틈을 줄일 수 있습니다.

로드맵과 확정 명세를 먼저 구분하십시오을 실제 일정에 넣을 때에는 확인 순서를 고정하는 편이 좋습니다. 먼저 공식 원문에서 대상과 기준일을 찾고, 다음으로 자신의 계정·기기·예약·연령처럼 적용 조건을 맞춘 뒤, 마지막으로 완료 결과를 별도 화면에서 검증하십시오. 세 단계 가운데 하나라도 확인되지 않으면 미완료로 표시해야 합니다. 단순히 안내 페이지를 열었거나 입력 버튼을 눌렀다는 사실은 결과 확인을 대신하지 않습니다. 가족이나 팀이 함께 진행한다면 대상별 담당자와 확인 시간을 나누고, 한 사람의 성공 사례를 전체에 복사하지 마십시오.

첫 확인에서 끝내지 말고 실제 이용 또는 배포 하루 전 같은 원문을 다시 여십시오. 공지의 수정일과 적용 범위가 바뀌었다면 이전 메모에 취소선을 긋기보다 새 기준을 별도 줄로 남겨 변경 이유를 추적하는 편이 좋습니다. 최종 행동은 가장 최근의 공식 안내와 자신의 실제 상태가 일치할 때 진행하십시오.

준비물을 한곳에 모을 때에는 원문 링크, 확인 날짜, 자신의 적용 조건, 다음 확인일 네 가지를 기본 항목으로 두십시오. 화면 캡처만 저장하면 나중에 수정된 안내를 찾기 어려우므로 주소와 문서 제목도 함께 남겨야 합니다. 일정이 촉박하더라도 확인되지 않은 항목을 임의의 값으로 채우지 말고, 공식 문의가 필요한 이유와 답변을 받아야 할 시점을 표시하십시오. 이 방식은 여행 서류부터 소프트웨어 전환까지 정보의 최신성과 개인 적용 여부를 동시에 관리하는 데 도움이 됩니다.

로드맵과 확정 명세를 먼저 구분하십시오: 확인된 범위와 다음 행동을 함께 보십시오.

에이전트 메시징은 작업 위임과 섞지 마십시오

로드맵은 여러 에이전트가 장기 실행 작업을 조정할 수 있는 메시징 기본 요소를 우선 영역으로 제시합니다. 기존 Tasks 확장은 비동기 작업 수명주기에 초점을 두며 에이전트 간 대화 전체를 대신하지 않습니다.

작업 상태, 결과 전달, 취소와 재시도는 메시지 주소 지정이나 신뢰 경계와 별도 문제입니다. 설계표에서 작업 큐와 에이전트 통신 채널의 책임을 각각 적으십시오.

분석 에이전트가 실행 에이전트에 결과를 넘기는 구조에서는 누가 메시지를 보냈는지 확인해야 합니다. 현재 프로토콜로 표현 가능한 상호작용과 애플리케이션이 자체 구현한 부분을 추적하십시오.

향후 메시징 기능이 등장해도 기존 권한 모델과 감사 로그가 자동으로 해결되지는 않습니다. 메시징 도입의 목적은 에이전트 수를 늘리는 것이 아니라 위임 경계를 관찰 가능하게 만드는 데 있습니다.

에이전트 메시징은 작업 위임과 섞지 마십시오 내용을 의사결정에 쓰려면 장점만 모으지 말고 실패했을 때 돌아갈 경로도 준비해야 합니다. 적용 전 상태를 보존하고 작은 범위에서 먼저 확인한 뒤 문제가 없을 때 넓히는 순서가 적절합니다. 결과가 기대와 다르면 기능 자체보다 계정, 지역, 버전, 연결 방식의 차이를 먼저 살펴보십시오.

비교 기준은 편리함, 오류 가능성, 복구 난이도 세 가지로 잡을 수 있습니다. 분석 에이전트가 실행 에이전트에 결과를 넘기는 구조에서는 누가 메시지를 보냈는지 확인해야 합니다. 이때 향후 메시징 기능이 등장해도 기존 권한 모델과 감사 로그가 자동으로 해결되지는 않습니다.라는 경계를 남겨 두면 한 사례를 전체 상황으로 확대하지 않게 됩니다.

에이전트 메시징은 작업 위임과 섞지 마십시오에서 예상과 다른 결과가 나왔을 때에는 즉시 같은 동작을 반복하기보다 차이를 설명할 정보를 모아야 합니다. 공식 기준의 날짜와 버전, 실제 화면의 상태, 직전에 바꾼 항목, 오류가 발생한 시각을 순서대로 남기십시오. 이 기록은 고객센터나 담당자에게 문의할 때 재현 조건을 전달하는 자료가 됩니다. 결제·제출·설치처럼 중복 실행의 영향이 큰 작업은 처리 내역을 먼저 조회하고, 되돌릴 수 없는 변화라면 사람의 확인을 받은 뒤 재시도하십시오.

재시도 여부는 실패 원인을 확인한 뒤 결정하십시오. 네트워크 지연인지, 대상 조건 불일치인지, 이미 처리된 요청인지 구분하지 않으면 중복 신청과 상태 꼬임이 생길 수 있습니다. 조회 화면과 이메일·알림을 먼저 확인하고, 불확실하면 공식 지원 채널의 답변을 기다리는 편이 안전합니다.

문제가 발생했을 때 필요한 증거는 길고 복잡할 필요가 없습니다. 발생 시각, 대상, 바로 전 행동, 표시된 결과와 공식 기준의 차이를 순서대로 정리하십시오. 개인정보와 인증 정보는 가린 뒤 문의하고, 공개 게시판에는 전체 화면이나 문서 번호를 올리지 마십시오. 해결 뒤에는 어떤 조건에서 정상으로 돌아왔는지를 남겨 우연한 일시 회복과 실제 조치의 효과를 구분해야 합니다. 같은 오류가 반복되면 임의 우회보다 공식 상태 페이지와 지원 답변을 우선하십시오.

에이전트 메시징은 작업 위임과 섞지 마십시오: 확인된 범위와 다음 행동을 함께 보십시오.

HTTP 전송 통합은 호환성 시험이 핵심입니다

로드맵은 HTTP 네이티브 전송을 통합하고 보안을 강화하는 작업을 주요 과제로 꼽습니다. 2026-07-28 명세의 무상태 코어와 Streamable HTTP 방향은 배포 확장성에 영향을 줍니다.

728x90

세션 유지, 재연결, 프록시 버퍼링, 타임아웃은 같은 HTTP라는 이름 아래에서도 구현 차이가 큽니다. 클라이언트와 서버 조합별로 연결, 취소, 재시도, 큰 결과 전송을 시험하십시오.

로드밸런서 뒤에서만 끊기는 호출은 애플리케이션 코드보다 전송 정책이 원인일 수 있습니다. 프로토콜 추적에서 요청 식별자와 종료 사유가 끝까지 유지되는지 확인하십시오.

전송 통합 방향이 모든 양방향 상호작용을 무상태 방식으로 보존한다는 뜻은 아닙니다. 운영 전에는 개발 환경의 성공보다 실제 네트워크 경계에서의 실패 동작을 먼저 검증해야 합니다.

여기서는 HTTP 전송 통합은 호환성 시험이 핵심입니다 여부를 한 번 확인하는 것으로 끝내지 않는 편이 좋습니다. 준비 시점, 실행 직전, 완료 직후에 같은 기준을 다시 대조하면 정보 변경과 입력 실수를 구분할 수 있습니다. 동행자나 팀원이 있다면 확인 결과를 공유하되 여권번호, 건강정보, 계정 식별자 같은 민감정보는 남기지 마십시오.

실행 전에는 담당자와 마감 시점을 정하고 결과를 확인할 증거를 남기십시오. 클라이언트와 서버 조합별로 연결, 취소, 재시도, 큰 결과 전송을 시험하십시오. 완료 뒤에는 신청 화면이나 설정값만 믿지 말고 실제 이용 가능 여부를 점검해야 합니다.

HTTP 전송 통합은 호환성 시험이 핵심입니다을 여러 사람이 함께 준비한다면 공통 체크리스트와 개인별 확인표를 분리해야 합니다. 공통표에는 정책 날짜, 공식 링크와 시설·서비스 조건을 두고 개인표에는 여권·연령·건강 상태·기기 버전처럼 사람이나 환경마다 다른 값만 적으십시오. 공유할 필요가 없는 민감정보는 전체 문서에 복사하지 말고 당사자가 직접 확인하는 방식이 안전합니다. 완료 표시는 근거가 있는 항목에만 붙이고, 구두로 들은 내용은 문의 날짜와 답변 기관을 남겨 나중에 다시 검증할 수 있게 하십시오.

공유 문서는 편의를 위한 도구이지 개인정보 저장소가 아닙니다. 사람마다 달라지는 번호와 건강정보는 최소한으로 다루고, 완료 여부와 확인 날짜처럼 협업에 필요한 상태만 공유하십시오. 문서 접근 권한과 보관 기간을 정하면 일정이 끝난 뒤 민감한 자료가 계속 남는 문제도 줄일 수 있습니다.

여러 대상의 진행 상황은 완료·보류·문의 중 세 상태로만 관리해도 충분합니다. 완료는 결과 화면까지 검증한 경우에만 사용하고, 보류는 일정이나 지원 범위를 기다리는 경우, 문의는 공식 답변이 있어야 결론을 낼 수 있는 경우로 정하십시오. 상태 옆에 담당자와 다음 확인일을 적으면 정보가 멈추지 않습니다. 특히 사람별 자격이나 환경별 호환성이 다른 작업은 공통 완료 표시를 만들지 말고 각 행을 독립적으로 닫아야 누락을 줄일 수 있습니다.

HTTP 전송 통합은 호환성 시험이 핵심입니다: 확인된 범위와 다음 행동을 함께 보십시오.

에이전트 신원을 사용자 계정과 나누십시오

로드맵은 에이전트 신원과 기업 환경에 맞는 보안을 독립 우선순위로 제시합니다. 사용자가 로그인했다는 사실만으로 그 사용자를 대신해 행동하는 에이전트의 권한이 설명되지는 않습니다.

인간 주체, 에이전트 인스턴스, 도구 서버, 하위 작업을 구분해야 최소 권한을 적용할 수 있습니다. 감사 로그에 사용자 승인과 에이전트 실행 주체를 서로 다른 필드로 남기십시오.

같은 서비스 계정으로 여러 에이전트를 실행하면 사고 시 어느 실행이 원인이었는지 찾기 어렵습니다. 토큰 발급자, 대상 리소스, 위임 범위와 만료 시간을 호출 단위로 확인하십시오.

향후 신원 표준이 정리돼도 조직의 승인 정책과 비밀 관리 책임은 남습니다. 신원 설계는 연결 성공보다 누가 무엇을 허용했는지 설명할 수 있는 상태를 목표로 해야 합니다.

에이전트 신원을 사용자 계정과 나누십시오 판단표에는 확인된 사실, 독자에게 미치는 영향, 지금 할 일, 아직 모르는 범위를 나란히 두십시오. 이 네 칸이 채워지지 않으면 기사 제목보다 근거가 좁을 수 있습니다. 공식 문서가 다루지 않은 결과를 경험담처럼 보충하지 말고 추가 확인 항목으로 남기는 편이 안전합니다.

선택지가 여러 개라면 공식 지원 범위와 현재 환경의 호환성을 먼저 비교하십시오. 토큰 발급자, 대상 리소스, 위임 범위와 만료 시간을 호출 단위로 확인하십시오. 이후 차이가 생긴 이유를 기록하면 다음 변경 때 같은 검사를 반복하지 않아도 됩니다.

에이전트 신원을 사용자 계정과 나누십시오 관련 선택을 비교할 때에는 비용만 보지 말고 시간, 실패 영향과 복구 가능성을 함께 평가해야 합니다. 지금 진행했을 때 얻는 이점, 다음 공식 일정까지 기다렸을 때의 불편, 잘못 적용했을 때 원래 상태로 돌아가는 방법을 한 줄씩 적으십시오. 세 항목을 나란히 보면 긴급한 필수 조치와 단순한 편의 개선을 구분하기 쉬워집니다. 근거가 부족한 선택은 자신 있게 추정하지 말고 보류 상태로 두며, 마감이 있는 경우에는 공식 문의처에 확인할 시간을 일정에 포함하십시오.

비용이 드는 선택은 총액과 환불·해지 조건을 함께 확인하십시오. 무료, 지원, 미리보기, 선택이라는 표현이 모든 부가 항목과 위험을 없앤다는 뜻은 아닙니다. 최종 화면이나 계약·고지에서 실제 부담과 되돌릴 수 있는 시점을 확인한 뒤 결정을 확정하십시오.

결정을 서두르게 만드는 표현도 점검 대상입니다. 한정, 필수, 즉시, 무료 같은 단어는 적용 기간과 대상을 함께 읽어야 하며, 공식 자료가 아니라 광고나 요약문에서만 보인다면 근거로 사용하지 마십시오. 조건이 복잡할수록 최종 행동 직전에는 실제 고지와 계약·설정·예약 화면을 확인해야 합니다. 선택을 미루는 비용과 지금 진행하는 위험을 함께 비교하면 과도한 낙관이나 불안을 피하고 자신의 상황에 맞는 시점을 정할 수 있습니다.

에이전트 신원을 사용자 계정과 나누십시오: 확인된 범위와 다음 행동을 함께 보십시오.

SDK 개선은 사양 적합성과 함께 보십시오

로드맵은 SDK 개발자 경험과 기본 요소 개선도 핵심 작업으로 포함합니다. 편리한 헬퍼가 늘어나더라도 서로 다른 언어 SDK가 같은 사양 의미를 구현하는지 확인해야 합니다.

타입 모델, 오류 표현, 기능 협상 방식의 차이는 다중 언어 시스템에서 호환성 문제를 만듭니다. 지원 언어마다 동일한 적합성 시나리오를 실행하고 결과를 비교하십시오.

Python 클라이언트만 통과한 시험을 TypeScript와 Java 서버의 보장으로 확대하면 안 됩니다. SDK 버전표에 지원 명세, 폐기 예정 API, 전송 기본값을 함께 기록하십시오.

로드맵의 개발자 경험 개선이 기존 비호환 코드를 자동 수정해 주지는 않습니다. 업그레이드는 라이브러리 번호보다 기능 협상과 오류 처리의 실제 차이를 기준으로 판단해야 합니다.

운영이나 여행 일정에 SDK 개선은 사양 적합성과 함께 보십시오 내용을 반영할 때에는 필수 조치와 선택 조치를 구분해야 합니다. 필수 조건을 먼저 끝내고 편의 기능이나 최적화는 그다음에 시험하면 문제가 생겼을 때 원인을 좁히기 쉽습니다. 비용이나 시간이 드는 선택은 취소·복구 조건을 확인한 뒤 결정하십시오.

주의 문구는 부정적인 장식이 아니라 중단 기준입니다. 로드맵의 개발자 경험 개선이 기존 비호환 코드를 자동 수정해 주지는 않습니다. 이 조건에 걸리면 억지로 진행하지 말고 공식 문의처나 담당 기관의 최신 답변을 확인하는 편이 낫습니다.

SDK 개선은 사양 적합성과 함께 보십시오은 준비 당일의 한 번짜리 확인으로 끝나지 않습니다. 예약·여행·접종은 이용일 직전에 조건이 바뀔 수 있고, 소프트웨어는 배포 뒤 알려진 문제와 지원 범위가 갱신될 수 있습니다. 준비 시점에는 자격과 사전 조건을, 실행 직전에는 운영 상태와 취소·복구 경로를, 완료 뒤에는 실제 결과와 이상 징후를 확인하십시오. 각 단계의 확인 날짜를 남기면 오래된 화면 캡처와 현재 안내를 혼동하지 않으며, 변경이 발견됐을 때 어느 결정부터 다시 검토해야 하는지도 알 수 있습니다.

변경 감시는 알림 하나에만 맡기지 않는 편이 좋습니다. 출발·설치·접종·이용 시점에 공식 페이지를 직접 열고 운영 상태와 공지 날짜를 확인하십시오. 중요한 변경은 동행자나 담당자에게 공유하고, 기존 계획의 어느 항목이 영향을 받는지 다시 표시하십시오.

점검 일정을 만들 때에는 최초 준비와 최종 확인 사이에 여유를 두십시오. 문의 답변, 재고와 예약 상태, 업데이트 배포처럼 사용자가 통제할 수 없는 요소는 바로 해결되지 않을 수 있습니다. 마감 당일에 처음 확인하면 대체 수단을 선택할 시간이 없습니다. 반대로 너무 이른 정보만 믿으면 이후 변경을 놓치므로 중간 확인일을 하나 더 두는 편이 좋습니다. 변경이 없다면 그대로 진행하고, 변경이 있다면 영향을 받는 단계만 다시 검토해 불필요한 반복을 줄이십시오.

SDK 개선은 사양 적합성과 함께 보십시오: 확인된 범위와 다음 행동을 함께 보십시오.

지금 준비할 것은 관찰 가능한 경계입니다

새 기능을 기다리는 동안에도 신원, 권한, 전송, 작업 상태를 관찰 가능하게 만드는 준비는 진행할 수 있습니다. 로드맵이 바뀌어도 명확한 책임 경계와 상호운용 시험은 재사용할 수 있습니다.

현재 자체 구현한 확장 지점을 목록화하면 표준 기능으로 이동할 때 교체 범위를 줄일 수 있습니다. 서버와 클라이언트의 명세 버전, 기능 플래그, 감사 로그를 한 대시보드에 묶으십시오.

다음 사양이 나오기 전에 비표준 메시징을 깊게 고정하면 마이그레이션 비용이 커질 수 있습니다. MCP 블로그, 사양 변경 기록, SDK 릴리스를 정기 검토하는 담당자를 정하십시오.

예정 기능을 전제로 한 보안 약속이나 고객 계약은 확정 명세가 나오기 전에는 피해야 합니다. 가장 안전한 선행 투자는 기능 추측이 아니라 실패를 설명하고 되돌릴 수 있는 운영 기반입니다.

마지막 검수에서는 지금 준비할 것은 관찰 가능한 경계입니다 관련 화면이나 문서의 제목만 보지 말고 실제 상태를 확인하십시오. 버전 번호, 처리 결과, 예약 상태, 접종 대상처럼 결론을 좌우하는 값이 근거와 일치해야 합니다. 확정되지 않은 일정은 예정이라고 표시하고 출발일·배포일·이용일에 공식 안내를 다시 여는 절차를 남기십시오.

최종 결정은 확인 날짜와 실제 대상이 맞을 때만 유효합니다. 가장 안전한 선행 투자는 기능 추측이 아니라 실패를 설명하고 되돌릴 수 있는 운영 기반입니다. 이후에도 일정이나 버전이 바뀌면 같은 체크리스트를 다시 적용하십시오.

지금 준비할 것은 관찰 가능한 경계입니다 검수는 정상 결과뿐 아니라 실패했을 때의 행동까지 포함해야 합니다. 연락할 기관, 준비할 주문·예약·버전 정보, 중단해야 할 증상이나 오류, 대체 일정과 복구 방법을 미리 적으십시오. 현장에서 당황해 비공식 링크나 출처 불명의 해결책을 선택하는 일을 줄일 수 있습니다. 공식 답변을 받았다면 답변 일시와 적용 대상을 기록하고 개인 경험과 정책을 구분하십시오. 최종 체크에서는 필수 조건이 모두 충족됐는지, 아직 확인되지 않은 항목이 결론을 바꿀 정도인지 다시 판단하십시오.

완료 뒤에는 결과가 기대와 맞는지 짧게 점검하고 기록을 정리하십시오. 문제가 없다면 불필요한 개인정보와 임시 파일을 정리하고, 문제가 있다면 원래 상태와 현재 상태의 차이를 보존하십시오. 이런 마무리가 다음 일정이나 업데이트에서 같은 실수를 반복하지 않게 합니다.

최종 기록에는 성공 여부만 아니라 아직 남은 제한도 포함하십시오. 정상 완료가 모든 상황의 보장으로 확대되지 않도록 확인한 대상과 환경을 적고, 다음 갱신이나 이용 시점에 다시 볼 항목을 남기십시오. 공식 안내가 변경되거나 새로운 이상 징후가 나타나면 과거 결론을 고집하지 말고 현재 상태에서 다시 평가해야 합니다. 이런 기록은 다른 사람에게 무조건 같은 행동을 권하지 않으면서도 검증 가능한 경험과 정책 정보를 구분해 전달하는 기준이 됩니다.

지금 준비할 것은 관찰 가능한 경계입니다: 확인된 범위와 다음 행동을 함께 보십시오.

이번 로드맵의 가치는 다음 기능을 맞히는 데 있지 않습니다. 에이전트 메시징과 Tasks, HTTP 전송과 세션, 사용자 신원과 에이전트 신원을 분리해 볼 기준을 제공한다는 점이 중요합니다. 현재 명세에 근거한 구현을 유지하면서 관련 SEP와 SDK 적합성 시험을 따라가십시오.

참고한 자료

• The New MCP Roadmap
• MCP Specification 2026-07-28

태그: MCP, AI 에이전트, 에이전트 보안, MCP 로드맵, Agent Identity, Streamable HTTP