본문으로 건너뛰기
피드

MCP는 새로운 GraphQL이다 — 하이프가 기술적 판단을 덮을 때

backend 약 3분
vote
0
댓글
북마크

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

  • 1

    MCP가 GraphQL과 같은 권위 편향 기반 하이프 사이클에 진입함

  • 2

    GraphQL 전환 시 Cloudflare edge rate-limiting 설정이 통째로 날아간 실제 사례 공유

  • 3

    MCP는 Claude에 외부 도구 연결하는 데는 합리적이지만 프로덕션 AuthZ/감사 요구사항에는 부족할 수 있음

  • 4

    이미 'MCP 서버 수'가 OKR이 되고 있다는 징후가 보임

  • 5

    LLM 도구 생태계 극초기에 초기 추상화를 무비판적으로 수용하면 위험함

"MCP는 새로운 GraphQL이다"

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

⚠️주의

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

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

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

댓글

댓글

댓글을 불러오는 중...

backend

클릭하우스가 PgBouncer 처리량을 4배로 끌어올린 방법

ClickHouse Managed Postgres 팀은 단일 스레드인 PgBouncer를 여러 프로세스로 띄우고 `so_reuseport`와 피어링(peering)을 조합해 16 vCPU 머신을 제대로 쓰게 만들었다. 동일한 AWS 환경에서 단일 프로세스는 약 8.7만 TPS 근처에서 막혔지만, 16개 프로세스 구성은 약 33.6만 TPS까지 올라갔다.

backend

SQLite 쓸 거면 STRICT 테이블을 기본값으로 보자는 주장

SQLite의 STRICT 테이블은 INTEGER 컬럼에 문자열이 들어가는 식의 타입 실수를 막아주는 기능이다. 글쓴이는 SQLite 특유의 유연한 타입 시스템보다, 실수는 빨리 터뜨리는 쪽이 실무에서 낫다고 주장한다. 다만 기존 테이블을 바로 STRICT로 바꾸기 어렵고, SQLite 3.37.0 이상에서만 쓸 수 있다는 제약도 있다.

backend

왜 아직도 Lisp를 배워볼 만한가

Lisp는 괄호가 많은 이상한 언어처럼 보이지만, 핵심은 문법이 아니라 언어 자체를 확장할 수 있다는 점에 있음. 매크로, 코드-데이터 동일성, REPL 중심 개발이 합쳐지면 프로그램을 '작성'한다기보다 살아 있는 시스템을 계속 진화시키는 방식으로 개발하게 됨.

backend

EDB 포스트그레스 AI, 포레스터 멀티모델 데이터 플랫폼 리더 선정

EDB의 AI 데이터 플랫폼 EDB 포스트그레스 AI가 2026년 2분기 포레스터 웨이브 멀티모델 데이터 플랫폼 보고서에서 리더로 선정됐음. 트랜잭션, 분석, AI 워크로드를 하나의 플랫폼에서 다루는 흐름이 강해지는 가운데, EDB는 전략과 현재 제공 기능 모두에서 높은 평가를 받았다고 밝힘.

backend

Bun, Zig에서 Rust로 갈아탔다: 11일짜리 초대형 런타임 포팅 실험

Bun 팀이 53만 줄이 넘는 Zig 코드베이스를 Rust로 기계적으로 포팅했고, Bun v1.4.0부터 Rust 기반으로 전환될 예정임. 핵심 이유는 성능보다 안정성이었고, use-after-free, double-free, 메모리 누수 같은 문제를 컴파일러와 타입 시스템으로 더 빨리 잡기 위해서였음. Claude Code 워크플로 64개를 병렬로 돌려 11일 만에 전 플랫폼 테스트 통과까지 밀어붙인 사례라, LLM 기반 대규모 코드 마이그레이션의 꽤 강한 신호탄임.