▲

Web 2.0 2.0의 도래: MCP

 (anildash.com)
1P by GN⁺ 8시간전 | ★ favorite | 댓글 1개
  • Model Context Protocol(MCP) 이 빠르게 채택되며 새로운 개방형 표준으로 부상함
  • MCP의 핵심 가치는 완벽함이 아닌 개방성과 상호운용성에 있음
  • Web 2.0의 진정한 의미는 폐쇄적 플랫폼이 아니라, 오픈 API와 데이터 공유임
  • 과거의 폐쇄화 시대에서 다시 개방형 웹의 가치로 회귀하는 흐름이 일어남
  • MCP 채택으로 개발자들이 플랫폼 통제와 투명성을 더욱 요구할 가능성 제기됨

MCP: 새로운 개방형 웹의 등장

최근 몇 달 동안, 개발자들 사이에서 Model Context Protocol(MCP) 에 대한 관심이 폭발적으로 증가함. Anthropic에서 2023년 자체 LLM(Claude) 시스템이 다양한 앱과 상호작용할 수 있도록 설계한 것이 시작점임. 이후 OpenAI가 ChatGPT에 동일 프로토콜을 지원하면서 빠르게 표준으로 자리 잡음. 지금은 Windows에도 채택되는 등 주요 플랫폼으로 확대되는 중임.

흥미로운 점은 MCP 자체의 명확성이나 완성도보다는 사용의 편리함과 속도에 있음. 기존의 엄밀하게 설계된 전통적 표준과 달리, MCP는 다소 모호하고 느슨하게 정의된 사양임에도 불구, 실제로 잘 작동한다는 점이 중요한 강점임. 무엇보다 오픈 프로토콜로 누구나 활용 가능하다는 점이 중요성이 높음.

진정한 오픈 웹의 의미

실제 세계의 웹 환경에서는 완벽하지 않고 다소 부족한 표준들이 빠르게 채택될 때, 진정한 발전이 이루어짐. 이런 흐름이 "팟캐스트를 좋아하는 곳에서 언제든지 듣기" 같은 혁신을 만들어 냈음.

Web 2.0의 정신은 오픈 API, 데이터 공유, 이용자와 개발자의 통제력 증대 등 열린 생태계를 지향했음. Facebook 같은 폐쇄적 플랫폼은 Web 2.0을 소멸시킨 주체임에 주의해야 함. 과거 Flickr, del.icio.us, Upcoming 등은 공유와 연결을 중시하는 문화를 주도했으며, 라이브 블로그와 같은 플랫폼에서 API/프로토콜의 개방 표준 논의가 활발했음.

오픈의 부활

한 세대가 지나, 다시 상호운용성의 기대가 높아지는 시점임. 과거 대형 테크 기업들의 폐쇄 정책으로 API가 막히고 서비스가 사라지는 경험이 반복됐음. 예를 들어, 작성자가 구축한 소셜 네트워크 데이터 분석 툴은 결국 플랫폼 측의 API 차단으로 폐지됨. 이러한 정책은 Web 2.0의 오픈 데이터·호환성 비전을 무너뜨렸음. 이로 인해 콘텐츠 임베딩 불가, 데이터 이동성 저해 등 문제들이 일상적으로 발생함.

하지만 MCP의 등장으로 AI가 트리거가 되어 프로그램 가능성과 개방성의 재부상이 기대됨. 여러 플랫폼이 동일 프로토콜을 채택하는 것은 기술 기반의 선순환 구조를 가능하게 함.

플랫폼이 프로토콜을 그대로 받아들이고 표준화에 충실할 때 생태계 전체에 긍정적 변화가 일어남. "규격보다 더 잘 만들고 싶다"는 개발자의 욕심이 역설적으로 생태계를 저해할 수 있음을 강조함. HTML 등도 완벽하지 않은 스펙이지만 결과적으로 인터넷의 대규모 상호운용성 기반이 되었음.

표준 준수의 중요성

새로운 개발자 세대는 동일 프로토콜·포맷 기반 혁신의 강력함을 직접 경험함. 이러한 경험은 다시 개방형 표준에 대한 집착적으로 이어질 가능성이 높음. 과거 RSS, Podcast, OpenID, OAuth, OpenSocial 등 오픈 포맷이 실제로 사용자에게 힘을 실어줬던 시대와 유사한 분위기가 재현됨.

