RAG (Retrieval-Augmented Generation)는 현재 저의 집착 대상이 되었습니다. 매일 저는 저만의 파이프라인을 한 단계 더 깊게 파고들고 있으며, 거의 매일 제가 "확실히 알고 있다고 생각했던" 것들이 틀렸음이 드러나고 있습니다.

이것은 다음과 같이 시작되었습니다.

저는 틈틈이 비즈니스와 금융 콘텐츠를 읽어왔습니다. 진지한 것은 아니었고, 기업들이 실제로 어떻게 생존하는지 파악할 수 있을 정도였습니다. 한 가지 기억에 남는 사실이 있었습니다. 지속 가능한 비즈니스는 단순히 매출만을 쫓는 것이 아니라, 비용이 정확히 어디로 나가는지 파악하는 데 집착한다는 것입니다. 연료를 덜 쓰고 더 멀리 가는 것, 그것이 게임의 전부입니다.

저는 동일한 습관을 저의 RAG 파이프라인에 적용하기로 했습니다. 추측을 멈추고, 실제로 모든 단계를 파헤쳐 돈이 정말 어디로 들어가는지 확인하기로 한 것입니다.

제가 발견한 결과는 저를 놀라게 했습니다.

제가 의심하지 않았던 믿음

"임베딩 (Embedding)은 비싸다 — 어떤 대가를 치르더라도 재임베딩을 피하라."

이 말을 한 번만 들은 것이 아닙니다. 어디에서나 들었습니다. 제가 대화한 모든 개발자가 어떤 식으로든 이 말을 반복했습니다. 그래서 제가 시맨틱 캐시 (Semantic Cache)를 구축할 때, 저는 그 두려움을 바탕으로 설계했습니다. "임베딩 = 비싸다"라는 생각이 머릿속에 복음처럼 자리 잡고 있었기 때문에, Redis 기반의 시맨틱 검색 레이어가 절약하는 비용보다 더 많은 비용을 발생시킬 것이라고 가정했습니다. 결국 저는 단순한 키-값 (Key-value) 캐시에 크게 의존하게 되었는데, 그것이 "안전한" 선택처럼 느껴졌기 때문입니다.

나중에 저는 제가 잘못된 병목 현상 (Bottleneck)을 최적화했다는 것을 깨달았습니다. 임베딩을 피함으로써 얻는 절감액은 파이프라인의 다른 곳에 자리 잡은 반복적인 비용에 비하면 아주 미미했습니다.

그래서 저는 실제 문서가 제 파이프라인을 통과하는 과정을 단계별로, 하나씩 가격을 매겨보았습니다.

결과적으로 임베딩은 전혀 비싼 부분이 아니었습니다. 전체 파이프라인에서 가장 저렴한 단계 중 하나였습니다. OpenAI의 현재 임베딩 가격을 기준으로, 제 테스트에서 일반적인 1,000페이지 분량의 문서를 임베딩하는 데는 단 한 번에 약 0.18달러가 소요되었습니다.

임베딩이 병목 현상이 아니라는 것을 깨달은 후, 저는 비용이 실제로 어디에 숨어 있는지 확인하기 위해 파이프라인의 각 단계를 따라가기 시작했습니다.

파이프라인을 따라가며 돈이 실제로 어디로 가는지 찾기

  PDF 업로드 (Upload PDF)
      │
      ▼
...

중복 제거 (Dedup) 확인은 사람들이 생각하는 것보다 훨씬 더 중요합니다. 대부분의 지식 베이스 (Knowledge base)는 하루아침에 완전히 바뀌지 않으며, 천천히 진화합니다. 저의 경우, 약 80%의 문서는 그대로 유지되고 약 20%만이 실제로 변경됩니다. 이는 전형적인 80/20 법칙에 가깝습니다.

이 사실은 제가 데이터 수집 (Ingestion)을 생각하는 방식을 바꿉니다. 지식 베이스의 80%가 변경되지 않았다면, 왜 100% 전체를 다시 처리해야 할까요?

제가 저지를 뻔했던 실수는 다음과 같습니다. 문서가 업데이트될 때, 게으른 접근 방식은 이를 완전히 새로운 파일로 취급하여 전체 히스토리를 포함한 모든 과정을 다시 실행하는 것입니다. 이는 필요 이상의 완전히 다른 (그리고 훨씬 더 비용이 많이 드는) 문제입니다. 올바른 접근 방식은 이미 보유하고 있는 데이터와 차이점 (Diff)을 비교하여 실제로 변경된 부분만 처리하는 것입니다.

