LLM/RAG 제품에서 ‘성능이 조금 더 좋다’는 메시지는 이제 차별화가 아니다. 사용자가 체감하는 건 응답이 빠른지(레이턴시), 과금이 합리적인지(가격·제한), 그리고 그 결과로 제품을 계속 쓰게 되는지(리텐션)다. 토큰 비용이 커지면 곧바로 요금제 상향이 막히고, 무료 구간은 얇아지고, 온보딩에서 사용량 제한이 빨리 걸리면서 전환 퍼널이 무너진다.
dev.to의 프롬프트 캐싱 아티클은 많은 팀이 모델 선택이 아니라 “프롬프트 구성” 때문에 토큰을 3~10배 더 태우고 있다고 지적한다. 핵심은 단순하다. 캐싱은 프롬프트의 ‘앞부분(prefix)’이 바이트 단위로 동일해야 히트한다. 그런데 시스템 프롬프트 앞쪽에 날짜, 유저명, 세션ID 같은 동적 값을 섞어 넣는 순간 캐시 히트율은 사실상 0%로 수렴한다. 즉, 잘 다듬어둔 긴 정책/도구 정의/페르소나가 매 호출마다 새로 과금된다.
성장 관점에서 이건 “보이지 않는 CAC”다. 광고비는 줄이기 어렵지만, LLM COGS는 아키텍처 한 번으로 바로 내려간다. ProjectDiscovery 사례(Claude 기반 에이전틱 시스템)처럼 시스템 프롬프트가 수만 토큰이고 툴콜이 많은 제품일수록, 캐시 히트율이 8%→74%로 뛰는 순간 비용 구조가 ‘다른 회사’가 된다(해당 내용은 dev.to 원문이 인용). 이건 원가 절감이 아니라, 무료 체험 확장·온보딩 제한 완화·가격 실험을 가능하게 하는 성장 레버다.
실행 설계는 “정적 스파인 + 동적 팔”로 프롬프트를 구조화하는 것이다. 정적 콘텐츠(정책, 도구 정의, 고정 지침)는 맨 앞에 고정하고, 동적 콘텐츠(런타임 컨텍스트, working memory, 최근 대화, 툴 결과)는 배열의 뒤쪽으로 보낸다. 필요하면 캐시 브레이크포인트를 여러 구간으로 나눠 TTL을 다르게 둔다(예: 1시간짜리 공용 시스템 프롬프트, 5분짜리 최근 대화 슬라이딩 윈도우). “프롬프트를 하나의 문자열로 매번 새로 조립”하는 습관을 버리는 게 포인트다.
여기에 RAG 프로덕션 최적화를 결합하면 비용-지연을 동시에 잡을 수 있다. dev.to의 RAG 프로덕션 가이드는 성능을 ‘정확도’에서 끝내지 말고, 반복 질의에 강한 semantic caching(임베딩 유사도로 캐시), chunking 전략(문장 윈도우, parent-document, late chunking)을 실험하라고 제안한다. 성장팀 관점에선 “자주 묻는 질문이 반복되는 구간”을 캐시로 눌러 토큰을 아끼고, chunking으로 재현율/정확도를 끌어 전환율(답변 만족→재방문)을 올리는 2트랙이다.
시사점은 세 가지다. 첫째, 캐시 히트율은 이제 핵심 그로스 메트릭이다. Anthropic/OpenAI 모두 응답 메타데이터에 캐시 사용량을 주므로(원문 언급), 로깅에 cache hit rate를 넣는 순간 ‘비용 누수’가 계량화된다. 둘째, long context vs RAG 논쟁은 “기술 취향”이 아니라 단가와 리텐션의 문제다. 긴 컨텍스트는 캐싱으로도 어느 정도 완화되지만, 반복 질의·대규모 운영에선 RAG가 구조적으로 싸다(dev.to 비교 글의 비용 예시가 이를 뒷받침). 셋째, 비용을 줄이는 팀이 실험 속도를 산다. COGS가 내려가면 A/B 테스트 트래픽을 더 태울 수 있고, 무료 플랜/체험을 두껍게 만들어 상단 퍼널을 확장할 수 있다.
전망: 2026년 이후 LLM 제품 경쟁은 “더 똑똑한 모델”보다 “더 지속 가능한 단가로 더 많은 상호작용을 만들 수 있는 운영 설계”로 이동한다. 프롬프트 캐싱은 버튼 하나가 아니라 아키텍처 규율이며, RAG는 정확도만이 아니라 캐시·청킹·모니터링·ACL까지 포함한 프로덕션 시스템이다. 다음 분기 목표가 전환율/리텐션이라면, 지금 해야 할 일은 새로운 모델을 붙이는 게 아니라 (1) 캐시 히트율 로깅, (2) 프롬프트 prefix 정적화, (3) semantic caching A/B, (4) chunking eval 파이프라인을 만드는 것이다. 성능은 따라온다. 비용과 레이턴시를 먼저 잡는 팀이 LTV를 선점한다.