AI 에이전트가 ‘말만 하는 챗봇’에서 ‘행동하는 운영자’로 넘어오면서, 제품 가치가 곧바로 퍼널 지표로 번역되기 시작했다. 최근 Claude의 Computer Use + Dispatch 조합(velog의 Claude 블로그 리뷰 요약 기반)은 “설정 없이” 파일을 열고, 브라우저를 조작하고, 개발 도구까지 돌리는 경험을 전면에 세운다. 이건 기능 업데이트가 아니라 온보딩과 활성화(Activation)의 난이도를 통째로 낮추는 퍼널 재설계다.
핵심 이슈는 명확하다. 에이전트가 실제로 클릭/타이핑/네비게이션을 하기 시작하면, (1) 첫 성공 경험은 빨라져 전환율이 오르지만, (2) 자동화가 한 번이라도 깨지면 신뢰가 붕괴해 리텐션이 급락한다. 즉 가치 전달 속도와 운영 리스크가 같은 축에서 움직이는 구조다.
맥락을 퍼널로 해석해보면, Claude가 제시한 3-tier 실행 우선순위(Connector → 브라우저(Chrome) → Computer Use)가 힌트다. Connector는 안정적이고 빠르며 계측도 쉽다. 반대로 화면 기반 조작은 범용성이 있지만 느리고, UI 변경에 취약하다. 여기서 중요한 성장 인사이트는 “자동화를 더 똑똑하게”가 아니라 자동화를 ‘어디까지’ 내려보낼지 결정하는 것이 곧 퍼널 최적화라는 점이다. OSWorld 72.5%로 인간 전문가 수준에 근접했다는 벤치마크(원문 요약 인용)는 ‘가능성’을 증명하지만, 제품의 승부는 ‘성공률 평균’이 아니라 유저가 만나는 실패 모드의 설계에서 갈린다.
실패 모드가 왜 치명적이냐? 링크드인의 에디터가 ProseMirror에서 Quill로 조용히 마이그레이션하면서 브라우저 자동화가 한 번에 붕괴한 사례(dev.to 포스트)는 자동화 제품의 숙명적인 리텐션 리스크를 보여준다. 셀렉터/DOM에 기대어 “그냥 텍스트를 넣는” 방식은 플랫폼이 내부 모델(Delta 등)을 바꾸는 순간 즉시 깨진다. 사용자는 에러 로그를 보지 않는다. “AI가 고장났다”는 인상만 남고 D7/D30 리텐션이 내려간다.
여기에 Dispatch(폰에서 지시→PC에서 실행)가 결합되면 기대치는 더 올라간다. 유저는 ‘대화’가 아니라 ‘완료’를 산다. 이때 자동화가 중간에 멈추면, 단순 실패가 아니라 시간 손실+통제 상실로 인지된다. Activation은 좋아지는데 Churn이 더 빨라지는, 가장 비싼 패턴이 나온다.
시사점은 3가지로 압축된다. 첫째, Activation 실험의 핵심 KPI를 “첫 성공까지 걸린 시간(TTFS)”과 “첫 실패 이후 복구율(Recovery Rate)”로 쪼개라. Computer Use는 TTFS를 극단적으로 줄여주지만, 복구 설계가 없으면 그 이득을 D7에서 토해낸다.
둘째, 자동화의 ‘행동’에는 반드시 서버사이드 가드레일이 필요하다. dev.to의 deny-by-default 스코프 게이트 설계(툴 스코프 enum 고정, high-risk 5개는 CEO 승인 없이는 실행 불가, fail-close와 명확한 blockedReason)는 단순 보안이 아니라 전환 퍼널의 마찰을 통제하는 UX 장치다. 모든 거절을 403으로 뭉개면 유저는 “작동 안 함”으로 인식한다. 반대로 empty_scope / missing_scope / approval_required로 쪼개면, UI에서 버튼을 비활성화하거나 승인 플로우로 자연스럽게 라우팅해 이탈 대신 ‘다음 행동’을 만든다.
셋째, “화면 조작” 레이어를 쓰는 제품이라면 변경 감지→런타임 분기→폴백이 제품 기능이어야 한다. 링크드인 사례의 교훈은 단순하다: 플랫폼은 안정성을 보장하지 않는다. 그러니 (a) 에디터/페이지 타입을 런타임에서 감지하고, (b) 가능하면 내부 API(Quill instance 등)를 우선 사용하며, (c) 불명확하면 클립보드 이벤트 같은 ‘최후의 폴백’으로 내려가야 한다. 이걸 코드 품질이 아니라 리텐션 방어 장치로 봐야 한다.
전망: 2026년의 승자는 “에이전트가 더 많은 일을 한다”가 아니라, 에이전트 자동화 퍼널을 ‘계측 가능한 신뢰’로 운영하는 팀이 가져간다. Connector 기반(안정/저비용)에서 시작해, 브라우저/OS 조작(범용/고위험)으로 확장하되, 각 레이어마다 ①성공률 ②평균 실행시간 ③실패 사유 분포 ④승인 발생률 ⑤실패 후 재시도율을 고정 지표로 박아야 한다.
결국 질문은 하나다. “이 기술로 무엇을 자동화할 수 있나?”가 아니라 “자동화가 깨지는 순간에도 유저가 떠나지 않게 퍼널을 설계했나?” Claude의 Computer Use와 Dispatch는 성장의 문을 열었다. 이제 제품팀이 해야 할 일은, 그 문을 통과한 유저가 D30까지 남아 있게 만드는 ‘가드레일+복구 UX+관찰성’의 패키징이다.