AI 에이전트가 제품에 붙는 순간, 성장 병목은 모델 성능이 아니라 COGS(토큰/인프라 비용)와 신뢰(보안·안정성)로 이동합니다. 응답이 조금만 느려지거나, 요금이 예측 불가능해지거나, “이거 안전해?”라는 의심이 생기면 전환율은 조용히 깎이고(D1), 불안은 리텐션 이탈(D7/D30)로 번집니다. 그래서 지금 필요한 건 ‘기능 추가’가 아니라 단위경제와 신뢰를 동시에 방어하는 인프라 레버입니다.
dev.to의 Stacklok 글은 이 레버를 비용 측면에서 구체화합니다. MCP Optimizer를 개인별로 깔아 토큰을 아끼는 방식은 팀 스케일에서 구성 드리프트(설정 불일치)와 로컬 리소스 낭비로 망가집니다. 특히 에이전트는 여러 MCP 서버를 붙이며 툴 카탈로그를 컨텍스트에 매번 욱여넣는데, 이게 곧 토큰 폭증→지연 증가→툴 선택 오류로 연결됩니다. Stacklok의 vMCP(가상 MCP 서버) 게이트웨이에 Optimizer를 얹어 툴 목록을 on-demand 검색(find_tool) + 호출(call_tool)로 바꾸면, 벤치마크 기준 요청당 토큰을 60~85%까지 줄일 수 있다는 주장이 나옵니다(출처: dev.to/stacklok).
하지만 비용만 잠그면 끝이 아닙니다. 같은 dev.to의 다른 글은 MCP 서버가 지금 “신뢰 폭탄”을 품고 있음을 경고합니다. adversa.ai가 공개한 시나리오는 달력 초대장 같은 저위험 입력에서 시작해, 에이전트가 툴을 연쇄 호출(tool chaining)하며 고위험 로컬 실행기로 상승해 zero-click RCE로 이어질 수 있다는 것입니다. 핵심은 각 툴 권한이 그럴듯해 보여도, 에이전트가 중간 대리자(confused deputy)가 되면 권한의 합이 공격 경로가 된다는 점입니다. 더 무서운 건 “사용자 승인 프롬프트면 충분” 같은 태도가 시장 표준이 되면, 결국 강제 샌드박싱/권한 모델 변경이 오고 준비 안 된 MCP 서버는 한 번에 깨질 가능성이 크다는 전망(4~6주)까지 나왔다는 점입니다(출처: dev.to/ai-agent-economy).
여기서 그로스 관점의 결론은 명확합니다. COGS와 신뢰는 같은 레이어에서 동시에 관리해야 합니다. vMCP처럼 트래픽이 한 점으로 모이는 구조는 “토큰 절감”뿐 아니라 “보안 경계의 단일화”라는 장점을 줍니다. 즉, 툴 디스커버리/호출이 게이트웨이를 통과하도록 만들면 (1) 카탈로그 노이즈를 줄여 비용과 품질을 같이 올리고, (2) 중앙에서 인증·인가·감사 로그를 걸어 신뢰를 제품 기능이 아니라 인프라 규율로 만들 수 있습니다.
실행 관점에서 바로 적용 가능한 체크리스트는 두 묶음입니다. 비용 방어(Activation 가속): ① 툴 카탈로그 전체 주입을 금지하고 on-demand 검색으로 전환(Optimizer류), ② 팀 단위 단일 배포로 구성 드리프트 제거(vMCP/Kubernetes 오퍼레이터 방식), ③ 토큰·지연·툴선택 오류율을 한 대시보드에서 코호트로 추적(온보딩 직후 vs 숙련 사용자). 신뢰 방어(Retention 방어): ① 툴 실행 샌드박싱(툴별 격리), ② 스코프를 READ/WRITE처럼 명시해 권한 상승 경로 차단, ③ 입력 스키마 검증과 레이트리밋, ④ “서버 내부 툴 체이닝 금지”로 연쇄 상승 차단, ⑤ 모든 호출 로깅으로 사고 시 원인 규명. 이 조합은 보안팀만의 과제가 아니라, CS 티켓/환불/이탈을 줄이는 성장 레버입니다.
전망은 ‘에이전트 운영 표준’이 바뀌는 쪽으로 기울어 있습니다. 비용은 Optimizer·게이트웨이로 내려가고, 보안은 샌드박싱·스코프·감사로 올라갑니다. 결국 경쟁 우위는 “더 똑똑한 에이전트”가 아니라, 더 싸고(낮은 COGS) 더 믿을 수 있게(낮은 사고율) 대규모로 굴리는 운영 능력에서 갈립니다. 지금 할 일은 단순합니다. 툴 디스커버리와 실행을 중앙으로 모으고(vMCP), 토큰 낭비를 줄이며(Optimizer), 그 중앙을 가장 먼저 하드닝하세요. 성장 그래프는 그 다음에 따라옵니다.