RAG 비용 구조: 2026년, 돈은 실제로 어디서 새는가

네 가지 비용 항목, 그리고 그중 셋이 미끼인 이유

검색 증강(RAG) 시스템이 돈을 쓰는 곳은 네 군데인데, 각각의 규모는 천차만별이다. 인덱싱 임베딩은 코퍼스를 처음 적재할 때 한 번 지불하고(이후 문서가 바뀔 때마다 증분으로 추가 지불), 쿼리당 임베딩은 사용자 질문을 임베딩해 벡터 스토어를 검색할 때마다 지불한다. 생성 단계는 컨텍스트를 읽고 답변을 작성하는 모델 호출이다. 그리고 리랭킹을 쓴다면, 후보 청크들이 생성기에 도달하기 전에 점수를 다시 매기는 추가 패스가 붙는다.

대부분의 팀은 본능적으로 임베딩 항목부터 손대려 한다. 가장 "RAG다운" 부분처럼 느껴지기 때문이다. 하지만 그 본능은 거의 항상 틀렸다. 실제 질문에 답하는 프로덕션 시스템에서 임베딩은 반올림 오차 수준이고, 청구서를 결정하는 건 생성 호출이다. 그런데 생성 비용조차 단일 숫자가 아니다. 모델에 보내는 입력 토큰과 모델이 써내는 출력 토큰으로 나뉘는데, 입력 쪽에는 대부분의 대시보드가 결코 드러내지 않는 조용한 곱셈기가 숨어 있다.

아무도 슬라이드에 적지 않는 사실: 검색해 온 청크 하나하나가 모두 생성 호출의 입력 토큰이 되며, 매 요청마다 다시 과금된다. 검색은 인덱스처럼 일회성 비용이 아니다. 매 쿼리에 따라붙고, 트래픽만큼 곱해진다. 이 가이드가 진짜로 다루려는 비용 항목이 바로 이것이다. 당신이 가장 크게 줄일 수 있는 항목이면서, 팀들이 가장 나중에 최적화하는 항목이기 때문이다.

• 인덱스 임베딩 — 사실상 일회성, 적재 시점과 문서 변경 시 지불
• 쿼리당 임베딩 — 저렴, 스토어 검색을 위해 질문당 한 번 지불
• 생성 입력 — 검색된 컨텍스트 + 지시문, 모든 요청마다 지불 (조용한 거인)
• 생성 출력 — 모델이 써내는 내용, 토큰당 가장 비쌈 (입력의 5~6배)
• 리랭킹 — 선택적 점수 재산정 패스. 더 적은 청크만 보내게 해준다면 생성 입력을 낮춰줌

핵심 통찰: 검색된 컨텍스트는 곧 입력 토큰이며, 요청당 과금된다

구체적인 형태로 산수를 따라가 보자. Claude Sonnet 4.6(입력 100만 토큰당 $3.00, 출력 $15.00)으로 서포트 어시스턴트를 월 100만 요청 규모로 운영한다고 하자. 각 요청은 1,500 토큰짜리 지시문/시스템 블록, 1,500 토큰의 검색된 컨텍스트(대략 중간 크기 청크 8개의 top-k), 그리고 500 토큰짜리 답변을 생성한다.

입력 쪽: 1,500 토큰짜리 지시문 블록은 1,500 × 1,000,000 = 월 15억 토큰이고, 100만 토큰당 $3.00이니 $4,500이다. 1,500 토큰의 검색된 컨텍스트도 또 15억 토큰, 또 $4,500이다. 출력: 500 × 100만 = 5억 토큰을 100만 토큰당 $15.00로 계산하면 $7,500이다. 합계: 월 $16,500, 그리고 검색된 컨텍스트만으로 그중 27%를 차지한다.

이제 누군가 "재현율을 높인다고" top-k를 8에서 20으로 올렸을 때 무슨 일이 벌어지는지 보자. 검색 설정의 한 줄짜리 변경이고, 비용 관점에서 아무도 리뷰하지 않는 변경이다. 검색된 컨텍스트는 1,500에서 약 3,750 토큰으로 늘어난다. 이 항목은 $4,500에서 월 $11,250으로 뛴다. 모델이 대부분 무시할 청크를 위해 매달 $6,750이 추가로 나가는 것이다. 모델도 그대로, 트래픽도 그대로, 알림도 없었다. 단지 검색이 요청당 입력 곱셈기인데도 거의 누구도 그렇게 취급하지 않기 때문에 청구서가 41% 늘어난 것이다.

