#신구 제도가 동시에 존재하면 어떻게 처리하는가 — 버전 재정의 전치

← 전체 목차 · 이전: 다중 홉 질문은 왜 절반만 답해오나 · 다음: 대량 제로 리콜은 어떻게 트러블슈팅하는가

기업 지식베이스에서 신구 제도가 병존할 때 의미 유사도로만 리콜하면 반드시 구 제도를 현행 규칙으로 설명하게 된다. 두 버전 모두 관련 있고 모두 권위 있게 쓰여 있기 때문이다.

피해야 할 답변: "최신 문서를 리콜한다"만 답하는 것. 이유: 최신 ≠ 적용, 최신 ≠ 이미 발효.

#진짜 쟁점: 메타데이터 거버넌스 + 답변 재정

핵심 판단: 기업 지식베이스에서 문서는 애초에 평등하지 않다.

#총론: 버전 재정을 검색층과 증거층으로 전치

1. 버전 정보를 텍스트에서 뽑아내 필터 가능·비교 가능·설명 가능한 메타데이터로 만든다.
2. 검색 시 사용자 시나리오로 적용 범위를 먼저 필터링한다.
3. 그다음 발효 시간 + 권위 계층으로 증거를 선택한다.
4. 충돌 시 버전 차이를 보여주고, 모델의 자유로운 추측을 금지한다.

#1단계: 적재 시 메타데이터 추출

추출해서 적재해야 할 9개 필드:

1. 제도 명칭
2. 버전 번호
3. 발행 일자
4. 발효 일자
5. 폐지 일자
6. 사용 조직
7. 주관 부서
8. 초안 여부
9. 날인 여부

전형적 장애 근인: 시스템이 본문만 저장하고 이 통제 필드들을 저장하지 않았다.

예 — 사용자가 "지금 경비 정산이 가능한가요?"라고 물을 때

#2단계: 검색 시 먼저 필터링하고 나서 재정렬

반면 사례: 사용자가 화남 지사 직원인데 본사 구 제도와 지사 신 제도를 모두 모델에 던져 스스로 판단하게 한다.

1단계: 메타데이터 필터   [조직] [시간] [문서 상태]
            ↓
2단계: 재정렬 모델        관련성 비교

핵심 정렬 원칙: 고위험 제도 문답에서 메타데이터 필터의 우선순위는 흔히 의미 유사도보다 높다.

#3단계: 충돌과 경과 기간 처리

실제 제도에서 흔한 경과 규정 형태:

• 특정 일자 이전은 구 규칙, 이후는 신 규칙.
• 기존 주문은 구 규칙, 신규 주문은 신 규칙.

피해야 할 답변: "최신 버전을 고른다"만 답하는 것. 적용성 판단을 말해야 한다.

#4단계: 시계열 가중과 업무 라인 격리

버전 재정을 "현행/폐기" 두 값으로만 나누면 또 다른 함정이 생긴다 — 폐기로 표시된 구 버전이 "전량 검색" 모드에서는 여전히 필요하고, 갓 발효된 신 버전이 모든 적중 시나리오에서 무조건 1순위인 것도 아니다. 그래서 이진 필터 위에 시계열 가중치를 얹는다.

핵심은 "기본은 엄격, 필요 시 개방" — 일상 검색은 좁게, 소급·감사는 명시적으로 열어 주는 구조다.

또 하나의 함정은 다중 업무 라인이다. 같은 개념이 부서마다 정의가 다를 때(예: "정산 기준일"의 뜻이 회계팀과 영업팀에서 다름), 조직 범위 필터만으로는 부족하다 — 권한역(업무영역) 단위로 검색 자체를 격리해야 하며, 업무역 라벨은 반드시 적재 시점에 조각에 새겨야 한다. 조회 시점에 의미 유사도로 업무역을 추측하게 두면 안 된다.

새 버전을 올릴 때도 "즉시 전환"은 위험하다. 버전 그레이스케일 + 일치성 대조로 전환을 검증 가능한 과정으로 만든다.

신 버전 색인 구축 완료
  ↓
일부 트래픽에만 신 버전 노출(그레이스케일)
  ↓
같은 질문 집합에 대한 신구 버전 답변을 자동 대조
  ↓
이상 발견 시 → 이전 안정 버전으로 자동 롤백
  ↓
이상 없으면 → 전량 전환

모니터링에 올려야 할 4지표: 갱신 성공률 / 답변 일치율 / 구 정보 리콜 비중 / 버전 충돌률. 이상 발생 시 자동 경보. 특히 "답변 일치율"과 "구 정보 리콜 비중"은 면접관이 지적한 두 현상(신구 충돌, 만료 정보 인용)에 직접 대응하는 지표이므로 다른 지표보다 우선 관측 대상이다.

