[AI/LLM] MCP(Model Context Protocol): LLM이 곧바로 DB에서 최신 데이터도 읽고, 메일도 보내준다고?

🌏 MCP(Model Context Protocol)

AI 모델이 외부 시스템, 데이터, 도구와 상호작용하는 방식을 표준화한 통신 규약

✅ 개념

 

MCP는 비교적 최근(2024년 말부터 2025년 초까지) Anthropic에서 발표한 프로토콜로, LLM 기반 에이전트 시대에 필요한 모델 중심 프로토콜입니다.

 

기존 인터넷 프로토콜(HTTP, WebSocket 등)은 네트워크 통신 자체만 정의했지만, MCP는 AI 모델이 어떤 메시지를 주고받을지 자체를 정의합니다.

 

LLM은 적당히 똑똑하지만, 모델 자체가 학습 시점의 지식에 고착되어 있고, 외부 세계와 상호작용할 수 없습니다. 즉, 실시간 데이터에 액세스하거나 회의 예약, 고객 기록 업데이트와 같은 작업을 수행할 수 없습니다.

 

 

 

[LLM이 못 하는 것]

• 실제 파일 읽기·쓰기
• 인터넷 검색 후 결과 정리
• 회사 내부 API 호출
• 데이터베이스 조회·수정
• 반복 작업 자동 실행
• 여러 단계를 연결한 워크플로우 수행
• 도구 실행 결과를 다시 이용해 다음 행동 결정

주로 외부의 서비스에 직접 손대는 것들을 못하죠?

 

Model Context Protocol(MCP)은 이러한 문제를 해결하기 위해 설계된 개방형 표준입니다. 2024년 11월 Anthropic에서 도입한 MCP는 LLM이 외부 데이터, 애플리케이션, 서비스와 통신할 수 있는 안전하고 표준화된 '언어'를 제공합니다. AI가 정적 지식을 넘어 현재 정보를 검색하고 조치를 취할 수 있는 동적 에이전트가 되도록 지원하는 브리지 역할을 하여 AI의 정확성, 유용성, 자동화를 높입니다.

 

이를 통해 AI가 단순히 입력에 대한 응답을 생성하는 수준을 넘어, 필요한 데이터를 스스로 서버에 요청하거나 외부 시스템을 호출할 수 있게 만드는 것입니다.

결과적으로는 정확한 정보를 바탕으로 추론해 더 정확한 답변을 생성할 수 있어 할루시네이션을 억제하는 효과가 있습니당

 

✅ RAG와의 차이점

RAG는 응답 생성 전!!!에 관련 정보를 검색해 LLM 프롬프트에 함께 제공해 응답의 품질을 높이는 방법입니다. 여전히 외부와 상호작용할 수는 없습니다. 그냥 LLM이 좀더 잘 말하게 하는 기능입니다.

 

 

MCP는 LLM이 외부 도구와 서비스에 엑세스하고 상호작용할 수 있도록, 정보도 검색해 읽고 쓰기 작업도 할 수 있도록 하는 양방향 상호작용 레이어를 제공하는 프로토콜입니다. (웹소켓식 양방향은 아님! 나중에 한다고는 하는 것 같음)

 

🌏 MCP 아키텍처

✅ MCP 호스트

• 사용자가 AI를 사용하는 공간
• LLM이 포함된 전체 실행 환경
• MCP 호스트 = LLM + MCP 클라이언트

 

✅ MCP 클라이언트

• LLM ↔ MCP 서버의 통신
• MCP에 대한 LLM의 요청을 변환하고, LLM에 대한 MCP의 응답을 변환
• 사용 가능한 MCP 서버를 찾아 사용

 

✅ MCP 서버

• LLM에 컨텍스트, 데이터, 기능 등을 제공하는 외부 서비스
• 외부 서비스에 연결해 LLM의 응답을 LLM이 이해할 수 있는 형식으로 변환

 

✅ 전송 계층

• JSON-RPC 2.0 메세지 사용해 클라이언트 ↔ 서버 통신

 

[전송 방법]

• 표준 입력/출력(stdio): 로컬 리소스에 적합하며 빠른 동기식 메시지 전송을 제공합니다.
• 서버 전송 이벤트(SSE): 원격 리소스에 선호되며 효율적인 실시간 데이터 스트리밍을 지원합니다.

 

 

🌏 MCP 작동 예시

“DB에서 최신 판매 보고서 찾아서 관리자한테 이메일로 보내줘”

 

 

