MCP 및 Claude API를 활용해 구축하기

Anthropic 구독자 70,600명

요약

이 영상은 Anthropic 팀이 개발한 MCP(Model Context Protocol)의 개념부터 오픈소스 표준화 과정, Claude API와의 통합 방법까지 전반을 다룹니다. MCP를 통해 LLM이 웹 검색, GitHub, 문서, 브라우저 자동화, 홈 오토메이션 등 외부 컨텍스트와 상호작용하는 방식을 소개합니다. 또한 레지스트리를 통한 서버 관리, 도구 설계 시 프롬프트 엔지니어링 팁과 컨텍스트 최적화 전략을 제시하며, 실제 사례를 통해 확장 가능한 생태계 구축 방법을 보여줍니다.

주요 키워드

Model Context Protocol Claude API 레지스트리 프롬프트 엔지니어링 컨텍스트 관리 원격 MCP 서버 오픈소스 프로토콜 Playwright MCP llms.txt 도구 메타데이터

하이라이트

🔑 MCP는 LLM에 외부 컨텍스트와 도구 액세스를 제공하는 ‘범용 커넥터’입니다.
🚀 오픈소스로 공개된 MCP는 단일 프로토콜로 다양한 모델과 애플리케이션 간 호환성을 실현합니다.
🌟 중앙 레지스트리(예: mcp.github.com)를 통해 신뢰할 수 있는 MCP 서버를 쉽게 탐색하고 활용할 수 있습니다.
📌 Context 7 같은 서버는 최신 패키지 문서를 실시간으로 가져와 LLM의 지식 컷오프 한계를 보완합니다.
⚡️ Playwright MCP 서버는 브라우저를 원격 제어해 웹페이지 스크린샷과 상호작용을 가능하게 합니다.
📌 Claude API에 내장된 MCP 커넥터를 사용하면 별도 코드 없이 URL과 인증정보만으로 도구 호출이 자동화됩니다.
📝 도구 이름과 설명에 정확하고 구체적인 프롬프트를 작성하면 모델 성능과 활용도가 크게 향상됩니다.
🔍 불필요한 도구나 오래된 대화 이력을 줄여 컨텍스트 오염을 방지하고 모델의 의사결정을 명료하게 유지해야 합니다.

용어 설명

MCP(Model Context Protocol)

LLM이 웹 검색, API, 홈 오토메이션 등 외부 도구와 상호작용하도록 표준화된 프로토콜

LLM(대형 언어 모델)

대규모 텍스트 데이터를 학습해 자연어 이해·생성 작업을 수행하는 AI 모델

프롬프트 엔지니어링

모델에게 원하는 동작을 이끌어내기 위해 입력 문구(프롬프트)를 설계하는 기법

레지스트리

공식 MCP 서버 목록을 보관·공유하는 중앙 저장소로, 검증된 엔드포인트를 탐색할 수 있음

llms.txt

문서를 LLM에 친화적으로 제공하기 위해 텍스트 형태로 공개하는 표준 형식

슬랙 상태 업데이트를 Claude가 자동으로 생성한다는 농담으로 시작하며, 오늘의 주제인 MCP와 Claude API 활용을 예고합니다.

[00:00] 진행자들이 서로를 소개하며 대화를 시작합니다. Claude가 작성하는 슬랙 상태 업데이트에 대한 농담을 주고받은 후, Alex가 Anthropic의 Claude Relations 리더로, Michael은 API 팀 엔지니어로, John은 MCP 팀 멤버로 자신들을 소개합니다.

Alex(클로드 관계 총괄), Michael(API 엔지니어), John(MCP 팀) 세 발표자가 모여 MCP와 Claude API에 대해 설명할 예정임을 알립니다.

[00:30] John이 MCP의 기본 개념을 설명합니다. MCP는 Model Context Protocol로, 모델에게 외부 컨텍스트를 제공하는 방법입니다. 일반적인 챗봇 대화의 한계를 넘어서, Claude가 인터넷 검색이나 여행 예약 같은 외부 행동을 취할 수 있게 해주는 역할을 합니다.

MCP는 Model Context Protocol의 약자로, 대화 이력 이외에 웹, 외부 서비스 등 모델에 추가 컨텍스트를 제공하여 대리 작업이 가능하게 하는 프로토콜입니다.

[01:16] Alex가 MCP를 애플리케이션과 모델 사이의 범용 커넥터로 비유하며, Claude를 모든 외부 데이터 소스와 도구에 연결하는 방법이라고 설명합니다. 이어서 MCP를 개발하게 된 배경에 대해 질문합니다.

도구 사용 기능이 확장되며 유사 기능을 여러 곳에 중복 구현하던 문제를 해결하고, 다양한 애플리케이션에서 통일된 방식으로 외부 도구에 접근하기 위해 MCP를 구축했습니다.

[01:34] John이 MCP 개발의 동기를 설명합니다. 도구 사용 기능이 발전하면서 다양한 컨텍스트에서 동일한 기능들을 반복적으로 재구현하고 있다는 문제를 발견했습니다. 코딩 에디터의 어시스턴트, claude.ai, 기타 서비스들이 모두 웹 검색 같은 동일한 기능을 각각 구현해야 했던 상황을 예로 듭니다.

[02:10] 하나의 통합된 프로토콜을 만들어 '한 번 만들고 어디서든 구성하는' 방식을 채택했다고 설명합니다. 이를 통해 Claude Code에서 사용하는 웹 검색 기능과 Claude.ai에서 사용하는 기능이 동일하게 작동할 수 있게 되었습니다. Alex는 이런 범용 호환성 접근 방식에 동의하며, 오픈 소싱을 통한 MCP 접근법이 다른 통합 방식들과는 차별화된다고 언급합니다.

내부 프로토콜의 가치를 더 많은 엔지니어와 기업이 활용하도록 공개하며, 다양한 모델 통합을 위한 표준 프로토콜로 성장시키고자 오픈소스로 공개했습니다.

[02:48] 다른 회사들의 일반적인 통합 방식과는 다른 접근법을 택했던 이유와 오픈소스 결정의 배경에 대해 논의합니다.

[02:57] 오픈 스탠다드의 가치를 강조하며, 엔지니어와 회사들이 생태계를 구축할 수 있게 하는 것의 중요성을 설명합니다.

[03:12] Claude만을 위한 전용 커넥터 대신 다중 모델 지원의 필요성을 언급하며, 각 모델별로 별도 커넥터를 구현해야 하는 문제점을 지적합니다.

[03:37] 모델의 외부 컨텍스트 접근이 모든 참여자에게 도움이 되는 상생 관계임을 설명하고, 내부 프로토콜의 가치를 인정했습니다.

원격 호스팅 MCP 서버 지원과 중앙 레지스트리 출시로 초기 설정 절차를 간소화했습니다. GitHub, Asana 등 여러 기업이 MCP 서버를 배포 중입니다.

[04:04] MCP 오픈소스 공개 후 예상을 뛰어넘는 폭발적인 성장과 커뮤니티 반응, 그리고 최소한의 지원으로도 놀라운 개발 환경이 구축되었음을 회고합니다.

[04:31] 프로젝트가 당초 기대를 훨씬 넘어서는 성공을 거두었으며, Anthropic의 단순한 프로젝트에서 산업 표준 생태계로 발전했음을 설명합니다.

[04:54] 적절한 오픈소스 재단으로의 전환과 다양한 제공업체와의 협력을 통해 MCP의 장기적 지속가능성을 확보했다고 밝힙니다.

[05:06] MCP 발표 후 거의 1년이 지난 현재의 상황에 대해 질문하며, 많은 사람들이 여전히 초기 버전에 대한 인식을 가지고 있지만 프로토콜이 빠르게 발전하고 있음을 지적합니다.

