MCP: (우연한) 범용 플러그인 시스템

• USB-C는 단순한 충전·파일 전송용이 아니라, 다양한 용도로 확장될 수 있는 범용성에서 가치가 있음
• MCP(Model Context Protocol) 는 원래 AI 어시스턴트용으로 설계됐지만, 실제로는 모든 데이터 소스와 툴을 연결하는 범용 플러그인 시스템이 될 수 있음
• NFT Base64 사례처럼, 프로토콜이 원래 목적을 넘어 현실의 데이터를 직접 저장·활용하는 방식으로 확장가능
• MCP 서버가 늘어날수록, 각 앱이 별도의 연동 없이도 다양한 기능을 손쉽게 가져다 쓸 수 있음
• USB-C처럼 MCP도 '무엇이든 연결할 수 있는 가능성의 공간'으로, 예상치 못한 혁신을 만들어내는 기반이 될 것

---

MCP: An (Accidentally) Universal Plugin System (Or: The Day My Toaster Started Taking Phone Calls)

USB-C와 예기치 못한 범용성

• USB-C는 모두가 충전이나 파일 전송을 위한 용도라고 생각했으나, 그 구조 덕분에 다양한 용도로 확장 가능함
• 필자의 친구 Rex가 토스터를 모니터에 연결하여, 토스터가 HDMI 출력 기능을 갖게 된 사례에서 USB-C의 무한한 가능성을 보여줌
• 이는 USB-C가 전력 및 데이터 규격에 신경 쓰지 않고, 단자만 맞으면 무엇이든 연결 가능한 구조이기 때문

자동차 시거잭의 원리

• 자동차 시거잭은 원래 담배 점화용이었지만, 이제는 다양한 범용 전원 포트로 사용됨
• 시가잭처럼 프로토콜은 사용자의 선택을 제한하지 않고, 다양한 용도를 허용함
• MCP도 이와 유사한 확장성을 지님

MCP의 재발견: 우연히 범용 플러그인 시스템으로

• 흔히 MCP(Model Context Protocol) 가 AI 비서(예: Claude) 등이 데이터를 활용하도록 하는 용도라고 알려짐
• 공식 문서에도 "AI 모델을 여러 데이터 소스 및 도구에 표준적으로 연결"한다고 명시되어 있음
• 하지만 만약 AI 요소를 제외한다면, MCP는 "어떤 것이라도 서로 다른 데이터 소스 및 툴에 연결"하는 수단이 됨
• 이는 기존 목적과 무관하게 범용 연결 프로토콜이 되는 셈임

The NFT Base64 Revelation

• NFT가 원래 이미지를 참조하는 용도였으나, 어느 순간 참조 자체가 데이터가 됨
• 프로토콜 본래 취지가 바뀌면서 라이브러리 카드가 실제 책 역할을 하게 됨
• 원래 의도보다 훨씬 더 넓은 현실의 데이터를 직접 다루는 도구로 변모

누구도 예상치 못한 네트워크 효과

• MCP 서버가 AI용으로 늘어날수록, 누구든 별도의 개발없이 모든 앱이 새로운 기능을 획득하는 효과 발생
• 예를 들어 누군가가 Spotify MCP 서버를 만들면, 운동 앱이 MCP를 통해 자동으로 플레이리스트 생성 가능
• 서로 알지 못하는 개발자와 앱이 자연스럽게 연결되어 모두가 이익을 얻는 네트워크 효과가 발생
• 각 MCP 서버는 범용 플러그인으로 재활용될 수 있음
• 아무도 기획하지 않았지만, 우연하게 범용 플러그인 생태계가 만들어짐

USB-C의 의미와 MCP의 철학

• MCP를 종종 AI의 USB-C에 비유하는데, USB-C가 특별한 것은 단순한 포트가 아니라 무엇이든 연결할 수 있는 가능성의 공간이기 때문임
• USB-C가 전력, 데이터, 영상, 기타 미지의 기능을 받아들이듯, MCP도 'AI용'이 아니라 '기능을 위한 잘 설계된 구멍' 역할로, 누구든 어떤 기능이든 연결 가능

The Part Where I Tell You I'm Building Something

• 필자는 APM(Actions Per Minute) 이라는 작업 관리 앱을 개발 중임
• APM은 플러그인 시스템으로 전적으로 MCP 서버만을 사용해서 동작함
• 사용자는 원하는 기능을 추가할 때마다 MCP 서버만 연결하면 됨(예: 맞춤법 검사, 커피 자동 주문, 게임 캐릭터 리액션 등)
• 이는 앱 자체가 유동적이고 다양한 형태로 변신할 수 있는 구조

