RAG의 비용은 '검색 횟수'로 결정된다: 매번 검색하지 않는 아키텍처 설계론

LLM의 비용 최적화에는 크게 두 가지 축이 있습니다. 하나는 "1개 쿼리에서 무엇을 읽게 할 것인가" = 입력 토큰을 줄이는 설계이고, 다른 하나는 본고에서 다룰 "애초에 검색·생성을 할 것인가" = 무거운 처리의 횟수를 줄이는 설계입니다.

본고는 후자, "매번 검색하지 않는" 아키텍처에 관한 이야기입니다. RAG (Retrieval-Augmented Generation)를 실무 운영에 적용하면, 비용의 주된 원인은 1개 쿼리당 입력 토큰보다 **"모든 쿼리에 대해 매번 풀 검색(Full Search) + 풀 생성(Full Generation)을 돌리고 있다는 점"**으로 옮겨갑니다. 이 부분을 설계로 깎아내면, 월간 100만 쿼리 규모에서 **$50,000 → $3,000 (약 1/15~1/20)**까지 떨어질 수 있다는 구조를 정리합니다.

ShintaroAmaike 씨의 기사 「RAG의 비용 문제를 1/15로 줄이는 ― '매번 검색하지 않는' 아키텍처 설계」가 직접적인 영감을 주었습니다. 구체적이고 뛰어난 구현 사례였기에, 본고는 그것을 교재로 삼아 필자가 설계 판단의 축으로서 나름대로 다시 정리한 것입니다. 정확한 구현은 원전이 1차 정보이므로, RAG를 실무 운영하는 분들은 원전과 본고를 함께 읽어주시는 것을 전제로 합니다.

TL;DR

RAG 실무 운영의 비용 주원인은 "입력 토큰량"보다 "매번 풀 검색 + 풀 생성을 돌리는 횟수"
본질은 계산 배치 (computation placement) 문제 — 리퀘스트 패스(request path) 상의 계산을 precompute / cache / route를 통해 외부로 밀어내는 것 (DB의 마테리얼라이즈드 뷰(Materialized View), CDN과 같은 계보)
원전의 "상정 질문 인덱스"는 LLM 버전의 마테리얼라이즈드 뷰에 가까움. 비용이 사라지는 것이 아니라 생성·갱신 비용으로서 자산 측면으로 옮겨간다고 파악하면 손익을 읽기 쉬움
계층화 (분류기 → 사전 답변 → 경량 → 고성능)에서 필자가 주목한 것은 층의 경계. 병목(bottleneck)은 분류기이며, 오류의 방향(품질 저하 vs 비용 증가)은 비대칭적임
"1/15"의 효과는 구성뿐만 아니라 쿼리 분포의 형태에 좌우됨 (특정 질문에 쏠려 있다면 효과가 큼) → 구축하기 전에 분포를 측정해 두고 싶음
입력 설계 (세로) × 처리 횟수 설계 (가로·본고)의 이단 로켓
전제는 정적 코퍼스 (Static Corpus) (사내 매뉴얼, FAQ 등 빈번하게 업데이트되지 않는 데이터)

1. RAG의 비용은 어디서 불어나는가

RAG의 단순한 구현은 다음과 같습니다.

사용자의 쿼리
→ 임베딩 (Embedding) 생성
→ 벡터 검색 (Vector Search) (관련 청크 획득)
...

PoC(Proof of Concept) 단계에서는 이것으로 충분히 작동합니다. 문제는 실무에서 쿼리 수가 늘어났을 때입니다. 위의 경로는 모든 쿼리에 대해 "임베딩 + 검색 + 생성"을 풀 세트로 실행합니다. 월간 100만 쿼리라면, 100만 번의 풀 생성이 돌아갑니다. 1개 쿼리의 입력을 입력 설계의 궁리로 절반으로 줄인다 해도, 횟수 자체가 줄어들지 않으면 선형적으로 쌓이게 됩니다.

여기서 유효한 관찰은, **"모든 쿼리가 동일한 무게의 처리를 필요로 하는 것은 아니다"**라는 점입니다.

