MCP(Model Context Protocol)란 AI 모델이 외부 도구와 효율적으로 통신할 수 있도록 하는 혁신적인 표준 프로토콜입니다.
2025년 현재 MCP 구조는 클라이언트-서버 아키텍처를 기반으로 하며, Anthropic이 주도한 이 프로토콜은 AI 에이전트의 능력을 획기적으로 확장시킵니다.
MCP 공동 창작자인 David Soria Parra와 Justin Spahr-Summers 가 출현한 팟캐스트에서의 대화를 기반으로 MCP의 핵심 철학과 실제 구현 방법을 상세히 다룹니다.
MCP Model Context Protocol 이 어떻게 기존의 한계를 극복하고 새로운 가능성을 열어가는지, 그리고 개발자들이 실제로 어떻게 활용할 수 있는지 알아보겠습니다.
📑 목차
https://www.latent.space/p/mcp
The Creators of Model Context Protocol
MCP's coauthors on the origin, challenges and future of the protocol.
www.latent.space
참조한 팟캐스트 링크!
근본적인 문제의식과 해결책 고민
MCP의 시작은 의외로 단순한 불편함에서 비롯되었습니다.
2024년 7월경, David Soria Parra와 Justin Spahr-Summers는 Claude Desktop과 IDE 사이를 끊임없이 복사-붙여 넣기 하는 작업에 좌절감을 느끼고 있었습니다.
David는 이렇게 회상합니다
From my development tooling background, I quickly got frustrated by the idea that, you know, on one hand side, I have Claude Desktop, which is this amazing tool with artifacts, which I really enjoyed. But it was very limited to exactly that feature set. And it was there was no way to extend it.
제 개발 도구 경험 관점에서 말하자면, 저는 곧바로 이렇게 답답함을 느꼈습니다.
한편으로는 아티팩트를 다루는 훌륭한 도구인 Claude Desktop이 있었지만, 그 기능 세트에만 딱 제한되어 있었고, 확장할 방법은 전혀 없었거든요.”
이들이 주목한 것은 전형적인 M × N 문제였습니다.
And so it's very quickly that you see that this is clearly like an M times N problem. Like you have multiple like applications. And multiple integrations you want to build and like, what that is better there to fix this than using a protocol.
그래서 곧바로 이 상황이 명백히 M×N 문제라는 걸 알 수 있습니다.
여러 애플리케이션이 있고, 거기에 여러 가지 통합을 구축해야 하는데, 이를 해결하는 데 프로토콜을 사용하는 것보다 더 나은 방법이 있을까요?
여기서 의미하는 N times N problem 란?
M개의 애플리케이션과 N개의 서비스/시스템이 있을 때, 각각을 직접 연결하려면 M × N개의 개별 통합을 구축해야 하는 문제입니다.
5개 애플리케이션 × 4개 외부 API = 20개의 서로 다른 통합 코드
각각 다른 인증, 데이터 형식, 에러 처리 방식
LSP을 모티브로..
MCP의 설계에 영향을 준 것은 Language Server Protocol(LSP)입니다
we definitely did take heavy inspiration from LSP. David had much more prior experience with it than I did working on developer tools... LSP largely, I think, solved this problem by creating this common language that they could all speak
우리는 분명히 LSP에서 많은 영감을 받았습니다.
David는 제가 개발 도구 작업을 하기 훨씬 이전부터 LSP에 대한 경험이 풍부했어요… LSP는 본질적으로 ‘모두가 공통으로 이해할 수 있는 언어’를 만들어 줌으로써 이 문제를 대부분 해결했다고 생각합니다.
LSP가 IDE와 언어 서버 간의 통신을 표준화한 것처럼, MCP는 AI 애플리케이션과 외부 시스템 간의 통신을 표준화하고자 했습니다.
하지만 단순한 복제가 아닌, 추가적인 아이디어를 더했습니다.
MCP의 주요 설계 철학과 아키텍처
1. 애플리케이션 개발자 우선 설계
I think fundamentally we every sort of primitive that we thought through, we thought from the perspective of the application developer first
근본적으로 저희는 모든 종류의 프리미티브(primitives)에 대해 고민할 때, ‘애플리케이션 개발자 관점’에서 먼저 생각했습니다.
MCP 팀은 모든 설계 결정을 내릴 때 한 가지 질문을 먼저 던졌습니다.
IDE를 만들든, 데스크탑 애플리케이션을 만들든, 에이전트 인터페이스를 만들든, 어떤 애플리케이션이든 통합 기능을 통해 무엇을 받고 싶을까?
이런 관점으로 보면 도구 호출(tool calling)이 필요하다는 것은 분명 해지지만, 그것만으로는 여전히 아주 불충분하다는 사실 또한 명확해집니다. (상태 관리, 이벤트, 스트리밍, 확장 등의 주요 요구사항 충족이 힘들 수 있음)
Like there are many other things you would want to do besides just get tools. And plug them into the model and you want to have some way of differentiating what those different things are
모델에 단순히 도구를 가져다 연결하는 것 외에도 하고 싶은 일이 많이 있고, 그 서로 다른 일들이 무엇인지 구분할 수 있는 방법도 필요합니다.
2. MCP의 3가지 핵심 primitive
So the kind of core primitives that we started MCP with, we've since added a couple more, but the core ones are really tools, resources, and prompts
우리가 MCP를 시작할 때 정의한 핵심 프리미티브는 이렇습니다. 이후 몇 가지를 더 추가하기는 했지만, 진정한 핵심은 ‘도구(tools)’, ‘리소스(resources)’, ‘프롬프트(prompts)’ 세 가지입니다.
Tools - 모델 주도적 기능
Tools는 모델이 직접 호출할 수 있는 실행 가능한 함수
The way we separate these is like tools are always meant to be initiated by the model. It's sort of like at the model's discretion that it will find the right tool and apply it.
이들 간을 구분하는 방식은 이렇습니다. Tool은 언제나 모델이 직접 호출하도록 설계되어 있습니다.
즉, 모델의 판단(model’s discretion)에 따라 적절한 Tool을 찾아서 실행하는 구조인 것이죠.
Resources (리소스) - 유연한 데이터 접근
Resources는 애플리케이션이나 사용자가 제어할 수 있는 데이터 조각
resources, which is basically like bits of data or context that you might want to add to the context... this is the first primitive where it's like, we decided this could be like application controlled
리소스(resources)’는 기본적으로 컨텍스트에 추가할 수 있는 작은 데이터 조각이나 문맥 정보입니다.
이 프리미티브는 ‘애플리케이션이 제어(application-controlled)할 수 있다’고 저희가 처음으로 결정한 항목이기도 합니다.
Prompts (프롬프트) - 사용자 주도 매크로
Prompts는 사용자가 시작하는 텍스트나 메시지 템플릿.
And then the third one is prompts. Which are deliberately meant to be like user initiated or... Like. User substituted. Text or messages.
그리고 세 번째는 ‘프롬프트(prompts)’입니다.
이는 의도적으로 ‘사용자에 의해 시작(user-initiated)’되거나—즉, 사용자가 대체 또는 변경(substituted)할 수 있는 텍스트나 메시지를 의미합니다.”
그렇다면 Tools 과 Resource는 어떻게 구분지어야 할까요?
Tools
The way we separate these is like tools are always meant to be initiated by the model.
저희가 이 둘을 구분하는 방식은, tools은 항상 모델이 스스로 호출하도록 설계된다는 점입니다
It’s sort of like at the model’s discretion that it will find the right tool and apply it.
즉, 모델의 재량(model’s discretion)에 따라 적절한 도구를 찾아 실행하는 구조라는 뜻입니다.So if that’s the interaction you want as a server developer, where it’s like, okay, this, you know, suddenly I’ve given the LLM the ability to run SQL queries, for example, that makes sense as a tool.
따라서 서버 개발자로서 LLM에게 SQL 쿼리 실행 권한을 주고 스스로 판단해 쿼리 하게 하고 싶다 면, 그것은 tool로 구현하는 것이 합당합니다.
Resources
Resources are more flexible
…..
in an ideal world where all these concepts are fully realized, and there’s like full ecosystem support, you would do resources for things like the schemas of your database tables and stuff like that, as a way to like either allow the user to say like, okay, now, you know, cloud, I want to talk to you about this database table. Here it is. Let’s have this conversation.
하지만 리소스(resources)는 훨씬 더 유연합니다
...
그러나 이상적인 생태계에서는 데이터베이스 테이블의 스키마 같은 것을 리소스로 제공해, “이 테이블에 대해 이야기하자”는 URI 한 줄만으로 모델이 해당 리소스를 해석해 대화하도록 할 수 있습니다.
Resources are also, they’re uniquely identified by a URI, always.
리소스는 언제나 고유한 URI로 식별된다는 점도 특징입니다.
And so you can also think of them as like, you know, sort of general-purpose transformers, even like, if you want to support an interaction where a user just like drops a URI in, and then you like automatically figure out how to interpret that, you could use MCP servers to do that interpretation.
따라서 리소스를 transformer 처럼 활용할 수도 있습니다. 사용자가 URI만 입력해도 MCP 서버가 자동으로 해석해 주는 시나리오가 가능합니다.
간단하게 표로 정리하면 아래와 같습니다.
| 구분 | 주도 | 주요 역할 | 식별 | 예제 |
| 도구 (tools) | 모델 | 작업 실행 (SQL, API 호출) | – | LLM의 runSQL() |
| 리소스 (resources) | 앱·사용자 | 데이터 참조·컨텍스트 제공 | URI | DB 스키마, 프롬프트 라이브러리 |
도구 호출을 어떻게 할 것 인가? - 유연성 vs 제약
Alessio가 팟캐스트에서 제기한 문제는 많은 개발자들이 공감할 만한 내용입니다.
Another question that I had when I was looking at some server implementations, the server builders kind of decide what data gets eventually returned, especially for tool calls.
서버 구현체를 살펴볼 때 궁금했던 점은, 서버 빌더들이 도구 호출에 대해 최종적으로 어떤 데이터를 반환할지 미리 결정해 둔다는 겁니다.
For example, the Google maps one, right? If you just look through it, they decide what, you know, attributes kind of get returned and the user can not override that if there's a missing one. That has always been my gripe with like SDKs in general, when people build like API wrapper SDKs. And then they miss one parameter that maybe it's new and then I can not use it.
-Alessio-
예컨대 Google Maps 서버 래퍼를 보면, 어떤 속성(attributes)을 반환할지 고정해 둬서 사용자가 새로 추가된 필드를 사용할 수 없게 돼 있더군요. 저는 일반적으로 API 래퍼 SDK에서 이런 고정 반환 방식이 불만인데, 새 파라미터가 생겼는데 SDK가 이를 반영하지 않으면 그 기능을 전혀 못 쓰게 되니까요.
Google Maps API 래퍼를 예로 들면, 개발자가 새로운 속성이나 파라미터를 사용하고 싶어도 래퍼가 이를 지원하지 않으면 불가능합니다.
이는 API가 업데이트되거나 새로운 기능이 추가될 때마다 SDK의 업데이트를 기다려야 하는 의존성 병목현상을 만듭니다.
"I mean, in general, for things like for tool results in particular, we've actually made the deliberate decision, at least thus far, for tool results to be not like sort of structured JSON data, not matching a schema, really, but as like a text or images or basically like messages that you would pass into the LLM directly."
일반적으로 도구 호출 결과는 엄격한 JSON 스키마를 따르기보다, 모델에 직접 입력할 수 있는 메시지(텍스트나 이미지) 형태로 반환하도록 의도적으로 설계했습니다.
모든 데이터를 있는 그대로 전달하고 LLM이 필요한 정보를 추출하게 하는 것이 더 효과적일수 있습니다.
LLM의 자연어 처리 능력을 최대한 활용하는 접근법.
"And so I guess the correlation that is, you really should just return a whole jumble of data and trust the LLM to like sort through it and see."
모든 데이터를 몽땅 반환하고, LLM이 알아서 필요한 정보를 골라 쓰게 하라는 상관관계를 따르는 게 맞다고 생각합니다.
대규모 언어 모델은 방대한 비구조화 데이터에서 패턴을 찾고 필요한 정보를 추출하는 데 뛰어납니다.
따라서 개발자가 미리 데이터를 필터링하거나 구조화하려고 노력하기보다는, 원본 데이터를 그대로 제공하고 LLM이 판단하게 하는 것이 더 효율적이고 확장성 있는 방법이 될 수 있습니다.
과도한 명세화의 함정
"And we really try to think about like, yeah, how to, you know, use LLMs to their full potential and not maybe over specify and then end up with something that doesn't scale as LLMs themselves get better and better."
LLM이 점점 발전할수록 확장성 문제를 피하려면, 결과를 과도하게 규격화하지 않고 모델 잠재력을 최대한 활용하는 방향으로 가야 한다고 생각합니다.
전통적인 소프트웨어 개발에서는 명확한 인터페이스와 구조가 중요했지만, LLM은 모호하고 복잡한 입력도 잘 처리할 수 있습니다.
따라서 지나치게 구체적인 스키마나 제약을 두면 오히려 LLM의 발전과 함께 시스템이 성장할 수 없는 한계를 만들게 될지도 모른다고 생각하는 것 같습니다.
"And I think it's just like unlearning like 20, 30, 40 years of software engineering practices that go a little bit into this to some degree."
결국 20~40년간 축적된 전통적 소프트웨어 엔지니어링 관행을 일부 잊어야 하는 셈이죠.
20~40년간 엔지니어링 관행의 일부를 잊어야 한다.
이문장은 요즘 ai를 활용하면서 개발을 하면서 많이 공감되는 말이었습니다.
MCP는 외부 세계간의 연결에 대한 배팅
Like thinking, us thinking that like the biggest bottleneck to, you know, the next wave of capabilities for models might actually be their ability to like interact with the outside world to like, you know, read data from outside data sources or like take stateful actions.
다음 세대 모델 역량의 최대 병목은 외부 데이터 소스를 읽거나 상태가 있는(stateful) 행동을 수행하는 능력이 될 수 있다는 점을 상기해야 합니다.
Working at Anthropic, we absolutely care about doing that. Safely and with the right control and alignment measures in place and everything.
Anthropic에서도 바로 그 부분을 매우 중요하게 여기고 있습니다. 안전하고 관리·정렬(alignment) 장치를 갖춘 방식으로 말이죠.
다음 세대 모델 역량의 최대 병목은 외부 데이터 소스를 읽거나 stateful 하게 세션을 관리하는 행동을 수행하는 능력이 될 수 있다고 생각합니다.
LLM 정렬(Alignment)의 필요성과 딜레마
GPT-4, Claude, Bard 등의 LLM은 광범위한 사전학습(pre-training)을 통해 언어 이해·추론 능력을 갖추지만, 실제 애플리케이션에서는 helpful, honest, and harmless 하는 인간 기준이 요구됩니다.
Alignment란?
alignment aims to steer AI systems toward a person's or group's intended goals, preferences, or ethical principles.
-wiki-
AI 시스템의 행동과 목표를 인간이 갖는 가치를 부여하는 행위를 Alignment 한다고 합니다.
LLM의 외부 연동과 alignment는 상호 분리할 수 없는 과제이므로, 시스템 설계 단계에서부터 보안∙정렬∙성능 요구사항을 종합적으로 고려하는 것 같습니다.
+ Alignment Tax?
Alignment를 하기 위해 RLHF(Reinforcement Learning from Human Feedback)나 DPO(Direct Preference Optimization), RSF(Rejection Sampling Finetuning) 등이 쓰입니다.
이 과정에서 모델은 본래 갖고 있던 다양한 NLP 능력을 일부 상실하는 alignment tax를 치르곤 합니다.
Alignment Tax를 완화하려는 시도는 다양한 논문에서 확인해 볼 수 있습니다.
https://arxiv.org/abs/2309.06256
Mitigating the Alignment Tax of RLHF
LLMs acquire a wide range of abilities during pre-training, but aligning LLMs under Reinforcement Learning with Human Feedback (RLHF) can lead to forgetting pretrained abilities, which is also known as the alignment tax. To investigate alignment tax, we co
arxiv.org
"So MCP is also sort of like a bet on the future and where this is all going and how important that will be."
따라서 MCP는 바로 그 미래—AI와 외부 세계 간의 연결이 얼마나 중요한지를 베팅한 설계라고 볼 수 있습니다.
MCP vs OpenAPI
MCP vs OpenAPI: 이게 결론입니다”라고 말할 수 있는 명쾌한 설명을 부탁드리고 싶었어요.
-swyx-
Yeah, I think fundamentally, I mean, open API specifications are a very great tool. And like I've used them a lot in developing APIs and consumers of APIs. I think fundamentally, or we think that they're just like too granular for what you want to do with LLMs. Like they don't express higher level AI specific concepts like this whole mental model. Yeah.
- Justin/David -
네, 기본적으로 OpenAPI 사양은 훌륭한 도구입니다.
저도 API를 설계하고 소비하는 데 많이 사용해 왔죠.
다만 LLM 기반 애플리케이션에서는 너무 세부적(granular)이라, AI 고유의 상위 개념(mental model)을 담아내기 어렵다고 봅니다.
현대 LLM을 인간 선호에 맞춘 지능형 에이전트로 만들려면 최적화해야 합니다.
지도 미세조정(SFT)으로 지시 이행 능력을, 보상 모델(RM) 학습으로 휴먼 피드백을 수치화하고,
RLHF 단계에서 RM 보상 최대화 정책을 얻는 식입니다
Fine-tune large language models with reinforcement learning from human or AI feedback | Amazon Web Services
In this post, we introduce a state-of-the-art method to fine-tune LLMs by reinforcement learning, reviewed the pros and cons of RLHF vs. RLAIF vs. DPO, and saw how to scale LLM fine-tuning efforts with RLAIF. We also see how to implement an end-to-end RLAI
aws.amazon.com
이 과정은 LLM 내부에 상태-행동-가치(state–action–value) 구조를 만들지만, 여전히 명시적 world model은 없어 복합 계획·추론에서 한계가 드러납니다
https://arxiv.org/abs/2305.14992
Reasoning with Language Model is Planning with World Model
Large language models (LLMs) have shown remarkable reasoning capabilities, especially when prompted to generate intermediate reasoning steps (e.g., Chain-of-Thought, CoT). However, LLMs can still struggle with problems that are easy for humans, such as gen
arxiv.org
Justin과 David는 바로 이 지점을 들어 OpenAPI는 LLM이 필요로 하는
고차원 개념(상태·보상·행동)을 표현하기엔 지나치게 세부적(granular)이라고 표현하는 것 같습니다.
즉 OpenAPI 스펙은 REST 엔드포인트·스키마 같은 저수준 세부사항에 묶여 있어, LLM이 활용할 상위 개념(상태·보상·행동)을 담지 못한다라고 말하는 것이죠.
목적 기반 추론, 절차 위주
LLM : 사용자 만족 극대화 같은 목적 함수를 따라 보상 기반 추론을 수행
OpenAPI : 엔드포인트·파라미터·스키마만 정의 → 모델이 왜 가 아니라 어떻게만 안내한다.
예시
LLM mental model: 고객 문제 해결을 위한 정보 수집
OpenAPI: GET /api/v1/customers/{id}, POST /tickets …
But we've talked about with the primitives of MCP and thinking from the perspective of the application developer, like you don't get any of that when you encode this information into an open API specification. So we believe that models will benefit more from like the purpose built or purpose design tools, resources, prompts, and the other primitives than just kind of like, here's our REST API, go wild.
하지만 MCP의 primitives 도구, 리소스, 프롬프트 등을 애플리케이션 개발자 관점에서 설계하면, OpenAPI에 이 정보를 담아내는 것만으로는 부족합니다.
따라서 REST API “그대로 던져 주세요” 접근법보다는, AI 목적에 특화된 primitives를 사용하는 편이 모델 성능에 더 이롭다고 믿습니다.
MCP의 세 가지 핵심 primitives는 각각 명확한 의도와 사용 맥락을 가집니다.
Tools는 모델이 자율적으로 판단해서 사용하고, Resources는 애플리케이션이나 사용자가 명시적으로 제공하며, Prompts는 사용자가 직접 트리거합니다.
이런 구분은 OpenAPI에서는 표현할 수 없는 개념입니다.
I do think there, there's another aspect. I think that I'm not an open API expert, so I might, everything might not be perfectly accurate. But I do think that we're... Like there's been, and we can talk about this a bit more later. There's a deliberate design decision to make the protocol somewhat stateful because we do really believe that AI applications and AI like interactions will become inherently more stateful and that we're the current state of like, like need for statelessness is more a temporary point in time that will, you know, to some degree that will always exist.
또 한 가지 중요한 점은, MCP 프로토콜을 일부 상태(stateful) 기반으로 설계했다는 겁니다.
제가 OpenAPI 전문가가 아니라 완벽하지 않을 수 있지만, AI 애플리케이션 상호작용이 점점 상태를 유지하는 방향으로 진화할 것이라고 보기 때문입니다.
현재의 무상태(stateless) 모델은 일시적이며, 결국 상태 관리가 필수가 될 것입니다.
REST를 예로 들면 핵심 원칙 중 하나는 무상태성(statelessness)입니다.
각 요청은 독립적이고, 서버는 클라이언트의 상태를 기억하지 않습니다.
이는 확장성과 단순성 측면에서 훌륭했지만, AI와의 대화는 본질적으로 맥락을 필요로 필요로 하고, 맥락은 상태관리를 요합니다.
But I think like more statefulness will become increasingly more popular, particularly when you think about additional modalities that go beyond just pure text-based, you know, interactions with models, like it might be like video, audio, whatever other modalities exist and out there already.
특히 텍스트를 넘어 비디오·오디오 등 다양한 입력·출력 모달리티가 결합될수록, 상태 관리가 더욱 중요해질 것입니다.
실시간 비디오 분석을 상상해 봅시다.
"화면에 보이는 사람이 웃을 때마다 알려줘"라는 요청을 처리하려면, 지속적인 스트림 분석과 상태 추적이 필요합니다.
매 프레임마다 새로운 HTTP 요청을 보내는 것은 비현실적일 수 있습니다.
And so I do think that like having something a bit more stateful is just inherently useful in this interaction pattern.
따라서 상태(stateful)를 유지하는 설계가 이런 상호작용 패턴에서 본질적으로 유용하다고 봅니다.
One more thing to add here is that we've already seen people, I mean, this happened very early. People in the community built like bridges between the two as well. So like, if what you have is an open API specification and no one's, you know, building a custom MCP server for it, there are already like translators that will take that and re-expose it as MCP. And you could do the other direction too. Awesome.
추가로, 커뮤니티에서는 이미 양방향 변환 브리지를 만든 사례가 있습니다.
OpenAPI 사양을 MCP 서버로 중계(translator)하거나, 반대로 MCP 사양을 OpenAPI로 내보내는 도구가 개발되어 있죠.
MCP는 OpenAPI를 대체하려는 것이 아니라, AI 시대에 필요한 새로운 계층을 추가하는 것입니다.
필요에 따라 두 세계를 연결할 수 있고, 점진적으로 전환할 수 있습니다.
결국 MCP vs OpenAPI는 "무엇이 더 나은가"의 문제가 아닙니다.
각자의 영역에서 최적화된 도구들이며, AI가 주도하는 미래에는 MCP 같은 새로운 방식이 필요하다는 것이 포인트라고 생각합니다.
마치 웹이 등장했을 때 HTTP가 필요했던 것처럼, AI 시대에는 AI에 최적화된 프로토콜이 필요한 것이라는 것 같습니다.
MCP Server Client
MCP Server Client 구조를 간략하게 설명하겠습니다.
MCP follows a client–server architecture where a host application can connect to multiple servers.
이 한 문장이 전체 구조를 요약해 줍니다.
하나의 Host with MCP Client (Claude, IDEs, Tools)가
다수의 MCP Server A / MCP Server B / MCP Server C에 연결됩니다.
MCP Hosts: MCP를 통해 데이터에 접근하려는 Claude Desktop, IDE, AI 도구 같은 프로그램들
MCP Clients: 서버들과 1:1 연결을 유지하는 프로토콜 클라이언트
MCP Servers: 표준화된 Model Context Protocol을 통해 각각 특정 기능(capabilities)을 노출하는 경량 프로그램들
Local Data Source A / Local Data Sources: MCP 서버가 안전하게 접근할 수 있는, 사용자의 컴퓨터에 있는 파일·데이터베이스·서비스
Remote Service B / Remote Service C / Remote Services: MCP 서버가 연결될 수 있는, 인터넷을 통해 이용 가능한 외부 시스템(예: API)
Web APIs / Internet / Your Computer: 리소스·환경을 가리키는 표기 (각각 웹 API, 인터넷, 로컬 컴퓨터)
Host (Claude / IDE / Tool)가 여러 Lightweight MCP Servers에 1:1 연결을 유지하고, 그 서버들은 Local Data Sources와Remote Services(Web APIs, Internet)를 통해 기능과 데이터를 노출하는 구조입니다.
자세한 세부내용은 MCP 사이트에서 확인 가능합니다.
https://modelcontextprotocol.io/introduction
Introduction - Model Context Protocol
Get started with the Model Context Protocol (MCP)
modelcontextprotocol.io
Composability
MCP의 진정한 힘은 개별 도구를 넘어 복잡한 워크플로우를 구성할 수 있다는 점에 있습니다.
간단한 절차적인 업무 예시를 들어보겠습니다.
1. Slack에서 고객 문의 감지
2. Back Office or CRM Solution 에서 고객 이력 조회
3. Confluence wikin 또는 사내 wiki 에서 관련 문서 검색
4. 이전 해결 사례 분석
5. GPT로 맞춤형 답변 생성
6. Slack으로 답변 전송 및 Back Office or CRM Solution 후처리.
이런 워크플로우를 하나의 거대한 MCP 서버로 만들 수도 있지만, 그렇게 되면 각 구성 요소의 재사용성이 떨어지고 유지보수가 어려워집니다.
대신 작은 MCP 서버들을 조합할 수 있다면 어떨까요?
그렇다면 단일 Tool 호출의 나열을 넘어서 여러 MCP 서버를 계층적·재귀적으로 조합을 할 수 있을까요?
That's kind of my next question on composability. Like how, how do you guys see that? Do you have plans for that? What's kind of like the import of MCPs, so to speak, into another MCP? Like if I want to build like the subreddit one, there's probably going to be like the Reddit API, uh, MCP, and then the summarization MCP. And then how do I, how do I do a super MCP?
- Alessio -
제 다음 질문, ‘컴포저빌리티(composability)’인데요. MCP 서버끼리 서로 연동하는 건 어떻게 보시나요? 예컨대 “서브레딧 요약” 서버를 만들려면, 레딧 API MCP와 요약 MCP를 각각 구축해야 할 텐데, 이 둘을 합쳐 ‘슈퍼 MCP’는 어떻게 구성하나요?
Yeah. So, so this is an interesting topic and I think there, um, so there, there are two aspects to it.
- Justin/David -
네, 흥미로운 주제입니다. 이에는 두 가지 측면이 있다고 생각해요.
I think that the one aspect is like, how can I build something? I think agentically that you requires an LLM call and like a one form of fashion, like for summarization or so, but I’m staying model independent and for that, that’s where like part of this by directionality comes in, in this more rich experience where we do have this facility for servers to ask the client again, who owns the LLM interaction, right?
한 측면은 “어떻게 구축할 것인가?”입니다. 요약 같은 작업은 LLM 호출이 필요하겠지만, 저는 모델 독립성을 유지하고 싶어요. 이때 ‘양방향성(directionality)’이 중요한데, 서버가 “LLM과의 상호작용을 담당하는 클라이언트에게 다시 요청할 수 있는” 기능이죠.
Like we talk about cursor, who like runs the, the, the loop with the LLM for you there that for the server author to ask the client for a completion. Um, and basically have it like summarize something for the server and return it back.
예컨대 Cursor는 LLM과의 대화 루프를 클라이언트를 통해 실행합니다.
서버 작성자가 클라이언트에게 완성(completion)을 요청하면, 클라이언트가 응답을 요약해 서버로 반환하죠.
And so now what model summarizes this depends on which one you have selected in cursor and not depends on what the author brings. The author doesn’t bring an SDK. It doesn’t have, you had an API key. It’s completely model independent, how you can build this.
따라서 어떤 모델이 요약할지는 Cursor에서 선택한 모델에 달려 있고, 서버 작성자가 직접 SDK나 API 키를 제공할 필요가 없습니다. 완전히 모델 독립적으로 구성할 수 있죠.
Justin과 David는 Composability를 위한 두 가지 접근법을 제시합니다
첫 번 째요소는 모델 독립성을 유지하기 위한 양방향성 구조입니다.
특정 LLM 모델에 구애받지 않는 모델 독립성을 유지하면서 mcp 간 컴포지션에 대해서 생각해 보려면,
클라이언트가 서버에게 요청을 하고, 서버 역시 클라이언트에게 요청할 수 있는 양방향성이 중요해집니다.
cursor를 예시로 들어주는 jetbrain ai 역시 ide에서 model 선택을 제공하고 있습니다.
모델을 선택하고 사용하는 건 전적으로 ide 클라이언트에 달려있고 ide와 연결되어 있는 MCP서버는 모델별 sdk, api 키를 제공할 필요가 없어지게 됩니다.
There’s just one aspect to that. The second aspect to building richer, richer systems with MCP is that you can easily envision an MCP server that serves something to like something like cursor or win server for a cloud desktop, but at the same time, also is an MCP client at the same time and itself can use MCP servers to create a rich experience.
그리고 두 번째 측면은, 단일 MCP 서버가 클라우드 데스크톱용 Cursor나 Win Server에 서비스를 제공하는 동시에, 스스로도 MCP 클라이언트로 동작하며 또 다른 MCP 서버를 호출해 풍부한 경험을 만들어 낼 수 있다는 겁니다.
And now you have a recursive property, which we actually quite carefully in the design principles, try to retain. You know, you see it all over the place and authorization and other aspects, to the spec that we retain this like recursive pattern.
이로써 재귀적(recursive) 특성이 생깁니다. 설계 원칙에도 재귀 패턴을 유지하려고 신경 썼고, 권한 관리 등 스펙 전반에서 이 패턴을 확인할 수 있죠.
And now you can think about like, okay, I have this little bundle of applications, both a server and a client. And I can add. Add these in chains and build basically graphs like, uh, DAGs out of MCP servers that can just richly interact with each other.
이제 “서버이자 클라이언트인 작은 애플리케이션 묶음”을 생각해 보세요. 이들을 체인으로 연결해 DAG(Directed Acyclic Graph) 형태의 네트워크를 구성하면 MCP 서버들이 서로 풍부하게 상호작용할 수 있습니다.
두 번째 요소는 서버이자 클라이언트 일수 있다는 점.
단일 MCP 서버가 서비스를 제공하는 동시에, 스스로 다른 MCP 서버의 Client 로서 동작할 수 있는 것.
그로 인해 재귀적 특성이 생기게 됩니다.
And I think you see hopefully more of this, particularly when you think about like auto-selecting, auto-installing, there’s a bunch of these things you can do that make, make a really fun experience.
자동 선택(auto-selecting)·자동 설치(auto-installing) 같은 기능까지 더해지면, 더욱 흥미로운 경험이 가능할 겁니다.
auto-selecting과 auto-installing을 필요한 mcp를 자체적으로 판단하고 자체적으로 설치한다고 이해했습니다.
사용자: "이 PDF 논문을 한국어로 번역하고 요약해줘"
시스템 동작:
1. 의도 분석 → PDF 처리 + 번역 + 요약 필요
2. 필요 MCP 서버 확인:
- ✓ PDF 리더 MCP (설치됨)
- ✗ 학술 번역 MCP (미설치)
- ✓ 논문 요약 MCP (설치됨)
3. 자동 제안: "학술 번역 MCP를 설치하시겠습니까?"
4. 동적 파이프라인 구성 및 실행
위와 같이 놀라운 사용자 경험을 얻게 되는 것입니다.
auto-selecting을 하는 것에 있어서의 할루시네이션이 있다고 할지라도 말이죠.
This is, uh, very exciting. And very, I'm sure, I'm sure a lot of people get very, very, uh, a lot of ideas and inspiration from this. Is an MCP server that is also a client, is that an agent?
-swyx-
정말 흥미롭네요. 많은 분이 영감과 아이디어를 얻을 것 같은데, “서버이자 클라이언트인” MCP 서버를 에이전트라고 부를 수 있나요?
What's an agent? There's a lot of definitions of agents.
- Justin/David-
에이전트가 정확히 뭔가요? 정의가 다양하죠.
Because like you're, in some ways you're, you're requesting something and it's going off and doing stuff that you don't necessarily know. There's like a layer of abstraction between you and the ultimate raw source of the data. You could dispute that. Yeah. I just, I don't know if you have a hot take on agents.
-swyx-
사용자가 요청하면, 그 뒤에서 모르는 작업을 수행하잖아요. 데이터의 최종 원천과 사용자 사이에 추상화 계층이 생기고요. 이걸 에이전트라고 볼 수도 있겠죠. 에이전트에 대한 의견이 있나요?
I do think, I do think that you can build an agent that way. For me, I think you need to define the difference between an MCP server plus client that is just a proxy versus an agent. I think there's a difference.
-Justin/David-
네, 그렇게 에이전트를 구성할 수 있다고 봅니다. 다만 “단순 프록시(proxy)로서 서버+클라이언트”와 “에이전트”를 구분해야 합니다. 분명 차이가 있어요.
And I think that difference might be in, um, you know, for example, using a sample loop to create a more richer experience to, uh, to, to have a model call tools while like inside that MCP server through these clients. I think then you have a, an actual like agent.
예를 들어 샘플 루프(sample loop)를 사용해 모델이 MCP 서버 내부에서 도구 호출을 반복하며 더욱 풍부한 경험을 제공한다면, 그때가 진정한 에이전트가 아닐까 싶습니다.
프록시 mcp와 에이전트 mcp를 아래와 같이 구분하는 것 같습니다.
| 특성 | 프록시 MCP | 에이전트 MCP |
| 역할 | 단순 요청 전달 | 자율적 의사결정 |
| 상태 | 무상태 | 컨텍스트 유지 |
| 반복 | 없음 | 루프 기반 개선 |
| 목표 | 중계 | 문제 해결 |
And so I think the key question, which is still unresolved is like, to what degree are agents really naturally fitting in to this existing model and paradigm or to what degree is it basically just like orthogonal? It should be something.
따라서 핵심 질문은 “에이전트가 MCP 모델·패러다임에 자연스럽게 녹아드는가?” 아니면 “전혀 별개(orthogonal)로 다뤄야 하는가?”입니다. 이 부분은 아직 결론이 나지 않았습니다.
도구 사용 개수와 제어 권한 관리
MCP의 가장 큰 장점 중 하나는 다양한 서버를 동시에 연결할 수 있다는 점입니다.
하지만 이는 곧 새로운 도전과제를 만들어냅니다.
실제 개발 환경을 예제를 하나 만들어 본다면.
파일 시스템 서버 3개 (로컬, 클라우드 스토리지, 버전 관리)
데이터베이스 서버 5개 (PostgreSQL, MongoDB, Redis, Elasticsearch, MySQL)
API 통합 서버 12개 (GitHub, Slack, Jira, AWS, Google APIs 등)
약 20개의 MCP 서버가 연결된 상황에서 LLM은 어떻게 적절한 도구를 선택할까요?
Anyway, so the first one is, it's just a simple, how many MCP things can one implementation support, you know, so this is the, the, the sort of wide versus deep question.
-swyx-
좋습니다. 좀 더 구체적인 질문으로 넘어가 보죠. 첫 번째는 단순합니다. “하나의 구현에서 얼마나 많은 MCP 서버(또는 도구·리소스·프롬프트 등)를 지원할 수 있느냐?”라는 폭(많이) 대 깊이(적게) 문제입니다.
You know, so to me, that's wide in, in the sense that you, you don't have tools that call tools.
제게 있어 ‘넓다(wide)’는 의미는, 도구(tool)가 다른 도구를 호출하지 않는다는 뜻입니다.
-Justin/David-
You just have the model and a flat hierarchy of tools, but then obviously you have tool confusion.
단순히 모델과 평면적(flat)인 도구 계층(hierarchy)이 있을 뿐인데, 이 경우 도구 간 혼선(confusion)이 발생하기 마련입니다.
Tool Confusion의 예시를 들어보겠습니다.
- 유사한 기능의 중복
- GitHub API: create_issue() - GitLab API: create_issue() - Jira API: create_issue() 사용자: "버그 이슈를 생성해줘" LLM: 어떤 시스템에 생성해야 할까? - 모호한 명령어 해석
- FileSystem: search_files() - Database: search_records() - Elasticsearch: search_documents() 사용자: "고객 데이터를 검색해줘" LLM: 파일? 데이터베이스? 검색 엔진?
It's going to happen when the tools are adjacent, you call the wrong tool.
도구들이 서로 가까이(adjacent) 있을 때, 잘못된 도구를 호출하는 상황이 발생할 수밖에 없습니다.
You're going to get the bad results, right?
그럼 당연히 원하는 결과가 나오지 않겠죠?
Do you have a recommendation of like a maximum number of MCP servers that are enabled at any given time?
어떤 시점에 활성화할 MCP 서버의 최대 개수에 대해 권장하는 바가 있나요?
-swyx-
I think be honest, like, I think there's not one answer to this because to some extent, it depends on the model that you're using.
-Justin/David-
솔직히 말씀드리자면, 이 질문에는 정답이 하나만 있는 게 아닙니다. 어느 정도는 사용 중인 모델(model)에 달려 있기 때문이죠.
모델별 도구 처리 능력의 차이
1.대규모 모델 (GPT-o3, Claude 4 opus): 수백 개의 도구를 효과적으로 구분
2.중간 규모 모델: 수십 개 수준에서 혼선 시작
3.소규모 모델: 10개 이상에서 급격한 성능 저하
이러한 차이는 다음 요소들에 의해 결정될 수 있습니다.
1.활용하는 컨텍스트 크기
2.함수 호출(function calling) 학습 데이터의 품질
3.추론 능력과 의미 구분 능력
결국 모델 성능, 모델에서 제공하는 정보, 피쳐에 달려있습니다.
I mean, I think that the dream is certainly like you just furnish all this information to the LLM and it can make sense of everything.
꿈꾸는 이상(ideal)은 이런 모든 정보를 LLM에 제공하면, LLM이 알아서 모든 것을 해석해 주는 것입니다.
This, this kind of goes back to like the, the future we envision with MCP is like all this information is just brought to the model and it decides what to do with it.
이것은 MCP의 미래 청사진과도 연결되는데, 모든 정보가 모델에게 제공되고 모델이 스스로 처리 방안을 결정하는 구조를 지향한다는 뜻이죠.
But today the reality or the practicalities might mean that like, yeah, maybe you, maybe in your client application, like the AI application, you do some fill in the blanks.
그러나 현재 현실적으로는, 클라이언트 애플리케이션(또는 AI 애플리케이션) 쪽에서 fill in the blanks 작업을 해야 할 수도 있습니다.
현실적인 대안을 제시합니다.
Maybe you do some filtering over the tool set or like maybe you, you run like a faster, smaller LLM to like filter to what's most relevant and then only pass those tools to the bigger model.
도구 세트를 필터링(filtering) 하거나, 더 빠르고 작은 LLM을 사용해 가장 관련성 높은 도구만 선별한 뒤, 그 도구들만 더 큰 모델에 전달하는 식으로 말이죠.
Or you could use an MCP server, which is a proxy to other MCP servers and does some filtering at that level or something like that.
또는 MCP 서버를프록시(proxy) 로 두어, 그 서버에서 다른 MCP 서버들을 필터링하는 단계(routing/filtering)를 구현할 수도 있습니다.
SLLM을 사용해 사전 필터링을 하거나
MCP 서버를 프록시로 활용해 도구를 선별하는 방식을 제안합니다.
I think hundreds, as you referenced, is still a fairly safe bet, at least for Claude.
제가 보기에는, 적어도 Claude의 경우 수백 단위(hundreds)는 여전히 안전한 선택입니다.
Description and Overlap
Tool이 많아질수록 '설명의 명확성'이 중요해집니다
Yeah, and obviously it highly, it highly depends on the overlap of the description, right?
네, 그리고 분명히 도구 설명(description)의 중복(overlap) 여부에 크게 달려 있습니다.
Like if you, if you have like very separate servers that do very separate things and the tools have very clear unique names, very clear, well-written descriptions, you know, your mileage might be more higher than if you have a GitLab and a GitHub server at the same time in your context.
예컨대, 완전히 분리된 기능을 수행하는 서버들이 있고, 그 도구들의 이름이 명확하게 고유(unique)하며, 설명이 잘 작성되어 있다면, GitLab과 GitHub 같은 유사한 도구를 동시에 둔 경우보다 훨씬 더 성능이 좋을 수 있습니다.
And, and then the overlap is quite significant because they look very similar to the model and confusion becomes easier.
반면, 둘의 설명이 많이 겹치면 모델 입장에서 구분이 어려워져 혼선이 더 쉽게 발생하겠죠.
I guess the way I think about this is still like at the end of the day, and this is a core MCP design principle is like, ultimately, the concept of a tool is not a tool.
제 관점은 결국, 그리고 이것이 핵심 MCP 설계 원칙 중 하나인데, “tool이라는 개념 자체가 도구가 아니다”라는 것입니다.
It's a client application, and by extension, the user.
즉 Tool 은 클라이언트 애플리케이션이고 확장해서 말하면 결국 사용자(user)인 셈이죠.
Ultimately, they should be in full control of absolutely everything that's happening via MCP.
궁극적으로 MCP를 통해 일어나는 모든 일에 대해 사용자가 완전한 제어(full control)권을 가져야 합니다.
즉 MCP의 핵심 설계 철학 중 하나는 제어권은 사용자에게 입니다
When we say that tools are model controlled, what we really mean is like, tools should only be invoked by the model.
“도구가 모델에 의해 제어된다(model-controlled)”고 할 때 진짜 의미는 “도구는 오직 모델에 의해서만 호출(invoked)되어야 한다”는 뜻입니다.
Like there really shouldn't be an application interaction or a user interaction where it's like, okay, as a user, I now want you to use this tool.
예를 들어 사용자가 “자, 이 도구를 사용해 줘”라고 명령하는 UI 상의 인터랙션은 없어야 한다는 거죠.
We really want the client applications to have full control in the MCP paradigm.
우리는 MCP 패러다임 내에서 클라이언트 애플리케이션이 전권(full control)을 갖기를 원합니다.
안전하고 믿을만한 구현체를 어떻게 판단하는가
빠른 속도로 오픈소스 생태계에서 MCP 서버가 확산되면서 자연스럽게 떠오르는 질문이 있습니다. "어떤 구현체를 신뢰할 수 있을까?"
즉 플랫폼으로서 MCP를 활용함에 있어서 신뢰성 문제도 고려를 해봐야 합니다.
Like, how do you determine which MCP servers are like the kind of good and safe ones to use?
어떤 MCP 서버가 “안전하고 믿을 만한 구현체”인지 어떻게 판단할 것인가가 관건입니다.
But you want to make sure that you're not using ones that are really like sus, right?
정말 수상쩍은 구현체를 쓰지 않도록 주의해야 합니다.
MCP 서버는 일반적인 라이브러리와 달리 특별한 권한을 가집니다.
로컬 파일 시스템 접근, 데이터베이스 연결, 외부 API 호출 등 민감한 작업을 수행할 수 있기 때문에 보안이 더욱 중요합니다.
And so trying to think about like how to kind of endow reputation or like, you know, if hypothetically.
그래서 어떻게 하면 구현체에 reputation을 부여하거나, 예컨대,
Anthropic is like, we've vetted this.
“Anthropic에서 검증(vetted)했다”라는 식의
It meets our criteria for secure coding or something.
“우리의 보안 코딩 기준을 충족한다”라는
How can that be reflected in kind of this open model where everyone in the ecosystem can benefit?
표준화된 방식으로 반영해서 에코시스템 전체가 혜택을 볼 수 있도록 할 수 있을까요?
-swyx-
swyx는 일반적인 표준화된 방식의 해법을 제시합니다.
Don't really know the answer yet, but that's very much top of mind.
아직 정답은 모르겠지만, 현재 이 부분을 가장 중점적으로 고민 중입니다.
-Justin/David-
And a registry is very tempting to offer download counts, likes, reviews, and some kind of trust thing.
-swyx-
레지스트리는 다운로드 수, 좋아요, 리뷰 같은 소셜 증명(social proof)을 제공하기에 매력적인 플랫폼이죠.
여기서 말하는 레지스트리는 npm , pypi 같은 레지스트리 플랫폼입니다.
I think it's kind of brittle.
하지만 저는 그 시스템이 취약하다고 봅니다.
Like no matter what kind of social proof or other thing you can, you can offer, the next update can compromise a trusted package.
어떤 형태의 소셜 증명이라도, 다음 업데이트 때 신뢰받는 패키지(trusted package)가 훼손될 위험이 있기 때문입니다.
So abusing the trust system is like setting up a trust system creates the damage from the trust system.
즉, 신뢰 시스템을 악용(abuse)하면, 신뢰 시스템 자체가 오히려 피해를 낳습니다.
Yeah, absolutely. Cool.
-Justin/David-
네, 정말 맞는 말입니다.
멋지네요.
And then I think like that's very classic, just supply chain problem that like all registries effectively have.
이것은 사실 모든 레지스트리가 갖는 전형적인 공급망 문제(supply chain problem) 이기도 합니다
사실 이는 모든 레지스트리가 갖는 전형적인 supply chain 문제이기도 합니다.
event-stream 사건 (npm, 2018): 인기 있던 패키지가 악의적 코드를 포함한 업데이트를 배포
https://blog.npmjs.org/post/180565383195/details-about-the-event-stream-incident
npm Blog Archive: Details about the event-stream incident
The npm blog has been discontinued. Updates from the npm team are now published on the GitHub Blog and the GitHub Changelog. This is an analysis of the event-stream incident of which many of you became aware earlier this week. npm acts immediately to addre
blog.npmjs.org
PyPI typosquatting : 유명 패키지와 유사한 이름으로 악성 패키지 배포하는 방식
Typosquatting Cyberattack on PyPI Suspends New User and Project Creation
www.getsafety.com
SolarWinds 해킹 (2020): 신뢰받던 소프트웨어 공급망을 통한 대규모 침투
https://www.techtarget.com/whatis/feature/SolarWinds-hack-explained-Everything-you-need-to-know
SolarWinds hack explained: Everything you need to know
The SolarWinds hack exposed government and enterprise networks to hackers through a routine maintenance update to the company's Orion IT management software.
www.techtarget.com
기존 소프트웨어 보안 분야에서는 CRA(Cyber Resilience Act)나 CC(Common Criteria) 같은 인증 및 규정이 존재합니다.
CRA는 EU의 사이버 보안 규정으로 제품의 최소 보안 요구사항을 정의하고, CC는 IT 제품의 보안성을 평가하는 국제 표준입니다.
하지만 이러한 전통적 접근법도 빠르게 진화하는 오픈소스 생태계의 동적인 특성을 완전히 해결하지는 못합니다
https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act?utm_source=chatgpt.com
Cyber Resilience Act
The Cyber Resilience Act enhances cybersecurity standards of products that contain a digital component, requiring manufacturers and retailers to ensure cybersecurity throughout the lifecycle of their products.
digital-strategy.ec.europa.eu
https://www.commoncriteriaportal.org/index.cfm
Common Criteria : CC Portal
www.commoncriteriaportal.org
즉 플랫폼으로서 MCP를 활용하는 것에 있어서도 supply chain problem에 대한 충분한 고민이 필요합니다.
stateless로 전환
상태 관리의 딜레마
AI 애플리케이션의 본질적 특성을 그대로 구현하기에 현실적인 제약들이 존재합니다.
AI가 상태를 필요로 하는 이유 (여러 가지 지만 간단하게 리스팅 합니다.)
1. 대화의 연속성 : 방금 말한 그 파일을 분석해 줘
2. 작업 진행 추적 : 여러 단계로 이루어진 복잡한 작업
3. 개인화 : 사용자별 선호도와 히스토리
4. 실시간 협업 : 코드 편집, 문서 작성 중 지속적 지원
그러나 상태 유지는 운영상 큰 부담이 될 수 있습니다.
1. 서버 재시작 시 모든 연결 끊김
2. 로드 밸런싱의 복잡성
3. 메모리 사용량 증가
4. 장애 복구의 어려움
Stateful to stateless servers.
상태 유지 서버에서 무상태 서버로의 전환.
You guys picked SSE as your sort of launch protocol and transport.
여러분은 처음에 SSE(Server-Sent Events)를 프로토콜 겸 전송 수단으로 선택하셨고요.
And obviously transport is pluggable.
그리고 전송 방식은 플러그인처럼 교체 가능하다고요.
The behind the scenes of that, like was it Jared Palmer's tweet that caused it or were you already working on it?
그 결정의 배경은 무엇인가요? Jared Palmer의 트윗 때문이었나요, 아니면 이미 준비 중이셨나요?
처음 MCP는 SSE(Server-Sent Events)를 선택했습니다.
SSE란?
Server-Sent Events(SSE)는 서버가 HTTP 연결을 통해 클라이언트로 자동 업데이트를 푸시할 수 있게 하는 서버 푸시 기술입니다.
SSE 메커니즘은 2004년 Ian Hickson이
"WHATWG Web Applications 1.0" 제안의 일부로 처음 명시했습니다.
-wiki-
https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events
Using server-sent events - Web APIs | MDN
Developing a web application that uses server-sent events is straightforward. You'll need a bit of code on the server to stream events to the front-end, but the client side code works almost identically to websockets in part of handling incoming events. Th
developer.mozilla.org
전통적으로 웹 페이지는 새로운 데이터를 받기 위해 서버에 요청을 보내야 했습니다.
하지만 서버 전송 이벤트를 사용하면, 서버가 언제든지 웹 페이지로 새로운 데이터를 푸시할 수 있습니다.
Jared Palmer의 트윗이 도대체 뭘까 찾아보았습니다.
https://x.com/jaredpalmer/status/1898048865758007771
X의 Jared Palmer님(@jaredpalmer)
MCP’s fatal flaw is that it requires a stateful server
x.com
MCP's fatal flaw is that it requires a stateful server
MCP의 가장 큰 결함은 상태를 유지하는 서버가 반드시 필요하다는 것이다.
대화의 문맥상 위 트윗일 것 같습니다(뇌피셜)
we have GitHub discussions going back, like, you know, in public going back months, really talking about this, this dilemma and the trade-offs involved.
-Justin/David-
아니요, 이미 수개월 전부터 GitHub Discussions에서 이 딜레마와 그에 따른 트레이드오프(trade-offs)에 대해 활발히 공개 논의를 해 왔습니다.
You know, we do believe that like.
저희는 분명히 이렇게 믿고 있습니다.
The future of AI applications and ecosystem and agents, all of these things I think will be stateful or will be more in the direction of statefulness.
AI 애플리케이션·에코시스템·에이전트 등 미래의 많은 기술은 상태 유지(stateful) 쪽으로 나아갈 것이라고요.
trade off에 대한 논의 링크입니다.
http://github.com/modelcontextprotocol/modelcontextprotocol/discussions/102
State, and long-lived vs. short-lived connections · modelcontextprotocol modelcontextprotocol · Discussion #102
Context MCP is currently a stateful protocol, with a long-lived connection between client and server. This allows us to support behaviors like: Notifications about changes—e.g., changes to resource...
github.com
해당 논의 흐름에 대해서 추가적으로 글을 작성할 수 있다면 작성하겠습니다.
해당내용을 현재 글에서 작성하기엔 부담이라 패스합니다!
I think honestly, this is one of the most contentious topics we've discussed as like the core MCP team and like gone through multiple iterations on and back and forth.
솔직히 말해, MCP 핵심 팀 내부에서 가장 논쟁적(contentious)이었던 주제 중 하나로, 여러 차례 반복 논의를 거쳤습니다.
But ultimately just came back to this conclusion that like if the future l ooks more stateful, we don't want to move away from that paradigm. Completely.
하지만 최종 결론은, 미래가 상태 유지 쪽이라면 이 패러다임을 완전히 포기하고 싶지 않다는 것이었습니다.
Now we have to balance that against it's it's been operationally complex or like it's hard to deploy an MCP server if it requires this like long lived persistent connection.
다만 운영 난이도(operational complexity)를 고려해야 하는데, 장시간 지속 연결(persistent connection)을 요구하는 서버는 배포가 어렵습니다.
This this is the original like SSE transport design is basically you deploy an MCP server and then a client can come in and connect.
원래 SSE 기반 전송 디자인은 MCP 서버를 배포하면, 클라이언트가 접속(connect)만 하면 되는 방식이었고요.
And then basically you should remain connected indefinitely, which is that's like a tall order for anyone operating at scale.
클라이언트는 무한 연결(indefinite connection) 상태를 유지해야 하는데, 대규모 운영 환경에서는 매우 부담스럽습니다.
It's just like not a deployment or operational model you really want to support it.
사실상 그 방식을 그대로 지원하기는 어렵죠.
SSE의 운영상 문제점
# 실제 운영 시나리오
연결 수: 10,000개
서버당 메모리: 연결당 ~100KB = 1GB
서버 재배포: 모든 연결 끊김 → 재연결 폭주
네트워크 장애: 상태 복구 불가능
So we were trying to think, like, how can we balance the belief that statefulness is important with sort of simpler operation and maintenance and stuff like that?
그래서 상태 유지의 중요성과 운영·유지보수의 단순성 사이에서 어떻게 균형을 맞출지 고민했습니다.
And the news sort of we're calling it the streamable HTTP transport that we came up with still has SSE in there.
결과적으로 저희는 Streamable HTTP Transport라는 방식을 제안했는데, 내부적으로는 여전히 SSE를 활용합니다.
But it has a more like a gradual approach where like a server could be just plain HTTP, like, you know, have one endpoint that you send HTTP posts to and then, you know, get a result back.
그러면서도 서버를 순차적(gradual)으로 업그레이드할 수 있도록, 우선은 일반 HTTP POST 한 번으로 결과를 받을 수 있는 엔드포인트를 마련했습니다.
And then you can like gradually enhance it with like, OK, now I want the results to be streaming or like now I want the server to be able to issue its own requests.
그다음 단계로 “결과를 스트리밍(streaming)으로 받고 싶다”거나 “서버가 클라이언트 요청 없이도 푸시를 하길 원한다” 같은 기능을 순차적으로 추가할 수 있습니다.
And as long as the server and client both support the ability to like resume sessions, like, you know, to disconnect and come back later and pick up where you left off, then you get kind of the best of both worlds where it could still be this stateful interaction and stateful server, but allows you to like horizontally scale more easily or like deal with spotty network connections or whatever the case may be.
또한 서버·클라이언트가 세션 재개(resume sessions)를 지원하면, 연결이 끊겼다가 다시 이어도 이전 상태를 복원할 수 있어, 상태 유지와 확장성·불안정 네트워크 대응을 모두 만족시킬 수 있습니다.
http://github.com/modelcontextprotocol/modelcontextprotocol/discussions/102
State, and long-lived vs. short-lived connections · modelcontextprotocol modelcontextprotocol · Discussion #102
Context MCP is currently a stateful protocol, with a long-lived connection between client and server. This allows us to support behaviors like: Notifications about changes—e.g., changes to resource...
github.com
위 논의를 기준으로 확인해 보면.
2번째 옵션으로 고려하던 게 채택된 것 같습니다.
하이브리드 접근
기본은 짧은-수명(stateless) HTTP 요청/응답을 사용하고,
필요할 때만 선택적 스트리밍(서버→클라이언트) 채널을 붙이는 방향이 “Streamable HTTP transport”라는 이름으로 채택된 것 같습니다.
위 방식이 스펙에 반영된 것 같고, 기존 HTTP+SSE 전송은 이 새로운 전송방식으로 교체된 것 같습니다.
즉 포인트는 미래를 포기하지 않으면서 현재를 해결하자!
statelss 하면서도 statefull 한 설계를 열어둔 것이라고 생각합니다.
인증은 어떻게?
And you had, as you mentioned, session ID.
세션 ID를 언급하셨고요.
How do you think about auth going forward?
앞으로 인증(auth)은 어떻게 설계하실 계획인가요?
And that will solve a lot of these issues because you don't really want to have people bring API keys, particularly when you have like, when you think about a world, which, which I truly believe will happen where the majority of servers will be remote servers.
API 키를 그대로 노출하는 것은 위험하기 때문에, 특히 대부분의 서버가 원격 서비스화될 미래를 대비해 OAuth 기반 인증이 더 안전한 해법입니다
인증의 경우 Oauth 베이스 인증으로 생각 중이라고 한다.
이후 오픈소스 관련 논의와 대화를 하면서 끝을 맺습니다.
최종 정리 및 느낀 점
mcp의 공식 발표일은 2024년 11월 25일입니다.
현재 글을 작성하는 시점은 2025년 07 19일 약 8개월이 조금 지난 시점
mcp 에 대한 dx가 많이 쌓여있는 시점에서 mcp를 개발한사람들의 사상과 생각이 궁금하여 글을 작성하게 되었습니다.
mcp 를 개발하는 사람들의 의견과 시야가 사용하는 스스로와 많은 부분이 달라서 많은 것을 생각해 보게 된 좋은 계기가 된 것 같습니다.
벌써 금년 4월 google 은 a2a라는 agent to agent 프로토콜을 이야기합니다.
기술과, 지식의 변화가 빠르고 내가 갖는 지식의 반감기가 줄어든 현시점.
ai model 기반의 work process, 통신, 플랫폼활용등의 많은 부분들이
다가올 미래에 어떻게 변해갈 것이며 일을 하는 방식이 어떻게 변화할 것 인지 무서우면서도 한편으로는 신나는 모순적인 하루하루입니다.
https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/
Announcing the Agent2Agent Protocol (A2A)- Google Developers Blog
A new era of Agent Interoperability AI agents offer a unique opportunity to help people be more productive by autonomously handling many daily recurring or complex tasks. Today, enterprises are increasingly building and deploying autonomous agents to help
developers.googleblog.com
댓글