AI 에이전트를 처음 만들어본 개발자라면 한 번쯤 이런 경험을 했을 것이다. Claude에서 잘 동작하던 툴을 다른 에이전트 프레임워크에 연결하려는 순간, 처음부터 다시 작성해야 한다는 걸 깨닫는 순간. MCP(Model Context Protocol)는 바로 이 '플러그인 파편화' 문제를 정면으로 겨냥한다.
MCP는 왜 'USB-C'에 비유되는가
dev.to에 공개된 실사례 레포를 보면 MCP의 핵심이 한눈에 들어온다. 하나의 Python 서버(FastMCP로 구성)가 Claude Code, Google ADK 에이전트, 그리고 Rust CLI—코드를 한 줄도 공유하지 않는 세 클라이언트—를 동시에 서빙한다. MCP 이전 세계에서 이 세 클라이언트를 지원하려면 통합 코드를 세 벌 따로 작성해야 했다. MCP 이후에는 서버 하나, 클라이언트는 자유롭게.
구조는 단순하다. MCP 서버는 툴의 이름·설명·파라미터 타입을 JSON으로 선언하고, 클라이언트는 "어떤 툴이 있어?"라고 물어본 뒤 LLM이 결정한 툴 호출을 서버로 포워딩한다. 통신은 stdio, 즉 표준 입출력 파이프다. 프로토콜이 stdout을 채널로 쓰기 때문에 서버 코드에 print()를 잘못 넣는 순간 전체 프로토콜이 깨진다—이 디테일 하나가 MCP 서버 디버깅에서 가장 자주 마주치는 함정이기도 하다.
300줄로 세 클라이언트를 먹이는 설계
FastMCP를 쓰면 함수 하나에 @mcp.tool() 데코레이터를 붙이는 것만으로 툴이 등록된다. 함수 시그니처와 docstring이 곧 AI가 읽는 스펙이다. 별도의 스키마 파일도, 복잡한 등록 로직도 없다. 이 단순함은 단순한 편의가 아니라 설계 철학이다—툴의 인터페이스와 구현이 같은 파일 안에 있으니 둘이 어긋날 수가 없다.
이 레포가 흥미로운 이유는 '이미지 편집 상태 관리' 방식에 있다. 대부분의 이미지 API는 매 요청이 독립적이지만, Gemini Interactions API는 interaction_id를 반환하고 이 ID를 다음 요청에 넘기면 같은 이미지를 이어서 편집할 수 있다. "사이버펑크 라멘 주방 생성 → ID 수신 → '네온사인 추가'로 편집 요청"이 하나의 대화 흐름으로 이어진다. 중요한 건 MCP 서버 자체는 상태를 보유하지 않는다는 점이다. 상태는 Google 서버에, ID는 에이전트의 대화 메모리에—서버는 언제든 재시작 가능하다. 이 패턴은 MCP 서버 설계 원칙으로도 그대로 쓸 수 있다.
솔로 빌더가 증명한 현실적 진입장벽
추상적인 프레임워크 얘기만으로는 부족하다. 모로코에서 혼자 SEO 툴을 개발 중인 개발자의 사례가 MCP의 실용성을 더 직접적으로 보여준다. dev.to에 공개된 이 사례에서 그는 2억 건 이상의 백링크 데이터를 조회하는 MCP 서버를 300줄 미만 코드로 완성했다. 인프라 비용은 월 8유로. Claude Desktop에서 claude mcp add seo-backlinks -- npx -y seo-backlinks-mcp 한 줄로 설치된다.
이 사례가 의미 있는 이유는 'MCP 서버 = 대형 팀의 인프라'라는 선입견을 깨기 때문이다. 기존 API가 있다면 MCP 레이어 추가는 주말 프로젝트 수준이다. Common Crawl의 무료 웹 크롤 데이터를 백링크 분석에 연결하고, Postgres와 Bun 서버로 API를 구성한 뒤, 5개 툴만 MCP로 노출했다. 사용자는 Claude 안에서 자연어로 "stripe.com의 백링크 프로필 확인해줘"라고 입력하면 된다.
프론트엔드 개발자 시각에서 본 핵심 설계 원칙 세 가지
두 사례를 관통하는 설계 원칙을 프론트엔드 관점에서 정리하면 이렇다.
첫째, 툴의 반환값은 토큰 경제를 고려해 설계하라. 이미지 MCP 서버는 PNG 바이트 대신 파일 경로 문자열을 반환한다. Base64 인코딩된 이미지를 컨텍스트에 쑤셔 넣으면 수천 토큰이 낭비된다. AI는 픽셀을 읽을 수 없지만 파일 경로는 충분히 활용할 수 있다. 컴포넌트가 필요한 데이터만 props로 받아야 하는 것처럼, 툴 역시 AI가 실제로 쓸 수 있는 형태의 최소한의 데이터만 반환해야 한다.
둘째, 에러를 크래시가 아닌 메시지로 반환하라. 툴이 예외를 던지지 않고 "이미지 생성 실패: 유효하지 않은 aspect ratio" 같은 문자열을 반환하면, AI가 스스로 올바른 파라미터로 재시도한다. 에러가 구조화된 피드백이 되는 순간 에이전트 루프가 self-healing 능력을 얻는다.
셋째, 서버는 stateless하게, 상태는 외부에. MCP 서버가 내부 상태를 들고 있으면 재시작, 스케일아웃, 디버깅이 모두 복잡해진다. 상태는 DB·외부 API·에이전트 메모리에 위임하고 서버는 순수한 함수 실행기로 유지하는 것이 장기적으로 훨씬 안정적이다.
시사점: '하나의 서버, 여러 에이전트'는 컴포넌트 재사용과 같은 이야기다
MCP의 상호운용성은 프론트엔드 개발자에게 익숙한 개념의 에이전트 버전이다. 잘 설계된 React 컴포넌트가 여러 페이지에서 재사용되듯, 잘 설계된 MCP 서버는 여러 에이전트에서 호출된다. 차이가 있다면 소비자가 UI 컴포넌트가 아닌 LLM 모델이라는 것—그리고 인터페이스 스펙이 TypeScript 타입이 아닌 자연어 docstring이라는 것이다.
이 관점에서 보면 MCP 서버 설계는 본질적으로 '에이전트를 위한 API 설계'다. 어떤 툴을 노출할지, 툴의 이름과 설명을 어떻게 쓸지, 반환값의 형태를 어떻게 구성할지—이 결정들이 에이전트가 툴을 얼마나 잘 활용하는지를 직접 결정한다. Claude Code 사용자라면 .mcp.json 한 파일로, Google ADK 사용자라면 MCPToolset 한 줄로, Rust 개발자라면 rmcp 크레이트로 같은 서버를 바라볼 수 있다는 사실은—이 설계 투자의 ROI가 단일 클라이언트 통합보다 구조적으로 높다는 것을 의미한다.
전망: MCP는 에이전트 워크플로우의 'npm'이 될 수 있다
백링크 체커 사례처럼 솔로 빌더가 자신의 API를 MCP로 노출하고 npx 한 줄로 배포하는 패턴이 확산되면, MCP 서버 생태계는 npm 패키지 생태계와 유사한 형태로 성장할 가능성이 있다. 이미 Vercel AI SDK 통합, Chrome 익스텐션, CLI 배포를 다음 스텝으로 계획하는 팀들이 나오고 있다.
프론트엔드 개발자에게 이 흐름이 중요한 이유는, AI 에이전트 워크플로우의 설계 주도권이 점점 프론트엔드 레이어로 가까워지고 있기 때문이다. 어떤 툴을 에이전트에게 줄지, 툴들을 어떻게 조합할지, 에이전트의 작업 결과를 UI에 어떻게 연결할지—이 질문들의 교차점에 MCP가 있고, 이 설계를 가장 잘 할 수 있는 포지션이 사용자 경험과 시스템 구조를 동시에 이해하는 프론트엔드 개발자다. 손발 없는 AI에 손발을 달아주는 일, 지금 시작하기에 진입장벽은 생각보다 낮다.