간직해야 할 멘탈 모델은 이것이다: 검색된 토큰은 공짜 컨텍스트가 아니라, QPS만큼 곱해지는 반복 입력 비용이다. 아래의 모든 해법은 결국, 같은 토큰에 정가 입력 비용을 내기를 멈추거나, 답을 잃지 않으면서 더 적은 토큰을 보내는 방법이다.

레버 1: 안정적인 프리픽스를 캐싱하라 (그리고 캐싱할 수 없는 것을 파악하라)

첫 번째 레버는 당기는 데 비용이 거의 들지 않는다. 1,500 토큰짜리 지시문/시스템 블록은 매 요청마다 동일하다. 같은 페르소나, 같은 출력 규칙, 같은 퓨샷 예제다. 이는 교과서적인 프롬프트 캐싱 대상이다. Claude Sonnet 4.6에서 캐시 읽기는 표준 입력 $3.00/1M 대비 $0.30/1M으로 10배 저렴하며, 일회성 캐시 쓰기 $3.75/1M만 한 번 내면 된다. 월 100만 건의 웜 요청이라면 그 쓰기 한 번은 반올림 오차이고, 사실상 한 달 내내 읽기 요율만 내는 셈이다.

프리픽스를 캐싱한 채 같은 워크로드를 돌려보자. 지시문 블록은 $4,500에서 1,500 × 100만 × $0.30/1M = 월 $450으로 떨어진다. 검색된 컨텍스트와 출력은 그대로이니 합계는 $16,500에서 월 $12,450으로 줄어든다. 본질적으로 설정 변경 하나로 $4,050을 아낀 것이다. OpenAI와 Gemini는 운영상 더 단순하다. 쓰기 수수료가 아예 없다(GPT-5.4 캐시 읽기 $0.25, Gemini 2.5 Flash 캐시 읽기 $0.03). 다만 대량일 때는 보통 Anthropic의 더 깊은 읽기 할인이 유리하다. 손익분기 계산 전체는 프롬프트 캐싱 ROI 가이드에 있다.

여기서 RAG 팀을 특히 걸려 넘어지게 하는 함정이 있다: 검색된 청크는 보통 캐싱할 수 없다. 캐싱은 정확하고 안정적인 토큰 프리픽스를 키로 삼는다. 검색된 컨텍스트는 매 쿼리마다 바뀐다. 질문도 다르고, 청크도 다르고, 순서도 다르다. 그러니 캐시 히트가 절대 나지 않는다. 더 나쁜 건, 검색된 청크를 안정적인 지시문 앞에 두면 캐싱 가능한 프리픽스 자체가 깨진다는 점이다. 캐시는 처음으로 달라지는 토큰까지만 확장되기 때문이다.

구조적 해법은 순서다. 안정적인 것을 모두 먼저 둔다. 시스템 규칙, 페르소나, 퓨샷 예제, 고정된 보일러플레이트 일체를 앞에 놓고 거기에 캐시 브레이크포인트를 표시한 뒤, 변동하는 검색 청크와 사용자 질문을 그 뒤에 붙인다. 변하지 않는 것을 캐싱하고, 정말로 요청마다 변하는 것에만 정가를 낸다. "캐싱을 시도했는데 효과가 없었다"는 팀들은 대부분 순서가 뒤집혀 있었다.

레버 2: 더 적게, 그러나 더 잘 검색하라

캐싱은 안정적인 토큰의 가격을 줄인다. 레버 2는 캐싱할 수 없는 부분, 즉 검색된 청크 자체를 공략한다. 그것들은 매 호출마다 정가 입력이므로, 가장 저렴한 검색 토큰은 애초에 보내지 않는 토큰이다. 목표는 답을 담고 있는 가장 작은 컨텍스트를 생성기에 먹이는 것이지, 답을 담고 있을지도 모르는 가장 큰 컨텍스트가 아니다.

