말 한 마디로 SaaS가 등록된다—MCP가 프론트엔드 레이어에 닿는 순간
claude mcp add --transport http saaskr https://saaskr.com/api/mcp
한 줄 명령어로 Claude나 Cursor에 연결하고, 자연어로 서비스 등록을 지시하면 끝. saaskr.com이 공개한 이 MCP 서버 구현 사례가 흥미로운 건 단순히 자동화가 잘 됐다는 게 아닙니다. Next.js 라우트 핸들러 파일 하나, SDK 없이 MCP Streamable HTTP를 JSON-RPC로 직접 구현했다는 점입니다.
프론트엔드 개발자 입장에서 이 접근은 꽤 시사적입니다. 별도 백엔드 인프라 없이 이미 익숙한 Next.js의 Route Handler(/api/mcp/route.ts)가 AI 에이전트의 도구 엔드포인트가 될 수 있다는 걸 증명했으니까요. 디렉토리 폼 작성의 마찰을 없애겠다는 단순한 프로덕트 아이디어가, 결국 프레임워크 숙련도를 AI 워크플로우와 연결하는 최소 구현 경로를 보여준 셈입니다.
문제는 도구의 수가 아니라 컨텍스트 낭비다
MCP 서버를 직접 만들 수 있게 됐다면, 다음 질문은 자연스럽게 따라옵니다. "도구가 많아지면 어떻게 되는가?"
dev.to에 공개된 Progressive MCP Tool Routing 케이스 스터디는 이 질문에 냉정한 숫자로 답합니다. GitHub, Kubernetes, PostgreSQL, Datadog 등 47개 도구를 Claude 3.5 Sonnet에 한꺼번에 붙였을 때, 시스템 프롬프트에서만 18~22K 토큰이 소진됩니다. 실제 작업과 무관한 스키마 설명이 컨텍스트 윈도우의 절반을 잠식하는 거죠. 그 결과는? 도구 선택 환각률 34%, 작업 정확도 61%.
이 문제의 본질은 토큰 낭비가 아닙니다. 트랜스포머의 어텐션 예산이 실제 요청이 아닌 관련 없는 스키마 패딩에 분산된다는 구조적 문제입니다. 프론트엔드 개발자에게 친숙한 언어로 바꾸면, 렌더링에 필요 없는 데이터를 전부 내려받고 클라이언트에서 필터링하는 패턴과 구조적으로 같습니다.
Progressive Disclosure, 에이전트에게도 통한다
해법으로 제시된 Progressive Tool Routing은 UI/UX의 Progressive Disclosure 원칙을 에이전트 컨텍스트 설계에 그대로 적용합니다. 3단계 파이프라인입니다.
- Intent Classifier: DistilBERT 기반 경량 분류기가 사용자 의도를 5개 도메인(배포·데이터·옵저버빌리티·보안·인프라)으로 분류. 이 단계에서 에이전트 컨텍스트에 들어가는 툴 스키마는 0개.
- Domain Router: 분류된 도메인의 8~12개 도구만 컨텍스트에 노출. 토큰 비용 5개 수준.
- Full MCP Execution: 이제 컨텍스트의 70~80%가 툴 정의가 아닌 추론에 쓰입니다.
결과는 명확했습니다. 동일한 200개 운영 태스크 기준으로 환각률이 34%에서 20.4%로 감소(40% 상대적 개선), 토큰 사용량은 평균 51.4K에서 13.7K로 73% 절감. "PostgreSQL 레플리카 패스워드를 Vault에서 교체하고 무중단으로 재시작" 같은 복합 태스크에서 모놀리식 에이전트가 3번 시도에 성공했던 것을 Progressive Router는 첫 시도에 올바른 3단계 도구 시퀀스를 선택했습니다.
하이브리드 아키텍처: 생산 현장에서 살아남은 패턴
MCP를 실제 운영 환경에 투입해 얻은 교훈도 있습니다. dev.to의 하이브리드 에이전트 회고는 93개 도구를 하나의 MCP 서버에 몰아넣는 모놀리식 접근이 결국 실패했음을 솔직하게 기록합니다. 스키마 오버헤드만 55,000 토큰, 규모에 따라 월 $51,000에 달하는 비용이 발생했죠.
살아남은 전략은 이렇습니다.
- MCP는 구조에, CLI는 실행에: 타입이 필요한 쿼리는 MCP, 오버헤드가 0에 가까워야 하는 단순 액션은 50토큰짜리 셸 커맨드로.
- 집중된 서버: 도구 3~8개, 단일 도메인, 약 1,500 토큰. 독립 배포 가능.
- 프로세스 독립성: "플러그인은 부모 프로세스의 생명주기를 물려받지만, MCP 서버는 자신의 생명주기를 스스로 관리한다." 컨테이너로 배포하면 클라이언트가 죽어도 서버 상태가 유지됩니다.
이 원칙들은 PR 하나가 77일 동안 살아남다 결국 리셋된 실패 경험에서 추출됐습니다. 아키텍처 이론이 아닌, 프로덕션 장애에서 나온 규칙입니다.
프론트엔드 개발자에게 이 모든 게 의미하는 것
세 사례를 연결하면 에이전트 UX 설계의 실용적 프레임이 나옵니다.
첫째, MCP 서버는 Next.js Route Handler로 시작할 수 있습니다. SDK 없이 JSON-RPC를 직접 구현한 saaskr.com 사례는, 별도 인프라 없이 기존 Next.js 프로젝트에 에이전트 도구 엔드포인트를 붙이는 가장 낮은 진입점을 보여줍니다. app/api/mcp/route.ts 하나로 Claude가 사용할 수 있는 도구를 정의하는 것, 이건 프론트엔드 개발자의 영역입니다.
둘째, 컨텍스트 설계가 곧 UX 설계입니다. 도구를 얼마나 정교하게 만드느냐보다, 에이전트가 어떤 순서로 어떤 정보를 받느냐가 성능을 결정합니다. Progressive Disclosure는 UI 컴포넌트 전략이기도 하고, 에이전트 컨텍스트 전략이기도 합니다—같은 원리입니다.
셋째, 작게 집중하는 서버가 이깁니다. 93개 도구 모놀리스보다 3~8개 도구를 가진 집중된 서버 여럿이 토큰 효율, 유지보수성, 장애 격리 모두에서 우월합니다. 컴포넌트를 잘게 쪼개는 프론트엔드의 직관이 MCP 서버 설계에도 그대로 적용됩니다.
전망: 프론트엔드가 에이전트 인터페이스의 설계자가 되는 시대
MCP가 표준 프로토콜로 자리잡으면서, 에이전트와 서비스 사이의 인터페이스를 설계하는 일이 새로운 프론트엔드 전문 영역으로 부상하고 있습니다. Route Handler로 도구를 정의하고, Progressive Disclosure로 컨텍스트를 최적화하고, 집중된 서버로 장애를 격리하는 이 패턴들은 결국 사용자 경험 설계의 연장선입니다.
"AI에게 말 한 마디면 SaaS가 등록된다"는 사례가 보여주듯, 가장 좋은 에이전트 UX는 사용자가 도구의 존재를 의식하지 못하는 UX입니다. 그 투명성을 만드는 설계—토큰 최적화, 스키마 라우팅, 프로세스 격리—가 이제 프론트엔드 개발자의 필수 어휘가 되고 있습니다.