리텐션은 결국 ‘내일도 하게 만드는 루틴(스트릭)’ 싸움입니다. 문제는 많은 팀이 스트릭을 살리려다 알림·개인화·상담형 UX를 과하게 얹고, 그 순간 COGS(특히 LLM 추론비)가 리텐션 이득을 집어삼킨다는 점입니다. 오늘의 핵심 이슈는 하나입니다: 스트릭을 지키는 레버를 켜면서도, 운영비는 선형이 아니라 ‘통제 가능’하게 만들어야 합니다.
dev.to의 Trophy 팀은 24M 스트릭을 운영하며 흥미로운 전역 패턴을 공유했습니다. 스트릭 손실의 25%가 금요일에 발생하고, 토요일(19%), 수요일(18%)이 뒤를 잇습니다(출처: dev.to ‘Guess what day most people lose their streak?’). 개별 앱 팀이 자기 데이터만 보면 “우리 유저가 나약해서”로 끝날 수 있지만, 횡단 인프라가 모은 데이터는 다른 결론을 줍니다. 유저 의지의 문제가 아니라 ‘요일 리듬’이라는 예측 가능한 리스크가 존재한다는 것.
여기서 많은 팀이 바로 “금·토에 LLM로 개인화 알림을 더 세게 돌리자”로 뛰어듭니다. 그런데 또 다른 dev.to 글(‘The Hidden Cost of Running LLM Applications at Scale’)이 경고하듯, 청구서는 모델 단가가 아니라 호출 전 설계 결정에서 터집니다. 같은 모델을 모든 작업에 쓰는 습관, 상한 없는 에이전트 루프, 과도한 RAG 청크, 비대한 툴 스키마, 굳이 합성(synthesis)하는 단계가 누적되면 6개월 뒤 비용이 3배가 됩니다. 즉 리텐션을 살리려다 비용으로 죽는 전형적인 함정이 열립니다.
두 소스를 묶으면 실행 포인트가 선명해집니다. 첫째, 스트릭 방어는 ‘전체에게 더 자주’가 아니라 깨질 확률이 높은 구간에만 더 정밀해야 합니다. 금요일 리스크가 크다면, 전 유저에게 7일 내내 알림을 늘릴 게 아니라 금·토에만 강도를 올리고 다른 요일은 최소화하는 편이 CAC/LTV 관점에서 이깁니다. 둘째, 정밀 타격을 위해 LLM을 쓰더라도 “개인화 = 매번 비싼 추론”이 되지 않게 구조를 바꿔야 합니다: 간단한 카피 변형·타이밍 추천은 저가 모델로, 에지 케이스만 고가 모델로 라우팅하고(모델 티어링), 에이전트 루프는 하드 캡을 두고, RAG는 요일/유저 상태에 따라 top-k를 줄이며, 툴 스키마는 LLM이 결정해야 하는 변수만 남겨 토큰을 다이어트합니다(출처: dev.to ‘The Hidden Cost…’).
시사점은 ‘그로스 실험’ 형태로 설계할 때 더 강력합니다. 예를 들어 “금요일 이탈 확률이 높은 코호트”를 정의하고(최근 3주 연속 금/토 미션 미완료, 혹은 금요일 세션 길이 급감), 그 코호트에만 리마인드 정책을 단계적으로 적용합니다. A안은 규칙 기반(비LLM) 카피+푸시, B안은 저가 LLM로 1회 개인화 문구 생성(주 1회 캐시), C안은 고가 LLM+RAG로 완전 개인화. 목표 지표는 D7/D30 스트릭 유지율과 함께 알림 1회당 추가 유지일(Incremental days retained per notification), 그리고 유저당 추론비(LLM COGS/User)를 동시에 봐야 합니다. 리텐션이 올라도 COGS가 더 빨리 오르면, 그건 성장 레버가 아니라 부채입니다.
전망은 명확합니다. 스트릭 인프라처럼 ‘횡단 데이터’가 쌓일수록, 팀은 더 이상 감으로 알림을 쏘지 않게 됩니다. 대신 요일·상황·세그먼트별로 실패 확률을 예측하고, 그 구간에만 비용을 배치하는 운영으로 이동합니다. 그리고 LLM은 만능 엔진이 아니라, “필요한 순간에만, 가장 싼 형태로” 끼워 넣는 방향이 정답입니다. 앞으로 이기는 팀은 리텐션을 ‘더 많은 메시지’로 사지 않습니다. 더 정확한 타이밍과 더 얇은 추론 레이어로 삽니다.