프로덕션 환경에서의 RAG 아키텍처: 품질을 실제로 결정짓는 결정 요소들

By Ama Senevirathne | Full-Stack Engineer | .NET / Angular / Agentic AI

Tags: rag, ai, software-architecture, llm, dotnet, vector-databases, information-retrieval

읽기 시간: 약 14분

검색 증강 생성 (Retrieval-Augmented Generation, RAG)은 모델을 미세 조정 (Fine-tuning)하거나 전체 코퍼스 (Corpus)를 컨텍스트 윈도우 (Context window)에 억지로 밀어 넣지 않고도, 내부 문서, 제품 지식 베이스, 코드베이스, 고객 기록과 같은 사용자의 자체 데이터에 대해 LLM (Large Language Model)에게 질문할 수 있게 해주는 아키텍처입니다.

개념은 간단합니다. 응답을 생성하기 전에 관련 문서를 검색(Retrieve)하고, 이를 컨텍스트(Context)에 포함하며, 학습 데이터의 근사치가 아닌 실제 증거를 바탕으로 생성하는 것입니다.

구현은 간단하지 않습니다. 대부분의 팀은 데모 단계에서 RAG가 작동하도록 비교적 빠르게 구현해냅니다. 하지만 그 후 대부분의 팀은 "데모에서 작동하는 것"과 "프로덕션 품질 수준에서 신뢰할 수 있는 것" 사이에는 튜토리얼에서 다루지 않는 일련의 명확하지 않은 결정 사항들이 존재한다는 사실을 깨닫게 됩니다. 튜토리얼은 사용자가 시스템을 신뢰할지 여부를 결정하는 정밀도 (Precision), 재현율 (Recall), 지연 시간 (Latency) 특성을 위해 최적화된 것이 아니라, 20줄의 코드로 작동하는 프로토타입을 만드는 데 최적화되어 있기 때문입니다.

이 글은 그러한 결정 사항들을 다룹니다. 여기에 담긴 모든 내용은 제가 직접 구축하거나 검토한 시스템에 근거하고 있으며, 직접 읽어볼 가치가 있는 증거가 있는 경우 1차 출처를 참조합니다.

아키텍처 개요

RAG 파이프라인은 세 가지 뚜렷한 단계로 구성됩니다:

Ingestion Pipeline (오프라인)
    │
    ├── Load documents
...

각 단계에는 최종 품질을 절반으로 떨어뜨리거나 두 배로 높일 수 있는 최소 하나 이상의 결정 사항이 있습니다. 순서대로 살펴보겠습니다.

1단계: 청킹 (Chunking) — 전체 파이프라인에서 가장 영향력이 큰 결정

청킹 (Chunking)은 소스 문서를 저장 및 검색될 단위로 나누는 과정입니다. 이는 RAG 시스템에서 단일 결정 사항 중 가장 영향력이 큽니다. 청크가 너무 크면 관련 신호(signal)가 노이즈에 묻혀버리고, 청크가 너무 작으면 신호에 의미를 부여하는 문맥(context)을 잃어버리기 때문입니다.

고정 크기 청킹 (Fixed-size chunking)

M 토큰의 중첩(overlap)을 두어 매 N 토큰마다 분할합니다. 구현과 논리적 추론이 간단합니다. 문서가 균질할 때(밀집된 산문, 구조화된 보고서 등)는 어느 정도 효과적입니다. 하지만 문서의 콘텐츠 유형이 섞여 있을 때는 실패합니다 (예: 코드 블록, 산문 설명, 표가 포함된 README 파일은 이 세 가지 요소가 임의로 분할됩니다).

중첩(overlap) 파라미터는 중요한 콘텐츠가 두 청크 사이의 간극에 빠지는 것을 방지하기 위해 존재합니다. 합리적인 시작점은 20% 중첩입니다. 512 토큰 크기의 청크라면, 인접한 청크 사이에 약 100 토큰의 공유 문맥이 존재하게 됩니다.

