MCP Is Not Good Yet - David Cramer, Sentry

영상 링크: MCP Is Not Good Yet — David Cramer, Sentry
채널명: AI Engineer

MCP는 아직 완성되지 않았다 — 센트리의 데이비드 크레이머 핵심 요약

• 영상 제목: MCP는 아직 완성되지 않았다 — 센트리의 데이비드 크레이머
• 발표자는 Sentry의 창업자 및 임원 데이비드 크레이머로, Sentry의 MCP 서버 개발 경험을 바탕으로 MCP에 대한 실무적, 비판적 견해를 공유함
• MCP는 “플러그인 아키텍처를 통한 에이전트 연동”으로, VS Code, Cursor 등 3rd-party 개발 환경과 클라우드 서비스에서 활용성을 갖지만 아직 미완성 단계임
• Sentry MCP 서버는 오픈 API 노출만으로는 충분하지 않으며, 실제로 에이전트와 모델에 적합하게 별도의 컨텍스트와 데이터 구조가 필요함을 강조
• MCP 도입의 진입 장벽이 낮아 보이나, OAuth 2.1 등 지원 미비, 인증 복잡성, 클라이언트(에디터 등)별 호환성 문제 등으로 생각보다 복잡함
• 마크다운(Markdown) 활용, 오류 응답의 인간 친화적 설계 등, 에이전트가 이해하기 쉽도록 데이터 포맷과 설명 체계를 세밀하게 다듬는 것이 필수적임
• MCP 모델 하에서 API 호출 또는 도구 사용의 비용과 토큰 제한 등 현실적 한계가 존재하며, 결과의 신뢰성 및 효율성도 아직 불완전함
• 현재 MCP는 베타 단계에 머무르고 있으며, 사용자 경험(UX)이 미흡하지만, 에이전트 아키텍처를 중심으로 점진적 발전이 기대됨
• 보안 취약성(특히 프롬프트 인젝션, 무분별한 MCP 도구 사용 등)에 주의할 필요가 있으며, 신뢰할 수 있는 공급자만 통합할 것을 권장
• MCP 서버 구현은 본질적으로 어렵지 않으나, 에이전트 워크플로우와 컨텍스트 최적화에 대한 깊은 고민이 필요함을 결론적으로 전달함

세부 요약 - 주제별 정리

MCP 개념은 새로운 ‘플러그인 아키텍처’이지만 여전히 미완성 단계에 머물러 있음

• MCP는 ‘에이전트 간 플러그인 아키텍처’로, 기존 크립토(암호화폐)와 유사한 유행처럼 업계 내 큰 화두가 되고 있음
• 업계 종사자 대부분이 MCP의 실체와 가능성에 대한 의견을 갖고 있으나, 실제 MCP를 빌드하거나 운영해본 사람은 드뭄
• Sentry에서도 장난 삼아 MCP 서버를 먼저 개발했고, 실사용 관점에서 느낀 어려움과 한계를 공유
• MCP에 대한 본 발표의 의견은 Sentry의 B2B SaaS 관점에서 편향될 수 있음을 언급
• MCP의 본질적 정의는 “에이전트를 위한 플러그인 아키텍처”에 불과함을 강조

클라우드 기반 B2B SaaS 문맥에서 MCP의 실제 사용 사례와 한계를 체감함

• Sentry는 앱 모니터링 및 버그 트래킹을 제공하며, MCP를 활용해 VS Code 등 에디터 내에서 버그를 탐색·수정하도록 연동
• 예시: VS Code에서 Sentry MCP를 플러그인으로 연결해 실시간으로 버그 정보를 불러오고, 자동 수정 워크플로우를 수행
• 실제로 ‘모든 버그 고쳐줘’와 같은 요청 시, 내부적으로 20여 개의 API 호출이 발생하여 약 $5의 운영비용(토큰/쿼리 비용)이 듦
• MCP가 기대하는 ‘에이전트 중심 협업 및 자동화’ 시나리오의 가능성을 보이지만, 완성도와 실효성 측면에서는 아직 부족함

MCP의 도입은 겉보기보다 단순하지만, OAuth 2.1 등 인증 절차가 발목을 잡음

• MCP를 도입하는 데 필요한 코드는 예상보다 적으며, 내부 API와 인증(OAuth) 체계를 이미 갖고 있다면 진입 장벽이 낮음
• 실제 구현 과정에서 OAuth 2.1 및 클라우드 인증 프록시(예: Cloudflare Shim, WorkOS 등)의 지원 부족이 가장 큰 난관으로 등장
• 크레이머는 이러한 인증 복잡성을 Cloudflare Workers, Shim 등으로 해결하였다 언급 (“이틀 만에 구현 가능했음”)
• 표준 IO(standard IO) MCP 인터페이스는 보안·운영 면에서 클라우드 B2B 환경에는 부적합함

MCP 연동 시 단순 API 오픈만으로는 모델과 에이전트에 적합하지 않음

• 오픈 API 엔드포인트를 MCP ‘도구’로 그대로 노출시키면, LLM/에이전트가 무의미한 결과를 내거나 오작동하기 쉬움
• 기존 API 호출의 결과를 마크다운(Markdown) 등으로 구조화하여 최소한의 핵심 정보만을 명확하게 전달해야 실제 사용 가치가 생김
• 예: Sentry MCP는 응답에서 불필요한 정보를 모두 제거, 사람이 읽을 수 있는 형식(마크다운)으로 결과를 제공
• 이는 LLM이 인간과 유사한 언어 패턴·문맥추론 기반으로 작동하기 때문이며, JSON 등 비정형 데이터는 해석이 불안정함