높은 top-k는 마음의 안정을 주는 담요일 뿐이다. top-k를 8에서 20으로 올리는 것이 추가한 토큰에 비례해 답변 품질을 높여주는 경우는 드물다. 어느 지점을 넘으면 거의 중복이거나 주제에서 벗어난 구절로 프롬프트를 채우게 되고, 이는 신호를 희석시키며 일부 모델에서는 오히려 답을 망친다("중간에서 길을 잃음(lost in the middle)"). 더 타이트하고 잘 청킹된 검색이 더 좋은 답과 더 작은 청구서를 동시에 내는 경우가 많다. 저렴한 선택지가 동시에 좋은 선택지이기도 한 드문 사례 중 하나다.

리랭킹이 제 몫을 하는 지점이 바로 여기다. 리랭커 자체도 비용이지만, 넓게 과잉 검색한 다음 상위 소수만 비싼 생성기에 보내도록 해주는 저렴한 점수 매김 모델이다. 후보 30개를 검색하고, 리랭킹하고, 상위 4~6개만 넘긴다. 리랭킹 패스에 약간 내는 대신 생성 입력에서는 훨씬 덜 내게 된다. 요청당 검색 토큰을 강하게 잘라내기 때문이다. 리랭킹은 생성 입력이 지배적 비용일 때만 이득이다. 그리고 위의 지도가 보여주듯, 보통은 그렇다.

청킹 전략은 나머지 절반이다. 너무 큰 청크는 무관한 이웃 텍스트를 컨텍스트로 끌고 들어와 토큰을 낭비하고, 너무 작은 청크는 답을 여러 검색 조각으로 쪼개 재구성하려고 top-k를 높이게 만든다. 청크 크기와 오버랩을 당신의 실제 질문에 맞춰 튜닝한 뒤, 요청당 검색 토큰을 측정하라. 그 숫자에 월 볼륨과 입력 요율을 곱한 값이 바로 당신이 지켜보며 끌어내릴 수 있는 항목이다. 토큰 카운터로 현재 청크가 정확히 몇 토큰을 소비하는지 확인해 보라.

레버 3: 합성 모델을 질문에 맞춰라

생성 모델은 가장 큰 비용 항목이므로, 모델 선택이 가장 큰 단일 레버다. 다만 "가장 싼 모델을 골라라"는 잘못된 프레임이다. 올바른 프레임은 라우팅이다. 모든 질문이 최고 모델을 필요로 하지는 않는다. 서포트 RAG는 단순 조회의 긴 꼬리("영업시간이 어떻게 되나요", "비밀번호를 어떻게 재설정하나요")와, 그보다 적은 진짜 어려운 다중 문서 추론 질문을 함께 처리한다.

쉬운 다수는 더 저렴한 티어로 라우팅하고, 어려운 소수에만 플래그십을 아껴 쓰라. Claude Haiku 4.5($1.00/$5.00, 캐시 읽기 $0.10)나 Gemini 2.5 Flash($0.30/$2.50)는 컨텍스트에 이미 답이 들어 있는, 근거가 있고 잘 검색된 사실 질문이라면 충분히 잘 답한다. 그게 바로 RAG의 핵심이다. 당신은 모델에게 무언가를 알라고 요구하는 게 아니라, 당신이 건넨 것을 읽으라고 요구하는 것이다. 작은 모델이 곧잘 해내는 일이고, 내 주장 대신 당신의 자체 평가(eval)로 확인해야 한다.

롱컨텍스트 모델은 가격뿐 아니라 아키텍처를 바꾼다. Gemini 2.5 Pro는 2M 토큰 윈도우를 갖고, Claude Sonnet/Opus, Grok 4.3, DeepSeek V4는 모두 1M에 이른다. 그 여유는 의도적인 트레이드오프를 가능케 한다. 작거나 천천히 변하는 코퍼스라면 공격적인 청킹과 검색 튜닝을 건너뛰고 큰 윈도우에 기댈 수 있다. 다만 레버 2의 경고를 기억하라. 그 윈도우에 쏟아붓는 모든 토큰은 여전히 매 호출마다 입력으로 과금된다. 큰 컨텍스트 윈도우는 더 많은 토큰을 보내도 된다는 허가일 뿐, 그 토큰에 대한 할인이 아니다.