구조 인식 청킹 (Structure-aware chunking)

문서의 구조를 파싱하여 문단, 섹션, 함수, 클래스와 같은 의미론적 경계(semantic boundaries)에서 청킹합니다. Markdown의 경우 헤더(header)를 기준으로 분할합니다. 코드의 경우 함수 또는 클래스 정의를 기준으로 분할합니다. HTML의 경우 <section> 또는 <article> 요소를 기준으로 분할합니다.

이 방식은 거의 항상 고정 크기 청킹보다 우수합니다. 다만, 형식별로 특화된 파서(parser)가 필요하다는 비용이 발생합니다. 혼합 형식의 코퍼스(corpus)를 다룰 때는 여러 전략과 형식 감지(format-detection) 단계가 필요합니다.

부모-자식 청크 패턴 (The parent-child chunk pattern)

각 청크에 대해 두 가지 표현 방식을 저장합니다. 검색 정밀도를 위한 작은 청크(small chunk)와, 생성(generation)을 위해 LLM에 전달될 더 큰 부모 청크(parent chunk, 작은 청크가 속한 섹션)입니다. 작은 청크로 검색하고, 부모 청크로 생성합니다.

이 조합 — 정밀한 검색과 풍부한 생성 문맥 — 은 검색 품질과 생성 품질 사이의 핵심적인 긴장 관계를 해결합니다. 작은 청크는 올바른 구절을 검색하고, 큰 청크는 LLM이 질문에 일관성 있게 답변할 수 있도록 충분한 문맥을 제공합니다.

저는 프로덕션 환경에서 이 패턴을 사용합니다. 인덱스 저장 공간이 더 많이 들지만(각 청크의 두 가지 복사본), 사소하지 않은 규모의 코퍼스(corpus)라면 품질 향상의 가치가 충분합니다.

실용적인 기본값:

• 검색용 청크 (Retrieval chunk): 256–512 토큰, 10–20% 중첩 (overlap)
• 부모 청크 (Parent chunk): 전체 섹션 (1,000–2,000 토큰)
• 소스 문서 ID, 섹션 제목, 청크 위치를 항상 메타데이터 (metadata)로 저장

2단계: 임베딩 모델 선택 (Embedding Model Selection)

임베딩 모델은 텍스트를 벡터 (vector)로 변환합니다. 검색 (Retrieval)은 임베딩 공간 (embedding space)에서 쿼리 벡터 (query vector)와 가장 가까운 인덱스 내 벡터를 찾는 방식으로 작동합니다. 만약 모델이 정의하는 "유사성 (similarity)"이 귀하의 도메인이 정의하는 "관련성 (relevance)"과 일치하지 않는다면, 이후의 어떤 단계도 이를 보완할 수 없습니다.

범용 임베딩 vs 도메인 특화 임베딩

OpenAI의 text-embedding-3-large와 Cohere의 embed-multilingual-v3.0은 현재 영어에 대한 범용 벤치마크 (benchmark) 모델입니다. 이들은 다양한 코퍼스 (corpora)에서 우수한 성능을 보입니다. 의료, 법률, 코드, 금융과 같은 도메인 특화 코퍼스의 경우, 도메인 학습된 모델이 도메인 내 검색 작업에서 범용 모델보다 일관되게 높은 성능을 보이며, BEIR와 같은 벤치마크에서 종종 상당한 차이로 앞섭니다.

권장 사항: text-embedding-3-large 또는 그에 상응하는 오픈 소스 모델(Hugging Face에서 사용 가능하며 직접 호스팅할 수 있는 Beijing Academy of AI의 bge-large-en-v1.5)로 시작하십시오. 먼저 검색 품질의 베이스라인 (baseline)을 설정하세요. 그런 다음 실제 쿼리의 대표 샘플을 사용하여 해당 베이스라인과 도메인 특화 임베딩을 비교 평가하십시오. 도메인 특화 모델이 더 관련성 있게 들린다는 이유 때문이 아니라, 실제로 성능 향상이 측정될 때만 교체하십시오.

