MCP 도입으로 무엇이 표준화됐나…사내 데이터·도구 연결 공통 규격과 남은 접근통제 과제
AI 에이전트가 사내 문서와 데이터베이스를 읽고 외부 프로그램을 호출하는 흐름에서 MCP는 개별 서비스마다 제각각 만들던 연결 방식을 공통 규격으로 묶는 쪽으로 발전하고 있다. 다만 이것이 곧바로 보안까지 자동으로 표준화했다는 뜻은 아니다. 2025년 12월 9일 앤스로픽은 MCP를 리눅스재단 산하 에이전틱 AI 재단에 기증한다고 발표했고, 이후 2026년 7월 규격 개정에서는 HTTP 기반 전송과 인증 절차가 한층 명시적으로 정리됐다. 기업 IT 책임자 입장에서 핵심은 “연결 형식이 표준화된 범위”와 “권한 위임·감사 책임이 여전히 각 조직과 서버 구현에 남는 범위”를 구분해 보는 일이다.
MCP가 실제로 표준화한 것은 도구 호출의 공통 인터페이스
MCP는 원래 앤스로픽이 2024년 11월 공개한 규격으로, AI 보조도구를 데이터 저장소·업무도구·개발환경 같은 외부 시스템과 연결하는 표준을 목표로 했다. 현재 공식 문서상 MCP 서버는 크게 프롬프트, 리소스, 도구를 노출할 수 있다. 프롬프트는 사용자가 고르는 템플릿, 리소스는 애플리케이션이 붙이는 문맥 데이터, 도구는 모델이 호출하는 실행 기능으로 구분된다. 다시 말해 MCP가 표준화한 첫 번째 대상은 모델이 외부 기능을 어떻게 발견하고, 어떤 이름의 도구를 어떤 인자 구조로 호출하며, 어떤 형태의 결과를 돌려받는지에 관한 인터페이스다.
이 점은 기존의 개별 API 연동과 다르다. 종전에는 AI 애플리케이션이 구글드라이브, 깃허브, 사내 검색, 티켓 시스템마다 서로 다른 API 문서와 인증 흐름을 별도로 붙여야 했다. MCP는 이런 연결을 서버 하나가 공통 형식으로 감싸고, 클라이언트는 같은 규칙으로 도구 목록을 읽고 호출할 수 있게 만든다. 표준화의 초점이 개별 업무 API 자체를 통일하는 데 있는 것이 아니라, AI 클라이언트와 외부 시스템 사이의 중간 계층을 공통화하는 데 있다는 뜻이다.
2026년 개정에서 바뀐 것은 ‘세션형 연결’보다 ‘HTTP 작업’에 가까운 구조
2026년 7월 확정된 MCP 규격은 이 공통 인터페이스를 더 운영 친화적인 형태로 다듬었다. 공식 블로그와 SDK 문서에 따르면 새 규격은 프로토콜 계층을 무상태로 바꾸고, 요청마다 프로토콜 버전과 호출 메서드 정보를 헤더에 싣는 방식을 채택했다. 이전처럼 세션을 먼저 맺고 그 세션에 계속 붙는 구조보다, 일반 HTTP 서비스처럼 로드밸런서와 게이트웨이 뒤에서 분산 처리하기 쉬운 형태에 가깝다.
이 변화는 기업 운영 측면에서 의미가 있다. 요청마다 어떤 메서드가 호출됐는지 헤더에서 드러나면 게이트웨이, 속도 제한 장치, 웹방화벽 같은 기존 인프라가 JSON 본문 전체를 해석하지 않고도 라우팅과 일부 정책 집행을 하기 쉬워진다. 공식 문서가 “traceable”과 헤더 기반 라우팅을 강조하는 이유도 여기에 있다. 다만 이것은 운영·관측 편의성이 높아졌다는 뜻이지, 감사 체계가 MCP만으로 완결됐다는 뜻은 아니다.
인증도 일부 표준화됐지만, 권한 범위 설계는 서버와 조직의 몫
MCP의 최신 문서는 인증·인가 흐름도 일정 부분 공통화했다. 공식 인증 문서에 따르면 보호된 MCP 서버는 OAuth 기반 절차를 사용하고, 인증이 필요한 경우 HTTP 401 응답과 보호 자원 메타데이터를 통해 클라이언트가 어느 인증 서버로 가야 하는지 찾도록 설계된다. 2026년 개정은 발급자 확인, 자격증명 격리, 점진적 권한 상향 같은 보안 강화를 명시했다.
하지만 여기서 표준화된 것은 어디까지나 인증 절차의 골격이다. 어떤 도구를 민감한 도구로 볼지, 어떤 사용자나 에이전트에 어떤 범위의 토큰을 줄지, 도구 실행 결과를 어느 조직 단위까지 보여줄지는 각 MCP 서버 구현과 기업의 IAM 설계가 결정한다. 공식 앱 문서도 전면 인증 방식과 도구별 인증 방식을 구분한다. 모든 요청에 토큰을 강제할 수도 있고, 특정 도구 호출에만 토큰을 요구할 수도 있다. 같은 MCP를 쓴다고 해도 접근통제 수준이 같아지는 것은 아니다.
이 대목에서 개별 API 직접 연결과 MCP 서버 방식의 차이가 드러난다. 직접 연결에서는 각 SaaS API가 자체 인증과 감사 로그를 따로 가진다. 반면 MCP 서버를 두면 여러 내부·외부 시스템 호출이 MCP라는 공통 진입점으로 모일 수 있다. 이 경우 장점은 정책과 식별을 한곳에서 정리하기 쉬워진다는 점이지만, 반대로 MCP 서버가 과도한 권한을 위임받으면 여러 시스템에 대한 접근이 하나의 중개 계층으로 집중될 수 있다. 표준화가 곧 위험 감소를 뜻하지 않는 이유다.
감사 범위는 ‘프로토콜 로그’보다 ‘조직의 관측 설계’가 더 중요해졌다
감사 측면에서도 비슷한 구분이 필요하다. 최신 MCP 문서에서는 과거 프로토콜 차원의 로깅 기능을 더 이상 새 구현의 중심으로 두지 않고, 표준 오류 출력이나 오픈텔레메트리 같은 일반적인 관측 도구로 이동하라고 안내한다. 이는 감사가 MCP 내부 기능 하나로 해결되기보다, 기존 운영 도구와 결합한 서버 측 관측 체계로 넘어가고 있음을 뜻한다.
기업 입장에서는 그래서 두 층의 로그를 따로 설계해야 한다. 첫째는 MCP 진입점에서 누가 어떤 도구를 어떤 헤더와 토큰 맥락으로 호출했는지 남기는 접근 로그다. 둘째는 MCP 서버 뒤편의 실제 데이터베이스, 파일 저장소, 업무 시스템에서 어떤 읽기·쓰기·삭제가 일어났는지 남기는 실행 로그다. MCP가 앞단의 호출 형식을 통일해도, 실제 업무 영향은 뒤쪽 시스템에서 발생한다. 감사 범위를 MCP 호출 기록까지만 두면 “무슨 도구를 눌렀는지”는 보여도 “어떤 레코드가 바뀌었는지”는 놓칠 수 있다.
A2A와 비교하면 MCP는 ‘도구 연결’, A2A는 ‘에이전트 간 협업’에 가깝다
비슷한 시기 주목받는 A2A와의 구분도 필요하다. A2A 공식 문서는 A2A를 에이전트 사이의 통신 프로토콜로 설명하고, MCP는 한 에이전트가 API와 엔터프라이즈 애플리케이션에 접근하는 내부 연결층으로 설명한다. 실제 A2A 문서에도 “A2A는 에이전트 사이의 경계를 넘고, MCP는 한 에이전트 안에서 API와 애플리케이션을 연결한다”는 구분이 나온다.
보안 구조도 다르다. A2A는 에이전트 카드에 적힌 보안 요구사항을 보고 클라이언트가 자격증명을 준비한 뒤, 각 요청마다 이를 헤더나 메타데이터에 싣는 방식을 기본으로 한다. 또 작업 도중 추가 승인이 필요하면 TASK_STATE_AUTH_REQUIRED 상태로 클라이언트에 권한 해결을 다시 요청할 수 있다. 반면 MCP는 도구 호출 앞단의 보호 자원과 권한 상승 절차를 더 세밀하게 다루는 쪽에 가깝다. 둘은 경쟁 규격이라기보다 서로 다른 층을 맡는 경우가 많다.
기업이 확인할 질문은 ‘MCP를 쓰느냐’보다 ‘어디까지 위임하느냐’
따라서 “MCP 도입으로 무엇이 표준화됐는가”라는 질문에 대한 답은 비교적 분명하다. 도구·리소스·프롬프트를 노출하는 방식, 도구 발견과 호출 형식, 원격 서버 운영을 위한 HTTP 전송 구조, OAuth 기반 인증 절차의 기본 골격이 공통 규격으로 정리됐다. 앤스로픽의 재단 기증 발표와 2026년 규격 개정은 이 프로토콜이 특정 벤더 기능이 아니라 공개 거버넌스 아래의 기반 규격으로 이동하고 있음을 보여준다.
반면 아직 표준화되지 않았거나 조직별 선택에 남는 영역도 크다. 사용자 승인 정책, 세분화된 권한 범위, 하위 시스템별 감사 보존 기간, 고위험 도구의 이중 승인, MCP 서버에 부여할 대리 권한의 크기 같은 문제다. 결국 기업 보안팀과 IT 운영팀이 따져야 할 것은 MCP 채택 여부 자체보다, 그 공통 연결층에 어떤 신뢰와 권한을 실어 보낼지다. AI 에이전트가 사내 데이터를 읽고 프로그램을 조작하는 시대에는 연결의 표준화가 곧 통제의 표준화를 보장하지 않는다.
자료: Anthropic, Donating the Model Context Protocol and establishing the Agentic AI Foundation(2025-12-09); Anthropic, Introducing the Model Context Protocol(2024-11-25); Model Context Protocol, The 2026-07-28 Specification 및 The 2026-07-28 MCP Specification Release Candidate(2026-07-28); Model Context Protocol, Authorization 문서(2026); A2A Protocol, What is A2A? 및 Agent2Agent Protocol Specification v1.0.1(2026)