솔직한 단서 두 가지. 첫째, 가격표만 보고 티어 간 품질이 동등하다고 절대 가정하지 마라. 더 싼 합성 모델은 당신의 특정 분포에서 사실을 지어내거나 뉘앙스를 놓칠 수 있으니, 전환 전에 실제 트래픽으로 200~500개 프롬프트 평가를 돌려라. 둘째, 출력이 비싼 쪽(입력의 5~6배)이므로, 장황한 답을 제한하고 출력 형식을 다듬는 것 자체가 하나의 레버다. 출력 비용 가이드가 이를 다루고, Haiku 4.5 vs GPT-5.4 mini 같은 티어 비교가 저렴한 티어들이 어디에 위치하는지 보여준다.

실전 예제: 월 100만 요청 서포트 RAG

위 워크로드에 레버들을 합쳐 보자. Sonnet 4.6, 월 100만 요청, 1,500 토큰 안정 프리픽스 + 1,500 토큰 검색 컨텍스트 + 500 토큰 출력. 아무것도 최적화하지 않은 기준선: 월 $16,500(프리픽스 $4,500 + 검색 $4,500 + 출력 $7,500). 이는 RAG 스타트업: 갈아탈까 머무를까? 리포트에서 비용을 산정한 시나리오와 같으며, 거기서의 핵심 질문은 애초에 프로바이더를 바꿀 가치가 있느냐다.

본능은 더 싼 프로바이더를 쫓는 것이다. 생성 호출을 GPT-5.4($2.50/$15.00, 캐시 읽기 $0.25)로 바꾸고 프리픽스를 캐싱하면 월 $11,625에 도달한다. 실제로 30% 절감이지만, SDK 마이그레이션, 프롬프트 재작성, 새로운 평가 한 바퀴라는 대가가 따른다. 이제 현 위치에서의 수정과 비교해 보자. 레버 1만으로도(기존 Sonnet에서 프리픽스 캐싱) 모델 변경 없이 월 $12,450으로 떨어진다. 여기에 레버 2를 더해 리랭킹으로 검색 컨텍스트를 1,500에서 약 800 토큰으로 줄이면 월 $10,350, 즉 37% 절감에 도달한다.

이 결과를 주의 깊게 읽어라. 이미 쓰고 있는 모델에서 컨텍스트를 줄이고 캐싱한 결과($10,350)가 프로바이더 전환($11,625)을 이긴다. 약 월 $1,275 더 싸고, 마이그레이션 리스크는 전혀 없다. 더 낮은 정가를 쫓아 스택을 재작성한 팀은, 검색을 손본 팀보다 더 많은 일을 하고도 더 나쁜 결과를 얻은 것이다. 이것이 핵심 교훈이다. 가장 효과적인 수는 보통 내부에 있지, 벤더 변경이 아니다.

그 위에 레버 3을 쌓는다. 트래픽의 약 60%(단순 조회)를 Haiku 4.5로 라우팅하고 어려운 40%는 Sonnet에 두되, 둘 다 줄인 컨텍스트와 캐싱된 프리픽스를 쓴다. 합계는 약 월 $6,210으로 떨어진다. 기준선 대비 62% 절감이며, 여전히 프로바이더 마이그레이션 없이 당신의 스택 안에서의 라우팅만으로 이뤄낸 것이다. 무언가에 손대기 전에, 마이그레이션 ROI 시뮬레이터에서 당신의 실제 토큰 수치로 당신만의 버전을 모델링해 보라.

• 기준선 (Sonnet 4.6, top-k=8, 캐싱 없음): 월 $16,500
• 생성을 GPT-5.4로 전환 + 프리픽스 캐싱: 월 $11,625 (−30%, 단 전면 마이그레이션)
• 레버 1 — Sonnet에서 안정 프리픽스 캐싱: 월 $12,450 (−25%, 설정만)
• 레버 1+2 — 캐싱 + 리랭킹/약 800 검색 토큰으로 축소: 월 $10,350 (−37%, 전환을 이김)
• 레버 1+2+3 — Haiku 4.5로 60% 라우팅 추가: 약 월 $6,210 (−62%, 프로바이더 변경 없음)