차원 (Dimensionality)

고차원 임베딩은 일반적으로 더 많은 정보를 인코딩하지만, 더 많은 저장 공간과 연산량을 요구합니다. text-embedding-3-large는 기본적으로 1,536 차원을 지원하며 최대 3,072 차원까지 지원합니다. 대부분의 프로덕션 시스템에서는 1,536 차원이 적절한 균형점입니다. 엄격한 비용 제약이 있는 대규모 환경을 운영 중이라면, 성능이 좋은 범용 모델을 사용하는 512 차원도 경쟁력이 있습니다.

실용적인 기본값 (Practical default): 대부분의 영어 말뭉치(English-language corpora)의 경우 1,536 차원의 text-embedding-3-large를 사용합니다. 비용에 민감한 배포 환경이라면 bge-large-en-v1.5를 셀프 호스팅(Self-host) 하세요.

3단계: 벡터 스토어(Vector Store) 선택

벡터 스토어는 임베딩(Embedding)을 인덱싱하고 근사 최근접 이웃 (ANN, Approximate Nearest-Neighbour) 쿼리를 처리합니다. 핵심 성능 파라미터는 다음과 같습니다:

• Recall@K: ANN 인덱스가 실제 상위 K개의 문서 중 어느 정도의 비율을 반환하는가? Recall이 0.95라면 매 쿼리마다 실제 관련 문서의 5%를 놓친다는 의미이며, 이러한 손실은 파이프라인 전체에 걸쳐 누적됩니다.
• p99 기준 QPS: 애플리케이션이 수용 가능한 99번째 백분위수(99th-percentile) 지연 시간(Latency)에서 초당 몇 개의 쿼리(QPS, Queries Per Second)를 처리할 수 있는가?
• 인덱스 구축 시간 및 비용: 빈번한 재인덱싱(Re-indexing)이 필요한 대규모 말뭉치의 경우 이 요소가 중요합니다.

옵션 비교 (요약)

pgvector: PostgreSQL 확장 기능입니다. 이미 Postgres를 운영 중이라면 약 100만 개(1M)의 벡터까지는 이것이 적절한 시작점입니다. pgvector 0.5.0에서 추가된 HNSW 인덱스는 Recall과 쿼리 성능을 실질적으로 개선했습니다. 운영 측면에서는 관리해야 할 시스템이 하나로 통합됩니다. 트레이드오프(Tradeoff)로는, pgvector를 대규모로 운영할 경우 세심한 튜닝이 필요하며, 벡터 전용 데이터베이스의 순수 QPS 성능에는 미치지 못합니다.

Qdrant: HNSW 인덱싱, 페이로드 필터링(Payload filtering), 온디스크 인덱싱(On-disk indexing) 지원을 갖춘 벡터 전용 데이터베이스입니다. pgvector가 부담스러워지기 시작하는 100만 개에서 1억 개(1M–100M) 사이의 벡터 규모를 가진 말뭉치에 좋은 선택입니다. Rust 기반으로 높은 QPS와 뛰어난 필터링 성능을 제공합니다. 셀프 호스팅 또는 관리형 클라우드(Managed cloud)로 이용 가능합니다.

Pinecone: 관리형 클라우드 벡터 데이터베이스로, 셀프 호스팅을 원하지 않는 경우 가장 운영이 간편한 경로입니다. 운영의 단순함이 비용 프리미엄보다 중요한 팀에게 적합합니다. 오픈 소스가 아닙니다.

Weaviate: 멀티모달 임베딩(Multimodal embeddings), 내장된 BM25 하이브리드 검색(Hybrid search), 그리고 GraphQL 쿼리 인터페이스를 지원합니다. 하이브리드 검색을 핵심 기능(First-class feature)으로 필요로 하는 팀에게 적합합니다.