전체의 수 퍼센트는 "영업시간은?", "반품 방법은?"과 같은 정형 질문 — 매번 검색할 필요가 없음
또한 일정 비율은 "애초에 RAG가 불필요" (잡담, 범위를 벗어난 질문) — 생성조차 필요 없음
정말로 문서 횡단 추론이 필요한 난제는 극히 일부

그럼에도 불구하고 단순한 RAG는 모든 것을 최중량 레인으로 통과시킵니다. 처리 무게를 쿼리의 난이도에 맞춰 단계화하는 것이 본고의 주제입니다.

2. RAG를 "계산 배치 문제"로 바라보기

여기서부터는 원전의 구현을 교재로 삼아, 필자가 배우면서 설계의 일반론으로서 풀어낸 정리입니다. 이해가 미치지 못한 부분은 원전이 더 정확하므로, 원전과의 병독을 전제로 읽어주시기 바랍니다.

필자의 정리에서 RAG의 비용 최적화 본질은 **"리퀘스트 패스 상에서 수행하는 계산을 다른 곳으로 밀어낼 수 있는가"**라는 계산 배치 (computation placement) 문제입니다. 이는 RAG에 국한된 이야기가 아니라, DB의 마테리얼라이즈드 뷰, CDN의 에지 캐시(edge cache), 웹의 admission control (과부하 시의 입장 제어)과 같은 계보의 발상입니다. 리퀘스트마다 돌아가는 계산을 줄이는 수단은 궁극적으로 세 가지뿐입니다.

precompute (사전 계산): 결과를 미리 만들어 두는 것
cache (재사용): 한 번 만든 결과를 다시 사용하는 것
route / shed (분배·솎아내기): 애초에 가벼운 경로로 흘려보내거나, 수행하지 않는 것

원문 「RAG의 비용 문제를 1/15로 줄이기」가 제안하는 메커니즘은 이 세 가지 수단을 RAG에 적용한 구체적인 사례로 읽을 수 있습니다. 그중에서도 필자가 가장 훌륭한 응용이라고 느낀 것이 원문에서 말하는 「상정 질문 인덱스 (Assumed Question Index)」 — precompute와 cache를 겸한 장치입니다.

2.1 「상정 질문 인덱스」는 LLM 버전의 마테리얼라이즈드 뷰(Materialized View)이다

원문의 아이디어는 이렇습니다. 코퍼스(Corpus) 측에서 「이 문서에 대해 물어볼 법한 질문」을 오프라인에서 생성하고, 그 답변까지 미리 만들어 인덱스화해 두는 것입니다. 쿼리(Query)가 들어오면 먼저 이 인덱스에 의미 검색(Semantic Search)을 수행하고, 히트(Hit)되면 검색도 생성도 하지 않고 사전 생성된 답변을 반환합니다.

필자의 견해로는, 이는 DB의 마테리얼라이즈드 뷰 (Materialized View)에 가까운 발상입니다. 「자주 실행되는 쿼리의 결과를 실체화하여 가지고 있다가, 요청 시에는 참조만 한다」는 데이터 기반(Data Infrastructure)에서의 성숙한 최적화 기법을 LLM의 Q&A에 도입한 것으로 이해하면 납득이 갑니다.

이렇게 보면 비용의 소재도 정리하기 쉬워집니다. 마테리얼라이즈드 뷰가 「뷰의 구축·갱신 비용」을 별도로 부담하는 것과 마찬가지로, 상정 질문 인덱스도 **「질문과 답변을 사전 생성하는 LLM 비용」과 「코퍼스 업데이트 시의 재생성 비용」**을 오프라인 측에 부담합니다. 즉, 이것은 비용을 제로로 만드는 장치가 아니라, 비용을 리퀘스트 패스(Request Path)에서 자산 측으로 옮기는 장치입니다. 호출 횟수가 많아질수록 옮기는 것이 이득이 되는 구조는 앞서 언급한 입력 설계의 손익분기점과 동일합니다.

2.2 「문자열 캐시」가 아닌 「의미 캐시」로 만드는 의미와 그 대가