#표준 답안

저는 적재 단계에서 발효 일자, 폐지 일자, 버전 번호, 조직 범위, 발행 상태를 추출하고, 검색 시 사용자 신원·시간·시나리오에 따라 먼저 필터링하며, 리콜·재정렬·생성 시 현행 유효 버전을 인용합니다. 경과 기간이나 충돌을 만나면 조건을 설명하고 추가 질문을 합니다. 이렇게 해야 RAG가 구 제도를 신 규칙으로 답하지 않습니다.

한 단계 위의 정리: 버전 문제는 Prompt로 완전히 해결할 수 있는 것이 아니라 지식베이스 거버넌스 문제다. 메타데이터 필터 / 권위 계층 / 경과 기간 / 충돌 처리 네 가지를 설명할 수 있어야 **"기업 RAG는 검색 엔진이 아니라 업무 기준을 지닌 문답 시스템"**임을 이해한 것이다.

#검수 방식과 프로덕션 모니터링

검수셋 구성: 동명 제도의 신 버전 vs 구 버전 / 부서별 버전 / 초안판 vs 정식판.

판정 규칙: 시스템이 답할 때 반드시 적용 시간과 적용 대상을 설명해야 한다. 다음 중 하나라도 나타나면 실패다.

• 구 버전을 인용해 현재 질문에 답함
• 초안을 정식 제도로 취급함

프로덕션 모니터링: 적중 문서의 버전 분포. 구 버전이 자주 리콜되면 → 필터 규칙과 문서 상태 라벨을 점검할 것.

#출시 점검과 회귀 테스트

모든 방안에는 세 가지 부속물이 필요하다: 관측 가능 지표 + 실패 샘플 + 롤백 동작.

아래 네 종류의 변경은 전부 같은 회귀 샘플 묶음으로 다시 돌려야 한다.

핵심 관측 지표 5종: 정확률 / 경로 안전 / 인용 품질 / 비용 / 지연.

프로덕션 클로즈드 루프: 실제 Trace 샘플링 → 실패 샘플 추출 → 평가셋에 환류. 단일 최종 답변이 보기 좋은지만 보지 말고 동종 작업이 전체적으로 더 안정적인지를 볼 것.

#핵심 통찰

1. 의미 유사도는 구조적으로 "유효성"을 표현할 수 없다 — 유사도가 재는 것은 "닮았는가"인데, 발효 여부는 불리언형 업무 사실이다. 답이 사실성 속성(시간, 조직, 상태)에 좌우되는 모든 문답은 벡터 거리가 아니라 구조화 필터로 해결해야 한다.
2. 문서는 애초에 평등하지 않다 — 이것이 기업 RAG와 개방 도메인 RAG의 분수령이다. 개방 도메인은 "관련되면 쓸 수 있다"고 가정할 수 있지만, 기업 도메인은 먼저 **"이 문서가 이 사람에게, 이 시각에 유효한가"**에 답해야 한다.
3. 재정은 전치해야지 모델에게 후치하면 안 된다 — 충돌을 LLM에게 던져 "스스로 판단"하게 하는 것이 가장 흔한 아키텍처 오류다. 검색층/증거층으로 전치해야 결과가 설명 가능하고, 감사 가능하고, 회귀 테스트 가능해진다.
4. "최신"은 서로 독립적인 세 개념의 혼동이다 — 최신(버전 번호가 큼), 적용(조직/시나리오 매칭), 발효(시간 창 안). 셋은 서로 독립적이며, 어느 하나의 차원으로만 정렬하는 모든 방안은 틀린다.
5. 메타데이터 추출의 실패점은 검색이 아니라 적재에 있다 — "본문만 저장하고 통제 필드를 버린 것"이 근인이다. 검색층을 아무리 최적화해도 적재 시 뽑지 않은 필드를 복원할 수는 없다.
6. 경과 기간 규정은 답이 확정값이 아니라 조건을 담을 것을 요구한다 — "특정 일자 이전은 구, 이후는 신"이란 정답 자체가 조건 표현식이라는 뜻이다. 시스템이 "X에 따라 다릅니다"를 출력하고 능동적으로 추가 질문하는 것을 허용하는 것은 체감 결함이 아니라 정확률의 일부다.
7. 재정할 수 없을 때 사람에게 인계하는 것도 정답의 한 형태다 — "충돌을 나열하고 사람에게 인계"를 시스템 능력 경계에 설계해 넣는 편이, 자신 있게 틀린 답을 억지로 주는 것보다 기업 컴플라이언스에 부합한다.
8. 평가는 단일 출력의 매끄러움이 아니라 동종 작업의 전체 안정성을 봐야 한다 — 단일 case의 인상은 오도되기 쉽고, 고정 회귀 샘플 + 5개 지표(정확률/경로 안전/인용 품질/비용/지연)라야 비교 가능한 기준이 된다.
9. "현행/폐기" 이진 상태만으로는 검색 모드의 다양성을 감당하지 못한다 — 일상 문답은 최신을 우선해야 하지만 소급 감사는 폐기본까지 봐야 한다. 하나의 필터 규칙으로 두 요구를 동시에 만족시키려 하면 결국 어느 한쪽이 희생된다. 검색 모드 자체를 파라미터화(최신판 우선/전량 검색/지정 버전 소급)하는 것이 정답이다.
10. 버전 전환은 일회성 스위치가 아니라 검증 가능한 과정이어야 한다 — 그레이스케일 + 신구 답변 자동 대조 + 이상 시 자동 롤백은, "배포"를 "구축이 끝나면 즉시 전환"에서 "검증을 통과해야 전환"으로 바꾼다. 이것은 15번 문서의 "구축과 발행 디커플링" 원칙을 버전 재정 시나리오에 그대로 적용한 것이다.

