[Production RAG] Day 5: RAG 운영 - 인덱스 갱신 전략과 파이프라인 모니터링

서론: 구축 후가 더 긴 여정이다

RAG 파이프라인을 한 번 만들고 끝나는 팀이 있다. 실제 운영에서는 문서가 바뀌고, 새 소스가 추가되고, 청크 전략을 개선해야 하고, 검색 품질이 조용히 저하된다. 구축보다 운영 설계가 더 중요한 이유다.

1. 인덱스 갱신 전략

1.1 전체 재구축 (Full Reindex)

모든 문서를 처음부터 다시 임베딩하고 인덱스를 교체한다.

장점: 단순, 일관성 보장
단점: 대규모 인덱스에서는 시간·비용이 큼
적합: 임베딩 모델 교체, 청킹 전략 변경 시

1.2 증분 갱신 (Incremental Update)

변경된 문서만 감지해 해당 청크를 삭제·추가한다.

변경 감지 방법:
  - 파일 수정 시간 비교
  - 문서 해시(MD5/SHA) 비교
  - 소스 시스템 변경 이벤트 (Webhook, CDC)

갱신 흐름:
  변경 감지 → 기존 청크 삭제 → 재청킹 → 재임베딩 → 인덱스 추가

증분 갱신은 속도와 비용 면에서 유리하지만, 삭제 누락 시 구버전 청크가 잔존할 수 있다.

1.3 갱신 주기 설계

소스 유형	권장 갱신 주기
실시간 문서 (뉴스, 로그)	스트리밍 또는 분 단위
업무 문서 (계약서, 정책)	일 단위 또는 변경 시 트리거
아카이브 문서	주 단위 또는 분기별

갱신 주기는 데이터 신선도 요건과 운영 비용의 균형으로 결정한다.

2. 인덱스 버전 관리

인덱스도 코드처럼 버전을 관리해야 한다.

인덱스 버전 메타데이터:
  - 청킹 전략 버전
  - 임베딩 모델 ID + 버전
  - 생성 시각
  - 포함 소스 목록 및 버전

Blue-Green 인덱스 배포:
  현재: index_v3 (서비스 중)
  신규: index_v4 (구축 중)
    └─ 평가 통과 → 트래픽 전환
    └─ 이상 시 → index_v3로 롤백

3. 파이프라인 모니터링

3.1 인덱싱 파이프라인

• 인덱싱 처리량 (문서/분)
• 임베딩 실패율
• 청크 수 이상 변화 (갑작스러운 감소는 삭제 오류 징후)
• 갱신 지연 (변경 발생 → 인덱스 반영까지 시간)

3.2 검색 파이프라인

• 검색 지연 p50/p95
• 회수 결과 수 이상 (0건 또는 기대 이하 빈도)
• 리랭킹 후 순위 변화율 (리랭킹 효과 측정)
• 캐시 히트율 (자주 묻는 질의에 캐싱 적용 시)

3.3 품질 드리프트 탐지

인덱스 변경 없이도 검색 품질이 저하될 수 있다. 정기 평가로 드리프트를 탐지한다.

주간 자동 평가 실행
  └─ 골든 테스트셋 → Context Recall, Faithfulness 측정
  └─ 기준선 대비 5% 이상 하락 → 알람
  └─ 원인 분석: 소스 문서 변경 / 임베딩 분포 변화

4. 운영 성숙도 체크

단계	기준
Level 1	수동 전체 재구축, 모니터링 없음
Level 2	증분 갱신, 기본 지연/에러 알람
Level 3	자동 품질 평가, Blue-Green 인덱스 배포
Level 4	드리프트 자동 탐지, 평가 파이프라인 CI 통합

5. 시리즈 종합 체크리스트

1. 문서 유형에 맞는 청킹 전략을 선택하고 오버랩을 설정했다.
2. 임베딩 모델 컨텍스트 길이와 청크 크기를 맞췄다.
3. 하이브리드 검색(벡터 + BM25)과 리랭킹을 파이프라인에 추가했다.
4. Faithfulness, Answer Relevance, Context Recall을 자동 측정한다.
5. 증분 갱신과 Blue-Green 인덱스 배포로 운영 연속성을 확보했다.

시리즈 마무리

Production RAG는 “검색하고 생성하는” 단순 파이프라인이 아니다.

청킹·임베딩·검색·리랭킹·평가·인덱스 운영 각각이 독립적인 엔지니어링 과제다. 이 중 하나가 약하면 전체 품질이 그 링크에 의해 제한된다. 각 단계를 측정하고, 실패 지점을 격리하고, 개선 루프를 자동화하는 것이 Production RAG의 핵심이다.