AI 에이전트를 제품/채널로 붙이는 순간, 그로스 병목은 의외로 뻔한 3가지로 수렴합니다. ① 토큰 비용(=실행 비용), ② 정확도(=실패율), ③ 연결성(=툴 발견·인증·설정). 이 3개가 흔들리면 CAC가 튀고, 전환율은 새고, 리텐션은 꺾입니다. 그런데 요즘 MCP(Model Context Protocol) 생태계에서 “이거다!” 싶은 힌트가 쏟아지고 있어요. 비용·정확도·연결성을 한 번에 건드리는, 실행 가능한 최적화 포인트들이요.
먼저 비용. dev.to의 WebClaw vs Playwright MCP 비교 글은 토큰이 ‘모델’이 아니라 ‘포맷’에서 새는 현실을 숫자로 보여줍니다. 접근성 트리 스냅샷을 LLM 컨텍스트로 넣을 때, 포맷을 더 컴팩트하게만 바꿔도 페이지에 따라 51~79% 토큰이 줄었습니다(위키 51%, 깃허브 78%, 해커뉴스 79%). 브라우저 자동화는 스냅샷을 5~10번 찍는 게 기본이라, 이 절감률은 누적되며 곧바로 유닛코스트를 깎습니다. “Conversion rate가 얼마나 오를까요?”를 비용 관점에서 보면, 동일 예산으로 더 많은 세션/실행을 태울 수 있으니 퍼널 실험 속도도 같이 올라가요.
두 번째는 정확도. 토큰을 줄이면 품질이 떨어질 것 같지만, 역설적으로 ‘행동 가능한 정보만 남기는 압축’은 정확도를 올리기도 합니다. WebClaw가 모든 DOM 요소에 ref를 붙이는 대신 클릭/입력 가능한 인터랙티브 요소 위주로 라벨링하는 설계가 대표적이죠. 에이전트가 실제로 조작할 수 없는 노드까지 들고 있으면 선택지가 폭발하고(탐색 공간 증가), 잘못된 타겟을 고르는 확률이 올라갑니다. 또 다른 dev.to 글(35-tool MCP 서버, 95% 토큰 절감 사례)처럼 “한 번 구조화(분석)하고, 질의로 제공”하는 방식은 맥락을 길게 퍼 올리는 대신 정답 후보를 좁혀줍니다. 이건 비용 절감이면서 동시에 실패율 감소(=재시도 감소)라서 CAC에 이중으로 이득이에요.
세 번째는 연결성. 유저가 ‘에이전트가 일을 하게’ 만들려면 결국 툴을 붙여야 하는데, 여기서 유저가 이탈합니다. 설정 지옥, 각 툴마다 다른 인증, 팀 온보딩 난이도… 이거 바이럴 될 것 같은데? 반대로 말하면, 한 번 풀면 팀 단위 확산이 터집니다. dev.to의 Arcade MCP Gateway는 “단일 URL로 툴 카탈로그를 묶고, 클라이언트(IDE/앱) 이동에도 설정을 재사용”하게 만들어 연결성 비용을 낮춥니다. 게다가 JIT(Just-in-time) 권한 요청과 중앙 가시성은 운영 리스크를 줄여 ‘에이전트가 자꾸 멈춘다’는 신뢰도 문제까지 같이 잡습니다.
연결성의 다른 축은 ‘발견 가능성(discoverability)’입니다. CryptoDataAPI 사례(dev.to)에서 에이전트가 API 문서를 못 찾아 30번 넘게 404를 때렸다는 건, 곧 온보딩 퍼널의 마찰을 그대로 숫자로 보여준 사건이에요. /docs, /openapi.json, /llms.txt, /.well-known/ai-plugin.json 같은 표준 경로와, 404 응답에 문서 링크를 넣는 ‘빵부스러기(breadcrumb)’는 구현 30분짜리인데 첫 성공시간(Time-to-first-success)을 확 줄입니다. 첫 성공이 빨라지면 D1 잔존이 오르고, 결과적으로 CAC 대비 LTV가 좋아집니다.
시사점은 명확합니다. 에이전트 그로스는 이제 “프롬프트 잘 쓰면 된다”가 아니라, MCP 레이어에서 (1) 컨텍스트 압축(포맷·요약·파일 참조·구조화 질의), (2) 툴 게이트웨이(단일 엔드포인트·표준 스키마·권한/관찰성), (3) 문서 discoverability(표준 경로·리다이렉트·헤더/404 가이드) 3종 세트를 갖추는 싸움입니다. 유저가 여기서 이탈할 것 같은데… 라는 지점이 대부분 “토큰 과금 폭탄”과 “툴 연결 실패”에서 터지니, 이 부분을 먼저 깎아야 퍼널이 열려요. 특히 B2B/팀 확산을 노리면 ‘한 번 설정하면 팀 전체가 복사-붙여넣기’ 되는 구조가 바이럴 계수에 직결됩니다.
전망: MCP 최적화는 곧 ‘에이전트 유통’의 표준이 될 가능성이 큽니다. 브라우저 스냅샷은 파일 기반(--output-mode file)처럼 컨텍스트 밖으로 빼는 방향과, WebClaw/DOM 압축처럼 인컨텍스트를 더 똑똑하게 줄이는 방향이 같이 갑니다(둘 다 dev.to에서 언급). 툴 쪽은 게이트웨이화가 빨라질 거고, 문서는 llms.txt + well-known 매니페스트 + 표준 엔드포인트가 SEO처럼 “에이전트 SEO”가 될 겁니다. 결국 CAC가 너무 높아요… 라는 탄식은 모델 교체보다, 이 3요소를 제품 설계에 박아 넣는 쪽이 더 빨리 해결합니다. 빨리 테스트해봐야 돼요: 토큰/성공률/연결 성공률을 KPI로 박고, AARRR 퍼널에서 온보딩 구간부터 실험을 돌리면 바로 숫자가 움직일 겁니다.