예전에는 RAG 파이프라인을 블랙박스처럼 취급했습니다. 임베딩이 들어가면 답변이 나왔고, 그 과정 어딘가에서 클라우드 비용은 계속 불어났습니다. 제가 대화해 본 대부분의 개발자처럼, 저 역시 밀집 벡터 모델(dense vector models)이 주범이라고 생각했습니다. 비용이 많이 들 것 같았거든요. 천 페이지 분량의 문서를 고차원 부동 소수점(high-dimensional floats)으로 변환하는 작업은 마치 중공업처럼 무겁게 느껴졌고, 그래서 그만큼 조심스럽게 다뤘습니다. 이미 처리한 데이터를 다시 임베딩하지 않으려고 별도의 캐싱 레이어까지 구축했습니다. 그 최적화 작업이 꽤 자랑스러웠죠. 그러다 청구서를 열어보고 계산을 해보았습니다.
저는 완전히 잘못된 것을 최적화하고 있었습니다.
임베딩의 함정
제 가설을 완전히 깨뜨린 숫자가 있습니다. 1,000페이지 분량의 문서를 임베딩하는 데 드는 비용은 약 18센트입니다. 오타가 아닙니다. 대부분의 도시에서 커피 한 잔 값도 안 되는 금액으로 책 한 권 전체를 벡터화할 수 있습니다. 더 중요한 점은, 이 비용은 데이터 주입(ingestion) 시점에 단 한 번만 발생한다는 것입니다. 초기 작업이 끝나면 해당 벡터들은 저장소에 머물며 대기합니다. 사용자가 애플리케이션을 열 때마다 매번 비용이 발생하는 것이 아닙니다. 이는 반복적인 지출이 아니라 자본 지출(capital expense)에 가깝습니다.
그럼에도 불구하고 오해는 계속됩니다. 혼란의 일부는 구조적인 문제에서 기인합니다. 엔지니어들은 초기에 인제스션 파이프라인에 많은 에너지를 쏟습니다. 청커(chunker)를 작성하고, 토크나이저(tokenizer)와 씨름하며, 터미널에서 느릿하게 올라가는 진행 표시줄을 지켜봅니다. 이러한 눈에 보이는 노력은 비용의 비중이 크다는 착각을 불러일으킵니다. 노동 집약적인 작업이기 때문에 비용도 많이 들 것이라고 느끼는 것이죠. 하지만 노동과 비용은 같지 않으며, RAG에서는 종종 반비례 관계에 있습니다.
세 가지 서로 다른 비용 항목
비용을 한데 묶지 않고 단계별로 분리하자 비로소 상황이 명확해졌습니다. RAG 시스템은 세 가지 서로 다른 경제 모델로 운영되며, 예산을 효율적으로 관리하려면 이 차이를 이해하는 것이 필수적입니다.
임베딩은 일회성 제조 비용입니다. 문서를 벡터로 변환하기 위해 비용을 지불하면 작업은 끝납니다. 문서가 정적이라면, 이 항목은 월간 청구서에 거의 나타나지 않을 것입니다.
벡터 데이터베이스는 인프라 임대료입니다. 시스템을 24시간 가동하기 위해 비용을 지불합니다. 수백만 개의 청크를 보관하는 SSD, 인덱스를 유지하는 CPU 코어, 그리고 100밀리초 미만의 검색 속도를 제공하는 네트워크에 비용을 지불합니다. 이 비용은 실재하며 데이터 양에 따라 늘어나지만, 일반적으로 예측 가능합니다. 마치 헬스장 회원권과 같습니다. 쿼리를 한 번 하든 만 번 하든, 기본 인프라 비용은 거의 일정하게 유지됩니다.
대규모 언어 모델(LLM)은 소비세입니다. 사용자의 질문 하나하나가 비용을 발생시킵니다. 검색 레이어를 떠나 프롬프트로 들어가는 모든 토큰에는 비용이 따릅니다. 모델이 수행하는 모든 추론 단계, 모든 포맷팅 지침, 모든 인용 생성 요청이 미세한 무게를 더합니다. 하지만 이러한 미세 비용은 세션 수에 따라 배수로 늘어나며, 세션 수는 계속 증가하는 추세입니다. 바로 이 지점에서 지연 시간(latency)과 지출이 결합됩니다. 느린 쿼리는 사용자에게 짜증을 유발할 뿐만 아니라, 사용자가 기다리는 동안 실제로 현금을 태우고 있는 것과 같습니다.
이것들은 동일한 문제의 변형이 아닙니다. 세 가지 별개의 문제입니다. 인제스션 비용을 낮춘다고 해서 쿼리 시점의 지출 문제를 해결할 수는 없습니다. 그것은 주차비를 아끼려고 자동차 엔진을 튜닝하는 것과 같습니다.
돈이 실제로 새 나가는 곳
실제 운영 중인 RAG 애플리케이션을 사용하고 있다면, 비용 탐색기(cost explorer)를 열어 사용 유형별로 필터링해 보십시오. 저는 여러분의 임베딩 작업은 하루에 한 번 평탄한 선을 그리는 반면, LLM 엔드포인트는 트래픽에 따라 심장 박동처럼 요동치는 모습을 보일 것이라고 확신합니다. 그 패턴이 모든 것을 말해줍니다. 벡터는 잠들어 있지만, 사용자가 질문을 던질 때마다 모델은 깨어납니다.
이 깨달음은 제가 엔지니어링 작업의 우선순위를 정하는 방식을 바꾸어 놓았습니다. 저는 어떻게 하면 인제스션을 더 저렴하게 만들지 묻는 대신, 어떻게 하면 각 질문의 비용을 더 낮출 수 있을지 묻기 시작했습니다. 이 변화는 당연해 보이지만, 대부분의 팀은 여전히 직감에 의존해 운영합니다. 임베딩 단계에서는 정교한 중복 제거(deduplication) 로직을 구축하면서도, 정작 LLM에는 아무런 고민 없이 비대하고 초점이 맞지 않는 컨텍스트 윈도우를 밀어 넣습니다. 지붕이 새고 있는데 바닥만 닦고 있는 격입니다.
파이프라인을 망가뜨리지 않고 비용을 절감하는 방법
RAG 시스템에서 비용을 절감하려면 각 비용 모델에 맞는 전략을 선택해야 합니다. 실제로 효과가 있는 방법은 다음과 같습니다.
프로세스 전 중복 제거하기
대부분의 조직 지식 베이스는 변화가 느립니다. 정책, 핸드북, 연구 PDF, 아카이브된 보고서들은 몇 달 동안 방치되곤 합니다. 많은 파이프라인에서 소스 문서의 약 80%는 데이터 수집(ingestion) 실행 간에 동일하게 유지됩니다. 그럼에도 불구하고, 많은 시스템이 정해진 일정에 따라 전체 코퍼스를 버리고 인덱스를 처음부터 다시 구축합니다. 그렇게 하지 마세요. 파이프라인 입구에 게이트를 만드세요. 들어오는 파일의 해시를 생성하세요. 마지막 수정 타임스탬프를 비교하세요. 문서가 변경되지 않았다면 완전히 건너뛰세요. 정적인 파일을 다시 처리하는 것은 순전한 낭비입니다. 컴퓨팅 자원을 소모하고, SSD를 불필요하게 마모시키며, 잘못된 활동으로 인제스션 로그를 부풀립니다.
실제로 파일 경로를 체크섬(checksum)에 매핑하는 가벼운 매니페스트를 저장하세요. 스케줄러가 깨어나면 매니페스트를 먼저 확인하게 하세요. 변경된 소수의 파일만 청커(chunker)를 거치도록 해야 합니다.
문서를 교체하지 말고 패치하세요
문서가 변경되었을 때, 이를 완전히 새로운 파일로 취급하려는 본능을 억제하세요. 50페이지 분량의 기술 사양서에서 4번 섹션의 두 단락만 수정될 수도 있습니다. 파이프라인이 파일 전체를 교체한다면, 아무 이유 없이 49페이지의 멀쩡한 페이지를 다시 청킹하고 다시 임베딩하게 됩니다.
대신 새 버전을 이전 버전과 비교하세요. 차이(delta)를 식별하세요. 그런 다음 변경된 섹션만 다시 청킹하고 다시 임베딩하세요. 페이지 번호, 섹션 ID, 헤더 앵커 또는 단락 범위를 메타데이터로 사용하여 경계를 추적하세요. 청킹 전략이 문서 구조를 존중한다면 이는 간단합니다. 그렇지 않다면, 더 큰 추론 클러스터를 구매하는 것보다 청커를 수정하는 것이 더 나은 투자입니다. 문서 수가 늘어남에 따라 차이 인지(diff-aware) 파이프라인을 유지하는 엔지니어링 비용은 몇 주 안에 본전을 뽑을 것입니다.
반복되는 비용에 정면으로 대응하세요
모든 쿼리마다 LLM 호출이 실행되므로, 단 몇 개의 토큰을 줄이거나 몇 개의 응답을 캐싱하는 것만으로도 엄청난 수익을 창출할 수 있습니다. 프롬프트 캐싱부터 시작하세요. 한 사용자가 환불 정책에 대해 묻고 10분 뒤에 다른 사용자가 같은 질문을 한다면, 모델을 두 번 호출할 이유가 없습니다. 최근의 쿼리-응답 쌍을 의미론적 유사도 매칭(semantic similarity matching)과 함께 저장하세요. 새로운 질문이 캐시된 질문과 유사도 임계값 내에 들어오면 저장된 답변을 직접 반환하세요. 토큰 생성도, 비용 지출도 없습니다.
다음으로 검색 품질을 면밀히 살펴보세요. 허술한 검색기(retriever)는 LLM이 바늘을 찾기 위해 건더미를 뒤지게 만듭니다. top-k 컷오프가 너무 느슨해서 프롬프트에 관련 없는 20개의 청크를 채워 넣는다면, 모델이 노이즈를 훑어보게 하는 비용을 지불하고 있는 셈입니다. 검색을 강화하세요. top-k를 줄이세요. 전송하기 전에 청크를 압축하세요. 인제스션 단계에서 상용구(boilerplate)인 푸터와 헤더를 제거하여 프롬프트에 도달하지 않도록 하세요. 컨텍스트 윈도우에서 제거하는 모든 토큰은 0.01센트의 절약이며, 이러한 작은 금액이 매일 수천 건의 쿼리에 걸쳐 쌓입니다.
더 나은 검색은 지연 시간(latency)도 개선하며, 이는 또 다른 형태의 비용입니다. 사용자는 느린 인터페이스를 떠납니다. 더 빠른 답변은 생성 비용이 저렴할 뿐만 아니라 사용자 유지(retention)에도 좋습니다.
진정한 핵심 요약
비싸게 느껴지는 것을 최적화하는 것을 멈추고, 청구서에 비싸다고 적힌 것을 최적화하기 시작하세요. 각 단계를 독립적으로 측정하세요. 아마도 임베딩은 저렴한 부분이고, 벡터 저장소는 꾸준한 부분이며, LLM 추론이 비용이 새어나가는 부분임을 알게 될 것입니다. 쿼리 시점의 효율성, 증분 업데이트, 그리고 정밀한 중복 제거에 에너지를 집중하세요. 50번째 문서 업로드가 아니라 1,000번째 사용자 질문을 위해 구축하세요. 병목 현상은 당신이 생각하는 곳에 있는 경우가 드뭅니다.
Source: Where Does RAG Actually Cost You Money? I Decided to Stop Guessing
Join the discussion in the GyaanSetu AI learning community.