검색 증강 생성(Retrieval-augmented generation)은 종종 간결한 다이어그램으로 소개됩니다:

documents -> embeddings -> vector database -> LLM

이는 유용한 시작점이지만, 아키텍처의 한 부분을 마치 전체 시스템처럼 보이게 만들 수 있습니다.

좋은 RAG 데이터베이스 설계는 벡터 저장소 이상의 것을 다루어야 합니다.

운영(production) 환경의 RAG 애플리케이션은 원본 문서 저장, 테넌트 경계 강제 적용, 정확한 제품 이름 찾기, 날짜별 필터링, 대화 기억하기, 오래된 콘텐츠 무효화, 여러 데이터 소스 결합, 그리고 최종 프롬프트를 토큰 예산 내에 유지하는 기능이 필요할 수도 있습니다.

어떤 데이터베이스도 단순히 임베딩을 저장한다고 해서 'RAG 데이터베이스'가 되지는 않습니다. 서로 다른 데이터베이스 모델들이 검색의 서로 다른 부분을 해결합니다.

본 기사에서는 RAG에서 관계형 데이터베이스(relational databases), 문서 데이터베이스(document databases), 캐시(caches), 전체 텍스트 검색 엔진(full-text search engines), 그리고 벡터 데이터베이스(vector databases)가 수행하는 역할을 살펴봅니다. 그런 다음 유사성만으로는 표현하기 어려운 검색 문제를 검토합니다. 즉, 애플리케이션이 중심점은 알지만 답변의 정확한 경계는 모를 때 유용한 컨텍스트 주변 영역을 찾는 것입니다.

실제 AI 사용 사례 중 이 패턴은 고객 지원, 영업용 비즈니스 효율성 AI 도구, 내부 지식 비서, AI 프로그래밍 자동화, 그리고 AI 에이전트 개발에서 나타납니다. 또한 접근 제어 및 출처의 신선도가 생성된 답변만큼 중요한 내부 데이터를 사용하는 AI 어시스턴트 개발에도 동일한 검색 질문들이 적용됩니다.

RAG 작동 방식—그리고 파인튜닝과의 차이점

RAG는 요청이 있을 때 외부 정보를 검색하여 선택된 증거를 모델의 컨텍스트에 배치합니다. 반면, 파인튜닝(fine-tuning)은 모델 가중치(model weights)를 변경합니다. 따라서 실질적인 RAG와 파인튜닝의 차이는 지식(knowledge)이 언제, 어디서 도입되는지에 관한 것입니다.

RAG는 지식이 모델 외부에 남아 있기 때문에 업데이트하거나, 인용하거나, 필터링하거나, 제거하는 것이 종종 더 쉽습니다. 파인튜닝은 동작 방식, 스타일 또는 학습된 패턴을 변경할 수 있지만, 자주 변경되는 문서 저장소의 편리한 대체재는 아닙니다.

RAG의 주요 장단점은 그러한 분리에서 비롯됩니다. RAG는 모델을 재학습시키지 않고도 최신 데이터와 비공개 소스를 사용할 수 있지만, 데이터 수집 (ingestion), 검색 (retrieval), 권한 관리 (permissions), 평가 (evaluation), 지연 시간 (latency) 및 운영 (operations) 작업이 추가됩니다. AI 생성 (generation) 방식이 어떻게 작동하는지 이해하는 것만으로는 충분하지 않습니다. 유창한 모델이라 할지라도 여전히 취약하거나, 오래되었거나, 권한이 없는 증거를 바탕으로 답변할 수 있기 때문입니다.

데이터베이스 유형 및 RAG 구축 방법

더 완전한 RAG 파이프라인은 다음과 같은 형태를 띱니다:

소스 데이터 (source data)
  -> 수집 및 정규화 (ingestion and normalization)
  -> 문서 및 메타데이터 저장 (document and metadata storage)
...

데이터베이스는 여러 단계에서 참여할 수 있습니다.

하나의 데이터베이스가 이러한 작업 중 여러 개를 수행할 수 있습니다. 테이블에 6개의 행이 나타난다고 해서 소규모 애플리케이션에 6개의 데이터베이스가 필요한 것은 아닙니다. 핵심은 저장 엔진 (storage engine)을 선택하기 전에 검색 (retrieval) 작업을 식별하는 것입니다. 유용한 데이터베이스 비교는 기능 개수 표가 아니라, 이러한 작업들을 기준으로 시작됩니다.

