MCP(Model Context Protocol) 란?

증권사 AI 리서치 챗봇 PoC를 수행하면서 실무적으로 MCP를 적용해볼 기회가 있었고, 당시 미처 깊게 공부하지 못했던 부분을 다시 정리해보고자 한다.
아직 생태계가 빨리 발전하고 있는 기술이지만, LLM 기반 애플리케이션을 구현하는 입장에서 반드시 이해해야 하는 개념이라고 느꼈다.

---

 

1. MCP(Model Context Protocol)란 무엇인가?

먼저 MCP가 등장한 이유부터 살펴보는 것이 이해에 도움이 된다.

기존 LLM 기반 애플리케이션에서는 모델이 외부 도구나 데이터 소스와 상호작용하는 방식이 표준화되어 있지 않았다.

그 결과 개발자는 다음과 같은 문제를 반복적으로 겪었다.

• 새로운 툴을 추가할 때마다 Function Calling 스펙을 직접 다시 정의해야 하고,
• 모델(GPT/Claude/오픈소스)마다 호출 규격이 달라 호환성이 떨어지며,
• 파일 접근, 네트워크 요청 등 보안/권한 관리도 직접 구현해야 했다.

이 문제를 해결하기 위해 등장한 것이 Model Context Protocol(MCP)이다.

 

MCP는 LLM이 외부 도구·데이터와 안전하고 일관되게 연결될 수 있도록 설계된 개방형(Open Spec) 표준 프로토콜이다.
OpenAI가 적극적으로 도입하고 있지만 특정 회사 전용 기술이 아니며, 현재 Claude, VS Code, Cursor 등 다양한 생태계에서 빠르게 채택되고 있다.

⸻

2. MCP가 해결하는 문제

✔ 도구 연결 방식의 표준화

모델이 MCP를 통해 외부 도구를 호출할 때 항상 동일한 JSON 기반 인터페이스를 사용한다.
덕분에 툴을 새로 추가하더라도 Function Calling 스펙을 다시 정의할 필요가 없다.

✔ 모델 교체 비용 감소

GPT → Claude → 오픈소스 모델로 바꿔도 MCP 툴을 그대로 사용 가능하다.
멀티모델·멀티에이전트 구조에서 특히 큰 장점이다.

✔ 보안과 권한 제어 내장

모델이 파일 읽기, 폴더 접근, 네트워크 요청 등을 시도할 때는
consent flow(사용자 승인) 를 반드시 거치며 sandbox 환경에서 안전하게 실행된다.

✔ 도구 기반 에이전트 개발 표준

최근 프레임워크(LangChain, LangGraph, Cursor Agent 등)들이 MCP를 적극 도입해
툴 기반 에이전트 개발이 훨씬 단순해지고 있다.

⸻

3. MCP의 핵심 구성 요소

MCP는 크게 tool, resource, event 세 가지 개념으로 구성된다.

(1) Tool

LLM이 호출할 수 있는 기능 단위.
예: index_retriever, news_fetch, generate_html_report

Tool은 모델이 “무엇을 실행할 수 있는지”를 정의한다.

(2) Resource

LLM이 읽을 수 있는 외부 데이터 소스.

resource는 단순 파일 접근만 의미하는 것이 아니라,
파일 시스템, DB 쿼리, HTTP 요청 등 데이터 접근 계층 전체를 추상화한 개념이다.

예시 리소스:

• /workspace/files — 로컬 파일 시스템
• /http/request — HTTP 호출 핸들러
• /db/query — SQL 조회 엔드포인트

(3) Event

툴 실행/리소스 사용에 따라 발생하는 상태 변화나 알림.
여러 에이전트가 협업할 때 유용하게 사용됨.

⸻

4. MCP의 동작 방식

1) MCP Server

FastAPI 또는 Node에서 MCP 서버를 띄우고 툴을 정의한다.

@mcp.tool(
    name="index_retriever",
    description="주식 지수(KOSPI, KOSDAQ, DOW 등) 조회"
)
async def index_retriever(index: str, start_date: str, end_date: str):
    ...
    return {
        "status": 200,
        "search_result": search_result
    }

2) MCP Client

LLM이 MCP 클라이언트를 통해 서버의 툴을 호출한다.

• 모델은 표준화된 JSON schema에 따라 툴 호출
• 서버는 동일한 규격으로 응답 반환
  → 모델이 바뀌어도 서버는 바뀔 필요 없음

3) Consent Flow

모델이 민감한 작업(파일 읽기, 네트워크 호출 등)을 시도하면
사용자 승인 없이는 접근 불가.

MCP의 보안성이 높은 이유는 모델이 서버 자원에 직접 접근하는 구조가 아니라,
툴을 통해서만 제한된 정보만 전달받는 sandbox 형태이기 때문이다.

⸻

5. PoC에서는 이렇게 사용했다

AI 리서치 챗봇 PoC에서는 FastAPI 기반으로 MCP 서버를 구축했고,
아래와 같은 MCP 툴들을 정의해 시스템을 설계했다.

• index_retriever — KOSPI/KOSDAQ/해외지수 조회
• report_summarizer — 리서치 리포트 요약
• web_retriever — tavliy api를 활용한 웹 검색 및 검색 결과 요약

전체 에이전트 흐름은 아래와 같다:

1. 사용자 질의 입력
2. LLM이 Intent 분석
3. MCP 서버의 툴 목록 조회
4. 적절한 tool 선택
5. 툴 실행 → 데이터 반환
6. LLM 내부 reasoning
7. 최종 답변 구성

이 구조를 적용하면서 툴 추가/수정이 훨씬 쉬워졌고,
모델 교체에도 영향을 받지 않는 확장 가능성을 확인할 수 있었다. 

 

⸻

6. 마무리 — MCP를 도입하며 느낀 점

실무에서 MCP를 직접 구현해보니 다음과 같은 결론이 나온다.

• Function Calling의 한계를 보완하는 상위 호환 프로토콜에 가깝다.
• 모델 교체 비용이 줄어든다는 점은 기업 환경에서 매우 큰 장점이다.
• 에이전트 기반 시스템을 구축할 때 MCP는 사실상 필수 도구로 보인다.
• 보안, 권한 관리, 도구 확장의 측면에서 기존 방식보다 훨씬 안정적이다.

PoC 이후 MCP의 필요성과 장점을 더 명확히 이해하게 되었고,
앞으로 LLM 기반 서비스를 설계할 때 반드시 고려해야 하는 기술이라는 확신이 들었다.