MCP란 무엇인가? AI 에이전트가 데이터에 연결하는 방법 (2026 스펙 업데이트)

Model Context Protocol의 약자인 MCP는 AI 에이전트가 하나의 공통 인터페이스를 통해 도구와 데이터 소스에 접근할 수 있도록 지원하는 개방형 표준입니다. 앱마다 맞춤형 연동을 개발하는 대신, 클라이언트가 하나의 프로토콜을 사용하면 이를 준수하는 모든 서버가 응답할 수 있습니다. 이 사양은 2026년 7월 28일에 대대적으로 개정되었으며, 그 변화는 매우 중요합니다.

이 가이드에서는 프로토콜의 역할과 2026-07-28 릴리스에서 변경된 사항을 다룹니다. 또한 현재 지원 중단(deprecated)된 기능, 일반 API 연동과의 차이점, 그리고 이 프로토콜이 필요하지 않은 경우에 대해서도 설명합니다. 여기에 기재된 사실은 2026년 8월 5일 기준입니다.

MCP란 무엇인가요?

규격이 같은 플러그라고 생각하시면 됩니다. 표준이 존재하기 전에는 어시스턴트를 데이터베이스, 티켓 시스템, 파일에 연결하려면 세 가지 맞춤형 연동이 필요했습니다. 각각 고유한 인증, 에러 처리, 유지 관리 부담이 따랐습니다.

MCP는 이러한 연결을 한 번만 정의합니다. 클라이언트는 에이전트 측입니다. 서버는 데이터 소스나 도구를 감싸서 수행할 수 있는 작업을 노출합니다. 클라이언트는 서버에 사용 가능한 작업이 무엇인지 묻고 이를 호출합니다.

서버는 일반적으로 세 가지 요소를 노출합니다. 도구(Tools)는 에이전트가 호출할 수 있는 작업입니다. 리소스(Resources)는 읽기 가능한 콘텐츠입니다. 프롬프트(Prompts)는 재사용 가능한 템플릿입니다. 클라이언트는 이 세 가지를 하드코딩하는 대신 런타임에 검색하여 찾아냅니다.

이 이름은 다소 느슨하게 사용되므로 한 가지 명확히 짚고 넘어갈 필요가 있습니다. 이 프로토콜은 모델도, 에이전트도, 제품도 아닙니다. 이들 사이의 와이어 포맷(wire format)일 뿐입니다.

두 단어로 이 프로토콜을 둘러싼 대부분의 혼란을 설명할 수 있습니다. 검색(Discovery)은 클라이언트가 런타임에 서버가 제공하는 기능을 파악하는 것을 의미합니다. 재사용(Reuse)은 동일한 서버가 프로토콜을 준수하는 모든 클라이언트에 응답할 수 있음을 의미합니다.

도입은 더 이상 이론에 그치지 않습니다. 프로토콜 유지 관리자들의 보고에 따르면, Tier 1 SDK 전체에서 월간 다운로드 수가 5억 건에 육박하고 있습니다. TypeScript 및 Python SDK는 각각 누적 다운로드 수 10억 건을 넘어섰습니다.

2026-07-28 사양에서 변경된 사항

이번 릴리스는 프로토콜 역사상 가장 큰 규모의 개정입니다. 핵심은 이제 코어가 상태 비저장(stateless) 방식으로 작동한다는 점입니다.

변경 사항	의미
상태 비저장(Stateless) 코어	세션과 핸드셰이크가 사라졌습니다. 각 요청은 자체 프로토콜 버전과 클라이언트 식별 정보를 전달합니다.
다중 왕복 요청(Multi Round-Trip Requests)	스트림을 열어두어야 했던 서버 시작 요청을 대체합니다. 도구는 호출 중간에 사용자에게 입력을 요청할 수 있습니다.
헤더 기반 라우팅	메서드 및 도구 이름이 Mcp-Method 및 Mcp-Name 헤더로 전달되므로, 게이트웨이가 헤더를 기반으로 라우팅 및 권한 부여를 수행합니다.
캐시 가능한 목록 결과	도구, 프롬프트, 리소스 목록에 이제 ttlMs 및 cacheScope가 포함됩니다.
권한 부여 강화	RFC 9207 발급자 검증, Dynamic Client Registration에서 Client ID Metadata Documents로의 전환, 그리고 발급자 바인딩 자격 증명이 도입되었습니다.
확장 프레임워크	태스크(Tasks)가 실험적 코어에서 벗어나 Apps 및 Enterprise Managed Authorization과 함께 정식 확장 기능으로 이동합니다.

이 목록은 하나의 결정이 여섯 번 반복된 것으로 이해할 수 있습니다. 각 변경 사항은 원격 서버 운영을 까다롭게 만들었던 전제 조건들을 제거합니다. 도구가 수행할 수 있는 작업 자체는 변하지 않습니다.

공식 2026-07-28 사양 게시글에서 전체 변경 목록을 확인하실 수 있습니다. TypeScript, Python, Go, C# SDK는 이미 이를 지원하고 있으며, Rust는 베타 버전입니다.

