이 글의 작성자는 인증 RFC의 조정자이며, 프로토콜이 초기 단계에 있어 많은 부분이 아직 해결되지 않았음을 언급함. Anthropic이 커뮤니티의 의견을 듣고 피드백을 반영하는 점을 칭찬함. 인증 사양 RFC는 Microsoft, Arcade, Hellō, Auth0/Okta, Stytch, Descope 등 여러 보안 전문가와의 협력으로 이루어짐. Anthropic이 기초를 세우고 다른 이들이 이를 발전시키도록 환영함.
작성자는 MCP의 책임을 과도하게 부여하는 것 같다고 언급함. MCP는 LLM이 외부 관리 자원과 상호작용할 수 있는 "문"을 제공하는 역할을 함. 민감한 데이터 노출을 쉽게 만드는 것은 MCP의 잘못이 아님. 시스템이 민감한 데이터를 어떻게 처리하는지 주의해야 함. 신뢰할 수 있는 서비스 제공업체와만 작업해야 함. 비용에 대한 개념이나 통제가 없는 것은 사용자가 자체적으로 사용량을 제한하고 모니터링해야 함. 개발자가 AI 에이전트에 위임하는 것에 대한 문제로 보임.
MCP 서버 도구의 출력이 같은 메시지 스레드에서 다른 도구에 영향을 미칠 수 있는 문제가 있음. 이를 방지하기 위해 도구 간의 샌드박싱이 필요함. Invariant Labs는 도구 설명을 통해 이를 해결했으며, MCP 리소스 첨부를 통해 같은 결과를 얻음. 이는 사양 자체의 문제가 아니라 대부분의 클라이언트가 이를 구현한 방식 때문임.
MCP에 대한 비판보다는 "LLM이 서비스에서 작업을 수행할 수 있도록 하는 프로토콜"에 대한 일반적인 비판으로 보임. LLM이 원하지 않는 작업을 수행할 수 있는 문제가 있음. 사용자가 직접 확인한 후에만 작업을 수행하도록 해야 함. 사용자가 자동 확인 패턴에 빠질 수 있는 심리적 문제가 있음.
MCP에 대한 30개의 기사를 읽었지만 왜 API를 사용하지 않는지 이해하지 못함.
MCP 서버가 로컬에서 악성 코드를 실행할 수 있음. Docker 컨테이너를 사용하여 프로젝트 코드를 마운트하고 LibreChat 및 vscode와 함께 사용함. 에이전트가 시간을 절약하고 타이핑을 줄이지만 비용이 더 많이 듦. Unix 도구 세트를 LLM에 제공하여 프로젝트에 작업할 수 있도록 함.
AI 개인 비서가 정말 어리석다고 생각함. 예를 들어, booking.com이 MCP 서버를 구축하여 호텔 예약을 쉽게 할 수 있게 한다면, 내부 데이터베이스를 제공하는 것과 같음. AI의 가치가 거의 없다고 봄.
도구가 출력 스키마가 부족하다는 점이 신뢰할 수 있는 다단계 계획을 어렵게 만듦. Xops는 OpenRPC를 기반으로 하여 결과 스키마를 정의하도록 요구함.
MCP는 LangChain과 비슷한 느낌을 줌. 몇 줄의 코드로 해결할 수 있는 문제를 해결하지 않음. 많은 기사들이 장점을 설명하려 하지만 모두 실패함.
MCP로 몇 주 동안 개발했지만 HTTP API로 더 잘 해결될 수 있는 사용 사례를 보지 못함. 모든 "도구" 사용은 API 엔드포인트를 통해 기능을 노출하는 것으로 귀결됨. API가 텍스트와 이미지를 반환하는 것이 필요함. Python MCP SDK의 디버깅에 이틀을 소비했음. 클라이언트와 서버 간에 데이터를 통신할 수 있는 상태 없는 방법이 필요함.
Hacker News 의견
이 글의 작성자는 인증 RFC의 조정자이며, 프로토콜이 초기 단계에 있어 많은 부분이 아직 해결되지 않았음을 언급함. Anthropic이 커뮤니티의 의견을 듣고 피드백을 반영하는 점을 칭찬함. 인증 사양 RFC는 Microsoft, Arcade, Hellō, Auth0/Okta, Stytch, Descope 등 여러 보안 전문가와의 협력으로 이루어짐. Anthropic이 기초를 세우고 다른 이들이 이를 발전시키도록 환영함.
작성자는 MCP의 책임을 과도하게 부여하는 것 같다고 언급함. MCP는 LLM이 외부 관리 자원과 상호작용할 수 있는 "문"을 제공하는 역할을 함. 민감한 데이터 노출을 쉽게 만드는 것은 MCP의 잘못이 아님. 시스템이 민감한 데이터를 어떻게 처리하는지 주의해야 함. 신뢰할 수 있는 서비스 제공업체와만 작업해야 함. 비용에 대한 개념이나 통제가 없는 것은 사용자가 자체적으로 사용량을 제한하고 모니터링해야 함. 개발자가 AI 에이전트에 위임하는 것에 대한 문제로 보임.
MCP 서버 도구의 출력이 같은 메시지 스레드에서 다른 도구에 영향을 미칠 수 있는 문제가 있음. 이를 방지하기 위해 도구 간의 샌드박싱이 필요함. Invariant Labs는 도구 설명을 통해 이를 해결했으며, MCP 리소스 첨부를 통해 같은 결과를 얻음. 이는 사양 자체의 문제가 아니라 대부분의 클라이언트가 이를 구현한 방식 때문임.
MCP에 대한 비판보다는 "LLM이 서비스에서 작업을 수행할 수 있도록 하는 프로토콜"에 대한 일반적인 비판으로 보임. LLM이 원하지 않는 작업을 수행할 수 있는 문제가 있음. 사용자가 직접 확인한 후에만 작업을 수행하도록 해야 함. 사용자가 자동 확인 패턴에 빠질 수 있는 심리적 문제가 있음.
MCP에 대한 30개의 기사를 읽었지만 왜 API를 사용하지 않는지 이해하지 못함.
MCP 서버가 로컬에서 악성 코드를 실행할 수 있음. Docker 컨테이너를 사용하여 프로젝트 코드를 마운트하고 LibreChat 및 vscode와 함께 사용함. 에이전트가 시간을 절약하고 타이핑을 줄이지만 비용이 더 많이 듦. Unix 도구 세트를 LLM에 제공하여 프로젝트에 작업할 수 있도록 함.
AI 개인 비서가 정말 어리석다고 생각함. 예를 들어, booking.com이 MCP 서버를 구축하여 호텔 예약을 쉽게 할 수 있게 한다면, 내부 데이터베이스를 제공하는 것과 같음. AI의 가치가 거의 없다고 봄.
도구가 출력 스키마가 부족하다는 점이 신뢰할 수 있는 다단계 계획을 어렵게 만듦. Xops는 OpenRPC를 기반으로 하여 결과 스키마를 정의하도록 요구함.
MCP는 LangChain과 비슷한 느낌을 줌. 몇 줄의 코드로 해결할 수 있는 문제를 해결하지 않음. 많은 기사들이 장점을 설명하려 하지만 모두 실패함.
MCP로 몇 주 동안 개발했지만 HTTP API로 더 잘 해결될 수 있는 사용 사례를 보지 못함. 모든 "도구" 사용은 API 엔드포인트를 통해 기능을 노출하는 것으로 귀결됨. API가 텍스트와 이미지를 반환하는 것이 필요함. Python MCP SDK의 디버깅에 이틀을 소비했음. 클라이언트와 서버 간에 데이터를 통신할 수 있는 상태 없는 방법이 필요함.