MCP 기반 에이전트가 ‘연결’ 단계에서 ‘운영’ 단계로 넘어가면서, 성장은 기능 추가가 아니라 두 가지 숫자에 막힙니다. 첫째는 토큰 COGS(질문 1건당 모델·컨텍스트 비용)이고, 둘째는 보안 리스크가 만드는 신뢰 붕괴(도입 보류→전환 하락, 사고/불안→리텐션 하락)입니다. 지금부터의 경쟁은 “도구를 몇 개 붙였나”가 아니라 “질문 1건을 얼마나 싸고 안전하게 처리하나”로 재정의됩니다.
dev.to의 ‘Smart MCP’ 글은 이 비용 병목을 라우팅 아키텍처로 정면 돌파합니다. 기존 클라이언트(호스트 LLM) 중심 오케스트레이션은 여러 툴의 원본 결과가 그대로 호스트 컨텍스트로 쏟아지며 토큰을 태웁니다. 반면 MCP 서버 안에 작은 목적형 모델(embedded router)을 넣어 의도 분류→툴 선택→병렬 실행→서버에서 합성까지 끝내고, 호스트에는 “정제된 단일 응답”만 반환합니다. 결과적으로 컨텍스트 오염을 줄이고, 쿼리당 토큰 소비를 극단적으로 낮출 수 있다는 주장(예: 다중 툴 질의에서 80%+ 절감)이 핵심입니다.
이 구조를 그로스 관점으로 번역하면 간단합니다. 토큰 COGS가 내려가면 (1) 동일 예산에서 더 많은 트래픽을 감당해 CAC의 ‘스케일 페널티’를 줄이고, (2) 가격을 올리지 않아도 마진이 생겨 온보딩/세일즈에서 할인·프리 티어 같은 실험 여지가 커지며, (3) 지연시간이 줄어 체감 품질이 올라 D1/D7 리텐션 방어가 가능해집니다. 즉 “라우팅 최적화”는 엔지니어링 작업 같지만, 실제로는 유료 전환율과 리텐션을 흔드는 성장 레버입니다.
문제는 비용만 깎으면 끝이 아니라는 점입니다. dev.to의 또 다른 글(‘Why every MCP server needs a security audit…’)은 50개+ 오픈소스 MCP 서버를 스캔했더니 커맨드 인젝션, 패스 트래버설, SSRF, 하드코딩 시크릿, 입력 검증 부재 같은 취약점이 ‘거의 공통적으로’ 발견됐다고 말합니다. MCP 서버는 일반 API가 아니라 파일·네트워크·쉘·DB에 닿는 “권한 프로세스”이고, 호출 주체도 사용자뿐 아니라 프롬프트에 의해 조작될 수 있는 모델입니다. 신뢰 경계가 흐릿한 만큼, 한 번의 사고/의심이 세일즈 사이클을 길게 만들고(전환↓), 기존 고객의 사용 범위를 축소시키며(확장↓), 보안팀에 막혀 이탈을 촉진합니다(리텐션↓).
여기에 velog의 ‘MCP가 CLI보다 43배 비싼 이유…’가 현실감을 더합니다. MCP는 컨텍스트에 툴 스펙과 응답 텍스트가 쌓이면서 비용·속도·안정성이 흔들리고, 이 체감이 “이거 써도 되나?”로 이어지는 순간 퍼널에서 미끄러집니다. 즉 비용과 보안은 따로가 아니라 같은 퍼널 문제입니다. 느리고 비싼 경험은 전환을 떨어뜨리고, 불안한 경험은 리텐션을 떨어뜨립니다.
시사점은 명확합니다. MCP 에이전트를 스케일하려면 ‘비용 라우팅’과 ‘보안 거버넌스’를 하나의 패키지로 묶어야 합니다. 실행 가능한 실험 주제를 3개로 쪼개면 빠릅니다. (1) 서버사이드 라우팅 A/B: 클라이언트 오케스트레이션 vs embedded router를 비교해 쿼리당 토큰, p95 지연, 세션당 완료율(목표 작업 성공률)을 측정합니다. (2) 권한 최소화 실험: 툴을 “모든 사용자에게 전부”가 아니라 역할 기반으로 노출(툴 레지스트리 필터링)해 사고 반경을 줄이고, 동시에 불필요한 툴 스펙 로딩을 줄여 토큰도 함께 절감합니다. (3) 보안 감사의 세일즈 전환 실험: 스캐너/체크리스트 기반 리포트(취약점 카테고리, severity, 수정 가이드)를 ‘도입 패키지’로 제공해 보안 리뷰 리드타임을 줄이는지(POC→계약 전환율, 세일즈 사이클 길이)로 검증합니다.
전망: MCP 생태계가 커질수록 “에이전트 기능”은 빠르게 상향 평준화될 겁니다. 그 다음 차별화는 두 가지로 수렴합니다. 첫째, 라우팅·합성·모델 선택을 서버에서 통제해 토큰 COGS를 예측 가능하게 만드는 팀. 둘째, 입력 검증·샌드박싱·시크릿 관리·SSRF 방지·감사 로그까지 갖춰 신뢰 비용을 낮추는 팀입니다. 결국 성장의 승부처는 ‘더 똑똑한 에이전트’가 아니라, 더 싸고 더 감사 가능한 에이전트입니다. MCP 에이전트로 성장하고 싶다면, 다음 스프린트의 KPI는 기능 개수가 아니라 “쿼리당 원가”와 “감사 통과 가능성”부터 잡아야 합니다.