3.5.3 정답지 버전 관리(Versioning)와 생명주기

소프트웨어 공학에서 ’정답(Ground Truth)’은 영원불멸의 진리가 아니다. 비즈니스 환경의 변화, 정책의 갱신, 심지어 사회적 합의의 이동에 따라 어제의 정답은 오늘의 오답이 된다. 만약 오라클(Oracle)이 사용하는 골든 데이터셋(Golden Dataset)이 한 번 구축된 후 갱신되지 않는다면, 그 오라클은 언어 모델의 발전된 응답을 도리어 ’틀렸다’고 채점하는 레거시의 덫이 되어버린다.

따라서 결정론적 정답지는 소스 코드와 동일한 수준의 엄격한 **‘버전 관리(Versioning)’**와 지속적인 ‘생명주기(Lifecycle)’ 통제 하에 놓여야 한다.

1. 데이터 드리프트(Data Drift)와 정답지의 노후화

골든 데이터셋은 시간이 지남에 따라 필연적으로 현실의 비즈니스 룰과 괴리되는 ‘데이터 드리프트(Data Drift)’ 현상을 겪는다.

• 정책 변화: “환불 수수료는 1,000원이다“라는 정답을 구축해 두었으나, 올해부터 정책이 변경되어 수수료가 1,500원으로 올랐다면, 기존 정답지는 STALE(만료됨) 상태가 된다.
• 방치된 정답지의 위험성: 정책이 변경되었음에도 오라클의 정답지가 업데이트되지 않으면, AI 챗봇이 RAG를 통해 올바른 ’1,500원’을 대답하더라도, 오라클은 기존 정답(1,000원)과 다르다는 이유로 배포 파이프라인(CI/CD)을 Fail 처리해 버린다. 이는 개발자들로 하여금 오라클의 평가 결과 자체를 불신하게 만드는 최악의 안티 패턴(Anti-pattern)이다.

2. Git 기반의 데이터셋 형상 관리 전략

정답지는 단순히 엑셀 파일 형태로 공유 폴더에 존재해서는 안 된다. 시스템의 코드 형상 관리와 완벽하게 동기화되기 위해, 데이터셋 역시 선언적 인프라(Declarative Infrastructure)의 일부로 취급되어야 한다.

• 코드와 데이터의 결합: 정답지(예: ground_truth.json)는 버저닝이 가능한 Git 기반 레포지토리(Repository)에 애플리케이션 소스 코드와 함께 커밋(Commit)되어야 한다. 이를 통해 v1.2 버전의 애플리케이션 코드는 언제나 v1.2 버전의 정답지에 의해 평가됨을 수학적으로 보장할 수 있다.
• 분리형 스토리지와 포인터: 만약 정답지의 용량이 너무 비대하여(수십만 건의 QA 쌍) Git에 직접 올리기 적합하지 않다면, DVC(Data Version Control)와 같은 도구를 활용한다. 정답지 파일 자체는 S3나 원격 스토리지에 보관하고, 그 데이터의 해시(Hash) 포인터만을 Git으로 버전 관리하여 무결성을 강제한다.

3. 정답지의 생명주기(Lifecycle) 모델

모든 정답지 엔티티는 탄생부터 폐기까지 명확한 라이프사이클 상태(State)를 가져야 하며, 오라클은 이 상태를 읽고 평가 스위트 포함 여부를 결정해야 한다.

1. DRAFT (초안): 새롭게 생성되었으나 아직 인간 검수자(Human-in-the-loop)의 최종 승인을 받지 못한 상태. 오라클 평가 스위트에서 제외된다.
2. ACTIVE (활성): 검증이 완료되어 CI/CD 파이프라인에서 무결성 평가의 절대적 기준으로 사용되는 상태.
3. STALE (만료/재검토 요망): 연동된 원본 지식 문서(RAG Chunk)가 변경되었거나, 생성 후 일정 기간(예: 6개월)이 도과하여 정책 변화 가능성이 의심되는 상태. STALE 상태의 정답지가 격발한 Fail 판정은 파이프라인을 완전히 멈추지 않고 ’경고(Warning)’로만 표출되며, 즉각적인 재검수 대상이 된다.
4. DEPRECATED (폐기): 비즈니스 로직 변화로 인해 명백히 오답이 된 상태 영구 보존 공간으로 아카이빙(Archiving)되며 런타임 검증에서 완전히 배제된다.

정답지의 버저닝과 생명주기 관리는, 결정론적 오라클을 멈춰있는 박제(Taxidermy)가 아니라 진화하는 소프트웨어 생태계와 발맞추어 호흡하는 유기적인 시스템으로 유지하기 위한 방부제이다.