The Toaster Protocol Principle

• 모든 위대한 프로토콜은 처음 의도와 다르게, 예상치 못한 용도로 사용되어 혁신을 만듦
  • HTTP: 학술 논문용 → 문명 인프라
  • Bluetooth: 핸즈프리 → 현관문 잠금 해제 등
  • USB: 입력장치 → 휴대용 선풍기 충전 등
• MCP 역시 원래는 AI 컨텍스트 전달용이지만, 본질적으로는 모든 것과 모든 것을 연결해주는 프로토콜임
• 예측불허의 혁신을 만드는 플러그인 생태계의 기반임을 강조
• 전혀 의도하지 않았지만, 토스터와 모니터를 HDMI로 연결하는 시대에 꼭 맞는 방식임

마무리

• PS: 만약 MCP 서버로 신선한 빵 냄새를 내는 컴퓨터를 만든다면, 꼭 연락을 바람
• PPS: APM의 얼리억세스을 공개했고, 기발한 시도와 창의적 실험을 장려함
• (어딘가에서는 프로토콜이 본래 목적대로 쓰이고 있음. 이건 매우 의심스러움)

[a1eng0]

MCP 서버의 응답은 정해진 schema가 없이 자연어인 경우가 높습니다.

이 자연어 응답을 LLM 없이 programming 적으로 처리하긴 어려울거에요.

[winterjung]

참고로 mcp 2025-06-18 명세에 새롭게 structed tool output이 추가되면서 응답 schema 기술이 가능해졌습니다. 기존 구현된 mcp 툴은 말씀하신대로 대부분 unstructured 겠지만 앞으로의 mcp 툴엔 기대해볼만해보여요.

[GN⁺]

Hacker News 의견

• 나는 이 글과 MCP 프로토콜이 정말 마음에 든다는 생각. 하지만 MCP를 보면 왠지 마이크로서비스와 SOA가 떠오른다. 새로운 장애 지점을 만들어내는 악몽이 반복되는 건 아닐지 걱정이 든다. 아니면, 에이전트 도입 덕분에 신뢰성 향상이 더 자연스럽게 이뤄질 수 있다는 기대감도 있다

• 나는 글의 생각에 공감하고 있고, 저자가 MCP 활용법을 (약간 엇나가게) 사용하는 점이 참 재밌다. 이 사고의 진짜 핵심은 전에 없던 새로운 일들을 하게 해주는 프로토콜 등장 자체가 아니다. 사실 다른 댓글처럼, MCP 그 자체는 특별히 새롭거나 흥미로운 아이디어가 아니다. 정말 흥미로운 부분은 AI 에이전트 열풍 덕분에 상호운용성(Interoperability)이 주목받으면서 벤더 락인(vendor lock-in) 문제가 시대에 뒤처진 것으로 취급된다는 사실이다. 이 현상이 얼마나 오래 갈지는 모르겠지만 덕분에 기분이 좋은 상황이다

  • 나는 이를 보면 윈속(Winsock) 도입 당시가 생각난다. 윈도우즈에서 네트워크 관련 모든 작업이 한때는 제각각의 사적 인터페이스를 썼다. 그러다 여러 벤더가 한자리에 모여 모두에게 이득이 되는 공동 표준을 만들기로 결정했던 날이 있었다는 스토리 기억. Winsock 위키피디아 참고
  • 핵심은 단순히 상호운용성이 유행이 됐다거나 손쉽게 연결될 수 있다는 점이 아니다. 진정한 혁신은 LLM 자체가 툴을 다루는 방법을 익혔다는 사실이다. 백엔드를 만드는 것까지만 하면 프론트엔드는 더 이상 내 일이 아니고 AI가 알아서 해결해주는 변화다. Claude와 Gemini도 목적만 제시해주면 도구 활용을 스스로 해낸다. 예전에는 항상 원하는 결과를 얻기 위해 단계별로 명확히 절차를 짜줬어야 했는데 이젠 고정적인 프로그램보다 LLM이 유동적인 상황에 훨씬 더 잘 적응해서 엄청난 변화라는 인식
  • 과한 기대감이 느껴지는 상황이다. 하지만 내 생각엔 AI 에이전트들이 상호운용성에 대한 동기를 확실히 만들어줬다. 과거에는 모두가 각자 시스템에서 느리게 일하면 안정적인 직업 보장이 됐지만, 이제는 모두가 모든 걸 연결하려는 추세다. CEO가 해커톤에 피자 심부름 직접 나서는 게 더 싸게 먹히는 식의 변화처럼, 에이전트는 연동성에 의존한다. 과거 API 연동 혁신의 파도에 직접 탔던 입장에선, 이제야 세상이 따라잡았다는 느낌. 이 분위기가 오래가길 바란다
  • AI 에이전트 열풍이 상호운용성 유행을 이끌고 벤더 락인이 구시대적인 것이 되었다는 지적, 완전히 동의하지 않는다. 최근 주목받고 있는 Cursor 같은 툴도 MCP를 일방향으로만 쓸 뿐 밖으로 대화 이력이나 컨텍스트를 내보내지는 않는다. Cursor를 좋아하지만, 오픈소스가 아닌 VS Code 포크부터 이런 '돌려주지 않는' 마인드는 개발자 신뢰에 부정적 영향을 줄 거라 본다. 결국 락인은 여전히 견고하다는 현실
  • 아이러니하게도, 최근 API 접근 제한 조치들은 AI 데이터 학습과 관련해서 더 심해진 상황이다. 사실 이런 API 락다운은 훨씬 이전부터 있었고, 새로운 개방 트렌드가 과열 기대감을 못 따라가면 언제든 다시 닫힐 수 있다는 회의적인 시각도 있다

