---
title: "MCP는 새로운 GraphQL이다 — 하이프가 기술적 판단을 덮을 때"
published: 2026-01-24T22:32:33.000Z
canonical: https://jeff.news/article/1173
---
# MCP는 새로운 GraphQL이다 — 하이프가 기술적 판단을 덮을 때

MCP가 GraphQL과 동일한 하이프 패턴을 밟고 있다는 경고 글임. GraphQL이 overfetching을 해결했지만 edge 관측성 붕괴 등 심각한 대가가 있었듯이, MCP도 개인 도구 연결에는 좋지만 프로덕션 AuthZ가 필요한 환경에 무조건 맞는 건 아님. 추상화가 지위 상징이 되면 이성이 퇴장한다는 게 핵심 메시지임.

"MCP는 새로운 GraphQL이다"

- MCP(Model Context Protocol)가 GraphQL과 똑같은 하이프 패턴을 밟고 있다는 주장임
- GraphQL의 교훈부터 돌아봄. overfetching 해결이란 명확한 문제가 있었지만, 대가가 컸음: 내부 상태에 대한 재귀적 접근, 복잡도 제한 불가, 관측성 붕괴
- 저자의 실제 경험이 생생함. Cloudflare에서 REST API 기반으로 엔드포인트별 rate-limiting을 잘 쓰고 있었는데, GraphQL로 바꾸니 전부 `/graphql` 단일 엔드포인트로 합쳐져서 edge 설정이 통째로 날아감
- 다시 동일한 보호 수준을 확보하려면 별도 GraphQL 게이트웨이 벤더 제품을 사야 했음. REST가 공짜로 주던 걸 돈 주고 다시 산 셈임
- 대기업에서 "모든 내부 REST API 위에 하나의 graph 구축"이 OKR이었던 적이 있음. 이유? Shopify가 했으니까. 기술적 판단이 아니라 권위 편향이었음

> [!warning] MCP도 같은 길을 걷고 있음
> 이미 "MCP 서버 수"가 누군가의 OKR이 되고 있다는 얘기가 들림. 추상화가 지위의 상징이 되면 이성은 퇴장함.

- MCP 자체가 나쁜 기술은 아님. Claude에 Gmail이나 Linear 같은 외부 도구 연결하는 데는 합리적인 솔루션임
- 하지만 세밀한 AuthZ, 감사 요구사항, 명확한 소유권 경계가 있는 프로덕션 시스템에서 MCP가 맞는 추상화라는 보장은 없음
- 저자의 결론: LLM 도구 생태계는 아직 극초기라 초기 추상화에 더 비판적이어야 함. 추상화는 틀리기 쉬움

## 핵심 포인트

- MCP가 GraphQL과 같은 권위 편향 기반 하이프 사이클에 진입함
- GraphQL 전환 시 Cloudflare edge rate-limiting 설정이 통째로 날아간 실제 사례 공유
- MCP는 Claude에 외부 도구 연결하는 데는 합리적이지만 프로덕션 AuthZ/감사 요구사항에는 부족할 수 있음
- 이미 'MCP 서버 수'가 OKR이 되고 있다는 징후가 보임
- LLM 도구 생태계 극초기에 초기 추상화를 무비판적으로 수용하면 위험함

## 인사이트

기술 선택이 '왜 필요한가'가 아니라 '누가 쓰는가'로 결정되는 순간을 정확히 짚은 글임. GraphQL 경험이 있는 시니어라면 데자뷔 느낄 내용.