MCP(Model Context Protocol)는 에이전트가 외부 툴·데이터에 붙는 방식을 표준화해 “한 번 연동하면 어디서나 동작”하는 채널을 연다. 문제는 프로덕션에서 그 채널이 곧바로 성장으로 이어지지 않는다는 점이다. dev.to의 비판적 리뷰는 MCP가 실제 운영에서 비용 폭주(토큰)와 보안 리스크로 인해 퍼널을 깨뜨리는 장면을 정리한다.
핵심 이슈는 두 가지다. 첫째, ‘컨텍스트 윈도우 세금’. MCP는 툴 스키마·파라미터 정의를 대화 턴마다 대량으로 컨텍스트에 싣는다. 리뷰는 GitHub/DB 서버 예시로 “질문하기 전 이미 수만 토큰을 태운다”는 현실을 보여주며, Cloudflare 분석(복잡 에이전트에서 컨텍스트의 최대 81% 낭비)과 MCPGauge(입력 토큰 236배 팽창)를 인용한다. 이건 단순 성능 이슈가 아니라 COGS가 CAC를 갉아먹는 구조적 문제다.
둘째, 보안. Equixly의 테스트 결과(명령 주입 43%, SSRF 30%, 임의 파일 접근 22%) 같은 수치가 말하듯, MCP 서버는 ‘툴 호출’이 아니라 ‘새 공격 표면’이 되기 쉽다. mcp-remote 패키지의 고위험 취약점, Inspector RCE, “인증 없는 인터넷 노출 MCP 서버가 대량”이라는 Knostic 스캔 결과 등은 한 번의 사고가 신뢰와 리텐션을 함께 태울 수 있음을 시사한다(출처: dev.to 기사 종합).
맥락을 성장 관점으로 번역하면 트레이드오프가 명확해진다. MCP는 통합 비용을 낮춰 신규 채널(통합/툴 마켓/에이전트 스토어)에서의 도달을 늘릴 수 있다. 즉, 상단 퍼널에서 CAC를 낮출 잠재력이 있다. 하지만 하단 퍼널(전환·확장·리텐션)은 ‘신뢰’와 ‘단위경제(토큰·운영비)’가 잠금장치다. 스키마가 컨텍스트를 잡아먹으면 응답 지연·실패율이 올라가고, 그 즉시 활성/리텐션 지표가 흔들린다. 보안 사고는 더 단호하다—전환율이 아니라 “계정 삭제”와 “세일즈 파이프라인 중단”으로 돌아온다.
그렇다면 실행 전략은 “MCP를 할까 말까”가 아니라 “성장가드(Guard)를 깔고 확장하느냐”다. 여기서 두 번째 소스가 힌트를 준다. dev.to의 mcps-audit는 OWASP MCP Top 10 + OWASP Agentic AI Top 10에 맞춰 MCP 서버/에이전트 코드를 스캔하고(툴 포이즈닝, 인증 부재, 메시지 서명 부재, 로깅 실패 등), CI/CD에 붙일 수 있는 형태로 제공한다. 성장 조직 입장에선 이게 ‘보안 툴’이 아니라, 엔터프라이즈 전환을 막는 가장 큰 마찰(보안 심사·리스크 질의)을 줄여주는 세일즈 가속 장치다.
시사점은 세 가지로 정리된다. (1) MCP 도입 KPI를 “연동 수”가 아니라 “툴 성공률·p95 토큰·툴콜당 비용·보안 스캔 PASS율”로 둬야 한다. 상단 퍼널(도달)과 하단 퍼널(신뢰/비용)을 한 장부에서 본다. (2) 기본 경로는 ‘HTTP/CLI 우선 + MCP는 필요한 구간에만’이 현실적이다. dev.to 비판이 말하듯 많은 작업은 잘 설계된 API/CLI가 더 싸고 안정적이다. (3) 조직 단위에선 MCP의 중앙화 가치도 무시하면 안 된다. GeekNews가 요약한 관점처럼, 인증·텔레메트리·콘텐츠 동기화(프롬프트/리소스의 최신 배포)는 엔터프라이즈 운영에서 강력한 레버다. 다만 그 가치를 얻으려면, 처음부터 보안/관측/비용 통제 레이어를 제품화해야 한다.
전망: 단기적으로는 “MCP vs CLI” 논쟁이 더 커지겠지만, 시장은 결국 하이프가 아니라 운영 지표로 수렴한다. MCP가 살아남는 경로는 두 갈래다. (A) 컨텍스트 세금을 줄이는 프로토콜/클라이언트 개선(중복 제거, 온디맨드 로딩, 스키마 압축)과 (B) 신원·무결성·감사로그를 기본값으로 만드는 보안 표준화(스캐닝·서명·제로트러스트 게이트웨이). 성장팀이라면 결론은 간단하다. 채널 확장을 욕심내기 전에, ‘COGS 폭주와 신뢰 붕괴’를 막는 성장가드를 깔아야 MCP가 CAC 절감으로 이어진다.