LLM을 쓰는 제품의 CAC는 광고비만으로 결정되지 않습니다. 실제로는 “유입 → 활성화 → 전환”을 얼마나 자주, 얼마나 싸게 실험하느냐가 CAC를 갈라놓습니다. 여기서 로컬 LLM 전환은 단순한 인프라 선택이 아니라, 성장 실험의 탄약(비용·속도·제약)을 재편하는 결정입니다.
dev.to의 한 이커머스 팀 사례는 숫자가 명확합니다. 월 8만 건 상품 설명을 GPT-4o로 생성하며 월 800달러 이상을 쓰다가, Ollama로 Llama 4(Maverick) 계열을 로컬 배포로 옮겨 전기료 약 40달러 수준으로 낮췄습니다(하이브리드 운영 후 총액 830→250달러). 이건 “비용 절감”이 아니라 LTV/CAC, ARPU 개선을 위한 여유분을 즉시 만들어낸 겁니다.
맥락을 그로스 관점에서 해석하면 포인트는 3가지입니다. 첫째, 고정비(하드웨어)로 변동비(API)를 대체해 한계비용을 깎으면, 상단 퍼널 실험(랜딩 카피·상품 상세·SEO 템플릿·온보딩 메시지)을 ‘더 많이’ 돌릴 수 있습니다. 둘째, 레이트 리밋/지연이 줄면 배치 처리와 실시간 개인화가 가능해져 전환 구간의 마찰을 줄입니다. 셋째, 경쟁사 가격·구매이력 같은 민감 데이터는 외부 API로 나가는 순간 컴플라이언스·법무·보안 검토가 CAC처럼 누적되는데, 로컬은 이 “숨은 통과세”를 제거합니다(동 기사에서 GDPR 맥락 언급).
하지만 “로컬로 옮기면 끝”은 슬라이드에서나 살아남는 결론입니다. 같은 dev.to의 다른 글(‘What Ships vs. What Dies in Slides’)이 말하듯, 프로덕션은 모델이 아니라 경계(boundary)에서 죽습니다: 데이터가 지저분하고, 통합이 70%를 먹고, 장애는 새벽 3시에 납니다. 즉 로컬 LLM로 COGS를 줄이려면 배포/통합/관측까지 같이 설계해야 절감이 성장으로 연결됩니다.
시사점은 실전 체크리스트로 정리됩니다. (1) 브레이크이븐을 수요로 계산: 원문은 5만+ 요청/월부터 로컬이 이득이라고 봤습니다. 우리 제품도 “월 요청 수 × 평균 토큰 × 실패 재시도율”로 손익선을 먼저 잡아야 합니다. (2) 모델 선택은 품질이 아니라 실패율: 이 팀이 base Maverick에서 Hermes 파인튜닝으로 옮긴 이유는 ‘감성’이 아니라 JSON 파싱 실패(88%→97%)와 툴콜 정확도(78%→93%)였습니다. 대량 생성/자동화는 1~2% 품질보다 5~10% 실패율이 운영비(재시도·검수·CS)를 폭발시킵니다.
그로스팀이 바로 써먹을 설계는 “하이브리드 라우팅”입니다. 로컬은 고볼륨·저복잡·규격 출력(상품/FAQ/태그/번역/요약)에 붙이고, 클라우드는 브랜드 보이스·창의 카피·저볼륨 고가치에 남깁니다(첫 기사도 실제로 브랜드 카피는 Claude/GPT-4o에 남김). 이렇게 하면 비용은 즉시 내려가고, 전환에 직결되는 고품질 구간은 방어할 수 있습니다.
또 하나: 로컬 전환의 진짜 보상은 “절감된 돈”이 아니라 “빨라진 루프”입니다. 절감분을 (a) 온보딩 메시지/상품 상세 A/B 테스트 트래픽, (b) 리텐션 리마인드/리커버리 시나리오, (c) 코호트별 개인화 규칙 실험에 재투자하세요. CAC는 보통 유입보다 활성화·전환율에서 더 크게 꺾입니다. 로컬 LLM은 그 병목 구간을 싸게 자주 두드릴 수 있게 합니다.
전망: 로컬 LLM은 “전부 대체”가 아니라 “대량 파이프라인의 표준 옵션”으로 자리 잡을 가능성이 큽니다. 단, 승자는 모델 성능보다 운영 설계가 가릅니다. 통합세를 줄이기 위한 검증 레이어, 실패 시 폴백(클라우드/캐시/휴먼 핸드오프), 그리고 응답 품질을 전환 지표(CTR, CVR, D7 유지)와 연결해 모니터링하는 팀만이 ‘API비 절감’을 ‘CAC 하락’으로 번역할 겁니다. 결국 질문은 하나입니다: 로컬로 아낀 비용을, 당신은 실험 회전수로 바꿔 넣을 준비가 되어 있나요?