• 저자가 MCP의 범용성에 큰 기대를 걸고 있지만, 솔직히 API라는 개념 자체와 뭐가 다른 건지 의문. MCP 대신 REST로 바꿔도 글의 내용이 크게 달라질까? 운영체제 API나 POSIX, 유닉스 파이프도 유사성이 있다. 물론 MCP가 이 모든 것보다 훨씬 더 단순하고 범용적이다. 하지만 진짜 해법은 매번 새로운 추상화를 만드는 게 아니라, 기본에 충실하고 단순한 소프트웨어를 만드는 것 아닐까 생각

  • MCP는 REST와 다르다. 오히려, MCP는 런타임에서 REST 엔드포인트를 동적으로 발견하게 해주고 사용자가 직접 어떤 REST 엔드포인트를 활용할지 설정하는 프로토콜 같은 느낌이다. 예를 들어, 앱에서 Spotify 노래를 재생시키려면 당연히 Spotify API를 쓴다. 나중에 Sonofm의 곡도 지원하고 싶으면 기존 방식은 코드 수정, 조건문 추가, 새로운 버전 배포, 업데이트 안내 등을 해야 한다. 반면 MCP는 이런 작업을 런타임에 설정할 수 있게 해주어 확장성이 훨씬 높게 느껴진다
  • 핵심 차이점은 MCP는 처음부터 자기 기술이 의무라는 것. REST도 OpenAPI가 있지만 이건 후속 덧대기고, 표준 활용도도 낮다. 반면 MCP는 가장 먼저 기술을 공개하도록 요구하기에 접근성이 다르다
  • 내가 보기엔 MCP가 정말 새롭다고 느낀 건 프로토콜 차원에서 스키마 제공을 의무화했다는 점 뿐이다. 물론 요청과 응답 구조가 일관된 건 동적 타입을 정적 타입으로 감싸는 라이브러리 입장에서도 관리가 편하긴 하다. 사실 모두가 API에서 이미 유사하게 하고 있었다. 우리가 그 envelope 형태에 합의하지 못했을 뿐이다. 애초에 스키마 제공이 필수이고, AI 모델들이 이걸 즉시 활용할 수 있다는 메리트가 있기 때문에 각광 받고 있다는 생각
  • MCP와 REST가 크게 다른 점은 list-tools라는 내장 명령 존재다. REST API는 리소스 목록화에 여러 방법이 있지만 MCP는 하나의 표준화된 방법만 제공
  • 또 하나의 커다란 차이점은 MCP는 프로토콜에 자체적으로 discovery(발견) 절차가 내장되어 있다. REST에는 어떤 리소스가 가능한지, 클라이언트에게 API 기능 자체를 알려주는 요소가 전혀 없다

