그럼1편에 이어서, 실제 MCP 사용 사례에 관련된 자세한 이야기를 이어가볼게요.
🤖 실제 MCP 사용 예시
지금부터는 실제 MCP가 작동하는 상황을 좀 가정해볼게요.
제가 Anthropic의 Python SDK 저장소를 관리하는 유지 관리자이고, 여기에 대해 몇 가지 작업을 해야 한다고 쳐봅시다. Claude for Desktop 앱에 제가 작업 중인 GitHub 저장소의 URL을 전달한 다음, 이렇게 말하는 거예요. “이 저장소의 이슈들을 불러와서 분류해줄 수 있어?”
Claude는 그 요청을 받은 뒤, 내부적으로 가장 적합하다고 판단한 list_issues라는 툴을 자동으로 호출합니다. 이 툴을 통해 이슈 목록을 불러오고, 이를 모델의 컨텍스트로 끌어온 뒤 요약을 시작하죠.
제가 “이슈들을 분류해줘”라고 요청했기 때문에, Claude는 제가 이전에 Claude와 주고받은 대화 내용이나 프로젝트 내의 다른 작업 등을 참고해서, 저에 대해 알고 있는 정보 기반으로 ‘이슈 중 가장 중요한 5개’를 뽑아줍니다. 신기하죠죠? 단순히 모델이 툴을 호출하는 것에 그치지 않고, 애플리케이션 자체가 사용자인 저에 대한 다양한 맥락을 이미 알고 있고, 그 정보가 모델의 판단에 영향을 주고 있다는 게 말입니다.
이번엔 이렇게 말해볼까요? “가장 우선순위가 높은 3개 이슈를 ASA 프로젝트에 추가해줘.” 저는 프로젝트 이름을 명시하지 않았지만, Claude는 이 정보가 필요하다는 것을 이미 알고 있습니다. 그래서 Claude는 자체적으로 ASA 서버에 연결합니다. 이 서버에는 약 30개의 툴이 등록되어 있는데요, Claude는 먼저 list_workspaces를 호출한 다음, search_projects 툴을 호출해 프로젝트를 찾고, 이어서 해당 이슈들을 작업으로 추가하기 위한 툴들을 순차적으로 실행합니다.
여기서 중요한 점은, 저는 GitHub 서버도, Asana 서버도 직접 만든 것이 아니라는 점입니다. 이 서버들은 커뮤니티에서 만든 것이며, 몇 백 줄 정도의 코드로 이루어져 있습니다. 대부분 서버의 기능은 MCP 프로토콜을 통해 툴을 노출하는 것이고, 특별히 복잡한 로직은 없기 때문에 보통 한 시간 정도면 만들 수 있을 정도로 간단합니다.
결과적으로, 제가 매일 사용하는 Claude for Desktop이라는 익숙한 인터페이스 안에서, 다른 사람이 만들어 놓은 GitHub와 Asana용 툴을 활용할 수 있게 됩니다. 이렇게 Claude for Desktop은 제가 일상에서 사용하는 데이터와 시스템들을 가져오고 연결하는 중앙 허브 역할을 하게 되죠. 실제로 Anthropic 내부에서도 이런 시스템을 아주 활발하게 사용하고 있어요. MCP는 이렇게 모든 걸 연결하는 표준 레이어 역할을 해냅니다.
결국 핵심은, 이 컨텍스트를 애플리케이션에 통합하는 방식은 개발자에게 달려있다는 점입니다. MCP를 통해 어떤 애플리케이션이든 이러한 컨텍스트 연결을 ‘표준화된 방식’으로 할 수 있으니까요.
🧩 에이전트(Agent) 구조와 MCP의 관계
자, 지금까지는 AI 애플리케이션에 컨텍스트를 불러오는 방법, 그리고 MCP가 이를 어떻게 가능하게 하는지를 이야기해봤습니다. 하지만 저희가 진정으로 기대하는 부분은, MCP가 에이전트 시스템 전반의 ‘기초 프로토콜’로 자리 잡게 되는 것입니다. 그 이유는 다음과 같습니다.
첫째, 곧 이야기할 MCP의 프로토콜 기능과 능력 때문이고요. 둘째, 에이전트 시스템이 점점 더 똑똑해지고 있고, 모델 자체도 향상되어, 우리가 제공하는 데이터를 훨씬 더 효과적으로 활용하고 있기 때문입니다. 이런 흐름이 아주 강력한 변화를 만들고 있다고 생각해요.
이런 급격한 변화를 뒷받침하는 내용을 소개하겠습니다.
몇 달 전, 제 동료 Barry와 Eric이 작성한 “Effective Agents 구축하기”라는 블로그 글을 보신 분들도 있을 거예요. 그 글에서 소개된 핵심 개념 중 하나가 바로 “증강 LLM(Augmented LLM)”입니다. 전통적인 LLM은 입력을 받고 출력을 내보내는 구조이지만, 여기에 세 가지 화살표—검색 시스템(Retrieval Systems), 툴(Tools), 메모리(Memory)—이 추가되면서 증강된다는 개념입니다.
그래서 LLM은 이런 능력을 갖게 됩니다:
- 다양한 시스템에 데이터를 쿼리하거나 기록할 수 있다.
- 툴을 호출하고 그 결과에 따라 반응할 수 있다.
- 일종의 상태(state)를 유지하면서 연속적인 작업을 수행할 수 있다.
MCP는 이 증강된 LLM의 ‘하단 계층 전체’를 담당합니다. 검색 시스템, 툴 호출, 메모리 접근 등을 MCP가 모두 표준화된 방식으로 다뤄줍니다. 이는 여러분이 에이전트를 구축할 때, 미리 모든 것을 구현하지 않아도 된다는 뜻이기도 해요. 초기에는 프로그램되지 않았더라도, 에이전트는 시스템 및 현실 세계와 상호작용하면서 새로운 기능을 ‘스스로 발견’하고 활용할 수 있습니다.
사실 에이전트 시스템은 그렇게 복잡하지 않아요.. 증강된 LLM이 루프 안에서 반복적으로 작업을 수행하면서 목표를 향해 나아가는 구조죠. 툴을 호출하고, 결과를 확인하고, 다음 단계를 수행하고. 이런 식의 반복입니다.
여기서 MCP는 증강 LLM에게 해당 능력을 제공합니다. 다시 말해, 에이전트 개발자가 초기 단계에서 모든 기능을 정의할 필요가 없고, 사용자가 이후에 툴이나 컨텍스트를 확장해도 문제가 없습니다. 에이전트 개발자는 루프 구조나 컨텍스트 관리, 메모리 사용 방식, 어떤 모델을 쓸지 같은 본질적인 부분에만 집중할 수 있게 됩니다.
이제 실제로 이것이 어떻게 작동하는지, 코드 예제를 통해 살펴보겠습니다.
우리가 살펴볼 예시는 Last Mile AI 팀에서 구축한 오픈소스 프레임워크인 MCP Agent라는 프레임워크입니다. 이 프레임워크는 매우 깔끔하고 단순한 구조를 가지고 있어서, MCP를 활용한 에이전트 시스템을 어떻게 구축할 수 있는지를 보여주는 좋은 사례가 됩니다.
이제 코드 에디터로 넘어갈게요.
작업 목표는 ‘양자 컴퓨팅(quantum computing)에 대해 조사해서 사이버보안에 어떤 영향을 미치는지에 대한 리서치 리포트를 작성하는 것’입니다. 저는 이 에이전트에게 “인터넷을 검색해서 정보를 종합하고, 그 정보를 정리해서 포맷된 파일로 결과를 제공해줘”라고 요청한 거예요.
MCP Agent 프레임워는 여러 개의 하위 에이전트(sub-agents)를 정의하고, 각자에게 고유한 역할을 부여합니다. 먼저 research agent라는 에이전트를 정의합니다. 이 에이전트는 “웹 리서치 전문가”라는 역할을 맡고 있어요. 인터넷에서 정보를 검색하고, 특정 URL을 방문한 다음, 그 데이터를 정리해서 파일 시스템에 저장하는 임무를 가지고 있죠. 이 에이전트에게 몇 개의 MCP 서버를 연결해볼까요?
- Brave: 웹 검색용 서버
- Fetch: 웹에서 실제 데이터를 가져오는 툴
- Filesystem: 로컬 파일 시스템 접근용 서버
이 MCP 서버들은 제가 직접 만든 게 아닙니다. 이름만 지정해주면 자동으로 연결되고 설치됩니다. 에이전트는 이 MCP 서버들을 바로 사용할 수 있게 됩니다. 다음은 fact-checker agent입니다. 이 에이전트는 research agent가 수집한 정보를 검증하는 역할을 합니다. 마찬가지로 Brave, Fetch, Filesystem MCP 서버를 사용합니다.
마지막으로 report writer agent가 있습니다. 이 에이전트는 앞서 수집된 데이터와 검증된 정보를 바탕으로 리서치 리포트를 작성하는 역할을 합니다. 이 에이전트에게는 파일 시스템과 Fetch 서버만 연결해줬어요. 인터넷 검색은 필요하지 않기 때문에 Brave는 포함되지 않았습니다.
각 에이전트가 어떤 MCP 서버에 접근 가능한지도 모두 명시되어 있고요. 이제 이 모든 에이전트를 실행시키면, 가장 먼저 실행되는 작업은 ‘계획(plan)’을 수립하는 것입니다. 계획이란, 이 에이전트가 어떤 작업 단계를 거쳐야 하고, 어떤 시스템과 상호작용해야 하며, 어떤 MCP 툴을 호출해야 하는지를 정리한 단계별 목록입니다.
예를 들어, 첫 번째 단계는 “양자 컴퓨팅에 대한 권위 있는 출처 찾기”입니다. 이 작업을 위해 Searcher 에이전트가 사용되고, 다양한 방식으로 MCP 툴을 호출합니다. 어떤 MCP 서버가 연결되어 있는지, 작업의 목표가 무엇인지 등을 바탕으로 계획을 자동 생성하죠.다음 단계는 정보 검증이고, 이때는 Fact-checker 에이전트가 동작합니다. 그 후 마지막 단계에서 Writer 에이전트가 모든 정보를 종합해서 최종 리포트를 작성하죠.
핵심은 이겁니다—MCP는 일종의 추상화 계층(abstraction layer)으로 작동합니다. 에이전트 개발자는 ‘서버 자체’를 신경 쓰지 않고, 오직 ‘에이전트가 어떤 작업을 해야 하는지’에 집중할 수 있게 됩니다.즉, “네가 할 작업은 이거야. 여기에는 이 서버를 사용하면 돼.”라고 선언만 하면 됩니다.
백그라운드에서는 다음과 같은 작업이 진행됩니다. 리서치 에이전트가 검색 툴을 호출하고, 팩트체크 에이전트가 검증 작업을 수행합니다. 왼쪽 화면에 출력 결과가 나타나기 시작할 거예요. 단순해 보일 수 있지만, 에이전트 개발자 입장에서는 매우 강력한 구조입니다. 이제 서버를 직접 만드는 데 집중할 필요 없이, 오직 에이전트의 루프 구조, 하위 에이전트의 작업 목표, 그리고 그 실행 흐름에만 집중할 수 있게 되었으니까요.
게다가 가장 좋은 점은—이 MCP 서버들은 제가 직접 만든 것이 아니라는 것입니다. 커뮤니티에서 만든 서버, 혹은 양자 컴퓨팅 관련 논문을 가장 잘 다루는 기관에서 만든 서버일 수도 있어요. 에이전트는 그저 이러한 서버들과 정해진 방식으로 인터페이스하면 되는 거죠.지금 왼쪽 화면을 보시면, Searcher 에이전트가 다수의 출처를 찾아 출력한 게 보이고, 최종 리포트 초안도 이미 작성되기 시작했네요. 이후에도 계속해서 백그라운드에서 작업이 이어질 겁니다.
자, 방금 보신 MCP Agent 프레임워크 데모는 실제로 MCP를 활용해 효율적인 에이전트를 구축하는 한 가지 방법이었습니다. 이제는 MCP 프로토콜 내에 존재하는, 에이전트 구축과 관련된 몇 가지 중요한 기능들을 더 살펴보겠습니다. 다만 여기서 소개할 기능들은 아직은 초기 단계이기 때문에, 향후 어떻게 발전할지는 더 지켜봐야 하겠습니다.
우선 MCP에서 가장 강력하면서도 아직 덜 활용되고 있는 기능 중 하나는 “샘플링(Sampling)”이라는 개념입니다.
샘플링이란 MCP 서버가 클라이언트에게 LLM 인퍼런스 요청, 즉 ‘모델 응답을 생성해달라’는 요청을 할 수 있도록 허용하는 기능입니다. 일반적으로 서버가 자체적으로 LLM을 실행하거나 Claude API를 호출하도록 구현하지 않아도 된다는 뜻이죠. 대신 MCP를 통해, 서버가 클라이언트에게 “이런 시스템 프롬프트와 작업 프롬프트, 이런 파라미터로 모델을 호출해줘”라고 요청할 수 있습니다.
이 구조에서의 장점은, 서버는 LLM의 실제 위치나 호스팅 방식에 대해 몰라도 되고, 클라이언트는 자신이 사용하는 모델이나 LLM 인프라에 대한 제어권을 유지할 수 있다는 점입니다. 예를 들어 서버는 아래와 같은 요청들을 할 수 있습니다:
- “Claude 3 같은 대형 모델을 최대한 써줬으면 좋겠어.”
- “온도 값은 0.7, 최대 토큰 수는 2048로 설정해줘.”
- “이 프롬프트를 시스템 메시지로 써줘.”
하지만, 클라이언트는 이 요청을 무조건 수락할 필요는 없습니다. 예를 들어 요청이 악의적으로 보인다든가, 너무 많은 비용이 든다든가 할 경우, 클라이언트는 요청을 거부할 수 있습니다. 클라이언트는 개인 정보 보호, 비용 제한, 허용된 호출 횟수 등 다양한 측면에서 제어권을 유지할 수 있어야 하며, MCP는 이를 고려해 설계되었습니다.
이 샘플링 기능은 특히 서버가 더 지능적인 판단을 할 수 있어야 하는 경우 유용합니다. 예를 들어 서버가 클라이언트에게 “이런 질문을 사용자에게 물어봐달라”고 요청할 수도 있고, 어떤 데이터를 받아오기 전에 사용자로부터 더 많은 정보를 요청해야 할 수도 있죠.
이러한 구조를 통해 서버는 ‘더 똑똑한 서버’가 될 수 있으며, 클라이언트는 LLM을 안전하고 유연하게 통제할 수 있게 됩니다.
다음은 “컴포저빌리티(composability)”라는 개념입니다.
MCP에서 클라이언트와 서버의 개념은 논리적인 분리이지, 물리적인 분리를 의미하지는 않습니다. 즉, 어떤 애플리케이션이나 API, 에이전트도 동시에 MCP 클라이언트이자 MCP 서버가 될 수 있습니다.
예를 들어 이런 구조를 생각해보세요. 최종 사용자가 Claude for Desktop을 통해 Claude에게 “이 정보를 찾아줘”라고 요청합니다. Claude for Desktop은 MCP 클라이언트로 작동하면서, 외부 MCP 서버—예를 들어 ‘리서치 에이전트’—에 요청을 보냅니다. 이 MCP 서버는 동시에 또 다른 MCP 서버들, 예를 들어 웹 검색 서버, 파일 시스템 서버, 페치(Fetch) 서버 등에 요청을 보냅니다.
결국 이런 식으로 호출이 체인처럼 이어지는 구조가 만들어집니다. 사용자 → 클라이언트/서버 조합 → 또 다른 클라이언트/서버 조합 → … 이런 식으로 다단계 체인이 형성되는 거죠.
이러한 구조 덕분에 LLM 시스템을 다양한 계층으로 쪼갠 복잡한 아키텍처를 설계할 수 있게 됩니다. 각 계층이 특정 역할을 수행하고, 서로 협력해서 정보와 작업을 계속하게 되죠.
이때 나올 법한 질문이 있습니다.
“이렇게 여러 계층이 생기면, 에러가 누적되어서 전체 시스템에 문제가 생기지 않을까요?”
사실 이건 MCP만의 문제는 아닙니다. 일반적인 다계층 에이전트 시스템에서도 마찬가지입니다. 각 계층(혹은 노드)은 자신이 호출한 하위 시스템의 결과를 받아서, 그 데이터를 검증하거나 정제하거나, 필요한 형태로 다시 정리해서 상위 계층으로 넘겨줘야 합니다.
즉, 이 구조에서는 각 계층이 스스로 책임지고, 결과의 품질을 보장하는 구조가 되어야 합니다. 이건 MCP가 특별히 어렵게 만드는 게 아니라, 오히려 MCP가 각 계층 간의 상호작용을 깔끔하게 정의해주기 때문에 더 관리하기 쉬워지는 셈입니다.
또 다른 질문이 있었어요.
“왜 이 서버들은 꼭 MCP 서버여야 하나요? 그냥 일반적인 HTTP API 서버면 안 되나요?”
사실 MCP 서버로 만드는 이유는, 단순한 ‘데이터 전달’ 이상을 가능하게 하기 위해서입니다. MCP는 일반적인 API처럼 단순히 요청에 응답하는 방식이 아니라, 각 서버(혹은 노드)가 ‘하나의 에이전트’처럼 작동할 수 있는 구조를 제공합니다.
예를 들어, 서버가 그저 데이터를 가져오는 역할만 하는 게 아니라, 그 데이터를 수집하기 위해 여러 작업을 비동기적으로 실행하거나, 중간 계산을 수행하거나, 스스로 다음 작업을 결정할 수 있는 지능을 갖도록 만들 수 있습니다. 이렇게 되면 각 MCP 서버는 단순 API가 아니라 ‘독립적인 지능형 단위’가 되는 것이죠.
그러다 보니 질문이 또 이어졌습니다.
“그럼 이 MCP 구조에서 호출 흐름, 레이트 리밋, 사용자 입력 등은 누가 제어하나요?”
답은 “상황에 따라 다르지만, 일반적으로는 가장 바깥 계층에 있는 클라이언트 애플리케이션이 제어권을 가집니다.” 예를 들어 Claude for Desktop이 LLM을 직접 제어하고 있다면, 결국 호출 흐름, 비용, 입력 타이밍 등은 그 애플리케이션에서 관리하게 되는 것이죠. 하지만 이건 고정된 규칙은 아니고, MCP는 매우 유연한 구조를 가지고 있어서, 각 단계의 MCP 서버가 자신의 LLM을 직접 운영하거나, 서버가 클라이언트를 호출할 수도 있도록 설계할 수 있습니다.
그리고 마지막으로 나왔던 질문 중 하나는 “서버가 서버를 호출할 수도 있나요?”라는 것이었는데요, 이건 기본적으로 가능하지만, 현재 MCP 프로토콜에서 공식적으로 1급(first-class) 기능으로 정의되지는 않았습니다. 다만 구조상 충분히 유연하게 설계되어 있어서 구현은 가능합니다. 그래서, 지금까지 MCP의 샘플링과 컴포저빌리티 기능에 대해 이야기했는데요, 이 두 가지 기능이 결합되면 아주 흥미로운 구조가 만들어집니다—바로 에이전트가 계층적으로 구성되는 구조예요.
예를 들어, 최종 사용자가 Claude for Desktop이라는 애플리케이션을 통해 Claude에게 직접 대화를 걸었다고 해봅시다. 이 Claude는 하나의 오케스트레이터 에이전트(Orchestrator Agent)입니다. 이 에이전트는 MCP 서버 역할을 하며, 동시에 MCP 클라이언트 역할도 수행합니다. 왜냐하면 이 에이전트는 또 다른 MCP 서버들—예를 들어 분석 에이전트, 코딩 에이전트, 리서치 에이전트 같은 하위 에이전트들과 통신해야 하니까요.
샘플링과 컴포저빌리티가 함께 작동하는 이 구조에서, Claude는 최종 사용자로부터 명령을 받은 뒤, 그 명령을 여러 하위 에이전트들에게 분산시켜 처리할 수 있습니다. 이 하위 에이전트들은 각각 또 다른 MCP 서버이자 클라이언트가 될 수 있고요. 이때 샘플링 기능이 중요해지는데, 각 하위 에이전트가 LLM 호출이 필요할 때, 샘플링을 통해 상위 클라이언트(Claude)에게 지능을 요청하게 됩니다.
이처럼 다층적인 호출 체인 속에서도, LLM의 실행과 제어는 가장 바깥쪽 애플리케이션에서 안전하게 관리할 수 있습니다. 덕분에 사용자는 보안과 프라이버시를 유지하면서도, 외부의 다양한 MCP 서버들과 유연하게 상호작용할 수 있게 됩니다.
🔐 보안, 인증, 그리고 레지스트리
이제 슬슬 “다음 단계”에 대해 이야기할 시간입니다. 레지스트리(Registry)와 디스커버리(Discovery)에 대한 내용도요.
하지만 그 전에 먼저 보여드리고 싶은 것이 있습니다. 바로 Inspector입니다.
Inspector는 여러분이 MCP 서버를 설치하고, 해당 서버와 어떤 상호작용이 오갔는지를 시각적으로 확인할 수 있는 툴이에요. Inspector에는 최근에 OAuth 인증 기능도 추가됐습니다. 몇 주 전, MCP 프로토콜에 OAuth 2.0을 공식적으로 통합했고, 이 기능이 Inspector와 다른 SDK들에도 점차 적용되고 있는 중입니다.
예를 들어, 제가 Slack과 통신하는 MCP 서버를 설치했다고 가정해볼게요. Inspector에서 이 서버의 URL을 입력하고 Connect 버튼을 누르면, OAuth 인증 플로우가 자동으로 시작됩니다. 서버는 Slack 측으로 인증 요청을 보내고, Slack은 callback URL을 생성해 서버에 반환합니다. 서버는 이 URL을 클라이언트에게 전달하고, 클라이언트는 브라우저를 열어 인증 과정을 진행합니다. 사용자가 Slack 계정으로 로그인하고 권한을 부여하면, 서버는 OAuth 토큰을 받아 저장하게 됩니다.
이후 클라이언트는 세션 토큰을 통해 서버와 안전하게 상호작용하게 됩니다. 이 구조 덕분에 서버는 애플리케이션과의 인증 관계를 완전히 통제할 수 있게 되고, 클라이언트는 세부 구현을 몰라도 서버와 상호작용할 수 있게 됩니다.
이 구조는 향후 “원격 서버(Remote Servers)”라는 개념을 가능하게 하는 핵심 열쇠입니다.
지금까지 MCP 서버들은 대부분 로컬에서 실행되었어요. 개발자들이 터미널에서 직접 실행하거나, 내 컴퓨터에 MCP 서버를 띄워놓고 사용했죠. 하지만 OAuth와 SSE(서버-센트 이벤트) 지원이 들어오면서, 이제는 완전히 원격에서 실행되는 MCP 서버를 만들 수 있게 됩니다. 마치 웹사이트처럼 말이죠. 사용자 입장에서는 그저 URL을 입력하고 접속하면 되고, 서버는 백그라운드에서 인증과 세션 관리를 다 알아서 처리합니다.
이렇게 되면 사용자들은 더 이상 “MCP가 뭐지? 어떻게 설치하지?” 같은 고민을 할 필요가 없습니다. 서버 개발자도 별도의 CLI, 표준 IO 같은 것에 얽매이지 않고, 서버를 어디서든 호스팅하고 제공할 수 있게 됩니다.
이제부터는 공식 MCP 레지스트리(Registry)에 대해 이야기해볼게요.
지금까지 MCP 서버들은 Anthropic에서 만든 예제들, 파트너사에서 만든 공식 서버들, 커뮤니티에서 만든 수천 개의 서버들이 각각 제각기 다른 레포지토리와 방식으로 배포되고 있었습니다. NPM에 올라온 것도 있고, GitHub에만 있는 것도 있고, 이름도 제각각이라서 검색조차 어려웠죠.
그래서 우리는 “공식 MCP 레지스트리 API”를 만들고 있습니다. 이 레지스트리는 MCP 팀이 호스팅하지만, 스키마와 메타데이터는 전부 오픈소스로 개발됩니다. 누가 만들었는지, 어떤 툴이 있는지, SSE인지 STDIO인지, 로컬 설치인지 원격 URL인지 등 MCP 서버에 대한 다양한 정보를 한 곳에서 조회할 수 있게 됩니다.
이 레지스트리를 통해 사용자는 ‘공식 Slack MCP 서버’나 ‘Shopify 서버’처럼 신뢰할 수 있는 서버들을 쉽게 찾고, 설치하거나 연결할 수 있게 됩니다. 나아가 각 서버의 버전 관리도 지원할 예정이라, 특정 버전의 툴 설명이 바뀌거나 기능이 추가되었는지도 추적할 수 있게 됩니다.
여기서 중요한 점은, 이 MCP 레지스트리는 중앙 집중형 서비스가 아니라는 거예요. 기업들은 자체적으로 프라이빗 레지스트리를 구축할 수도 있고, 레지스트리를 통합해 사내 툴 체계를 구축할 수도 있습니다. 예를 들어 Cursor나 VS Code 같은 앱 마켓과도 연결이 가능하죠.
그리고 또 하나—각 MCP 서버가 .well-known/mcp.json이라는 고정된 엔드포인트를 통해 자신을 외부에 알릴 수도 있게 만들고 있습니다. 예를 들어 shopify.com/.well-known/mcp.json 같은 주소를 통해 해당 사이트에서 제공하는 MCP 기능 목록과 인증 방식 등을 자동으로 가져올 수 있는 거예요. 이 방식은 MCP 레지스트리의 ‘탐색 기반 검색(discovery)’을 보완하는, ‘탑다운(top-down)’ 방식의 공식 채널 역할을 하게 됩니다.
🧠 MCP의 미래
자, 그럼 이제 거의 마지막입니다. 마지막으로 우리가 MCP의 미래를 어떻게 바라보고 있는지, 중기 로드맵을 간단히 공유드릴게요.
지금까지 말씀드린 내용 외에도, 중장기적으로 저희가 고민하고 있는 주제들이 많이 있습니다. 지금부터 소개해드릴 것들은 그 중 일부이고, 현재 저희가 얼마나 집중하고 있는지를 기준으로 대략 정렬해둔 것입니다.
첫 번째 주제는 바로 “상태 유지(stateful) vs 비상태(stateless) 연결”입니다.
현재 MCP 서버는 기본적으로 상태를 유지하는 방식으로 동작합니다. 즉, 클라이언트와 서버 간의 연결이 지속되고, 그 안에서 여러 작업과 문맥이 유지되죠. 그런데 많은 분들이 더 짧은 생명주기를 가진 연결—예를 들어 HTTP 요청처럼 요청과 응답만 주고받고 종료되는 구조—를 원하고 있습니다. 이유는 분명하죠. 사용자가 서버에 한 번 요청을 보낸 뒤 오랫동안 연결을 유지하지 않고, 잠시 오프라인 상태가 되었다가 다시 연결해도 이전의 컨텍스트가 유지되었으면 좋겠기 때문입니다.
이를 위해 저희는 “클라이언트가 서버에게 무언가를 요청하는 기본적인 능력”과, “서버가 클라이언트에게 뭔가를 요청하거나 알림을 보내는 고급 기능들”을 분리하는 방식으로 설계를 구상 중입니다. 예를 들어 고급 기능인 샘플링이나 서버-클라이언트 알림 기능은 SSE(서버-센트 이벤트) 같은 장기 연결을 요구하지만, 단순한 툴 호출 같은 기본 기능은 HTTP 기반의 짧은 연결로도 충분할 수 있습니다. 이 두 가지를 적절히 조합해 유연한 연결 방식을 지원하려는 것이 저희의 계획입니다.
두 번째는 “스트리밍(Streaming)”입니다.
지금 MCP는 서버가 클라이언트에게 데이터를 보낼 때, 하나의 응답으로만 전달됩니다. 하지만 어떤 경우에는 데이터가 순차적으로 여러 번에 걸쳐 도착해야 할 수도 있죠. 예를 들어 대용량 로그 파일이나 실시간 데이터 피드 같은 경우, 서버가 데이터를 한꺼번에 전송하는 것이 아니라, 여러 번 나눠서 스트리밍 형태로 보내는 게 훨씬 효율적일 수 있습니다. 이런 스트리밍 데이터 전송을 MCP 프로토콜 차원에서 1급 기능으로 지원하려고 합니다.
세 번째는 “네임스페이싱(namespacing)” 문제입니다.
현재 MCP에서 클라이언트가 10개의 MCP 서버를 설치했다고 해봅시다. 그런데 이 10개의 서버 모두가 create_file이라는 동일한 이름의 툴을 가지고 있다면, 충돌이 발생하겠죠. 지금은 이를 해결하기 위해 서버 이름을 툴 이름 앞에 붙이는 방식으로 대응하고 있지만, 이건 근본적인 해결책이 아닙니다. MCP 프로토콜 차원에서 네임스페이스를 구분하고, 툴 이름 충돌을 방지하는 방식이 필요합니다. 나아가 “재무 도구(finance tools)”처럼 관련 툴들을 하나의 패키지로 묶고, 로직상 그룹화할 수 있는 기능도 고민하고 있어요.
그리고 네 번째, 바로 “서버의 능동적 행동(proactive server behavior)”입니다.
지금까지 대부분의 MCP 상호작용은 클라이언트가 서버에게 요청을 보내는 방식이었습니다. 하지만 어떤 경우에는 서버가 먼저 클라이언트에게 말을 걸어야 할 수도 있습니다. 예를 들어, 서버가 파일을 새로 생성했거나 중요한 정보가 업데이트되었을 때, 클라이언트에게 이를 알려주고, 사용자에게 관련 조치를 요청할 수 있어야 하겠죠.
이런 기능을 위해 저희는 서버가 이벤트 기반으로 작동하거나, 혹은 서버 내부의 논리에 따라 “지금은 사용자에게 이걸 물어봐야겠다”는 판단을 내려, 클라이언트에게 먼저 요청을 보내는 구조를 추가로 고민하고 있습니다.
현재는 MCP가 이러한 기능을 직접적으로 지원하지 않지만, 명확한 패턴과 확장 가능성에 대한 설계를 진행 중입니다. 예를 들어 클라이언트가 “언제든지 나에게 요청해도 좋아”라는 준비 상태일 때, 서버가 어떤 이유로든 샘플링 요청을 보낸다든지, 혹은 새로운 리소스가 생성되었다고 클라이언트에게 알려주는 식의 동작이 가능해지는 것이죠.
더 많은 AI 강의가 궁금하다면? ↓
