LLM을 제품에 붙이는 순간, 성장팀이 제일 먼저 부딪히는 건 감탄사가 아니라 청구서입니다. 특히 고객지원 챗봇처럼 멀티턴 대화가 길어질수록, 매 턴마다 ‘변하지 않는 시스템 프롬프트/문서’를 다시 보내고 다시 계산하는 구조가 COGS를 갉아먹죠. 유저가 늘면 늘수록 CAC는 그대로인데 변동비가 폭증하는, 스케일에 불리한 모델입니다.
여기서 “와 이거다!” 싶은 포인트가 Amazon Bedrock의 프롬프트 캐싱(prompt caching) 입니다. dev.to의 튜토리얼은 Nova Pro로 5턴 대화를 돌릴 때 입력 토큰 11,814개 중 절반 이상이 고정 시스템 프롬프트(약 2,069 토큰) 반복 비용이었다는 걸 수치로 보여줍니다. 캐시 포인트를 한 번 찍어두면, 이후 동일한 prefix는 재추론이 아니라 캐시 읽기로 처리되고(캐시 읽기 단가가 일반 입력 토큰 대비 90% 저렴), 월 비용 추정이 “거의 반”으로 떨어졌다고 해요(출처: dev.to, How to Implement Prompt Caching on Amazon Bedrock and Cut Inference Costs in Half).
이건 단순한 인프라 최적화가 아니라 그로스 레버입니다. 1) 멀티턴 에이전트의 대화당 비용이 줄면, 무료 구간/체험 구간에서 LLM을 더 넉넉히 쓸 수 있어 전환율(Conversion Rate)을 올릴 실험 여지가 생깁니다. 2) 지연시간도 같이 내려가면, 온보딩/상담 퍼널에서 “유저가 여기서 이탈할 것 같은데…” 구간(대기 시간)에 직접적으로 칼이 들어갑니다. 즉, 캐싱은 COGS↓뿐 아니라 퍼널 마찰(Friction)↓까지 노릴 수 있어요.
그런데 비용만 줄이면 끝일까요? 아니요. 성장의 본질은 실험 빈도입니다. 두 번째 dev.to 글은 LLM이 코드보다 잘하는 데이터프레임 작업(정성 필터링, 분류, 웹 리서치 기반 컬럼 추가, 키 없는 퍼지 조인, 외부 지표로 랭킹)을 ‘함수 호출’처럼 처리해, 의외로 싸고 빠르게 결과를 만든다고 주장합니다(출처: dev.to, 5 DataFrame Operations LLMs Handle Better Than Code). 예를 들어 “가격 페이지를 방문해 최저 유료 티어 연간 가격을 채워라” 같은 작업을 246개 행에 돌려 성공률 99%대를 만들었다는 식이죠.
이 조합이 열어주는 새 퍼널은 명확합니다. 프롬프트 캐싱으로 운영 COGS를 낮추고, LLM 기반 데이터프레임 자동화로 분석·세그먼트·실험 설계를 빠르게 하면, ‘CAC/LTV 개선 루프’를 주 단위가 아니라 일 단위로 돌릴 수 있습니다. “빨리 테스트해봐야 돼!”가 가능해지는 거죠. 예를 들면: - 신규 유저 유입 채널별로 상담/온보딩 대화 로그를 LLM으로 자동 라벨링 → 이탈 사유 코호트 추출(D1/D7 리텐션 저하 원인) - 경쟁사/대체재 가격을 웹 리서치로 주기적으로 수집 → 프라이싱 실험 가설을 더 촘촘히 생성 - ‘키 없는 조인’으로 CRM, 결제, 서포트 티켓을 엮어 LTV 예측 세그먼트를 빠르게 만들고 메시징 실험
시사점은 한 줄입니다. LLM을 “기능”으로만 붙이면 돈 먹는 하마인데, “실험 엔진”으로 재설계하면 성장 비용을 낮추는 무기가 됩니다. 프롬프트 캐싱은 즉시 적용 가능한 COGS 절감 스위치(특히 멀티턴/긴 시스템 프롬프트 서비스에 치명적으로 유효)이고, 데이터프레임 자동화는 그 절감분을 ‘실험 횟수’로 재투자하게 만드는 가속 페달입니다.
전망: 앞으로 LLM 제품의 경쟁은 “모델 성능”보다 단가 구조×실험 속도에서 갈릴 가능성이 큽니다. 캐시 히트율(얼마나 재사용했는가)을 KPI로 두고, 고정 프롬프트/문서 영역을 최대한 prefix로 밀어 넣는 팀이 이깁니다. 동시에 데이터 작업은 ‘완벽한 파이프라인 구축’보다, LLM으로 먼저 러프하게 자동화해 신호를 뽑고(싸게, 빨리), 사람은 검증과 의사결정에 집중하는 방식으로 바뀔 겁니다. 결론은 간단합니다: 비용을 깎으면 실험이 늘고, 실험이 늘면 결국 CAC가 내려가고 LTV가 올라갑니다.