단순한 캐시는 「쿼리 문자열 → 답변」을 저장하지만, 사용자는 같은 내용을 「영업시간은?」, 「몇 시까지 열어?」, 「언제 닫아?」와 같이 무수한 표현으로 묻기 때문에 문자열 일치로는 거의 히트되지 않습니다. 상정 질문 인덱스가 효과를 발휘하는 이유는 임베딩(Embedding)의 의미 유사도로 히트 여부를 판단하기 때문에, 표현이 달라도 잡아낼 수 있기 때문입니다.

다만 필자로서 한 가지 덧붙이고 싶은 점은, 의미 캐시에는 문자열 캐시에는 없는 고유한 사고(Accident)가 있다는 것입니다. 유사도 임계값(Threshold)을 완화하면 히트율은 올라가지만, 「비슷하지만 실제로는 다른 질문」에 사전 답변을 반환하는 *오탐(False Hit)*이 섞이게 됩니다. 문자열 캐시는 완전 일치이므로 오답을 내지 않지만, 의미 캐시는 히트율(비용 절감)과 오답률(품질 저하)이 트레이드오프 (Trade-off) 관계에 놓입니다. 이 임계값 설계는 후술할 분류기와 더불어 운영상의 핵심 노하우입니다.

3. 계층화의 본질은 「입장 제어」 — 경계를 어떻게 그을 것인가

원문은 구체적으로 4개의 계층(쿼리 분류기 → 상정 질문 인덱스 → 경량 모델의 일반 RAG → 고성능 모델의 풀 RAG)을 제시하고 있습니다. 필자는 이를 보다 일반적인 tiered serving + admission control (다단 처리 + 입장 제어) 패턴의 한 구현으로 파악하고 있습니다. 「모든 리퀘스트를 가장 무거운 경로로 통과시키는 것」을 그만두고, 난이도에 따라 가벼운 경로로 분배하며, 불필요한 것은 입구에서 거절하는 —— CDN이나 로드 밸런서(Load Balancer) 세계에서는 당연한 태세를 LLM 추론 비용에 적용한 것입니다.

계층의 구성 자체는 정직하므로, 필자가 신경 쓰인 부분은 **「계층의 경계를 어떻게 그을 것인가」**입니다. 원문은 구현 제시를 중시하고 있으므로, 본고에서는 이 설계 판단 부분을 나름대로 보완해 보겠습니다. 구체적인 예로 4개 계층을 재게하면서 각 경계의 논점을 덧붙입니다.

계층	역할	비용	설계상의 핵심 (필자의 보완)
① 분류기	필요 여부·난이도 분배	극소	전체 효율은 이 정확도가 결정적임. 후술
...

3.1 병목은 「분류기」 — 오류의 방향에 따라 비용이 비대칭이 된다

필자가 이 아키텍처에서 가장 섬세해야 한다고 생각하는 것은 ①번 분류기입니다. 이유는 오분류의 비용이 방향에 따라 비대칭적이기 때문입니다.

어려운 문제를 ③(경량)으로 떨어뜨림 → 품질 저하 (오답·누락)
쉬운 문제를 ④(고성능)로 올림 → 비용 증가 (불필요하게 높은 경로)

이 두 가지는 등가(equivalent)가 아닙니다. FAQ 응답이라면 품질 저하가 더 치명적이지만(오답은 브랜드 가치 훼손), 사내용 초안 생성이라면 비용 증가가 허용 가능한 경우도 있습니다. 즉, "망설여질 때 위로 올릴 것인가, 아래로 내릴 것인가"는 용도에 따라 먼저 결정해야 할 방침 판단이지, 기술적으로 일의적으로 결정되는 것이 아닙니다. 분류기(classifier)를 만들기 전에 "이 용도는 fail-up인가 fail-down인가"를 정의해 두는 것이 필자가 생각하는 올바른 순서입니다.

3.2 계층화는 "퍼널(funnel)" — 효과는 통과율의 곱으로 결정된다