[05:33] 원격 MCP 지원 출시가 중요한 전환점이었으며, 초기에는 모든 것을 개별적으로 실행해야 했던 제약이 Asana 같은 제공업체들의 자체 서버 호스팅을 방해했다고 설명합니다.

[05:52] 원격 MCP 서버 지원으로 설정 과정이 크게 개선되어 사용자들이 빠르게 시작할 수 있게 되었다는 설명

Context 7: 최신 개발 문서를 자동 갱신해 모델 지식 컷오프를 보완합니다. GitHub MCP: 공식 엔드포인트로 PR 조회, 이슈 관리 등을 지원합니다.

[06:12] MCP 서버들의 중앙 레지스트리를 출시하고, 오픈소스 정신에 따라 다른 조직들도 레지스트리를 확장할 수 있는 표준을 제공

[06:48] GitHub MCP, Asana MCP 등 주요 회사들이 공식 MCP 서버를 구축하여 과거의 복잡한 설정 과정이 간소화됨

[07:20] 공식 GitHub 사이트에서 직접 MCP 서버에 접근할 수 있게 되어 Claude Code나 Claude.ai에 쉽게 연결 가능

[07:43] Context 7이라는 흥미로운 MCP 소개 - 대형 언어 모델의 지식 컷오프 문제를 해결하기 위한 솔루션

[08:10] Context 7이 Next.js나 API 웹사이트에서 최신 문서를 자동으로 가져와 Claude가 최신 정보에 접근할 수 있게 하는 방식 설명

[08:35] 최신 문서를 원시 텍스트 형태로 만들어 LLM이 접근하기 쉽게 하는 현재 업계 트렌드에 대한 논의

[08:50] Michael이 llms.txt 형식에 대해 설명하며 기술 업계 전반에서 이 형식의 채택이 증가하고 있다고 언급합니다.

Playwright MCP 서버를 통해 Claude가 브라우저에서 웹페이지를 로드·조작하고 스크린샷을 분석해 CSS 개선, UI 수정 등을 반복적 자가검증 루프로 수행합니다.

[09:00] John이 소프트웨어 개발자로서 Playwright MCP 서버의 유용성을 설명합니다. 이 도구는 Claude가 실제 사용자처럼 브라우저와 상호작용할 수 있게 해줍니다.

[09:19] Playwright를 통해 Claude가 웹페이지를 실제로 보고 CSS와 HTML 뿐만 아니라 시각적 결과물까지 분석할 수 있다고 설명합니다.

[09:50] Claude Code와 함께 사용할 때의 자기개선 루프에 대해 논의합니다. Claude가 변경사항을 적용하고, 결과를 확인한 후 필요에 따라 수정하는 반복 과정을 설명합니다.

MCP SDK를 직접 사용하거나, Claude API의 내장 MCP 커넥터 기능을 활용해 URL과 인증정보만 제공하면 도구 호출·결과 피드백 과정을 자동화할 수 있습니다.

[10:35] Claude API에서 MCP 활용 방법에 대한 질문이 제기됩니다. 전통적인 MCP SDK 사용법과 최근 출시된 MCP 커넥터 기능의 차이점을 설명합니다.

[11:04] MCP 커넥터 기능의 장점을 설명합니다. 원격 MCP 위치와 인증 정보만 제공하면 복잡한 연결 작업을 API가 자동으로 처리해준다고 합니다.

[11:31] 개발자들이 MCP 커넥터 덕분에 기존의 복잡한 코드를 대폭 삭제할 수 있게 되었다는 피드백을 공유합니다.

[11:45] MCP를 사용할 때는 URL과 엔드포인트만 전달하면 쉽게 연결할 수 있습니다.

도구 이름, 설명, 파라미터를 구체적이고 명확히 작성하는 것이 중요합니다. 모델이 최적의 호출 방법을 파악하도록 프롬프트 스타일을 도구 메타데이터에 담아야 합니다.

[11:51] MCP 개발자들에게 가장 중요한 팁은 MCP 서버와 도구들이 본질적으로 프롬프트라는 점을 이해하는 것입니다. AI 애플리케이션 개발 시 모델에게 프롬프트할 때 사용하는 언어가 신중하고 정확해야 합니다.

[12:15] MCP 서버 정의의 모든 요소가 중요합니다. 도구 이름을 적절히 정의하고, 설명을 제공하며, 사용법 예시를 포함하고, 적절한 매개변수 이름을 사용하는 것이 모델의 행동에 직접적으로 영향을 줍니다.

[12:38] 이미지 생성 서버 예시를 통해 설명하면, 단순히 'Generate Image' 도구에 'Description' 필드만 있을 때와 디퓨전 모델의 특성과 최적 프롬프트 방식을 상세히 설명했을 때 Claude의 결과물이 극명하게 달라집니다.

[13:31] 설명이나 프롬프트 이름에서 몇 단어만 바꿔도 MCP 서버에서 훨씬 좋은 결과를 얻을 수 있습니다. 이는 Claude와 함께 하는 모든 지식 작업에서도 동일하게 적용되는 원리입니다.

[13:47] 개발자들이 종종 잊는 점은 독립적으로 작업하는 도구 설명이나 기능들이 결국 모두 하나의 프롬프트로 통합되어 Claude에게 전달된다는 것입니다. 코드의 JSON에 작성하는 모든 설명이 프롬프트의 일부가 됩니다.

불필요한 도구나 오래된 대화 이력은 토큰 낭비와 혼란을 초래합니다. 작업 관련성에 맞춰 도구와 MCP 서버를 선별해 컨텍스트를 명확히 유지해야 합니다.

[14:20] 컨텍스트 관리와 많은 도구 및 결과 처리는 현재 LLM들이 직면한 큰 문제입니다. 컨텍스트 오염 측면에서 개발자들이 MCP와 함께 어떻게 접근해야 하는지가 중요한 고려사항입니다.

[14:39] Michael이 MCP 서버 개발에서 흔한 안티패턴에 대해 설명합니다. 개발자들이 너무 많은 도구나 서버를 한 번에 연결하면 비용이 증가하고 모델이 혼란스러워집니다. Linear와 Asana같은 유사한 도구들이 동시에 연결되면 모델이 어떤 것을 사용할지 판단하기 어려워진다고 지적합니다.

[15:19] 도구 선택 시 신중하고 결정적인 접근이 필요하며, 현재 사용자 프롬프트와 관련 없는 정보는 포함하지 않아야 한다고 조언합니다. 대화 초반의 기초적인 정보(날씨 등)가 나중의 복잡한 작업에는 불필요할 수 있다는 예시를 제시합니다.

[15:58] John이 Claude에 전달할 수 있는 도구나 MCP 서버의 개수에 대한 질문을 제기합니다. 이는 단순한 숫자 문제가 아니라 도구들이 얼마나 구별되고 잘 정의되어 있는지가 중요하다고 말합니다.

팀 업데이트 자동 생성, 홈 네트워크 홈오토메이션(문 잠금), 지식 그래프 서버(사용자 메모 연결) 등 다양한 개인·업무용 MCP 활용 예시를 공유합니다.

[16:19] Michael이 절대적인 개수 제한도 존재한다고 답변합니다. 컨텍스트 윈도우의 토큰 한계와 각 서버의 함수 정의가 차지하는 공간을 고려해야 합니다. 더 많은 정보를 제공할수록 LLM의 결정 능력이 떨어지므로, 현재 작업과 관련된 부분집합만 제공하는 것이 좋다고 권장합니다.

