RAG 인덱싱 파이프라인은 단순한 배치 작업이 아닙니다. 문서가 들어오고, 정제되고, 청크로 분해되고, 임베딩이 생성되고, 벡터 DB에 들어가고, 다시 갱신되는 전체 흐름입니다. 이 흐름이 흔들리면 검색 품질도 같이 흔들립니다.
이 글에서는 문서 수집부터 재색인까지의 흐름을 어떻게 설계해야 하는지, 그리고 RAG Ops, RAG 데이터 신선도, Hybrid Search, 임베딩 모델 선택, 벡터 저장 비용과 어떤 식으로 연결되는지 정리합니다.
개요 #
RAG 인덱싱 파이프라인의 목표는 한 가지입니다. 원본 문서의 의미를 최대한 보존하면서, 검색과 재생성에 적합한 형태로 바꾸는 것입니다.
그래서 좋은 파이프라인은 단순히 데이터를 많이 넣는 구조가 아니라, 변경 감지와 버전 관리, 재임베딩, 백필, 품질 검증까지 포함합니다. 운영 단계에서 중요한 것은 “얼마나 빨리 넣는가"보다 “얼마나 일관되게 갱신하는가"입니다.
왜 중요한가 #
인덱싱이 불안정하면 RAG 전체가 흔들립니다.
- 최신 문서가 검색되지 않으면 답변이 오래된 상태로 남습니다.
- 청킹이 엉키면 임베딩은 맞는데 검색 컨텍스트가 깨집니다.
- 메타데이터가 부족하면 필터링과 라우팅이 약해집니다.
- 재색인 전략이 없으면 모델이나 스키마가 바뀔 때 전체를 다시 만들게 됩니다.
결국 인덱싱 파이프라인은 품질과 비용을 동시에 결정합니다. 검색 품질이 낮으면 사용자 경험이 무너지고, 재처리가 과하면 비용이 폭증합니다.
파이프라인 설계 #
실무에서는 보통 아래 순서로 설계합니다.
- 문서 소스를 수집합니다.
- HTML, PDF, Markdown, Office 파일을 정규화합니다.
- 제목, 섹션, 표, 코드 블록을 기준으로 청킹합니다.
- 임베딩 모델을 선택하고 벡터를 생성합니다.
- 문서 ID, 버전, 출처, 태그, 권한 정보를 메타데이터로 넣습니다.
- 벡터 DB에 upsert하고, 필요하면 백필 작업을 돌립니다.
이때 핵심은 임베딩 모델 선택과 Hybrid Search를 같이 봐야 한다는 점입니다. 청킹 단위와 임베딩 차원이 달라지면 인덱스 구조와 저장 비용도 같이 바뀝니다.
설계 선택 #
인덱싱 파이프라인은 보통 다음 선택지 중 하나로 정리됩니다.
- 실시간 push 방식 vs 주기적 batch 방식
- 전체 재색인 vs 증분 갱신
- 문서 단위 청킹 vs 섹션 단위 청킹
- 단일 인덱스 vs 도메인별 분리 인덱스
문서 변경이 잦고 SLA가 낮으면 증분 갱신이 유리합니다. 반대로 스키마가 바뀌었거나 임베딩 모델을 교체했다면 전체 재색인이 더 안전합니다. 이 판단은 RAG 데이터 신선도와 직접 연결됩니다.
아키텍처 도식 #
권장 아키텍처는 다음과 같습니다.
- Source connector가 문서를 수집합니다.
- Parser/Normalizer가 형식을 통일합니다.
- Chunking worker가 구조를 보존하며 분해합니다.
- Embedding worker가 모델 버전을 붙여 벡터를 만듭니다.
- Vector DB가 검색 인덱스를 유지합니다.
- Metadata store가 권한, 버전, 출처를 관리합니다.
여기서 중요한 점은 벡터 DB만 보지 말고 앞단의 문서 처리와 뒷단의 평가를 함께 보는 것입니다. RAG Ops 글에서 정리한 운영 지표를 여기에 붙이면 안정성이 올라갑니다.
체크리스트 #
- 문서 소스별로 수집 주기가 정의되어 있는가
- 문서 버전과 임베딩 버전이 함께 저장되는가
- 청킹 규칙이 문서 타입별로 다르게 정의되어 있는가
- 재색인 트리거가 명확한가
- 실패한 upsert를 다시 처리하는 백필 경로가 있는가
- 품질 검증용 샘플 쿼리가 준비되어 있는가
- 저장 비용과 인덱스 크기를 주기적으로 확인하는가
결론 #
RAG 인덱싱 파이프라인은 검색 시스템의 공급망입니다. 이 공급망이 안정적이어야 retrieval, reranking, generation이 의미를 가집니다. 문서를 빨리 넣는 것보다, 구조를 잃지 않고 계속 갱신하는 것이 더 중요합니다.