#엔지니어링 실전 Tips

• 버전 통제 필드를 점수 특징이 아니라 하드 필터 조건으로 만들 것: 발효 일자·폐지 일자·조직 범위는 벡터 검색의 전치 filter로 써야지, 재정렬 모델이 그것들을 "저울질"해 주기를 기대하면 안 된다.
• 「초안 여부」「날인 여부」 같은 승인 상태 필드를 반드시 적재할 것: 초안이 정식 제도로 답변되는 것은 기업 시나리오에서 위해가 가장 큰 실패 유형이며, 본문 내용만으로는 전혀 식별할 수 없다.
• 변경(Prompt 수정 / 모델 교체 / 검색 전략 교체 / 도구 설명 교체)마다 같은 회귀 샘플을 돌릴 것: 그렇지 않으면 어느 변경이 퇴보를 유발했는지 귀인할 수 없다.
• 방안마다 3종 세트를 갖출 것: 관측 가능 지표, 실패 샘플, 롤백 동작. 하나라도 빠지면 출시하지 말 것.
• 5개 지표를 함께 볼 것: 정확률만 최적화하면 비용과 지연의 악화를 대가로 치르는 경우가 많다.
• Trace 샘플링 → 실패 샘플 → 평가셋 환류의 클로즈드 루프를 구축할 것: 프로덕션의 실제 실패가 오프라인 평가셋을 지속적으로 보충하게 한다.
• 「적중 문서 버전 분포」 모니터링은 저비용 고신호 프로덕션 지표다: 구 버전 비중의 이상 상승은 거의 반드시 필터 규칙이나 상태 라벨의 문제에 대응한다.
• 업무역 라벨은 적재 시점에 새길 것, 조회 시점에 추측하지 말 것: 다중 업무 라인에서 같은 개념의 정의가 부서마다 다를 때, 의미 유사도로 업무역을 가려내려 하면 반드시 교차 오염이 생긴다. 조각 입고 시점에 업무역 필드를 명시적으로 부여하고, 조회 시점에는 권한역으로 직접 필터링할 것.
• 이력 버전은 강등하되 배제하지는 말 것: 최신판 우선 모드에서도 이력 버전을 완전히 걸러내면 "전량 버전 검색" 모드에서 적중할 방법이 없어진다. 가중치를 낮추는 것과 색인에서 빼는 것은 다른 조작이다.
• "답변 일치율"과 "구 정보 리콜 비중"을 1급 관측 지표로 둘 것: 이 둘은 면접관이 지적한 "신구 충돌 / 만료 정보 인용" 두 증상에 가장 직접 대응하므로, 갱신 성공률 같은 절차 지표보다 이상 탐지 신호로서 우선순위가 높다.
• 더 파고들 방향: 「권위 계층」을 비교 가능한 점수로 정량화(그룹 > 사업부 > 지사)해 일률적 사람 인계 대신 자동 재정 구현, 경과 기간 규정의 구조화 표현 설계(발효 구간 + 적용 대상 술어)로 조건식 답변 출력, 「구 버전 인용 / 초안을 정식으로 취급」 두 실패 유형을 자동화 레드팀 케이스로 만들어 CI에 연결, 시계열 가중치의 감쇠 함수 설계(업무별 지식 반감기에 따라 감쇠 속도를 달리할 것).