반갑습니다.
이번 글에서는 MCP에 대해 알아볼까 합니다.
나온지는 꽤 된 개념이지만, 늦게나마 작성합니다.
사실 나왔을 때부터 글을 작성하려 했었는데,
머리속으로 정리가 제대로 되지 않아서 늦었네요.
아직도 제대로 설명할 수 있을지 모르겠지만, 노력해보겠습니다.
시작 ~!
MCP란?
MCP는 Model Context Protocol의 약자로, LLM이 외부 데이터 소스 혹은 도구 사용을 안전하고 효율적으로 상호작용 할 수 있도록 설계된 개방형 표준 프로토콜입니다.
프로토콜은 뭘까요 ? 많이 들어본 단어인데,, 딱 설명하자니 어렵습니다. (나만)
프로토콜이란, 컴퓨터 혹은 네트워크 장치들이 서로 데이터를 주고받을 때 통신을 원활하게 하기 위한 규약입니다.
이러한 규약은 왜 필요할까요 ?
이는 원활한 통신을 위해 아주 중요한 개념입니다.
예시를 통해 살펴보겠습니다.
- 도로에서는 모든 차가 빨간불에 멈추고 파란불에 출발하도록 약속돼 있습니다. 이것이 제대로 지켜질 때 보행자와 운전자 모두가 안전할 수 있죠.
- A라는 시스템과 B라는 시스템이 데이터를 주고받는데, A는 보낼때 B에게만 알려준 '무야호' 라는 암호를 함께 보냅니다.
이로서 B는 받은 데이터가 A로부터 온 것인지, 아니면 A로 위장한 악성 프로그램이 보낸 데이터인지 판별할 수 있습니다.
이와 같은 상호간의 약속을 프로토콜이라 부를 수 있습니다.
MCP를 좀 더 쉽게 설명하자면, LLM 어플리케이션을 제작할 때 많은 사람들이 안전하고 편리하게 제작할 수 있도록 Anthropic에 의해 제안된 표준(약속)입니다.
MCP의 등장 배경
MCP가 LLM으로 개발할 때는 이렇게 하자 라는 약속이구나 라는 건 알겠습니다.
그럼 이러한 약속들이 왜 생겼을까요?
이는 LLM을 활용한 개발에 여러가지 번거로움이 있었기 때문입니다.
MCP 이전의 LLM 개발 문제들
- 각 AI 어플리케이션마다 데이터를 받아오는 방식이 전부 다름
- 새로운 도구가 생길 때마다 해당 도구를 사용하기 위한 인터페이스 개발이 필요함
- AI 모델이 실시간 데이터에 접근하기 어려움 (도구가 개발될 때마다 이를 사용할 수 있도록 수정되어야 하기 때문)
- 1/2/3번 때문에 개발자의 인력이 많이 소비됨
어 적고보니 4번은 20대 개발자 취업준비생에게는 희소식이 될 수도 있었겠네요.
MCP가 등장해서 저희 일자리를 또 줄였군요. 속상합니다.
아무튼 이러한 문제점들이 존재했습니다.
한줄로 적어보면 "비슷한 작업을 너무 많이 한다" 가 되겠네요.
이를 해결하기 위해 LLM이 외부에서 Context를 받아오는 과정/방식을 하나로 통합하게 되었고, 그 약속들을 모아 MCP라는 개념이 등장하게 되었습니다.
MCP의 구조와 실행과정
클로드에게 구조를 그려달라 했는데,, 잘 그리는군요. 기특합니다.
위에는 다양한 구성 요소들이 있지만, 크게 Host, Client, Server 세가지로 분류합니다.
이 세 가지를 설명하기 위해 유저가 채팅창에 '오늘 서울의 날씨를 알려줘.' 라고 질문을 날린 시나리오를 가정하여 설명해보겠습니다.
Host
유저와 직접적으로 맞닿아 있는 주체(어플리케이션)입니다. 유저의 Input을 받아 Output을 내보냅니다.
Host는 Cluade, GPT가 될 수도 있으며 무언가의 AI App이 될 수도 있습니다.
예시 시나리오에서의 Host는 어떤 AI 서비스의 채팅창이 되겠습니다.
MCP Host는 MCP Client를 내장하고 있습니다. (아래에서 설명)
'오늘 서울의 날씨를 알려줘.' 라고 날리게 되면, LLM은 다음과 같이 출력됩니다.
{
"id": "d273405d6bc44104bbe5de75d81a8d4b",
"choices": [
{
"index": 0,
"message": {
"role": "assistant",
"content": "",
"tool_calls": [
{
"id": "call_U8Eg4kuXWtRnEzoksTSUtSRv",
"type": "function",
"function": {
"name": "get_current_weather",
"arguments": {
"location": "서울",
"unit": "celsius"
}
}
}
]
},
"finish_reason": "tool_calls"
}
],
"created": 1748881093,
"model": "HCX-005",
"usage": {
"completion_tokens": 38,
"prompt_tokens": 108,
"total_tokens": 146
},
"seed": 3727010911
}
모델은 서울의 날씨를 알려주기 위해 Tool call을 내보냅니다.
함수명은 get_current_weather이며, 그 input으로는 location에 "서울", unit에는 celsius를 입력하고 싶다네요.
해당하는 모델의 출력은 이후 Client가 넘겨받습니다.
Client
Host와 Server간의 표준화된 인터페이스를 제공합니다.
Tool server가 도구를 제공한다면, Client는 그 도구들을 어떻게 사용할지를 담당합니다.
Client는 Host의 로컬에서 동작하기에, 외부로부터의 통신으로 공격받을 위험을 줄일 수 있고, 동작들을 사용자가 직접 관리하고 관여할 수 있습니다.
역할이 많은데, 하나씩 설명해보겠습니다.
- 다양한 전송 방식을 처리 (stdio, HTTP/SSE)
- 어떤 도구가 있으며, 그 도구의 명세 (스키마)가 어떻게 되는지를 받아와서 변환
- 도구의 실행/결과 Parsing을 안전하게 관리하고 Error Handling
- 자원 할당을 적절하게 분배
- 사용자의 입력 유도 (사진 폴더에 접근해도 될까요? :예/아니오 같은거)
- 프롬프트 Management
Client는 1~6번 외에도 다양한 업무를 수행할 수 있습니다만, 그 목적은 결국 도구 서버는 도구의 기능만을 제공하도록 하는것입니다.
기존의 AI 어플리케이션은 도구를 사용할 때, 외부 서버에 Post 요청을 날리거나, 내부 서버를 둔 뒤 자신의 폴더 구조를 가져오거나 하는 등 다양한 방식으로 도구를 구현했었습니다.
이러한 도구들은
1. [LLM 출력 Parsing + 도구사용 + 도구결과를 LLM 입력에 맞게 변환]
2. [도구사용 + 도구결과를 LLM 입력에 맞게 변환]
3. [LLM 출력 Parsing + 도구사용]
등 그 규격이 전부 달랐습니다. 이를 오로지 [도구사용] 만 하도록 바꾸는 것이 Client의 역할이 되겠습니다.
Host - Client - Tool Server 구조의 장점은 Client는 구현이 어려운 대신 대부분의 빅테크 기업에서 개발해 제공하기에 일반 개발자는 Tool Server만 개발하면 된다는 것입니다.
이는 많은 사람들이 쉽게 개발할 수 있으며, 그 생태계를 빠르게 발전할 수 있다는 장점이 있습니다. 이 부분이 크게 주목받은 이유 중 하나이기도 하구요.
예시로 돌아와서,, 위 Host에서의 LLM 출력은 Client를 통과해 다음과 같은 형식의 데이터로 변환됩니다.
{
"jsonrpc": "2.0",
"id": "12345", // MCP Client가 생성하는 고유한 요청 ID (예시 값)
"method": "tools/call",
"params": {
"tool_name": "get_current_weather",
"arguments": {
"location": "서울",
"unit": "celsius"
}
}
}Host 에서의 LLM 출력은 데이터의 생김새가 전부 조금씩 다를 수 있지만, Client를 거치게 되면 전부 위와 같은 형식으로 변환됩니다.
jsonrpc는 Json 기반의 원격 프로시저 호출(Remote Procedure Call)을 의미합니다. 원격지에 있는 프로그램의 함수 / 프로시저를 로컬에 있는거처럼 호출하여 사용하는 기술입니다. 간단히 함수 호출 이라고 생각하면 되겠습니다. (간단히밖에 모름)
MCP Server
Tool에 대한 기능을 제공하는 서버입니다.
Tool Server는 리소스를 제공하는 역할을 합니다.
Client처럼 능동적으로 처리하지 않고, 요청이 들어오면 그에 맞는 리소스를 전달할 뿐입니다.
이는 Client가 비정상적인 요청을 걸러내고, 안전한 요청만을 기반으로 호출한다고 가정하기 때문에 가능합니다.
MCP 서버는 크게 세가지 기능을 갖고 있습니다.
- 리소스 제공
- 도구 API 제공
- 프롬프트 제공
통신 방식은
- STDIO : 클라이언트의 하위 프로세스로 실행됩니다. 로컬 환경에서 실행되며, standard i/o를 통해 통신합니다. 주로 로컬 파일 시스템에 접근하는 등 로컬에서만 실행할 수 있는 작업을 처리할 때 사용됩니다.
- HTTP/SSE : 원격 서버로 실행되며, HTTP 혹은 SSE (Server-Sent-Event)를 통해 통신합니다. 인터넷을 통해 접근 가능한 기능들을 제공할 때 사용됩니다.
입니다.
참고) SSE는 실시간 데이터를 단방향으로 전송하는 기술입니다. 서버는 Keep-Alive 기능을 활용하여 연결을 지속시키고, 새로운 데이터가 생길 때마다 text/event-stream 형식에 맞춰 데이터를 클라이언트에게 전송합니다.
간단하게 생각하면, 도구 서버는 어떠한 endpoint로 post 요청이 오면 알맞게 기능을 수행한 뒤 Result를 내보내는 역할이라고 생각하시면 되겠습니다.
Result는 "맑음" 이렇게도 될 수 있고,, 네이버 뉴스를 검색한 뒤 LLM Input으로 넣어 자연어 형태의 Output을 만들어 Return할 수 있습니다. 무궁무진하죠.
[예시]
@mcp.tool()
async def get_weather(location: str, unit: str) -> str:
"""
Args:
location (str): 날씨를 검색할 장소
unit (str): 단위
Returns:
str: 정보를 종합하여 얻어낸 결과
"""
information = naver_weather_search(location, unit)
system_prompt = "다음 검색결과를 바탕으로 날씨가 종합적으로 어떤지 설명하세요."
result = llm_call(prompt = system_prompt, info = information)
return resultClient로부터 온 요청에 맞게 도구를 실행되면 아래와 같은 Response가 Client에게 다시 전송됩니다.
{
"jsonrpc": "2.0",
"id": "12345", // 요청과 동일한 ID
"result": {
// 도구 호출 결과 데이터
"weather": "서울의 날씨는 어쭈구저쭈구 맑니 흐리니 어쭈구저쭈구",
"temperature": 25,
"unit": "celsius"
}
}이렇게 전송된 데이터는 Client에서 Error가 있는지 검사가 진행됩니다.
뭐 json 파싱이 되는지 검사하고,, ID는 요청 보낸것과 응답이 같은지 살펴보고,, 필드에 error가 있는지도 검사 하고,, 호출 기록 로깅도 하고,, 등등..
여러가지 처리된 뒤, Host로 다시 넘어가게 됩니다. Host는 도구의 실행 결과를 받게 되고, 이를 바탕으로 답변을 생성합니다.
"서울의 날씨는 어쭈구저쭈구 입니다."
이 답변이 사용자에게 전달되는 것이지요.
여기까지가 MCP를 활용한 LLM 어플리케이션의 동작 과정입니다.
도구 서버는 이외에도 프롬프트를 제공해준다던가, 사용자 로컬 파일시스템의 구조, 코드 등을 제공해준다던가 하는 등 사용자가 원하는 대로 구현하고 그 기능을 제공할 수 있습니다.
이러한 도구들은 전부 같은 규격 내에서 동작하기에 오픈된 커뮤니티에 공유될 수 있고 사람들은 이를 복붙해 사용할 수 있죠.
AI 개발이 보다 쉬워지고 있는 이유 중 하나가 될 수 있겠네요.
'
'
'
MCP에 대해 알아봤습니다.
제대로 설명이 전달됐는지 잘 모르겠네요.
틀린 부분이 있다면 언제든 댓글 부탁드립니다.
저도 모르는게 많으니,, 같이 배워가면 좋을 것 같습니다.
감사합니다 !
좋은 정보 감사합니다.