Teams가 RAG(Retrieval-Augmented Generation)를 데모에서 프로덕션 서비스로 전환할 때는 유용한 어시스턴트와 소음만 유발하는 어시스턴트를 가르는 몇 가지 결정에 직면하게 됩니다. 청킹(chunking), 임베딩 모델(embedding model), 벡터 스토어(vector store), 하이브리드 검색(hybrid search), 그리고 평가(evaluation)라는 다섯 가지 설계 선택이 실제 사용자가 경험하는 정밀도(precision), 재현율(recall), 지연 시간(latency)을 결정합니다.
프로토타입에서 프로덕션으로의 전환이 중요한 이유
대부분의 튜토리얼은 불과 수십 줄의 코드로 RAG 파이프라인을 실행하는 법을 알려주지만, 실제 트래픽을 처리하는 데 필요한 엔지니어링적 엄격함 단계에는 미치지 못합니다.
1. 청킹 전략 – 첫 번째 품질 관문
청크 크기가 가장 중요합니다. 청크가 너무 크면 관련 없는 텍스트가 섞여 신호가 희석되고, 너무 작으면 모델이 일관된 답변을 생성하는 데 필요한 주변 문맥이 사라집니다. 고정 크기 분할(Fixed-size splitting)은 소스 자료의 자연스러운 구조를 무시합니다.
실무적인 가이드라인
- 논리적 경계에서 분할하세요: 문서의 헤더, 기사의 문단 구분, 코드의 함수 정의 등.
- 정밀한 검색이 가능하도록 청크를 충분히 작게 유지하되, LLM의 생성 단계에서는 더 큰 상위 섹션(parent section)을 유지하세요. 이러한 “부모-자식(parent-child)” 패턴을 사용하면 검색기는 정확한 스니펫을 찾아내고, 생성기는 사실 관계를 유지할 수 있을 만큼 충분한 문맥을 확보할 수 있습니다.
2. 임베딩 모델 – 유사도를 판단하는 방식
임베딩 모델은 텍스트를 유사도 검색 엔진이 비교할 수 있는 벡터로 변환합니다. OpenAI의 text-embedding-3-large와 같은 강력한 범용 모델은 대부분의 도메인에서 견고한 기준점이 됩니다. 만약 코퍼스(corpus)가 법률 의견서, 의료 기록, 기술 사양서와 같이 매우 전문적인 분야라면, 반드시 자체 데이터에서 실질적인 성능 향상을 측정한 후에 도메인 특화 모델을 테스트하십시오.
교체 시점
- 애플리케이션에 중요한 관련성 점수(예: 문맥 정밀도 향상)에서 측정 가능한 이득이 확인될 때만 교체하세요.
3. 벡터 데이터베이스 – 스토어 확장하기
기존 인프라와 예상되는 벡터 수에 적합한 벡터 스토어를 선택하세요.
- pgvector는 PostgreSQL 내부에서 실행되며 약 100만 개의 벡터까지 안정적으로 처리합니다. 이미 관계형 데이터베이스를 운영 중이며 유지보수가 적은 솔루션을 찾는 팀에 이상적입니다.
- Qdrant는 100만~1억 개 범위에서 탁월한 성능을 발휘하며, 대규모 코퍼스에 대해 더 높은 처리량과 낮은 지연 시간을 제공합니다.
- Pinecone은 완전 관리형 클라우드 서비스를 제공하여 자체 호스팅에 따른 운영 부담을 제거합니다.
4. 하이브리드 검색 및 리랭킹 – 의미와 정확성의 균형
순수 벡터 검색은 의미적 유사성에는 뛰어나지만, 사용자가 기대하는 정확한 키워드 일치를 놓칠 수 있습니다. 하이브리드 검색은 벡터 인덱스 위에 전통적인 BM25 키워드 인덱스를 계층화한 다음, 두 결과 목록을 융합합니다. 상호 순위 결합(Reciprocal Rank Fusion, RRF)은 각 후보의 두 목록 내 순위를 기반으로 점수를 할당하고 이를 결합하여, 어느 한 쪽에서라도 상위에 나타나는 항목의 순위를 높입니다.
리랭킹(Reranking)은 마지막 정밀도 필터를 추가합니다. 하이브리드 검색 후, 상위 N개(통상 50개)의 후보를 쿼리-문서 쌍을 공동으로 점수화하는 모델인 크로스 인코더(cross-encoder)에 전달합니다. 크로스 인코더의 점수가 기존의 유사도 수치를 대체하여, LLM에 전달하기 전에 가장 관련성이 높은 청크를 선택할 수 있게 해줍니다. 이 추가 단계는 특히 길거나 노이즈가 많은 코퍼스에서 답변 품질을 눈에 띄게 향상시키는 경우가 많습니다.
5. 평가 및 답변 거부 – 중요한 지표 측정하기
측정하지 않는 시스템은 개선할 수 없습니다. RAGAS 프레임워크는 RAG 파이프라인의 건전성을 종합적으로 파악할 수 있는 네 가지 지표를 제안합니다:
- Context Precision (문맥 정밀도) – 검색된 청크 중 실제로 정답을 포함하고 있는 비율.
- Context Recall (문맥 재현율) – 검색되어야 할 모든 관련 청크 중 실제로 검색된 비율.
- Faithfulness (충실도) – 생성된 답변이 환각(hallucination)을 피하고 검색된 문맥 내에 머무르는 정도.
- Answer Relevance (답변 관련성) – 최종 답변이 원래의 질문을 얼마나 잘 충족하는지 여부.
프로덕션 트래픽을 반영하는 순환 테스트 세트(rolling test set)를 통해 이러한 지표를 추적하세요.
마지막으로 자주 간과되는 안전장치는 **답변 거부(abstention)**입니다. 모델이 낮은 확신도로 답변하도록 강제하는 대신, 충실도나 관련성 점수에 임계값을 설정하여 “잘 모르겠습니다”라는 응답을 트리거하도록 하세요. 사용자는 확신에 차 있지만 틀린 답변보다 명확한 불확실성 인정을 선호하며, 이러한 폴백(fallback) 방식은 사후 지원 비용을 줄여줍니다.
이 다섯 가지 영역을 단순히 한 번 설정하고 잊어버리는 구성 요소가 아니라, 지속적인 의사 결정 지점으로 다룬다면 RAG를 화려한 데모에서 신뢰할 수 있는 프로덕션 서비스로 전환할 수 있습니다. 그 결과로 얻는 보상은 빠르게 답변하고, 주제를 벗어나지 않으며, 침묵해야 할 때를 아는 시스템입니다.