이제 막 1년 된 MCP 프로토콜을 Linux Foundation 산하의 독립 재단으로 넘기는 건 너무 이르다는 생각임
LF 산하 재단들은 행사·교육·인증 등으로 수익을 내고, 그 수익이 다시 프로젝트 생태계를 돌리는 구조임
하지만 MCP는 아직 그 수익 구조를 뒷받침할 만큼 성숙하지 않았음. OAuth 같은 핵심 기능도 안정되지 않았고, “Certified MCP Developer” 같은 인증을 만들기엔 시기상조임
Kubernetes처럼 이미 검증된 기술이 재단의 중심이 되는 건 이해되지만, MCP는 아직 sandbox 단계에 머물러 있음. 차라리 Anthropic과 소수의 개발팀이 빠르게 개선하는 편이 낫다고 봄
반면, MCP의 채택 속도가 Kubernetes보다 10배 빠르기 때문에 지금 재단에 넘겨 다른 기업들이 참여하도록 하는 게 타당하다는 의견도 있음. 예를 들어 Google은 이런 중립적 구조 없이는 MCP에 전면적으로 참여하지 않을 것임
MCP는 미래가 없다고 봄. 이번 결정은 단순한 보여주기식 행보에 불과함
이건 그냥 영역 선점(land grab) 일 뿐임
오히려 Kubernetes가 CNCF에 기부될 당시보다 MCP가 더 오래된 프로젝트 아닌가 하는 의문도 있음
개인적으로 MCP는 일시적 유행(fad) 처럼 느껴짐
대부분의 사용 사례가 ‘tool calling’인데, 이를 위해 별도의 프로토콜을 만들고 다양한 런타임을 거치는 건 과도함
여러 MCP 서버를 다뤄본 입장에서, MCP는 LLM이나 AI가 상호작용하기 위한 전용 API 설계처럼 보임
tool calling이 주요 사용처인 건 맞지만, 단순 REST API 매핑보다는 더 높은 수준의 워크플로우 추상화를 제공할 수 있음
REST API와 비슷한 관리 이슈가 생기면서 MCP 서버용 게이트웨이와 관리 툴이 폭발적으로 늘고 있음
실제로 에이전트와 LLM의 도구 호출이라는 현실적인 문제를 대체할 다른 방법이 없기에, MCP는 사라질 유행이 아니라고 생각함
나는 MCP가 인간과 소프트웨어의 상호작용 방식을 바꾸는 잠재력에 더 관심이 있음
예를 들어 Jira용 MCP 서버를 Claude에 연결하면 “버전 1.2.3의 Epic 기반 릴리스 노트 작성” 같은 프롬프트로 바로 문서를 만들 수 있음
이런 식으로 여러 서비스(Mail, Cloud Drive 등)를 MCP로 연결하면, 사용자는 별도 내보내기 기능 없이도 데이터를 자유롭게 조합할 수 있음 Alibaba가 자사 서비스 전반에 MCP 서버를 구축 중인데, 이런 접근은 일반 사용자에게도 큰 가치를 줄 것임
지난주 MCP 서버를 직접 만들어봤는데, 함수 설명을 자세히 적어두면 AI가 훨씬 풍부한 맥락(context) 을 이해함
Claude나 Gemini 같은 도구가 서버에 연결될 때 각 함수의 설명을 읽고 도구 사용법을 스스로 파악함. 이런 점은 기존 API로는 구현하기 어려움
실제로 Claude가 MCP를 통해 보여주는 능력에 깊은 인상을 받았음
나도 비슷한 생각임. 결국 JSON 파일을 URL로 제공하는 일인데, 이렇게 복잡할 필요가 있나 싶음
그렇다면 MCP를 대체할 구조는 어떤 형태여야 하는지 궁금함. 그리고 그 제안을 표준화로 이끌 영향력 있는 단체는 어디일까 하는 의문이 있음
Anthropic이 MCP를 떠넘기려는 의도로 보임
기업들은 아직 MCP가 허술한 표준임을 인식하지 못했지만, Anthropic은 책임을 피하려는 듯함
실제로 Anthropic도 최근 programmatic tool calling으로 방향을 바꾼 상태임
흥미롭게도 Google은 이미 올해 초 자체 AgentToAgent(A2A) 프로토콜을 Linux Foundation에 기부했음
그런데 그 프로토콜은 거의 알려지지 않았음. 관련 소식을 꾸준히 봐왔는데도 처음 들어봄
많은 댓글과 달리, 이번 기부가 MCP의 종말 신호라고는 생각하지 않음
주요 AI 기업들이 RFC 단계부터 MCP 표준화를 함께 추진 중이며, 경쟁사 통제 하의 표준에 자원을 쏟는 건 비효율적이기에 중립 기관 이관은 자연스러운 수순임
Linux Foundation이 예전 Apache처럼 ‘프로젝트 무덤’이 된 것도 아님. 물론 인증 프로그램이나 컨퍼런스 중심 구조의 부작용은 있지만, 다자간 협력 프로젝트로서 성과를 내는 경우가 많음
Anthropic이 “MCP를 오픈소스·커뮤니티 중심·벤더 중립적으로 유지하겠다”며 Linux Foundation에 기부했다는 발표는 흥미로움
장기적으로 성공할지는 미지수지만, 전략적으로는 영리한 선택 같음
“출범 이후부터”라지만, 실제로는 고작 1년 된 프로젝트 아닌가 하는 반응도 있음
Tesla 커넥터처럼 공개 표준으로 내놓는 편이 장기적으로 성공 가능성이 높음. 특정 플랫폼에 묶어두는 건 오히려 위험함
MCP는 결국 JSON-RPC 기반 프로토콜일 뿐이라, 오픈소스 여부는 구현체에 달려 있음
MCP는 사실상 막다른 길이라고 생각함
Claude 모델은 좋아하지만 Anthropic의 경영진은 마음에 들지 않음. Apple처럼 폐쇄적임
지금까지 단 한 번도 모델을 오픈소스로 공개한 적이 없음
하지만 그럴 이유가 있나? Anthropic은 영리 기업이니 당연한 선택일 수도 있음
MCP와 기존 API의 차이를 혼동하는 의견이 많음
예전에 정리한 글이 있음: MCP vs API 비교
이 글이 혼란을 좀 줄여줄 것 같음
고마움. 다만 “Bonus: MCP vs API video” 섹션에 영상 링크가 빠져 있음
Hacker News 의견들
LF 산하 재단들은 행사·교육·인증 등으로 수익을 내고, 그 수익이 다시 프로젝트 생태계를 돌리는 구조임
하지만 MCP는 아직 그 수익 구조를 뒷받침할 만큼 성숙하지 않았음. OAuth 같은 핵심 기능도 안정되지 않았고, “Certified MCP Developer” 같은 인증을 만들기엔 시기상조임
Kubernetes처럼 이미 검증된 기술이 재단의 중심이 되는 건 이해되지만, MCP는 아직 sandbox 단계에 머물러 있음. 차라리 Anthropic과 소수의 개발팀이 빠르게 개선하는 편이 낫다고 봄
대부분의 사용 사례가 ‘tool calling’인데, 이를 위해 별도의 프로토콜을 만들고 다양한 런타임을 거치는 건 과도함
tool calling이 주요 사용처인 건 맞지만, 단순 REST API 매핑보다는 더 높은 수준의 워크플로우 추상화를 제공할 수 있음
REST API와 비슷한 관리 이슈가 생기면서 MCP 서버용 게이트웨이와 관리 툴이 폭발적으로 늘고 있음
실제로 에이전트와 LLM의 도구 호출이라는 현실적인 문제를 대체할 다른 방법이 없기에, MCP는 사라질 유행이 아니라고 생각함
예를 들어 Jira용 MCP 서버를 Claude에 연결하면 “버전 1.2.3의 Epic 기반 릴리스 노트 작성” 같은 프롬프트로 바로 문서를 만들 수 있음
이런 식으로 여러 서비스(Mail, Cloud Drive 등)를 MCP로 연결하면, 사용자는 별도 내보내기 기능 없이도 데이터를 자유롭게 조합할 수 있음
Alibaba가 자사 서비스 전반에 MCP 서버를 구축 중인데, 이런 접근은 일반 사용자에게도 큰 가치를 줄 것임
Claude나 Gemini 같은 도구가 서버에 연결될 때 각 함수의 설명을 읽고 도구 사용법을 스스로 파악함. 이런 점은 기존 API로는 구현하기 어려움
실제로 Claude가 MCP를 통해 보여주는 능력에 깊은 인상을 받았음
기업들은 아직 MCP가 허술한 표준임을 인식하지 못했지만, Anthropic은 책임을 피하려는 듯함
주요 AI 기업들이 RFC 단계부터 MCP 표준화를 함께 추진 중이며, 경쟁사 통제 하의 표준에 자원을 쏟는 건 비효율적이기에 중립 기관 이관은 자연스러운 수순임
Linux Foundation이 예전 Apache처럼 ‘프로젝트 무덤’이 된 것도 아님. 물론 인증 프로그램이나 컨퍼런스 중심 구조의 부작용은 있지만, 다자간 협력 프로젝트로서 성과를 내는 경우가 많음
장기적으로 성공할지는 미지수지만, 전략적으로는 영리한 선택 같음
Claude 모델은 좋아하지만 Anthropic의 경영진은 마음에 들지 않음. Apple처럼 폐쇄적임
지금까지 단 한 번도 모델을 오픈소스로 공개한 적이 없음
예전에 정리한 글이 있음: MCP vs API 비교
이 글이 혼란을 좀 줄여줄 것 같음