삼성이 갤럭시 S26에 Perplexity를 AI 에이전트로 탑재한다는 소식(브릿지경제·더페어)은 겉으론 “음성으로 리마인더 등록” 같은 편의 기능처럼 보이죠. 근데 저는 여기서 와 이거다! 싶었습니다. 이건 기능 추가가 아니라 ‘앱 실행’이라는 퍼널 단계가 사라지는 사건입니다.
기존 모바일 퍼널은 대체로 설치 → 회원가입 → 앱 열기 → 기능 탐색 → 핵심행동이었어요. 그런데 사이드 버튼/웨이크워드(“헤이 플렉스”)로 에이전트를 호출해 의도(intent)만 말하면 작업이 끝나는 UX가 오면, 유저는 더 이상 “어느 앱에서 했더라?”를 기억하지 않습니다. 유저의 뇌 속 네비게이션이 ‘아이콘’에서 ‘의도’로 갈아타는 거죠.
이 변화가 무서운 이유는, 온보딩/활성화의 정의가 바뀌기 때문입니다. 앱에서의 활성화가 “첫 리마인더 생성”이었다면, 인텐트 UX에서는 “첫 의도 성공(예: 일정 등록이 실제로 저장됨)”이 활성화가 됩니다. 즉 Activation 이벤트가 ‘앱 내부 이벤트’에서 ‘시스템 레벨 작업 완료’로 승격돼요. 이거 바이럴 될 것 같은데? 유저 입장에선 ‘방법’을 배우는 대신 ‘말’만 기억하면 되니까요.
여기서 그로스 관점의 기회는 2가지입니다. 첫째, 퍼널 마찰(Friction)이 급감합니다. 홈 화면에서 앱 찾고, 로딩 기다리고, 탭 이동하다 이탈하던 구간이 통째로 날아가요. 둘째, 멀티 에이전트가 기본값이 됩니다. 삼성 조사에서 “AI 사용자 10명 중 8명이 두 개 이상의 에이전트를 쓴다”고 했는데(기사 내 언급), 그 말은 곧 유저의 기본 행동이 ‘비교/스위칭’이라는 뜻입니다. 그러면 브랜드는 “앱 점유율”이 아니라 “인텐트 점유율”을 두고 싸우게 됩니다.
그럼 제품팀은 뭘 해야 할까요? 퍼널을 이렇게 다시 쪼개야 합니다: Wake(호출) → Intent Capture(의도 파싱) → Action Execution(툴 실행) → Confirmation(결과 확인) → Reuse(재사용).
- Wake에서 실패하면 재시도도 안 옵니다(D1 바로 흔들림).
- Confirmation이 느리거나 애매하면 신뢰가 깨지고 Churn으로 갑니다.
- Reuse를 만들면 D7이 뜁니다(“지난번처럼 ~해줘” 루틴).
여기서 “빨리 테스트해봐야 돼!” 포인트가 하나 더 있습니다. 음성 처리까지 LLM에 몰아주면 비용·지연이 전환율을 갉아먹어요. dev.to 글이 강조하듯 LLM은 추론(Reasoning)에 강하고, 음성(STT/TTS/발음평가)은 전문 Speech API/경량 모델이 싸고 빠릅니다. 예시로 p50 수백 ms vs 수 초, 비용도 7~10배 차이가 난다고 하죠. 이 차이는 단순 인프라 최적화가 아니라 Conversion rate 실험 속도입니다. 호출→응답이 1~2초만 빨라져도, 인텐트 UX에선 체감 성공률이 올라가고 재사용 의지가 커져요.
실행 레시피는 의외로 단순합니다. 아키텍처를 STT(경량) → LLM(의도/플랜) → Tool call(앱/시스템 액션) → TTS(경량)로 나누고, 각 단계의 KPI를 분리 트래킹하세요.
- Wake-to-STT success rate
- STT confidence 구간별 Intent success rate
- Tool execution latency p50/p95
- Confirmation 이후 24시간 내 재호출률(D1 proxy)
이렇게 쪼개면 “어디서 유저가 이탈할 것 같은데…”를 데이터로 바로 찍어낼 수 있습니다.
전망은 명확합니다. 첫째, 앱은 ‘목적지’가 아니라 ‘백엔드 툴’이 됩니다. 둘째, 신규 유저 획득도 광고보다 레퍼럴 문장(프롬프트) 공유가 강해질 수 있어요. “이거 한 번 말해봐”가 설치 링크보다 전파력이 셀 때가 옵니다. 셋째, 승자는 모델 크기가 아니라 인텐트 퍼널을 얼마나 매끄럽게 닫느냐에서 갈립니다. 비용·지연을 Speech API/경량 모델로 줄이고, LLM은 플래닝에 집중시키는 팀이 실험을 더 많이 돌리고 더 빨리 학습합니다. 결국 그 팀의 D7/D30이 올라가고 LTV가 이깁니다.