RAG 앞에 시맨틱 캐시 (Semantic Cache) 레이어를 구축하는 법 — 그리고 이것이 왜 프로덕션 AI 시스템에서 가장 과소평가된 비용 최적화 방법인지에 대하여.

Hey Dev 커뮤니티 👋

내가 보는 모든 RAG 아키텍처 다이어그램은 정확히 똑같아 보인다.

사용자 (User) → 벡터 검색 (Vector Search) → LLM → 응답 (Response).

하지만 나는 계속 궁금하다...

왜 우리는 똑같은 답변에 대해 수천 번씩 비용을 지불하고 있는 걸까?

50,000명의 고객이 _"체크카드를 어떻게 차단하나요?"_라는 질문을 조금씩 다른 단어로 물어본다고 상상해 보자. 왜 시스템은 50,000개의 거의 동일한 답변을 생성하기 위해 50,000번의 벡터 검색 (Vector Search)과 50,000번의 LLM 호출을 수행해야 하는가?

어쩌면 내가 무언가를 놓치고 있는 것일지도 모른다. 여기 내 머릿속에 박혀 있는 아키텍처가 있다 — 그리고 나는 RAG를 프로덕션 환경에서 운영해 본 사람들이 이 설계의 어디가 잘못되었는지 말해주길 바란다.

계속 읽기 전에 이 사고 실험을 해보자: 당신이 100만 명의 고객을 보유한 뱅킹 챗봇을 구축하고 있다고 상상해 보라. 만약 고객 질문의 70%가 매일 반복된다면, 당신은 정말 매번 벡터 검색과 LLM 호출에 비용을 지불할 것인가? 아니면 당신의 시맨틱 캐시 (Semantic Cache)가 결국 가장 먼저 확인해야 할 장소가 되어야 하는가?

1. 설정: 은행의 고객 지원 챗봇

사람 상담원이 개입하기 전에 문제를 해결하려고 시도하는 은행의 고객용 챗봇을 그려보자.

고객 (Customer)
    │
    ▼
...

그 챗봇은 내부적으로 모든 질문에 대해 매번 똑같이 비싼 작업을 수행한다: 벡터 검색 (Vector Search) → LLM 생성 (LLM Generation), 매번 말이다.

그것이 바로 내가 의문을 제기하고 싶은 부분이다.

숫자로 확인해 보자

엔지니어들은 "수천 명의 사용자"가 아니라 숫자에 관심이 있으므로, 내가 상상하는 시나리오는 다음과 같다. 이것은 예시를 위한 가정이며 측정된 데이터가 아니다 — 누구도 이것을 벤치마크로 오해하지 않도록 명확하게 표시해 둔다:

• 1,000,000명의 뱅킹 고객
• 하루 120,000건의 지원 채팅
• 그 중 약 70%는 FAQ 유형의 반복적인 질문
• Redis에서의 시맨틱 캐시 (Semantic Cache) 조회에 약 40ms 소요
• 전체 RAG 파이프라인 호출 (벡터 검색 (Vector Search) + LLM 생성 (LLM Generation))에 약 2~4초 소요

만약 매일 발생하는 120,000건의 채팅 중 70%를 2~4초가 아닌 40ms 만에 — 그리고 벡터 검색 (Vector Search)이나 LLM 호출 없이 — 답변할 수 있다면, 이는 단순한 지연 시간(Latency) 개선이 아닙니다. 그것은 근본적으로 다른 비용 곡선(Cost Curve)을 의미합니다.

이 글 전체를 관통하는 문장

💡 가설

고객이 챗봇을 더 많이 사용할수록,
챗봇은 RAG에 대한 의존도가 낮아진다.

더 정확히 말하자면, 저의 가설은 RAG가 기본 실행 경로(Default execution path)에서 점차 밀려나, 오직 캐시 미스 (Cache miss)와 새롭게 등장하는 질문들을 처리하는 역할로 전환될 것이라는 점입니다. 캐싱 가능한 (Cacheable) 모든 질문은 시맨틱 캐시 (Semantic Cache)를 풍성하게 만듭니다. 반복되는 질문은 캐시 히트율 (Cache hit rate)을 높입니다. 시간이 흐를수록 시스템은 비용이 많이 드는 검색 (Retrieval)에 대한 의존도가 낮아집니다.

아래의 모든 내용은 이 가설이 실제 운영 환경(Production)에서도 유효한지 확인하려는 시도입니다.

2. 표준 RAG 흐름 (그리고 숨겨진 세금)

여기 우리 대부분이 가장 먼저 배포하는 교과서적인 RAG 파이프라인이 있습니다:

사용자 질문 (User Question)
      │
      ▼
...

이 방식은 작동합니다. 하지만 이는 최악의 방식으로 상태가 없는 (Stateless) 방식이기도 합니다. 시스템은 오늘 이미 정확히 이 질문에 40번이나 답변했다는 사실을 전혀 기억하지 못합니다. 반복되는 모든 질문은 벡터 검색과 LLM 호출이라는 비용(Tax)을 매번 온전히 지불해야 합니다.