[16:49] MCP 서버 설계 시 15-20개 도구보다는 1-2개 도구를 갖는 것이 모델에게 더 유용하다고 설명합니다. MCP 인터페이스 개발은 API 개발과 다르며, 자연어를 받을 수 있는 도구 설명을 제공하면 여러 개의 구체적인 API 대신 하나의 포괄적인 '정보 가져오기' 도구로 대체할 수 있다고 조언합니다.

[17:45] MCP 서버 설계 시 추상화 레벨을 고려해야 하며, 작은 도구 세트로 효율적인 호출을 구현할 수 있다고 설명합니다.

[18:12] 개발자들의 실제 MCP 활용 사례에 대한 질문이 제기되며, Playwright 외의 다른 실험 방법들에 대해 궁금해합니다.

[18:27] Anthropic 내부에서 MCP를 활용한 정보 통합 사례를 소개하며, Slack, 문서, 코드베이스의 정보를 종합해 자동으로 프로젝트 상태 업데이트를 생성하는 방법을 설명합니다.

[19:17] 모든 상태 업데이트가 Claude에 의해 생성된다는 놀라운 사실이 밝혀지며, 실제 업무에서 AI의 광범위한 활용을 보여줍니다.

[19:25] John이 홈 오토메이션 분야에서 MCP를 활용하는 사례를 소개하며, 집안 기기 제어와 문 잠금 관리 등의 실용적인 활용법을 설명합니다.

[19:56] MCP 서버의 창발적 특성과 마법 같은 느낌에 대해 언급하며, 미래 기술에 대한 미리보기 같은 경험을 제공한다고 설명합니다.

[20:18] 지식 그래프 서버 구축 사례를 소개하며, Claude가 기억을 저장하고 기억들 간의 연결을 형성할 수 있는 두 가지 도구를 가진 MCP 서버를 설명합니다.

[20:44] MCP 서버가 기억을 생성하고 연결하는 간단한 도구를 제공했을 때, Claude와의 대화에서 흥미로운 현상이 나타났습니다. Claude는 탐사 기자처럼 행동하며 사용자의 피아노 연주 취향에 대해 깊이 질문하고, 지식 그래프에 세부 정보를 기록했습니다.

[21:22] MCP 프로토콜의 핵심 장점은 Gmail 서버와 홈 자동화 서버 같은 다양한 시스템들을 연결할 때 나타납니다. Claude는 이런 연결을 통해 사용자가 예상하지 못한 창의적인 방식으로 문제를 해결할 수 있습니다.

[21:52] MCP와 기존 구조화된 API의 핵심 차이점은 유연성에 있습니다. LLM이 충분히 똑똑해서 모든 것을 자연스럽게 조합할 수 있기 때문에, 엄격한 계약이나 호환성 문제에 대한 걱정이 줄어듭니다. API 구조를 크게 변경해도 새 버전을 배포할 필요가 없죠.

[22:46] MCP는 구체적인 기술적 세부사항보다는 높은 수준의 의도와 액션에 집중합니다. 이는 더 자연스럽고 유연한 상호작용을 가능하게 합니다.

유저가 MCP 존재를 인지하지 못할 만큼 투명하게 작동하는 표준 프로토콜이 되는 것이 목표입니다. 서버 평가 기준으로 자리잡고, 생태계가 성숙해질 것으로 기대합니다.

[22:58] MCP의 미래에 대한 질문에 대해, 성공적인 프로토콜은 사용자가 그 존재를 인식하지 못할 때 진정으로 성공한 것이라고 설명합니다. MCP가 뒤에서 모든 시스템을 연결하는 역할을 하면서도 사용자에게는 보이지 않아야 한다는 철학을 제시합니다.

[23:32] LLM이 모든 것을 구성하고 사용자는 필요한 도구만 제공하면 되는 MCP의 단순함에 대해 설명합니다.

[23:41] MCP에 대한 관심이 지속될지, 그리고 프로토콜의 미래에 대한 질문이 제기됩니다.

[23:54] AI 분야에서는 선례를 적용하기 어렵지만, MCP 팀의 작업이 매우 흥미진진하다고 평가합니다.

[24:06] 크고 작은 회사들이 MCP를 보편적인 기술로 만들기 위해 협력하는 모습이 인상적이라고 언급합니다.

[24:21] 현재 많은 사람들이 MCP의 가치를 깨닫고 서버를 개발하기 시작했지만, 아직 초기 단계라고 설명합니다.

[24:37] 사람들이 MCP 서버의 작동 방식을 평가하고 개선하기 시작하는 것을 기대한다고 말합니다.

[24:47] MCP가 업무용 벤더를 평가하는 지표가 되기를 바란다고 언급합니다.

[24:55] 로그 분석 서비스를 예로 들어, MCP 서버를 통해 Claude와 직접 상호작용할 수 있다면 매우 가치 있을 것이라고 설명합니다.

[25:13] 훌륭한 MCP 서버를 개발한 회사는 엔지니어들에게 큰 장점을 제공할 수 있으며, 이는 강력한 셀링 포인트가 될 것이라고 말합니다.

[25:31] 단순히 MCP 서버를 출시하는 것을 넘어서, 최고의 MCP 서버를 제공한다는 점으로 경쟁하는 성숙한 시장이 되기를 기대한다고 밝힙니다.

[00:00] - 그럼 슬랙에서 네 상태 업데이트를 내가 읽고 있는 거야?

[00:02] 그리고 그것들이 모두 Claude가 생성한 거야?

[00:04] - 맞아, 난 이제 실제로는 아무것도 안 쓰고 있어.

[00:07] 그냥 다 Claude가 하는 거야. - 너는 그냥

[00:08] 계속 Claude를 읽고 있었던 거네.

[00:09] 좋아, 알겠어.

[00:14] - 마크.

[00:15] - 안녕하세요, 저는 Alex입니다.

[00:16] Anthropic에서 Claude Relations을 담당하고 있습니다.

[00:18] 오늘은 MCP와 Claude API에 대해 이야기할 예정이고,

[00:22] 제 동료들과 함께하겠습니다.

[00:23] - 안녕하세요, 저는 Michael입니다.

[00:24] Anthropic의 API 팀에서 엔지니어로 일하고 있습니다.

[00:27] - 저는 John이고 Anthropic의

[00:29] Model Context Protocol 팀에서 일합니다.

[00:30] - 오늘 시작하면서,

[00:32] 정말로 MCP가 무엇인지에 대한

[00:34] 전반적인 개요를 제공하고 싶습니다.

[00:36] - MCP는 Model Context Protocol입니다.

[00:39] 모델에 외부 컨텍스트를 제공하는 방법이에요.

[00:44] 만약 당신이 챗봇을 가지고 있고

[00:45] 대화를 하고 있다면,

[00:47] 당신의 대화 기록이 컨텍스트입니다.

[00:48] 모델은 당신이 입력한 모든 것만

[00:51] 볼 수 있는 능력만 가지고 있는데,

[00:53] 이는 일부 종류의 작업에는 정말 유용합니다,

[00:55] 예를 들어, 이 문제를 해결하거나

[00:57] 이것을 작성하는 것을 도와달라고 할 때 말이죠. 하지만 때때로 Claude는

[01:01] 박스 밖의 것들에

[01:02] 접근해야 하는데, 인터넷과 대화할 수 있어야 하거나,

[01:04] 여행사에 연락해서

[01:06] 항공편을 예약할 수 있어야 합니다.

[01:08] 그래서 바로 그런 부분에서 MCP가 등장합니다.

[01:10] Claude에게 이러한 외부 컨텍스트를 제공하여,

[01:12] 외부 세계에서 당신을 대신해

[01:14] 행동을 취할 수 있게 합니다.

[01:16] - 맞아요, 과거에 들었던 좋은 비유가 있는데

[01:18] MCP를 애플리케이션과 모델 사이의 범용 커넥터라고

