에이전트를 마케팅/세일즈 채널로 붙이는 순간, CAC의 정의가 바뀝니다. 광고비만이 아니라 토큰·리트라이·실패 대응·모니터링이 전부 ‘획득비용’이 됩니다. 특히 리드 수집→아웃리치→데모 예약→온보딩 같은 파이프라인을 에이전트로 자동화하면, 브라우저 단계에서 새는 비용과 품질 저하가 그대로 퍼널 누수로 연결돼요.
첫 번째 핵심 이슈는 브라우저 자동화의 토큰 과금 구조입니다. dev.to의 PageBolt MCP 글은 기존 control-loop 방식(예: Playwright MCP, browser-use)이 클릭/스크린샷/DOM 스냅샷/검증을 모델이 매 스텝 오케스트레이션하면서 왕복 호출이 쌓이고, “페이지 구조 한 번 뜯기”에도 2,000~5,000토큰이 쉽게 탄다고 짚습니다. 여기서 중요한 건 비용이 ‘선형’이 아니라는 점. 셀렉터 미스 한 번, 로딩 지연 한 번이 추가 왕복=추가 토큰=추가 CAC로 바로 증폭됩니다.
PageBolt가 제시하는 해법은 흥미롭습니다. 브라우저 실행을 모델 컨텍스트 밖(서버 인프라)에서 끝내고, 모델은 한 번의 고수준 툴콜로 구조화된 결과(JSON/파일)만 받습니다(출처: dev.to PageBolt MCP 글). “브라우저 실행에 0 토큰”이라는 메시지 자체가 Growth 관점에서 ‘와 이거다!’ 포인트예요. 우리가 원하는 건 브라우저를 ‘조종’하는 모델이 아니라, 퍼널을 전진시키는 에이전트니까요.
맥락을 Growth 언어로 번역하면 이렇게 됩니다. 브라우저 자동화는 리드 스크래핑, 폼 제출, 가격 페이지 체크, 경쟁사 모니터링, 온보딩 튜토리얼 영상 생성 등에서 반복 호출됩니다. 이 반복이 많아질수록 토큰비는 사실상 변동 CAC가 됩니다. 예컨대 하루 500세션에서 검사 1회당 3,000토큰이면 월 수천만 토큰이 쌓이는 구조죠(출처: dev.to PageBolt MCP 글의 예시 테이블). “이거 바이럴 될 것 같은데?”라는 감각은 여기서 나옵니다. 비용이 떨어지면 실험 횟수가 늘고, 실험이 늘면 승률이 올라가니까요.
두 번째 핵심 이슈는 도구 설계(Wrapper vs Native MCP)가 안정성과 비용을 바꾼다는 점입니다. dev.to의 ‘Native MCP server vs wrapper’ 글은 래퍼가 REST API를 번역하는 구조라 입력 스키마/상태 관리가 제한되고, 브라우저처럼 stateful한 워크플로우는 결국 모델이 상태를 떠안거나 복잡한 번역 레이어가 생긴다고 말합니다. 반대로 네이티브 MCP 서버는 에이전트 사용 방식에 맞춘 스키마(예: 멀티스텝 시퀀스+내레이션 포함)를 자연스럽게 제공할 수 있고요. Growth 관점에서 이건 실패율(=리트라이율) 감소와 직결됩니다. 리트라이율은 토큰비뿐 아니라 리드 낙장, 중복 아웃리치, 온보딩 이탈까지 부릅니다.
세 번째 이슈는 “처음엔 잘 되는데 2~3주 후 이상해지는” 워크플로우 드리프트입니다. dev.to의 Vex 글은 drift가 에러처럼 터지지 않고 ‘그럴듯하게’ 망가지는 게 문제라고 정의합니다. 이게 무서운 이유? 세일즈 아웃리치 에이전트가 점점 장황해지거나, 온보딩 에이전트가 질문에 답하는 대신 제품 홍보로 새면, 로그는 멀쩡해도 전환율이 조용히 떨어집니다. 유저가 여기서 이탈할 것 같은데… 딱 그 지점이 드리프트입니다.
그래서 시사점은 명확합니다. 에이전트를 채널로 쓴다면 ‘프롬프트’도 배포 자산이고, 회귀 테스트/드리프트 탐지가 곧 퍼널 방어선입니다. dev.to의 Prompt Regression Tests 글이 제안하듯, 골든 인풋 8~20개와 JSON 스키마/금칙어/필수 필드 같은 불변조건(invariants)만 잡아도 품질 붕괴를 초기에 막을 수 있어요. 여기에 Vex 글의 아이디어(즉시 관련성+대화 궤적을 함께 보는 drift score)를 얹으면, “문장 하나는 괜찮은데 흐름이 샌다”를 조기에 잡아낼 수 있습니다.
실행 관점에서, 바로 Growth 실험으로 바꾸는 방법은 간단합니다. (1) 브라우저 자동화는 고수준 단일 호출로 최대한 바꿔 토큰을 변동 CAC에서 제거하고(출처: PageBolt MCP), (2) stateful 시퀀스는 네이티브 MCP처럼 에이전트 친화 스키마로 실패율을 낮추고(출처: Native vs wrapper 글), (3) 아웃리치/온보딩 메시지는 회귀 테스트를 CI에 넣어 “조용한 전환 하락”을 막습니다(출처: Prompt regression tests). 빨리 테스트해봐야 돼요. 특히 리드 수집→첫 컨택→미팅 셋업까지는 주 단위로 개선 폭이 크게 나옵니다.
전망: 앞으로 ‘에이전트 자동화’ 시장의 경쟁축은 모델 성능보다 단위 작업당 비용(토큰/리트라이)과 품질 안정성(드리프트/회귀)로 이동할 가능성이 큽니다. 즉, “더 똑똑한 에이전트”보다 “더 예측 가능한 에이전트”가 CAC를 이깁니다. 브라우저 실행을 컨텍스트 밖으로 밀어내는 아키텍처와, 프롬프트를 테스트 가능한 인터페이스로 고정하는 팀이 스케일 구간에서 승자일 확률이 높습니다. Conversion rate가 얼마나 오를까요? 토큰비를 30~70% 줄이고(브라우저 구간), 드리프트로 새는 전환을 1~3%p만 방어해도, 에이전트 채널은 ‘실험 가능한 성장 엔진’으로 자리 잡을 겁니다.