MCP(Model Context Protocol) 연동을 ‘기능 추가’로만 보면 답이 안 나옵니다. 그건 제품의 새 버튼이 아니라, 에이전트가 고객 워크플로우 안으로 들어가는 배포 채널이자 전환 장치입니다. 사용자는 앱을 배우는 대신, 이미 쓰는 코딩/운영 도구(Claude Code, Codex CLI 등)에서 바로 당신의 기능을 호출합니다. 학습 비용이 사라지면 퍼널의 가장 비싼 구간(도입·온보딩·PoC)이 짧아지고, 결과적으로 CAC가 내려갑니다.
dev.to의 Bifrost 테스트 글은 이 포인트를 실무적으로 보여줍니다. Bifrost를 게이트웨이로 두면 모델/툴/MCP 서버를 에이전트마다 일일이 배선하지 않고, 중앙에서 라우팅·키·로그·비용을 통제합니다. 특히 글에서 강조한 건 “에이전트가 프롬프트만 읽는 게 아니라 툴 정의·스키마·권한까지 읽는다”는 현실입니다. MCP 서버가 늘수록 컨텍스트가 비대해지고, 에이전트는 일을 하기 전에 ‘도구 목록 읽기’에 토큰과 시간을 씁니다. 이는 성능 문제를 넘어 첫 가치 도달 시간(TTV)을 늘려 전환을 깎는 마찰입니다.
여기서 Bifrost의 Code Mode 같은 접근이 의미를 갖습니다. 모든 툴을 매번 컨텍스트에 밀어 넣는 대신, 메타-도구로 진입시키고 필요한 문서/스텁만 단계적으로 로드합니다(출처: dev.to, Bifrost CLI/Code Mode 실사용 검증). 성장 관점에서 이건 “토큰 절감”보다 더 직접적입니다. 데모 성공률↑ → PoC 기간↓ → 세일즈 사이클↓로 연결되기 때문입니다. 같은 리드 수에서 계약까지 걸리는 시간이 줄면, 세일즈 인건비·솔루션 엔지니어 투입시간이 함께 내려가 CAC가 구조적으로 감소합니다.
하지만 MCP가 채널이 되는 순간, 보안은 ‘옵션’이 아니라 리텐션과 확장매출을 좌우하는 신뢰 인프라가 됩니다. dev.to의 nginx-ui MCP 취약점 사례는 이를 정면으로 때립니다. /mcp는 인증이 있었는데 /mcp_message는 인증 미적용 + “빈 allowlist=allow-all” 기본값으로 열려 있었고, 결과적으로 인증 없이 MCP 도구 호출로 nginx 설정 파일 수정/삭제, 재시작까지 가능한 수준(CVE-2026-33032, CVSS 9.8)으로 번졌습니다(출처: dev.to, nginx-ui 취약점 분석 글). MCP를 기존 앱에 ‘덧붙일’ 때, 권한/인증이 일관되게 상속된다는 가정이 얼마나 위험한지 보여주는 케이스입니다.
시사점은 단순합니다. MCP 연동 = 신규 유입 채널로 설계하되, 동시에 엔터프라이즈 체크리스트로 번역해야 합니다. (1) 엔드포인트별 인증 미들웨어 강제(‘한 군데 빠지면 끝’) (2) allowlist 기본값은 deny-all (3) 툴 권한 최소화(폴더/리포 단위 스코프) (4) 가상키/프로젝트별 키 분리로 예산·권한·감사 추적 분리 (5) “누가 어떤 툴을 어떤 모델로 호출했는가”를 로그로 증명. Bifrost 글이 말한 “inspectable control plane(관찰 가능한 통제면)”이 여기서 성장 장치가 됩니다. 보안이 좋아서가 아니라, 신뢰를 증빙할 수 있어야 전환이 안 깨지고 갱신이 붙기 때문입니다.
전망: MCP/에이전트 통합의 승자는 ‘더 많은 툴’을 붙이는 팀이 아니라, 발견(Discovery)·권한(Governance)·관찰(Observability)을 한 세트로 제품화하는 팀입니다. 단기적으로는 CLI/게이트웨이 레이어가 파트너 채널이 되어 CAC를 낮출 겁니다(에이전트 생태계 안에서 노출되기 때문). 중장기적으로는 nginx-ui 사례처럼 “MCP가 열어주는 운영 권한”이 커질수록, 보안 설계가 곧 세일즈 역량이 됩니다. 결론은 하나: MCP는 기능이 아니라 유통망입니다. 그리고 유통망은 반드시 신뢰 계약(거버넌스)과 함께 팔아야 스케일이 납니다.