또 다른 관점으로, 이 4개 계층은 **퍼널(funnel)**입니다. ①에서 몇 할을 걸러내고, ②에서 몇 할을 흡수하며, ③에서 몇 할을 처리하고, ④에 몇 할을 남길 것인가. 전체 비용은 각 계층의 "단가 × 통과율"의 총합으로 결정되므로, 가장 비중이 큰 ④의 통과율을 낮추는 것이 단가가 높기 때문에 가장 효과적입니다. 역으로 말하면, ②③에서 놓쳐서 ④로 흘러 들어가는 비율이 예상보다 높으면 견적은 쉽게 무너집니다. 설계 목표를 "각 계층의 정확도"가 아니라 "④ 통과율을 소정 값 이하로 유지하는 것"으로 두면 운영 지표를 세우기 쉬워집니다.

4. "1/15"를 실현하는 것은 『분포』 — 먼저 자신의 쿼리 분포를 측정하라

원전은 월간 100만 쿼리 규모에서 **$50,000 → $3,000 (약 1/15)**라는 시산을 보여줍니다. 매우 큰 숫자라 독자적으로 해석되기 쉬우므로, 필자의 이해를 한 가지만 보충하겠습니다. 이 절감률이 나오느냐는 4개 계층 구성 그 자체보다, 쿼리의 분포가 헤드 헤비(head-heavy)한지 여부에 크게 좌우된다는 점입니다.

핵심은 ②의 예상 질문 인덱스에서 "얼마나 흡수할 수 있는가"입니다.

헤드 헤비(head-heavy)한 분포 (소수의 정형 질문이 전체의 큰 비율을 차지함) → ②에서 많은 부분을 사전 답변으로 처리할 수 있으므로, 원전과 같은 대폭적인 절감이 효과를 보기 쉽습니다.
롱테일(long-tail) 분포 (질문이 다양하게 분산됨) → ②의 히트율(hit rate)이 낮아져 절감 폭이 크게 줄어듭니다 (정도는 분포에 따라 다름).

즉, 효과의 원천은 아키텍처 단독이 아니라, **"자신의 쿼리 분포 형태"**에 있다는 것이 필자의 해석입니다.

그렇기에 구축하기 전에 자신의 쿼리 로그 분포를 측정해 두는 것을 권장합니다. 상위 질문이 전체의 몇 할을 차지하는지(얼마나 편중되어 있는지)를 알면, ②의 사전 생성에 얼마나 투자해야 할지가 먼저 보입니다. 편중되어 있다면 예상 질문 인덱스에 중점을, 분산되어 있다면 ③의 경량화와 ①의 기각(rejection)에 중점을 두는 식의 배분 판단을 할 수 있습니다. 이는 전반부의 입력 설계에서 "반복 빈도의 실측에 기반하여 구조화 범위를 결정한다"라고 쓴 것과 마찬가지로, **"측정하고 나서 만든다"**가 양쪽 축에 공통되는 작법이라고 느낍니다.

그리고 "1개 쿼리를 저렴하게 만드는" 입력 설계가 세로 방향의 최적화라면, 본고의 계층별 분류는 가로 방향(수량)의 최적화입니다. 두 가지는 독립적이므로, 이를 결합하면 절감 효과는 곱연산으로 나타납니다.

5. 전제 조건과 적용 범위

이 설계가 강력하게 작용하는 것은 정적 코퍼스(static corpus) — 사내 매뉴얼, 제품 FAQ, 규정집 등 빈번하게 업데이트되지 않는 데이터가 대상일 때입니다. 이유는 명확합니다. 예상 질문 인덱스(사전 생성 답변)는 코퍼스가 바뀌면 다시 만들어야 하기 때문입니다.

코퍼스의 성질	예상 질문 인덱스와의 궁합
정적 (매뉴얼, FAQ, 규정)	◎ 사전 생성을 오래 사용할 수 있음
...

동적 데이터가 주를 이룬다면, ②의 비중은 낮추고 ①의 분류와 ③의 경량화에 집중하는 조정이 필요합니다. "자신의 코퍼스가 어느 위치에 있는가"를 처음에 파악하는 것이 설계의 출발점입니다.

6. 실운영 전환 시의 함정

ShintaroAmaike 씨의 글에서도 강조되고 있지만, 로컬 PoC에서 실운영으로 옮길 때의 전형적인 병목 지점을 꼽아보겠습니다.

6.1 벡터 DB, 임베딩 API, 추상화 레이어를 "처음부터 실운영을 상정"하여 선택하라

