Web 2.0 2.0의 도래: MCP

 (anildash.com)
2P by GN⁺ | ★ favorite | 댓글 1개
  • Model Context Protocol(MCP) 은 Anthropic이 LLM과 외부 앱·시스템을 연결하려 만든 명세로, OpenAI가 ChatGPT에서 지원한 뒤 여러 플랫폼의 공통 인터페이스처럼 확산됨
  • 명세가 느슨하고 불완전해도 여러 참여자가 빠르게 같은 방식을 채택하면 실제 웹에서는 열린 프로토콜이 힘을 얻을 수 있음
  • Web 2.0의 원래 가치는 폐쇄형 소셜 사이트보다 오픈 API와 상호운용 가능한 도구가 만든 개발자·사용자 생태계에 가까웠음
  • Facebook과 Twitter 같은 대형 플랫폼이 API를 닫으며 약해진 상호운용성의 기대를, MCP가 AI 코딩 도구의 흐름 속에서 다시 프로그래밍 가능한 플랫폼으로 되살릴 가능성이 있음
  • MCP는 만능 해법이 아니고 데이터 처리 불투명성과 보안 위험도 크지만, 표준 준수와 투명성을 요구할 새 계기가 될 수 있음

MCP가 표준처럼 확산된 배경

  • Model Context Protocol, 즉 MCP는 Anthropic이 Claude를 위해 설계한 명세임
    • LLM이 여러 앱에 정보를 요청하거나 다른 시스템과 상호작용할 수 있게 하는 목적을 가짐
  • OpenAI가 몇 달 전 ChatGPT에서 같은 프로토콜을 지원하면서 MCP는 여러 곳에서 채택되는 표준처럼 자리 잡음
  • Windows에도 MCP가 포함되며 확산 범위를 보여줌
  • 중요한 지점은 명세의 완성도보다 여러 플레이어가 같은 인터페이스를 빠르게 채택했다는 사실임
  • MCP는 느슨한 명세에 가깝지만, 열려 있고 작동한다는 점에서 웹의 성공 방식과 닮아 있음

Web 2.0이 원래 가리킨 것

  • Web 2.0은 Facebook 같은 폐쇄적이고 독점적인 사이트를 뜻하는 말이 아님
  • 초기 Web 2.0 커뮤니티의 중심에는 여러 사이트가 오픈 API를 제공하고, 개발자와 사용자가 사람과 데이터를 연결할 수 있게 하는 흐름이 있었음
  • Flickr, Del.icio.us, Upcoming은 태그와 소셜 공유 같은 기능을 개척한 시대의 대표적 사이트였음
  • LiveJournal과 Movable Type 같은 플랫폼도 API와 프로토콜을 둘러싼 오픈 표준 작업에 영향을 줌
  • 당시의 공유 가치는 비교적 분명했음
    • 도구, 기술, 플랫폼을 열린 데이터와 열린 프로토콜 위에 구축함
    • 사용자가 통제권을 가짐
    • 개발자가 일관되고 상호운용 가능한 도구로 시스템과 상호작용함

폐쇄형 플랫폼이 끊어낸 상호운용성

  • 한 세대 동안 개발자가 앱과 플랫폼 사이의 상호운용성을 당연하게 기대하기 어려워짐
  • 대형 VC와 기술 업계 리더들이 개방성의 시대를 끝냈다는 비판도 따라붙음
  • 소셜 네트워크 활동을 분석하는 도구는 대형 소셜 네트워크 플랫폼들이 API를 닫으면서 제품과 사용자 기반 서비스가 중단되는 사례를 겪음
  • Facebook과 Twitter 같은 플랫폼은 많은 사람에게 열린 데이터와 상호운용 가능한 기술이라는 Web 2.0의 기대를 무너뜨림
  • 그 결과 사용자가 자기 네트워크를 원하는 방식으로 다루기 어려운 상황이 일상화됨
    • Twitter 타임라인에서 임베드된 Instagram 사진을 볼 수 없음
    • fediverse나 Bluesky에서 가능한 팔로워 가져오기·내보내기 같은 기능을 쓰기 어려움
    • 원하는 앱으로 자신의 네트워크를 제어하기 어려움

MCP가 다시 열 수 있는 가능성

  • MCP의 부상은 AI가 코더들 사이에서 인기를 얻는 흐름과 맞물려, 플랫폼이 LLM뿐 아니라 다양한 프로그래밍 목적에도 열릴 수 있다는 기대를 만듦
  • Anthropic이 만든 명세를 다른 플랫폼들이 그대로 채택한 점이 핵심임
  • 다른 회사의 프로토콜을 충실히 두 번째로 채택하면, 생태계 전체가 같은 방식으로 더 쉽게 작동할 수 있음
  • 반대로 프로토콜을 베끼고 확장한 뒤 결국 없애는 방식은 생태계를 해칠 수 있음
  • 같은 인터페이스를 쓰겠다는 선의의 채택이 있을 때, 여러 도구와 플랫폼이 함께 작동할 여지가 커짐

