전 세계의 모든 MCP 호환 에이전트(agent)는 검색 백엔드로부터 동일한 세 가지를 필요로 합니다: 사용 가능한 데이터를 발견하고, 이를 대상으로 쿼리(query)를 실행하며, 구조화된 결과(structured results)를 돌려받는 것입니다. Claude, Amazon Q, Cursor, Kiro, Strands Agents, 그리고 점점 늘어나는 오픈 소스 프레임워크 목록이 이제 모두 네이티브하게 MCP를 지원합니다. 프로토콜 측면은 해결되었습니다. 이제 당신의 검색 인프라가 이에 응답할 수 있습니다.

Amazon OpenSearch Service가 이제 이를 지원합니다. 당신의 도메인이 네이티브 MCP 엔드포인트(endpoint)를 노출하면, 에이전트가 직접 연결됩니다. 커스텀 커넥터(custom connectors), 미들웨어(middleware), 에이전트별 통합 코드(per-agent integration code)가 필요 없습니다. 이 포스트에서는 이것이 실제 환경에서 어떻게 작동하는지 살펴봅니다: 엔드포인트가 무엇을 노출하는지, 어떻게 보안을 유지하는지, 그리고 데이터 소스가 에이전트가 이미 이해하고 있는 동일한 프로토콜을 사용할 때 왜 M×N 통합 문제(M×N integration problem)가 사라지는지에 대해 다룹니다.

60초 만에 이해하는 MCP

모델 컨텍스트 프로토콜 (Model Context Protocol, MCP)은 AI 에이전트가 외부 시스템의 도구(tools)를 발견하고 호출할 수 있게 해주는 표준 JSON-RPC 인터페이스입니다. MCP 서버는 자신이 무엇을 할 수 있는지(인덱스 검색, 클러스터 상태 확인, 집계 실행 등)를 광고하며, 모든 MCP 호환 에이전트는 커스텀 통합 코드 없이도 해당 도구들을 호출할 수 있습니다. 하나의 프로토콜이 모든 맞춤형 커넥터(bespoke connectors)를 대체합니다.

MCP가 해결하는 문제는 조합론적(combinatorial)입니다. 만약 M개의 에이전트가 N개의 데이터 소스에 연결된다면, 커스텀 통합 방식은 구축하고 유지 관리해야 할 커넥터가 M×N개가 된다는 것을 의미합니다. 3개의 에이전트가 5개의 OpenSearch Service 도메인과 통신한다면 15개의 커넥터가 필요합니다. 각 커넥터는 인증(authentication), 쿼리 포맷팅(query formatting), 응답 파싱(response parsing)을 각자의 방식대로 처리합니다. 여기에 6번째 도메인이나 4번째 에이전트를 추가하면 이 과정은 다시 반복됩니다. MCP는 이를 M+N으로 축소합니다. 각 에이전트는 하나의 프로토콜을 사용하고, 각 데이터 소스는 하나의 서버를 노출하며, 어떤 에이전트든 추가 코드 없이 어떤 서버와도 통신할 수 있습니다.

USB를 생각해보세요. USB 이전에는 모든 주변 기기(peripheral)마다 고유한 케이블과 드라이버가 필요했습니다. USB 이후에는 꽂기만 하면 작동합니다. MCP는 AI 통합 계층(AI integration layer)에 적용된 표준화입니다. 당신의 에이전트는 주변 기기이고, 당신의 데이터 소스는 컴퓨터이며, MCP는 포트(port)입니다.

MCP 서버가 노출하는 것

OpenSearch Service 도메인은 ML Commons 플러그인의 일부로 /_plugins/_ml/mcp 경로에서 MCP 엔드포인트(endpoint)를 노출합니다. 에이전트(Agents)는 여기에 직접 연결됩니다. 이 엔드포인트는 세 가지 유형의 구성 요소를 광고합니다. 리소스(Resources)는 인덱스(indexes)로부터 데이터 컨텍스트(data context)를 제공합니다. 프롬프트(Prompts)는 반복적인 분석을 위한 재사용 가능한 지침 템플릿(instruction templates)입니다. 도구(Tools)는 실행 가능한 함수로, 인덱스 검색, 클러스터 상태 확인, 성능 지표 분석, 집계(aggregations) 실행 등을 수행합니다.

도구 호출(tool call)은 다음과 같은 모습입니다. fastmcp를 사용하여 연결하는 Python 에이전트의 예시입니다:

from fastmcp import Client

async with Client("https://your-domain.us-east-1.es.amazonaws.com/_plugins/_ml/mcp") as client:
...

에이전트는 사용 가능한 도구를 발견하고, 이름으로 호출하며, 구조화된 결과(structured results)를 돌려받습니다. 커스텀 SDK나 REST 클라이언트 보일러플레이트(boilerplate)가 필요 없습니다. MCP 호환 에이전트(Amazon Q CLI, Claude, Cursor, Strands Agents)라면 모두 동일한 방식으로 연결할 수 있습니다.

설정 (본격적인 시작)