[01:22] 하는 것입니다.

[01:24] Claude를 다른 모든 것과 연결하는 방법이죠

[01:27] 접근해야 할 수도 있는

[01:28] 모든 다른 데이터 소스, 도구, 모든 것에 말이에요.

[01:31] - 맞아, 확실히.

[01:32] - 인터넷상의 모든 것들 말이에요.

[01:34] 왜 이것을 만들었나요?

[01:35] 의도가 어떤 것이었나요?

[01:36] 이런 연결을 갖는 것이 유용해 보이긴 하지만,

[01:39] 왜 우리가 구체적으로 그것을 맡았고

[01:42] 왜 범용 표준 프로토콜로 만들었나요?

[01:44] - 우리가 도구 사용에서

[01:47] 점점 더 발전해 나가면서

[01:49] Claude의 역량이 커지자,

[01:52] 우리는 깨닫기 시작했습니다

[01:53] 다양한 컨텍스트에서 동일한 기능들을

[01:55] 계속 재구현하고 있다는 것을.

[01:57] 제가 코딩 에디터에서 가지고 있던 어시스턴트는

[02:01] 웹 검색 도구가 연결되어 있어야 했지만,

[02:04] claude.ai도 마찬가지였고

[02:05] Claude가 외부 세계와

[02:07] 상호작용할 수 있기를 원하는

[02:09] 다른 모든 서비스들도 마찬가지였습니다.

[02:10] 그래서 우리는

[02:12] 하나의 통합된 프로토콜을 갖는 것이 좋겠다고 생각했습니다

[02:15] 기능들을 한 번 구현하고 어디서든 가져갈 수 있도록요.

[02:20] 한 번 만들고 어디서든 구성하는 거죠.

[02:22] Claude Code에서 사용할 수 있는 웹 검색 기능이

[02:24] Claude.ai에서 사용하게 될

[02:26] 웹 검색 기능과 동일한 것이 되는 거죠.

[02:29] - 좋습니다, 이해가 됩니다.

[02:30] 기본적으로 범용 호환성을

[02:32] 만드는 거네요

[02:34] 이런 동일한 연결이 필요한 수많은 애플리케이션이 있을 때 말이에요.

[02:37] 이제 오픈 소싱을 통한

[02:39] MCP에 대한 우리의 접근 방식은

[02:42] 꽤 달랐다고 생각하는데,

[02:47] 다른 많은 통합 경로들과 비교했을 때

[02:48] 다른 많은 통합 경로들과는

[02:50] 당시 다른 회사들이 택하던 방식과는 달랐습니다.

[02:53] 왜 오픈소스로 공개하기로 했을까요?

[02:54] 그 결정의 주요 동기는 무엇이었나요?

[02:57] - 오픈 스탠다드에는 많은 가치가 있다고 생각해요.

[03:00] 광범위한 네트워크를 허용하죠.

[03:03] 엔지니어들, 회사들, 개인들이

[03:07] 무언가를 중심으로 생태계를 구축할 수 있게 합니다.

[03:12] 우리는 Claude 앱 커넥터를 만들어서

[03:16] Claude와 연결할 수 있게 할 수도 있었지만,

[03:18] 그렇게 되면 정말로

[03:20] 여러 모델을 사용할 때 사용자 경험이 나빠집니다.

[03:26] 만약 제가 Asana 같은 회사라면

[03:28] 연결하려고 할 때,

[03:30] Claude 커넥터를 구현하고

[03:33] OpenAI 커넥터와 Grok 커넥터

[03:34] Gemini 커넥터까지

[03:35] 모두 구현해야 하는 악몽 같은 상황이 됩니다.

[03:37] 그리고 우리가 주목한 것 중 하나는

[03:40] 모델이 외부 컨텍스트에 접근할 수 있다는 것이

[03:42] 모든 사람에게 좋다는 점입니다.

[03:45] 밀물이 모든 배를 띄운다는 식의 상황이죠.

[03:47] 그리고 우리에게는 내부 프로토콜이 있었는데 정말 가치가 있었어요.

[03:53] 모델 상호작용을 표준화하는 데 말이죠.

[03:55] 그래서 우리는 이것을 오픈소스로 공개했습니다.

[04:00] 우리에게 유용했으니,

[04:02] 세상에도 유용할 것이라고 생각했습니다.

[04:04] 그런데 믿을 수 없을 정도로 빠르게 인기를 얻었어요.

[04:07] 많은 사람들이 같은 필요를 가지고 있었던 것 같습니다.

[04:10] 그들이 뛰어들어서 해킹을 시작했죠.

[04:13] 최소한의 지원만으로도

[04:15] 사람들이 해킹을 시작했고

[04:16] 정말 놀라운 개발 환경을 만들어냈습니다.

[04:18] 그리고 그것이 폭발적으로 성장했죠.

[04:20] 역사상 가장 빠르게 성장한

[04:22] 오픈소스 프로토콜이었다고 생각합니다.

[04:26] - 와. - 정말로

[04:27] 성층권까지 뚫을 정도의 성장이었고

[04:29] 이에 대한 엄청난 수요가 있었습니다.

[04:31] 네, 그래서 오픈소스로 공개했고,

[04:32] 이것이 성공한 이후로는

[04:35] 정말로 우리의 가장 큰 꿈을 넘어섰습니다.

[04:38] 이 작은 사양을 발표했을 때 말이죠.

[04:41] 그리고 이것이 움직이기 시작하면서 많은 작업을 해왔습니다.

[04:44] Anthropic을 위한 깔끔한 방법에서

[04:47] Anthropic의 프로젝트에서

[04:48] 모델에 컨텍스트를 제공하는 것에서

[04:50] 산업을 정의하는 표준 같은 생태계로 변화시켰습니다.

[04:54] 우리는 많은 작업을 통해

[04:55] 이것을 적절한 오픈소스 재단으로 이동시켰고

[04:59] 다른 모든 제공업체와 협력하여

[05:01] MCP를 지속 가능하고

[05:04] 장기적으로 유지될 수 있는 것으로 만들었습니다.

[05:06] - 현재 MCP의 현황은 어떤가요?

[05:08] 오픈소스 커뮤니티 측면에서도

[05:10] 기술적 사양 자체 측면에서도 말이죠?

[05:13] 처음 발표한 지 거의 1년,

[05:16] 1년이 채 안 된 것 같은데요.

[05:18] 많은 사람들이 아직도

[05:21] 올해 초, 2025년 초 정도의 상황에 기반한

[05:25] 직감을 가지고 있는 것 같아요.

[05:26] 하지만 프로토콜이 너무 빠르게 발전하고 있고 상황이 변하고 있어요.

[05:29] 여러분이 생각하는 MCP의 현재 상태는 어떤가요?

[05:33] - 적어도 제게는 큰 깨달음의 순간이었는데,

[05:36] 원격 MCP 지원을 출시했을 때였습니다.

[05:39] 프로토콜의 초기 특이점들 중 일부는

[05:41] 사실상 모든 것을 스스로 실행해야 한다는 것이었는데,

[05:45] 이것이 Asana 같은 MCP 서버 제공업체들이

[05:49] 자체 서버를 호스팅하는 것을 막았습니다.

[05:52] 매우 빠르게 접근할 수 있었던 것들이었어요.

[05:54] 그리고 설정 과정이 매우 복잡하고 번거로웠죠.

[05:58] 제 생각에는, 정말 큰 변화였던 것이

[06:01] 제 의견으로는,

[06:02] 우리가 원격 호스팅 MCP 서버에 대한

[06:04] 1차 지원을 제공했을 때였어요.

[06:06] 이것이 프로세스를 극적으로 줄여서,

[06:09] 최종 사용자들이 꽤 빠르게 시작할 수 있게 되었어요.

