MCP 표준화와 AI 에이전트 도구 통합 아키텍처

2024년 11월 Anthropic이 공개한 MCP(Model Context Protocol)는 에이전트와 외부 도구 사이의 연결 방식을 하나의 프로토콜로 묶는다. 도구마다 별도 연동 코드를 작성하는 대신, 서버가 기능과 스키마를 공개하고 에이전트가 이를 런타임에 탐색해 호출하는 구조다.

공개 후 14개월 만에 MCP는 Linux Foundation 산하 Agentic AI Foundation(AAIF)으로 이관됐다. 2026년 3월 기준 공개 서버는 1만 개를 넘어섰고 월간 SDK 다운로드는 9,700만 건에 달했다. Anthropic·OpenAI·Google·Microsoft·AWS를 비롯한 주요 AI 벤더도 지원을 선언했다.

벤더 프로젝트에서 공통 프로토콜로

Anthropic은 2024년 11월 JSON-RPC 2.0 기반의 MCP 사양과 SDK를 오픈소스로 공개했다. 이어 2025년 12월 MCP를 Linux Foundation 산하 AAIF에 기증했다. AAIF는 Anthropic, Block(구 Square), OpenAI가 공동 창립했으며, Linux Foundation은 CNCF와 OpenSSF에서 활용한 거버넌스 모델을 적용한다.

생태계의 외형도 빠르게 커졌다. 2024년 11월 월간 SDK 다운로드는 약 200만 건이었고, 2026년 3월에는 9,700만 건에 이르렀다. 16개월 만에 약 4,750% 성장한 셈이다. 2026년 3월 기준 공개 MCP 서버는 데이터베이스, API, 파일시스템, 클라우드, 개발 도구 전반에 걸쳐 1만 개 이상 존재한다. GitHub 스타는 81,000+이며 월간 SDK 다운로드는 9,700만 건이다. Claude, ChatGPT, Cursor, VS Code Copilot, Gemini, Microsoft Copilot, AWS Bedrock이 지원 플랫폼에 포함된다.

MCP를 “AI용 USB-C”라고 부르는 이유는 연결 비용의 변화에 있다. USB-C 이전에는 디바이스마다 별도 케이블이 필요했고, MCP 이전에는 AI 에이전트와 도구의 조합마다 커스텀 연동 코드를 만들어야 했다. 에이전트 M개와 도구 N개를 직접 연결하면 N×M 통합 문제가 생기지만, 공통 인터페이스를 두면 N+M 문제로 단순화된다. 예를 들어 에이전트 10개와 도구 5개를 직접 연결하면 50개 연동을 관리해야 하지만, MCP에서는 15개 구현으로 줄일 수 있다. 한 번 구현한 MCP 서버를 호환 에이전트에서 다시 사용할 수 있다는 의미다.

메시지와 전송 계층이 나누는 책임

MCP는 JSON-RPC 2.0 위에서 동작한다. 동일 호스트의 로컬 서버에는 표준 입출력 스트림인 Stdio를 사용할 수 있고, 원격 연결에는 HTTP POST와 서버 측 이벤트를 결합한 Streamable HTTP를 쓴다. 2026년 07월 RC에는 세션 의존성을 제거하는 Stateless 프로토콜 레이어가 추가됐다.

지속 연결 세션을 유지하는 서버는 로드밸런서 뒤에서 수평 확장하기 어렵다. 세션 스티키니스가 필요해지고, 상태를 외부 세션 스토어에 맡기는 구성은 멀티클라우드와 하이브리드 배포의 운영 복잡도를 높인다. Stateless HTTP에서는 단일 HTTP 요청 안에 처리에 필요한 컨텍스트와 JWT를 포함한 인증 맥락을 담는다. Kubernetes HPA가 세션 스티키니스 없이 요청을 임의의 파드로 보낼 수 있어 트래픽 스파이크에 탄력적으로 대응할 수 있고, 세션 탈취의 공격면도 줄일 수 있다.

