프로덕션 환경에서의 RAG: 최고의 엔지니어링 팀들이 기존 애플리케이션에 검색 증강 생성(Retrieval-Augmented Generation)을 통합하는 방법

대규모 언어 모델(Large Language Models)은 매우 인상적이지만, 환각(hallucination) 현상이 나타나기 시작하면 문제가 됩니다.

이것은 많은 엔지니어링 팀이 기존 제품에 AI를 임베딩(embed)하려고 할 때 직면하는 과제입니다. 파운데이션 모델(foundation models)은 유창한 응답을 생성할 수 있지만, 최신 비즈니스 데이터, 독점 지식 베이스(proprietary knowledge bases) 또는 고객 특정 정보에 대한 접근 권한이 부족한 경우가 많습니다.

이 지점에서 검색 증강 생성(Retrieval-Augmented Generation, RAG)이 가장 많이 채택되는 AI 아키텍처 패턴 중 하나가 되었습니다.

데이터가 변경될 때마다 모델을 재학습(retraining)시키는 대신, RAG를 사용하면 애플리케이션이 외부 소스에서 관련 정보를 검색하고 생성(generation) 전에 해당 컨텍스트(context)를 모델에 주입할 수 있습니다.

지난 2년 동안 OpenAI, Anthropic, Microsoft, Google, Databricks와 같은 기업들과 GeekyAnts와 같은 컨설팅 기업의 엔지니어링 팀들은 프로덕션 수준의 AI 기능을 구축하기 위해 RAG 기반 아키텍처를 점점 더 많이 채택해 왔습니다.

이 기사에서는 RAG가 기존 애플리케이션에 어떻게 통합되는지, 관련된 아키텍처 패턴, 일반적인 도구 선택, 그리고 구현 전에 개발자가 이해해야 할 실제 비용에 대해 탐구합니다.

기존 LLM 통합 방식이 실패하는 이유

AI 통합을 위한 일반적인 첫 번째 시도는 다음과 같은 모습입니다:

사용자 질의 (User Query)
    ↓
LLM API
...

이 접근 방식은 일반적인 질문에는 잘 작동하지만, 애플리케이션에 다음과 같은 사항이 필요할 때 어려움을 겪습니다:

• 내부 회사 지식
• 제품 문서
• 고객 특정 정보
• 실시간 비즈니스 데이터
• 규제 또는 컴플라이언스(compliance)에 민감한 콘텐츠

모델이 이 정보에 안정적으로 접근할 수 없기 때문에, 응답은 빠르게 구식이 되거나 부정확해집니다.

RAG는 지식 검색(knowledge retrieval)과 언어 생성(language generation)을 분리함으로써 이러한 한계를 해결합니다.

프로덕션 RAG 아키텍처의 모습

높은 수준에서 살펴보면, RAG 워크플로우는 생성 단계 이전에 검색 레이어(retrieval layer)를 도입합니다.

사용자 쿼리 (User Query)
     ↓
임베딩 모델 (Embedding Model)
...

모델의 메모리에 전적으로 의존하는 대신, 시스템은 런타임(runtime) 시점에 관련 컨텍스트(context)를 제공합니다.

이러한 접근 방식은 팀이 모델을 재학습(retraining)시키지 않고도 지식 소스(knowledge sources)를 업데이트할 수 있게 해줍니다.

RAG 스택의 핵심 구성 요소 (Core Components of a RAG Stack)

1. 데이터 인제스션 레이어 (Data Ingestion Layer)

대부분의 구현은 다음과 같은 소스로부터 데이터를 수집하는 것으로 시작합니다:

• PDF
• 문서 사이트 (Documentation sites)
• 내부 위키 (Internal wikis)
• 데이터베이스 (Databases)
• CRM 시스템
• 지식 베이스 (Knowledge bases)

그 후 콘텐츠는 정제(cleaned), 청킹(chunked) 과정을 거쳐 인덱싱(indexing)을 위한 준비를 마칩니다.

프로덕션 배포 과정에서 얻은 공통적인 교훈은 모델 선택보다 데이터 품질이 더 중요하다는 것입니다.

