#지식베이스를 왜 정기 전량 재구축하면 안 되나

← 전체 목차 · 이전: 지식베이스 갱신 시 인덱스는 어떻게 동기화하나 · 다음: Claude Code는 왜 코드 검색에 RAG를 쓰지 않는가

표준 답은 "너무 느려서"가 아니다 — 그것은 성능만 답한 것이고 일관성을 답하지 않았다.

프로덕션급 RAG는 반드시 증분 색인을 해야 하며, 버전 + 상태 머신으로 다음 여섯 대상이 협동해 갱신되도록 보장해야 한다.

동기화되지 않을 때의 결과: 답변에 신구 자료가 뒤섞인다.

#핵심 답변: 증분 색인 + 버전 + 상태 머신

문서 하나가 업로드부터 "검색 가능"까지 가는 완전한 상태 사슬:

업로드 → 파싱 → 청킹 → 벡터화 → 요약 생성 → 권한 동기화 → 색인 커밋 → 가시성 전환 → 검색 가능

철칙: 어느 한 단계가 실패해도 반제품이 프로덕션 리콜에 들어가서는 안 된다.

#1층: 문서 버전 관리

• 수정할 때마다 반드시 새 document_version을 생성한다(v1.0 → v2.0).
• 조각 데이터도 반드시 version을 지녀야 한다(chunk_v1 / chunk_v2).
• 옛 벡터를 직접 덮어쓰는 것을 엄금한다.
• 그렇게 하지 않을 때의 결과: 답변 중인 요청이 절반은 구 조각, 절반은 신 조각을 리콜할 수 있다.
• 권장 방식: 새 버전 색인 구축이 완료된 뒤에 가시 버전을 전환하고, 구 버전은 리플레이와 책임 규명을 위해 일정 기간 보존한다.

#2층: 삭제와 권한 변경의 전파

삭제는 원본 파일을 지우면 끝이 아니며, 아래 다섯 곳을 모두 처리해야 한다.

1. 벡터 DB
2. 요약 캐시
3. 문답 캐시
4. 인용 기록
5. 평가 샘플

권한 변경은 더 민감하다. 직원 퇴사, 부서 권한 회수 시 검색 필터가 즉시 발효되어야 한다.

가점 요소: "갱신 시간 필드를 하나 추가한다"만 답하지 말고 삭제 전파와 권한 우선순위를 보탤 것.

#3층: 실패 복구(예외 큐)

세 가지 전형적 실패: Embedding 서비스 타임아웃 / OCR 실패 / 일부 페이지 파싱 불가.

• 처리 방식: 전부 예외 큐(Dead Letter Queue)로 보내고 조용히 건너뛰는 것을 엄금한다.
• 시스템이 운영에게 알려줄 수 있어야 할 세 가지:
  1. 어느 문서가 현재 검색 불가인가
  2. 원인이 무엇인가
  3. 사람의 처리가 필요한가
• 하지 않을 때의 결과: 사용자가 답을 찾지 못할 때 지식 결손인지 색인 실패인지조차 구분할 수 없다.

#4층: 조각 안정성(장·절 단위 앵커)

• 리스크: 문서에서 한 단락만 고쳤는데 재청킹이 발동해 조각이 완전히 달라져 다른 chunk가 생성된다.
• 실효 범위: 과거 인용, 캐시, 평가 샘플.
• 핵심 전략: 되도록 장·절 단위 앵커를 유지해 각 조각에 고유하고 안정적인 신원 좌표를 만든다.