클라이언트와 서버는 몇 가지 핵심 메시지로 상호작용한다. initialize는 프로토콜 버전과 기능을 교환하고, tools/list는 호출 가능한 도구와 스키마를 가져온다. 실제 실행은 tools/call이 담당한다. 데이터 소스는 resources/list와 resources/read로 조회하며, 재사용 가능한 프롬프트 템플릿은 prompts/list와 prompts/get으로 찾는다.

서버가 노출하는 대상은 다음과 같이 구분된다.

요소	설명	사용 예
Tools	에이전트가 호출하는 실행 가능한 함수	DB 쿼리, API 호출, 파일 작성
Resources	에이전트가 읽을 수 있는 데이터 소스	파일, URL, DB 레코드
Prompts	재사용 가능한 프롬프트 템플릿	특정 작업용 시스템 프롬프트

리소스는 외부 데이터를 식별하고 참조하는 경계를 만든다. 기본 구조는 다음과 같다.

{scheme}://{authority}/{path}?{query}#{fragment}

가변 리소스는 ETag 또는 last-modified 헤더를 이용한 조건부 패치로 반복 조회에 따른 컨텍스트 낭비를 줄일 수 있다. 프롬프트는 반복되는 지시 패턴을 서버에 등록해 에이전트 코드 변경 없이 갱신하고 버전 관리할 수 있게 한다.

{
  "name": "contract-review",
  "description": "계약서 법적 위험 분석 프롬프트",
  "arguments": [
    {
      "name": "contract_type",
      "description": "계약 유형 (NDA, SaaS, Employment)",
      "required": true
    },
    {
      "name": "jurisdiction",
      "description": "준거법 국가 코드 (KR, US, EU)",
      "required": true
    }
  ]
}

도구는 호출 횟수보다 업무의 경계가 중요하다. 단일 쿼리만 실행하는 도구로 과도하게 쪼개기보다 조회와 필요한 컨텍스트 보강을 함께 처리하는 작업 단위로 설계한다. 저수준 DB 오류 대신 에이전트가 처리할 수 있는 시맨틱 오류를 반환하고, 쓰기 도구에는 idempotency-key를 요구해 비멱등 작업을 통제한다. 장시간 실행되는 도구는 notifications/progress로 진행 상태와 중간 결과를 전달하며, 클라이언트 연결·도구 실행·개별 진행 알림의 타임아웃을 나눠 한 지점의 장애가 전체 호출로 퍼지는 범위를 줄인다.

async def execute_data_analysis(params: dict, context: MCPContext):
    job_id = await start_async_job(params["query"])

    # 진행 상황 스트리밍
    async for progress in watch_job_progress(job_id):
        await context.send_progress(
            progress_token=params["_progressToken"],
            progress=progress.pct,
            total=100,
            message=f"처리 중: {progress.stage}"
        )

    result = await get_job_result(job_id)
    return {"status": "complete", "rows": result.rows, "summary": result.summary}

⤢✕

등록된 도구가 실제 호출로 이어지는 과정

MCP 서버는 먼저 도구 이름과 설명, JSON Schema 파라미터를 담은 manifest를 작성한다. 클라이언트가 서버에 연결하면 tools/list를 통해 도구 카탈로그를 동적으로 받는다. LLM은 사용자 의도와 각 도구의 description을 대조해 사용할 도구를 고르고, tools/call에 필요한 파라미터를 전달한다. 파라미터는 JSON Schema에 따라 검증된다. 실행 결과는 content 배열로 돌아와 후속 추론을 위한 컨텍스트에 포함된다.

⤢✕

이 동적 탐색 구조에서는 백엔드 팀이 서버에 신규 도구를 등록하면 에이전트 배포를 바꾸지 않고도 카탈로그에 반영할 수 있다. 정책에 따라 테넌트별로 보이는 도구를 달리할 수도 있으며, 멀티에이전트 환경에서는 중앙 레지스트리를 통해 동일한 도구 정의를 관리할 수 있다.

컨텍스트 외부화와 RAG의 적용 범위

MCP 컨텍스트 외부화와 RAG 중 하나가 항상 우월한 것은 아니다. 데이터 갱신 주기와 규모, 구조화 여부, 에이전트가 수행할 작업을 기준으로 선택해야 한다.