1) 요청 분석

LLM은 자신이 할 수 있는 것 없는 것을 분리할 수 있습니다.

• 할 수 있는 것: 판매 자료 찾기, 이메일 내용 작성
• 할 수 없는 것: DB 검색, 이메일 보내기

자신이 할 수 없는 것은 MCP 클라이언트를 사용해 사용 가능한 도구를 검색하고, MCP 서버에 등록된 관련 도구 2개(database_query 도구와 email_sender 도구)를 찾습니다.

 

 

2) 도구 호출

LLM은 도구 호출을 위해 요청을 생성합니다.

보고서 이름을 지정하여 database_query 도구를 호출합니다. 그러면 MCP 클라이언트가 이 요청을 적절한 MCP 서버로 보냅니다.

 

 

3) 외부 작업 및 데이터 반환

MCP 서버는 요청을 수신하고 이를 회사의 데이터베이스에 대한 보안 SQL 쿼리로 변환하여 판매 보고서를 검색합니다.

그런 다음 이 데이터를 포맷하여 LLM에 다시 보냅니다.

 

 

4) 두 번째 작업 및 응답 생성

보고서 데이터를 확보한 LLM은 email_sender 도구를 호출하여 관리자의 이메일 주소와 보고서 콘텐츠를 제공합니다. 이메일이 전송된 후 MCP 서버는 작업이 완료되었음을 확인합니다.

 

 

5) 최종 확인

LLM이 최종 응답을 제공합니다.

'최신 판매 보고서를 찾아서 관리자에게 이메일로 보냈습니다.'

 

 

🌏 너무 모호합니다. MCP는 어떻게 생겼슴니까!!!

우리에게 익숙한 HTTP는 이렇게 생긴 문자 기반 규격입니다.

 

GET /users HTTP/1.1
Host: example.com
Authorization: Bearer ...
Content-Type: application/json

 

 

요청 라인 → 헤더 → 바디 이런 구조가 표준인 것처럼, MCP는 아래와 같은 구조를 가집니당

 

 

✅ MCP 요청/응답 형태

MCP는 JSON-RPC 2.0 기반입니다. (= 모든 요청이 JSON 객체 형태입니다.)

 

 

[MCP 요청 예시]

{
  "jsonrpc": "2.0",
  "id": "23",
  "method": "tools.call",
  "params": {
    "tool": "query_database",
    "arguments": {
      "query": "SELECT * FROM sales WHERE date = '2025-01-01';"
    }
  }
}

 

 

 

[MCP 응답 예시]

{
  "jsonrpc": "2.0",
  "id": "23",
  "result": {
    "content": [
      { "id": 1, "amount": 10000, "region": "서울" },
      { "id": 2, "amount": 15000, "region": "부산" }
    ],
    "is_final": true}
}

 

 

 

또 메세지의 타입이 5가지로 표준화되어 있습니다.

✅ MCP 메세지 타입

1) message

LLM이 받거나 보내는 일반 텍스트 메시지

 

{
  "type": "message",
  "role": "user",
  "content": "서울 날씨 알려줘"
}

 

 

2) tool.call

LLM이 외부 도구 호출을 요청하는 메시지

 

{
  "type": "tool.call",
  "tool": "search_weather",
  "arguments": { "city": "Seoul" }
}

 

 

3) tool.result

도구가 수행된 후 MCP 서버가 보내는 결과

 

{
  "type": "tool.result",
  "tool": "search_weather",
  "content": { "temp": 21, "status": "Cloudy" },
  "is_final": true}

 

 

4) resource.*

파일/DB/문서 등 “리소스” 읽고 쓰는 메시지

 

{
  "type": "resource.read",
  "uri": "file:///workspace/readme.md"
}

 

 

5) stream.chunk

스트리밍 중간 결과

 

{
  "type": "stream.chunk",
  "content": "데이터 분석 중... 42% 완료"
}

 

 

여기에서는 모두 소개하지 못하지만, Anthropic은 MCP 스펙을 다음처럼 구성해 공개했으니 한번 찾아가서 살펴보셔도 좋을 것 같습니다.

https://modelcontextprotocol.io/docs/getting-started/intro

 

• Message Types
• RPC Methods
• Sessions
• Resource API
• Tool Call Workflow
• Event 구조
• Transport 규약

 

 

🌏 HTTP 그냥 쓰면 안됨? 왜 굳이 MCP를 만든걸까?

