MCP란 무엇인가? AI Agent와 기업 시스템을 연결하는 표준 구조

생성형 AI가 문장을 잘 만드는 것과 실제 업무를 처리하는 것은 다른 문제입니다.

AI 모델만으로는 사내 문서의 최신 내용을 확인하거나, 업무 시스템에서 회의록을 조회하거나, 승인된 사용자의 일정과 이슈를 변경할 수 없습니다. 이런 작업에는 외부 데이터와 기능을 안전하게 연결하는 통합 계층이 필요합니다.

MCP(Model Context Protocol)는 바로 이 연결 방식을 표준화한 공개 프로토콜입니다. AI 애플리케이션이 파일, 데이터베이스, SaaS, 사내 API 같은 외부 시스템을 일관된 방식으로 발견하고 사용할 수 있게 합니다.

흔히 MCP를 ‘AI 애플리케이션을 위한 USB-C’에 비유합니다. 연결 대상마다 전용 어댑터를 새로 설계하는 대신, 공통 규격으로 데이터와 도구를 연결한다는 의미입니다.

MCP가 해결하려는 문제

MCP가 없다고 해서 AI와 업무 시스템을 연결할 수 없는 것은 아닙니다. 기존 REST API나 SDK를 직접 연동해도 됩니다. 문제는 AI 애플리케이션과 외부 시스템이 늘어날수록 통합 조합이 빠르게 복잡해진다는 점입니다.

예를 들어 세 개의 AI 애플리케이션이 문서, 일정, 이슈 관리, 회의록 시스템에 각각 연결된다면 애플리케이션마다 인증 방식, API 형식, 오류 처리, 도구 설명을 별도로 구현해야 할 수 있습니다.

MCP는 이 사이에 공통 계약을 둡니다.

[사용자]
    │
    ▼
[MCP Host: AI 애플리케이션]
    │
    ├─ [MCP Client] ─ [문서 MCP Server] ─ 문서 저장소
    ├─ [MCP Client] ─ [이슈 MCP Server] ─ 이슈 관리 API
    └─ [MCP Client] ─ [회의 MCP Server] ─ 회의록 시스템

외부 시스템이 MCP Server로 기능을 제공하면, MCP를 지원하는 여러 AI 애플리케이션에서 같은 방식으로 연결할 수 있습니다. 다만 MCP가 기존 API를 없애는 것은 아닙니다. 대부분의 기업 환경에서는 기존 API와 업무 로직을 유지하고, 그 앞에 AI가 이해할 수 있는 MCP 인터페이스를 추가하게 됩니다.

Host, Client, Server의 역할

MCP는 크게 세 구성요소로 이해하면 쉽습니다.

1. MCP Host

사용자가 실제로 대화하거나 작업하는 AI 애플리케이션입니다. 여러 MCP Server 연결을 관리하고, 모델에 어떤 컨텍스트를 제공할지 결정하며, 사용자 승인과 보안 경계를 통제합니다.

2. MCP Client

Host 내부에서 특정 MCP Server와 연결을 담당하는 구성요소입니다. 일반적으로 Server 하나마다 전용 Client 연결이 만들어집니다.

3. MCP Server

외부 데이터와 업무 기능을 MCP 규격으로 노출하는 프로그램입니다. 로컬 PC에서 실행될 수도 있고, 기업의 원격 서버나 SaaS 환경에서 운영될 수도 있습니다.

여기서 중요한 점은 MCP Server가 AI 모델 자체가 아니라는 것입니다. Server는 자신이 담당하는 데이터와 기능을 명확한 계약으로 제공하고, 실제 추론과 전체 작업 조정은 Host가 담당합니다.

Tools, Resources, Prompts

MCP Server가 제공하는 핵심 요소는 세 가지입니다.

구분	역할	예시
Tools	외부 시스템에서 동작을 실행	회의록 조회, 이슈 생성, 일정 변경
Resources	모델이 참고할 데이터 제공	문서 내용, DB 스키마, 회의 상세 정보
Prompts	반복 가능한 작업 절차와 입력 형식 제공	회의 요약 작성, 장애 분석 템플릿

Tools: 행동

Tool은 AI가 호출할 수 있는 함수에 가깝습니다. 이름, 설명, 입력 스키마, 출력 형식을 통해 ‘무엇을 어떤 인자로 실행하는지’를 정의합니다.

