MCP 조사 - 갈피노트

MCP.

MCP(Model Context Protocol)이라는 이 녀석, 점점 발전해나가서 어느새 세상에 3천여개가 넘는 MCP가 존재하게 되었다.
(다수의 중복은 있다)

MCP란 무엇인가

MCP는 Model Context Protocol의 약자로, 인공지능 모델이 외부의 데이터 소스나 도구와 통신할 때 사용하는 표준화된 규격입니다. 앤스로픽(Anthropic)에서 처음 제안하고 오픈 소스로 공개했습니다.

기존에는 AI 모델을 특정 데이터베이스나 로컬 파일, 외부 API와 연결하기 위해 매번 별도의 통합 코드를 작성해야 했습니다. MCP는 이 연결 과정을 표준화하여, 한 번 구현된 MCP 서버가 있다면 이를 지원하는 어떤 AI 모델이나 클라이언트에서도 즉시 데이터를 불러오거나 도구를 실행할 수 있게 합니다.

MCP의 지향성

MCP의 핵심 목표는 파편화된 AI 생태계의 통합입니다. 현재 인공지능 기술은 모델 자체의 성능만큼이나 모델이 실제 데이터에 어떻게 접근하느냐가 중요해졌습니다. MCP가 지향하는 바는 다음과 같습니다.

교체 가능성 확보 특정 플랫폼이나 특정 모델에 종속되지 않는 연결 방식을 제공하여, 클라이언트나 모델을 바꾸더라도 데이터 연결 설정을 그대로 유지할 수 있게 합니다.
개발 효율성 증대 데이터 소스 제공자는 MCP 서버 하나만 구축하면 됩니다. 이를 통해 다양한 AI 애플리케이션에 자사의 데이터를 제공할 수 있습니다.
보안 및 제어 모델이 데이터에 직접 접근하는 것이 아니라, 중간에 위치한 MCP 서버가 허용된 데이터와 도구만 노출하도록 설계되었습니다. 이를 통해 데이터 노출 범위를 정교하게 제어합니다.

MCP의 현재와 미래

현재 MCP는 초기 확산 단계를 지나 다양한 개발 도구에 이식되고 있습니다.

현재 상황 클로드 데스크톱(Claude Desktop)이나 커서(Cursor) 같은 코드 에디터들이 MCP 클라이언트 역할을 수행하고 있습니다. 개발자들은 구글 드라이브, 슬랙, 깃허브, 로컬 데이터베이스 등을 연결하는 MCP 서버를 만들어 활용 중입니다. 오픈 소스 커뮤니티를 중심으로 다양한 사전 정의 서버들이 공유되고 있습니다.
미래 전망 앞으로는 더 많은 서비스 제공업체가 자사 API의 공식 접근 방식으로 MCP를 채택할 가능성이 높습니다. 또한 개별 모델뿐만 아니라 여러 모델이 협업하는 에이전트 환경에서 공용 데이터 인터페이스로 자리 잡을 것으로 보입니다. 이는 AI가 단순히 텍스트를 생성하는 수준을 넘어 실제 소프트웨어 환경을 조작하는 기능을 수행하는 데 필수적인 인프라가 될 것입니다.

그 외 MCP에 대해서 알아야 할 것

실제 도입이나 이해를 위해 필요한 기술적 세부 사항입니다.

아키텍처 구성 MCP는 크게 세 가지 구성 요소로 나뉩니다. 데이터를 보유하고 도구를 실행하는 MCP 서버, 사용자와 상호작용하며 모델을 실행하는 MCP 클라이언트, 그리고 이들을 연결하는 프로토콜입니다.
전송 방식 주로 표준 입출력(stdio)이나 서버 전송 이벤트(SSE)를 전송 계층으로 사용합니다. 이는 로컬 환경과 원격 환경 모두에서 유연하게 작동할 수 있음을 의미합니다.
기능의 범위 단순히 텍스트 데이터를 읽어오는 것에 그치지 않습니다. 리소스(Resource) 제공, 프롬프트 템플릿(Prompt) 공유, 그리고 실제 동작을 수행하는 도구(Tool) 실행 기능을 모두 포함합니다.
생태계의 개방성 앤스로픽이 주도하고 있지만 오픈 표준을 지향하므로 다른 모델 제조사나 플랫폼에서도 이를 채택할 수 있는 구조입니다. 이는 특정 기업의 독점적 기술이 아닌 업계 전반의 인프라로 기능할 수 있는 잠재력을 가집니다.

나는 여기서 MCP서버와 MCP클라이언트에 집중했다. 이런건 언제 또 만들어졌대?

AI세상은 인터넷 세상보다 발전 속도가 너무 빠른 것 같다.

MCP 아키텍처에서 Client와 Server는 JSON-RPC 메시지 처리의 주체와 LLM 통합 여부로 구분된다.

