MCP 업데이트 2026년 7월, 뭐가 달라졌나요

AI 에이전트가 여러 사무실 프로그램과 연결되는 표준으로 자리잡은 MCP(Model Context Protocol)에 2026년 7월 28일, 올해 들어 가장 큰 폭의 스펙 업데이트가 나왔습니다. 이번 업데이트로 MCP는 실행 방식 자체가 바뀌었고, 인증·보안 방식도 한층 강화됐습니다. “MCP 업데이트로 우리 회사가 지금 당장 뭘 해야 하나”라는 질문을 가진 실무자를 위해, 이번 변경의 핵심과 도입 전 점검할 점을 정리했습니다.

MCP 업데이트, 뭐가 달라졌나요

가장 큰 변화는 MCP가 양방향 상태 유지형 프로토콜에서 요청-응답 모델로 이동한다는 점입니다. 이 덕분에 서버가 서버리스나 엣지 인프라에도 배포될 수 있게 됐습니다. 여기에 더 강력한 OAuth·OIDC 인증 체계와 Apps·Tasks용 버전 확장 기능이 새로 추가됐습니다. 실무자 입장에서 요약하면, MCP가 “실험적인 연결 규격”에서 “기업이 안심하고 붙일 수 있는 표준 인프라”로 한 단계 올라선 업데이트라고 볼 수 있습니다.

MCP가 뭐였는지 다시 짚어보면

MCP는 Claude 같은 AI 모델이 사내 시스템, 문서함, 업무 툴과 대화하듯 데이터를 주고받을 수 있게 해주는 연결 규격입니다. 이미 여러 업무 툴이 “MCP로 연결됩니다”라고 선언하고 있는 흐름은 사무실 프로그램들이 MCP로 연결됩니다 글에서 다룬 바 있습니다. 이번 7월 업데이트는 그 연결 표준 자체의 내부 구조를 손본 것이라, 이미 MCP 연동을 검토 중이거나 도입한 회사라면 지나칠 수 없는 소식입니다.

왜 지금 이 업데이트가 중요한가요

MCP는 최근 월간 SDK 다운로드 수가 4억 건을 넘어섰고, 이는 올해 들어 4배 증가한 수치이며 AI 에이전트를 애플리케이션에 연결하는 업계 표준으로 자리잡았습니다. 즉 MCP는 더 이상 일부 개발자만 쓰는 실험적 프로토콜이 아니라, 이미 많은 SaaS·업무 도구가 표준으로 채택한 연결 방식이라는 뜻입니다. 이런 상황에서 스펙이 바뀌면 그 파급 범위도 넓을 수밖에 없습니다.

이번 업데이트는 가장 중요한 스펙 릴리스 중 하나로 평가되는데, 핵심은 상태 비저장(stateless) 코어입니다. 기존 방식은 클라이언트와 서버가 연결을 계속 유지해야 했지만, 이제는 요청마다 독립적으로 처리할 수 있어 서버 운영 부담이 줄어듭니다. 또한 임베디드 UI, 엔터프라이즈 관리형 인증, 관측성(observability), 프라이빗 네트워크 터널 같은 커넥터 신기능도 함께 강조됐습니다.

Anthropic은 이 업데이트가 개발자들이 더 낮은 마찰과 더 일관된 최종 사용자 경험으로 Claude에 더 많은 애플리케이션을 연결하도록 도울 것이라고 밝혔으며, MCP를 오픈 표준으로 계속 투자하겠다고 설명했습니다. 지원은 Claude 제품 전반에 점차 확대될 예정입니다.

MCP 2026-07-28 업데이트 핵심 요약

중소기업 실무자가 지금 점검할 점

먼저, 우리 회사가 쓰는 업무 툴 중 MCP 커넥터를 이미 붙였거나 붙일 예정인 도구가 있는지 확인해야 합니다. 벤더가 “MCP 지원”이라고만 표기했다면, 신규 스펙(2026-07-28) 기준인지 구버전 기준인지 물어볼 필요가 있습니다. 특히 인증 방식이 강화된 만큼, 사내 계정 관리 정책과 충돌하지 않는지 IT 담당자가 미리 점검하는 편이 안전합니다.