팀들이 RAG를 구축하는 방법을 연구할 때, 종종 임베딩 모델 (embedding model)이나 RAG 벡터 데이터베이스 (RAG vector database)부터 시작하곤 합니다. 더 안전한 순서는 신뢰할 수 있는 원천 (source of truth), 액세스 규칙 (access rules), 업데이트 프로세스 (update process), 정확한 필터 (exact filters), 후보 검색 방법 (candidate retrieval method), 그리고 평가 계획 (evaluation plan)을 먼저 식별하는 것입니다. 벡터 인덱스 (vector index)는 해당 설계의 한 구성 요소일 뿐입니다.

차이점을 구체화하기 위해, 우리가 교토를 위한 여행 비서를 구축한다고 가정해 보겠습니다. 이 비서는 랜드마크, 레스토랑, 문화 시설, 이벤트, 교통, 영업 시간, 예약 및 사용자 일정에 대한 정보를 저장합니다.

PostgreSQL 및 MySQL: 구조화된 진실과 정확한 관계

관계형 데이터베이스 (Relational databases)는 RAG 시스템 주변에서 권위 있는 애플리케이션 상태를 유지하기 위한 가장 의외성이 적은(가장 당연한) 장소인 경우가 많습니다.

여행 비서의 경우, 관계형 데이터베이스는 다음과 같은 정보를 저장할 수 있습니다:

• 사용자 및 계정;
• 예약 및 예약 정보;
• 저장된 장소 및 일정;
• 테넌트(tenant) 또는 조직 경계;
• 문서 버전 및 인입(ingestion) 상태;
• 권한 및 가시성 규칙;
• 구조화된 영업시간 및 접근성 필드.

SQL은 정확성이 정확한 관계에 의존할 때 특히 유용합니다. 만약 비공개 일정이 특정 사용자에게 속해 있거나, 문서가 테넌트 경계를 넘어서는 안 된다면, 해당 규칙은 임베딩 점수(embedding score)에 의존해서는 안 됩니다.

관계형 쿼리(relational query)를 통해 허용된 문서 ID를 먼저 선택할 수 있습니다. 그러면 RAG 파이프라인은 해당 문서들에 대해서만 순위를 매길 수 있습니다.

SELECT document_id
FROM travel_documents
WHERE city = 'Kyoto'
...

PostgreSQL은 또한 JSON, 전체 텍스트 검색(full-text search), 그리고 확장 기능(extension)을 지원합니다. pgvector 확장 기능을 사용하면 관계형 데이터 옆에 벡터를 보관할 수 있으며, 이는 초기 단계나 중간 규모의 RAG 애플리케이션에는 충분한 경우가 많습니다.

중요한 차이점은 벡터 컬럼을 추가한다고 해서 권한 설계, 문서 생명주기(lifecycle), 메타데이터, 후보 선택(candidate selection), 그리고 프롬프트 구성(prompt construction)의 필요성이 사라지는 것은 아니라는 점입니다.

MongoDB 및 문서 데이터베이스: 유연한 콘텐츠 레코드

인입된 항목이 이미 JSON 객체와 유사한 형태를 띠고 있고, 서로 다른 항목 유형이 각기 다른 필드를 가지고 있다면 문서 데이터베이스(document database)가 자연스럽게 적합합니다.

랜드마크 레코드는 이력, 이미지, 좌표, 영업시간을 포함할 수 있습니다. 레스토랑은 요리 유형, 가격대, 예약 규칙, 식단 옵션을 가질 수 있습니다. 이벤트는 시작 시간, 장소, 티켓 URL, 날씨 정책을 가질 수 있습니다.

