MCP와 에이전트는 SaaS를 ‘방문하는 제품’에서 ‘호출되는 도구’로 바꿉니다. dev.to의 PaperLink 사례처럼(118개 MCP 툴) 사용자는 UI를 열지 않고 “영수증 사진 정리”, “미결 인보이스 찾기”, “파일 업로드→링크 생성→만료 설정” 같은 작업을 한 문장으로 끝냅니다. 문제는 여기서부터입니다. 유입은 열렸는데, 그 다음 단계(활성화/전환/리텐션)가 기존 웹/앱 퍼널처럼 작동하지 않습니다.
핵심 이슈는 한 줄로 요약됩니다: 에이전트 채널은 ‘대화’가 아니라 ‘툴콜’로 전환되는 순간부터 퍼널이 깨진다. PaperLink는 에이전트가 사람이 상상 못한 필터 조합으로 버그(OVERDUE 전이 누락)를 찾아냈고, 이는 곧 “대화형 UX”가 아니라 “API/워크플로우 품질”이 경험을 지배한다는 신호입니다. 반대로 Safari MCP의 LinkedIn 자동화 실패 사례는 더 잔인합니다. 자동화는 전 단계에서 “성공”을 반환했지만, 실제로는 rich-text editor의 내부 상태가 변하지 않아 게시가 불가능했습니다(dev.to의 isTrusted:false/blur/focusout 연쇄 버그). 즉, 에이전트는 성공 로그를 남기면서도 유저 경험을 실패시킬 수 있고, 팀은 이를 모른 채 전환이 낮다고만 느끼게 됩니다.
이 맥락에서 “대부분의 팀은 데이터 플라이휠이 없다”는 지적이 정확히 맞물립니다(dev.to, LangChain/LangSmith 맥락). 트레이스를 수집해도 데이터셋으로 구조화하지 않고, 자동 평가(회귀 테스트/베이스라인)가 없고, 평가자를 신뢰할 수 없고, 배포까지 루프가 닫히지 않으면 개선이 ‘축적’되지 않습니다. 에이전트 채널에서는 이 문제가 더 빠르게 터집니다. 왜냐하면 유저의 행동이 UI 이벤트가 아니라 비가시적인 툴 호출·체인·권한·재시도·검증으로 나타나고, 실패가 “조용히” 발생하기 때문입니다.
성장 관점에서 에이전트 채널을 퍼널화하려면, 퍼널 정의부터 다시 써야 합니다. 추천 프레임은 4단계입니다. (1) Discover(발견): 에이전트/클라이언트 툴 디렉토리 노출→설치/연결. (2) Trust(권한/신뢰): OAuth 스코프 선택, 팀/워크스페이스 매핑, 안전 확인(컨펌). (3) Value(가치 실현): 첫 ‘성공한 작업’(북마크 가능한 Job Done) 완료. (4) Habit(습관화): 반복 작업 템플릿화/자동화, 재방문 호출. 기존 AARRR에 억지로 끼우면 Activation은 ‘첫 툴체인 성공’, Retention은 ‘7일 내 반복 호출/자동화 저장’으로 재정의됩니다.
그 다음은 계측입니다. 에이전트 퍼널의 최소 이벤트 스키마를 표준화해야 합니다. 예: agent_connect_success, oauth_scope_selected, tool_call_started/finished, tool_chain_completed, needs_confirmation_shown, confirmation_approved/denied, tool_error_type(권한/검증/외부사이트/레이트리밋), side_effect_verified(외부 상태 변화 검증). LinkedIn 사례가 말하듯 ‘성공 반환’은 지표가 될 수 없습니다. “DOM이 바뀌었는가”가 아니라 “소스 오브 트루스가 바뀌었는가”를 검증 이벤트로 박아야 합니다(예: Lexical/ProseMirror 내부 state, 또는 SaaS의 서버 상태 변화/웹훅 수신).
표준화의 핵심은 툴 설계입니다. PaperLink는 read/write/delete를 분리하고 OAuth 스코프를 세분화했습니다. 이는 보안뿐 아니라 전환율 레버이기도 합니다. 스코프가 과하면 연결 단계에서 이탈하고, 스코프가 부족하면 실행 단계에서 실패합니다. 따라서 “스코프 최소화”가 아니라 ‘첫 가치’에 필요한 최소 스코프 패키지를 제품화해야 합니다(예: 영수증 정리 패키지, 링크 공유 패키지). 또한 툴은 에이전트가 잘 쓰는 형태로 변해야 합니다: 배치 처리(한 번의 create-transactions), 명확한 확인 지점(저장 전 컨펌), 조합 가능한 필터(리스트/검색) 같은 패턴이 전환을 끌어올립니다.
실험은 ‘프롬프트’가 아니라 ‘퍼널 마찰’에 걸어야 합니다. 바로 돌릴 수 있는 A/B 테스트는 세 가지입니다. 1) 컨펌 UX: “항상 확인” vs “고위험만 확인”(금전/외부 게시/삭제) → 완료율과 사고율(롤백/CS)을 함께 봅니다. 2) 툴 실패 복구: 실패 시 자동 재시도/대체 경로(에디터 API 직접 호출 등) 제공 vs 단순 에러 반환 → 체인 완료율 변화 측정. 3) 첫 작업 온보딩: 에이전트용 ‘레시피 프롬프트/샘플 작업’ 제공 vs 자유 대화 → D1 활성화(첫 chain success)와 D7 반복 호출을 봅니다.
전망은 분명합니다. 에이전트 채널은 CAC를 낮출 잠재력이 큽니다(사용자가 “검색→방문” 대신 “바로 실행”으로 들어오므로). 하지만 승자는 “MCP 서버를 만든 팀”이 아니라, 에이전트 트래픽을 퍼널로 재정의하고, 성공을 검증 가능한 상태 변화로 계측하며, 트레이스를 데이터셋/평가/배포로 닫는 팀입니다. 지금 쌓이는 실패 사례는 경고이자 기회입니다. 에이전트가 호출하는 순간부터—전환은 제품이 아니라 운영 시스템(관측·평가·표준·실험)의 결과로 결정됩니다.