내장된 엔드포인트의 경우, 서버 측에서 설정할 것은 아무것도 없습니다. 도메인이 이미 MCP 엔드포인트를 노출하고 있기 때문입니다. 중요한 것은 인증(authentication)을 올바르게 설정하는 것입니다. IAM 역할(roles)과 백엔드 역할 매핑(backend role mapping)이 각 에이전트가 무엇을 볼 수 있는지 결정합니다. 이 설정이 완료되면, 새로운 에이전트를 연결하는 것은 단순한 구성 변경에 불과합니다. 저는 도메인을 구축하고, MCP를 활성화하고, 도구를 등록한 뒤, SearchIndexTool을 사용하여 OpenSearch Service의 데이터를 쿼리했습니다. 에이전트는 프로토콜의 기능 협상(capability negotiation)을 통해 사용 가능한 도구를 발견했으며, 별도의 커스텀 통합 코드 없이 쿼리를 실행했습니다.

접근을 위해서는 두 가지 계층이 필요합니다. 첫째, 에이전트 역할이 도메인에 도달할 수 있도록 허용하는 IAM 리소스 기반 정책(resource-based policy)입니다:

{
  "Version": "2012-10-17",
  "Statement": [{
...

둘째, 세분화된 액세스 제어 (fine-grained access control)가 활성화되면, IAM 역할 (IAM role)을 ML Commons API 및 에이전트가 검색해야 하는 인덱스 (indexes)에 대한 권한을 가진 OpenSearch 백엔드 역할 (backend role)에 매핑하세요. OpenSearch Dashboards에서 Security > Roles로 이동하여, ml_full_access에 대한 클러스터 권한(또는 더 좁은 범위의 사용자 정의 권한 세트)을 가진 역할을 생성하거나 선택하고, 대상 인덱스에 대한 인덱스 권한을 추가한 다음, Mapped users 항목에서 에이전트의 IAM 역할 ARN을 해당 백엔드 역할에 매핑합니다. 동일한 IAM 역할을 맡는 모든 에이전트는 동일한 액세스 권한을 상속받습니다. 커넥터마다 개별적으로 설정하는 대신 하나의 보안 경계 (security boundary)만 있으면 됩니다.

재구축 없는 확장 (Scaling Without Rebuilding)

내장된 MCP 엔드포인트 (endpoint)는 OpenSearch Service 도메인과 함께 확장됩니다. 도메인이 쿼리 부하를 처리할 수 있다면, MCP 엔드포인트도 이를 처리할 수 있습니다. 별도의 확장 레이어를 걱정할 필요가 없습니다. AgentCore 호스팅 경로를 사용하는 팀의 경우, AgentCore가 독립적으로 자동 확장 (auto-scaling)을 처리합니다.

새로운 AI 에이전트를 추가하는 데 서버 측 작업은 전혀 필요하지 않습니다. 에이전트는 도메인의 MCP 엔드포인트에 연결하고, 프로토콜의 내장된 기능 협상 (capability negotiation)을 통해 사용 가능한 도구 (tools)를 자동으로 발견합니다. 이것이 실제 적용된 M+N 속성입니다. 각 새로운 에이전트는 O(N)이 아닌 O(1)의 작업량만 요구합니다.

M+N의 이점 (The M+N Payoff)

3개의 OpenSearch Service 도메인에 연결된 4개의 AI 에이전트를 가진 팀을 가정해 보겠습니다. 기존 모델에서는 12개의 커스텀 통합 (custom integrations)이 필요했습니다. MCP를 사용하면 각 에이전트가 도메인의 엔드포인트를 가리키기만 하면 도구를 자동으로 발견합니다. 다섯 번째 에이전트를 추가하는 것은 개발 스프린트가 아니라 설정 항목 하나를 추가하는 작업입니다. 네 번째 도메인을 추가하면 기존 에이전트들이 즉시 해당 도메인에 접근할 수 있습니다. 복잡성은 선형적으로 유지됩니다.

오픈 소스인 OpenSearch MCP 서버는 OpenSearch 프로젝트의 일부입니다. 커뮤니티 주도의 개선과 보안 업데이트 덕분에 독점적인 통합 코드를 직접 유지 관리할 필요가 없습니다. 또한 OpenSearch Service 도메인의 내장 MCP 엔드포인트는 동일한 프로토콜을 사용하므로, 한 경로에서 작동하는 에이전트는 다른 경로에서도 코드 변경 없이 그대로 작동합니다.

만약 당신의 에이전트가 이미 MCP를 지원한다면, 당신의 OpenSearch Service 도메인은 응답할 준비가 되어 있습니다. ML Commons 플러그인을 활성화하고 (plugins.ml_commons.mcp_server_enabled를 true로 설정), 에이전트가 액세스하기를 원하는 도구들을 등록하며, IAM 및 백엔드 역할 매핑 (backend role mapping)을 구성한 뒤, 에이전트가 /_plugins/_ml/mcp 엔드포인트를 가리키도록 설정하십시오. 두 번째 에이전트를 추가하는 데는 비용이 들지 않습니다. 열 번째 에이전트를 추가하는 데도 비용이 들지 않습니다. 프로토콜은 프로토콜이 마땅히 해야 할 일을 수행합니다. 즉, 다음 연결을 무료로 만드는 것입니다.