대부분의 .NET 프로젝트를 위한 저의 권장 사항: 우선 (이미 인프라에 포함되어 있는) pgvector로 시작하고, 코퍼스(Corpus)가 약 50만 개 이상의 벡터를 초과하거나 쿼리 지연 시간(Query latency)이 제약 사항이 될 때 Qdrant로 업그레이드하십시오.

4단계: 하이브리드 검색 (Hybrid Search) — 벡터 전용 검색이 특정 카테고리를 놓치는 이유

벡터 유사도 검색(Vector similarity retrieval)은 의미론적 매칭(Semantic matching)에 능숙합니다. 예를 들어, "취소 정책은 무엇인가요?"라는 질문은 "정책"이라는 단어를 사용하지 않더라도 취소에 관한 청크(Chunk)들을 찾아냅니다. 하지만 정확한 일치 검색(Exact-match retrieval)에는 취약합니다. "RFC 2119에서 MUST에 대해 무엇이라고 말하나요?"와 같은 질문은 BM25 키워드 매칭이 필요합니다. "RFC 2119"라는 용어는 매우 구체적이어서 다른 문서와의 의미론적 근접성(Semantic proximity)이 무의미하기 때문입니다.

하이브리드 검색은 벡터 유사도와 BM25 키워드 검색을 결합한 다음, 재순위화(Reranking)를 수행하기 전에 두 개의 순위 목록을 융합(Fuse)합니다.

표준적인 융합 방식은 상호 순위 융합 (Reciprocal Rank Fusion, RRF)입니다:

score(doc) = Σ 1 / (k + rank(doc, result_list))

여기서 k는 매우 높은 순위의 영향력을 완화하는 상수(일반적으로 60)입니다. RRF는 단순하고 견고하며, 두 결과 집합 사이의 가중치를 조정할 필요가 없다는 장점이 있습니다. 이는 가중 선형 결합(Weighted linear combination) 방식에 비해 가지는 주요 이점입니다.

실제 구현: Elasticsearch를 통한 BM25 또는 경량 라이브러리(Python의 BM25Okapi, 또는 완전히 통합된 배포를 위한 Postgres의 pg_trgm + ts_vector)를 사용하십시오. 그 후 RRF로 융합합니다. Weaviate나 OpenSearch의 경우, 하이브리드 검색은 기본 API 기능(First-class API feature)으로 제공됩니다.

5단계: 재순위화 (Reranking)

검색(벡터 + BM25 + RRF) 이후에는 후보 청크(Candidate chunks) 집합을 얻게 됩니다. 재순위화는 각 (쿼리, 청크) 쌍에 대해 크로스 인코더(Cross-encoder) 모델을 실행하여 관련성 점수를 생성합니다. 크로스 인코더는 텍스트를 독립적으로 인코딩하는 대신 두 텍스트를 동시에 확인하기 때문에, 임베딩 거리(Embedding distance)나 BM25 점수보다 더 정확한 관련성 점수를 산출합니다.

Cross-encoders는 계산 비용이 많이 듭니다. 전체 인덱스(index)를 대상으로 실행하기에는 너무 비쌉니다. 표준적인 패턴은 bi-encoder 검색(빠르고 근사적인 방식)을 먼저 수행한 후, 상위 50개 또는 100개의 후보군에 대해 cross-encoder 재순위화 (reranking, 더 느리지만 정확한 방식)를 수행하는 것입니다.

우수한 Cross-encoders 예시: Cohere Rerank (관리형 API), cross-encoder/ms-marco-MiniLM-L-12-v2 (오픈 소스, Hugging Face), Flashrank (저지연 재순위화를 위해 구축된 경량 모델).

재순위화 단계를 추가함으로써 얻는 개선 효과는 프로덕션 시스템에서 일관되게 유의미합니다. BEIR 벤치마크에 따르면, cross-encoder를 사용한 재순위화는 작업에 따라 밀집 검색 (dense retrieval)만 사용했을 때보다 nDCG@10을 5~15포인트 향상시킵니다. 지연 시간(latency) 비용은 실제로 발생하지만, 재순위화를 상위 N개의 후보군으로 제한(gate)한다면 관리 가능한 수준입니다.