• MCP를 두고 대단하다고 말하는 사람은 많은데, 실제로 멋진 걸 만드는 사례는 별로 못 본 것 같다. 블록체인 유행 때와 비슷한 기분. 결국 MCP도 AI가 더 똑똑해질 때까지의 임시방편 같다는 생각이 든다. 2년쯤 뒤에는 MCP 대신 도구의 문서나 OpenAPI만 그대로 넣고 AI가 직접 전체 컨텍스트를 소화하는 방식으로 자연스럽게 발전할 것 같다

  • 예를 들어, Ableton Live의 문서만 넣는다고 Claude가 직접 곡을 만드는 데 어떤 도움이 될지 의문
  • 모델 성능이 아무리 좋아져도, 결국 확정적인 도구 접근과 세상 상태에 대한 정보를 직접 부여하지 않으면 활용도가 많이 제한된다. 그리고 보안 문제도 고려하면 제어 없이 모델이 프로덕션에서 임의로 요청을 내게 할 수 없다. MCP의 과열 분위기는 조금 과하다 생각하지만 그래도 여기서 말하는 문제 자체는 실제로 중요하다. 만약 이 프로토콜 덕분에 개발자들이 기능을 명확하게 API로 개방하게 된다면 그건 무척 기대되는 일이다
  • 블록체인 유행과 MCP는 꽤 다르다. 나도 초기엔 회의적이었는데, 직접 MCP 서버를 조금 구현해 보면 전혀 다른 경험이라는 걸 알게 된다. 대화형/음성 AI와 현행 LLM, 여기에 MCP와 각종 툴, 함수 기능을 API 및 프라이빗 데이터/서비스와 섞는 게 가능해지니 완전히 새로운 프론티어에 들어선 감각이다. 100% 완벽하진 않지만 거의 대부분의 실사용 사례에는 충분하고, 앞으로 앱 만드는 방식 자체가 크게 변할 전망
  • 실제로 나는 주(州) 내 의원들이 이번 주에 한 활동이 궁금해서, 관련 정보를 쉽게 찾을 길이 없던 차에 MCP와 congress.gov API가 매력적이라는 얘기를 듣고 MCP 서버를 만들어봤다. 여기서 코드 공개. 지금은 미국 국회 동향을 실시간으로 찾는 용도로 진짜로 잘 쓰고 있다
  • AI 모델 구조가 계속 진화하는 한, 중간 미들웨어(즉, MCP) 층은 쉽게 사라지기 어려울 거라 본다

• 나는 Microsoft가 늘 해왔던 "Embrace, Expand, Extinguish" 전략이 여기도 적용 중이라는 생각이다. 시스템 안정성과 보안을 이유로, 아무런 관리 없이 에이전트가 동적으로 도구를 찾아내면 충돌 위험이 커지기 때문. PydanitcAI 등 대체재들이 있지만 결국 Microsoft가 MCP를 'Build 2025'에서 공식적으로 밀고 나와 자신의 페이스대로 업계를 이끌어가고 있다. Anthropic은 도구 약하고 거버넌스 부재 상태로 표준을 내놨으니 Microsoft가 점령하기 쉬운 구도. 다음 단계는 Microsoft가 자신의 레지스트리를 업계 표준으로 만들고, Windows 특화된 명령과 결합하는 시나리오. 마지막엔 '보안' 기준을 자사에 유리하게 좌우해 경쟁자를 소외시키는 그림이 그려진다

• AI 요소를 아예 빼버리면 어떨까? 만약 AI 미들웨어 없이 MPC 서버에 직접 의존하게 되면, 곧바로 하위 호환성 문제에 봉착하게 된다는 우려. 왜냐하면 MCP 서버들은 호출하는 쪽이 AI 알고리즘이라 가정하고 있어 도구나 입력/출력 스키마에 기반한 깨지는 변경(브레이킹 체인지)이 언제라도 있을 수 있기 때문

• 나도 비슷하게 생각해봤지만 실제로 MCP 서버 대부분은 기존 API의 새로운 클라이언트에 불과하지 않을까 생각하게 된다. 예로 Kagi MCP 서버는 Kagi API만 호출한다. 그렇다면 어차피 API를 직접 쓰는 게 더 낫지 않을까? 또, 시스템에 MCP 서버 수만큼 파이썬 인터프리터가 계속 늘어나게 될 텐데, 이걸 다 모아서 한 번에 브릿지해주는 '호스팅' 서비스가 앞으로 나오지 않을지 궁금하다

  • 내가 이해한 바로는 MCP란 건 기존 API에 /list-tools라는 엔드포인트 API만 하나 더 붙이는 셈이다. 모든 클라이언트는 먼저 /list-tools에 접근해 사용 가능한 도구 리스트를 받아와서 이후 각각의 API를 호출하는 방식
  • 내 접근법은 이렇다. 이미 OpenAPI 스펙이 있는 API가 있다면, FastMCP로 그냥 래핑하면 되는 것 아니냐는 생각. 실제로 인증 요청 처리 등을 하면서 Goose에 연동해봤는데, 결론은 Goose가 기존 API 라우트에 curl 명령만 날리면 끝이란 점. OpenAPI 스펙이 충분히 잘되어 있으면 MCP는 꼭 필요하지 않을 수 있다는 견해. 물론 기존 API가 없다면, MCP 서버 자체가 핵심 동작을 실현해버리는 쪽으로 진화한다고 보는 듯