{
  "kind": "restaurant",
  "name": "Example Cafe",
...

MongoDB 문서는 모든 항목 유형을 동일한 컬럼 세트에 강제로 맞추지 않고도 그러한 형태를 표현할 수 있습니다. 메타데이터와 원문 텍스트(source text)를 함께 저장할 수 있으며, 액세스 패턴(access patterns)이 알려진 경우 중첩된 필드(nested fields)에 인덱스를 지정할 수 있습니다.

하지만 유연성이 검색 설계(retrieval design)를 불필요하게 만드는 것은 아닙니다. 애플리케이션은 여전히 어떤 컬렉션(collection), 필드(fields), 필터(filters), 그리고 레코드(records)가 모델의 후보가 되어야 할지 결정해야 합니다.

익숙한 RDB 대 NoSQL의 차이점은 여기서도 여전히 중요합니다. 관계형 시스템(Relational systems)은 정확한 관계(relationships)와 제약 조건(constraints)에 집중하는 반면, 문서 데이터베이스(document databases)는 유연한 레코드 형태(record shapes)와 집계 지향적 액세스(aggregate-oriented access)에 집중합니다. 비즈니스 시스템의 경우, NoSQL 데이터베이스 선택 기준에는 단순히 유입되는 데이터가 JSON인지 여부뿐만 아니라 일관성(consistency), 권한 부여(authorization), 운영 기술(operational skills), 백업(backup), 그리고 마이그레이션(migration)이 포함되어야 합니다.

Redis: 단기 상태 및 반복 작업

Redis는 기본 문서 저장소(primary document store)가 아니더라도 RAG 주변에서 유용하게 사용될 수 있습니다.

일반적인 용도는 다음과 같습니다:

• 대화 세션 상태 (conversation session state)
• 캐싱된 검색 결과 (cached retrieval results)
• 속도 제한 (rate limits)
• 단기 에이전트 상태 (short-lived agent state)
• 작업 큐 (job queues)
• 중복 제거 키 (deduplication keys)
• 빈번하게 재사용되는 컨텍스트 파편 (frequently reused context fragments)

만약 많은 사용자가 동일한 명소에 대해 유사한 질문을 던진다면, 검증된 검색 결과를 캐싱하는 것이 전체 파이프라인(pipeline)을 다시 실행하는 것보다 비용이 저렴할 수 있습니다.

Redis는 영속성(persistence)과 여러 데이터 구조(data structures)를 지원하지만, 캐시에는 여전히 무효화 정책(invalidation policy)이 필요합니다. 여행 정보는 이를 명확하게 보여줍니다. 이벤트, 임시 폐쇄 또는 영업 시간에 대한 답변은 캐싱된 텍스트가 내부적으로 일관되더라도 틀릴 수 있습니다.

Redis documentation은 이를 단순한 키/값(key/value) 캐시 이상으로 설명하지만, RAG 아키텍처에서의 역할은 여전히 명시적으로 선택되어야 합니다.

OpenSearch: 단어, 필드, 그리고 필터의 중요성

임베딩 검색(Embedding search)은 어휘 검색(lexical search)을 대체할 수 없습니다.

사용자는 정확한 장소 이름, 열차 노선, 제품 코드, 법률 용어, 에러 메시지, 그리고 인용된 문구를 검색합니다. 모델은 관련 텍스트에 대해 유사한 임베딩(embeddings)을 생성할 수 있지만, 정확한 식별자(identifier)는 종종 어휘적 일치(lexical match)를 필요로 합니다.

OpenSearch는 다음과 같은 것들을 결합할 수 있습니다:

• 전체 텍스트 쿼리 (full-text queries);
• BM25 스타일의 어휘적 관련성 (BM25-style lexical relevance);
• 필드 필터 (field filters);
• 집계 (aggregations);
• 지리적 쿼리 (geographic queries);
• 벡터 검색 (vector search);
• 검색 중심의 대시보드 및 운영 도구 (search-oriented dashboards and operational tooling).

여행 어시스턴트의 경우, 다음과 같은 질문에 답할 수 있습니다:

영어

벡터 데이터베이스 (Vector database)의 유사도 검색 알고리즘, 인덱스 유형, 필터링 동작, 메모리 사용량 및 업데이트 패턴은 모두 결과에 영향을 미칩니다. Pinecone, Qdrant, pgvector 또는 OpenSearch 간의 RAG 벡터 DB 비교는 애플리케이션 자체의 코퍼스 (corpus)와 필터를 사용하여 수행해야 합니다. 권장되는 벡터 데이터베이스 목록은 워크로드 특화 평가 (workload-specific evaluation)를 대체할 수 없습니다.

## RAG 하이브리드 검색 (hybrid search): BM25, 벡터, 그리고 재순위화 (reranking)

키워드 검색 (Keyword retrieval)과 의미론적 검색 (semantic retrieval)은 상호 보완적입니다. RAG 하이브리드 검색 파이프라인은 BM25와 벡터 점수를 결합하여, 정확한 이름과 식별자를 유지하면서도 의미론적으로 관련된 문서를 여전히 발견할 수 있도록 할 수 있습니다.

메타데이터 및 권한 필터 (metadata and permission filters)
-> BM25 어휘 후보 (lexical candidates)

• 벡터 유사도 후보 (vector similarity candidates)
  ...

RAG 정확도 향상을 위해서는 단순히 1단계 결과 개수를 늘리는 것보다 재순위화 (rerank) 통합이 더 유용할 때가 많습니다. 1단계가 재현율 (recall)에 최적화되어 있는 동안, 재순위화 모델 (reranker)은 소수의 후보 세트를 더 세밀하게 검토할 수 있습니다.

RAG 청크 크기 (chunk size) 최적화 기술 또한 중요합니다. 작은 청크는 매칭 정밀도를 높일 수 있지만 주변 맥락을 잃을 수 있으며, 큰 청크는 컨텍스트 (context)를 보존하지만 더 많은 토큰을 소비하고 관련성을 희석시킬 수 있습니다. 적절한 청크 크기는 문서 구조, 검색 방법, 그리고 인용되어야 하는 단위에 따라 달라집니다.

LangChain 및 LlamaIndex와 같은 RAG 프레임워크는 로더 (loaders), 임베딩 (embeddings), 리트리버 (retrievers), 그리고 모델을 연결할 수 있습니다. LangChain RAG 설정 샘플을 통해 연결 방식을 보여줄 수는 있지만, 프레임워크가 애플리케이션의 올바른 권한 경계 (authorization boundary), 최신성 규칙 (freshness rule), 또는 후보 범위 (candidate scope)를 결정할 수는 없습니다.

내부 검색을 위한 오픈 소스 RAG 설정은 PostgreSQL, OpenSearch 또는 Qdrant, 로컬 모델, 그리고 오케스트레이션 프레임워크 (orchestration framework)를 결합할 수 있습니다. 셀프 호스팅 (Self-hosting)은 운영 방식과 프라이버시 경계를 변화시키지만, 동일한 검색 및 평가 결정의 필요성을 제거하지는 않습니다.

## RAG 정확도 향상 및 평가 지표 (evaluation metrics)

검색 품질 (retrieval quality)과 답변 품질 (answer quality)은 별도로 측정되어야 합니다. 유용한 RAG 평가 지표 (evaluation metrics)에는 다음이 포함됩니다:

- `k`에서의 재현율 (recall) 및 정밀도 (precision);
- 평균 역순위 (mean reciprocal rank) 또는 nDCG;
- 컨텍스트 관련성 (context relevance) 및 컨텍스트 정밀도 (context precision);
- 근거성 (groundedness) 또는 충실도 (faithfulness);
- 인용 정확성 (citation correctness);
- 답변 완결성 (answer completeness);
- 검색된 토큰 (retrieved tokens), 지연 시간 (latency), 그리고 요청당 비용 (cost per request).

Ragas와 같은 도구는 평가의 일부를 자동화하는 데 도움을 줄 수 있지만, 어떤 RAG 평가 도구나 튜토리얼도 모든 비즈니스 워크플로우에 대해 올바른 기대 답변 (expected answer)을 정의할 수는 없습니다. 실제 질문으로 구성된, 검토를 거친 작은 테스트 세트가 여전히 가치가 있습니다.

RAG 환각 (hallucination) 방지 조치에는 단순히 추가 문서를 더하는 것 이상의 것이 포함되어야 합니다. 더 강력한 조치로는 최신 소스 사용, 명시적 인용 (explicit citations), 권한 확인 (permission checks), 충돌 탐지 (conflict detection), 답변 거부 옵션 (option to abstain), 그리고 지식 베이스에 답변이 존재하지 않는 질문에 대한 테스트 등이 있습니다.

RAG 지식 베이스의 자동 업데이트에는 버전 관리 (versioning) 및 무효화 (invalidation)도 필요합니다. 파이프라인은 어떤 소스 리비전 (source revision)이 청크 (chunk)를 생성했는지, 언제 임베딩 (embedding)을 다시 구축해야 하는지, 그리고 삭제되거나 만료된 정보가 캐시 (cache)와 인덱스 (index)에서 어떻게 제거되는지를 알고 있어야 합니다.

## RAG 보안 조치 및 구현 비용