운영 데이터가 실시간 또는 분 단위로 바뀌거나, 구조화된 API와 데이터베이스에서 정확한 레코드를 찾아야 한다면 MCP 컨텍스트 외부화가 맞는다. 데이터를 쓰거나 변경하는 에이전트 작업에도 적합하다. RAG는 읽기 전용 패러다임이기 때문이다. 컨텍스트 길이보다 도구 호출 지연을 허용할 수 있는지도 함께 봐야 한다.

수백만 건 이상의 비정형 문서에서 의미론적 유사도 검색이 필요하다면 RAG 쪽이 자연스럽다. 전체 문서를 MCP 리소스로 불러오기 어려울 만큼 컨텍스트 길이 제약이 엄격하거나, 조직이 이미 임베딩 인덱스 인프라를 운영하는 경우도 마찬가지다.

캐시는 어느 접근법을 쓰더라도 비용과 지연에 직접 영향을 준다. MCP 컨텍스트 외부화에서는 ETag 기반 리소스 캐싱, TTL 기반 도구 결과 캐싱, Anthropic prompt caching API를 이용한 LLM 프롬프트 캐싱을 독립된 계층으로 구성한다. MCP 리소스를 시스템 프롬프트 상단에 고정 배치하면 LLM 프롬프트 캐시 히트율이 최대 85%까지 올라 API 비용을 줄일 수 있다.

AAIF가 다루는 표준화 범위

AAIF의 Technical Steering Committee(TSC)는 사양 변경을 승인하고 프로젝트 수명주기를 관리한다. 프로젝트는 Growth, Impact, Emeritus의 3단계를 거친다. 보안, 엔터프라이즈, 수직 도메인처럼 특정 기술 영역은 Working Groups가 담당하며, 2026년부터는 외부 프로젝트가 AAIF에 편입되는 공식 경로도 개방됐다.

Lead Maintainer David Soria Parra가 발표한 2026 로드맵의 우선순위는 다음과 같다.

우선순위	내용	현황
(1) 엔터프라이즈 보안	SSO 연동 인증, 표준화된 감사 추적	OAuth 2.1 + PKCE 의무화
(2) 전송 계층 진화	Streamable HTTP 안정화, Stateless 지원	2026.07.28 RC 출시
(3) 에이전트 간 통신	A2A 프로토콜과의 통합 설계	Working Group 활성화
(4) 수직 도메인 프로파일	헬스케어(HIPAA), 금융(SOX) 규정 준수	EU AI Act 대응

표준화 논의는 MCP 자체에만 머물지 않는다. 통신 API 연합인 CAMARA는 MCP 기반 네트워크 인식 AI 애플리케이션을 위한 표준 경로를 발표했다. 2026년 8월 발효되는 EU AI Act의 고위험 AI 시스템 요구사항과 MCP 거버넌스 프로파일을 연결하는 작업도 진행되고 있다. ISO/IEC와의 공식 국제 표준화 트랙은 검토 중이다.

중앙 게이트웨이로 멀티벤더 연결을 통제한다

여러 에이전트와 MCP 서버를 직접 연결하면 인증, 라우팅, 감사 정책이 분산된다. 엔터프라이즈 아키텍처에서는 MCP Gateway를 중앙에 두고 토큰 검증과 스코프 기반 라우팅, 도구 등록, 감사 로그를 한곳에서 처리하는 패턴을 사용할 수 있다.

⤢✕

Pinterest가 2026년 4월 공개한 사례는 도메인별 MCP 서버, 중앙 레지스트리, Human-in-the-loop 승인을 결합했다. 월 66,000건의 호출과 844명의 활성 사용자를 처리했으며, 거버넌스·보안 검토와 게이트웨이 인프라를 함께 적용해 엔터프라이즈 규모를 검증했다.

내부 API부터 시작해 운영 통제로 확장한다

내부 도구를 MCP로 전환할 때는 단일 API에서 시작해 연결 대상과 통제 계층을 순차적으로 넓힐 수 있다.

