10.6 회귀 테스트 자동화를 위한 골든 데이터셋의 분할 및 관리

10.6 회귀 테스트 자동화를 위한 골든 데이터셋의 분할 및 관리

AI 기반 애플리케이션에서 완벽한 골든 데이터셋(Golden Dataset)을 구축했다 하더라도, 수천 건에 달하는 LLM 호출을 CI/CD(Continuous Integration/Continuous Deployment) 파이프라인의 모든 커밋(Commit)마다 실행하는 것은 시간과 비용(토큰 비용) 측면에서 지극히 비효율적이다.

개발 속도를 저해하지 않으면서도 AI 모델의 회귀(Regression)를 효과적으로 방어하기 위해, 소프트웨어 공학의 ‘테스트 피라미드(Test Pyramid)’ 개념을 차용하여 골든 데이터셋을 전략적으로 분할하고 관리해야 한다.

1. 테스트 실행 목적에 따른 데이터셋 티어링(Tiering)

전체 골든 데이터셋을 하나의 거대한 덩어리로 관리하는 대신, 실행 주기와 커버리지에 따라 3개의 계층(Tier)으로 분류하라.

1.1 스모크 테스트(Smoke Test) 데이터셋 (Tier 1)

  • 목적: 코드 빌드(Build) 직후 즉시 실행되어 시스템의 근본적인 파괴(Fatal Crash) 여부를 수 분 이내에 판별한다.
  • 크기: 전체 골든 데이터셋의 1~5% (보통 10~50건 내외).
  • 구성 요소:
  • 가장 빈번하게 발생하는 ‘해피 패스(Happy Path)’ 시나리오.
  • 절대 실패해서는 안 되는 크리티컬(Critical) 비즈니스 로직(예: 결제 정보 파싱, 개인정보 마스킹).
  • 실행 주기: 개발자의 모든 git push 또는 PR(Pull Request) 생성 시.

1.2 회귀 테스트(Regression Test) 데이터셋 (Tier 2)

  • 목적: 프롬프트 변경이나 로직 수정이 기존에 잘 작동하던 다른 기능에 부작용(Side-effect)을 발생시켰는지(프롬프트 회귀)를 면밀히 검증한다.
  • 크기: 전체 골든 데이터셋의 20~30% (수백 건 수준).
  • 구성 요소:
  • 과거에 장애를 유발했던 엣지 케이스(Edge Cases).
  • 각 도메인/기능별 대표적인 사용자 입력 패턴.
  • 복잡한 추론(Reasoning)이 요구되는 다중 턴(Multi-turn) 대화.
  • 실행 주기: 주요 브랜치(Main/Master) 병합(Merge) 시점, 혹은 매일 밤(Nightly Build).

1.3 벤치마크/전수 테스트(Benchmark Test) 데이터셋 (Tier 3)

  • 목적: 새로운 LLM 모델(예: GPT-4o에서 Claude 3.5로 교체) 도입, 아키텍처 대규모 개편(RAG 파이프라인 변경 등) 시 시스템의 종합적인 성능 지표(Metrics)를 측정하고 베이스라인(Baseline)을 재설정한다.
  • 크기: 가용한 전체 골든 데이터셋 (100%).
  • 구성 요소: 수집된 모든 정상/비정상/적대적(Adversarial) 시나리오 총망라.
  • 실행 주기: 배포 전 최종 릴리스(Release) 단계, 혹은 LLM 백엔드 교체 등 주요 마일스톤 시점.

2. 도메인 및 기능별 부분 분할(Partitioning)

티어링(Tiering) 외에도, 골든 데이터셋은 변경된 코드나 프롬프트의 ’영향 범위(Impact Radius)’에 맞춰 선택적으로 실행될 수 있도록 도메인별 분할이 필수적이다.

모든 데이터 항목(Row)에 대해 메타데이터 태그(Tag)를 부여하라.

  • @domain=finance, @domain=customer_support
  • @feature=intent_classification, @feature=data_extraction
  • @model=gpt-4-turbo (특정 모델에 특화된 프롬프트 검증용)

만약 개발자가 ‘고객 지원(Customer Support)’ 라우팅 관련 프롬프트만을 수정했다면, CI 파이프라인은 전체 회귀 테스트를 돌리는 대신 @domain=customer_support 태그가 붙은 데이터셋 파티션만 필터링하여 실행함으로써 검증 속도를 극대화해야 한다.

3. 데이터셋 버전 관리(Data Versioning) 기법

코드의 변경 이력만큼이나 평가 기준(골든 데이터)의 변경 이력(History)을 추적하는 것은 필수적이다. 정답 자체가 바뀌면 이전의 테스트 통과율(Pass Rate) 95%와 현재의 95%는 의미가 완전히 다르기 때문이다.

  • DVC(Data Version Control) 모델 도입: Git이 텍스트 파일을 관리하듯, 대용량 골든 데이터셋(JSON, CSV 형태)의 스냅샷을 DVC나 W&B(Weights & Biases), LangSmith 등의 평가 플랫폼을 통해 해시(Hash) 값으로 버전 관리하라.
  • 코드와 데이터의 결합 결속: 특정 릴리스(v1.2.0)에 사용된 프롬프트 코드는 해당 시점에 평가를 수행했던 ’골든 데이터셋 v3’와 강하게 결합되어야 한다. 이를 통해 향후 운영 중 장애 파악 시 “그 당시 어떤 정답지를 기준으로 이 모델이 배포 승인을 받았는가?“를 즉시 추적(Traceability)할 수 있다.