물론 AI 모델 역시 http 통신을 통해 외부 시스템과 통신할 수 있었습니다만,
여러 가지 한계가 있기에 새로운 프로토콜을 제안하게 되었습니다.

 

1) HTTP는 Stateless함

HTTP는 본질적으로 stateless입니다.

그렇기 떄문에 모델이 이전 요청의 컨텍스트를 기억할 수 없어 매 요청마다 전체 프롬프트를 다시 보내야 하는 문제가 발생합니다.

이 무상태성은 서버와 클라이언트 통신에서는 서버를 자유롭게 확장할 수 있게 해 확장성에는 유리하지만, AI 모델과의 통신에서는 단점이 됩니다. (비용 증가 + 지연 증가 발생)

 

 

2) 도구 호출 형식이 서비스마다 모두 달랐음 (표준 부재)

OpenAI, Anthropic, Google, AWS 모두 function calling 규격이 서로 달랐습니다.
각 벤더마다 다른 형태의 JSON을 사용했고, 외부 서비스를 연결할 때마다 커스텀 어댑터를 새로 만들었습니다.

 

 

3) 양방향 스트리밍·이벤트 기반 구조가 부족함

기존 HTTP는 단방향 구조이기 때문에 비효율성을 가지고 있습니다.

HTTP는 요청-응답만 지원하기 때문에 모델이 도구 실행 결과를 기다리는 동안 멈추게 되고, 서버가 모델에게 변화를 알릴 방법이 없었습니다. 또 스트리밍은 있어도 이벤트 구조가 없기 때문에 AI 모델이 외부 데이터를 스트리밍으로 받아가며 추론하는 데에는 적합하지 않습니다.

 

 

4) 반복적인 요청 오버헤드

HTTP는 요청마다 모든 메타데이터(헤더, 인증정보, 옵션) 를 다시 전송합니다. LLM은 많은 기능을 호출할 때 매우 짧은 주기의 요청을 수십~수백 번 반복하는데, 이런 구조에서는 불필요한 네트워크 패킷이 누적될 수 있습니다.

물론 이 오버헤드 자체가 치명적인 문제는 아니지만, AI 시스템 특성상 더 가볍고 연속적인 통신 구조가 필요하다는 한계를 보여줍니다.

 

 

5) HTTP는 양방향/실시간 통신에 적합하지 않음!

HTTP는 본질적으로 Request → Response 구조로 설계된 단방향 프로토콜입니다.

그러니깐! 클라이언트 → 서버 방향만 주도권이 있습니다.

= HTTP에서는 통신을 시작할 수 있는 주체가 오직 클라이언트뿐입니다.
= 서버는 스스로 말 걸기를 할 수 없습니다.

AI 에이전트가 도구 실행 후 결과를 조금씩 알려야 할 때에 적합하지 않습니다.

또한 서버에서 실시간 업데이트가 있을 때 모델에게 알릴 방법이 없습니다.

파일이 수정되거나 DB 값이 바뀌었을 때에 서버는 모델에게 현재 변화가 생겼다고 전달해야 하는지, HTTP에서는 이런 과정이 불가합니다. (정확히는 자연스럽지 않습니다. SSE나 WebSocket 기반 이벤트, 폴링 등을 사용해야 하고, 규격이 제각각인데다가 표준 메세지 형태가 없습니다)

 

 

이러한 구조적 한계 때문에, AI 모델이 실시간·상태 유지형 통신을 수행하기에는 HTTP만으로는 부족합니다. 그 대안으로 등장한 것이 바로 MCP입니다.

 

🌏 MCP의 효능

• 할루시네이션 감소
  • MCP를 사용하면 LLM이 실시간 정보, 확실한 정보를 가지고 응답을 생성할 수 있습니다.
• AI 유용성/자동화 향상
  • 많은 작업들을 자동화할 수 있습니다.
• AI를 외부 서비스와 간편하게 연결할 수 있음
• 작업의 추적성 증가 (traceability)

 

 

🌏 참고자료

• https://modelcontextprotocol.io/docs/getting-started/intro
• https://github.com/modelcontextprotocol/modelcontextprotocol
• https://cloud.google.com/discover/what-is-model-context-protocol?hl=ko
• https://bcho.tistory.com/1470

 

 

 

 

도움이 되었다면, 공감/댓글을 달아주면 깃짱에게 큰 힘이 됩니다!🌟
비밀댓글과 메일을 통해 오는 개인적인 질문은 받지 않고 있습니다. 꼭 공개댓글로 남겨주세요!