브라우저 자동화는 이제 ‘업무 편의’가 아니라 CAC를 직접 깎는 성장 레버입니다. 리드 발굴→리서치→폼 제출/DM→후속 팔로업까지 반복 작업이 많은 팀일수록, 사람 대신 에이전트가 브라우저를 안정적으로 돌릴 수 있느냐가 곧 Acquisition 비용 구조를 바꿉니다. 문제는 여기서부터예요. “브라우저를 조종한다”는 말은 쉬운데, 실제 웹은 로그인 벽·봇 탐지·동적 UI(섀도우 DOM) 때문에 자동화가 생각보다 자주 깨집니다. 유저 획득 파이프라인이 한 번만 멈춰도 CAC는 바로 튑니다.
dev.to의 벤치마크 글(“Every AI Browser Tool Is Broken Except One”)은 이 현실을 숫자로 보여줍니다. 동일 모델(Claude Sonnet 4.6), 동일 지시, 3개의 실제 과제에서 Playwright/CLI/OpenClaw 브라우저 도구/tappi를 비교했는데, ‘정답 데이터’ 기준으로 tappi만 3/3을 안정적으로 성공했습니다. 반면 OpenClaw는 결과 품질은 좋았지만 페이지 스냅샷(ARIA 트리)이 커서 토큰을 252K까지 태웠고, Playwright는 빠르고 싸게 보였지만 Reddit에서 자동봇 댓글을 “최상위 댓글”로 오인하는 등 품질 오류가 났습니다. playwright-cli는 아예 봇 탐지(CAPTCHA)에서 막혔고요.
그로스 관점에서 “와 이거다!” 싶은 포인트는, 이 비교가 단순 성능 자랑이 아니라 퍼널 자동화의 핵심 KPI를 찌른다는 겁니다. 브라우저 에이전트의 실행 지표는 결국 3개로 환원돼요. (1) 성공률(끝까지 완료했나), (2) 단위 작업당 비용(토큰/시간), (3) 데이터 품질(틀린 답을 내면 오히려 역효과). 특히 ‘성공률’이 낮으면 자동화는 오퍼레이션 리스크가 되고, 사람이 재작업하면서 CAC 절감이 아니라 CAC 상승으로 돌아섭니다. “싸게 실패”는 성장팀에 독입니다.
tappi가 흥미로운 이유는 구조적으로 그 실패 확률을 줄이는 설계를 했기 때문입니다. 기사에 따르면 tappi는 CDP(Chrome DevTools Protocol)로 “이미 켜져 있는 내 크롬”에 붙습니다. 즉, 로그인 세션/쿠키/확장 프로그램/브라우저 지문을 그대로 상속하니, 신규 headless 브라우저를 띄우는 도구들이 맞는 봇 탐지·로그인 문제를 정면으로 피합니다. 게다가 DOM을 통째로 덤프하지 않고 ‘압축된 요소 리스트’를 줘서 토큰을 아끼고, 섀도우 DOM까지 관통(pierce)해 최신 웹앱 UI에서의 실패를 줄입니다. 이게 곧 “반복 업무를 저비용으로 스케일”시키는 전제조건이죠.
여기서 바로 시사점. 브라우저 에이전트 도입으로 CAC를 낮추려면, “우리 팀이 자동화할 업무”를 AARRR 퍼널에 매핑해봐야 합니다. 예를 들면 Acquisition에서는 (a) 타깃 커뮤니티/디렉토리에서 리드 수집, (b) 경쟁사 가격/스펙 모니터링, (c) 파트너십 문의 폼 제출 자동화가 있고요. Activation/Revenue에서는 (d) POC 신청 후속 메일/캘린더 예약 보조, (e) 온보딩 중 막히는 설정 화면을 에이전트가 대신 클릭/가이드하는 ‘지원형 자동화’도 가능합니다. Retention에서는 (f) 만료 예정 고객에게 맞춤 리마인드 발송을 위한 데이터 갱신(관리자 콘솔/CRM/결제 페이지 확인)이 있죠. “이거 바이럴 될 것 같은데?”라는 감각도 여기서 나오는데, CS/세일즈 처리 속도가 빨라지면 응답 경험이 좋아지고, 추천/리뷰 전환 같은 간접 바이럴이 붙기 시작합니다.
두 번째 dev.to 글(“Tappi MCP Is Live…”)은 실행 속도를 더 끌어올립니다. tappi가 MCP(Model Context Protocol) 서버로 제공되면서 Claude Desktop 같은 클라이언트에 ‘진짜 브라우저’를 붙일 수 있게 됐거든요. 이 말은 곧, 엔지니어가 복잡한 스크립트를 짜지 않아도 “자연어→브라우저 액션”을 빠르게 프로토타이핑할 수 있다는 뜻입니다. 그로스 팀 입장에선 “빨리 테스트해봐야 돼!”가 가능해집니다. 자동화 실험의 리드타임이 줄면, 채널/카피/리스트/세그먼트 A/B 테스트 빈도가 올라가고 학습 속도가 올라갑니다.
전망은 명확합니다. 모델 추론 성능은 계속 좋아질 겁니다(구글의 Gemini 3.1 Pro처럼 ‘에이전트 워크플로’ 강화를 강조하는 흐름도 있고요). 그런데 CAC를 실제로 내리는 쪽은 모델보다 브라우저 실행 레이어의 안정성입니다. 앞으로 경쟁은 “누가 더 똑똑한 모델을 쓰나”보다 “누가 더 높은 자동화 성공률로, 더 낮은 토큰/시간으로, 더 정확한 데이터를 뽑나”로 이동합니다. 성장팀이 지금 할 일은 하나예요: 브라우저 자동화의 KPI를 제품 KPI처럼 다루는 것. 성공률(완주율), 토큰당 완료건수, 재작업률(품질)을 대시보드에 올리고, 가장 돈이 새는 퍼널 구간부터 자동화를 붙이세요. CAC가 내려갈지 말지는—거의 여기서 결정납니다.