크롬이 AI를 브라우저 기본 기능으로 끌어올리면, 성장팀이 익숙하게 다루던 퍼널의 첫 단추(유입)가 바뀝니다. 구글이 한국에 ‘Gemini in Chrome’을 확대 출시하며 웹 요약, 탭 간 비교, 이메일/캘린더 작업, 이미지 변환까지 브라우저 사이드 패널에서 처리하게 만들었죠(네이트 보도, 구글 공식 블로그). 유저는 더 이상 “검색→클릭→랜딩페이지”로 들어오지 않습니다. “지금 하던 작업을 더 빨리 끝내기”라는 흐름 안에서 AI가 다음 행동을 제안하고 실행합니다.
맥락을 보면 이 변화는 단순한 편의 기능이 아닙니다. 브라우저가 ‘작업 OS’가 되면서, AI는 탭/히스토리/구글 앱(지메일·지도·캘린더·유튜브) 컨텍스트를 묶어 의사결정 단위를 재조립합니다. 가격 비교처럼 원래라면 여러 사이트를 왕복해야 했던 행동이 “요약/비교 결과”로 압축되면, 기존 SEO·콘텐츠·리타겟팅이 먹히던 지점이 줄어듭니다. 유입 채널이 ‘페이지’에서 ‘브라우저 어시스턴트의 응답/추천/실행’으로 이동하는 겁니다.
여기서 WebMCP가 붙으면 게임이 한 단계 더 바뀝니다. WebMCP는 웹사이트를 AI 에이전트가 호출 가능한 ‘도구(tool)’로 노출하는 브라우저 API 표준(구글·마이크로소프트가 W3C 커뮤니티 그룹에서 추진)로, 에이전트가 버튼을 화면 스크래핑으로 “추측”하는 대신 타입이 있는 입력/구조화된 응답으로 기능을 호출하게 합니다(dev.to 사례). 즉, 사이트는 “읽히는 페이지”를 넘어 “실행되는 인터페이스”가 되고, 퍼널은 방문 기반 세션보다 ‘툴 호출→결과 반환→확인(사용자 승인지점)’ 중심으로 재정의됩니다.
성장 관점 시사점은 3가지입니다. (1) CAC 구조: 클릭을 사는 대신 ‘에이전트가 선택하는 도구’가 되면, 상단 퍼널 비용은 줄 수 있지만(에이전트가 비교·요약으로 선별), 그만큼 “호출될 확률”을 올리는 최적화가 필요합니다. WebMCP라면 툴 설명/스키마/응답 품질이 새로운 SEO가 됩니다. (2) Activation 재정의: 기존 온보딩은 ‘앱에 들어와서’ 배우는 과정이었지만, AI 브라우저 시대엔 첫 가치 경험이 “브라우저 패널에서 우리 기능을 1번 호출해 즉시 결과를 얻는가”로 바뀝니다. Time-to-Value를 세션 내부가 아니라 ‘작업 흐름 내부’에서 측정해야 합니다. (3) 전환 마찰 이동: 구글은 이메일 전송/일정 추가 같은 민감 작업에 사용자 확인을 강제한다고 밝혔는데(구글 블로그), 앞으로 결제·권한·외부 전송은 모두 ‘확인 스텝’에서 전환율이 갈릴 가능성이 큽니다. 전환 최적화 포인트가 버튼 위치가 아니라 “에이전트가 요약한 제안→사용자 승인”의 카피/신뢰/리스크 설계로 이동합니다.
바로 실험을 설계해보면 좋습니다. A/B 1) “에이전트 친화 인터페이스” 실험: WebMCP(또는 유사한 구조화 엔드포인트)를 붙이고, 툴 설명을 ‘문제-해결-출력’ 형태로 바꿨을 때 툴 호출률/성공률/재호출률(D1)을 봅니다. A/B 2) 승인 단계 최적화: 사용자 확인이 필요한 액션(메일 발송, 예약 생성, 결제 전 단계)에서 요약 카드 UI/리스크 문구/되돌리기(undo) 제공이 승인률과 이후 리텐션에 미치는 영향을 봅니다. A/B 3) “비교 결과에서의 브랜드 점유” 실험: 크롬 탭 비교/요약에서 우리 제품이 더 자주 추천되게 하는 구조(명확한 가격/플랜, 스키마 마크업, 한 문장 가치제안)를 바꿔 인용/추천 발생률을 측정합니다.
전망은 명확합니다. 브라우저 기본 AI는 유저를 ‘더 많이 클릭하게’ 만드는 게 아니라 ‘덜 클릭하게’ 만듭니다. 그럼에도 성장 기회는 큽니다. 클릭이 줄어드는 만큼, “작업을 끝내는 데 필요한 가장 짧은 경로”를 제공하는 제품은 오히려 상단 퍼널을 건너뛰고 바로 활성화로 진입할 수 있습니다. 다음 분기 성장은 광고 예산이 아니라, 우리 제품이 AI 브라우저/에이전트의 작업 흐름에 얼마나 자연스럽게 꽂히는지—즉 ‘호출 가능한 도구’로서의 설계에 달려 있습니다.