임베딩 현실 점검: 인덱스가 문제가 아닌 이유

임베딩은 가장 많은 주목을 받지만 가장 적게 받아 마땅하다. "임베딩"이라는 단어 아래에는 별개의 두 비용이 숨어 있다. 인덱스는 코퍼스를 적재할 때 한 번 지불하고 문서가 변할 때마다 증분으로 추가된다. 지식 베이스가 끊임없이 바뀌지 않는 한 진짜로 사실상 일회성이다. 쿼리당 임베딩은 사용자 질문을 임베딩해 스토어를 검색할 때마다 지불하는데, 질문은 짧아서 보통 수십 토큰 수준이다.

생성 청구서와 견줘 그 격차를 체감해 보자. 500만 문서 코퍼스를 각 약 800 토큰으로 임베딩하면 40억 토큰이다. 하지만 일반적인 임베딩 요율(100만 토큰당 1달러의 작은 분수)에서는 그 일회성 인덱스 전체가 수천 달러가 아니라 수십 달러 초반대에 떨어진다. 쿼리당 임베딩은 가령 질문당 40 토큰으로 100만 요청이면 월 4천만 토큰, 같은 요율에서 1달러 미만이다. 두 수치 모두 예시일 뿐이지만(임베딩 SKU는 프로바이더마다 다르고 이 사이트의 생성 가격표에 포함돼 있지 않다), 요점은 자릿수다. 월 $16,500의 생성 비용에 비하면 임베딩은 잡음이다.

그렇다고 "싸다"가 "무시하라"는 아니다. 아주 큰 규모이거나 문서 변경이 잦을 때(코퍼스를 매일 밤 재임베딩하거나, 수천 토큰짜리 문서를 대량으로 임베딩하는 경우) 인덱스 항목이 실제로 의미 있는 숫자까지 오를 수 있다. 이럴 때 적재에 배치 티어(제공되는 경우, 보통 50% 할인)를 쓰는 것은 가치가 있다. 하지만 우선순위는 명확하다. 생성 입력부터 통제하라. top-k가 20으로 매달 조용히 $6,750을 생성 호출에서 태우는데 임베딩 모델을 튜닝해 인덱스 청구서를 깎고 있다면, 당신은 엉뚱한 비용 항목을 최적화하고 있는 것이다.

레버리지를 존중하는 분류(triage) 순서

비용 항목들이 자릿수 단위로 차이 나기 때문에, 어떤 순서로 손대느냐가 해법 자체만큼이나 중요하다. 가장 큰 레버리지·가장 낮은 리스크에서 시작해 가장 작은 레버리지·가장 높은 리스크 쪽으로 작업하고, 각 단계 후에 다시 측정해서 목표에 도달하면 멈춰라. 과도하게 엔지니어링하지 말고.

먼저 측정하라: 실제 트래픽에서 요청당 검색 토큰과 캐싱된 입력 대 캐싱되지 않은 입력을 계측하라. 로그에 없는 숫자는 최적화할 수 없고, 대부분의 RAG 청구서가 놀라움인 이유는 바로 누구도 요청당 토큰 형태를 추적하지 않았기 때문이다. 무엇을 수집해야 하는지는 비용 모니터링 가이드가 다룬다.

• 안정적인 프리픽스를 캐싱하고 응답 usage 메타데이터에서 캐시 히트를 확인하라 — 가장 적은 노력으로 가장 큰 이득
• top-k와 청킹을 점검하고, 리랭킹을 추가해 과잉 검색한 뒤 상위 4~6개 청크만 보내라
• 쉬운 질문은 더 저렴한 합성 티어로 라우팅하고, 어렵고 다중 문서 추론에는 플래그십을 유지하라
• 출력을 제한하고 다듬어라. 출력 토큰은 입력의 5~6배 비싸다
• 그런 다음에야 프로바이더 전환을 고려하라 — 그리고 먼저 현 위치 수정과 비교해 가격을 매겨라. 그쪽이 이기는 경우가 많다
• 코퍼스 변경량이 정말로 크지 않은 한 임베딩은 맨 마지막에 두라

자주 묻는 질문

관련 글