단계	활동	기간
(1) 파일럿	단일 내부 API MCP 서버 구축, 개발팀 내 검증	1~2주
(2) 확장	DB·메시징·코드 저장소 MCP 서버 추가	1개월
(3) 거버넌스	MCP Gateway 도입, OAuth 2.1 인증, 감사 추적	2~3개월
(4) 표준화	멀티에이전트 통합, 중앙 레지스트리 구축	3~6개월

서버 하나에 여러 업무 영역을 섞기보다 DB, 파일, API처럼 도메인별 책임을 분리한다. 도구 파라미터는 JSON Schema를 먼저 정의해 타입 안정성을 확보하고, 프로토콜 오류와 실제 도구 실행 오류는 구별해야 한다. 스키마가 바뀔 때는 하위 호환성을 유지하고 브레이킹 체인지를 최소화한다.

Python SDK로 내부 데이터베이스 조회 도구를 노출하면 다음과 같은 형태가 된다.

from mcp.server import Server
from mcp.server.models import InitializationOptions
import mcp.types as types

app = Server("internal-db-server")

@app.list_tools()
async def handle_list_tools() -> list[types.Tool]:
    return [
        types.Tool(
            name="query_customer_db",
            description="고객 데이터베이스에서 레코드 조회",
            inputSchema={
                "type": "object",
                "properties": {
                    "customer_id": {"type": "string", "description": "고객 ID"},
                    "fields": {"type": "array", "items": {"type": "string"}}
                },
                "required": ["customer_id"]
            }
        )
    ]

@app.call_tool()
async def handle_call_tool(name: str, arguments: dict) -> list[types.TextContent]:
    if name == "query_customer_db":
        result = await db.query(arguments["customer_id"])
        return [types.TextContent(type="text", text=str(result))]

IDE 안에서 프로젝트 컨텍스트 연결하기

2026년 기준 VS Code는 GitHub Copilot MCP 통합과 .vscode/mcp.json 설정을 지원한다. Cursor는 네이티브 MCP 지원과 설정 UI를 제공하며, JetBrains는 IntelliJ, PyCharm, WebStorm에서 AI Assistant MCP 플러그인을 사용할 수 있다. Zed에도 MCP 서버 지원이 내장돼 있다.

VS Code 프로젝트에서 Stdio 서버와 원격 HTTP 서버를 함께 등록하는 예시는 다음과 같다.

{
  "servers": {
    "project-db": {
      "type": "stdio",
      "command": "python",
      "args": ["-m", "mcp_server_db"],
      "env": { "DB_URL": "${env:DATABASE_URL}" }
    },
    "github": {
      "type": "http",
      "url": "https://mcp.github.com",
      "headers": { "Authorization": "Bearer ${env:GITHUB_TOKEN}" }
    }
  }
}

이 연결을 통해 코드를 작성하는 동안 에이전트가 DB 스키마와 API 문서를 조회할 수 있다. PR 리뷰에서는 GitHub MCP로 변경 이력을 컨텍스트에 넣고, 로그 분석에서는 Grafana나 Datadog MCP를 통해 실시간 메트릭을 연동한다.

인증만 붙여서는 보안이 완성되지 않는다

2025년 11월 스펙 개정에서는 인터넷에 노출된 MCP 서버에 OAuth 2.1과 PKCE를 의무화했다. 이 구조에서 MCP 서버는 RFC 8707 Resource Indicators를 준수하는 OAuth Resource Server이며, 스코프를 사용해 도구 단위 최소 권한을 부여한다.

세션 스코프 인증은 토큰의 작업 범위를 특정 세션으로 제한하고, 세션 종료 시 토큰을 폐기한다. 에이전트가 Human gate 없이 토큰을 다시 발급받지 못하도록 막으며, 중앙 MCP Gateway가 토큰 검증과 감사 로그 기록을 담당한다.

인간 사용자 ID와 에이전트 ID는 분리하되 조직의 IAM 체계 안에서 함께 검증해야 한다. 에이전트 런타임은 조직의 IdP에서 클라이언트 크레덴셜 플로로 Access Token을 받고, 게이트웨이는 Bearer Token을 JWKS 엔드포인트로 검증한다. Token Claims에서 agent_id, user_context, allowed_scopes를 추출해 도구 접근 정책과 비교한 뒤, 허용된 요청만 다운스트림 MCP 서버로 프록시한다.