[06:12] - 그리고 이제 우리는 이런 서버들의 레지스트리를 가지고 있어서,

[06:14] 사람들이 실제로 이것들을 레지스트리에 업로드할 수 있고

[06:17] 저희가 승인하거나 검토해서-

[06:21] - 네, 맞아요.

[06:21] 오픈소스 프로젝트에서

[06:27] 저희가 방금 출시한 것이

[06:28] MCP 서버들의 중앙 레지스트리입니다.

[06:32] 오픈소스 정신에 따라서,

[06:34] 저희는 레지스트리를 가지고 있고

[06:36] 그것이 호스팅되는 곳은

[06:37] 모델 컨택트 프로토콜 조직 사이트입니다.

[06:40] 또한 다른 조직들이 레지스트리를 확장하고

[06:43] 그 정보를 가져올 수 있는 표준도 있어요.

[06:48] 그리고 우리는 MCP의 엄청난 성장을 보고 있습니다.

[06:52] GitHub MCP, Asana MCP,

[06:56] 많은 회사들이

[06:57] 이런 엔드포인트들을 구축하고 배포하고 있어요.

[07:00] 그래서 이것을 가져오는 것이 더 쉬워지고 있습니다.

[07:05] 과거에는 가서

[07:08] GitHub와 상호작용하고 싶다면,

[07:10] 어떤 무명 개발자를 찾아야 했고

[07:13] 그들이 급조한 GitHub 커넥터를

[07:15] 그리고 컴퓨터에 있는 그들의 Node.js 설치를 신뢰해야 했어요.

[07:19] 그런데 이제는

[07:20] 공식 GitHub 사이트에 가면 됩니다.

[07:24] mcp.github.com이라고 생각하는데,

[07:26] 그것을 Claude Code나 Claude.ai에 넣으면

[07:29] Claude를 확장하여

[07:31] GitHub와 상호작용할 수 있게 됩니다.

[07:33] 정말 멋진 방향으로 발전하고 있어요.

[07:35] - 정말 멋지네요.

[07:36] 저도 GitHub MCP를 사용하고 있어요

[07:37] Claude Code에서 여러 가지들에 대해서요.

[07:39] 하나의 엔드포인트만 연결하면 되는 것이 좋네요.

[07:42] 그냥 연결하면 되거든요.

[07:43] 지금 레지스트리에 있거나 레지스트리 밖에

[07:46] 재미있고 독특한 MCP가 있나요?

[07:48] 여러분이 본 것 중에서요?

[07:50] - 제가 생각하기에

[07:52] 정말 흥미롭게 지켜본 것 중 하나는

[07:55] Context 7이라고 불리는 것입니다.

[07:57] 대형 언어 모델의 가장 큰 제약 중 하나는

[07:58] 지식 컷오프가 있다는 것입니다

[08:00] 보통 몇 달 정도 지연되는데,

[08:01] 이는 소프트웨어 개발자로서 최신 패키지로 작업하는 것이

[08:05] LLM으로는

[08:06] 때로는 어렵다는 뜻이에요.

[08:09] 왜냐하면 구식 정보를 줄 수 있거든요.

[08:10] Context 7이 하는 일은

[08:13] 이런 웹사이트들에서 문서를 가져오는 것을 처리하는 것입니다

[08:16] Next.js 웹사이트나

[08:19] 심지어 우리 자체 API 웹사이트에서도

[08:21] 그리고 그것들을 최신 상태로 유지합니다.

[08:24] 그리고 해야 할 일은

[08:25] MCP 연결을 한 번만 구성하면

[08:27] Claude가 접근할 수 있게 됩니다

[08:29] 거기에 있는 최신 정보에

[08:31] 당신이 개발하고 있는 무엇이든지에 대해서요.

[08:33] - 음, 알겠어요.

[08:35] 네, 그것에 대해 들어본 것 같아요.

[08:36] 기본적으로 최신 문서, 모든 것을 가져오는 것이고,

[08:39] 지금 우리도 중간 전환기에 있다고 알고 있어요

[08:42] 많은 사람들이 문서를 완전히 원시 텍스트로 만들고

[08:45] LLM이 접근할 수 있게 하는 것의.

[08:46] 그래서 같은 종류의 정보에서

[08:49] 가져오는 것으로 추정됩니다.

[08:50] - 네, 이건 llms.txt 형식과 같은 것으로,

[08:54] 기술 업계 전반에서 많은 채택을 보고 있어서

[08:57] 매우 흥미로운 현상입니다.

[08:58] - 멋지네요.

[08:59] John은 어떤가요?

[09:00] - 제 입장에서는,

[09:01] 소프트웨어 개발자로서 일하면서

[09:04] 유용하다고 생각한 건

[09:06] Playwright MCP 서버입니다.

[09:10] 이를 통해 Claude가 브라우저와 상호작용할 수 있어서

[09:14] 사용자가 클릭하는 것처럼 동작할 수 있습니다.

[09:18] 웹사이트 작업을 할 때,

[09:19] Claude는 CSS와 HTML을 모두 읽을 수 있지만

[09:22] 실제로 웹페이지를 볼 수는 없습니다.

[09:25] 하지만 Playwright MCP 서버를 설치하면

[09:26] Claude가 웹페이지를 실제로 보고

[09:29] 더 아름답게 만드는 방법이나

[09:32] 정렬 문제를 수정하는 조언을 줄 수 있습니다.

[09:36] - 실제 스크린샷을 찍는 건가요?

[09:38] - 네, 실제로 브라우저에서 로딩해서

[09:39] Playwright를 사용해 브라우징합니다.

[09:42] 원격 브라우저 구동을 가능하게 하는

[09:44] 마이크로소프트 프로젝트입니다.

[09:49] - Claude Code 같은 걸로 루프를 돌리면

[09:50] 어떻게 될까요?

[09:52] - 자기 개선 루프를 만들 수 있습니다.

[09:53] Claude Code에게 헤더의 정렬 문제를 수정하라고 하면

[09:56] HTML을 수정하고

[09:58] CSS를 변경한 다음

[10:01] 필요하면 페이지를 새로고침하고

[10:04] 다시 확인해서

[10:06] '아, 모든 게 더 나아 보인다'거나

[10:08] '이건 고쳐지지 않았네'라고 판단할 수 있습니다.

[10:10] 그리고 자신이 만든 변경사항과

[10:12] 실제로 웹사이트 스크린샷을 찍을 수 있는

[10:14] 상황을 모두 파악해서

[10:16] '이 CSS 변경이 의도하지 않은

[10:18] 효과를 만들었네. 이걸 되돌리고

[10:20] 다른 방법을 시도해보자'라고 할 수 있습니다.

[10:23] - 다른 종류의 정렬 문제군요.

[10:25] - 네, CSS 정렬 문제는

[10:27] 더욱 어려운 문제일 수도 있습니다.

[10:30] 주제를 조금 바꿔서,

[10:32] 개발자가 Claude API를 사용하려고 한다면

[10:34] API와 Claude 모델에서 MCP를 어떻게 활용할 수 있을까요?

[10:38] - 아주 좋은 질문입니다.

[10:40] 표준적인 방법은 MCP SDK를 설치하고

[10:44] Claude Code처럼 자체 루프를 설정해서

[10:46] 필요한 MCP 서버에 연결하는 것입니다.

[10:48] 하지만 본질적으로 소프트웨어 개발자가

[10:53] 모든 연결 작업을 직접 처리해야 합니다.

[10:55] 물론 잘 작동하긴 하지만요.

[10:57] 하지만 최근에 API에 직접

[10:59] 네이티브 기능으로 출시한 것이

[11:01] MCP 커넥터 기능입니다.