현재는 대형 기업의 전유물이 아닌, 개발자와 사용자 커뮤니티가 스스로 요구권을 행사할 수 있는 시점임. 모두가 플랫폼에 경험 통제·투명성을 요구할 수 있어야 하고, MCP와 같은 오픈 표준 도입 시 플랫폼 내부 동작과 데이터 활용의 투명성이 반드시 뒷받침되어야 함. MCP는 개방적이지만 여전히 내부 작동과 보안 이슈에서는 미흡하다는 점에서 후속 개선이 요구됨.

Web 2.0 정신의 부활 가능성

MCP가 모든 문제를 해결하는 만능 해법은 아니지만, Web 2.0 시절 열린 생태계의 부활을 자극할 계기가 될 것으로 보임. AI 논의의 과장, 비판 부재 등 한계는 여전함.

그러나 젊은 개발자를 중심으로 프로그래밍 가능한 웹, 폐쇄성 탈피의 가치는 재조명되고 있음. 웹은 일부 거대 기업만의 소유물이 아니라, 모두가 각자 원하는 방식으로 활용할 수 있는 열린 장이었고, MCP가 그 철학을 다시 불러올 수 있는 가능성이 제기됨.

▲
GN⁺ 8시간전  [-]
Hacker News 의견
  • 많은 사람들이 MCP의 핵심이 엔터프라이즈 소프트웨어에 적합하다는 사실을 간과하는 경향을 느끼는 입장임, LLM이 일종의 만능 번역기처럼 서로 연결하기 힘든 시스템을 이어주는 유연한 중간 레이어 역할이 가능하다는 점에서, 실제로 B2B SaaS 업계에서도 MCP 서버 도입이 활발하게 일어나는 중임, 회사 내부적으로도 API 사용 패턴에 맞춰 제한이나 구조를 조정하는 논의가 많아지고 있음, 프로토콜이 다양한 의미에서 “엔터프라이즈 레디”가 아니라고 해도 그게 크게 중요하지 않다는 견해를 가지는 중임, 표준 역사상 정제되지 않은 ‘엉성한’ 규격이 시장의 요구에 맞으면 결국 채택되는 사례가 흔했던 것임
    • MCP는 긴 연결에서 작동하는 RPC 같은 느낌이며 대체로 WebSocket 기반임을 이해하고 있음, 개인적으로는 RPC가 더 쉽다고 생각하는데, 그 이유 첫째는 REST 엔드포인트 설계에서 POST로 전체 대체할지 PUT으로 필드만 수정할지와 같은 불필요한 논쟁을 줄여줌, 둘째는 LLM이 REST 용어/시맨틱을 몰라도 되고 RPC 메소드만 보면 바로 호출하면 된다는 점임, 결론적으로 이 두 가지가 큰 강점임
    • 기업 관점에서 MCP가 훌륭한 수익 모델이라는 점을 짚고 싶음, 각 데이터 요청이 유료 LLM 실행과 직결되는 구조임, 반면에 MCP 도입으로 미래 쿼리를 더 저렴하게 만드는 스키마 협상 같은 최적화가 전혀 없는 상태라 아쉬움이 남음
    • 이미 rest와 openapi가 있어서 자체적 self-discovery(자동 탐색) 같은 기능을 지원하고 있음, MCP 제공할 기업치고도 어차피 다들 좋은 API를 제공할 것이라 믿는 입장임
    • 정말 공감하는 부분인데, 대규모 기업에는 9시부터 5시까지 멋진 작업만 집중적으로 하고 퇴근 이후엔 회사 생각조차 하지 않는 엔지니어가 많음, 그렇다면 기업 입장에선 업무 시간 한정으로 직원 생산성 극대화 기회를 잡는 것이 최고의 선택이라는 상식적 결과임
  • MCP 서버로 바퀴벌레 같은 생물을 제어하는 실험이 등장하기까지 얼마나 걸릴지 궁금증을 가짐, 실제로 과거 10년 넘게 로보로치 실험, 사이보그 바퀴벌레 등 많은 사례가 있었음
  • 예전에는 유닉스 개발자들이 철저히 사양 문서를 작성했지만 시대가 달라지면서, 이런 엄격함과 확장성(eXtensible)의 피로감이 XML 기반 아키텍처의 실패 요인 중 하나였다고 개진하고 싶음, 당시엔 XSL, XHTML, XSD, WSDL, RDF, RSS 등 지나치게 복잡했던 아키텍처였고 결과적으로 JSON 같은 단순 포맷이 인기를 얻은 배경임, 하지만 최근엔 XML 활용이 늘어나는 트렌드를 목격하기도 했음, 특히 Anthropic같은 LLM 시스템 프롬프트에서 XML이나 Markdown 같은 구조적 텍스트가 많이 쓰임을 체감함, 그러나 MCP 모델은 잘못됐다고 생각함, 모델에게 정보를 "끌어오라" 시키기보다는 "밀어주기" 방식, 즉 미리 문맥을 제공하는 게 더 나은 방식이라는 의견임
    • 흥미로운 점은 최근 JSON 기반 매크로 확장 언어를 만들면서 실은 XSLT나 XPath의 재발명임을 알게 되어, graph 탐색에 탁월한 xpath 사양에 감탄했던 경험임, BaseX 같은 툴로 임의의 XML을 DB로 끌어오고 XPATH/XQUERY로 질의할 수 있어 유용함, LLM에 헛소리 방지를 위한 확실한 데이터 인터페이스를 만든다고 하면, XML 스키마를 시스템 프롬프트에 집어넣고 데이터 질의문을 생성하게 하는 방법이 최고의 해법이라고 생각함
    • “문맥을 미리 푸시하는 모델”이 현실적으로 어떤 문제까지 대응 가능할지 의문임, 만약 사용자가 미리 정보를 알고 있다면 그냥 바로 문제를 해결할 것이고, 대부분의 MCP 수요는 “15개의 소스 연결법 공부하지 않고도 쿼리 처리만 해주라” 같은 요구임을 체감함
    • LLM이 tag 형태의 XML은 잘 처리하지만, 실제로는 대부분 제대로 된 XML 덩어리(<?xml version="1.0" encoding="UTF-8"?> 시작, 네임스페이스, 스키마 등)를 쓰지 않고 그냥 SGML 스타일 태그 모음 수준임을 지적함
    • 시맨틱 웹이 실패한 진짜 이유는 광고 삽입이나 비즈니스 모델 연계에 성공하지 못했기 때문이라는 현실적 원인을 강조하고 싶음
    • “문맥 푸시” 방식에 비판적인 입장임, LLM의 문맥 처리 용량(context window)은 매우 제한적이므로, 필요한 정보만 최소한으로 전달해주는 게 최적이라는 사실을 강조함, 개별 모델이 필요한 맥락만 직접 선택해 pull할 수 있을 때 한계 극복 가능성 높음
  • MCP가 AI의 인기로 인해 다양한 플랫폼이 어떤 목적으로든 프로그래밍 가능해질 거라는 희망을 심어주는 것 같지만, 오히려 실패할 운명이라고 생각함, 왜냐면 시맨틱 웹이 실패한 이유도 수익구조를 구축하지 못한 것이었음, AI가 웹을 대신 깊이 파고드는 “리서치” 기능도 마찬가지임, 예를 들어 레스토랑 메뉴를 메타데이터로 퍼블리싱해서 “텍사스에서 가장 저렴한 타코 찾기” 같은 자동화가 가능했지만, 현실은 데이터 락다운과 AI 크롤러가 이를 우회하는 인프라 경쟁임, 큰 틀에서 보면 현 시스템이 비효율적이라는 결론임
    • MCP도 결국 robots.txt가 진화한 형태일 뿐이라는 평가임, 본질적으로는 “내 리소스를 잘 설명해주면 활용하겠다” 모델임, 과거 90년대 Java 기반 에이전트 시스템도 에이전트 간 정보 비대칭 문제 때문에 실패했고, 이 디자인적 한계를 없애면 사회/비즈니스 전체가 작동을 멈출 수도 있다는 우려임
    • 오픈 API가 금전적 수익 문제 이전에, 실질적으로 무제한 리소스를 투입하지 않으면 AI 에이전트의 요청봇 물결이 자원 고갈을 일으켜 결국 파산한다는 경험적인 판단임, 장기적으로는 RPC pay-per-call 요금제가 안정적 대안이 될 거라 판단함, 모델·에이전트 운영자가 결제 클리어링 하우스 역할을 하며, 그 비용을 구독요금 등에 녹이는 방향이 유력하다고 예상함
    • HATEOAS 같은 REST 아키텍처 이상향이 2010년대 초반 대유행이었지만, swagger yaml 등 자동화 도구 외엔 실질적 확장 없이 사장됨, 용어부터가 너무 어려워서 실패 요인을 자초했다고 봄
    • 사람이 읽는 텍스트를 인공적인 장벽으로 치부하는 견해에 이견이 있음, 오히려 레스토랑에 JSON 생산 스킬 혹은 소프트웨어 도입을 요구하는 것이 실제로 인공적 장벽임, NLP 도구 덕분에 기존 데이터 그대로 활용이 가능해져서 개발 비용이 거의 0 수준으로 축소되어, 비록 언어적 비정확성은 있지만 그게 인간 언어 본연의 특성이므로 크게 문제를 삼지 않는 입장임
    • 시맨틱 웹 비판하는 와중에 언급해서 조심스럽지만, 실제로 원하는 레스토랑 사장님이면 언제든 메타데이터 퍼블리싱이 가능하고, 구매자와 판매자를 쉽게 연결시켜주는 계기가 될 수 있다고 생각함, WordPress 플러그인을 예로 들면 이미 schema.org/Restaurant, Menu, MenuItem, Offer 등 메타데이터 지원이 되고 있어서, 결국 최대 장벽은 Cloudflare 같은 게이트키핑이 아닐까 추정함, 실제로 Python 자동화 아이디어를 막는 실질적 요인임
  • LLM이 API 문서를 읽고 자동 적응할 수 있으므로, 표준 API 규격 준수가 이전보다 필수는 아니라는 생각임, MCP 규격 채택과 무관하게 각 사이트에서 ‘API 제공’이 기대된다는 자체가 큰 변화임
    • 실제 환경에서는 API 문서가 부실할 수도 있으므로 LLM이 잘못된 코드나 호출을 생성할 수 있고, 사용자가 수정해서 LLM에게 전달하면 결국 중간 계층(MCP식 서버)을 만드는 결과임, LLM에게 API 직접 접근권한을 줄 때는 보안 및 자원 관리 측면에서도 위험(지나친 호출 시 비용 폭탄 가능성)이 발생함, 여러 추가 pain point가 존재하는데 그 중 일부는 아예 중간에 MCP와 같은 인터페이스가 있는 구조에서 해결됨, 그 “중간자”가 굳이 MCP여야 하냐는 것은 다를 수 있지만, 현시점에서는 충분히 실용적인 솔루션임
  • MCP에서 가장 걱정되는 게 미흡한 프로토콜 수준이 아니라, Anthropic·OpenAI 같은 업체 내 팀에만 개선/수정 권한이 쏠려 있다는 점임, 실제 개발·운영자 중심이 아닌 브레인스토밍 단계에만 머무는 사양이라는 경계심도 들었음, 마치 Visa-Mastercard 듀오폴리 같은 그림자가 겹치는 느낌임
  • “시맨틱 웹”은 사실 문법 구조에 불과했고, MCP가 진짜 실질적 실현 가능성을 지니는 것 아닌가 하는 기대감이 있음
  • “주요 구식 유닉스 개발자들은 지나치게 까다로운 스타일이었다”는 인식이 있는데, 오히려 유닉스야말로 “빠르게 시도하고 깨부수기” 문화의 원조라는 점이 아이러니하게 느껴짐, 세대는 달라도 본질은 변하지 않는다고 생각함
  • MCP가 구글 검색엔진 최적화(SEO)처럼 AI를 향한 광고·스팸 확산에 악용될 수 있다는 현실적 우려가 있음
  • MCP 덕분에 모두가 각종 데이터에 쉽게 접근하게 될 거란 착각에 주의가 필요하다고 생각함, 실상은 여러 겹의 결제 인증, 허용된 white list IP 등 보안장치에 묶여서, 실제 유저에게는 “ERR 402” 에러만 돌아오는 현실이 더 공감감임
답변달기