{
  "name": "get_meeting_summary",
  "description": "지정한 회의의 승인된 AI 요약을 조회합니다.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "meetingId": {
        "type": "string",
        "description": "조회할 회의 식별자"
      }
    },
    "required": ["meetingId"]
  }
}

설명이 모호하면 모델이 잘못된 Tool을 선택할 수 있습니다. 따라서 Tool 설명은 단순한 개발 문서가 아니라 AI의 실행 품질을 좌우하는 인터페이스 설계입니다.

Resources: 컨텍스트

Resource는 파일, 문서, 레코드처럼 모델이 읽고 판단에 사용할 정보를 제공합니다. 모든 데이터를 프롬프트에 미리 넣지 않고, 필요한 시점에 필요한 범위만 가져올 수 있다는 장점이 있습니다.

Prompts: 재사용 가능한 작업 방식

Prompt는 특정 업무를 일관된 순서와 형식으로 수행하도록 돕는 템플릿입니다. 조직의 분석 절차나 결과 형식을 재사용 가능한 형태로 제공할 때 유용합니다.

MCP 요청은 어떻게 처리되는가

최신 2026-07-28 사양을 기준으로 보면 기본 흐름은 다음과 같습니다.

1. Client가 server/discover로 Server의 버전과 지원 기능을 확인합니다.
2. Client가 tools/list, resources/list, prompts/list 등으로 사용 가능한 기능을 조회합니다.
3. 사용자의 요청을 받은 Host가 적절한 Tool 또는 Resource를 선택합니다.
4. 필요한 경우 Host가 사용자에게 실행 여부나 추가 입력을 확인합니다.
5. Client가 tools/call 같은 요청을 Server에 전달합니다.
6. Server가 권한과 입력값을 검증하고 내부 API 또는 데이터 저장소를 호출합니다.
7. 결과가 Host로 돌아오면 모델이 이를 해석해 사용자에게 응답합니다.

MCP의 데이터 계층은 JSON-RPC 2.0을 사용합니다. 전송 방식은 로컬 프로세스 연결에 적합한 stdio와 원격 연결에 적합한 Streamable HTTP가 대표적입니다.

참고: 2025-11-25 이전 방식에 익숙하다면 주의해야 합니다. 2026-07-28 사양에서는 initialize 핸드셰이크와 Mcp-Session-Id 기반 프로토콜 세션이 제거됐습니다. 요청마다 필요한 버전과 기능 정보를 전달하는 stateless 구조가 도입되어 일반적인 HTTP 인프라에서 수평 확장이 쉬워졌습니다.

REST API와 MCP는 무엇이 다른가

REST API와 MCP는 경쟁 관계가 아닙니다.

관점	REST API	MCP
주 사용자	일반 애플리케이션과 개발자	AI Host, Agent, 개발 도구
인터페이스	서비스별 엔드포인트와 문서	발견 가능한 공통 프리미티브
기능 탐색	별도 API 문서나 SDK 필요	*/list, server/discover 사용
AI 사용 설명	애플리케이션에서 별도 작성	Tool 설명과 스키마에 포함
기존 시스템 관계	업무 기능의 원본 인터페이스	기존 API를 AI에 연결하는 어댑터 역할

기업 시스템에서 일반적인 구조는 다음과 같습니다.

AI Agent
   │
MCP Host / Client
   │
인증·정책·감사 계층
   │
도메인별 MCP Server
   │
기존 REST API / 메시징 / 데이터베이스

기존 업무 API가 잘 설계돼 있다면 다시 만들 필요가 없습니다. MCP Server는 기존 API를 호출하면서 AI가 사용할 수 있는 도구 이름, 입력 스키마, 권한 경계, 결과 형식을 제공하면 됩니다.

기업용 MCP에서 더 중요한 것

간단한 데모는 Tool 하나를 연결하는 것만으로 완성할 수 있습니다. 하지만 운영 시스템에서는 ‘연결된다’보다 ‘통제할 수 있다’가 더 중요합니다.

최소 권한

모든 기능을 하나의 광범위한 권한으로 열지 말고 조회, 생성, 수정, 삭제 권한을 분리해야 합니다. 원격 HTTP 환경에서는 OAuth 기반 인증과 세분화된 scope를 적용하고, Server는 요청마다 실제 권한을 다시 확인해야 합니다.

