MCP란 무엇인가? AI Agent와 외부 도구를 연결하는 방법

최근 AI 개발 분야에서는 LLM의 성능뿐 아니라 AI가 외부 시스템과 어떻게 연결되고 실제 작업을 수행하는지가 중요한 주제로 떠오르고 있습니다. 대규모 언어 모델(LLM)이 질문에 답하는 수준을 넘어 데이터베이스를 조회하고, 파일을 읽고, 개발 도구를 사용하며, 여러 시스템을 연결해 작업을 수행하는 구조가 주목받고 있기 때문입니다.

이 과정에서 자주 등장하는 기술이 바로 MCP(Model Context Protocol) 입니다.

MCP는 AI 모델 자체를 더 똑똑하게 만드는 기술이라기보다, AI 애플리케이션이 외부 도구와 데이터에 접근하는 방식을 표준화하는 프로토콜입니다. 그렇다면 MCP는 기존의 API나 Function Calling과 무엇이 다를까요? 그리고 AI Agent 개발에서 MCP가 중요한 이유는 무엇일까요?

이번 글에서는 MCP의 기본 개념부터 아키텍처, 실제 작동 방식, 개발 시 고려해야 할 부분까지 살펴보겠습니다.

1. MCP란 무엇인가?

MCP(Model Context Protocol)는 AI 애플리케이션이 외부 데이터 소스와 도구에 연결할 수 있도록 통신 방식을 표준화한 프로토콜입니다. Anthropic이 2024년 11월 공개했으며, 이후 다양한 AI 개발 도구와 애플리케이션에서 활용되고 있습니다.

쉽게 설명하면 MCP는 AI와 외부 시스템 사이에서 공통으로 사용하는 연결 규격입니다.

예를 들어 AI Agent가 다음과 같은 작업을 수행한다고 가정해 보겠습니다.

프로젝트 폴더에 있는 파일을 읽습니다.
데이터베이스에서 특정 정보를 조회합니다.
GitHub에서 이슈 목록을 가져옵니다.
개발 환경에서 테스트 결과를 확인합니다.
외부 서비스의 기능을 호출합니다.

이러한 기능을 AI에 연결하려면 기존에는 서비스마다 API를 분석하고, 인증 방식을 구현하고, 도구의 입력과 출력을 처리하는 코드를 작성해야 했습니다.

MCP는 이러한 연결 과정을 공통된 프로토콜로 다룰 수 있도록 설계되었습니다.

비유하자면 MCP는 다양한 주변기기를 연결할 때 사용하는 표준 인터페이스와 비슷합니다. 각 도구의 내부 구현은 서로 다르더라도, MCP를 지원하는 클라이언트와 서버는 정해진 방식으로 기능을 탐색하고 요청을 주고받을 수 있습니다.

다만 MCP를 도입한다고 모든 API가 자동으로 연결되는 것은 아닙니다. 실제로 사용하려는 시스템에 MCP 서버가 제공되거나, 직접 MCP 서버를 구현해야 할 수 있습니다.

2. MCP가 필요한 이유: AI와 도구 사이의 연결 문제

LLM은 자연어를 이해하고 코드를 생성하며 다양한 정보를 추론할 수 있습니다. 하지만 모델 자체가 외부 시스템에 직접 접근할 수 있는 것은 아닙니다.

모델이 데이터베이스에 저장된 최신 정보를 조회하거나 로컬 파일을 읽으려면 애플리케이션이 적절한 도구를 연결하고 실행 결과를 전달해야 합니다.

기존 방식에서는 여러 외부 서비스를 연결할 때 각 서비스에 맞는 통합 코드를 작성해야 하는 경우가 많았습니다.

예를 들어 개발자가 파일 시스템, 데이터베이스, GitHub, 사내 API를 하나의 AI 애플리케이션에 연결한다고 생각해 보겠습니다. 각각의 인증 방식, 요청 형식, 응답 처리, 오류 처리 로직을 따로 관리해야 할 수 있습니다.

연결 대상이 늘어나면 구현과 유지보수 부담도 커집니다.

MCP는 이 과정에서 공통 통신 규격을 제공합니다.

MCP를 지원하는 AI 애플리케이션은 연결된 서버가 제공하는 기능을 탐색하고, 정해진 프로토콜에 따라 도구를 호출할 수 있습니다. 따라서 각 서비스의 내부 구현과 AI 애플리케이션 사이의 결합도를 낮추는 데 도움이 됩니다.