도구 접근 정책은 역할로 도구 카테고리 접근을 제한하고 속성으로 개별 레코드 수준 필터를 적용하는 RBAC·ABAC 혼합 구조로 설계할 수 있다. 금융 트랜잭션, 개인정보 접근, 인프라 변경처럼 위험이 높은 호출은 게이트웨이에서 비동기 인간 승인 플로를 통과하도록 강제한다.

# 도구 접근 정책 예시 (OPA Rego 스타일)
policy:
  name: finance-agent-tools
  principals:
    - agent_id: "finance-reconciliation-agent"
      role: "finance-readonly"
  rules:
    - tool: "db://erp-prod/accounts/*"
      action: read
      condition:
        department: "finance"
        data_classification: ["internal", "confidential"]
    - tool: "db://erp-prod/accounts/*/write"
      action: write
      condition:
        require_human_approval: true
        approver_role: "finance-manager"

감사 로그는 단순한 도구 호출 이력보다 넓은 실행 맥락을 보존해야 한다. 리소스 조회, 도구 호출, 프롬프트 실행에서 최종 액션까지의 체인을 단일 trace_id로 연결하고, 요청 주체인 사용자와 에이전트, 사용한 도구와 입력·결과, 정책 판정과 승인 여부를 함께 기록한다. MCP 게이트웨이에 OpenTelemetry 분산 추적을 통합하면 사후 분석에 필요한 실행 맥락을 보존할 수 있다.

다만 2026년 초 전체 공개 MCP 서버 가운데 OAuth 2.1을 실제 구현한 비율은 8.5%다. 프롬프트 인젝션을 통한 도구 오남용과 광범위한 스코프를 가진 토큰의 노출도 주요 취약점으로 남아 있다.

AAIF Working Group의 보안 거버넌스 성숙도 모델은 다음 단계로 구분된다.

Level 1: Static secret (API Key)
Level 2: OAuth 2.0 (기본 토큰)
Level 3: OAuth 2.1 + PKCE + 스코프 제어
Level 4: SSO(SAML/OIDC) + 세션 스코프 + 감사 추적

Kiteworks의 2026년 조사에서는 보안·IT·리스크 리더 225명 모두가 에이전트 AI를 로드맵에 포함했다. 동시에 배포 목표와 실제 보안 역량 사이에는 위험한 격차가 있는 것으로 나타났다. MCP를 도입할 때 연결 기능과 보안 성숙화를 별도 과제로 다뤄서는 안 되는 이유다.

멀티에이전트는 컨텍스트와 권한을 함께 나눈다

여러 에이전트가 MCP 서버를 공유할 때는 작업 상태를 전달하면서도 민감 정보의 범위를 제한해야 한다. 오케스트레이터가 작업을 나누고, 서브에이전트가 공유 컨텍스트와 메모리 서버를 통해 진행 상태를 이어받는 구조를 사용할 수 있다.

⤢✕

각 에이전트에는 독립 MCP 세션을 부여해 컨텍스트를 격리한다. Memory MCP 서버는 작업 상태를 영속화해 워크플로의 연속성을 유지한다. 독립 서버 연결은 병렬 실행에 활용하고, 고위험 도구 호출에는 AAIF 승인 게이트 패턴에 따른 Human-in-the-loop를 둔다.

Function Calling과 LangChain Tools 사이에서 고르기

MCP, OpenAI Function Calling, LangChain Tools는 모두 모델이 외부 기능을 사용하게 만들지만 탐색 방식과 종속 범위가 다르다.