구조가 잘못된 문서는 깨끗한 검색 파이프라인(retrieval pipelines)을 갖춘 더 작은 모델을 사용하는 것보다 종종 더 나쁜 결과를 초래합니다.

2. 임베딩 모델 (Embedding Models)

임베딩(Embeddings)은 텍스트를 의미론적(semantically)으로 검색 가능한 수치 벡터(numerical vectors)로 변환합니다.

인기 있는 옵션은 다음과 같습니다:

• OpenAI Embeddings
• Cohere Embed
• Voyage AI
• BAAI BGE 모델
• Sentence Transformers

목표는 정확한 키워드 매칭(keyword matching)보다는 의미를 표현하는 것입니다.

예를 들어:

"환불 정책이 어떻게 되나요?"

와

"돈을 돌려받을 수 있을까요?"

는 서로 다른 표현을 사용하더라도 유사한 문서를 검색해야 합니다.

3. 벡터 데이터베이스 (Vector Databases)

벡터 데이터베이스는 임베딩을 저장하고 유사도 검색(similarity search)을 수행합니다.

인기 있는 선택지는 다음과 같습니다:

• Pinecone
• Weaviate
• Qdrant
• Milvus
• Chroma
• pgvector (PostgreSQL)

엔지니어링 팀은 기존 PostgreSQL 인프라를 확장할 수 있기 때문에 초기 단계 제품에는 종종 pgvector를 선택합니다.

규모가 더 큰 배포의 경우, 향상된 성능과 확장성(scalability)을 위해 전용 벡터 검색 시스템으로 마이그레이션할 수 있습니다.

4. 검색 레이어 (Retrieval Layer)

검색 레이어는 어떤 콘텐츠가 모델에 전달될지를 결정합니다.

일반적인 기술에는 다음이 포함됩니다:

• 의미론적 검색 (Semantic search)
• 하이브리드 검색 (Hybrid search)
• 메타데이터 필터링 (Metadata filtering)
• 리랭킹 모델 (Reranking models)
• 컨텍스트 압축 (Context compression)

많은 프로덕션 시스템은 최첨단 (Frontier) LLM을 교체하는 것보다 검색 품질이 출력 품질에 더 큰 영향을 미친다는 사실을 발견합니다.

5. 생성 계층 (Generation Layer)

컨텍스트가 검색되면, 이는 프롬프트에 삽입됩니다.

그 후 LLM은 검색된 정보에 기반하여 응답을 생성합니다.

대중적인 선택지는 다음과 같습니다:

• GPT-4o
• Claude
• Gemini
• Llama 모델
• Mistral 모델

모델은 추론 엔진 (Reasoning engine)이 되고, 검색 시스템은 지식 엔진 (Knowledge engine)이 됩니다.

팀들이 저지르는 가장 큰 실수들

다양한 프로덕션 RAG 구현 사례를 검토한 결과, 몇 가지 반복되는 문제들이 나타납니다.

모든 것을 저장하기

많은 팀이 사용 가능한 모든 문서를 인덱싱합니다.

이는 다음과 같은 문제를 야기합니다:

• 관련 없는 검색 결과
• 저장 비용 증가
• 낮은 응답 품질

가치 높은 콘텐츠를 선별 (Curating)하는 것이 종종 더 나은 결과를 만들어냅니다.

청킹 전략 (Chunking Strategy) 무시

청크 크기는 검색 성능에 직접적인 영향을 미칩니다.

청크가 너무 크면 관련성이 희석됩니다.

청크가 너무 작으면 컨텍스트를 잃게 됩니다.

적절한 균형을 찾는 데는 대개 실험이 필요합니다.

모니터링 부재

RAG 시스템도 다른 프로덕션 서비스와 마찬가지로 관찰 가능성 (Observability)이 필요합니다.

주요 지표는 다음과 같습니다:

• 검색 정확도 (Retrieval accuracy)
• 컨텍스트 활용도 (Context utilization)
• 환각률 (Hallucination rates)
• 쿼리 지연 시간 (Query latency)
• 토큰 소비량 (Token consumption)

모니터링이 없으면, 사용자가 문제를 보고할 때까지 품질 저하를 알아차리지 못하는 경우가 많습니다.

RAG의 실제 비용은 얼마인가?