VS Code, Cursor, Cloud Code 등 주요 에디터 및 클라우드 도구의 MCP 지원 현황은 아직 불안정함

• VS Code Insiders는 현재 유일하게 완전한 MCP(OAuth)를 지원하는 대표적 사례
• Cursor는 곧 MCP 지원 예정(‘이번 주 내’), Cloud Code는 부분적 지원만 제공
• MCP 서버/플러그인과 주요 클라이언트의 호환성 불안정으로, 빈번한 연결 오류 발생
• 초기 단계에서 Cursor, VS Code, Cloud Code 등은 꾸준히 발전하고 있으나, MCP 연동 경험은 ‘rough’(거칠고 불안정), 베타 수준임

MCP 시스템 설계의 본질은 모델·에이전트에 제공할 ‘최소한의 맥락(context) 전달’임

• 도구(tool) 및 오류 메시지 모두, 인간이 이해할 수 있도록 간결·구조화해 전달해야 LLM이 효과적으로 활용 가능
• 예: 툴 설명에서 너무 방대한 토큰이나 복잡한 설명은 LLM/에이전트가 올바른 툴 선택 및 실행을 방해
• 적절한 맥락 설명과 오류 설계가 필수적이며, 클라이언트의 토큰 한도 및 응답 비용까지 감안해야 함
• 실무에서는 “한 번에 버그 다 고쳐줘” 요청이 모든 조직, 프로젝트에 대해 무의미하게(20여 개 API 호출) 실행되는 비효율도 발생

MCP 연동의 현실적 비용 및 한계 — 호출 비용, 토큰 제한, UX 미흡 등이 현존

• 도구 호출 또는 MCP API 요청의 응답 데이터가 크면 토큰 비용이 기하급수적으로 증가(예시: $1 → $10)
• LLM/클라이언트의 툴/도구 설명 길이 제한 존재, 이를 초과할 경우 도구 사용이 정상적으로 작동하지 않음
• 이러한 한계로 인해, MCP 기반 시스템은 매주 지속적인 유지보수·미세조정이 필요 (“set and forget” 불가)
• 현재 MCP 기반 도구의 사용자 경험, 신뢰성 등은 부족하지만, 실질적인 미래 가능성이 존재

보안(특히 프롬프트 인젝션 등)의 잠재적 위험성에 경각심을 가져야 함

• 표준 IO MCP 인터페이스는 각종 보안 취약점(프롬프트 인젝션 등)에 매우 노출되어 있음
• 무분별하게 MCP 도구/패키지를 다운로드하거나, 신뢰성 없는 서드파티 공급자를 조직 내 통합하지 말 것을 경고
• 조직 내 MCP 도구 및 공급자 신뢰성 심사가 필수적임

에이전트 아키텍처에 주목하여, MCP를 에이전트 중심 전략으로 전환할 필요가 있음

• 현재 MCP에서 가장 큰 가치는 에이전트(Agent)를 서비스화하여 MCP로 노출·통합하는 전략에 있다고 강조
• 예: Sentry에서는 내부적으로 ‘Seir’라는 에이전트(고품질 root cause analysis를 자동화)를 MCP 및 UI 양쪽에 노출함
• 에이전트 기반 MCP 확장은, 제어권(프롬프트 설계, 요청 흐름, 결과 처리, 비용 결정 등)과 시스템 신뢰성 측면에서 장점이 큼
• 다만, 현시점 MCP는 스트리밍 응답 미지원 등 기술적 한계로 인해 실제로는 폴링(polling), 상태체크 등 우회 방식이 필요

MCP 서버 개발·도입은 어렵지 않으나, 본질은 에이전트 컨텍스트 설계 최적화에 있음

• 실질적으로 MCP 서버 초안 구축은 이틀이면 충분(“내가 이틀에 완성, 회사 일도 많은데…”)
• 핵심은 ‘컨텍스트 중심 에이전트 워크플로우 설계’에 집중하는 것이며, 기존 API 포맷이나 기술 용어에 얽매일 필요 없음
• LLM tool call, MCP 호출 등은 대부분 기존 API 호출을 새로운 응답 포맷으로 변환한 것에 지나지 않음
• Cloudflare Workers 등 최신 인프라를 활용한 인증·웹소켓 등 부수 구현은 비교적 손쉽게 해결 가능

결론적으로 MCP는 성장 가능성이 크나 당분간 지속적 학습·조정과 신중한 활용이 필요함

• MCP 및 관련 기술은 당장 실무 투입 시 오류와 불완전성이 많지만, 접근성은 점점 높아질 전망
• fancy new words(신조어·마케팅 용어)로 인해 MCP나 에이전트가 특별해 보일 뿐, 본질은 기존 서비스 아키텍처와 유사
• 실제로 적용하며 겪는 버그, 불완전한 사용자 경험 등을 감안해 꾸준한 학습과 실험이 필요하며, 곧 업계 표준으로 자리잡을 것이라 전망