• 댓글엔 회의적인 시각이 많아서 공감이 된다. 지난주 MCP 서버를 직접 구현해봤는데 솔직히 '잘 설계됐다'는 과찬이라고 본다. MCP 목표 중 하나가 '간단하게 만들 수 있게 하자'라는 점이지만, 실제 해보면 그렇게 쉽지만은 않다. 그래도 중요한 것은 지금 수많은 개발자들의 시선이 한 방향으로 쏠리고 있다는 점이다. 이런 모멘텀에서는 문제 해결 속도가 무척 빨라질 수 있다. 또, 뭔가에 비판적 질량이 형성되어야 생태계가 갖춰지는데, 지금 그 변곡점이 실제로 오고 있다 느껴진다. 모두가 인내심과 행운을 누리길 응원

  • MCP Python 라이브러리만 쓰면 정말 쉽다. 함수에 데코레이터만 달면 도구가 바로 완성된다. 나도 MCP 프로토콜을 아예 몰랐지만 그 방식으로 잘 돌아가고 있다. 물론 직접 프로토콜을 구현해야 한다면 사정이 다를 수도 있다
  • MCP 서버는 "기존의 공용 또는 준공용 API"만 다시 노출하면 된다. 가능한 원래 엔드포인트의 최소한의 변경으로 구현할 수 있어야 한다는 관점이 설득력 있다
  • 과거에도 이런 시도가 있었지만, 결국 몇 년이 지나면 앱들이 엔드포인트를 잠가 버려서 chatgpt, claude 등 특정 서버만 접근할 수 있게 막는다. 상호운용성은 사실상 사용자 이동성이기도 하고, 현실적으로 많은 기술 회사는 이동성보다 락인과 독점을 지향한다

• 기술 채택과 확산을 위해 접근 장벽을 낮추는 일이 역사를 통틀어 중요한 역할을 했다는 점을 강조. MCP도 그 연장선이고, 무시해서는 안 된다. 우리 팀에서도, 기술배경이 전혀 없는 사람이 파일 공유 작업을 자동화하는 에이전트를 직접 쓸 수 있었다. 물론 예전에는 수백 개의 프로그래밍 언어나 라이브러리, API로만 가능했지만, MCP 덕에 비전문가도 신경 쓰지 않고 바로 해결하는 시대가 됐다. 성능 면에서는 최고가 아니고 최적의 구현 역시 아니지만, 이런 새로운 방식이 가져오는 가치는 지금 자원과 기술 수준에서는 전례가 없었다. 그런 점이야말로 진짜 핵심

  • 기술자가 아니라는 팀원이 파일 공유 정리를 혼자 잘했다는 이야기는 과장이라고 본다. 수천개 파일 정리라면 몰라도, 내 경험으론 거의 모든 파일 공유 정리 시도에서 관련 부서의 협조조차 얻기 힘들었다. 업무 담당자들조차 본인이 할 일도 아닌데 싫어한다. 고위 임원까지 동원해 겨우 설득하거나, 같이 앉아서 파일 구조만 한 시간 짜내는 일도 힘들었다. 작업량 중 50%는 부서 간 정치, 20%는 절차 갱신, 20%는 교육, 기술적 문제는 10%뿐이었다. 크고 작은 재앙, 끝없는 혼란까지 겪었는데, 아무리 AI 도구가 쉽게 만들어준다고 해도 현실이 그렇게 간단할 리는 없다는 생각. 수개월 뒤 백업 복구작업 하게 될 것 같다는 회의적인 예측

• "AI 에이전트가 워크래프트 3에서 피온처럼 명령받고 대답해줬으면 좋겠다"는 농담, 나는 차라리 요트 타고 싶다는 답변

  • "I'd rather be sailing"은 워크래프트 2 대사고, 워크래프트 3에선 "I'd rather be flying"이라는 대답이 나온다는 점을 짚어주고 싶다