여기서 중요한 점은 MCP가 모든 연동 코드를 없애는 기술은 아니라는 것입니다. 외부 시스템과 통신하는 MCP 서버는 여전히 필요하지만, 클라이언트와 서버 사이의 연결 방식을 표준화할 수 있다는 것이 핵심입니다.

3. MCP의 아키텍처: Host, Client, Server

MCP를 이해하려면 세 가지 구성 요소를 먼저 알아야 합니다.

3-1. MCP Host

Host는 MCP를 활용하는 AI 애플리케이션입니다. 사용자의 요청을 받고 LLM과 상호작용하며, MCP 연결과 도구 사용을 관리하는 역할을 합니다.

예를 들어 MCP를 지원하는 AI 개발 환경이나 데스크톱 AI 애플리케이션이 Host가 될 수 있습니다.

Host는 단순히 서버에 요청을 전달하는 것에 그치지 않습니다. 애플리케이션의 정책에 따라 어떤 도구를 사용할 수 있는지 관리하고, 사용자 승인이나 권한 확인을 처리할 수도 있습니다.

3-2. MCP Client

Client는 Host 내부에서 MCP 서버와 통신하는 구성 요소입니다.

일반적으로 MCP 서버와 연결을 관리하고, 프로토콜에 정의된 메시지를 주고받으며, 서버가 제공하는 기능을 탐색하고 호출합니다.

하나의 Host는 여러 MCP 서버에 연결할 수 있습니다. 구현 구조에 따라 각 서버 연결을 담당하는 별도의 Client 인스턴스를 둘 수 있습니다.

3-3. MCP Server

Server는 외부 도구나 데이터에 접근할 수 있도록 기능을 제공하는 구성 요소입니다.

예를 들어 파일 시스템에 접근하는 서버, 데이터베이스를 조회하는 서버, GitHub와 상호작용하는 서버 등을 생각할 수 있습니다.

MCP 서버는 도구의 실제 구현을 담당하고, 클라이언트가 정해진 프로토콜에 따라 기능을 호출할 수 있도록 인터페이스를 제공합니다.

전체 구조를 간단하게 표현하면 다음과 같습니다.

사용자
  ↓
MCP Host
  ├─ LLM
  ├─ MCP Client
  │    ↓
  │  MCP Server A → 파일 시스템
  │
  ├─ MCP Client
  │    ↓
  │  MCP Server B → 데이터베이스
  │
  └─ MCP Client
       ↓
     MCP Server C → 외부 API

이 구조에서 LLM은 사용자의 요청을 해석하고 어떤 도구가 필요한지 판단하는 데 활용될 수 있습니다. MCP Client와 Server는 실제 도구의 기능을 탐색하고 호출하는 통신을 담당합니다.

즉, LLM의 추론과 외부 시스템의 실행을 구분해 설계할 수 있다는 점이 중요합니다.

4. MCP Server가 제공하는 세 가지 핵심 기능

MCP는 단순히 외부 함수를 호출하는 규격만 제공하지 않습니다. 대표적으로 Tools, Resources, Prompts라는 세 가지 기능을 정의합니다.

4-1. Tools: 외부 기능 실행

Tools는 AI 애플리케이션이 외부 시스템의 기능을 실행할 수 있도록 제공하는 인터페이스입니다.

예를 들어 다음과 같은 기능을 Tool로 제공할 수 있습니다.

특정 파일 검색하기
데이터베이스 쿼리 실행하기
GitHub 이슈 조회하기
이슈 생성하기
외부 서비스에 작업 요청하기

각 Tool은 이름과 설명, 입력 스키마 등을 통해 어떤 작업을 수행하는지 나타낼 수 있습니다. 클라이언트는 서버가 제공하는 Tool 목록을 조회하고, 필요한 기능을 호출할 수 있습니다.

다만 Tool이 제공된다고 해서 AI가 무조건 실행 권한을 갖는 것은 아닙니다. 실제 실행 가능 여부는 서버의 권한 설정과 Host의 정책에 따라 달라집니다.

4-2. Resources: 외부 데이터 제공

Resources는 AI 애플리케이션이 참고할 수 있는 데이터나 콘텐츠를 제공하는 기능입니다.

예를 들어 다음과 같은 정보를 Resource로 노출할 수 있습니다.

프로젝트 문서
데이터베이스의 특정 데이터
로그 파일
시스템 상태 정보
사내 지식 문서

Tool이 특정 작업을 실행하는 기능에 가깝다면, Resource는 AI가 참고할 데이터를 제공하는 인터페이스라고 이해할 수 있습니다.

