두 개의 다른 뉴스, 하나의 같은 질문
이번 주 프론트엔드 커뮤니티에 거의 동시에 올라온 두 글이 있다. 하나는 MCP(Model Context Protocol)의 2026-07-28 스펙 개편—스테이트리스 코어, Tasks 확장, MCP Apps, 그리고 여섯 개의 SEP로 강화된 인가 체계. 다른 하나는 Figma에서 익스포트한 SVG가 왜 필요 이상으로 무거운지를 해부한 글. 주제도, 기술 스택도 달라 보인다. 그런데 두 글을 나란히 읽고 나면 같은 질문이 남는다. "우리는 크기(complexity)를 설계하고 있는가, 아니면 그냥 누적하고 있는가?"
MCP 리라이트: 배포가 쉬워질수록 카탈로그가 폭발한다
MCP 스펙 개편의 핵심은 마찰 제거다. 기존 스펙에서 원격 MCP 서버는 스테이트풀한 존재였다—세션 피닝, 게이트웨이의 딥 패킷 인스펙션, 수평 확장을 위한 세션 스토어 관리. 이 마찰이 역설적으로 자연스러운 속도 조절 장치 역할을 했다. 서버를 새로 띄우는 게 번거로우니 팀이 두 번 생각했다.
2026-07-28 스펙은 그 마찰을 거의 사라지게 만든다. 라운드로빈 로드밸런서 뒤에 스테이트리스 서버를 두고, Mcp-Method 헤더로 라우팅하고, tools/list 응답을 캐시한다. dev.to의 분석처럼, 플랫폼 팀이 오후 한나절에 배포할 수 있는 구조다. 결과는 예측 가능하다. 모든 내부 API가 MCP 서버가 된다. 모든 SaaS 벤더가 하나씩 붙는다. 오늘 15개 도구 중 선택하던 에이전트가 연말엔 150개 앞에 선다.
프로토콜이 해결한 것과 해결하지 못한 것
MCP가 표준화한 것은 발견과 호출이다—와이어 포맷, 핸드셰이크, 기능 협상. 에이전트가 올바른 도구를 선택하는지는 스펙의 범위 밖이다. 이 구분이 현장에서 자주 흐려진다.
실제 프로덕션에서 벌어지는 실패들—인보이스를 물어봤는데 search_orders를 호출하거나, ISO 8601을 요구하는 스키마에 MM/DD/YYYY를 넘기거나, 이미 성공한 쓰기 작업을 타임아웃으로 오인해 재시도하거나, 한 번에 해결될 워크플로우를 세 번의 도구 호출로 처리하는 것—은 모두 스펙 준수 JSON-RPC다. 프로토콜 실패가 아니라 판단 실패다. 그리고 판단은 트랜스포트 레이어가 아니라 학습 데이터에서 온다.
더 불편한 진실이 있다. 현재 프런티어 모델들의 함수 호출·도구 사용 능력은 대부분 소규모의 깔끔한 도구 세트—서로 명확히 구분되는 몇 개의 함수, 합성 API 환경—로 학습되고 평가됐다. 모델들은 도구 호출의 문법을 잘 익혔다. 잘못된 포맷의 도구 호출은 거의 사라졌다. 하지만 대규모 카탈로그에서 거의 비슷한 도구들을 변별하는 능력은 그 학습 데이터에 거의 존재하지 않는다. 스테이트리스 스펙은 여러 서버를 집계하는 시나리오를 엣지 케이스가 아닌 기본값으로 만든다.
SVG 최적화가 같은 이야기를 하는 방식
Figma나 Illustrator에서 아이콘을 익스포트하면 보통 필요 이상으로 3~5배 큰 SVG가 나온다. SVG 포맷 자체가 비효율적인 게 아니다. 디자인 도구가 에디터 내부 관리를 위한 XML 주석, 실제로 사용되지 않는 네임스페이스 선언, 렌더링에 무관한 ID와 그룹핑, 시각적 차이 없는 6자리 소수점 좌표를 흘려보내고, 아무도 프로덕션 배포 전에 치우지 않기 때문이다.
두 원 짜리 아이콘 하나가 ~375바이트로 나오는 상황. 주석·메타데이터·공백만 제거해도 ~300바이트—18~20% 절감—이 무시각적 위험으로 가능하다. 단일 아이콘에서 75바이트는 아무 의미 없다. 하지만 JSX로 인라인된 수십 개의 아이콘이라면, 스프라이트 시트라면, LCP에 영향을 주는 히어로 그래픽이라면 얘기가 다르다. 개별 요소의 크기 문제가 시스템 규모에서 성능 문제로 전환된다.
공통 원칙: 크기는 설계하지 않으면 누적된다
MCP 카탈로그와 SVG 에셋은 표면적으로 전혀 다른 문제다. 그런데 두 영역에서 같은 패턴이 반복된다.
- 생성 비용이 낮아지면 크기(complexity)는 기본값으로 늘어난다. 스테이트리스 MCP 서버는 오후에 배포 가능하고, 디자인 도구는 원클릭으로 SVG를 생성한다. 마찰이 사라지면 선택의 긴장도 사라진다.
- 툴링이 만들어주는 것과 실제로 필요한 것 사이의 간극을 아무도 명시적으로 좁히지 않는다. MCP 서버는 명세를 준수하지만 도구 설명이 중복된다. SVG는 렌더링되지만 에디터 메타데이터를 달고 있다.
- 문제는 스케일에서 드러난다. 도구 15개일 때는 선택 오류가 드물다. 150개가 되면 시스템적 실패가 된다. 아이콘 1개의 75바이트는 무시된다. 아이콘 50개의 75바이트는 LCP 지표를 움직인다.
프론트엔드 워크플로우에서 지금 당장 바꿔야 할 것
MCP 마이그레이션을 계획 중이라면, 도구 설명을 프롬프트처럼 다뤄야 한다. tools/list 응답이 캐시되면 그 설명들은 대규모로 소비된다. 두 설명이 같은 요청에 그럴듯하게 매칭된다면 모델은 반드시 혼동한다. 도구 선택 결정을 로그에 남길 때는 무엇을 호출했는지만이 아니라 어떤 후보 중에서 선택했는지를 기록해야 한다. 그래야 '잘못 선택'과 '애초에 보이지 않음'을 구분할 수 있다.
SVG 에셋을 다루는 워크플로우라면, 익스포트 직후를 최적화 게이트로 만드는 것이 가장 레버리지가 높다. SVGO 계열 도구를 CI에 넣거나, React 컴포넌트로 변환할 때 JSX 어트리뷰트 변환(stroke-width → strokeWidth)까지 한 번에 처리하는 파이프라인을 갖추면 나중에 손으로 고치는 비용이 사라진다.
두 영역 모두에서 핵심은 같다. 생성 도구(디자인 툴, MCP 서버 프레임워크)의 기본 출력을 그대로 프로덕션에 흘리는 것이 기본값이 되어서는 안 된다. 축소와 정리는 사후 작업이 아니라 설계 단계에 포함되어야 한다.
전망: AI가 생성한 모든 것에 '크기 설계'가 필요해진다
MCP 스펙이 성숙하고, 디자인-개발 사이의 AI 도구가 더 많은 에셋을 자동 생성하는 방향으로 가면서, 프론트엔드 개발자가 직접 '크기를 결정'하는 순간은 점점 줄어든다. Figma MCP로 컴포넌트 스펙을 바로 가져오고, AI가 SVG를 생성하고, 에이전트가 API를 직접 호출하는 워크플로우에서는 인간이 검토하는 체크포인트가 구조적으로 더 적다.
그렇기 때문에 지금이 원칙을 심어야 할 타이밍이다. 에이전트 도구 카탈로그의 크기를 의도적으로 관리하는 것, SVG 에셋의 최적화 게이트를 파이프라인에 넣는 것—이 둘은 각기 다른 문제처럼 보이지만 같은 근육을 쓴다. 생성된 것을 그대로 믿지 않고, 필요한 것만 남기는 설계 감각. AI 도구가 점점 더 많은 것을 만들어주는 시대일수록, 무엇을 줄일지 결정하는 능력이 프론트엔드 개발자의 핵심 역량이 된다.