둘째, 상태 비저장 구조로 바뀌면서 서버 쪽 배포가 가벼워졌다는 것은, 앞으로 더 많은 소규모 벤더나 사내 개발팀도 자체 MCP 서버를 쉽게 만들 수 있다는 의미이기도 합니다. 실제로 사내에서 사용하는 그룹웨어나 결재 시스템에 자체 커넥터를 붙이는 시나리오를 검토하는 회사라면, 이번 스펙 변경 이후 진입장벽이 낮아졌다는 점을 참고할 만합니다. 간단한 커넥터 상태를 코드로 점검하는 예시는 다음과 같습니다.

import requests

def check_mcp_server(url):
    try:
        res = requests.get(f"{url}/health", timeout=3)
        return res.status_code == 200
    except requests.exceptions.RequestException:
        return False

servers = ["https://internal-erp.example.com/mcp", "https://docs.example.com/mcp"]
for s in servers:
    status = "정상" if check_mcp_server(s) else "확인 필요"
    print(f"{s}: {status}")

이런 헬스체크 스크립트는 거창한 도구 없이도 사내 MCP 연동 상태를 주기적으로 확인하는 데 활용할 수 있습니다. 물론 실제 인증 토큰 발급이나 OAuth 흐름까지 검증하려면 더 정교한 점검이 필요하지만, 첫 단계로는 충분합니다.

셋째, MCP 커넥터가 늘어날수록 관리 부담도 함께 늘어난다는 점을 잊지 말아야 합니다. 여러 업무 툴에 에이전트가 개별적으로 들어오면서 생기는 이력 관리와 권한 문제는 에이전트가 늘어난 사무실, 이제는 관리가 필요합니다 글에서 정리한 것처럼, 커넥터 하나하나를 누가 승인했고 어떤 데이터에 접근하는지 기록해두는 습관이 필요합니다. MCP 신규 스펙이 인증을 강화한다고 해서 사내 검증 절차까지 자동으로 안전해지는 것은 아니기 때문입니다.

결재 시스템에 AI를 붙이려면 뭘 먼저 봐야 하나요

결재나 문서 승인 시스템처럼 민감한 사내 데이터를 다루는 곳에 MCP 커넥터를 붙이려면, 먼저 신규 스펙의 인증 방식(OAuth·OIDC)이 우리 회사의 SSO·계정 체계와 호환되는지부터 확인해야 합니다. 그다음 어떤 데이터 범위까지 접근을 허용할지 범위(scope)를 최소한으로 좁혀서 시작하는 것이 안전합니다. 마지막으로 접근 로그를 남기는 관측성 기능을 활성화해 사후 검증이 가능하도록 준비해야 합니다.

이 세 가지는 순서가 중요합니다. 인증 호환성을 먼저 확인하지 않고 범위부터 정하면 나중에 계정 체계를 바꿔야 하는 상황이 생길 수 있고, 로그 기능을 마지막에 켜면 초기 도입 단계의 오류를 추적하기 어려워집니다. 특히 B2G 환경처럼 문서 보안이 중요한 조직이라면 관측성 기능을 처음부터 필수 조건으로 두는 편이 낫습니다.

MCP, SI 프로젝트에는 어떤 의미인가요

맞춤형 소프트웨어를 개발하거나 유지보수하는 입장에서 보면, MCP 표준화는 앞으로 발주처가 “AI 에이전트 연동”을 요구사항에 넣을 가능성이 커진다는 신호이기도 합니다. 신규 스펙이 서버리스 배포를 지원하면서 개발 난이도와 인프라 비용 부담이 줄었다는 점은, 중소 규모 프로젝트에서도 MCP 커넥터 개발을 검토할 만해졌다는 뜻입니다. 다만 표준이 자주 바뀌는 시기인 만큼, 특정 벤더나 특정 스펙 버전에 지나치게 종속되지 않도록 설계 단계에서부터 버전 호환성을 염두에 두는 것이 중요합니다.

MCP처럼 빠르게 표준화되는 연결 규격은 도입 시점의 판단이 이후 유지보수 부담을 크게 좌우합니다. 픽셀앤코드는 맞춤형 소프트웨어 개발과 하드웨어 유지보수를 함께 다루는 만큼, 사내 시스템에 AI 에이전트 연동을 검토 중인 기업이라면 어떤 스펙 기준으로 커넥터를 설계해야 장기적으로 안전한지부터 함께 점검해 드릴 수 있습니다.