6단계: 컨텍스트 구성 및 프롬프트 아키텍처 (Context Composition and Prompt Architecture)

이제 상위 K개의 관련 청크(chunks)를 확보했습니다. 이 청크들을 LLM 프롬프트에 어떻게 구성하느냐는 검색 품질만큼이나 생성 품질을 결정짓는 중요한 요소입니다.

컨텍스트 창 예산 편성 (Context window budgeting)

컨텍스트 창(context window)을 의도적으로 할당하십시오:

• 시스템 지침 (System instructions): ~500 토큰
• 검색된 컨텍스트 (Retrieved context): 남은 예산의 60–70%
• 대화 기록 (Conversation history, 멀티턴용): 10–15%
• 쿼리 + 출력 공간 (Query + output space): 나머지

창 제한(window limit)에 도달할 때까지 모든 청크를 단순히 이어 붙이지 마십시오. 관련성 점수(relevance score)를 기준으로 내림차순 정렬하십시오. 들어갈 수 있는 양보다 청크가 더 많다면, 순위가 가장 높은 것들을 우선적으로 선택하십시오.

근거 제시 지침 (Grounding instructions)

모델이 제공된 컨텍스트를 바탕으로 답변하도록 유도하는 명시적인 지침을 시스템 프롬프트에 포함하십시오:

아래 컨텍스트 섹션에 제공된 정보만을 사용하여 질문에 답하세요.
만약 컨텍스트에 질문에 답하기 위한 충분한 정보가 없다면, 
...를 통해 추론하지 말고 "이 질문에 답변하기 위한 충분한 정보가 없습니다"라고 말하세요.

이것이 환각 (hallucination)을 완전히 방지할 수는 없습니다. 적대적인 조건(adversarial conditions) 하에서 모델이 항상 이 지침을 따르는 것은 아니기 때문입니다. 하지만 일반적인 사용 환경에서는 꾸며낸 답변(confabulated answers)을 실질적으로 줄여줍니다.

인용 형식 (Citation format)

중요도가 높은 애플리케이션의 경우, 모델이 출처를 인용하도록 지시하십시오:

각 주장 뒤에 [출처: <제목>, <섹션>] 형식으로 소스 문서를 인용하십시오.

제공하는 컨텍스트(context)에 소스 메타데이터(문서 제목, 섹션, 가능한 경우 URL)를 포함하십시오. 모델은 당신이 제공한 소스만을 인용할 수 있습니다.

7단계: 기권 (Abstention) 및 신뢰도 임계값 (Confidence Thresholds)

관련 정보가 없을 때 자신 있게 답변하는 RAG 시스템은 "모릅니다"라고 말하는 시스템보다 더 위험합니다. 기권(Abstention) — 즉, 답변하지 않기로 선택하는 것 — 은 많은 경우에 올바른 답변입니다.

실질적인 기권 신호:

1. 검색 신뢰도 임계값 (Retrieval confidence threshold): 검색된 최상위 청크(chunk)의 코사인 유사도(cosine similarity)가 임계값(예: 0.7) 미만인 경우, "낮은 신뢰도" 플래그를 표시하거나 기권합니다.
2. 컨텍스트 부재 감지 (No-context detection): 검색된 청크에 쿼리(query)에 포함된 개체명(named entities)이 전혀 포함되어 있지 않다면, 이는 검색 실패의 신호입니다.
3. 모델 수준의 불확실성 (Model-level uncertainty): 컨텍스트가 불충분할 때, 모델이 신뢰도가 낮은 응답 앞에 "사용 가능한 정보에 따르면..."이라는 접두사를 붙이도록 지시하고, "이 주제에 대한 신뢰할 수 있는 정보가 없습니다"라며 기권하도록 합니다.