RAG/에이전트를 프로덕션에 올리면 곧바로 두 개의 퍼널 변수가 튀어나옵니다. 첫째는 ‘근거가 있는 것처럼 보이는 환각’이 신뢰를 깨서 재방문을 날리는 문제, 둘째는 ‘사용자 눈에 안 보이는 토큰’이 COGS를 갉아먹어 유료 전환과 가격 실험을 막는 문제입니다. 둘 다 단순 품질 이슈가 아니라 Activation→Retention→Revenue로 이어지는 경로를 직접 흔듭니다.
dev.to의 「Stop Your RAG Pipeline From Hallucinating」는 이 신뢰 문제를 ‘retrieve→generate→verify’로 정리합니다. 핵심은 RAG가 문서를 잘 가져와도 8~15%는 틀릴 수 있다는 현실 인식입니다. 더 까다로운 점은, 인용이 달려 있고 문서도 진짜라서 겉보기엔 “정답처럼 보이는 오답”이 나온다는 것. 이건 검색 품질 지표나 동일 모델 기반의 faithfulness 평가로 잘 안 잡힙니다. 그래서 제안은 단순합니다: 생성 모델과 독립적인 검증 패스(다른 프롬프트/다른 근거 소스)로 최종 답을 원자 클레임으로 쪼개 ‘통과/거절’을 게이트로 걸어라.
이 패턴이 그로스 관점에서 중요한 이유는, 검증이 곧 ‘리스크 기반 퍼널 제어’이기 때문입니다. 예를 들어 (1) refuted가 한 개라도 있으면 답변을 숨기고 재생성, (2) unverifiable이면 “근거 부족”으로 안전 응답, (3) confidence가 낮으면 사용자에게 확인 질문을 던지는 식으로 흐름을 분기할 수 있습니다. 즉, 환각을 0으로 만들겠다는 이상론이 아니라 “위험한 순간에만 브레이크를 밟아 이탈을 줄이는 설계”입니다. 결과적으로 CS 티켓/환불/불신 리뷰를 줄여 D7·D30 리텐션에 직결됩니다.
동시에 토큰 비용은 ‘보이지 않는 누수’로 퍼널을 잠식합니다. velog의 토큰 경제/숨은 소비자 글이 강조하듯, 비용은 input/output 비대칭(대개 output이 3~5배 비쌈), 캐시가 깨지는 프롬프트 구조, RAG bloat(top-K×청크 크기), reasoning 토큰, 에이전트 루프(한 번의 UX가 뒤에선 N번 패스)에서 증폭됩니다. 사용자는 한 문장만 쳤는데 런타임은 수천~수만 토큰을 싣고 갈 수 있고, 이건 가격 인상 압력→전환율 하락→실험 예산 감소로 이어집니다.
여기서 ‘검증+토큰절감’은 같이 설계할수록 레버가 커집니다. 검증을 붙이면 호출이 늘어 비용이 올라갈 수 있으니, 반드시 계측과 차단을 같이 해야 합니다. 실전 체크리스트는 간단합니다. (1) verify는 “거절이 발생하는 구간/유저 세그먼트”에서만 켜는 리스크 기반 샘플링(예: 결제/법무/의료/수치 포함 답변, 신규 유저 첫 3회, 낮은 confidence). (2) RAG는 retrieve K를 크게 두지 말고 rerank로 3~5개만 최종 프롬프트에 투입. (3) 프롬프트 프리픽스를 안정화해 prefix caching이 먹게 만들고(타임스탬프를 앞에 두지 않기), (4) 에이전트 루프는 스텝 상한/요약 정책으로 컨텍스트 팽창을 제어. 이렇게 하면 검증으로 신뢰를 올리면서도 총 토큰은 오히려 내려갈 여지가 큽니다.
전망은 명확합니다. 앞으로 RAG/에이전트 경쟁력은 “더 똑똑한 모델”보다 “언제 믿고 언제 멈추는가(verify gating)”와 “얼마를 쓰고 있는지 보이는가(token observability)”로 갈립니다. 신뢰는 전환율을, 비용은 가격과 마진을, 둘의 곱은 LTV를 결정합니다. 지금 할 일은 거창한 리빌드가 아니라, dev.to가 보여준 것처럼 작은 verify 게이트를 먼저 꽂고(최소 코드), velog가 말한 ‘숨은 토큰 소비자’부터 계측해 큰 누수를 막는 것입니다. 이 두 개를 붙이는 순간, 품질 개선이 아니라 퍼널 최적화가 시작됩니다.
출처: dev.to의 RAG 검증 패턴(AgentOracle evaluate 예시)과 velog의 토큰 경제/숨은 토큰 소비자 분석을 바탕으로 재구성했습니다.