확장으로 넘어간 감사·인증·게이트웨이
Model Context Protocol 운영진이 공개한 2026 로드맵은 우선순위 4개 축 중 하나로 "엔터프라이즈 준비"를 꼽으면서, 감사 로그(audit trail)·SSO 연동·게이트웨이 동작·설정 이식성을 코어 스펙이 아니라 확장(extension)으로 다루겠다고 명시했습니다. 즉 이 네 항목은 프로토콜이 표준 스키마를 정해주지 않고, 서버·게이트웨이를 운영하는 쪽이 직접 설계해야 하는 영역으로 남습니다.
2026-07-28 최종 스펙은 이 방향을 앞서 구체화했습니다. Tasks가 io.modelcontextprotocol/tasks 확장으로, MCP Apps와 EMA(Enterprise Managed Authorization)가 같은 확장 프레임워크 아래로 편입되면서, 감사·설정 이식성도 동일한 트랙으로 갈 신호가 뚜렷해졌습니다.
왜 지금 설계를 미루면 안 되는가
코어가 아닌 확장이라는 말은 "선택 사항"이 아니라 "우리 조직이 직접 버전을 고정하고 검증해야 한다"는 뜻입니다. 헤더 기반 라우팅(Mcp-Method, Mcp-Name)으로 게이트웨이가 JSON 본문을 파싱하지 않고도 메터링할 수 있게 됐지만, 이 헤더를 못 읽는 구형 게이트웨이는 트래픽을 조용히 놓칩니다. 확장 버전을 환경마다 다르게 고정해 두면 감사 로그 스키마가 dev·staging·prod에서 서로 어긋나는 사고로 이어집니다.
설계에서 운영까지: MCP 엔터프라이즈 확장 배포 거버넌스 체크리스트
기획 단계에서는 목표 지표부터 숫자로 고정합니다. 감사 이벤트 커버리지(도구 호출·인증 실패·권한 변경 3종) 100%, 배포 전 설정 드리프트 탐지율 100%, 게이트웨이 라우팅 오분류율 1% 이하, 신규 확장 버전 롤아웃 후 24시간 관측을 기본 합격선으로 둡니다.
실패 패턴은 크게 세 갈래로 나타납니다. 첫째, 감사 확장 버전을 환경별로 따로 고정해 로그 필드가 어긋나는 경우. 둘째, SSO·게이트웨이 정책을 코드에 하드코딩해 설정 이식성이 깨지는 경우 — 신규 환경을 열 때마다 수작업 재설정이 필요해집니다. 셋째, 헤더 기반 라우팅을 지원하지 않는 레거시 게이트웨이를 그대로 둬 메터링 수치가 실제 트래픽보다 낮게 잡히는 경우입니다.
복구 전략은 확장 버전 단위로 설계해야 합니다. 감사 로그 스키마가 깨지면 이전 확장 핀으로 즉시 되돌리고, 설정 드리프트가 감지되면 배포를 자동 중단한 뒤 사람 승인을 받습니다. 게이트웨이 헬스체크가 연속 3회 실패하면 트래픽을 이전 세대 게이트웨이로 넘기는 백오프 규칙을 둡니다.
운영 체크리스트에서는 배포 전 시나리오 테스트가 핵심입니다. 신규 도구 등록·삭제·권한 변경 각각에서 감사 이벤트가 실제로 기록되는지 확인하고, 로그 필드는 actor·tool name·method 헤더·타임스탬프·처리 결과를 표준으로 고정합니다. 사용자 식별자는 해시 처리해 PII 노출을 막고, 환경 간 설정 차이를 자동으로 비교하는 config lint를 배포 파이프라인에 넣습니다.
개선 루프는 감사 이벤트 누락 상위 유형을 정기적으로 추려 확장 설계에 반영하는 방식으로 굴립니다. 설정 드리프트 변경 이력은 일반 기능 변경 로그와 분리해 남겨야, 사고 시 원인이 확장 버전인지 애플리케이션 코드인지 빠르게 구분됩니다.
바로 쓰는 체크리스트
감사·SSO·게이트웨이·설정 이식성이 코어 스펙 대신 확장으로 남는다는 로드맵 신호는, 표준 스키마를 기다리지 말고 팀이 먼저 목표 지표와 버전 고정 규칙을 세우라는 요구입니다. 감사 이벤트 커버리지 100%와 설정 드리프트 탐지율 100%를 기준선으로 잡고, 확장 버전 단위 롤백 경로를 배포 전에 확보해 두는 조직만 다음 릴리스에서도 같은 체크리스트를 그대로 재사용할 수 있습니다.