효과: 재청킹 전후로 chunk의 ID가 일치하게 유지된다(예: 구 조각 #Sec-2.1 → 신 조각 #Sec-2.1). 다시 벡터화하더라도 신구 조각의 대응 관계를 알 수 있다.

#5층: 관측 가능성(진행 대시보드)

진행 대시보드가 보여줘야 할 다섯 지표:

상담원 원인 규명 3문: 문서가 이미 적재되었는가? 파싱에 실패했는가? 권한 때문에 보이지 않는가?

• 상담원이 "지식베이스에 없습니다"라고만 말해서는 안 된다.
• 이 능력이 RAG를 운영할 수 있는지 없는지를 직접 결정한다.

#일관성 모델의 답변 기조

• 좋은 제품 표현: 새 문서 업로드 후 **"색인 중이며 몇 분 후 문답 가능"**을 표시하는 편이, 사용자가 이미 발효되었다고 생각하는데 검색되지 않는 것보다 낫다.
• 중요 정책 갱신: 동기 발행이나 사람 확인을 거쳐 신구 버전 전환에 명확한 시점이 있도록 보장한다.

#프로덕션 함정: 내용 변화만 감시해서는 부족하다

• 증분 색인은 파일 내용 외에도 권한, 제목, 목차, 태그, 업무 상태를 감시해야 한다.
• 전형적 사고 시나리오: 문서 내용은 바뀌지 않았는데 권한이 "전원 열람 가능"에서 "부서 열람 가능"으로 바뀌었다. 벡터 색인의 metadata가 동기화되지 않으면 검색층이 여전히 옛 권한의 조각을 리콜할 수 있다.
• 위험한 점: 에러를 내지 않는다(침묵 실패). 그러나 곧바로 보안 사고가 된다.

#표준 답안

저는 지식베이스 색인을 증분 데이터 파이프라인으로 봅니다.

• 문서 버전, 조각 버전, 구축 상태, 원자적 전환으로 일관성을 보장하고
• 신규 / 수정 / 삭제 / 권한 변경이 모두 같은 이벤트 스트림을 타게 하며
• 실패는 재시도 가능한 큐로 보내고 구 버전을 리플레이용으로 보존합니다.

#핵심 통찰

1. "너무 느리다"는 성능 답변이고 "신구 혼용"이 정확성 답변이다 — "왜 X를 하면 안 되나"를 물을 때는 먼저 효율 제약인지 정확성 제약인지 구분할 것. 정확성 제약이야말로 시스템 설계 문제의 진짜 쟁점이다.
2. RAG 색인의 본질은 일회성 ETL이 아니라 하나의 데이터 파이프라인이다 — "지속 운행하는 파이프라인"으로 모델링하는 순간 버전, 상태 머신, 재시도 큐, 관측 가능성 같은 고전적 데이터 엔지니어링 수단을 전부 그대로 재사용할 수 있다.
3. 구축과 발행은 반드시 디커플링되어야 한다(원자적 전환) — "새 버전 색인 구축이 완료된 뒤에 가시 버전을 전환한다"는 것은 색인층에서의 블루-그린 배포다. 구축하면서 덮어쓰면 반은 새것 반은 옛것인 리콜이 필연적으로 발생한다.
4. 삭제가 가장 놓치기 쉬운 쓰기 확산이다 — 문서 한 편이 시스템 안에 6개 이상의 사본 형태(벡터, 요약 캐시, 문답 캐시, 인용 기록, 평가 샘플)로 존재하므로 삭제 조작은 전부로 팬아웃되어야 한다. 원본 파일만 지우는 것이 전형적인 "다 지웠나?" 함정이다.
5. 권한은 RAG의 일급 시민이지 필터 위의 패치가 아니다 — 권한 변경이 동기화되지 않으면 에러가 나지 않지만 곧바로 데이터 유출이다. 권한을 내용과 동급의 변경 소스로 취급해 같은 이벤트 스트림에 편입시켜야 한다.
6. 안정적인 조각 ID가 RAG 시스템의 "기본 키"다 — 안정적 앵커가 없으면 과거 인용, 평가셋, 캐시가 전부 재청킹과 함께 실효되어 시스템이 회귀 가능성을 잃는다. 앵커는 문서 구조(제목 경로 / 페이지 / 단락 번호 / 표 ID)에서 와야지 바이트 오프셋에서 오면 안 된다.
7. 설명 가능한 지연이 설명 불가능한 정확함보다 낫다 — "색인 중이며 몇 분 후 문답 가능" 같은 상태 노출은 시스템 일관성 문제를 제품 체감 문제로 전환하는 표준 수법이다.
8. 가장 위험한 버그는 에러를 내지 않는 버그다 — 파싱 실패를 조용히 건너뛰는 것, metadata 지연은 에러 로그에 남지 않으므로 능동적인 진행 대시보드와 원인 규명 절차로만 드러낼 수 있다.

#엔지니어링 실전 Tips

• 변경 소스를 빠짐없이: 감시 목록 = 파일 내용 + 권한 + 제목 + 목차 + 태그 + 업무 상태. 내용 변화의 webhook만 거는 것이 가장 흔한 누락이다.
• metadata와 벡터를 따로 갱신할 때 일관성 검사를 둘 것: 벡터 자체는 변하지 않았는데 권한 식별자가 바뀐 시나리오에는 독립된 metadata 동기 경로가 필요하며, "metadata 버전 < 문서 버전"인 조각에 경보를 걸 것.
• 운영을 위한 원인 규명 화면을 준비할 것: "문서가 이미 적재되었는가 / 파싱에 실패했는가 / 권한 때문에 보이지 않는가"를 상담원이 셀프로 조회할 수 있게 만들면 "지식베이스에 없습니다" 류의 무효 티켓이 뚜렷이 줄어든다.
• 평가셋은 chunk 내용이 아니라 앵커에 바인딩할 것: 그렇지 않으면 재청킹 때마다 평가셋을 다시 만들어야 해서 회귀 능력이 그대로 0이 된다.
• 상태 노출이 곧 제품이다: 색인 상태(색인 중 / 예상 몇 분)를 최종 사용자에게 노출하는 것이 일관성 문제를 수용 가능한 체감으로 바꾸는 저비용 방법이다.
• 중요 정책 계열 문서에는 동기 발행 / 사람 확인의 급행 차선을 열어 줄 것: 명확한 전환 시점으로 최종 일관성을 대체한다.
• 더 파고들 방향: 조각 안정성의 구체적 구현(Markdown / DOCX 개요 같은 구조화 파싱으로 안정적 앵커를 산출하는 법), 권한 모델과 벡터 DB의 결합 방식(metadata 필터링 vs 분리 인덱스 vs 조회 시 2차 인증), 증분 색인의 일관성 검증 수단(색인과 원본 라이브러리의 대사 작업, 드리프트 탐지), 평가셋의 문서 버전 진화에 따른 관리 방법.