Function Calling(이전 프로토콜)
-
기존에는 LLM프롬프트 엔지니어링으로 구조화된 json 아웃풋 유도
-> 원하는 형식의 아웃풋 얻기 힘듦
-> 사용자의 자연어 요청을 이해하고 외부 시스템의 특정 함수를 호출하여 작업 실행
-> 모델 출력의 안정성 및 신뢰성 향상 -
2023/7 OpenAi가 function calling 제공
-
작동 방식
- 함수 정의 및 메시지 전달
- 함수 호출
- 외부 함수 실행
- 실행 결과 반환: 앞의 모든 과정을 포함해서 전달(컨텍스트에 업데이트)
- 최종 응답 생성
-
한계점
- 상태유지 어려움 : 단일 요청 - 응답(REST API 처럼 각 호출이 독립적)
- 복잡한 작업 처리: 함수 하나씩 콜링하다보니, 여러단계 워크 플로우나 병렬 처리나 다양한 데이터 사용이 어려움
- 플렛폼 단편화: AI모델/벤더 마다 다른 함수 호출 방식(모델 n개, Tool m개의 경우 n*m개의 프록시 필요)
-> 유지보수 어려움, 구현 시간 오래걸림
-
개선 방향
- 보편적인 모든 지식 습득 X -> 주어진 상황의 맥락을 이해하고 툴을 활용
-> 컨텍스트의 중요성 극대화
- 보편적인 모든 지식 습득 X -> 주어진 상황의 맥락을 이해하고 툴을 활용
MCP 등장 배경
- 24/11 엔트로픽에서 제공
- Function Calling vs. MCP
Function Calling: 외부 데이터와 단편적 상호작용("How"에 대한 질문)
MCP : 다양한 도구 및 context를 일관된 방식으로 활용하는 규약(외부와 지능적 상호작용)
-> What, When, Why 처럼 전체적인 맥락을 질문
MCP 정의
- AI 모델과 외부 자원 간 맥락 정보를 일관된 형태로 주고 받을 수 있도록 정의한 표준 규약
MCP의 해결책: 호스트 - 서버 - 클라이언트 구조
[ 호스트 - 서버 - 클라이언트의 모식도 ]
- 호스트 - 서버 - 클라이언트 구조를 도입한 개방향 표준 프로토콜
- AI 애플리케이션(호스트: Claude, IDEs, Tools...)가 여러 MCP 클라이언트 인스턴스를 생성 및 관리
- 각 클라이언트는 개별 MCP서버와 1:1로 연결해서 필요한 맥락과 도구를 동적으로 조율
- AI 애플리케이션 수정 없이 새로운 도구(MCP 서버) 추가 가능
- 각 MCP 서버는 언어, 기능 등을 각각 독립적으로 개발 및 실행 가능
클라이언트 - 서버 아키텍처의 자세한 설명
[ 클라이언트 - 서버의 자세한 구조 ]
MCP 연결의 세 단계 생명 주기
1. 초기화(Initialization)
- 클라이언트가 Initialize 요청 전송
- 서버가 능력과 버전 정보(날짜 기준)로 응답
- 클라이언트가 Initialized 알림 전송
- 서로 생존 확인
2. 운영(Operation)
- 사용자가 호스트에 질문을 하다가 적절한 떄 MCP 서버 호출
- 정상적인 프로토콜 통신 확인
- 협상된 기능만 사용
- 클라이언트는 MCP 서버로부터 응답을 컨텍스트로 받음
3. 종료(Shutdown)
- 전송 매커니즘을 통한 연결 종료
- Transport Layer(통신부)만 on/off 가능
MCP의 표준 전송 메커니즘
-
Streamable HTTP(주로 원격)
HTTP GET/POST 요청 사용
Server-Sent Events(SSE)로 스트리밍 지원
세션 관리 기능 포함 -
통신 프로토콜(JSON-RPC 2.0 기반)
메시지 형태: 요청(Requset), 응답(Response), 알림(Notification)
양방향 통신 기본 UTF-8 인코딩 -
전송 계측
STDIO(Standard I/O) 표준 입출력을 이용한 전송 방식
-> 클라이언트 서버를 자식 프로세스로 실행, 간단하고 빠른 로컬 연결에 적합
Streamable HTTP : HTTP POST와 서버 발신 이벤트(SSE)를 결합한 원격 전송 방식
-> 양방향 통신 스트리밍 지원(실시간 진행 상황 업데이트 등) -
인증
선택사항 but 원격 서버 구현시와 streamable HTTP 구성시에 권장
OAuth 2.1 표준을 활용한 인증 흐름 구현 가능
MCP Host, Client, Server의 역할
MCP Host
- LLM 통합과 샘플링 조정의 오케스트레이터 및 보안 및 사용자 승인 관리자
- LLM 오케스트레이션 호스트(Claude, IDEs, Tools...)
- MCP 클라이언트 생성, 수명 및 권한 관리, 전체 보안 정책 및 사용자 컨트롤 실행
- 여러 서버 정보 종합하여 LLM에 전달
MCP Client
- MCP 프로토콜 어뎁터 및 메시지 라우터, 각 MCP 서버와 보안 경계
- 호스트 내에서 인스턴스 실행(개별 MCP 서버와 1:1로 통신)
- JSON-RPC 세션 유지 및 기능 협의 수행(Capability Negotiation)
- 각 서버와 통신 채널 격리 -> 안정성 확보
MCP Server
- 특화된 Context 및 도구 기능 제공
- 파일 시스템, DB, API 등 특정 데이터 소스나 도구에대한 접근 제공
- 기능을 표준 MCP 프리미티브로 노출(리소스, 프롬프트, 툴)
- 독립적으로 운영 가능하며, 자신이 다루는 Context에 대한 책임만 갖음
MCP의 핵심 제공 가치
-
맥락 단편화 해결(Context Fragmentation)
다양한 AI모델의 각기 다른 맥락 처리 방식 -> MCP 프로토콜을 통한 일관된 관리 방식 제공
-
M x N 통합 문제 해소
-> M x N 맞춤형 통합 -> 표준 인터페이스 제공으로 M + N 형태의 간단한 문제로 변환
-
동적 맥락 접근(Dynamic Contex Access)
LLM 외부 시스템에 동적으로 접근하여 Context를 주입받음으로써 RAG와 같이 환각 현상 줄임
Agentic 플로우 가능 -
맥락 길이 문제 완화(Context Windows)
외부 시스템과의 효율적인 정보 교환을 통해서 LLM Context Windows 길이 문제를 완화
요청 사항의 결과를 MCP서버에서 압축시킨 Context로 제공하여 길이 문제 완화 -
상호운용성 확보(Interoperability)
서로 다른 공급 업체의 도구들이 통일된 방식으로 모델과 맥락을 교환할 수 있는 표준화된 방법 제공
MCP 한계점
명시적인 도구 발동 조건 작성 필요
애매한 경우 모델이 MCP 서버 활용 가능성 낮아짐다중 도구 연계 및 활용 한계
도구 활용 개수 제한 등, 1 Model - N MCP의 현실적인 한계 발생
처리가능한 컨텍스트 길이, 한 번에 활용 가능한 도구 개수, 도구 조합 복잡성과 Description 부족 등보안 취약
아직은 공식 MCP 서버만 사용 추천