다만 Resource를 어떤 방식으로 LLM의 컨텍스트에 넣을지는 클라이언트 애플리케이션의 구현에 따라 달라집니다.

4-3. Prompts: 재사용 가능한 프롬프트 제공

Prompts는 서버가 재사용 가능한 프롬프트 템플릿을 제공하는 기능입니다.

예를 들어 코드 리뷰, 데이터 분석, 로그 진단 등의 작업에 사용할 프롬프트를 서버에서 정의할 수 있습니다.

클라이언트는 제공되는 프롬프트를 조회하고 필요한 인자를 전달해 사용할 수 있습니다. 이를 통해 특정 업무에 필요한 지시문을 일관된 형태로 관리할 수 있습니다.

세 가지 기능의 차이를 정리하면 다음과 같습니다.

구분	주요 역할	예시
Tools	외부 기능 실행	파일 수정, 이슈 생성
Resources	데이터와 콘텐츠 제공	문서, 로그, 조회 데이터
Prompts	재사용 가능한 프롬프트 제공	코드 리뷰 템플릿

이 세 가지는 MCP 서버가 제공할 수 있는 대표적인 기능입니다. 모든 서버가 세 가지를 전부 구현해야 하는 것은 아닙니다.

5. MCP는 실제로 어떻게 작동할까?

사용자가 AI에게 다음과 같이 요청했다고 가정해 보겠습니다.

"GitHub 프로젝트에서 최근 생성된 이슈를 찾아 핵심 내용을 정리해 줘."

이 요청을 처리하는 과정은 다음과 같이 구성할 수 있습니다.

1단계: 사용자의 요청을 해석합니다.

LLM은 요청을 분석하고 GitHub의 이슈 데이터를 조회해야 한다고 판단할 수 있습니다.

2단계: 사용 가능한 도구를 확인합니다.

MCP Client는 연결된 MCP 서버에서 사용할 수 있는 Tool 목록을 확인합니다. 서버가 list_issues라는 도구를 제공한다면 해당 도구의 설명과 입력 스키마를 활용할 수 있습니다.

3단계: 도구를 호출합니다.

Host는 LLM의 판단과 애플리케이션 정책에 따라 필요한 도구 호출을 진행합니다. MCP Client는 해당 요청을 MCP Server에 전달합니다.

4단계: 외부 시스템에서 데이터를 가져옵니다.

MCP Server는 GitHub API 등 실제 외부 시스템과 통신해 이슈 데이터를 조회하고 결과를 반환합니다.

5단계: 결과를 LLM에 전달합니다.

Host는 도구 실행 결과를 모델의 컨텍스트에 전달해 후속 추론을 진행하도록 할 수 있습니다.

6단계: 사용자에게 결과를 제공합니다.

LLM은 조회된 내용을 바탕으로 이슈의 핵심 사항을 요약합니다.

이 과정을 간단히 나타내면 다음과 같습니다.

사용자 요청
    ↓
LLM의 작업 판단
    ↓
MCP Client
    ↓
MCP Server
    ↓
외부 API 또는 데이터
    ↓
도구 실행 결과
    ↓
LLM의 후속 추론
    ↓
최종 응답

여기서 MCP가 담당하는 것은 주로 클라이언트와 서버 사이의 표준화된 통신입니다. 어떤 도구를 선택할지, 몇 번 호출할지, 결과를 어떻게 활용할지는 LLM과 Host 애플리케이션의 구현에 따라 달라집니다.

따라서 MCP를 도입했다고 해서 AI Agent가 자동으로 자율적인 판단 능력을 얻는 것은 아닙니다.

6. MCP와 API, Function Calling의 차이

MCP를 처음 접할 때 가장 혼동하기 쉬운 부분은 기존 API와 Function Calling의 차이입니다.

MCP와 API

API는 서로 다른 소프트웨어가 기능이나 데이터를 주고받기 위한 인터페이스입니다. REST API, GraphQL API 등 다양한 형태가 있습니다.

MCP 서버는 내부적으로 외부 API를 호출할 수 있습니다. 하지만 MCP 자체가 외부 API를 대체하는 것은 아닙니다.

예를 들어 GitHub API를 직접 호출하는 프로그램을 만들 수도 있고, GitHub API를 감싸는 MCP 서버를 구현해 MCP Client에서 사용할 수도 있습니다.

두 방식은 서로 경쟁하는 관계라기보다 서로 다른 계층에서 활용될 수 있습니다.

MCP와 Function Calling

