15.3.2. 정답 데이터의 유효 기간 설정 및 만료 데이터 자동 탐지

15.3.2. 정답 데이터의 유효 기간 설정 및 만료 데이터 자동 탐지

소프트웨어 시스템을 감싸고 있는 비즈니스 환경과 외부 지식 매개변수는 끊임없이 변화한다. 그러나 일반적인 단위 테스트(Unit Test)의 패러다임에 갇힌 많은 개발 조직들은 한 번 생성한 골든 데이터(Golden Data)를 ’영원 불변의 진리(Permanent Truth)’로 간주하는 치명적인 인지적 오류를 겪는다.

시간에 저항하는 데이터는 존재하지 않는다. 특정 시점에 완벽했던 정답지는 시간이 흐름에 따라 비즈니스 규칙의 변경, 법적 규제의 신설, 혹은 기저 파운데이션 모델(Foundation Model)의 성능 진화로 인해 점진적으로 부패(Decay)한다. 본 절에서는 이러한 테스트 데이터의 부패 현상을 막고, 시스템의 신뢰성을 능동적으로 방어하기 위한 ‘유효 기간(Time-To-Live, TTL)’ 기반의 자동 탐지 아키텍처를 제시한다.

1. 정답 데이터의 부패 유형과 생명주기

정답 데이터가 유효성을 상실하는 궤적은 크게 두 가지 거시적 원인에 의해 촉발된다.

  1. 외인성 부패(Exogenous Decay): 시스템 외부 요인에 의한 부패이다. RAG(Retrieval-Augmented Generation) 시스템이 참조하는 외부 정보 소스의 갱신, 기업의 환불 정책 변경, 혹은 통계청의 새로운 물가 지수 발표 등 비대화형(Data Outdated) 결함이 이에 해당한다.
  2. 내인성 부패(Endogenous Decay): 시스템 내부 요인에 의한 부패이다. 파운데이션 모델의 메이저 통계 가중치 업데이트로 인해 이전에 장황하게 기술해야만 합격 판정을 받았던 오라클 검증 로직이, 이제는 ’과적합된 옛날 테스트(Overfitted Old Test)’로 전락해버리는 현상이다.

이를 데이터베이스 이론에 접목하면, 모든 골든 데이터셋의 레코드(Record)는 생성 시점에 수명(Life Expectancy)을 선험적으로 할당받아야 함을 의미한다.

2. Time-To-Live (TTL) 기반의 메타데이터 아키텍처

오라클이 실행 시간에 데이터의 노후화를 스스로 인지하기 위해서는, 골든 데이터셋의 스키마 자체가 단선적인 [Query, Expected_Answer] 쌍에서 벗어나야 한다. 시간적 맥락을 주입하는 확장 스키마 패러다임을 도입해라.

{
  "test_id": "TC-FIN-8821",
  "domain_category": "interest_rate_policy",
  "query": "2025년 청년 도약 계좌의 최고 금리는 얼마인가요?",
  "expected_answer_schema": "float_percentage",
  "expected_value": "6.5",
  "metadata": {
    "author": "Alice (Financial QA)",
    "created_at": "2024-11-01T09:00:00Z",
    "ttl_days": 180,
    "expiration_date": "2025-04-30T23:59:59Z",
    "dependency_tags": ["database:polices_v2", "doc_hash:8f4c2"]
  }
}

이러한 TTL 메타데이터를 주입하면 데이터는 단순히 정적으로 존재하는 것이 아니라, 스스로 만료 시점을 시스템에 알리는 ’활성 객체(Active Object)’로 진화한다.

3. 만료 데이터 자동 탐지 파이프라인 (Automated Obsolescence Detection)

CI/CD 파이프라인에서 테스트가 실행될 때, 무작정 오라클 평가를 수행하기 전에 데이터의 유효성을 검사하는 ’선행 청소(Pre-cleaning) 단계’가 반드시 필요하다.

graph TD
    A[CI/CD 파이프라인: 회귀 테스트 시작] --> B[골든 데이터셋 로드]
    B --> C[Time Validator: 현재 시간과 Expiration Date 비교]
    
    C -->|유효 기간 내 Valid| D[LLM 추론 및 오라클 검증 수행]
    C -->|유효 기간 초과 Expired| E[의도적 테스트 스킵 Skip Test]
    
    E --> F[만료 데이터 알림 Alert: QA 엔지니어 및 도메인 전문가]
    F --> G[도메인 전문가의 정책 리뷰]
    
    G -->|재승인| H[TTL 연장 및 Expiration Date 갱신]
    G -->|정책 변경 확인| I[새로운 Expected Value로 레코드 업데이트]
    
    H --> J[데이터셋 재생성 및 커밋]
    I --> J
    
    style E fill:#ffe4e1,stroke:#f00,stroke-width:2px
    style F fill:#fffacd,stroke:#ffd700,stroke-width:2px

다이어그램의 핵심은 기한이 만료된 데이터(Expired)에 대해 로직 검증 결과와 무관하게 즉시 테스트 스킵(Skip)을 선언하는 아키텍처다. 만료된 데이터를 가지고 오라클 검증을 수행하여 Pass가 나온다면 이는 시스템이 ’구형 지식을 여전히 내뱉고 있음’을 의미하는 심각한 보안 결함(False Positive)일 수 있고, Fail이 나온다면 단순히 정답지가 구형일 뿐 시스템 결함이 아닐 수 있기 때문이다(False Negative). 어떠한 경우에도 파이프라인의 명확성(Clarity)을 훼손하게 되므로 선제적 차단이 필수적이다.

4. 소결

데이터의 진리값은 시간에 종속적이다. 골든 데이터셋의 모든 조각들에 ‘시한폭탄’ 다이얼(TTL)을 달아주는 작업은 겉보기엔 유지보수 비용을 증가시키는 듯 보이나, 실제로는 잘못된 오라클의 Fail 사태 위에서 원인을 찾기 위해 허비되는 개발팀의 신경소모전(Burn-out)을 원천 차단하는 가장 경제적인 설계이다. 오라클 시스템 설계자는 테스트 데이터가 영원할 것이라는 환상에서 벗어나, 지속적인 폐기와 재생이 반복되는 순환기(Circulatory System)를 프로그래밍해야 한다.