1. 기술적 정의

MCP Client (The Host): MCP 프로토콜의 Initiator(연결 시작자)이자 Aggregator(통합자)다. 주로 Claude Desktop, Cursor, Zed 같은 IDE나 애플리케이션 자체가 이에 해당한다. 가장 중요한 특징은 LLM(Large Language Model)과의 인터페이스를 직접 소유하고 있다는 점이다.
MCP Server: MCP 프로토콜의 Endpoint(종단점)다. 데이터 소스나 특정 로직을 MCP 규격(JSON-RPC 2.0)에 맞춰 노출하는 경량화된 프로세스다. 이 녀석은 LLM이 누구인지, 현재 대화의 맥락이 무엇인지 전혀 모르는 Stateless(무상태) 서비스다.

2. 아키텍처 상의 역할 구분

이 둘의 차이는 데이터 흐름(Data Flow)을 보면 명확하다.

A. 연결 및 초기화 (Connection Lifecycle)

Client: config.json 등을 참조하여 Server 프로세스를 생성(Spawn)하거나 원격으로 연결하고, initialize 핸드셰이크를 요청한다.
Server: Client의 요청을 대기하고, 자신이 가진 기능(Tools, Resources, Prompts)의 목록을 Client에게 반환한다.

B. 프롬프트 엔지니어링 및 실행 (Execution Loop)

Client의 역할 (핵심):
1. Server들로부터 수집한 Tool 정의(Schema)를 LLM의 System Prompt에 주입한다.
2. 사용자의 입력을 LLM에 전송한다.
3. LLM이 "특정 도구를 사용하라"는 응답(Function Call)을 내뱉으면, 이를 파싱한다.
4. 해당 도구를 보유한 Server에게 JSON-RPC 요청(tools/call)을 전송한다.
Server의 역할:
1. Client로부터 들어온 JSON-RPC 요청을 받아 내부 로직(DB 쿼리, API 호출, 파일 I/O)을 실행한다.
2. 실행 결과(Text, Image 등)를 JSON 형태로 Client에게 반환한다.

3. 요약

MCP Server: "내부 로직을 표준 프로토콜로 래핑(Wrapping)한 데몬". 로컬 자원에 접근 권한을 가진다.
MCP Client: "여러 Server를 관리하고 LLM과 통신하는 오케스트레이터". 어떤 Server의 어떤 Tool을 호출할지 결정하는 권한(Decision Making)을 LLM에게 위임하고, 그 결과를 중개한다.

드라이하게 시켜본 요약.
우리가 사용하는 클로드, 제미니가 어느새 MCP client로 불리게 되었다.

기술적으로 딱 잘라 말하면 클라이언트는 호스트 애플리케이션(Host Application)을 말해. Claude Desktop 앱, Cursor, Zed 같은 에디터들이 바로 클라이언트야.

서버가 도구함이라면, 클라이언트는 그 도구함을 열어서 뭘 꺼낼지 결정하는 사람(LLM)이야.

서버는 가만히 있어. "나 이거 할 줄 알아"라고 목록만 들고 서 있는 거지. 이때 클라이언트가 등장해서 이런 일들을 처리해.

연결 관리 클라이언트가 서버들을 찾아서 연결해. "너는 구글 검색 서버구나? 너는 파일 시스템 서버구나?" 하고 인식하는 게 클라이언트야.
권한 통제 "이 서버가 내 컴퓨터 파일을 읽으려고 하네? 허용할까?"라고 오빠한테 물어보는 창을 띄우는 녀석이 바로 클라이언트야.
두뇌(LLM)와의 소통 이게 핵심이야. 오빠가 질문을 던지면, 클라이언트 안에 있는 LLM이 판단을 해. "이건 내 지식으로 안 되네. 아까 연결해 둔 서버한테 시켜야겠다." 라고 결정하고 명령을 내리는 주체가 바로 클라이언트야.

정리하자면, MCP 서버는 기능만 제공하는 수동적인 부품이고, MCP 클라이언트는 그 부품을 언제 어떻게 쓸지 결정하고 명령하는 사령관이야.

오빠가 Claude 앱을 켜서 "내 컴퓨터 바탕화면에 있는 파일 좀 읽어줘"라고 썼지? 그때 그 Claude 앱이 클라이언트고, 실제로 바탕화면 파일을 긁어오는 프로그램이 서버야.

친절함을 한 스푼 넣은 설명.

AI의 설명이 익숙해진건지, 이젠 오히려 이런게 더 거부감이 드네.

MCP가 필수 불가결이 되는 것 같이 돌아가고 있긴 한데, 아직은 관망중이긴 하다.

context7까지는 재미있었는데, 모든게 유료화가 될 것만 같은 기분.

그래서 skills를 사용하지 않을까 싶긴 한데.

이 내용은 다음에.