골든 데이터셋은 개수가 많을수록 신뢰도가 올라간다고 오해하는 경우가 흔합니다. 실제로는 100건 안팎이라도 실패 유형별로 고르게 담겨 있으면 충분한 평가셋 역할을 합니다. 반대로 500건을 모아도 비슷한 질문만 반복되면 LLM 평가용 회귀 테스트로서 의미가 크게 줄어듭니다. 이 글에서는 서비스 단계별로 골든 데이터셋을 몇 건, 어떤 구성으로 채워야 하는지와 갱신 주기를 어떻게 잡아야 하는지 구체적으로 정리해 보겠습니다.
골든 데이터셋 개수, ‘몇 건’보다 커버리지가 기준입니다
프롬프트를 한 줄 고쳤을 때 서비스 전체가 흔들리는 사고는 대부분 회귀 테스트 없이 배포했을 때 벌어집니다. 이런 사고를 막으려면 서비스의 ‘정답’이 명확한 케이스를 모아둔 골든 데이터셋이 먼저 있어야 하고, 이 데이터셋으로 프롬프트나 모델을 바꿀 때마다 자동으로 채점해야 합니다.
여기서 개수보다 중요한 건 실패 유형의 커버리지입니다. 단순 질의응답 30건만 넣고 100건이라고 부풀려봐야, 정작 사용자가 자주 겪는 예외 케이스(빈 입력, 긴 문맥, 여러 조건이 섞인 질문)가 빠져 있으면 회귀를 못 잡습니다. 반대로 카테고리 5~6개에 각 15~20건씩 균등하게 넣은 100건짜리 세트가, 무작위로 모은 400건짜리 세트보다 실전에서 더 잘 작동합니다.
평가셋 크기를 정하는 계산법
무작정 개수를 정하기보다, 서비스가 처리하는 ‘의도(intent)’ 개수에 기준을 두는 방식이 실무에서 관리하기 쉽습니다. 계산 순서는 이렇습니다.
- 실제 로그나 기획 문서에서 사용자 의도를 카테고리로 분류합니다(예: 정보 조회, 요약, 분류, 도구 호출, 거절 응답).
- 카테고리마다 최소 10~15건씩 배정합니다. 카테고리가 5개면 50~75건이 최소치가 됩니다.
- 여기에 과거 장애 로그에서 뽑은 ‘실패했던 실제 케이스’를 카테고리 수와 무관하게 20~30건 추가합니다.
서비스 성숙도별로 정리하면 아래와 같은 규모가 됩니다.
| 서비스 단계 | 권장 골든 데이터셋 건수 | 특징 |
|---|---|---|
| 런칭 초기(MVP) | 30~50건 | 핵심 시나리오만 커버, 매주 손으로 검토 가능한 크기 |
| 성장기(사용자 로그 확보 후) | 100~150건 | 실패 로그 기반 케이스 비중을 30% 이상으로 확대 |
| 성숙기(카테고리 다변화) | 300건 이상 | 자동화된 LLM 평가 파이프라인 없이는 관리가 어려움 |
카테고리별로 몇 건씩 넣어야 할까요?
모든 카테고리를 똑같은 비중으로 채우면 오히려 비효율적입니다. 실제 트래픽 비중과 실패율을 함께 고려해서 배분하는 편이 낫습니다.
- 트래픽 비중이 높은 카테고리: 전체 평가셋의 40~50%를 배정합니다. 예를 들어 상담 챗봇에서 ‘주문 조회’가 전체 질의의 절반이라면, 골든 데이터셋도 그 비중을 반영해야 실제 서비스 품질과 평가 점수의 괴리가 줄어듭니다.
- 실패율이 높거나 리스크가 큰 카테고리(개인정보 언급, 결제 관련 답변): 트래픽 비중과 무관하게 최소 15건 이상을 고정 배정합니다.
- 신규 기능이라 로그가 아직 없는 카테고리: 기획 단계에서 예상 질문 10건 정도로 시작하고, 출시 후 2주 안에 실제 로그로 교체합니다.
갱신 주기는 언제, 얼마나 자주가 적당할까요?
골든 데이터셋은 한 번 만들고 방치하면 오히려 위험합니다. 서비스는 계속 바뀌는데 평가 기준만 과거에 머물러 있으면, 실제로는 품질이 떨어졌는데도 회귀 테스트는 계속 통과하는 상황이 생깁니다.
실무에서 무리 없이 지킬 수 있는 주기는 다음과 같습니다.
- 매일: 실패 로그나 사용자 신고 건 중 재현 가능한 케이스를 태깅만 해둡니다(바로 추가하지 않습니다).
- 2주 단위: 태깅해둔 케이스 중 대표성 있는 것만 골라 골든 데이터셋 후보로 리뷰합니다. 이때 중복되거나 이미 커버된 케이스는 넣지 않습니다.
- 분기 1회: 전체 세트를 다시 훑어서, 더 이상 발생하지 않는 옛날 UI·기능 관련 케이스는 폐기합니다. 오래된 골든 데이터셋을 그대로 두면 이미 죽은 기능을 계속 테스트하느라 리소스만 낭비하게 됩니다.
코드로 확인하는 골든 데이터셋 드리프트
골든 데이터셋을 JSONL로 관리하고, 매 배포 전 채점 결과를 이전 결과와 비교하는 방식이 관리하기 쉽습니다. 아래는 카테고리별 통과율과 직전 실행 대비 드리프트를 함께 출력하는 예시 스크립트입니다. model_fn은 실제 서비스에서 쓰는 LLM 호출 함수를 대입한다고 가정합니다.
import json
def load_golden_set(path):
with open(path, encoding="utf-8") as f:
return [json.loads(line) for line in f]
def run_eval(golden_set, model_fn):
results = []
for case in golden_set:
output = model_fn(case["query"])
passed = case["expected"] in output
results.append({
"id": case["id"],
"category": case["category"],
"passed": passed,
})
return results
def summarize(results, prev_path="prev_results.json"):
by_category = {}
for r in results:
by_category.setdefault(r["category"], []).append(r["passed"])
print(f"전체 통과율: {sum(r['passed'] for r in results)}/{len(results)}")
for cat, passes in by_category.items():
rate = sum(passes) / len(passes) * 100
print(f"- {cat}: {rate:.1f}% ({sum(passes)}/{len(passes)})")
try:
with open(prev_path, encoding="utf-8") as f:
prev = json.load(f)
prev_pass_ids = {p["id"] for p in prev if p["passed"]}
now_fail_ids = {r["id"] for r in results if not r["passed"]}
drifted = prev_pass_ids & now_fail_ids
if drifted:
print(f"\n[경고] 직전엔 통과했으나 이번에 실패한 케이스: {sorted(drifted)}")
except FileNotFoundError:
pass
with open(prev_path, "w", encoding="utf-8") as f:
json.dump(results, f, ensure_ascii=False)
golden_set = load_golden_set("golden.jsonl")
results = run_eval(golden_set, model_fn=my_llm_call)
summarize(results)
실행하면 아래와 같은 형태로 출력됩니다.
전체 통과율: 92/100
- 정보조회: 96.0% (24/25)
- 요약: 90.0% (18/20)
- 분류: 100.0% (20/20)
- 도구호출: 80.0% (12/15)
- 거절응답: 90.0% (18/20)
[경고] 직전엔 통과했으나 이번에 실패한 케이스: [14, 37]
이 구조를 쓰면 프롬프트를 수정할 때마다 “어느 카테고리가 나빠졌는지”, “직전엔 되던 게 왜 안 되는지”를 바로 확인할 수 있습니다. 평가셋 채점 로직을 직접 짜기보다 promptfoo 공식 문서처럼 YAML로 케이스를 정의하고 CI에 붙일 수 있는 오픈소스 도구를 검토해보는 것도 방법입니다.
이 기준이 안 통하는 경우와 트레이드오프
카테고리 기반으로 골든 데이터셋을 짜는 방식이 모든 상황에 맞는 건 아닙니다. 몇 가지 한계를 짚어두겠습니다.
- 적대적 입력(프롬프트 인젝션, 유도 질문)은 골든 데이터셋만으로 못 잡습니다. 정답이 명확한 케이스 위주로 구성되기 때문에, 공격 패턴은 별도의 레드팀 테스트셋으로 관리해야 합니다.
- 라벨러 한 명이 만든 골든 데이터셋은 그 사람의 판단 기준이 그대로 정답 기준이 됩니다. 최소 2명이 교차 검토하지 않으면, 실제로는 애매한 답변인데도 통과 판정이 나올 수 있습니다.
- 건수를 늘릴수록 유지보수 비용이 같이 늘어납니다. 300건을 매번 자동 채점하려면 API 호출 비용과 실행 시간이 무시할 수 없는 수준이 되고, 사람이 리뷰하는 주기(분기 1회)도 그만큼 오래 걸립니다. 규모를 키우기 전에 자동화 파이프라인부터 먼저 갖춰두는 편이 안전합니다.
평가셋과 훈련·검증 데이터의 역할 구분이 헷갈린다면 위키백과의 훈련·검증·테스트 데이터셋 설명을 참고하면 개념을 정리하기 좋고, 조직 차원에서 AI 평가 체계를 문서화해야 한다면 NIST의 AI 위험 관리 프레임워크가 카테고리 분류와 리스크 우선순위를 정하는 데 참고할 만한 공식 기준을 제공합니다.
골든 데이터셋은 처음부터 완벽한 크기를 맞추기보다, 서비스 단계에 맞춰 30건에서 시작해 실패 로그로 채워나가는 쪽이 현실적입니다. 이번 주에 카테고리를 5개로 나누고 각 10건씩만 모아도, 다음 배포 전에 회귀 여부를 눈으로 확인할 수 있는 최소한의 안전망은 만들어집니다.