[11:04] 이를 통해 mcp.github.com 같은

[11:06] 원격 MCP가 어디에 있는지만 지정하고

[11:09] 필요한 인증 정보를 제공하면

[11:12] 도구를 실행하고

[11:14] 결과를 모델에 다시 전달하는

[11:18] 호출 루프를 저희가 처리해 드립니다.

[11:21] 따라서 '최신 풀 리퀘스트를 가져와줘'라는

[11:24] 단일 API 호출만 보내면

[11:26] 나머지는 알아서 처리해 드립니다.

[11:28] - 정말 좋네요.

[11:31] 많은 개발자들이 이제 더 이상

[11:33] 그런 왔다갔다하는 작업을 직접 처리할 필요가 없어서

[11:36] 수많은 코드를 삭제할 수 있게 되었다고 들었습니다.

[11:36]

[11:45] URL과 엔드포인트만 전달하면

[11:47] 거의 완성되는 거죠.

[11:51] MCP를 사용하는 개발자들에게 다른 팁이 있나요?

[11:54] 제가 이야기할 때 개발자들에게 가장 강조하는 것은

[11:58] MCP 서버와 도구들이

[12:03] 본질적으로는 프롬프트라는 점입니다.

[12:05] 그래서 우리가 깨달은 것은

[12:07] AI 기반 애플리케이션을 작성할 때는

[12:10] 신중하고 정확하게

[12:12] 언어를 사용하는 것이 정말 중요하다는 것입니다.

[12:13] 모델에게 프롬프트할 때 말이죠.

[12:15] 이는 MCP 서버를 정의하는 모든 것에 적용됩니다.

[12:20] 도구 이름을 적절하게 정의하고,

[12:23] 설명을 제공하는 것까지요.

[12:25] 설명에 몇 가지 간단한 예시를

[12:28] 사용법과 함께 포함시키거나,

[12:30] 적절한 매개변수 이름을 주는 것입니다.

[12:32] 이 모든 것들이 MCP 서버와

[12:36] 상호작용할 때 모델의 행동에 영향을 줍니다.

[12:38] 제가 겪었던 예시는

[12:40] 이미지 생성 서버를 만들 때였는데

[12:41] 'Generate Image'라는 도구가 있었고,

[12:43] 'Description'이라는 필드만 있었습니다.

[12:47] 그러면 Claude에게

[12:48] '귀여운 강아지 이미지를 생성해 줘'라고 하면

[12:50] 도구를 호출해서

[12:52] 'Description: 귀여운 강아지'라고 하죠.

[12:55] 좋습니다.

[12:56] 하지만 이것을 바꿔서

[12:57] 이렇게 말한다면

[12:59] '이 도구는 XXX 디퓨전 모델 Y 버전을 호출하며

[13:04] 최상의 결과를 위해 이런 스타일로 프롬프트해야 합니다'

[13:10] 이런 종류의 설명적 언어를 사용하고,

[13:12] 이 모든 것을 하세요.

[13:13] Claude는 이러한 시스템과

[13:14] 상호작용하는 방법에 대한 정보를 가지고 있고

[13:16] 단지 알려주기만 하면 됩니다.

[13:18] '아, 좋다, 내가 지금 디퓨전 모델과 대화하고 있구나,

[13:20] 언어를 바꿔보자,

[13:21] 이 프롬프트에서 사용할 것들을 바꿔보자'라고 하고,

[13:22] 귀여운 강아지를 요청하는 대신

[13:25] 훨씬 더 자세한

[13:28] 디퓨전 모델 프롬프트를 제공해서 훨씬 좋은 결과를 줄 겁니다.

[13:31] MCP 서버에서 훨씬 좋은 결과를 얻을 수 있습니다

[13:34] 설명이나 프롬프트 이름에서 몇 단어만 바꿔도

[13:37] 말이죠.

[13:39] 풀 리퀘스트를 작성하거나

[13:41] Claude와 함께

[13:42] 어떤 종류의 지식 작업을 할 때

[13:44] 그런 것들을 조정해서 더 나은 결과를 얻는 것과 똑같습니다.

[13:47] 저 자신도 항상 잊곤 하는데

[13:49] 도구나 어떤 종류의 설명을

[13:52] 독립적으로 다룰 때

[13:54] 새로운 기능을 작업하면서

[13:56] AI 앱을 위해서 말이죠

[13:59] 그것이 모두 같은 프롬프트로 다시 끌어당겨진다는 것을, 맞죠?

[14:02] 결국 하나의 텍스트 문자열처럼

[14:05] 각 요청마다 모델에 전달되는 것입니다.

[14:07] 그리고 네, 그것은 좋은 조언입니다

[14:09] '그것도 프롬프트의 일부다'라는

[14:11] 코드 어딘가의 JSON에

[14:13] 작성하고 있는 설명도 여전히

[14:15] Claude에게 보내지는 같은 프롬프트로

[14:18] 끌어당겨질 것입니다.

[14:20] 컨텍스트 관리에 대해서도 조금 이야기해보죠

[14:23] 그리고 많은 도구들과 많은 결과를 처리하는 것에 대해서요.

[14:25] 이것은 현재 LLM들에게 큰 문제입니다

[14:28] 컨텍스트를 오염시키는 측면에서 말이죠.

[14:30] MCP와 함께 개발자들이

[14:31] 어떻게 생각해야 하는지에 대한 생각이 있는지 궁금합니다.

[14:35] 네, 많은 개발자들이 저지르는 큰 안티패턴이 있다고 생각합니다

[14:39] 개발자들이 MCP 서버나 API 요청에 너무 많은 도구들을

[14:43] MCP 서버와 함께 무작정 넣어버리는 것입니다

[14:46] 또는 너무 많은 MCP 서버들을 연결하는데,

[14:48] 이는 비용 측면에서도 문제가 될 뿐만 아니라,

[14:49] 추가하는 모든 것에 대해 토큰을 생성하기 때문에

[14:51] 비용이 증가하게 되고,

[14:53] 또한 모델을 혼란스럽게 만드는 경향이 있습니다.

[14:55] 예를 들어 Linear와

[14:59] Asana 작업 관리 MCP 서버를 동시에 연결했을 때,

[15:02] 같은 요청에서

[15:03] 둘 다 '프로젝트 상태 조회' MCP 도구를 가지고 있을 수 있는데,

[15:08] 모델은 어떤 상황에서 어떤 것을 사용해야 하는지에 대한

[15:11] 명시적인 정보를 가지고 있지 않습니다.

[15:13] 하지만 그것을 넘어서,

[15:15] 네, 본질적으로 모델을 혼란스럽게 만드는 것이죠

[15:17] 잠재적으로 상충되는 정보를 제공함으로써 말입니다.

[15:19] 따라서 어떤 도구를 추가할지에 대해 매우, 매우 신중하고 결정적으로

[15:23] 접근해야 하고,

[15:25] 그 도구들의 사용성이

[15:27] 이해가 되는지,

[15:28] 그리고 그 도구들을 사용하는 것이 자연스럽게 느껴지는지

[15:30] 확인해야 합니다. 만약 여러분이 직접 사용한다면 말이죠.

[15:33] 그 외에도 확실히 해야 할 것은,

[15:36] 네, 현재 사용자 프롬프트의 턴에

[15:38] 반드시 도움이 되지 않을 수도 있는 정보는

[15:41] 포함하지 않는 것입니다.

[15:42] 때로는 대화의 이전 부분들이

[15:45] 매우 기초적인 정보를 포함할 수 있는데,

[15:47] 예를 들어, '오늘 날씨가 어때?'와 같은 것들이

[15:50] 대화가 훨씬 나중에 진행될 때는 그다지 관련성이 없을 수 있습니다