특성	MCP	OpenAI Function Calling	LangChain Tools
툴 탐색 방식	동적 (런타임 탐색)	정적 (빌드타임 정의)	정적/반동적
공급사 중립성	완전 중립 (멀티벤더)	OpenAI 전용	프레임워크 종속
표준화 거버넌스	Linux Foundation	OpenAI 독점	Proprietary
전송 프로토콜	JSON-RPC 2.0	REST API	Python 함수
엔터프라이즈 거버넌스	OAuth 2.1 + Gateway	API Key 기반	프레임워크 의존
배포 변경 없는 툴 추가	가능	불가 (코드 변경 필요)	제한적
멀티모델 지원	전체 AI 벤더	GPT 계열 한정	다수 모델 지원
성숙도	빠른 성장 (2024~)	성숙 (2023~)	성숙 (2022~)

멀티벤더 지원, 중앙화된 도구 관리, 엔터프라이즈 거버넌스와 공급사 종속 회피가 필요하면 MCP가 맞는다. GPT 전용 서비스에서 빠른 프로토타이핑과 토큰 효율이 우선이라면 OpenAI Function Calling을 선택할 수 있다. 복잡한 에이전트 그래프나 기존 LangChain 파이프라인을 활용해야 한다면 LangChain Tools가 자연스럽다.

두 방식을 섞는 것도 가능하다. 고빈도 핵심 도구는 Function Calling으로 연결해 토큰 효율을 확보하고, 롱테일 도구는 MCP의 동적 탐색으로 관리하는 패턴이다.

아키텍처 원칙으로 읽는 MCP

MCP 서버를 도메인별로 분리하면 인터페이스 분리 원칙(ISP)에 맞게 노출 범위를 줄일 수 있다. 에이전트가 개별 API가 아니라 MCP라는 추상 인터페이스에 의존한다는 점은 의존성 역전 원칙(DIP)과 연결된다. 재사용 가능한 MCP 서버는 서비스 지향 아키텍처의 서비스 컴포넌트로 볼 수 있으며, SSE 전송은 이벤트 기반 아키텍처에서 실시간 스트리밍 결과를 반환하는 방식과 맞닿아 있다. 모든 호출에 OAuth 2.1 인증과 최소 권한 스코프를 적용하는 구조는 제로 트러스트 보안 원칙을 반영한다.

품질 속성	MCP 구현 방식
상호운용성(Interoperability)	JSON-RPC 2.0 표준 + Linux Foundation 표준화
확장성(Scalability)	동적 툴 탐색으로 코드 변경 없는 수평 확장
보안성(Security)	OAuth 2.1 + PKCE + 세션 스코프 인증
이식성(Portability)	공급사 중립 프로토콜로 멀티벤더 전환 용이
가용성(Availability)	Stateless 아키텍처(2026.07 RC)로 수평 확장
감사 추적(Auditability)	MCP Gateway 중앙화 로그 및 AAIF 표준 감사

MCP와 A2A·ACP가 맡는 영역

MCP는 에이전트와 외부 도구, 데이터베이스, API를 연결하는 수직 통합 프로토콜이다. 반면 Google이 주도하는 A2A(Agent-to-Agent)는 에이전트 사이의 작업 위임을, IBM과 Linux Foundation의 ACP(Agent Communication Protocol)는 에이전트 간 메시지 표준을 다룬다.

⤢✕

현재 제시된 수렴 시나리오는 AAIF 거버넌스 아래에서 MCP, A2A, ACP가 공존하며 서로를 보완하는 방식이다. 2027~2028년에는 MCP Stateless 아키텍처가 완성돼 클라우드 네이티브 배포에 최적화되고, 헬스케어·금융·법률·교육 분야의 수직 도메인 프로파일이 확산될 전망이다. Cloudflare Workers와 Lambda@Edge를 대상으로 한 엣지 디바이스용 경량 MCP 구현, ISO/IEC 국제 표준 트랙의 본격화도 전망에 포함된다.

MCP가 연결 파편화를 줄이는 공통 인터페이스라는 사실만으로 엔터프라이즈 도입이 끝나는 것은 아니다. 중앙 게이트웨이, OAuth 2.1 인증, 도구별 최소 권한, 사용자와 에이전트 신원의 분리, 실행 맥락을 묶는 감사 추적과 에이전트별 컨텍스트 격리가 함께 갖춰져야 운영 가능한 기반이 된다.