하루에 수천 개의 유사한 질문 — "체크카드를 어떻게 차단하나요?", "ATM 카드를 분실했습니다", "온라인으로 카드를 비활성화할 수 있나요?" — 을 받는 고객 지원 봇의 경우, 의미론적으로 동일한 작업에 엄청난 비용이 낭비되고 있는 셈입니다.

3. 아이디어: RAG 앞단의 시맨틱 캐시 (Semantic Cache)

동일한 문자열만 일치시키는 캐시 대신, **의미 (Meaning)**를 기준으로 캐싱한다면 어떨까요?

첫 번째 사용자는 RAG 비용을 온전히 지불합니다. 하지만 그 이후의 모든 유사한 질문은 그 비용을 다시 지불하지 않을 기회가 됩니다.

**시맨틱 캐시 (Semantic Cache)**는 들어오는 질문을 임베딩 (Embedding)하고, 벡터 유사도 (Vector similarity)를 사용하여 이전에 답변했던 질문들과 비교합니다. 만약 유사도 점수가 임계값(예: 코사인 유사도 (Cosine similarity) 0.92)을 넘으면, 전체 지식 베이스에 대한 벡터 검색이나 LLM 호출 없이 캐시된 답변을 반환합니다.

왜 일반적인 캐시(Normal Cache)를 사용하지 않을까요?

일반적인 Redis 캐시는 두 요청이 정확히 일치할 때만 작동합니다:

"How do I block my debit card?" (체크카드를 어떻게 정지하나요?)
              != 
"My ATM card is lost." (ATM 카드를 분실했습니다.)
...

세 개의 서로 다른 문자열은 세 개의 서로 다른 캐시 키(Cache Key)가 되어 세 번의 캐시 미스(Cache Miss)를 발생시킵니다. 비록 이 질문들이 모두 동일한 답변을 원하고 있음에도 말이죠. 일반적인 캐시는 '의미(Meaning)'라는 개념이 없으며, 오직 정확한 일치(Exact Match)만을 다룹니다.

시맨틱 캐시(Semantic Cache)는 이 세 가지가 모두 동일한 의도(Intent)를 표현한다는 것을 인식합니다. 이것이 임베딩(Embeddings)이 중요한 이유입니다. 임베딩은 시스템이 질문이 어떻게 타이핑되었는지가 아니라, 그 질문이 무엇을 의미하는지에 따라 비교할 수 있게 해줍니다.

워크플로우(Flow)의 모습

일반적인 캐시는 다음을 세 개의 서로 다른 키로 취급할 것입니다:

• "How do I block my debit card?"
• "My ATM card is lost. How can I disable it?"
• "I misplaced my card, what should I do?"

시맨틱 캐시는 이 세 가지를 하나의 조회(Lookup)로 통합합니다:

                        ┌───────────────────────────┐
                        │      Semantic Cache        │
                        │   (Redis + Embeddings)     │
...

핵심적인 변화: 제안된 이 아키텍처(Architecture)에서 RAG는 기본 경로가 아닌 폴백(Fallback) 경로가 됩니다.

4. 실제로 무엇을 캐싱해야 하는가

이 부분은 주의하지 않으면 아이디어가 무너질 수 있는 지점이므로, 미리 선을 그어두겠습니다.

캐싱해도 안전한 것 — 답변이 안정적인 일반 지식 베이스(Knowledge-base) 질문:

• "How do I block my debit card?"
• "What documents are needed for a personal loan?"
• "How do I reset my net banking password?"
• "What are the charges for an international transfer?"

절대 캐싱하면 안 되는 것 — 실시간, 개인 정보 또는 계정 특정 상태와 연결된 모든 것:

• 계좌 잔액 (Account balance)
• 최근 거래 내역 (Recent transactions)
• 대출 신청 상태 (Loan application status)
• 신용카드 한도 (Credit card limits)

Incoming Question
        │
        ▼
...

실제 구현에서는 보통 캐시 조회(Cache Lookup)를 하기 전에 의도(Intent)를 분류하는 것을 의미합니다. 즉, "캐싱 가능한 지식 쿼리(Cacheable knowledge query)"와 "개인화된 실시간 쿼리(Personalized live query)"를 결정하는 가벼운 라우터(Router)를 두어, 전자의 경우에만 시맨틱 캐시를 통과하도록 하는 것입니다.

5. 구현 (On Implementation)

여기서 70줄에 달하는 Redis 클라이언트 코드를 일부러 생략하겠습니다. 이 글은 API 호출에 관한 것이 아니라, 아키텍처 (Architecture)와 트래픽 패턴 (Traffic pattern)에 관한 것이기 때문입니다.