조회와 변경의 분리

읽기 Tool과 쓰기 Tool을 구분해야 합니다. 삭제, 외부 발송, 결제, 상태 변경처럼 영향이 큰 작업은 실행 직전 사용자 확인 단계를 두는 것이 안전합니다.

사용자와 조직 경계

모델이 특정 레코드의 식별자를 알고 있다는 사실이 접근 권한을 의미하지는 않습니다. 모든 요청에서 사용자, 조직, 역할을 검증해 다른 사용자나 테넌트의 데이터가 노출되지 않도록 해야 합니다.

토큰과 비밀정보 관리

액세스 토큰을 그대로 하위 시스템에 전달하는 token passthrough는 피해야 합니다. Server는 자신을 대상으로 발급된 토큰인지 검증하고, 내부 시스템용 자격증명은 별도의 안전한 저장소에서 관리해야 합니다. 인증 헤더, 토큰, 인가 코드가 로그에 남지 않도록 마스킹도 필요합니다.

감사와 관측성

누가 어떤 Tool을 어떤 인자로 호출했고, 승인 여부와 결과가 무엇이었는지 추적할 수 있어야 합니다. 단, 감사 로그에도 개인정보와 비밀정보가 과도하게 저장되지 않도록 데이터 분류와 보존 정책을 함께 설계해야 합니다.

입력 검증과 멱등성

모델이 생성한 인자도 신뢰할 수 없는 외부 입력으로 취급해야 합니다. 스키마 검증뿐 아니라 업무 규칙 검증이 필요합니다. 재시도될 수 있는 생성·수정 작업은 중복 처리를 막기 위한 멱등성 키나 업무 식별자를 고려해야 합니다.

MCP가 적합한 경우와 그렇지 않은 경우

MCP는 다음 상황에서 특히 효과적입니다.

• 하나의 업무 기능을 여러 AI 애플리케이션에서 사용해야 할 때
• Agent가 필요한 기능을 동적으로 발견해야 할 때
• 사내 데이터와 실행 기능에 공통 보안 경계를 적용해야 할 때
• AI 모델이나 Host 제품이 바뀌어도 통합 자산을 재사용하고 싶을 때

반대로 단일 애플리케이션이 단일 API를 호출하고 인터페이스가 거의 변하지 않는다면 직접 연동이 더 단순할 수 있습니다. 실시간 대용량 스트리밍이나 매우 낮은 지연이 핵심인 데이터 경로도 별도의 전용 프로토콜이 더 적합할 수 있습니다.

MCP를 도입하는 목적은 유행하는 기술을 하나 더 추가하는 데 있지 않습니다. AI와 업무 시스템 사이의 계약을 표준화하고, 연결 기능을 재사용 가능한 통합 자산으로 만드는 데 있습니다.

마무리

MCP는 AI 모델의 성능을 높이는 기술이라기보다 AI가 실제 시스템과 협업하는 방식을 정리하는 프로토콜입니다.

핵심은 다음 세 문장으로 요약할 수 있습니다.

1. MCP Server는 데이터와 기능을 Tools, Resources, Prompts로 제공합니다.
2. MCP Host는 여러 Server를 연결하고 모델의 판단, 사용자 승인, 보안 경계를 관리합니다.
3. 기업 환경에서는 Tool 개수보다 권한, 감사, 실패 처리, 기존 API와의 경계 설계가 더 중요합니다.

다음 글에서는 이 구조를 바탕으로 기업용 MCP Server를 설계할 때 Tool을 어떻게 나누고 이름과 입력 스키마를 어떻게 정의해야 하는지 구체적인 사례와 함께 살펴보겠습니다.

---

참고 자료

• MCP 공식 소개
• MCP 아키텍처 개요
• MCP 보안 모범 사례
• MCP 2026-07-28 사양 릴리스 안내

이 글은 2026년 7월 29일 기준 공식 문서와 MCP 2026-07-28 사양을 바탕으로 작성했습니다. 프로토콜과 SDK 지원 상태는 이후 변경될 수 있으므로 실제 구현 시 사용 중인 Client와 SDK의 지원 버전을 함께 확인해야 합니다.