표준을 그대로 따르는 일의 어려움

  • 표준을 그대로 지원하는 일은 보기보다 어려움
  • AI 플랫폼용 시맨틱 캐싱 제품을 출시할 때도, 개발자들에게 일반 ChatGPT API를 그대로 쓰게 설득하기가 쉽지 않았음
  • 개발자는 “더 좋게 만들 수 있다”고 생각하기 쉽지만, 표준과 달라지는 순간 오히려 더 나빠질 수 있음
  • 불일치가 많은 나쁜 명세라도 모두가 같은 방식으로 구현하는 편이 더 중요할 때가 있음
  • HTML도 많은 것이 빠진 불완전한 명세였지만, 웹은 그 위에서 만들어짐
  • 인터넷 전체도 여러 불완전한 명세 위에 놓여 있음

표준 준수와 투명성 요구

  • 새 세대 개발자는 좋아하는 도구와 플랫폼이 같은 프로토콜과 형식을 쓸 때 생기는 창의성과 가능성을 경험하고 있음
  • RSS, 팟캐스팅, OpenID, OAuth, OpenSocial 같은 흐름은 일부가 나중에 fediverse와 ActivityPub 같은 결과로 이어짐
  • 개발자, 코더, 기술 애호가, 일반 사용자도 플랫폼에 코드로 경험을 제어할 접근권을 요구할 수 있음
  • MCP 같은 열린 표준으로 접근할 때는 플랫폼이 실제로 무엇을 하는지에 대한 투명성도 함께 요구해야 함
  • MCP는 유연하지만 여러 위험을 남김
    • 플랫폼이 사용자 데이터를 어떻게 다루는지 불투명함
    • MCP를 통한 상호작용에서 어떤 동작이 발생할지 알기 어려움
    • 보안 위험이 매우 큼
    • 프로토콜은 이런 우려를 충분히 다루지 않음