실제로 이는 Redis Vector Search, pgvector, 또는 다른 임베딩 저장소 (Embedding store)를 사용하여 구축할 수 있습니다. 들어오는 질문을 임베딩 (Embed)하고, KNN 유사도 검색 (KNN similarity lookup)을 실행한 뒤, 임계값 (Threshold) 이상의 결과가 있으면 캐시된 답변을 반환합니다. 그렇지 않으면 RAG 파이프라인 (RAG pipeline)으로 넘어가고, 새로운 답변을 다시 캐시에 기록합니다. 구현 자체는 흥미로운 부분이 아닙니다. 제가 설명하는 트래픽 패턴이 실제로 유효한지가 핵심입니다.

이 방식의 실제 버전에 필요할 것으로 예상되는 한 가지는 다음과 같습니다. 프로덕션 (Production) 환경에서는 모든 RAG 출력물을 저장하는 것이 아니라, 검증되었거나 신뢰도가 높은 답변만을 시맨틱 캐시 (Semantic cache)에 기록해야 합니다. 환각 (Hallucination)이 발생했거나 신뢰도가 낮은 응답이 캐싱되어 수천 번 재사용되는 것은, 매번 새로 생성하는 것보다 더 나쁜 상황을 초래할 것입니다.

6. RAG가 단지 부트스트래핑 엔진 (Bootstrapping engine)이라면?

어쩌면 RAG는 영원히 모든 질문에 답하도록 설계된 것이 아닐지도 모릅니다.

어쩌면 RAG의 진짜 역할은 '새로운' 질문에 답하는 것일지도 모릅니다.

한 번 답변이 유용하다고 증명되고 계속해서 요청된다면, 왜 그 답변이 시맨틱 캐시 (Semantic cache)로 승격되지 말아야 할까요?

오늘 (Today)

100개의 요청 (100 requests)
...

만약 그렇게 생각하는 것이 옳다면, RAG의 역할은 시간이 흐름에 따라

만약 이 가설의 절반이라도 성립한다면, 성숙한 시맨틱 캐시 (Semantic Cache)는 **반복적인 지식 질의를 위한 주요 검색 레이어 (primary retrieval layer)**가 될 수 있습니다. 이 경우 RAG는 캐시 무효화 (Cache invalidation), TTL 만료, 그리고 정책 변경이 허용된다는 전제하에, 새롭거나 드물거나 혹은 예외적인 질문들만을 처리하게 될 것입니다.

8. 이 모델이 무너질 것이라고 생각하는 지점 (그리고 여러분이 생각하는 다른 지점도 알려주길 바랍니다)

• 캐시 무효화 (Cache invalidation) — 지식 베이스 (Knowledge base)가 변경될 때 (정책 업데이트, 새로운 수수료 구조 등), 이제는 오래된 정보가 된 모든 캐시된 답변을 어떻게 찾아내고 갱신할 것인가? 캐시된 응답에 버전을 매길 것인가, 아니면 지식 베이스가 업데이트될 때마다 캐시 전체를 삭제할 것인가?
• 유사도 임계값 튜닝 (Similarity threshold tuning) — 임계값을 너무 낮게 설정하면 단지 소리만 비슷한 질문에 대해 잘못된 답변을 반환하게 됩니다. 반대로 너무 높게 설정하면 캐시 히트가 거의 발생하지 않아 시스템의 목적 자체가 무색해집니다.
• 거짓 양성 (False positive) 위험 — "저축 계좌를 해지하려면 어떻게 하나요?"와 "신용카드를 해지하려면 어떻게 하나요?"는 구조적으로 유사한 문장이지만 답변은 매우 다릅니다. 임베딩 유사도 (Embedding similarity)만으로는 충분하지 않을 수 있으며, 그 위에 엔티티/슬롯 (Entity/slot) 체크와 같은 추가적인 검증이 필요할 수 있습니다.
• 메모리 관리 (Memory management) — Redis도 공짜는 아닙니다. 캐시 크기가 어느 정도에 도달했을 때, 저장 비용이 LLM 호출 감소로 얻은 절감액을 갉아먹기 시작할 것인가?
• Redis가 과연 적절한 도구인가, 아니면 규모가 커졌을 때 전용 벡터 캐시 (Vector cache)나 (더 저렴한 근사 인덱스를 사용하는 하이브리드 설정)이 더 합리적일 것인가?

9. 내가 답할 수 없는 질문

여기 제가 답할 수 없는 질문이 있습니다:

만약 캐시 히트율 (Cache hit rate)이 결국 80%에 도달한다면, 이제 시맨틱 캐시가 여러분의 주요 검색 엔진이며, RAG는 단순히 캐시 미스 (Cache miss)를 처리하는 역할만 수행하게 되는 것일까요?

만약 이것이 실제 운영 환경의 RAG를 생각하는 잘못된 방식이라면, 그 이유를 진심으로 알고 싶습니다.

토론을 기대하겠습니다.