[15:52] 대화에서

[15:53] 최신 뉴스로 이동하거나

[15:56] 모델로부터 필요한 다른 정보로 넘어갈 때 말입니다.

[15:58] - 음, 저는 종종 이런 질문을 받습니다,

[16:00] Claude에 몇 개의 도구를 전달할 수 있나요?

[16:02] 또는 한 번에 몇 개의 MCP 서버를 연결할 수 있나요?

[16:05] 그리고 이것은 숫자의 문제가 아닌 것 같고,

[16:09] 오히려 도구들이 서로 얼마나 구별되는지와

[16:12] 얼마나 잘 정의되고 범위가 설정되어 있는지의 문제인 것 같습니다.

[16:14] 맞나요?

[16:15] 아니면 MCP의 절대적인 개수도 있는 건가요?

[16:19] - 저는 절대적인 개수도 결국 있다고 생각합니다.

[16:23] 컨텍스트 윈도우가 X 토큰이라면,

[16:25] 각 서버는 여러 개의

[16:28] 함수 정의를 가져올 것입니다.

[16:29] 각각이 토큰을 소모할 것이고요.

[16:30] 그래서 점점 시작하게 될 것입니다.

[16:34] LLM에게 더 많은 정보를 제공할수록,

[16:36] 좋은 결정을 내리기가 더 어려워집니다.

[16:38] 그래서 여러 서버에 연결해도 아마 작동할 수는 있겠지만,

[16:42] 여러 서버에 연결하더라도,

[16:44] Claude에게 현재 작업하고 있는 태스크와 관련된

[16:47] 부분집합을 제공할 수 있다면 더 잘 작동할 것입니다.

[16:49] Michael이 말한 것에서 나오는 또 다른 포인트는

[16:51] MCP 서버를 설계할 때,

[16:56] 일반적으로 서버에 하나 또는 두 개의 도구가 있는 것이

[17:00] 15개나 20개의 도구를 갖는 것보다

[17:04] 모델에 훨씬 도움이 될 것입니다.

[17:06] 그래서 때로는

[17:11] MCP 인터페이스 개발은

[17:14] API 개발과는 조금 다릅니다

[17:17] 우리가 이것들을 LLM에 제공하기 때문입니다.

[17:18] 그리고 도구에 자연어를 받을 수 있는

[17:22] 설명을 제공하거나

[17:24] 매개변수를 채우는 과정의 일부로 포함시키면,

[17:26] 모델이 몇 가지 결정을 내리고

[17:27] 텍스트를 생성할 것이고, 아마 다음과 같이 할 수 있을 것입니다

[17:31] API에서는 이렇게 하겠지만,

[17:33] 프로젝트 가져오기, 포스트 가져오기, 사용자 가져오기와 같이.

[17:36] 단지 정보 가져오기 도구 하나만 가질 수도 있습니다.

[17:41] 왜냐하면 호출하는 LLM이

[17:43] 여러분의 설명을 보고

[17:45] 필요한 정보를 자동으로 채워줄 수 있습니다.

[17:47] 이렇게 하면 훨씬 더 작은 도구 세트를 제공할 수 있고,

[17:51] 다른 MCP 서버들과 더 잘 호환되며

[17:53] 여러분의 서버가 더 효율적으로

[17:56] 적절하게 호출될 수 있습니다.

[17:57] 맞아요, 항상 일대일 대응은 아니죠.

[18:00] 적용할 수 있는 추상화 레벨이 여러 가지 있고

[18:03] API 명세서가 모델이 받아들이기에 가장 잘 정의된 것이

[18:08] 아닐 수도 있죠.

[18:12] 여러분은 매일 MCP를 다루고 계시는데,

[18:14] 기본적으로 모든 일상이 그렇죠.

[18:16] 직장에서든 집에서든 사이드 프로젝트든

[18:18] 실제로 어떻게 활용하고 계신가요?

[18:23] Playwright 예시 말고도

[18:24] 개인적으로

[18:25] MCP로 실험하고 있는 다른 방법들이 있나요?

[18:27] 개인적으로 가장 큰 활용 사례는

[18:29] Anthropic이 정보의 고속도로 같다는 점이에요.

[18:32] Slack, 문서, 코드베이스에

[18:35] 정말 많은 정보가 흩어져 있는데

[18:38] 제가 현재 진행 중인 프로젝트의

[18:41] 최신 상태를 파악하는 것이 단일 소스만으로는

[18:44] 이해하기가 쉽지 않아요.

[18:47] 그래서 제가 습관적으로 하는 것은

[18:49] Claude AR이나 Claude 코드에서

[18:52] 이 모든 위치들에 연결되도록

[18:54] MCP 서버를 설정하고

[18:55] 이렇게 요청해요.

[18:57] "여기 제가 이전에 작성한 프로젝트 업데이트

[19:00] 예시들이 있는데,

[19:01] 지난 주 정보를 찾아서

[19:04] 똑같은 형식으로 상태 업데이트를 생성해 줄 수 있어?"

[19:08] 그리고 그 성공률이

[19:11] 원래 생각했던 것보다 훨씬 높아요.

[19:13] 그럼 제가 Slack에서 읽는 당신의 상태 업데이트는

[19:16] 모두 Claude가 생성한 건가요?

[19:17] 네, 저는 이제 실제로 아무것도 쓰지 않아요.

[19:20] 모두 Claude예요.

[19:21] 그동안 Claude를 읽고 있었던 거네요.

[19:22] 알아서 다행이네요.

[19:24] John은 어떠세요?

[19:25] 집 하드웨어를 해킹하면서 몇 가지 관점을 발견했어요.

[19:30] 홈 네트워크에서

[19:31] MCP 서버를 실행해서 집안 기기들을 제어할 수 있어요.

[19:35] 그래서 Claude와 대화하면서

[19:38] "오늘 아침에 문 잠그는 걸 깜빡했나?"

[19:40] 라고 물어보면 Claude가 "네, 현재 문이 열려 있어요.

[19:45] 제가 잠가드릴까요?"

[19:48] 라고 하면

[19:49] "네, 그렇게 해주세요"라고 답할 수 있어요.

[19:53] 이런 식으로 사용하는 것이 정말 유용하고

[19:55] 재미있기도 해요.

[19:56] 미래 세계가 어떨지에 대한

[19:58] 미리보기 같은 느낌이 들어요.

[20:03] MCP 서버에는 어떤 마법 같은 느낌이 있는데

[20:07] 서버를 추가할 때 예상하지 못했던

[20:10] 창발적 속성들이

[20:12] 나타나기 때문입니다.

[20:18] 예를 들어

[20:21] MCP 서버를 처음 시작했을 때

[20:23] Anthropic의 동료들과 함께 지식 그래프 서버를 구축했어요.

[20:28] 지식 그래프라는 것은?

[20:31] 지식 그래프는 Claude에게

[20:32] 기억을 저장하고

[20:35] 기억들 간의 연결을 형성할 수 있는

[20:38] 능력을 제공하는 것입니다.

[20:40] 두 가지 도구가 있는 MCP 서버예요.

[20:43] 기억 생성 도구와

[20:44] 그리고 기억을 다른 기억과 연결하는 도구가 있었죠

[20:47] 가장 간단한 인터페이스였어요

[20:49] 그리고 이걸 Claude에 연결했어요

[20:51] 그러자 갑자기 Claude와 대화를 나누면

[20:54] Claude가 탐사 기자 모드로 들어가더라고요

[20:56] 제가 "저는 피아노를 쳐요"라고 말하면

[20:59] Claude가 이렇게 말하죠

[21:00] "멋지네요, 무엇을 연주하는 걸 좋아하세요?"

[21:02] 그리고 제가 "라흐마니노프를 좋아해요"라고 하면