Web 2.0식 개방성의 한계와 기대

  • MCP가 개발자 생태계의 모든 문제를 고치는 만능 해법은 아님
  • AI를 둘러싼 과장과 논의의 왜곡을 바로잡지도 않음
  • 다만 이전 세대의 Web 2.0 시기를 경험하지 못한 젊은 개발자들이 MCP를 계기로 웹을 원래의 아키텍처에 가깝게 되돌리려 할 가능성이 있음
  • 웹은 독점적이거나 소수 대기업의 몇몇 인물이 통제하는 구조로 의도된 것이 아님
  • 웹은 모두가 서둘러 채택한 거친 명세를 통해 프로그래밍 가능해야 했고, 그런 해킹 가능한 즐거움은 웹에 버전 번호가 붙기 전부터 존재했음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • MCP에서 많은 사람이 놓치는 건, 이게 엔터프라이즈 소프트웨어에 잘 맞는다는 점임
    LLM은 범용 번역기라서, 중간에 어느 정도 느슨한 계층이 없으면 연결하기 극도로 어려운 단절된 시스템들을 이어 붙이는 접착제로 적합함
    그래서 B2B SaaS 업계가 MCP 서버를 내놓고 있고, 내부적으로는 달라진 사용 패턴에 맞춰 API와 그 제한을 어떻게 다시 설계할지 논의하는 것임
    프로토콜이 여러 정의에서 “엔터프라이즈 준비 완료”는 아니지만, 작성자가 말하듯 그게 아주 중요하진 않음. 표준의 역사를 보면 지저분하고 “나쁜” 것들도 적절한 시점에 적절한 사람들에게 맞아떨어지면 널리 채택됨

    • MCP는 긴 연결 위의 RPC일 뿐이고, 대부분은 WebSocket임. 내 생각엔 RPC가 설정하기 더 쉬움
      사용자 객체의 필드를 바꾸는 게 원래 사용자 객체를 대체하는 PUT인지 POST인지 같은 논쟁이 줄어듦. REST 동사 두고 꽤 많은 시간을 소모해 봤음
      LLM도 API의 REST 의미론을 이해할 필요가 없음. 사용 가능한 RPC 메서드를 보고 될 것 같은 호출을 하면 됨. 핵심은 정말 그 정도라고 봄
    • 돈 벌기 좋은 구조임. 각 데이터 요청마다 유료 LLM 왕복이 들어감
      엔드포인트끼리 앞으로 저렴하게 질의할 수 있는 스키마를 협상하는 식도 아님
    • 이미 REST와 OpenAPI가 있음
      그것만으로도 자기 발견 같은 기능은 가능함
      MCP를 제공할 곳이라면 어차피 괜찮은 API도 제공할 것임
    • 완전히 동의함. 거대 기업에는 9시부터 5시까지 멋진 걸 만들고 퇴근하면 다음 날까지 일을 잊고 싶은 엔지니어가 가득함
      어떤 회사가 업무 시간 동안 직원들에게서 최대한의 생산성을 뽑아내고 싶어 하지 않겠나

  • “예전에는 까다로운 늙은 Unix 아저씨들이 명세를 쓰던 시절과 비교하면”이라는 부분은, 시맨틱 웹이 실패한 여러 이유 중 하나라고 봄. 작성자의 “나쁜 것이 더 낫다”는 요지와도 모순되지 않음
    사람들은 XML의 eXtensible에 너무 몰입했고 어느 정도 피로감이 쌓였다고 생각함. XSL, XHTML, XSD, WSDL, XSLT, RDF, RSS 등이 너무 많아졌음
    당시 세상에 필요했던 건 단순한 교환 형식이었고 JSON이 그 요구에 맞았는데, XML 쪽은 데이터 형식에 대한 아키텍처 우주비행에 가까웠음
    하지만 이제 XML의 때가 왔다고도 믿음. Anthropic 같은 곳의 유출된 시스템 프롬프트에서 XML이 자주 보임. LLM은 구조화된 텍스트 형식, 특히 Markdown과 XML을 꽤 잘 다루는 듯함
    다만 MCP는 잘못된 모델이라고 봄. 모델이 직접 문맥을 “끌어오도록” 지시하기보다, 우리가 모델에 문맥을 “밀어 넣어야” 한다고 생각함

    • 흥미로운 관찰임. 최근 JSON 매크로 확장 언어를 만들다가 XML/XSLT에 꽤 관심이 생겼음
      매크로 태그 네 가지(#=, #&, #?, #!)가 각각 대입, 치환, cond 같은 조건 분기, 사용자 정의 함수 호출로 자기 자신을 매크로 확장 결과로 바꾸는 식이었는데, 결국 XSLT를 다시 만들고 있다는 걸 깨달음
      정말 원했던 건 XPath였음. 그래프를 여러 축을 따라 앞뒤로 순회하는 방법을 기술하는 방식인데, 실제로 훌륭한 명세임
      그러다 임의의 XML 문서를 질의 가능한 데이터베이스로 가져오고 XPath나 XQuery로 질의할 수 있게 해주는 BaseX https://basex.org/를 찾았음
      환각 없는 신뢰할 만한 자연어 데이터셋 인터페이스를 만들려면, XML 스키마를 시스템 프롬프트에 넘기고 모델이 데이터를 가져오는 질의를 작성하게 하는 방식이 제일 좋아 보임
    • “모델이 직접 문맥을 끌어오게 하기보다 문맥을 밀어 넣어야 한다”는 게 사람들이 인턴에게 해결해 달라고 원하는 사례에서 어떻게 가능할지 모르겠음
      미리 정보를 알고 있다면 아마 직접 문제를 풀었을 것임
      MCP에서 얻는 가치는 “15개 소스를 이어 붙이는 법을 배우게 하지 말고, 나 대신 어떤 질의를 실행해 줘”에 가까워 보임
    • XML 태그는 LLM에 잘 먹힘. 하지만 대부분은 그냥 XML 태그일 뿐임
      아무도™ XML 선언으로 시작하는 제대로 된 XML을 LLM에 먹이지 않고, 네임스페이스나 XSLT, XML Schema 같은 것도 쓰지 않음
      그냥 SGML 스타일 태그를 임의로 모아 둔 것에 가까움
    • 취미 코드에서 문서 원본 형식으로 가끔 XML을 만지지만, 결국 멀어지는 이유는 문법 주변의 자잘한 것들 때문임
      XML은 꺾쇠괄호 이상의 큰 명세이고, 모든 경우를 덮고 보안과 문자 인코딩을 제대로 처리하려 함
      그래서 “일반 텍스트 편집”이 꽤 직관적이지 않음. 이 문단 같은 걸 입력하면 호환 모드에서는 파싱될 수 있지만 유효하지는 않을 수 있음
      교환 형식이나 그에 맞게 만들어진 애플리케이션에 로드되는 형식으로는 가능성이 더 있고, LLM도 분명 이해하는 데 어려움이 없을 테니 그건 좋음
      과거의 많은 문제는 시간이 부족하고 기능을 빨리 끼워 넣고 싶어 하는 프로그래머들이 강하게 구조화된 명세를 둔기처럼 휘두른 데서 왔음. “XML? 정규식으로 쓰면 되지.”를 서로 다른 프로그램 세 개와 작성자 세 명이 반복하면 난장판이 됨
      개인적으로 원하던 것에 실제로 가까운 형식은 BBCode였음. 많은 것의 원본 형식으로 훌륭함. 기본적으로는 여전히 꺾쇠괄호류지만, 범용 프런트엔드 문법으로 쓰기 좋은 정도의 구조와 유연성을 갖췄음
      초기 구현은 “정규식으로 쓰면 되지”였지만, 수십 년간 실전 검증을 거치며 요즘은 더 우아한 파서들도 있음
    • 시맨틱 웹은 광고를 끼워 넣는 법을 못 찾아서 실패했음

  • “MCP의 부상은 AI가 코더들 사이에서 인기를 얻으면서, LLM이 제어하기 위해서만이 아니라 어떤 목적이든 프로그래밍 가능하도록 다른 플랫폼들을 열어젖힐 수 있다는 희망을 준다”는 문장과 반대로 생각함
    MCP는 시맨틱 웹이 실패한 바로 그 이유로 실패할 운명임. 무언가가 잠겨 있지 않으면 돈을 버는 사람이 없기 때문임
    AI가 우리 대신 웹을 검색하는 것, 미안하지만 “deep-research”라고 부르는 기능 중 얼마나 많은 부분이 더 나은 방식으로 해결될 수 있었을지 궁금함
    식당들이 메뉴를 메타데이터 형식으로 공개하고 누구든 Python 스크립트로 텍사스에서 제일 싼 타코를 찾을 수 있었을 텐데, 현실은 한쪽 손으로 데이터를 인위적 장벽 뒤에 잠그고 다른 손으로는 그걸 우회하려고 데이터센터까지 포함한 AI를 만듦. 거시적으로 보면 그냥 멍청한 일임

    • 맞다고 봄. MCP는 robots.txt가 더 고등한 생명체로 진화한 것 같지만, 여전히 “우리가 착취할 수 있게 당신 자원을 설명해 달라”에 가깝음
      이전 에이전트 물결이 죽은 이유는 결국 모두가 협상 대상인 기계 위에서 실행되는 자기 코드를 신뢰할 수 없다는 걸 깨달았기 때문임. 90년대 Java 쪽 일이었음
      근본적으로 상호작용하는 에이전트 사이에는 의도적으로 설계된 정보 비대칭 문제가 있음. 그걸 없애면 사회의 큰 부분이 작동을 멈출 것임
    • 무료 개방 API를 제공해도 돈을 못 번다는 것만이 아님. 그런 API를 운영하려면 사실상 무제한 자원이 필요함
      문제에 아무리 많은 자원을 던져도, 누군가는 아주 작은 이득을 위해 그 자원을 고갈시키는 방법을 찾아낼 것임
      MCP는 AI 에이전트들이 공개 MCP 서버로 메뚜기 떼처럼 몰려들면서 문제를 더 악화시킬 뿐임
      안정적인 선택지는 호출당 과금 RPC 가격 책정일 것 같음. 적어도 모델이나 에이전트를 운영하는 주체가 결제 정산소 역할을 할 테니, Web 2.0 API 때보다는 가능성이 있음
      아마 가장 그럴듯한 과금 방식은 이런 비용을 구독 요금제에 포함하는 것일 듯함. 그게 인센티브를 맞추는 최선으로 보임
    • 2010년대 초반에는 HATEOAS가 꿈이었고, API 소비를 사소한 일로 만들려 했지만 결국 swagger yaml을 만들어내는 것 이상으로 거의 가지 못했음
      애초에 HATEOAS라는 이름을 붙인 사람이 실패하도록 판을 깔아 둔 셈임
    • MCP의 인기는 지금 AI를 밀어 올리는 과열 거품의 부작용이라고 봄. AI로 할 수 있는 그럴싸한 것 중 하나일 뿐임
      데이터를 표준 형식으로 공개하는 데 “쉬운” 가치가 있었다면, 상호운용 가능한 엔드포인트가 훨씬 더 많이 채택됐을 것임
      예를 들어 schema.org나 일반적인 공통 온톨로지를 쓰는 방식 말임. 하지만 현실은 매번 특별한 마법 SDK가 필요한 맞춤 형식이 많음
    • 평범한 사람이 읽을 수 있는 텍스트는 “인위적 장벽”이 아님. 그것이 우리 세계의 본질임
      식당에 메뉴를 메타데이터 형식으로 공개하라고 요구하는 쪽이 인위적 장벽임
      새 자연어 처리 도구들의 아름다움은 여기에 있음. 식당 주인이 JSON을 배우거나 JSON을 생성하는 소프트웨어 패키지를 살 필요가 없음
      우리는 데이터를 있는 그대로 쓸 수 있음. 유용한 도구를 만드는 비용은 거의 0에 가까워짐
      부정확하긴 하겠지만, 원래 인간 언어가 그런 것임

  • MCP가 있다고 해서 뭐든 접근할 수 있을 거라고 생각하는 사람들은 딱해 보임
    그런 것들은 결제 검증과 인증 레이어 수십 겹 뒤에 숨을 것임. 물론 허용 목록 IP도 붙을 것이고, 당연히 IPv4일 것임
    여러분에게 보이는 건 ERR 402;뿐일 듯함

  • MCP에서 가장 걱정되는 건 프로토콜이 형편없이 만들어졌다는 점보다, 이를 고치고 개선하는 일이 Anthropic과 OpenAI 내부 팀에만 달려 있다는 점임
    프로토콜을 만드는 사람들이 실제로 구현도 해 보는 엔지니어처럼 보이지 않음
    어렴풋이 Visa-Mastercard 과점처럼 느껴짐

  • 이제 LLM이 API 문서를 읽고 적응할 수 있다면, 표준 API를 따르는 게 예전보다 덜 필요해진 것 아닐까
    내게 중요한 이점은 사이트가 MCP 명세를 따르든 아니든 API를 “갖고 있다”는 기대가 생기는 것임

    • API 문서가 형편없이 작성됐을 수 있음
      문서가 좋아도 LLM이 API와 상호작용하는 잘못된 코드를 생성할 수 있음. 생성된 코드를 고치고 LLM이 그 코드를 호출해서 API와 상호작용하게 만든다면, 어차피 중간 계층으로 가는 길에 들어선 것임. 사실상 “MCP 같은” 서버를 만드는 셈임
      LLM에 API 직접 접근을 줄 때 보안이나 자원 할당 문제도 있음. LLM은 API가 마지막으로 언제 호출됐는지에 대한 지식이 제한적임. 너무 자주 호출할 수 있고, 호출당 비용이 비싸면 예상 못 한 인프라 청구서가 생김
      이 밖에도 중간에 무언가를 두면 해결되는 잠재적 고통 지점이 많음
      그 “무언가”가 MCP여야 하냐는 합리적인 사람들이 서로 다르게 볼 수 있음. 지금은 사람들이 해야 할 일을 처리하기에 충분히 잘 작동하는 듯함

  • 이제 시맨틱 웹을 만들 수 있음. 조직들이 SQL CREATE TABLE DDL을 MCP 앱이 읽을 수 있는 정적 파일로 공유하는 작은 프로토콜을 만들기만 하면 됨. MCP의 선택적 확장으로 충분함
    그러면 AI/LLM 함수 호출을 SQL로 연결하는 이미 존재하는 도구를 이용해 데이터를 이해하고 질의할 수 있으니, 그것이 시맨틱 웹이 될 것임
    이 방식은 시맨틱 웹을 늘 가로막았던 빠진 고리를 채움. 기업들이 독점 데이터 타입 대신 표준 “데이터 타입”을 쓰도록 만들 인센티브가 없었던 문제임
    MCPQ, 즉 질의를 포함한 MCP가 생기면 갑자기 조직들이 데이터 구조 계층에서 협력할 이유가 생김

  • 알고 보니 “시맨틱 웹”은 내내 구문 웹이었고, 어쩌면 이번이 진짜일지도 모르겠음

  • 누군가 바퀴벌레 같은 걸 제어하는 MCP 서버를 만들기까지 얼마나 걸릴지 궁금함
    참고 자료:
    https://www.technologynetworks.com/informatics/news/robo-roa...
    https://www.sciencealert.com/scientists-turned-cockroaches-i...
    그리고 10년도 더 전까지 거슬러 올라가는 다른 예도 많음

  • “명세를 까다로운 늙은 Unix 아저씨들이 쓰던 시절”이라는 표현이 꽤 웃김
    이 세대가 “늙은 Unix 아저씨들”을 까다로운 사람들로 상상한다는 게 재미있음. Unix는 MIT 학파에 맞선 궁극의 빠르게 움직이고 부수기 반란이었는데 말임
    변하지 않는 것도 있나 봄 :-)

답변달기