AI 에이전트 시장에서 ‘기능’은 이제 차별점이 아닙니다. 진짜 전장은 에이전트가 어디에 배치되느냐(채널) 입니다. Claude Code·Cursor·Windsurf 같은 에디터 안에서 바로 툴이 호출되는 MCP(Model Context Protocol) 흐름이 커지면서, 유저는 제품 사이트가 아니라 자신의 작업 공간에서 제품을 처음 만납니다. 이때 MCP는 단순한 연동 규격이 아니라, CAC를 좌우하는 배포 표준이 됩니다.
dev.to의 IPFS.NINJA 사례는 이 변화를 가장 노골적으로 보여줍니다. 이 팀은 관리형 IPFS 핀닝 서비스를 만들면서, MCP 서버로 12개 툴(업로드/핀/폴더/사용량/분석 등)을 노출해 사용자가 “자연어로 요청→모델이 툴 호출→CID/URL 반환”까지 에디터 내에서 끝내게 했습니다. 가입 후 API 키만 넣으면 npx로 실행되는 ‘60초 셋업’을 강조한 것도 포인트입니다. 즉, 제품의 첫 경험을 랜딩페이지가 아니라 워크플로우 안의 즉시 가치(Time-to-Value) 로 재설계한 겁니다.
그로스 관점에서 이건 퍼널을 바꿉니다. 기존엔 “광고/콘텐츠 → 랜딩 → 가입 → 온보딩 → 첫 가치”였는데, MCP가 끼면 “에디터에서 MCP 추가 → 첫 액션 성공(업로드/핀) → 필요할 때마다 반복 사용”으로 단축됩니다. 컨텍스트 스위칭 제거(터미널/대시보드 이동 감소)는 단순 편의가 아니라, 활성화(Activation) 구간의 마찰을 줄여 전환율을 올리는 장치입니다. 특히 IPFS처럼 ‘가끔 필요하지만 설정이 귀찮은’ 범주의 서비스는 이 한 번의 마찰 제거가 체감 전환을 크게 만듭니다.
하지만 여기서 성장의 역풍도 같이 옵니다. 에이전트가 외부 도구를 실행하는 순간, 에이전트는 ‘UX’가 아니라 권한 경계(authorization boundary) 가 됩니다. dev.to의 보안 글(authorization attacks)은 에이전트가 전통적 권한 상승을 뚫지 않아도, 자기가 가진 자격증명으로 “그럴듯하게” 실행해버리는 취약점을 지적합니다. 즉, MCP로 채널이 열릴수록 “연동 확장”은 성장 레버가 되지만, “권한 통제 실패”는 신뢰 붕괴로 리텐션/레퍼럴을 한 번에 깨뜨리는 성장 리스크가 됩니다.
또 다른 dev.to 글(Should my code agent use my credentials?)이 던지는 질문은 더 현실적입니다. 에이전트가 내 크리덴셜을 쓰면 감사 로그가 ‘내가 한 일’로 남고, 사고 시 책임 경계가 무너집니다. 성장 지표로 번역하면, B2B에선 세일즈/보안 심사 단계에서 막히고(전환 하락), B2C에선 한 번의 사고로 커뮤니티 평판이 깨지며(리텐션·레퍼럴 하락) CAC가 구조적으로 상승합니다. MCP 채널이 커질수록 ‘권한 설계’는 제품의 신뢰 인프라가 아니라 유통 인프라의 필수 조건이 됩니다.
시사점은 명확합니다. MCP로 확장하려는 팀은 “툴을 많이 붙여서 유입을 늘리자”만으로는 부족합니다. (1) 에이전트 실행을 최소권한으로 ‘번역’하는 레이어(auth transmogrification), (2) 실행 전 2단 검증(two-checkpoint validation), (3) 오케스트레이터가 검증 단계를 건너뛰지 못하는 순차 파이프라인(sequential pipeline), (4) security.md 같은 제약조건 명문화까지를 ‘배포 패키지’로 같이 내야 합니다(보안 글이 제안한 전술). 그리고 자격증명은 “내 계정 공유”가 아니라 에이전트 전용 아이덴티티 + 좁은 스코프 + 회수/로테이션 + 감사 로그 분리로 가야, 채널 스케일이 가능합니다.
전망: MCP는 곧 ‘앱스토어’가 아니라 워크플로우 스토어처럼 작동할 겁니다. 사용자는 검색보다 “내 에디터/에이전트가 추천하는 툴”로 제품을 채택하고, 승자는 기능보다 연동의 즉시성(셋업 1분)과 안전한 위임(권한/감사 기본값) 을 동시에 제공하는 팀이 됩니다. IPFS.NINJA가 보여준 ‘에디터 내 핀닝’은 시작일 뿐입니다. 다음 경쟁은 “툴 수”가 아니라, 연동 확장 속도 × 권한 통제 품질의 곱으로 결정됩니다—이 곱이 커질수록 CAC는 내려가고, 리텐션은 오래 갑니다.