PoC에서 간편하게 in-memory 벡터 검색이나 특정 SDK를 직접 호출하는 방식으로 만들면, 실운영에서 스케일(scale) 요구사항이나 운영 요구사항에 부딪혀 다시 만들어야 합니다. 영속화, 스케일, 교체 가능성을 처음부터 고려하여 (임베딩 API나 벡터 DB를 앱에서 추상화 레이어를 통해 호출하도록 함으로써) PoC와 실운영 사이의 차이를 최소화할 수 있습니다.

6.2 예상 질문의 생성 품질이 히트율을 좌우한다

②의 히트율이 곧 비용 절감률이므로, 예상 질문이 실제 사용자의 질문과 어긋나 있으면 효과가 없습니다. 실제 쿼리 로그에서 빈번한 의도를 추출하고, 이를 예상 질문 생성 프롬프트에 반영하는 개선 루프를 돌리는 것이 정석입니다.

6.3 분류기(Classifier)의 오분류 비용

①이 난제를 ③(경량 모델)으로 보내면 품질이 떨어지고, 쉬운 문제를 ④(고단가 모델)로 보내면 비용이 낭비됩니다. 오분류 방향에 따른 비용(품질 저하 vs 단가 증가)을 살펴보고, 분류기(Classifier)의 임계값(Threshold)을 조정합니다. 판단이 어려울 때는 상위 레인으로 몰아줄 것인지(품질 우선) / 하위 레인으로 몰아줄 것인지(비용 우선)에 대한 방침을 미리 결정해 두어야 합니다.

6.4 캐시의 노후화(Staleness)를 감지할 수 없음

코퍼스(Corpus) 업데이트 시 ②의 재생성을 잊으면 계속해서 오래된 답변을 반환하게 됩니다. 코퍼스의 버전과 예상 질문 인덱스의 버전을 연결하여, 불일치를 감지하고 재생성을 트리거(Trigger) 하는 메커니즘을 운영에 포함시켜야 합니다.

7. 요약 — 「1 쿼리를 가볍게」와 「무거운 쿼리를 줄이기」의 2단 로켓

RAG의 비용 최적화는 두 개의 독립된 축의 곱셈입니다.

세로축 (입력 설계): 1 쿼리당 입력을 압축 (무엇을 읽게 할 것인가)
가로축 (본고): 무거운 처리에 도달하는 쿼리 수를 압축 (애초에 검색·생성을 할 것인가)

단순한(Naive) RAG는 「모든 쿼리 × 전체 처리 × 고단가 모델」이라는 최악의 조합이 되기 쉽습니다. 이를 다음과 같이 재설계하는 것만으로도,

입구에서 분류 (①)
정형 질문은 사전 생성(Pre-generation)으로 반환 (②)
대부분은 경량 모델 사용 (③)
고단가 모델은 난제에만 사용 (④)

월간 100만 쿼리 규모에서는 10배 이상의 비용 차이가 현실적으로 나타납니다.

그리고 중요한 점은, 이것이 **「추론 시 계산(Inference-time computation)을 오프라인으로 옮긴다」**는 일반 원칙의 RAG 버전이라는 사실입니다. 동일한 계산을 「쿼리마다 과금되는 곳」에서 할 것인가, 아니면 「한 번 만들어두면 재사용할 수 있는 곳」에서 할 것인가——이 질문은 RAG에 국한되지 않고, LLM을 실서비스로 운영하는 모든 상황에서 유효합니다. 구동하는 것 자체가 무료가 아닌 시대에, 추론을 오프라인으로 돌릴 수 없는지를 설계의 시작 단계에서 묻는 것은 충분한 가치가 있습니다.

참고

RAG의 비용 문제를 1/15로 줄이기 — 「매번 검색하지 않는」 아키텍처 설계 (ShintaroAmaike) — 본고의 직접적인 영감의 원천
LLM의 「입력 설계」 (무엇을 읽게 할 것인가 = 입력 토큰 절감) — 본고(처리 횟수 절감)와 짝을 이루는 세로축의 논점
Anthropic - Prompt Caching — 온라인 처리 중에서도 캐시를 통해 재계산을 피하는 기법