RAG가 인기를 얻게 된 이유 중 하나는 대규모 모델을 미세 조정 (Fine-tuning)하는 것보다 일반적으로 더 저렴하기 때문입니다.

전형적인 비용 카테고리는 다음과 같습니다:

인프라 (Infrastructure)

• 벡터 데이터베이스 (Vector database) 호스팅
• 저장소 (Storage)
• API 게이트웨이 (API gateways)
• 캐싱 시스템 (Caching systems)

임베딩 비용 (Embedding Costs)

모든 문서는 인덱싱 전에 임베딩 (Embeddings)으로 변환되어야 합니다.

대규모 지식 베이스의 경우, 임베딩 생성은 종종 상당한 일회성 비용이 됩니다.

추론 비용 (Inference Costs)

지속적인 비용은 일반적으로 다음에서 발생합니다:

• 검색 요청 (Retrieval requests)
• LLM API 호출
• 컨텍스트 창 (Context window) 사용량

RAG는 모델 재학습 (retraining)의 필요성을 줄여주기 때문에, 많은 조직이 이를 더 예측 가능한 확장 모델 (scaling model)을 제공하는 방법으로 판단하고 있습니다.

선도적인 기업들이 RAG에 접근하는 방식

각 조직은 서로 다른 사용 사례 (use cases)를 위해 RAG를 채택해 왔습니다:

OpenAI

지식 기반 (knowledge-grounded) AI 애플리케이션과 엔터프라이즈 워크플로 (enterprise workflows) 전반에 걸쳐 검색 패턴 (retrieval patterns)을 광범위하게 사용합니다.

Microsoft

Azure AI 서비스와 엔터프라이즈 지식 플랫폼을 통해 검색 시스템을 통합합니다.

Google

검색, 엔터프라이즈 AI, 그리고 지식 관리 제품 전반에 검색 기술을 적용합니다.

Databricks

엔터프라이즈 데이터 인프라와 AI 애플리케이션을 위한 검색 파이프라인 (retrieval pipelines)에 집중합니다.

Anthropic

신뢰성을 높이고 환각 (hallucinations)을 줄이기 위한 실질적인 방법으로 검색 기반 아키텍처 (retrieval-based architectures)를 권장합니다.

GeekyAnts

GeekyAnts에서 발행한 엔지니어링 사례 연구는 전체 아키텍처를 재구축하지 않고 기존 애플리케이션에 AI를 통합하려는 조직을 위한 실질적인 RAG 구현 패턴을 강조해 왔습니다. 이들의 분석은 프로덕션 시스템을 위한 도구 옵션, 배포 고려 사항, 그리고 비용 트레이드오프 (cost trade-offs)에 대한 유용한 세부 분석을 제공합니다.

더 깊이 있는 아키텍처 분석에 관심이 있는 독자라면, 다음 기술 분석을 통해 RAG 통합 패턴, 도구 선택, 그리고 구현 비용을 더 자세히 살펴볼 수 있습니다:

https://geekyants.com/blog/how-to-integrate-rag-into-your-existing-application-architecture-tools-and-cost-breakdown

엔터프라이즈 AI의 미래는 더 많은 학습이 아니라, 더 나은 검색입니다

1년 전만 해도 많은 팀은 파인튜닝 (fine-tuning)이 엔터프라이즈 AI의 기본 경로가 될 것이라고 가정했습니다.

하지만 업계는 대체로 검색 우선 아키텍처 (retrieval-first architectures)로 이동했습니다.

이유는 간단합니다:

지식은 모델보다 더 빠르게 변하기 때문입니다.

RAG를 통해 조직은 대규모 모델을 반복적으로 재학습시키지 않고도 정보를 최신 상태로 유지하고, 독점 데이터에 대한 제어권을 유지하며, 응답 품질을 향상할 수 있습니다.

오늘날 AI를 구축하는 대부분의 애플리케이션 팀에게 문제는 더 이상 RAG를 사용할 것인가의 여부가 아닙니다.

진짜 질문은 사용자가 RAG의 존재를 전혀 눈치채지 못할 정도로 검색(retrieval)을 얼마나 효과적으로 구현할 것인가입니다.