청킹 (Chunking) 또한 동일한 논리를 따릅니다. 문서의 특정 섹션만 변경되었다면, 문서 전체를 다시 청킹하거나 다시 임베딩 (Re-embed)할 이유가 없습니다. 변경된 청크 (Chunk)만 다시 처리하십시오. 여기서 세심한 메타데이터 (Metadata, 페이지, 섹션, 버전)가 제 역할을 합니다. 메타데이터는 애초에 "변경사항만 찾기"를 가능하게 만드는 핵심 요소입니다.

벡터 스토어 (Vector store)는 완전히 다른 비용 게임입니다. 여러분은 벡터 그 자체에 비용을 지불하는 것이 아닙니다. 수백만 개의 벡터를 밀리초 단위로 검색 가능한 상태로 유지하는 인프라에 비용을 지불하는 것입니다. 이 인프라는 누군가 질문을 하고 있든 아니든 계속 실행됩니다. 소규모 규모에서는 비용이 저렴합니다. 하지만 프로덕션 (Production) 규모에서는 실제 반복적인 비용 항목이 되며, 인덱싱 (Indexing) 및 검색 (Retrieval) 비용은 임베딩 (Embedding) 비용보다 더 빠르게 쌓입니다. 한 번 생성되면 끝나는 임베딩과 달리, 벡터 데이터베이스 (Vector database)는 온라인 상태를 유지해야 하고, 인덱스를 관리해야 하며, 모든 개별 쿼리 (Query)에 대해 유사도 검색 (Similarity search)에 응답해야 합니다.

그리고 LLM (Large Language Model)이 있습니다. 이것이 실제적인 헤비급(heavyweight)입니다. 임베딩 (Embedding)처럼 일회성 비용이 아니라, 매일 모든 사용자의 모든 질문에 대해 실행됩니다. 또한 대부분의 지연 시간 (Latency)이 발생하는 지점이기도 합니다. 저는 앞으로 이 부분에 가장 많은 시간을 할애하고 싶습니다. 왜냐하면 이곳이 비용과 사용자 경험 (User experience) 모두가 결정되는 지점이기 때문입니다.

비용 프로필은 제가 예상했던 것과 전혀 달랐습니다

전체 파이프라인을 살펴본 후, 실제로 명확해진 사실은 다음과 같습니다:

• **임베딩 (Embeddings)**은 대부분 일회성 인제스션 (Ingestion) 비용입니다.
• **벡터 데이터베이스 (Vector databases)**는 반복적인 인프라 (Infrastructure) 비용을 발생시킵니다.
• LLM은 모든 개별 사용자 요청에 대해 반복적인 비용이 됩니다.

이것들은 완전히 다른 세 가지 비용 모델입니다. 재임베딩 (Re-embedding)을 피하는 것과 같이 하나를 최적화한다고 해서 나머지 두 개에 도움이 되지는 않습니다. 그것이 제가 시맨틱 캐시 (Semantic cache)를 통해 빠졌던 함정입니다. 저는 반복적인 단계들이 배경에서 계속 실행되는 동안, 가장 저렴한 일회성 단계만을 최적화하고 있었습니다.

서로 다른 비용에는 서로 다른 최적화가 필요합니다. 일회성 인제스션 비용은 중복 제거 (Deduplication)와 증분 업데이트 (Incremental updates)를 통해 이득을 얻습니다. 반복적인 인프라 비용은 효율적인 인덱싱 (Indexing)과 스토리지 (Storage)를 통해 이득을 얻습니다. 반복적인 추론 (Inference) 비용은 캐싱 (Caching), 더 나은 검색 (Retrieval), 그리고 적합한 경우 더 작은 모델을 사용함으로써 이득을 얻습니다. 이것들을 하나의 문제가 아닌 세 개의 별개 문제로 바라보게 되자, 최적화 선택지가 훨씬 명확해졌습니다.

현재 나의 상태

저는 아직 모든 정답을 알고 있지는 않습니다. 저는 제 자신의 프로덕션 시스템을 하나씩 분해하며 배우고 있으며, 그 과정에서 틀린 부분도 있을 것입니다. 만약 여러분이 대규모 RAG 시스템을 구축해 보셨고 제가 무언가 잘못 알고 있다면, 제가 직접 확인하지도 않고 몇 달 동안 "임베딩은 비싸다"라는 가정을 반복했던 것처럼, 잘못된 가정을 계속 반복하기보다는 진심으로 교정받고 싶습니다.

다음에 파헤쳐 보고 싶은 것: 왜 벡터 데이터베이스 인프라가 임베딩 다음의 주요 비용이 되는지, 그리고 이를 줄이기 위해 제가 어떻게 생각하고 있는지에 대해서입니다.

소음은 줄이고, 실행은 더 많이. 이제 시작해 봅시다.