5.7 테스트 데이터(Fixtures) 관리와 골든 샘플(Golden Sample) 선정

거대 언어 모델(LLM)을 검증하는 오라클을 극도로 정교하게 깎아내었다 하더라도, 그 오라클이 검사하는 ‘시험지(Test Data)’ 자체가 형편없다면 테스트의 의미는 퇴색된다. 일반적인 소프트웨어 유닛 테스트에서는 “hello”, 빈 문자열 "", 혹은 특수 기호 몇 개 정도를 테스트 픽스처(Fixtures)로 통과시키는 것만으로도 충분한 경우가 많다. 그러나 자연어의 망망대해를 헤엄치는 AI 모델에게 이처럼 단순한 고정 데이터는 어떠한 스트레스도 주지 못한다.

AI 유닛 테스트 파이프라인이 살아 움직이는 생태계가 되려면, 모델의 추론 능력과 오라클의 방어력을 동시에 시험할 수 있는 극도로 정제되고(Refined) 다채로운(Diverse) 픽스처 저장소가 필요하다. 이 저장소의 핵심 개념이 바로 **‘골든 샘플(Golden Sample)’**이다.

1. 픽스처(Fixtures)로서의 골든 샘플의 정의

골든 샘플이란, 현재 프로덕션 환경에서 발생할 수 있는 가장 대표적인 정상(Happy) 케이스와 가장 파괴적인 예외(Edge) 케이스들을 엄선하여, “어떤 일이 있어도 이 데이터에 대해서 만큼은 모델이 완벽한 A라는 정답(Ground Truth)을 내놓아야 한다“고 합의된 고정 데이터셋을 뜻한다.

소프트웨어 공학의 관점에서 수만 개의 로그를 긁어와 매번 테스트하는 것은 유닛 테스트의 ‘신속성’ 원칙에 위배된다. 따라서 도메인 전문가(SME)와 엔지니어는 전체 사용성을 대표할 수 있는 최소한의 정수(Extract)만을 뽑아내어 골든 샘플 픽스처로 격리(Isolate)해야 한다.

• 입력(Input): LLM에게 주입될 원시 사용자 프롬프트나 RAG 검색 결과 텍스트.
• 기댓값(Expected Output/Ground Truth): 오라클이 대조해야 할 단단한 정답지(예: 추출되어야 할 고정 JSON 스키마, 반드시 포함되어야 할 필수 키워드 그룹).

2. 골든 샘플 픽스처의 관리 원칙

테스트 데이터는 코드베이스와 거의 동등한 대우를 받아야 한다. AI 파이프라인에서 픽스처를 관리하는 핵심 공학 원칙은 다음과 같다.

• 버전 관리의 결합(Version Control Integration): 골든 샘플 데이터셋(예: tests/fixtures/golden_samples_v1.2.json)은 프롬프트 템플릿 코드, 그리고 검증 오라클 로직과 함께 동일한 Git 커밋(Commit) 내에서 버저닝되어야 한다. 프롬프트가 바뀌면, 그 프롬프트를 평가하는 골든 샘플과 오라클도 동시에 갱신되어야 테스트의 일관성이 유지된다.
• 불변성(Immutability)의 원칙: 한 번 합의되어 CI 파이프라인에 등재된 골든 샘플의 기댓값(Ground Truth)은, 명백한 스펙 변경이 발생하기 전까지는 개별 개발자가 임의로 수정해서는 안 된다. 모델이 정답을 맞히지 못한다고 해서 정답지를 모델의 출력에 맞춰 수정하는 것은 테스트의 본질을 파괴하는 행위다.
• 카테고리별 분리(Categorization): 골든 샘플은 단일한 거대 파일이 아니라, ‘환자 정보 파싱’, ‘의학 용어 번역 오류’, ‘악의적인 프롬프트 인젝션’ 등 테스트의 목적성에 따라 물리적인 픽스처 파일로 쪼개져야(Modularized) 한다. 이는 특정 카테고리에서 테스트가 실패했을 때 문제의 범위를 즉각적으로 좁히기(Triaging) 위함이다.

3. 골든 시스템의 나침반

결국 결정론적 오라클을 구축한다는 것은 방대한 지도를 그리는 행위이며, 골든 샘플은 그 지도 위의 북극성이다. 확률과 무작위성이 지배하는 LLM의 블랙박스 안에서 “우리의 튜닝이 올바른 방향으로 나아가고 있는가?“를 판별할 수 있는 유일한 기준선(Baseline)은, 변하지 않는 견고한 골든 샘플 데이터와 그것을 가차 없이 채점하는 결정론적 오라클의 조합뿐이다.

이후 서술될 장에서는 이 골든 샘플 데이터셋을 최소한의 볼륨으로 최대한의 커버리지를 내도록 구성하는 구체적인 타겟팅(Targeting) 및 발굴 전략에 대해 깊이 있게 논의한다.