LLM에 대해 거의 무지한 사람으로써 MCP를 최대한 이해하기 위해 써보는 글이다.
LLM에 대한 이해도가 없기 때문에 이해하기 위해 필요한 정보들을 그때그때 최대한 채워서 넣었다.
https://velog.io/@k-svelte-master/what-is-mcp
MCP의 모든 것을 알아봅시다.
개발자인데 mcp 원리 계속 모른상태로 있을건가요?
velog.io
위 글의 흐름을 기반으로 풀어보았다.
MPC가 뭐길래?!
Anthropic 주도로 개발된 24년 11월 26일 발표된 모델이다.
"모델 컨텍스트 프로토콜"
MCP는 애플리케이션이 LLM에 컨텍스트를 제공하는 방법을 표준화하는 개방형 프로토콜이다.
*애플리케이션(application) : 스마트폰, 태블릿, PC와 같은 기기에 설치하여 사용하는 응용 소프트웨어
*프로토콜(Protocol) : 컴퓨터나 네트워크 장치들이 서로 통신할 때 따르는 규칙의 집합
여기서 LLM에서의 Context Window란 무엇인가?
LLM은 인공지능의 능력을 크게 향상하여 인간과 유사한 텍스트를 이해하고 생성할 수 있게 되었다.
이러한 모델은 '컨텍스트 윈도우'에 의해 유용성 정도가 정해진다고 할 수 있다.
컨텍스트 윈도우란 모델이 텍스트를 생성하거나 이해할 때 입력으로 받을 수 있는 양을 의미한다.
입력된 토큰의 양은 후속 토큰을 예측하는 데 사용할 수 있는 정보의 양에 영향을 준다.
따라서 컨텍스트 윈도우의 크기를 늘리는 것은 기존 트랜스포머 모델에 있어 항상 풀어야하는 과제였다.
윈도우 크기는 선형적으로 증가하지만 이에 따른 모델의 매개변수 수는 2차적으로 증가한다.
다시 말하면 이제 MCP로 LLM에 전달할 외부 API를 규격화할 수 있다라는 것을 의미한다.
여기서 LLM과 외부 API가 또 이해가 안간다.
먼저 API에 대해 이해하고 가보자.
스마트폰으로 카카오톡에 로그인하는 상황으로 예를 들어보겠다.
스마트폰이 보낸 로그인 요청은 카카오 본사의 서버가 받은 후 그에 알맞은 응답을 다시 스마트폰에 돌려주게 된다.
이를 클라이언트-서버 구조라고 한다. 클라이언트는 로그인, 친구 추가, 메세지 발송 등 수많은 요청을 서버에 보내야하는데 때마다 이 요청들을 일일이 대응하는 것은 비효율적이다.
API(Application Programming Interface)는 서버와 클라이언트가 데이터를 주고받을 수 있도록 도움을 주는 매개체라고 정의할 수 있다. 이때 API를 사용하기 위해서는 서보와 클라이언트 간의 몇 가지 약속들을 지정해야한다. 예를 들어 데이터 형식, 글자수 제한, 데이터 전달 방식 등 말이다. 이는 API 문서를 통해 확인할 수 있다.
LLM 자체가 모든 정보를 가지고 있지 않기도 하며 또 직접 계산을 수행하지 못하는 등 외부 도구가 필요할 때가 있다.
여기서 LLM이 외부 도구(함수, API, 데이터베이스)를 호출하여 특정한 작업을 수행하는 기능이 Tool Calling이다.
기본적으로 LLM은 훈련된 데이터에 기반해 응답을 생성한다.
-> 훈련 이후의 최신 데이터 반영이 힘들다.
-> 복잡한 계산이나 데이터 검색 등을 직접 수행할 수 없다.
-> API 호출, 데이터베이스 조회 등의 외부 기능이 필요할 수 있다.
Tool Caliing 동작 방식
1. 사용자 입력 처리 -> 사용자의 질의에 따라 tool calling이 필요한지 판단
2. 적절한 도구 선택 -> 사전에 정의된 도구 목록에서 적절한 API, 함수나 DB 조회 기능을 선택
3. 도구 호출 및 결과 반환 -> LLM이 외부 API/함수 호출로 해당 도구가 실행되어 결과 반환
4. LLM이 응답 생성
즉, MCP를 사용하면 아주 다양한 외부 도구인 API를 AI 모델과 연결할 수 있는 표준 방법을 제공한다는 것이다.
마치 현재 USB-C 타입으로 대부분의 외부 기기들을 연결할 수 있는 것처럼 말이다.
현재 Cursor과 같은 코딩 툴에서도 MCP를 통해 로컬 파일 시스템에 접근해 코드 분석, 자동 코드 생성 기능을 선보이고 있다.
Claude 데스크탑앱도 MCP 연동을 통해 외부 API를 활용하도록 지원한다.
Microsoft 또한 MCP 서버 코드를 직접 오픈하여 웹 테스트 자동화를 지원한다.
이처럼 점점 더 많은 도구들이 이 프로토콜을 채택하며 대세가 되어가고 있다.
기존에도 API 연동은 빈번했다, MCP는 뭐가 다르길래?!
기존에도 LLM과 외부 도구를 연결하는 방법은 존재했다.
하지만 각 서비스 마다의 API 구조가 다르며 인증 방식이 달라 통합하는 과정이 복잡했다.
이와 달리 MCP는 규격화되었다는 것이다.
누구나 동일한 방식으로 API를 구현하고 연결할 수 있게 된 것이다.
Cursor, FIgma로 MCP의 유용함을 느껴보자
Cursor에서 MCP를 통해 '내 프로젝트의 모든 python 파일을 분석해 중복 코드를 찾아줘'라고 해보자.
MCP 서버를 통해 AI가 내 로컬 파일 시스템에 안전하게 접근할 수 있다.
이를 통해 AI는 단순하게 대화 상자에 붙여넣은 코드 조각이 아닌 전체 프로젝트 구조를 이해하고 맥락에 맞는 코드를 생성할 수 있게 된 것이다.
그렇다면 실제로 어떻게 MCP를 사용할 수 있는 건가?
우리는 연결 케이블만 가지고 있다. MCP 서버만 구현한다고 해서 LLM이 모든 기능을 자동으로 수행할 수 있는 것은 아니다.
MCP는 왜 중요하며 앞으로 AI의 미래는 어떻게 변할지 살펴보자.
MCP는 Function Call의 사촌이다.
Function Call은 무엇인가?
2023년 6월 발표된 Function Call은 LLM을 외부 툴에 안정적인 연결하여 효과적으로 툴을 사용하거나 외부 API와의 상호작용을 가능하게 하는 것이다.
GPT-4와 같은 LLM은 함수를 호출해야할 때를 감지한 후 함수를 호출하기 위한 인수가 포함된 json을 출력하도록 되어있다.
예를 들어 GPT에게 '서울 날씨 알려줘'라고 했을 때, GPT는 get_weather(location='서울')이라는 함수를 호출해야겠다.라고 판단을 하게 되고 이를 통해 Function Calling 기능이 활성화된 GPT가 JSON 형식의 인자를 출력한다. 이 json을 바탕으로 API 요청을 호출하여 결과를 받아 응답하게 된다.
MCP 서버는 어떻게 동작할 수 있는가?
MCP 서버는 /messages라는 하나의 API 주소만 만들고 그 안에서 method 값에 따라 다르게 동작하면 된다.
- MCP Client : llm이 mcp로 외부 도구를 사용하고 싶어할 때 해당 요청을 json 형식으로 내보낸다.
- MCP Server : client가 json을 서버로 보내고 내부에서 method 값을 보고 반응한다
-> method 필드만 바꾸면서 다양한 기능을 하나의 서버로 처리할 수 있다
그런데 이때 현실에 이미 존재하는 API는 MCP의 포멧을 모른다.
예를 들어 기존의 날씨 API는 GET / weather?city=seoul이라는 명령으로 받는다고 해보자
그런데 MCP 클라이언트는 {"method : "get_weather",
"params": {"location":"seoul"}}
라는 식으로 명령을 보내는 것이다.
두 방식의 형식이 일치하지 않아 mcp client가 보내는 것을 기존 API들이 알아듣지 못한다는 문제를 해결해야한다.
이때 우리는 Transport 인터페이스를 통해 해결할 수 있다.
MCP 포맷을 기존의 API 호출 포맷으로 변환해주며 기존 API의 응답 또한 다시 MCP 포맷으로 감싸 변환을 해준다.
이를 통해 MCP 서버가 직접 외부 API를 호출하지 않고 transport가 그거만 따로 처리해주는 것이다.
즉, MCP는 기존에 존재하는 API, 로컬 서비스나 새로 구현한 서버 등 어떤 도구든 transport layer만 잘 구현해놓으면 MCP Client에서 정해진 method로 LLM function call에 필요한 내용들을 호출할 수 있다.
이제까지 여러 번 언급했듯이 MCP 핵심 가치는 규격화인 것이다.
각 서비스 마다 다른 방식의 함수 정의를 작성해야하는 것이 아니라 model context protocol만 따르면 되는 것이다.
기존의 Function Call을 사용하려면 모든 소스들마다의 고유한 함수를 정의해야한다.
그렇다면 이 MCP 서버를 어떻게 우리가 사용할 수 있다는 거지?
지금까지 우리는 usb-c를 만든 것 뿐이다.
하지만 이것만으로 우리는 아무것도 할 수 없다는 것을 알 것이다.
다양한 도구를 쓰기 위한 표준화된 통로를 다 만들었다면 이를 LLM과 연결하여 실제로 언제 어떤 도구를 쓸지 결정해주는 호스트 앱이 필요하다!
호스트 앱은 LLM이 사용자와의 대화에서 mcp 도구 호출이 필요한지 확인해준다. 또 도구가 필요하다면 언제 호출할지 판단해준다.
또한 LLM이 json을 출력하면 그것을 해석하여 어떤 도구를 쓸지 정하며 MCP 호출과 결과를 다시 LLM에게 전달해주는 역할을 한다고 이해하면 된다.
MCP는 도구 연결용 인터페이스로, LLM이 없으며 실행할 로직도, 판단 기능도 없기 때문에 이러한 호스트 앱이 필수이다.
ex) Claude Desktop, Cursor
정리해보자면!
| 구성요소 | 역할 | 관계 |
| LLM | 사용자와 대화 / 도구 필요 여부 판단 / json 생성 | MCP Client |
| 호스트 앱 | LLM 응답 분석 / MCP 호출 시기 결정 / 응답 전달 | MCP와 LLM 사이의 조율자 |
| MCP 서버 | 표준화된 도구 목록 제공, 도구 실행 포멧 제공 | LLM의 요청을 받아주는 서버 |
| Transport 인터페이스 | MCP 형식을 기존 API 형식으로 번역 | MCP 서버 내부에 있거나 붙음 |
따라서 MCP를 효율적으로 사용하기위해서는 호스트앱이 잘 구성되어있어야한다.
MCP 서버가 도구를 제공하며 LLM이 이를 호출한다고 할 때 LLM을 잘 사용하기 위해서는 효과적으로 LLM 워크플로우 설계가 필수인 것이다. mcp를 통해 1000개의 도구를 사용할 수 있다고 할 때 이를 잘 처리할 수 있는 방법을 잘 설계해야하는 것이다.
이러한 LLM 워크플로우 방식은 아주 다양한 방법론이 있다. 이 부분은 나중에 다시 공부해보려고 한다.
MCP의 장점과 한계점
- 통합된 도구 연결 방식 : 다양한 외부 툴인 api, db를 하나의 표준 형식으로 연결 가능
- 재사용 가능 : 한 번 만든 도구를 여러 앱에서 공유 가능
- 모듈화 구조 : 도구 추가, 교체, 확장이 쉽다 (mcp 서버와 transport만 손보면 됨)
- 보안 설계 가능 : 클라이언트가 직접 외부 api를 호출하는 것이 아니기 때문에 프록시/필터/감시 가능
- 모델 독립적 : open ai, claude, ollama 등 어떤 llm이든 연결 가능
- 세션&흐름 유지 가능 : 단순 요청-응답을 넘어선 에이전트 식 복합 작업 가능
한계점
- 초기 개발 난이도 : 호스트앱, llm, mcp server, tranport까지 직접 구현해야해 초기 진입 장벽 존재
- llm의 reasoning 퀄리티에 의존 : 도구 호출 판단이 결국은 llm의 판단 정확도에 달려있음
- 에러 핸들링 불편 : 도구 실패, 응답 오류 등은 mcp 포맷으로 감까 다시 llm에 전달해야해 복잡도 증가
- transport 구현 부담 : 기존 api마다 transport 어댑터를 따로 구현해야함 - 반자동화 필요
아직 초기 생태계임은 분명하다. 하지만 조만간 확산될 것으로 보여 어느 정도 이 부분을 인지하고 있다면 재미있을 것이다.
앞으로 MCP는 랭체인 등 다양한 agent 프레임워크들이 mcp 연동을 적극적으로 공식 지원할 것이다.
이르르 통해 llm이 자동으로 mcp 도구 호출 흐름까지 포함해 멀티스텝 작업이 가능할 것이라고 한다.
또한 transport 자동 생성 도구가 등장하지 않을까..
mcp기반의 tool store 생태계가 생길 것이다. 그렇게 되면 mcp 규격 도구 모음 처럼 여러 서비스들이 공개되고 재사용이 될 것
보안/프라이버시가 뛰어나기 때문에 여러 기업이 이미 많은 관심을 보이고 있다. 의료, 금융, 법률 등 데이터의 외부 노출이 꺼려지는 분야에서의 mcp 도입은 증가할 것이다.
+ GPT에게 그렇다면 무엇을 중점적으로 봐야하는가라고 물었더니
라는 답변을 주었다.
'DL 기본개념' 카테고리의 다른 글
| Transformer outline (0) | 2025.03.27 |
|---|---|
| Deep Learning : ANN, DNN, RNN, CNN (SLP, MLP) (1) | 2024.03.07 |
| Bayes' theorem & VAE (0) | 2024.03.01 |
| Wavenet 논문 전체 내용 (0) | 2023.11.01 |
| Object Detection 개념 정리 및 학습일지 (0) | 2023.10.27 |