Function Calling은 LLM이 애플리케이션에 정의된 함수 호출을 요청할 수 있도록 하는 모델 또는 API의 기능입니다.

예를 들어 모델이 다음과 같은 형태의 호출을 요청한다고 가정해 보겠습니다.

{
  "name": "get_weather",
  "arguments": {
    "city": "Seoul"
  }
}

이것은 모델이 함수와 인자를 지정하는 예시입니다. 실제 함수 실행은 애플리케이션이 담당하고, 실행 결과를 모델에 다시 전달할 수 있습니다.

MCP는 이러한 도구 호출 과정에서 외부 도구를 발견하고 통신하는 표준화된 방법을 제공합니다. MCP를 사용하는 애플리케이션은 서버에서 Tool 정보를 가져와 모델에 제공하고, 모델이 요청한 도구를 실제 MCP 호출로 연결할 수 있습니다.

따라서 Function Calling과 MCP는 동일한 개념이 아닙니다.

Function Calling은 모델이 도구 사용을 요청하는 방식과 관련되고, MCP는 AI 애플리케이션과 외부 도구 사이의 통신 규격과 관련됩니다. 실제 시스템에서는 두 기술을 함께 사용할 수 있습니다.

7. MCP와 RAG는 어떤 관계일까?

MCP와 RAG(Retrieval-Augmented Generation)는 모두 AI가 외부 정보를 활용하는 데 관련되지만, 해결하려는 문제는 다릅니다.

RAG는 외부 문서나 데이터에서 관련 정보를 검색한 뒤, 검색 결과를 LLM의 컨텍스트에 제공해 답변을 생성하는 아키텍처입니다.

예를 들어 사내 문서에서 특정 정책을 찾아 답변하는 시스템은 RAG를 활용할 수 있습니다.

반면 MCP는 AI 애플리케이션이 외부 도구와 데이터에 연결하는 표준 인터페이스를 제공합니다. MCP 서버가 검색 기능을 Tool로 제공한다면, AI 애플리케이션이 이를 이용해 RAG 파이프라인의 일부를 실행하도록 구성할 수도 있습니다.

두 기술의 관계를 정리하면 다음과 같습니다.

RAG: 외부 지식을 검색해 LLM 응답에 활용하는 방식
MCP: AI 애플리케이션과 외부 도구·데이터를 연결하는 프로토콜

MCP가 RAG를 대체하는 것은 아닙니다. 오히려 MCP를 통해 검색 도구를 제공하고, 그 도구를 RAG 기반 AI 애플리케이션에서 활용하는 조합도 가능합니다.

RAG의 기본 구조가 궁금하다면 관련 글인 'RAG란 무엇인가? LLM의 한계를 보완하는 검색증강생성 구조'와 함께 살펴보면 이해하기 쉽습니다.

8. AI Agent 개발에서 MCP가 중요한 이유

AI Agent는 사용자의 목표를 달성하기 위해 LLM의 추론, 도구 사용, 작업 결과 확인 등을 조합하는 시스템입니다.

Agent가 복잡한 작업을 수행하려면 다양한 외부 시스템과 연결되어야 합니다. 파일을 읽고, 코드를 실행하고, 데이터베이스를 조회하고, 업무 시스템에 요청을 보내는 기능이 필요할 수 있습니다.

이때 각 도구를 개별적으로 통합하는 대신 MCP를 활용하면 연결 방식을 공통 규격으로 정리할 수 있습니다.

예를 들어 개발자가 여러 AI 애플리케이션에서 같은 MCP 서버를 사용할 수 있도록 구성하면, 각 애플리케이션마다 도구의 내부 구현을 반복해서 작성할 필요를 줄일 수 있습니다. 반대로 기존 MCP 서버를 지원하는 Host에 연결해 재사용하는 것도 가능합니다.

특히 다음과 같은 환경에서 MCP의 활용 가치를 검토할 수 있습니다.

여러 AI 개발 도구에서 공통 도구를 사용해야 하는 환경
사내 데이터와 외부 서비스를 AI 애플리케이션에 연결하는 환경
AI Agent가 다양한 업무 시스템을 활용해야 하는 환경
도구의 구현과 AI 애플리케이션의 로직을 분리하고 싶은 환경

다만 MCP가 모든 상황에서 가장 효율적인 선택은 아닙니다. 단일 애플리케이션에서 간단한 함수 몇 개만 호출한다면 직접적인 API 연동이 더 단순할 수도 있습니다.

중요한 것은 기술의 유행보다 시스템의 복잡도, 재사용성, 보안 요구사항을 기준으로 적절한 구조를 선택하는 것입니다.

