우리는 MCP의 핵심을 놓치고 있다: 단지 도구 때문이 아니다
Yifan - Beyond the Hype
구독자 9,830명
요약
MCP는 모델 간 상호작용을 표준화해 큰 주목을 받았지만, 대부분의 구현은 도구 인터페이스에만 집중되어 있다. 클라이언트와 서버의 역할, 프로토콜이 제공하는 다섯 가지 핵심 기능(툴, 리소스, 프롬프트, 샘플링, 루트)을 이해해야 온전한 가능성을 활용할 수 있다. 특히 샘플링과 루트 기능을 통해 에이전틱 행동과 사용자 제어를 강화할 수 있지만, 현업에서는 여전히 도구 기능만 활용 중이다. 앞으로 공개 레지스트리와 로드맵 확장 등 커뮤니티 참여가 관건이며, MCP를 직접 구현해보면서 진정한 잠재력을 체험하길 권장한다.
주요 키워드
MCP
클라이언트
서버
프롬프트
툴
샘플링
루트
리소스
에이전틱 루프
레지스트리
하이라이트
Warning: htmlspecialchars() expects parameter 1 to be string, array given in /var/www/youtubetranscribeapi/public/detail.php on line 851
Warning: htmlspecialchars() expects parameter 1 to be string, array given in /var/www/youtubetranscribeapi/public/detail.php on line 851
Warning: htmlspecialchars() expects parameter 1 to be string, array given in /var/www/youtubetranscribeapi/public/detail.php on line 851
Warning: htmlspecialchars() expects parameter 1 to be string, array given in /var/www/youtubetranscribeapi/public/detail.php on line 851
Warning: htmlspecialchars() expects parameter 1 to be string, array given in /var/www/youtubetranscribeapi/public/detail.php on line 851
Warning: htmlspecialchars() expects parameter 1 to be string, array given in /var/www/youtubetranscribeapi/public/detail.php on line 851
Warning: htmlspecialchars() expects parameter 1 to be string, array given in /var/www/youtubetranscribeapi/public/detail.php on line 851
용어 설명
Model Context Protocol (MCP)
LLM 기반 시스템 간 표준화된 통신 프로토콜
클라이언트 (Client)
MCP 호출·설정·에이전틱 루프를 관리하는 주체
서버 (Server)
클라이언트에 기능과 리소스를 제공하는 주체
프롬프트 (Prompts)
서버가 제공하는 템플릿과 매개변수로 LLM 입력을 정의하는 기능
리소스 (Resources)
클라이언트와 서버가 공유하는 맥락 데이터 자원 정의
툴 (Tools)
클라이언트가 서버에 API 호출을 요청하도록 정의된 기능 모음
샘플링 (Sampling)
클라이언트 측에서 LLM 생성을 요청·제어하는 기능
루트 (Roots)
자원 접근 범위를 제한하고 작업 경계를 설정하는 기능
에이전틱 루프 (Agentic loop)
클라이언트가 LLM을 호출하고 결과 기반으로 반복 실행하는 과정
[00:00:00]
MCP 도입 현황과 과제 소개
MCP가 AI 커뮤니티에서 주목받는 현황을 요약한다. 그러나 도구에만 집중된 구현 한계를 지적한다.
[00:00]
Model Context Protocol이 AI 커뮤니티에서 큰 주목을 받고 있으며, Sam Altman과 Sundar Pichai도 자사 제품에 통합을 발표했습니다.
[00:27]
프로토콜의 진정한 잠재력은 아직 완전히 활용되지 않고 있으며, 현재 상황과 향후 개발 방향을 살펴볼 예정입니다.
[00:00:50]
클라이언트와 서버의 역할 이해
클라이언트가 LLM 호출·설정·에이전틱 루프를 관리한다. 서버는 기능 제공에 집중한다.
[00:50]
MCP는 클라이언트와 서버로 구성되며, 클라이언트의 역할이 사용자 경험에 매우 중요합니다.
[01:38]
MCP의 다섯 가지 핵심 기능: 프롬프트, 리소스, 도구, 샘플링, 루트를 소개합니다.
[00:01:41]
다섯 가지 핵심 기능
툴, 리소스, 프롬프트, 샘플링, 루트 기능을 개괄한다.
타임라인 정보가 없습니다.
[00:01:45]
툴(Tools) 기능 설명
Slack·Postgres 예시로 API 호출 도구 구조를 소개한다.
[01:51]
Slack과 Postgres MCP 서버의 예시를 통해 도구 기능의 실제 구현 사례를 설명합니다.
[02:51]
리소스 기능은 클라이언트와 서버 간의 데이터 공유를 위한 추상적 정의를 제공합니다.
[00:02:54]
리소스(Resources) 기능
클라이언트와 서버 간 자원 공유 구조를 설명한다.
[03:11]
서버와 클라이언트 간의 파일 참조 시스템에 대해 설명합니다. PostgreSQL 데이터베이스의 예시를 들어 URL과 URI를 통한 직접 참조 방식을 소개합니다.
[00:03:49]
프롬프트(Prompts) 기능
서버 제공 템플릿과 파라미터 예시를 시연한다.
[03:49]
프롬프트 기능에 대한 설명으로, 서버가 완전한 프롬프트 템플릿을 클라이언트에 제공하고 매개변수를 설정할 수 있는 기능을 소개합니다.
[04:41]
GPT-3.5 시대의 프롬프트 템플릿 비즈니스를 언급하며, MCP를 통해 프롬프트 템플릿을 효율적으로 공유하고 활용할 수 있는 방법을 설명합니다.
[05:32]
클라이언트의 중요한 두 가지 기능인 샘플링과 루트에 대해 소개하며, 특히 샘플링이 어떻게 서버와 클라이언트 간의 LLM 생성 요청을 가능하게 하는지 설명합니다.
[00:05:56]
샘플링(Sampling)과 루트(Roots) 기능
클라이언트 측 생성 제어와 경계 정의를 살펴본다.
[06:27]
MCP 클라이언트는 LLM 생성과 샘플링을 요청할 수 있으며, 모든 LLM 상호작용을 제어할 수 있습니다. 사람의 개입이 가능한 설계를 통해 입력과 LLM 선택을 관리할 수 있습니다.
[07:03]
클라이언트 측 샘플링의 장점은 자체 컨텍스트를 첨부할 수 있다는 것입니다. 서버는 클라이언트가 전송한 컨텍스트만 접근 가능하며, 클라이언트가 데이터 전달을 완전히 제어합니다.
[07:37]
Anthropic의 프로토콜은 다른 MCP 서버의 컨텍스트 주입을 허용하며, 이를 통해 개인정보 보호를 유지하면서도 서버 간 협업이 가능합니다.
[08:05]
root 기능은 리소스 접근의 경계를 정의합니다. 파일 시스템이나 데이터베이스에서 작업 범위를 제한하여 의도치 않은 리소스 접근을 방지합니다.
[08:50]
실제 MCP 프로토콜은 초기화 단계에서 클라이언트와 서버가 서로의 기능을 파악하고 양방향 통신 채널을 수립합니다. 모든 서버가 전체 기능을 구현할 필요는 없습니다.
[00:08:52]
프로토콜 통신 흐름
초기화·운영·종료 단계 양방향 통신 구조를 설명한다.
[09:39]
MCP 프로토콜의 운영 단계에서는 각 모델의 기능을 나열하고, 리소스와 콘텐츠를 가져올 수 있으며, 프롬프트와 도구를 실행할 수 있습니다.
[10:00]
샘플링 기능은 사람이 참여하는 설계를 가지고 있으며, 이는 클라이언트가 구현해야 합니다. 프로토콜은 매우 다재다능하지만, 대부분의 서버는 도구 부분만 구현하고 있습니다.
[00:10:23]
MCP 서버 구현 사례
Slack·SQLite 서버 예제로 구현 구조 차이를 비교한다.
[10:35]
MCP 리소스는 공식 저장소에서 찾을 수 있으며, 기본 구현된 참조 서버들과 커뮤니티가 기여한 다양한 서드파티 서버들이 있습니다.
[11:20]
Slack MCP 서버의 예시를 통해 구현을 살펴보면, 메시지 전송, 채널 및 사용자 정보 가져오기 등 기본적인 기능을 제공합니다.
[12:10]
이는 단순한 REST API 래퍼로 보일 수 있지만, 이는 전체 모델 기능의 작은 부분일 뿐이며, 클라이언트에게 유연성을 제공하는 방식으로 설계되어 있습니다.
[12:57]
MCP 클라이언트는 다양한 타입의 데이터(텍스트, 이미지, 오디오 등)를 처리할 수 있으며, 기본적인 MCP 서버의 기능을 설명합니다.
[13:17]
SQLite를 활용한 MCP 서버 예시를 통해 프롬프트 기능의 구현을 설명합니다. 이 서버는 데모용 데이터베이스를 위한 프롬프트 템플릿을 제공합니다.
[13:47]
MCP 서버 정의에는 리소스 핸들러, 예시 리소스, 그리고 프롬프트 목록이 포함되어 있으며, 토픽 기반 생성을 위한 필수 인자를 처리하는 방법을 설명합니다.
[14:44]
대부분의 클라이언트에서 프롬프트 기능이 제대로 구현되지 않았으며, Claude 데스크톱 앱에서는 연결 버튼을 통해 MCP 도구와 프롬프트 템플릿에 접근할 수 있습니다.
[15:36]
실제 데모를 통해 EU GDP 데이터 예시로 프롬프트 템플릿의 사용 방법을 보여줍니다. 템플릿이 필요한 컨텍스트를 모두 제공하므로 추가 정보가 필요하지 않습니다.
[16:27]
Claude에게 DB 데이터 채우기를 명시적으로 요청하며, 지속적인 팝업 확인이 필요한 현재 워크플로우의 불편함을 지적합니다.
[17:05]
서버의 프롬프트 템플릿 제공만으로는 부족하며, 클라이언트가 이를 효과적으로 사용자에게 표시하는 것이 중요함을 설명합니다.
[00:17:07]
프롬프트 가시성과 클라이언트 도입
템플릿만 제공되면 사용자 노출이 어렵다는 점을 강조한다.
[17:44]
프로토콜 명세를 통해 각 클라이언트의 기능 구현 현황을 검토하며, Claude Desktop의 우수한 기본 기능 구현을 확인합니다.
[00:18:08]
클라이언트 지원 기능 현황
클라이언트별 구현 현황 표로 지원 차이를 제시한다.
[18:32]
샘플링 기능의 중요성과 현재 구현의 어려움을 설명하며, 이는 UX 문제와 함께 닭과 달걀의 딜레마를 가지고 있다고 분석합니다.
[00:19:34]
로드맵과 레지스트리 전망
공개 레지스트리 도입과 커뮤니티 참여 중요성을 전망한다.
[19:34]
새로운 클라이언트 도구를 발견하는데 유용한 페이지를 소개하며, 특히 Olama를 사용하는 터미널 기반 채팅 도구인 OTM을 예시로 들었습니다.
[19:57]
기술자들을 위해 MCP 전체 명세를 읽어볼 것을 권장하며, 현재 대부분이 도구에만 집중하고 있지만 더 많은 에이전트 동작 구현이 가능함을 설명했습니다.
[20:35]
구글의 새로운 에이전트 간 프로토콜(A2A)과 MCP를 비교하며, MCP가 이미 충분히 강력하고 대부분의 기능을 구현할 수 있다고 설명했습니다.
[00:21:08]
결론 및 행동 권고
MCP 직접 구현을 권장하며 테스트로 이해를 높이자.
[21:22]
로드맵에서 가장 기대되는 것은 Anthropic이 우선순위로 두고 있는 공개 레지스트리 구현이며, 이를 통해 설정 관리와 신뢰할 수 있는 서버 발견이 더욱 쉬워질 것이라고 전망했습니다.
[00:00]
Model Context Protocol은 최근 한 달간
[00:02]
AI 커뮤니티 내에서 모두의
[00:04]
관심을 끌고 있습니다.
[00:07]
심지어 Sam Altman과 Sundar Pichai도
[00:10]
트위터에서 자사의
[00:12]
핵심 제품에 MCP를 통합할 것이라고
[00:14]
발표했습니다. 원래 이것이
[00:17]
Anthropic이 주도한 표준임을 고려할 때,
[00:20]
경쟁사들이 이 표준을
[00:22]
도입한다는 사실은
[00:24]
커뮤니티에서의 영향력을 잘 보여줍니다.
[00:27]
하지만 프로토콜 명세를 깊이 들여다보면,
[00:29]
대부분의 구현이 이 프로토콜의
[00:32]
진정한 잠재력의 표면만
[00:34]
긁고 있다는 것을 알 수 있습니다.
[00:36]
오늘은 현재 우리가 어디에 있고
[00:39]
개발자들이 앞으로 몇 달 동안
[00:41]
어떻게 구현할 수 있는지
[00:43]
살펴보겠습니다. 매우 흥미로운
[00:46]
여정이 기다리고 있으니
[00:48]
바로 시작해보겠습니다. 먼저
[00:50]
명심해야 할 것은
[00:52]
이 프로토콜에는 두 부분이 있다는 것입니다.
[00:54]
바로 클라이언트와 서버입니다.
[00:57]
대부분의 사람들이 간과하는 것은
[00:59]
서버가 아무리 강력해도
[01:02]
클라이언트가 형편없다면
[01:04]
사용자들은 좋은 경험을 할 수 없다는 것입니다.
[01:06]
왜냐하면 클라이언트가 모든 MCP
[01:09]
서버 호출을 담당하기 때문입니다.
[01:12]
클라이언트가 자체 에이전트 루프를 설계하는 방식,
[01:15]
LLM에 구성을 제공하여
[01:18]
다양한 MCP 서버에 적절한 호출을
[01:20]
할 수 있도록 하는 방식이
[01:22]
매우 중요합니다. 이것이 바로
[01:25]
많은 사람들이 MCP에서 사용할 수 있는
[01:28]
기능을 제공하더라도
[01:31]
클라이언트마다
[01:33]
성능이 크게 다를 수 있는
[01:36]
이유입니다.
[01:38]
MCP 프로토콜에는 실제로 다섯 가지
[01:41]
핵심 기능이 있습니다.
[01:45]
프롬프트, 리소스, 도구,
[01:48]
샘플링, 그리고 루트입니다. 도구에 대해서는
[01:51]
설명할 필요도 없을 것 같습니다.
[01:53]
이는 지금까지 가장 많이
[01:56]
접한 기능이기 때문입니다. 예를 들어,
[01:59]
Slack MCP 서버는
[02:01]
MCP 클라이언트가 채널 목록을 조회하고,
[02:04]
특정 메시지를 검색하고,
[02:07]
메시지를 보내고,
[02:10]
MCP 서버를 통해 직접 메시지를 전송하고
[02:12]
사용자를 조회하는 등 다양한
[02:15]
Slack API 관련 기능을 제공합니다.
[02:17]
또한 Postgres MCP는
[02:20]
raw 데이터베이스 쿼리 실행,
[02:22]
테이블 조회, 메타데이터와 스키마
[02:25]
정보 조회 등을 가능하게 합니다.
[02:28]
많은 사람들이 이것을 단순히 REST
[02:31]
API의 확장판이라고 말하는 것을 들었는데,
[02:35]
만약 MCP가 도구만 구현한다면 맞는 말이지만
[02:38]
아직 다루지 않은 다른 네 가지
[02:42]
구성 요소가 있습니다.
[02:43]
이는 단순한 REST API로는
[02:46]
쉽게 달성할 수 없는 것들입니다.
[02:48]
최소한 좋은 구조로는 구현하기 어렵죠.
[02:51]
다음으로 리소스를 살펴보면,
[02:54]
이는 클라이언트와 서버 간에 공유되는
[02:57]
리소스에 대한 추상적 정의입니다.
[02:59]
이는 클라이언트가 서버에
[03:01]
처리를 위해 제공하는 것이거나
[03:03]
서버가 제공할 수 있는
[03:05]
리소스가 될 수 있습니다.
[03:07]
예를 들어, 클라이언트 측에서는
[03:09]
로컬 파일을 제공할 수 있습니다.
[03:11]
파일 콜론과 같은 참조할 수 있는 컨텐츠를
[03:15]
참조하고 서버로 보낼 수 있습니다.
[03:17]
PostgreSQL의 경우를 예로 들면,
[03:19]
PostgreSQL 콜론 URL이나 URI를 반환하여
[03:23]
이 데이터베이스의 특정 객체나
[03:26]
데이터베이스 내의 특정 테이블을
[03:29]
클라이언트가 직접 참조할 수 있게 합니다.
[03:31]
이를 통해 프로토콜은
[03:34]
정의를 쉽게 지정할 수 있는 방법을 제공합니다.
[03:37]
지금까지 가장 많이 사용된 방식은
[03:39]
주로 원시 컨텍스트를 공유하는 것이었습니다.
[03:42]
프로토콜에서 가장 흥미로운 부분은 아니지만
[03:45]
주목할 만한 부분입니다.
[03:46]
이제 프롬프트로 넘어가보겠습니다.
[03:49]
여기서부터 상황이
[03:52]
더 흥미로워지기 시작하는데,
[03:54]
프롬프트를 통해 서버는
[03:57]
완전한 프롬프트 템플릿을
[03:59]
클라이언트에 직접 제공하고
[04:02]
매개변수도 설정할 수 있습니다.
[04:05]
곧 간단한 데모로 보여드리겠습니다.
[04:08]
서버가 좀 더 복잡한 프롬프트가 필요한
[04:10]
고급 기능을 제공하는 경우
[04:14]
대부분의 서버에서 볼 수 있듯이
[04:16]
LLM 기능이 직접 내장되어 있지는 않습니다.
[04:19]
하지만 서버가 프롬프트 템플릿과
[04:22]
리소스를 검색하는 도구를 제공할 수 있다면
[04:24]
클라이언트는 LLM을 사용하여
[04:26]
최종 결과를 합성할 수 있습니다.
[04:29]
이렇게 하면 서버 개발자는
[04:32]
에이전트 루프나 LLM 구현 대신
[04:35]
서버의 유틸리티에만 집중할 수 있어
[04:38]
작업이 훨씬 수월해집니다.
[04:41]
GPT-3.5 시대로 돌아가보면
[04:44]
프롬프트 템플릿 판매로
[04:47]
수백만 달러를 벌었던 때가 있었는데,
[04:51]
이제 우리도 그렇게 할 수 있습니다.
[04:53]
여기서는 실제로
[04:54]
모든 프롬프트 템플릿을 호스팅하는
[04:57]
서버를 가질 수 있고
[04:59]
이를 MCP 클라이언트에
[05:01]
직접 제공할 수 있습니다.
[05:04]
이것이 이 프로토콜이 빛나는 부분인데,
[05:07]
단일 서버가
[05:09]
프롬프트 템플릿을 제공하면
[05:10]
현재 사용 중인 모든 클라이언트에
[05:12]
통합할 수 있고 매번 커스텀 플러그인을
[05:15]
만들거나 프롬프트를
[05:17]
복사-붙여넣기 할 필요 없이
[05:20]
그 기능을 활용할 수 있습니다.
[05:23]
클라이언트를 사용할 때마다
[05:24]
Cursor에서도 작동하고,
[05:26]
Warp에서도 작동하며,
[05:28]
Claude 데스크톱이나
[05:30]
프롬프트 기능을 구현한
[05:32]
모든 클라이언트에서 작동합니다.
[05:35]
클라이언트로 넘어가면 정말 흥미로워지는데,
[05:39]
대부분의 사람들은 이렇게 물을 것입니다.
[05:41]
'왜 클라이언트가 기능을
[05:43]
구현해야 하나요? 서버에
[05:46]
호출만 하면 되는 거 아닌가요?'
[05:49]
하지만 실제로 프로토콜은
[05:52]
클라이언트가 제공할 수 있는
[05:53]
두 가지를 지정하고 있는데,
[05:56]
이는 전체 프로세스를 더 효과적으로 만듭니다.
[05:58]
하나는 샘플링이고 다른 하나는 루트입니다.
[06:01]
샘플링은 MCP 서버가 클라이언트에
[06:06]
LLM 생성을 요청할 수 있게 해주는 기능입니다.
[06:09]
프로토콜은 서버가
[06:11]
LLM 기능을 가지고 있다고 가정하지 않고
[06:14]
클라이언트가 가지고 있다고 가정합니다.
[06:16]
왜냐하면 모든 합성이
[06:18]
거기서 일어나기 때문이죠. 샘플링을 통해
[06:22]
MCP 서버는 클라이언트에
[06:24]
알림을 보내 요청할 수 있습니다.
[06:27]
샘플과 LLM 생성을 요청할 수 있는데,
[06:30]
이를 통해 특정 콘텐츠에 대해
[06:34]
모든 LLM 상호작용이 MCP 클라이언트를 통해
[06:38]
또는 사람이 개입하는 설계를 통해 이루어질 수 있어서
[06:41]
LLM에 무엇이 입력되는지,
[06:43]
어떤 LLM을 실제로 사용할지
[06:46]
조정하고 제어할 수 있으며
[06:48]
클라이언트 측에서만
[06:51]
모든 호출을 라우팅할 수 있습니다.
[06:53]
물론, 서버에서
[06:55]
이를 구현하는 다른 방법도 있는데
[06:57]
서버가 LLM을 사용한다는 사실을
[06:59]
완전히 숨길 수도 있습니다. 하지만
[07:03]
클라이언트 측에서 샘플링을 하는 것의 장점은
[07:06]
클라이언트 샘플링 코어의 일부로
[07:08]
자체 컨텍스트를 첨부할 수 있다는 것입니다.
[07:11]
다른 서버나 리소스에 대한 정보를 포함하여
[07:15]
클라이언트가 가진 모든 컨텍스트로
[07:17]
생성을 수행할 수 있습니다.
[07:20]
서버는 클라이언트의 컨텍스트를
[07:22]
가지고 있지 않을 테니까요.
[07:24]
서버는 클라이언트가
[07:26]
전송한 것만 갖게 됩니다. 따라서 클라이언트가
[07:29]
이 생성을 수행할 수 있기 때문에
[07:31]
어떤 컨텍스트를 전달할지
[07:32]
그리고 서버에 무엇을 반환할지
[07:34]
결정할 수 있습니다. 심지어
[07:37]
프로토콜 자체에서 Anthropic은
[07:40]
다른 MCP 서버의 컨텍스트도
[07:43]
주입할 수 있다고 명시하고 있습니다.
[07:46]
즉, 샘플링을 통해 우리는
[07:49]
서로 다른 MCP 서버들 간의
[07:51]
흥미로운 협업이 가능하며
[07:54]
각자의 컨텍스트를 활용하면서도
[07:56]
개인정보 보호 문제를 일으키지 않습니다.
[07:59]
MCP 클라이언트가 항상 데이터 전달을
[08:02]
제어하기 때문입니다. 마지막으로
[08:05]
root에 대해 말씀드리면, 이는 리소스의
[08:08]
하위 집합이라고 볼 수 있습니다.
[08:11]
리소스 접근의 경계를 정의하는 역할을 합니다.
[08:15]
현재 작업 중인 코드베이스에서
[08:17]
파일 URI는 현재 작업 중인 폴더를
[08:21]
지정할 수 있어서
[08:23]
서버가 이 폴더 외의 파일에는
[08:26]
접근하지 못하도록 할 수 있고
[08:28]
데이터베이스를 사용할 때는
[08:31]
특정 테이블만 지정하여
[08:33]
다른 것은 건드리지 못하게 할 수 있습니다.
[08:35]
이는 작업의 경계를 정의하는
[08:37]
유용한 방법이 됩니다.
[08:40]
MCP 서버가 실수로 다른 리소스를
[08:43]
건드리는 것을 방지하고
[08:45]
작업을 특정 위치로 제한할 수 있습니다.
[08:48]
이제 기능들을 살펴보았으니
[08:50]
실제 프로토콜이
[08:52]
어떻게 생겼는지 보여드리겠습니다.
[08:54]
왼쪽과 같은 모습입니다.
[08:57]
초기화 단계에서 먼저
[08:59]
클라이언트는 서버가 제공하는
[09:02]
기능들을 파악하고
[09:04]
서버도 클라이언트가 제공하는
[09:06]
기능들을 이해할 수 있게 하며
[09:08]
양방향 통신 채널을
[09:10]
수립할 수 있습니다.
[09:14]
이는 매우 중요한데,
[09:16]
MCP 클라이언트와
[09:18]
서버 간의 통신이
[09:21]
양방향이기 때문입니다. 그리고
[09:24]
운영 단계에서는
[09:25]
발견된 기능들을 기반으로 작동합니다.
[09:29]
주목할 점은 모든 서버나
[09:32]
MCP가 여기 나열된
[09:34]
모든 기능을 구현할 필요는 없고
[09:37]
서로가 어떤 기능을 가졌는지만
[09:39]
수행할 수 있는 기능을 알려주면 됩니다. 그리고
[09:40]
운영 단계에서는 각각의
[09:43]
모델 기능에 대해 나열할 수 있고
[09:47]
리소스를 가져올 수 있으며
[09:50]
콘텐츠도 가져올 수 있습니다. 프롬프트의 경우
[09:52]
프롬프트 목록을 가져올 수 있고
[09:54]
실행할 수 있습니다. 도구의 경우에는
[09:56]
도구 목록을 가져오고
[09:58]
실행할 수 있죠. 샘플링 기능은
[10:00]
사람이 참여하는 설계를 가지고 있는데
[10:02]
이는 클라이언트가 구현해야 합니다.
[10:04]
마지막으로 종료 단계가 있습니다.
[10:07]
결국 이 프로토콜은 실제로
[10:10]
매우 다재다능하고 다양한 기능을
[10:14]
지원할 수 있습니다. 하지만
[10:17]
앞서 말씀드렸듯이 대부분의 서버에서는
[10:21]
도구 부분만 구현하고 있습니다.
[10:23]
하지만 MCP는 그 이상의 것임을 알고 있죠.
[10:27]
그럼 이제 MCP 서버 구현의
[10:31]
몇 가지 예시를 통해
[10:33]
전체적인 작동 방식을 설명하겠습니다.
[10:35]
MCP 리소스를 어디서 찾아야 할지
[10:37]
모르시는 분들은
[10:40]
MCP 저장소의 서비스 목록을
[10:43]
확인해 보시기 바랍니다.
[10:46]
우선, 이미 기본 구현이 된
[10:48]
다양한 참조 서버들이 있어서
[10:50]
바로 사용할 수 있고
[10:52]
커뮤니티에서 기여한 많은
[10:55]
서드파티 서버들도 있습니다.
[10:57]
공식, 비공식 모두 포함해서요.
[10:59]
현재 검색을 위한
[11:02]
레지스트리들이 많이 있다는 것을
[11:04]
알고 있습니다만
[11:06]
이 영상에서는 다루지 않을 것이고
[11:08]
제가 MCP 호출을 훨씬 더 쉽게 만드는
[11:11]
제품을 개발 중이라는 것도 말씀드리고 싶네요.
[11:14]
관심 있으시다면
[11:16]
아래에 메시지를 남겨주세요.
[11:18]
초기 세부 정보를 공유해 드리겠습니다.
[11:20]
이제 Slack MCP 서버를 자세히 살펴보겠습니다.
[11:23]
보시다시피 주로 도구들을 제공하는데
[11:27]
메시지 전송, 채널 가져오기
[11:30]
사용자 가져오기 등 기본적인 기능이 있고
[11:32]
설정에서는 이미 익숙한
[11:35]
구성들이 있습니다.
[11:37]
이제 실제 구현을
[11:38]
살펴보겠습니다. 모든 도구들에 대해
[11:42]
도구가 무엇인지, 설명과
[11:44]
MCP 클라이언트가 서버를 호출할 때 필요한
[11:48]
적절한 입력 스키마를 정의하고
[11:51]
기본 요구사항들을 포함합니다.
[11:54]
실제 구현을 보면
[11:57]
채널 가져오기를 예로 들면
[11:59]
특별한 것이 없습니다.
[12:03]
단순히 Slack API를 직접 호출하는 것뿐이죠.
[12:06]
이 시점에서 대부분의 사람들이
[12:10]
'이건 그냥 REST API의
[12:13]
래퍼일 뿐이잖아'라고 생각할 수 있습니다.
[12:16]
특별한 게 없다고요.
[12:18]
그리고 그 말이 맞습니다.
[12:20]
그래서 제가 말씀드린 것처럼
[12:23]
도구만 구현한다면, 네, 이것은 단순한
[12:26]
REST API 래퍼일 뿐입니다. 하지만
[12:28]
그게 중요한 게 아닙니다. 이것은
[12:31]
모델 기능의 작은 부분일 뿐이니까요.
[12:34]
조금 더 아래로 내려가서
[12:35]
응답을 살펴보겠습니다.
[12:38]
MCP 클라이언트에 반환되는 것은
[12:43]
익숙한 완성 텍스트인데
[12:45]
텍스트 타입의 콘텐츠를 가지고 있고
[12:49]
임의의 텍스트를 넣을 수 있습니다.
[12:51]
여기에는 구조가 없는데, 그 이유는
[12:54]
LLM 클라이언트에게 맡기기 때문입니다.
[12:57]
MCP 클라이언트 측에서 이 데이터를
[13:00]
해석하도록 되어 있습니다. 단순히 텍스트 타입만
[13:03]
전송할 수 있는 것이 아니라
[13:05]
이미지, 오디오 등 다양한 타입을
[13:08]
전송할 수 있습니다. 이것이
[13:10]
기본적인 MCP 서버의 예시입니다. 이제
[13:13]
조금 더 흥미로운 예시를 살펴보겠습니다
[13:16]
SQLite 예시를 보겠습니다.
[13:17]
이 예시를 살펴보려는 이유는
[13:21]
코드가 길어서가 아니라
[13:24]
추가적인 기능을 구현하고 있기 때문입니다
[13:26]
바로 프롬프트 부분입니다
[13:29]
프롬프트 부분에서
[13:32]
이 SQLite MCP 서버는
[13:36]
클라이언트가 데모용 SQLite 데이터베이스를
[13:38]
채울 수 있도록 프롬프트 템플릿을 제공합니다
[13:41]
물론 이것은
[13:43]
일상적으로 사용하는 것은 아니지만
[13:44]
흥미로운 예시가 될 수 있습니다
[13:47]
MCP 서버 정의를 보면
[13:49]
리소스를 처리하는 핸들러가 있고
[13:52]
예시 리소스도 있습니다
[13:54]
이것도 데모 목적으로만 있는 것이고
[13:59]
실제 SQLite 리소스를 나열하지는 않습니다
[14:01]
하지만 프롬프트 목록을 보면
[14:05]
MCP 데모 프롬프트를 나열할 수 있고
[14:07]
이를 통해 MCP 서버의 통합을
[14:10]
시연할 수 있다고 알려줍니다
[14:14]
그리고 토픽을 기반으로
[14:16]
생성하기 위한 필수 인자가 있습니다
[14:19]
여기서는 실제로 요청이 들어올 때
[14:22]
관련 인자와 함께 프롬프트를 처리해야 합니다
[14:26]
어떻게 프롬프트를 생성하고 클라이언트에게
[14:31]
돌려보낼지 처리해야 합니다
[14:33]
그리고 Slack 도구에서도 봤듯이
[14:35]
표준 도구 목록도 있습니다
[14:37]
이 시점에서 일부 분들은
[14:40]
"도구는 봤는데 프롬프트는
[14:42]
본 적이 없다"고 하실 텐데
[14:44]
그건 대부분의 클라이언트에서
[14:46]
이 기능이 제대로
[14:48]
구현되지 않았기 때문입니다
[14:49]
Claude에서도 UI에서 찾기가
[14:52]
정말 어려웠습니다
[14:56]
대부분의 클라이언트에서 잘못 구현되어 있죠
[14:59]
Claude에서도 찾기가 쉽지 않았는데
[15:02]
UI에서 정말 열심히 찾아야 했습니다
[15:05]
Claude 데스크톱 앱의 연결 버튼 안에
[15:09]
있습니다
[15:12]
여기에 모든 MCP 도구가
[15:15]
직접 나열되어 있고
[15:17]
MCP에서 첨부할 수 있습니다
[15:19]
통합 메뉴에서 선택하면
[15:21]
설정된 MCP 서버 아래에
[15:24]
채팅 아이콘처럼 생긴 버튼이 있습니다
[15:27]
이것이 첨부할 수 있는
[15:28]
프롬프트 템플릿이고
[15:31]
파일 아이콘이 있는 것은
[15:33]
첨부할 수 있는 리소스입니다
[15:36]
데모를 클릭하면
[15:38]
실제 토픽을 입력하라는 메시지가 나옵니다
[15:43]
예를 들어 'EU의 2022년부터
[15:48]
2024년까지의 GDP'라고 입력해보겠습니다
[15:53]
이 프롬프트를 추가하면
[15:55]
로직에 따라 방금 언급한 내용으로
[15:59]
프롬프트가 채워진 것을 볼 수 있습니다
[16:01]
GDP를 검색해보면
[16:03]
사용자가 선택한 토픽이 보이고
[16:06]
나머지는 프롬프트 템플릿에서 가져옵니다
[16:10]
계속 진행해보겠습니다. 추가 컨텍스트는
[16:13]
제공하지 않을 건데
[16:16]
프롬프트 템플릿이 이미
[16:17]
모든 것을 제공하고 있기 때문입니다
[16:20]
전체 생성을 위해 이것을 사용할 것입니다
[16:23]
아, 제가 너무 일찍 말한 것 같네요
[16:27]
아, 너무 이른 것 같네요.
[16:29]
명시적으로 요청해야겠어요. DB에 이 데이터를
[16:33]
채워넣어 주세요.
[16:36]
나머지 워크플로우는
[16:38]
이미 잘 알고 계실 거예요.
[16:41]
Claude가 YOLO 모드 같은 걸 제공해서
[16:44]
MCP 도구들이 자동으로 실행되게 했으면 좋겠어요.
[16:47]
이렇게 계속 팝업이 뜨는 게
[16:50]
꽤 귀찮거든요.
[16:52]
완료될 때까지 기다리진 않을 건데,
[16:54]
보시다시피 실제로 작성되는
[16:57]
데이터의 양과 생성되는 데이터가
[17:00]
긴 프롬프트를 작성하지 않아도
[17:02]
자동으로 처리되고 있죠.
[17:05]
여기서 중요한 점은,
[17:07]
서버가 프롬프트 템플릿만 제공하는 것으로는
[17:09]
충분하지 않다는 거예요.
[17:12]
클라이언트가 이걸 사용자에게
[17:14]
보여줄 수 있어야 해요. 서버가 아무리
[17:17]
템플릿을 제공해도,
[17:18]
클라이언트가 이를 표시할
[17:20]
좋은 방법을 제공하지 않으면
[17:22]
사용자는 결국 이게 어디서
[17:25]
오는지 알 수 없게 되죠.
[17:27]
아마도 궁금하실 거예요.
[17:29]
'이런 유용한 템플릿이 있는데
[17:31]
왜 Cursor나 WinSF에는 없지?'라고요.
[17:33]
그건 이 도구들이
[17:35]
사양의 도구 부분만 구현했기 때문이에요.
[17:38]
아직 프롬프트 지원은
[17:40]
추가하지 않았어요.
[17:44]
제가 정보를 찾아보는
[17:45]
또 다른 곳은 프로토콜 명세 내부예요.
[17:48]
실제 예제 클라이언트들을 보면
[17:51]
현재 지원되는 데이터와
[17:54]
각 클라이언트가 지원하는
[17:57]
다양한 기능들의 최신 목록을
[18:00]
확인할 수 있어요.
[18:03]
이걸 자세히 살펴보면...
[18:05]
좀 더 크게 볼까요?
[18:07]
이 목록을 보면,
[18:10]
Claude Desktop가 기본 기능들을
[18:13]
꽤 잘 구현하고 있는 걸
[18:15]
방금 테스트로도 확인했죠.
[18:17]
Cursor를 보면
[18:20]
도구 기능만 구현했고,
[18:22]
WinSF도 마찬가지예요.
[18:27]
전반적으로 보면 아무도
[18:29]
샘플링을 구현하지 않았는데,
[18:32]
제가 보기에 샘플링이야말로
[18:36]
클라이언트가 구현할 수 있는
[18:38]
가장 흥미로운 기능이에요. 왜냐하면
[18:41]
서버가 LLM의 기능을
[18:44]
직접 구현하지 않고도
[18:46]
활용할 수 있게 해주거든요.
[18:49]
하지만 프로토콜이 요구하는
[18:52]
휴먼 인 더 루프 설계 때문에
[18:54]
이건 쉽게 해결할 수 있는
[18:58]
UX 문제가 아니에요.
[19:01]
하지만 최근 샘플링을 구현한
[19:04]
새로운 UI들이 등장하고 있어서,
[19:06]
앞으로 몇 달 안에
[19:08]
서버 측과 클라이언트 측 모두에서
[19:11]
이 기능이 더 많이 사용되길 바라요.
[19:13]
이건 닭이 먼저냐
[19:14]
달걀이 먼저냐 같은 문제거든요.
[19:16]
서버가 샘플링을 구현하지 않으면
[19:19]
클라이언트도 이를 구현할
[19:21]
동기가 없고, 그러면 서버도
[19:23]
새로운 기능을 추가할 수 없죠.
[19:25]
그래서 지금은 대부분
[19:28]
도구 기능에만 머물러 있어요.
[19:31]
이 페이지는 수시로 확인하는 게 좋은데
[19:34]
새로운 클라이언트를 발견하는 데
[19:37]
매우 유용한데,
[19:40]
오늘 제가 발견한 것은
[19:42]
OTM이라는 것입니다.
[19:44]
이것은 터미널 기반 채팅으로
[19:46]
Olama를 사용하여 채팅을 구현한
[19:49]
몇 안 되는 일반 사용자용 도구 중
[19:51]
샘플링을 구현한 도구입니다.
[19:54]
한번 시도해보시길 추천드립니다.
[19:57]
기술에 관심 있으신 분들은
[20:00]
모델 컨텍스트 프로토콜의
[20:03]
전체 명세를 꼭 읽어보시길 바랍니다.
[20:05]
현재 정의된 기능이 매우 많고
[20:09]
이를 이해하면
[20:11]
새로운 기능을 구현할 수 있는
[20:14]
좋은 아이디어를 얻을 수 있습니다.
[20:17]
아직 아무도
[20:18]
시도하지 않은 기능들이 많죠.
[20:20]
비디오 시작 부분에서 언급했듯이
[20:23]
대부분의 사람들이
[20:24]
도구에만 집중하고 있기 때문입니다.
[20:27]
하지만 이를 통해 구현할 수 있는
[20:30]
에이전트 동작이 훨씬 더 많습니다.
[20:32]
일부 사람들은 이렇게 말할 수 있죠.
[20:35]
"구글이 방금 출시한
[20:37]
에이전트 간 프로토콜이 이미 해결하지 않나요?"
[20:40]
확실히 매우 흥미로운 프로토콜이고
[20:43]
많은 측면에서
[20:45]
MCP와 경쟁할 것 같지만
[20:48]
정확한 결과는
[20:51]
커뮤니티의 채택에
[20:53]
달려있습니다.
[20:55]
하지만 제게 MCP는 이미
[20:58]
대부분의 에이전트 동작을
[21:01]
구현하기에 충분히 강력합니다. A2A SDK는
[21:06]
좋은 추상화 계층이지만
[21:08]
제 개인적인 견해로는
[21:11]
그다지 많은 추가 가치를
[21:13]
제공하지 않습니다. MCP 명세나
[21:16]
로드맵에서 이미 계획된 것 외에
[21:19]
새로운 것이 없습니다.
[21:22]
그래서 로드맵 섹션도 확인해보시고
[21:25]
실제로 진행 중인 것을
[21:28]
살펴보시면 커뮤니티 전반에 걸쳐
[21:30]
많은 논의가 이루어지고 있음을
[21:31]
보실 수 있습니다.
[21:34]
제가 가장 기대하는 것은 레지스트리입니다.
[21:38]
최근 Anthropic의
[21:40]
스태프 엔지니어의 발표에 따르면
[21:43]
이것이 그들의
[21:45]
최우선 과제 중 하나라고 합니다.
[21:47]
공개 레지스트리를 구현하여
[21:50]
더 쉬운 발견과
[21:52]
중앙화된 레지스트리를 통한
[21:55]
설치 지침 설정을 가능하게 합니다.
[21:57]
이것이 구축되면
[21:58]
설정 관리가 줄어들고
[22:00]
신뢰할 수 있고 사용 가능한 서버를
[22:04]
중앙에서 찾을 수 있어
[22:06]
매우 편리해질 것입니다.
[22:08]
이제 MCP가 무엇인지 잘 이해하셨으니
[22:11]
직접 MCP를 개발해보면서
[22:13]
이해도를 테스트해보세요.
[22:15]
제 AI 코딩 영상을
[22:17]
확인해보시기 바랍니다.
[22:20]
그럼 다음 영상에서
[22:22]
만나뵙겠습니다.