[21:04] "혹시 그 중에서도

[21:06] 특별히 좋아하는 곡이 있나요?"라고 묻더라고요

[21:07] 그래서 지식 그래프를 보면

[21:09] Claude가 가서 메모를 적으면서

[21:11] "사용자는 세련된 클래식 음악 취향을 가지고 있다"

[21:13] 라고 적고, 악기 연주에 능숙하다고 찾아내려 해요

[21:17] 이 모든 게 당신이 제공한 아주 작은 변화에서 나온 거예요

[21:22] 정말 멋진 점 중 하나는

[21:24] MCP를 프로토콜로 가지고 있어서

[21:26] Gmail 서버와 함께

[21:30] 홈 자동화 서버를 연결하면

[21:33] 아마도 Claude가 가서 당신이 요청한 문제를

[21:37] 어떤 방식으로든 해결해낼 수 있고

[21:39] 이 둘을 연결해서

[21:40] 당신이 생각지도 못한 방법으로 말이죠

[21:41] 맞아요, 이런 애매한 중간 지점이 있죠

[21:44] 이 모든 것들이 서로 연결될 때

[21:46] Claude의 일반적인 지능과 결합하면

[21:49] 흥미로운 일들이 일어날 수 있어요

[21:52] 이게 MCP와

[21:54] 기존 구조화된 API들 간의 핵심적인 차이 중 하나예요

[21:58] 모든 게 너무 유연하고

[22:01] LLM들이 충분히 똑똑해서

[22:03] 그냥 모든 걸 잘 조합해내니까

[22:05] 계약서 같은 건 그렇게 중요하지 않아요

[22:07] 흥미로운 특성이 있는데

[22:09] 제가 Gmail과 상호작용하는 MCP 서버가 있고

[22:13] 그다음에 가서 평가를 해보고

[22:17] Gmail과 상호작용하기 위한

[22:19] 더 나은 도구와 설명 세트를 찾았다면

[22:21] 설명이 있는 15개 도구에서

[22:23] 다른 설명이 있는 2개 도구로 바꿨을 때

[22:25] 새 버전의 API를 배포할 필요가 없어요

[22:27] 그런 식으로 API를 대규모로 변경한다면

[22:28] 호환성 문제를 다뤄야 하죠

[22:30] 호환성 문제, 사용자와 소통, 이런 모든 걸

[22:32] MCP는 그냥 배포할 수 있어요

[22:35] MCP의 목적이

[22:36] Claude가 Gmail과 상호작용할 수 있게 하는 거니까

[22:38] 이메일 읽기 도구와

[22:40] 이메일 쓰기 도구를 제공하는 건 아니잖아요

[22:44] 정말 멋진 일이죠

[22:45] 네, 더 높은 수준의 의도와

[22:46] 액션에 관한 것이지

[22:50] 어떻게 거기에 도달하는지의 구체적인 기술적 세부사항이 아니라는 거죠

[22:53] 네, 맞아요

[22:55] 정말 멋지네요

[22:58] 그래서 앞으로 어떻게 될까요?

[22:59] 6개월, 12개월,

[23:01] 1년 후에 MCP는 어떻게 될까요?

[23:04] 흥미로운 질문이네요

[23:05] 제가 항상 생각해왔던 건

[23:06] John이 말했듯이 MCP는 프로토콜이라는 거예요

[23:09] 프로토콜의 인기를 보는 건 정말 흥미로워요

[23:13] 왜냐하면

[23:15] MCP가 성공하고 저희와 MCP를 통합하는 모든 사람이

[23:19] 제대로 일을 했다면

[23:21] MCP가 뒤에서 동작하고 있다는 걸 전혀 몰라야 하거든요

[23:24] 그냥 당신이 사용하는 프로그램이나

[23:27] 앱을 사용하는 것만 있어야 하고

[23:29] MCP는 뒤에서 작동하면서

[23:30] 모든 걸 연결해주는 역할을 해야죠

[23:32] 그리고 LLM이 모든 것을 구성하고,

[23:34] 여러분은 단지 필요한 팔과 다리를 제공하는 것뿐입니다.

[23:36] 그게 전부죠.

[23:36] 하지만 네, MCP를 둘러싼 관심이

[23:39] 항상 흥미로웠어요.

[23:41] - 맞아요, 그런 관심이 계속될 것 같나요?

[23:44] 여기서 정체기가 있을까요,

[23:46] 프로토콜 측면에서 실제로 어떤 모습일까요?

[23:49] MCP를 판단할 수 있는

[23:52] 어떤 선례가 있을까요?

[23:54] - 우리가 살고 있는 AI 세계에서

[23:56] 어떤 것에든 선례를 적용하기는 어렵다고 생각하지만,

[23:59] 확실히 John과 MCP 팀의 동료들이

[24:03] 하고 있는 많은 일들을 보면

[24:05] 정말 흥미진진해요.

[24:06] 그리고 제게는 크고 작은 회사들이

[24:10] 테이블에 와서

[24:12] 어떻게 이것을 확산시키고

[24:14] 인터넷처럼

[24:16] 어디에나 있는 보편적인 것으로 만들 수 있는지

[24:19] 이야기하는 것을 보는 게 놀라웠어요.

[24:21] - 앞으로 제게 정말 흥미진진한 한 가지는

[24:25] 지금 우리가 많은 사람들이

[24:26] MCP의 가치를 깨닫고

[24:29] 이런 서버들을 작성하기 시작한 지점에 있다는 거예요.

[24:31] 하지만 MCP 서버를 프롬프트에 비유한다면,

[24:35] 우리는 아직 초기 단계에 있어요.

[24:37] 그래서 사람들이 이제 이런 서버들을 구축하기 시작했으니

[24:40] 이것들이 어떻게 작동하는지 평가하고

[24:42] 더 나은 것으로 만들기 시작하는 것이 정말 기대돼요.

[24:47] 그리고 업무를 위한 벤더를 평가하는

[24:51] 지표가 되기 시작하는 것이 기대돼요.

[24:55] 만약 제가 누군가에게

[24:58] 로그 분석을 위해 비용을 지불한다면,

[25:01] 정말 멋질 것이고, 제게 정말 가치 있는 일은

[25:04] 그들의 로그 분석 MCP 서버를

[25:07] 제 Claude에 연결해서 "제 사이트가 다운됐어요,

[25:10] 무슨 일이죠?"

[25:11] 라고 말할 수 있는 거예요.

[25:13] 그리고 그들이 정말 훌륭한

[25:16] MCP 서버를 설계하고 개발해서

[25:18] Claude가 그들의 서비스와

[25:20] 상호작용하고

[25:22] 답을 찾는 데 필요한 도구를 제공한다면,

[25:25] 엔지니어인 저에게는 엄청난 셀링 포인트가 되죠.

[25:27] 그러면 이 기능에 의존할 수 있거든요.

[25:28] 제가 직접 구축할 필요가 없어요.

[25:31] 그리고 이것이 더 성숙해지기 시작하는 것이 기대돼요.

[25:33] MCP 서버를 출시했다는 것만으로

[25:36] 흥미진진한 것보다는 사람들이

[25:38] "우리가 최고의 MCP 서버를 가지고 있어요.

[25:39] 이것이 당신의 삶을 훨씬 쉽게 만들어줄 거예요.

[25:42] 저희를 사용해야 해요.

[25:43] 우리가 Claude와 이런 식으로 상호작용하니까요."

[25:46] 라고 경쟁하기 시작하는 것을 보고 싶어요.

[25:49] - 저도 그런 미래가 기대됩니다.

[25:50] 출연해 주셔서 감사합니다.

[25:51] 정말 좋았어요. - 감사합니다. - 정말 감사합니다.