9. MCP를 사용할 때 고려해야 할 보안 문제

MCP를 활용하면 AI 애플리케이션이 파일이나 데이터베이스, 외부 서비스에 접근할 수 있습니다. 편리한 만큼 권한과 보안에 대한 설계도 중요합니다.

특히 쓰기 작업이나 외부 시스템 변경을 수행하는 도구를 제공할 때는 주의해야 합니다.

첫째, 최소 권한 원칙을 적용해야 합니다. MCP 서버가 필요한 데이터와 기능에만 접근할 수 있도록 권한을 제한하는 것이 좋습니다.

둘째, 도구 입력값을 검증해야 합니다. 파일 경로, SQL 쿼리, 외부 API 요청 등을 무조건 신뢰하면 의도하지 않은 동작이 발생할 수 있습니다.

셋째, 중요한 작업에는 승인 절차를 고려해야 합니다. 파일 삭제, 데이터 변경, 메시지 전송, 결제와 같은 작업은 사용자 확인이나 별도의 정책 검증이 필요할 수 있습니다.

넷째, 신뢰할 수 있는 서버와 도구만 연결해야 합니다. MCP 서버의 출처와 코드, 권한 범위를 확인하고 인증 정보나 민감한 데이터가 불필요하게 노출되지 않도록 관리해야 합니다.

다섯째, 도구 실행 기록과 오류를 추적할 수 있도록 로깅과 모니터링을 구성하는 것이 좋습니다.

MCP는 연결 규격을 제공하지만, 그 자체가 모든 보안 문제를 자동으로 해결해 주지는 않습니다. 실제 보안 수준은 Host, Client, Server의 구현과 권한 관리 방식에 달려 있습니다.

10. MCP를 이해한 다음에는 무엇을 공부해야 할까?

MCP를 이해했다면 다음 단계에서는 AI 애플리케이션이 도구를 활용하는 전체 구조를 살펴보는 것이 좋습니다.

먼저 Function Calling을 공부하면 LLM이 어떤 형태로 도구 실행을 요청하고, 애플리케이션이 그 요청을 어떻게 처리하는지 이해할 수 있습니다.

다음으로 AI Agent의 구조를 살펴보면 LLM의 판단, 도구 호출, 결과 확인, 반복 실행이 어떻게 하나의 작업 흐름으로 연결되는지 알 수 있습니다.

RAG와 Vector Database를 함께 공부하면 AI가 외부 지식을 검색하는 방식도 이해할 수 있습니다. 여기에 MCP를 결합하면 검색 기능이나 업무 시스템을 AI 애플리케이션에 연결하는 방법까지 살펴볼 수 있습니다.

추천 학습 순서는 다음과 같습니다.

LLM과 Function Calling의 기본 개념
AI Agent의 구조와 도구 사용 방식
RAG와 Vector Database
MCP의 Host, Client, Server 구조
MCP Server 구현과 실제 도구 연결
인증, 권한, 입력 검증 및 실행 기록 관리

MCP를 단순한 연결 기술로만 이해하기보다, AI Agent의 기능을 모듈화하고 외부 시스템과 연결하는 아키텍처의 일부로 이해하는 것이 중요합니다.

마치며: MCP는 AI와 외부 시스템 사이의 공통 언어입니다

MCP(Model Context Protocol)는 AI 모델 자체의 추론 능력을 향상시키는 기술이 아닙니다. 대신 AI 애플리케이션이 외부 도구와 데이터에 접근하는 방식을 표준화해 다양한 시스템을 연결하고 재사용하기 쉽게 만드는 데 목적이 있습니다.

API가 외부 시스템의 기능을 제공하고, Function Calling이 LLM의 도구 사용 요청을 지원한다면, MCP는 AI 애플리케이션과 외부 도구 사이의 통신을 표준화하는 역할을 합니다.

앞으로 AI Agent가 여러 데이터 소스와 업무 시스템을 활용하는 환경이 확대될수록, 도구 연결과 권한 관리, 실행 흐름을 어떻게 설계할 것인지는 중요한 개발 과제가 될 것입니다.

MCP는 이러한 구조를 이해하는 데 필요한 핵심 기술 중 하나입니다. AI 개발을 공부하고 있다면 MCP의 개념을 익히는 데서 그치지 않고, 실제 MCP 서버를 연결해 도구를 탐색하고 호출하는 과정까지 직접 실습해 보는 것을 추천합니다.

이 블로그 검색

빈이의 AI이야기