서버를 운영할 때 상태 비저장(stateless) 방식이 중요한 이유

기존 설계는 지속적이고 양방향인 연결을 전제로 했습니다. 이 단 하나의 전제가 운영상의 고통 대부분을 유발했습니다.

이전에는 원격 서버가 클라이언트를 동일한 인스턴스로 계속 연결하기 위해 스티키 세션(sticky sessions)이 필요했습니다. 재시작 후에도 상태를 유지하기 위해 공유 세션 스토리지가 필요했습니다. 게이트웨이는 요청이 무엇을 하려는지 파악하기 위해 페이로드를 검사해야 하는 경우가 많았습니다.

이제는 이 중 어느 것도 필요하지 않습니다. 서버는 일반적인 라운드 로빈 로드 밸런서 뒤에 위치할 수 있습니다. 라우팅은 헤더를 기반으로 이루어집니다. 클라이언트는 서버가 지정한 유효 기간 동안 도구 목록을 캐시합니다. 이 프로토콜은 조심스럽게 배포해야 했던 것에서 평범하게 배포할 수 있는 것으로 바뀌었습니다.

물론 마이그레이션 비용이 수반됩니다. 기존 코어를 기반으로 구축된 서버는 수정 작업이 필요하며, 클라이언트 라이브러리도 함께 마이그레이션해야 합니다.

또한 이번 변경으로 서버를 시도해 보는 비용이 낮아졌습니다. 예전에는 서버를 구축하는 것이 인프라적인 결정이었지만, 이제는 소규모 웹 서비스를 배포하는 것에 가까워졌습니다.

벤더의 MCP 서버 도입을 검토 중인 분들이라면 다음과 같은 실질적인 질문을 던져야 합니다. "어떤 사양 버전을 타겟으로 하고 있으며, 언제 전환할 예정인가요?"

지원 중단(deprecated)되는 기능과 남은 시간

세 가지 기능이 사라질 예정입니다. 바로 Roots, Sampling, Logging입니다. 기존의 HTTP+SSE 전송 방식도 지원 중단됩니다.

유지 관리자들은 실제 제거 전까지 최소 12개월의 유예 기간을 약속했습니다. 이는 넉넉한 기간이지만 엄연한 마감 기한이기도 합니다. 이 네 가지 기능 중 하나라도 기반으로 구축했다면, 마이그레이션을 백로그에 방치하지 말고 로드맵에 반영하십시오.

서버뿐만 아니라 클라이언트도 확인해야 합니다. 기존 전송 방식에 고정된 클라이언트는 유예 기간 동안에는 계속 작동하겠지만, 그 이후에는 작동을 멈출 것입니다.

Dynamic Client Registration은 공식적으로 지원 중단되며 Client ID Metadata Documents로 대체됩니다. 이제 발급자 바인딩 자격 증명을 통해 한 서버에 발급된 토큰이 다른 서버에서 재사용(replay)되는 것을 방지합니다.

MCP와 일반 API 연동 비교

	맞춤형 API 연동	MCP 서버
소스별 작업	매번 새로운 인증, 스키마, 에러 처리 필요	하나의 프로토콜 재사용
검색(Discovery)	존재하는 요소를 하드코딩함	클라이언트가 런타임에 요청함
사용 가능 대상	연동을 직접 구현한 앱	프로토콜을 준수하는 모든 클라이언트
유지 관리	벤더의 API가 변경되면 작동이 중단됨	서버가 변경 사항을 흡수함
가장 적합한 경우	단일 경로의 심층적이고 대용량인 처리	에이전트가 접근해야 하는 다수의 소스

고려해야 할 또 다른 사항은 커넥터를 누가 유지 관리하느냐입니다. 벤더가 배포한 서버는 벤더의 제품과 함께 업데이트되므로, 여러분이 직접 관리할 필요가 없습니다.

솔직히 말씀드리면, 단 하나의 연동만 필요한 경우에는 MCP가 더 빠르거나 저렴하지 않습니다. MCP는 소스의 수가 늘어나거나, 재구축 없이 여러 에이전트가 동일한 소스에 접근하도록 하려는 경우에 진가를 발휘합니다.

데이터 소스가 연결된 후 제작할 수 있는 결과물

연결은 배관 작업에 불과합니다. 굳이 번거로움을 감수하는 이유는 결국 최종 결과물 때문입니다.

데이터 소스가 연결되면 에이전트는 현재 수치를 가져와 분석을 실행할 수 있습니다. 그 결과 차트, 서면 요약본, 슬라이드 세트 등 완성된 결과물이 반환됩니다. 가치는 프로토콜 자체에서 나오는 것이 아니라 내보내기(export) 단계를 생략하는 데서 옵니다. 또한 이러한 결과물은 내부적으로 이 설정을 유지해야 하는 명분이 됩니다. 아무도 보고서로 만들지 않는 연결은 조용히 차단되기 마련입니다.

