에이전트가 퍼널에 들어오는 순간, 성장은 ‘기능 추가’가 아니라 ‘마찰 제거’의 게임이 됩니다. 유저가 망설이는 지점은 늘 비슷합니다. 무엇을 입력해야 하는지 모르겠고(입력 마찰), 답이 늦거나 들쭉날쭉하고(응답 마찰), 다음 단계로 넘어가기까지 처리가 길어집니다(처리 마찰). 이 세 가지가 겹치면 CAC는 올라가고 전환율은 내려갑니다.
dev.to의 Tap 사례가 흥미로운 이유는, 에이전트 자동화의 비용 구조를 ‘매 세션 추론’에서 ‘1회 추론 + 무한 실행’으로 뒤집었기 때문입니다. 기존 웹 자동화형 에이전트는 사이트를 열 때마다 셀렉터를 찾고, 단계를 재구성하고, 같은 문제를 다시 풀며 토큰을 태웁니다. Tap은 여기서 “인터페이스 조작은 한 번만 알아내면 끝”이라는 전제를 세우고, 알아내기(LLM)와 실행(결정론적 프로그램)을 분리합니다. 한 번 forge해서 .tap.js를 만들면, 이후에는 LLM 호출 없이 1초 내 실행·구조화된 결과·항상 같은 출력으로 돌아갑니다(출처: dev_to).
이 구조가 퍼널에 주는 효과는 명확합니다. 첫째, 응답 시간 단축: 런타임이 LLM 레이턴시에 종속되지 않으니 ‘기다림’이 줄고 이탈이 줄어듭니다. 둘째, 실패율 감소: 프롬프트 편차로 인한 불안정성이 줄어 “이번엔 되겠지” 같은 재시도 마찰이 사라집니다. 셋째, COGS 안정화: 한 번의 forging 비용(기사에선 약 $0.50) 이후 런타임 비용이 0에 가까워지면, 전환을 올려도 비용이 같이 폭증하지 않습니다. 성장 팀 관점에선 “전환율 × 실행비용”의 곱을 낮추는, 꽤 직선적인 레버입니다.
반대로 카카오모빌리티의 ‘AI 사진 접수’는 마찰 제거를 입력 부담 축소로 풀었습니다. 퀵·배송 접수에서 유저가 가장 막히는 건 물품 종류/크기/차량 선택 같은 ‘모호한 폼’입니다. 사진 한 장으로 분류·추천·문구 작성까지 자동화하면, 유저는 판단을 외주화하고 입력을 생략합니다. 과거 ‘AI 주소 자동 붙여넣기’가 접수 시간을 평균 24% 단축했다는 데이터는, 이런 입력 마찰 축소가 실제 퍼널 속도를 바꾼다는 강한 증거입니다(출처: AI타임스).
세 사례를 한 문장으로 정리하면 이렇습니다. Tap은 ‘처리’를 결정론적으로 고정해 퍼널의 실패/지연을 없애고, 카카오는 ‘입력’을 멀티모달로 줄이며, 롯데시네마는 ChatGPT 앱으로 ‘탐색/질문’의 진입장벽을 대화형으로 낮춥니다(출처: 글로벌경제신문). 다만 여기서 성장 관점의 체크포인트는 “대화형 UI가 편하냐”가 아니라, 실제로 (1) 입력 단계 수를 줄였는지, (2) 응답을 예측 가능하게 만들었는지, (3) 다음 행동(예약/결제/접수)까지의 처리 시간을 단축했는지입니다.
시사점은 두 가지입니다. 첫째, 에이전트는 이제 ‘똑똑함’ 경쟁이 아니라 퍼널 엔지니어링 경쟁입니다. LLM을 계속 호출해 매번 생각하게 만들면, 전환은 모델 품질이 아니라 변동성(지연/실패)과 비용에 발목 잡힙니다. 반대로 Tap처럼 실행을 프로그램으로 굳히면, 성장은 제품팀이 통제 가능한 영역으로 들어옵니다. 둘째, 입력 마찰을 줄이는 멀티모달은 CAC를 건드립니다. “설명할 필요 없는 입력(사진/복붙)”은 광고 랜딩의 의도를 곧바로 행동으로 연결해, 유입 대비 활성화율을 올립니다. 특히 신규 유저에서 효과가 큽니다.
전망: 다음 웨이브는 ‘에이전트가 퍼널을 돌리는 방식’의 표준화입니다. 인터페이스 자동화는 (a) 한 번 학습해 영구 실행(결정론), (b) 입력을 1샷으로 축소(멀티모달), (c) 대화형 진입으로 탐색 비용 제거(Conversational entry)라는 세 갈래로 수렴할 가능성이 큽니다. 이때 승자는 “에이전트를 붙였다”가 아니라, 전환 이벤트 기준으로 레이턴시/실패율/입력 스텝을 계측하고 A/B로 깎아내리는 팀입니다. 결국 퍼널은 말로 설득하는 곳이 아니라, 마찰을 없애서 ‘그냥 되게’ 만드는 곳이니까요.