AI 제품이 PMF 근처까지는 ‘기능’이 견인합니다. 그런데 유저가 늘기 시작하는 순간, 성장을 막는 병목은 기능이 아니라 COGS(토큰/API 비용)와 신뢰(장애·품질·가드레일)로 옮겨갑니다. 비용은 가격/마진을 흔들고, 장애는 리텐션을 직접 깎습니다. 이 두 축이 동시에 터지면 CAC는 올라가고 전환은 내려갑니다.
dev.to의 Claude 기반 고객지원 봇 사례(“When NOT to use RAG…”)는 ‘과한 정석’이 어떻게 성장 비용을 키우는지 보여줍니다. 16개 문서(총 4,000토큰 내외)짜리 작은 KB에도 튜토리얼대로 RAG를 붙이면, 임베딩 호출 + 벡터DB 조회 + LLM 호출로 API 홉이 3개가 됩니다. 그 결과 첫 토큰 지연이 ~1,150ms로 늘고, “검색 실패/임계값 튜닝” 같은 운영 이슈가 새로 생깁니다. 즉, 기능은 같아도 전환(응답 속도)과 운영 복잡도가 악화됩니다.
흥미로운 해킹은 Anthropic의 Prompt Caching으로 “KB를 통째로 시스템 프롬프트에 넣고 캐시”한 선택입니다. 첫 메시지에서 캐시를 만들고, 이후 5분 내 재대화에서는 입력 토큰 비용이 크게 내려가며(글에서는 읽기 비용 90% 절감 조건 언급), 지연도 ~700ms대로 떨어졌습니다. 비용은 월 $17 vs $18로 비슷했지만, 성장 관점에서 더 중요한 건 (1) 레이턴시 개선 → 문의 이탈 감소 (2) 구성요소 축소 → 장애면적 감소 (3) retrieval miss 제거 → CS 품질 안정화였습니다. “RAG냐 아니냐”가 아니라 트래픽 형태(세션 지속, 반복 메시지)에 맞춰 COGS/UX를 같이 최적화한 겁니다.
반대로 자율 에이전트를 프로덕션에 풀었을 때의 비용/리스크는 dev.to의 다른 글(“Autonomous AI Agents Look Great in Demos…”)이 정리합니다. 데모에서는 한 번에 끝나지만, 실제 운영에서는 루프/함정에 빠져 토큰을 태우고, 24/7 상시 에이전트는 월 수백 달러 단위로 예측 불가능한 청구가 생깁니다. 더 무서운 건 비용이 아니라 블라스트 레디우스입니다. 글에서 언급된 Amazon Kiro 사건처럼 권한 경계·파괴적 작업 차단·피어리뷰가 없으면 “에이전트가 잘못”이 아니라 “설계가 시킨 대로” 대규모 장애가 납니다.
그리고 신뢰의 마지막 퍼즐은 ‘우리’가 아니라 ‘벤더’에서 터지기도 합니다. 2026년 4월 28일 Claude 플랫폼의 광범위 장애(google_news 인용)는 채팅/코드/Anthropic API/로그인 경로까지 영향을 줬고, 수천 건의 신고가 쏟아졌습니다. 이건 단순한 불편이 아니라, LLM API를 핵심 워크플로에 박은 제품에게는 D1/D7 리텐션을 흔드는 즉시 리스크입니다. 특히 온보딩 초기에 장애를 맞으면 “우리 제품이 불안정하다”는 인식으로 전환이 끊깁니다(원인이 벤더여도 사용자는 구분하지 않습니다).
시사점은 명확합니다. 첫째, RAG는 ‘기술적 정답’이 아니라 ‘규모/업데이트 빈도/개인화’에 따른 선택입니다. 작은 KB라면 캐싱 기반 all-in-context로 레이턴시·장애면적을 줄여 전환을 올릴 수 있습니다(출처: dev.to RAG 회고). 둘째, 에이전트는 “완전 자율”이 아니라 감독·스케줄·티어링(작업 위험도별 승인 단계)으로 COGS와 사고 비용을 캡핑해야 합니다(출처: dev.to 에이전트 운영 비용 글). 셋째, 벤더 장애는 피할 수 없으니 제품 레벨에서 폴백(모델/벤더 스왑), 큐잉, 제한 모드(읽기 전용/요약만), 상태 배너와 보상 플로우를 준비해야 신뢰 손실을 최소화합니다.
전망: AI 제품의 경쟁은 곧 “모델 성능”에서 “운영 성숙도”로 이동합니다. 비용은 더 정교하게 세션/캐시 히트율/루프 횟수 같은 퍼널 변수로 관리될 것이고, 신뢰는 가드레일·권한·관측(로그/리플레이)·장애 대응에서 점수가 갈립니다. 다음 성장 레버는 기능 추가가 아니라, COGS와 가동률을 설계해 같은 유저 증가를 더 낮은 CAC와 더 높은 리텐션으로 받아내는 운영 시스템입니다.