Powerdrill Bloom은 이 패턴을 따르는 서버를 제공합니다. 자체 문서에 따르면, 사용자의 User ID 및 Project API Key로 인증을 수행합니다. 그런 다음 클라이언트는 계정 내의 데이터 세트를 탐색하고, 특정 데이터 세트의 세부 정보를 가져오며, 자연어로 질문하여 작업을 실행할 수 있습니다. 이는 Claude Desktop 및 기타 호환 클라이언트와 연동됩니다. MCP 서버 발표 내용에서 설정 방법을 다루고 있으며, 데이터 커넥터 페이지에서 다른 소스 유형 목록을 확인할 수 있습니다.

MCP가 전혀 필요하지 않은 경우

대부분의 설명서에서 이 부분을 생략하므로, 명확하게 짚고 넘어갈 가치가 있습니다.

데이터가 파일 형태로 제공된다면 프로토콜은 필요하지 않습니다. 업로드만 하면 됩니다. 분기별 내보내기 파일, 누군가 이메일로 보낸 CSV, PDF 명세서 등은 서버를 구축할 이유가 되지 않습니다. 파일을 끌어다 놓고 질문을 던지면 됩니다.

구축하기 전에 한 가지 질문을 던져보세요. "내가 아닌 다른 사람이 다음 달에 이 동일한 내보내기 파일을 다시 필요로 할 것인가?"

MCP는 소스가 실시간으로 업데이트되고 반복적일 때 제값을 합니다. 매시간 변경되는 데이터베이스, 티켓 대기열, 주간 보고서의 기반이 되는 웨어하우스 테이블 등이 이에 해당합니다. 핵심 기준은 '그렇지 않았다면 다음 주에 동일한 데이터를 다시 내보내야 하는가'입니다.

보안 측면도 존재합니다. 연결된 소스는 일회성 공유가 아니라 상시 권한 부여를 의미합니다. 2026-07-28 권한 부여 변경 사항이 존재하는 이유도 바로 이 차이가 중요하기 때문입니다.

요약

MCP는 에이전트와 데이터 소스 사이의 표준 플러그입니다. 2026-07-28 릴리스에서는 코어를 상태 비저장 방식으로 변경하고, 라우팅을 헤더로 이동했으며, 목록 결과를 캐시할 수 있도록 하고, 권한 부여를 강화했습니다. Roots, Sampling, Logging 및 기존 HTTP+SSE 전송 방식은 12개월의 유예 기간을 두고 지원 중단됩니다.

일회성 파일의 경우 이 모든 과정을 건너뛰십시오. Powerdrill Bloom을 무료로 체험해 보세요. 파일을 업로드하고 자연어로 질문한 뒤 차트나 슬라이드 덱을 내보내기만 하면 됩니다. 서버 옵션을 비교하고 싶다면 최고의 MCP 플랫폼을 확인해 보세요.

자주 묻는 질문

MCP는 무엇의 약자인가요?

Model Context Protocol의 약자입니다. AI 클라이언트를 하나의 인터페이스를 통해 도구 및 데이터 소스에 연결하는 개방형 표준입니다. 이를 통해 새로운 소스가 추가될 때마다 맞춤형 연동을 개발해야 하는 번거로움을 피할 수 있습니다.

MCP 2026-07-28 사양에서 무엇이 변경되었나요?

코어가 상태 비저장(stateless) 방식으로 변경되어 세션과 핸드셰이크가 제거되었습니다. 열린 스트림을 통한 서버 시작 요청이 다중 왕복 요청(Multi Round-Trip Requests)으로 대체되었으며, 라우팅이 Mcp-Method 및 Mcp-Name 헤더로 이동했습니다. 목록 결과를 캐시할 수 있게 되었고, 발급자 검증 및 발급자 바인딩 자격 증명을 통해 권한 부여가 강화되었습니다.

MCP는 API와 같나요?

아닙니다. API는 특정 벤더가 단일 시스템을 위해 제공하는 인터페이스입니다. 반면 이 프로토콜은 여러 시스템이 구현할 수 있는 공통 래퍼(wrapper)이므로, 프로토콜을 준수하는 모든 클라이언트가 소스별 맞춤형 코드 없이도 이를 검색하고 호출할 수 있습니다.

새로운 MCP 사양에서 지원 중단(deprecated)되는 것은 무엇인가요?

Roots, Sampling, Logging 및 기존 HTTP+SSE 전송 방식이 지원 중단됩니다. Dynamic Client Registration은 Client ID Metadata Documents로 대체됩니다. 유지 관리자들은 실제 제거 전까지 최소 12개월의 유예 기간을 두겠다고 밝혔습니다.

AI로 스프레드시트를 분석하려면 MCP가 필요한가요?

아닙니다. 이미 가지고 있는 파일의 경우 업로드하는 것이 더 간단하고 빠릅니다. 이 프로토콜은 소스가 실시간으로 업데이트되고 주기적으로 동일한 데이터를 다시 내보내야 하는 상황일 때 구축할 가치가 있습니다.