AX LABS
← 블로그 AX Ops 방법론

골든셋은 테스트가 아니다

회귀를 막는 운영 자산이다

AX LABS 5분 읽기

현장에서 에이전트 PoC가 멈추는 지점은 비슷하다. 데모는 된다. 특정 질문에는 답한다. 그런데 프롬프트를 조금 바꾸거나 모델을 교체하면 어제 되던 업무가 오늘 깨진다. 팀은 원인을 찾느라 로그를 뒤지고, 현업은 “이번 버전도 믿기 어렵다”고 말한다.

문제는 모델 성능이 아니다. 회귀를 잡는 운영 장치가 없다는 점이다. 에이전트는 일반 소프트웨어보다 변동성이 크다. 모델, 프롬프트, tool, retrieval, memory, 권한 정책이 동시에 품질을 흔든다. 그래서 eval 골든셋은 선택 사항이 아니다.

골든셋은 좋은 답변 모음이 아니라, 조직이 다시는 놓치지 않기로 합의한 실패의 목록이다.

골든셋은 정답지가 아니라 계약이다

골든셋을 “대표 질문 100개”로 만들면 곧 낡는다. 업무는 바뀌고, 데이터는 갱신되고, 에이전트의 tool 경로도 바뀐다. 오래가는 골든셋은 입력과 정답만 저장하지 않는다. 성공 조건, 실패 조건, 허용 가능한 변형, 금지 행동을 함께 저장한다.

OpenAI의 Agent evals 문서는 agent 품질을 재현 가능한 평가로 측정하고, trace grading으로 end-to-end 의사결정과 tool call을 평가하라고 설명한다. LangSmith도 production trace에서 흥미롭거나 문제가 있는 run을 dataset으로 샘플링하고, PR 또는 nightly build에서 eval을 실행하는 흐름을 제시한다. 핵심은 같다. eval은 연구용 점수가 아니라 배포 전후의 운영 절차다.

골든셋 한 건에는 최소한 다섯 가지가 들어간다.

  • 사용자 요청과 업무 맥락
  • 기대 산출물 또는 판정 rubric
  • 반드시 써야 할 tool과 쓰면 안 되는 tool
  • 실패 유형 태그
  • 담당 도메인 오너와 마지막 검토일

이 구조가 없으면 “모델이 좋아졌다”는 말은 검증되지 않는다.

데이터셋은 실패 로그에서 자란다

처음부터 완벽한 eval 데이터셋을 만들려는 팀은 오래 걸리고 작게 끝난다. 출발점은 운영 로그다. CS, 영업, 구매, 설비, 법무처럼 실제 업무에서 나온 실패를 수집한다. 단, 모든 로그를 넣지 않는다. 골든셋은 운영비가 드는 자산이다. 중복, 일회성, 정책 밖 요청을 그대로 넣으면 회귀 테스트가 아니라 쓰레기통이 된다.

흔한 방식 AX Ops 방식
자주 묻는 질문을 모은다 자주 깨지는 업무 경로를 모은다
답변 텍스트를 정답으로 둔다 성공 조건과 금지 행동을 둔다
모델 출력만 본다 trace, tool call, 최종 산출물을 함께 본다
한번 만들고 방치한다 릴리즈마다 승격·폐기·보류를 결정한다

특히 에이전트는 최종 답변만 보면 놓친다. 잘못된 tool을 호출했지만 우연히 맞는 답을 냈을 수 있다. retrieval 문서가 틀렸는데 모델이 상식으로 메웠을 수 있다. 권한이 없는 데이터에 접근했는데 최종 문장에는 드러나지 않을 수 있다. 그래서 trace 기반 평가가 필요하다.

골든셋 운영에는 승격 규칙이 필요하다

운영 규칙이 없으면 골든셋은 빠르게 정치적 문서가 된다. 어느 부서는 자기 업무를 더 넣으려 하고, 어느 팀은 실패 사례 공개를 꺼린다. AX Ops에서는 승격 기준을 먼저 고정한다.

첫째, 실제 사용자 영향이 있었던 실패를 우선한다. 둘째, 재현 가능한 입력과 환경을 확보한다. 셋째, 판정자가 바뀌어도 같은 결론이 나오는 rubric을 붙인다. 넷째, 모델 교체·프롬프트 변경·tool 변경 때 반드시 다시 돈다. 다섯째, 더 이상 발생하지 않는 업무나 정책이 바뀐 항목은 폐기한다.

OpenAI가 2025년 11월 공개한 evals 비즈니스 글도 eval을 “Specify → Measure → Improve” 흐름으로 설명하며, domain expert가 LLM grader를 정기적으로 감사해야 한다고 말한다. 자동 채점은 속도를 준다. 하지만 골든셋의 권위는 현업 판정과 감사 루프에서 나온다.

배포 게이트에 묶어야 회귀를 막는다

골든셋은 dashboard에만 있으면 힘이 없다. 배포 게이트에 묶어야 한다. 프롬프트 수정, retrieval index 재생성, tool schema 변경, 모델 버전 변경이 일어날 때 골든셋을 자동 실행한다. 실패 항목은 “나중에 확인”이 아니라 release blocker 또는 승인 예외로 처리한다.

팀이 지금 할 일은 거창하지 않다. 지난 운영 로그에서 실제로 문제를 만든 사례를 추린다. 각 사례에 성공 조건과 금지 행동을 붙인다. 자동 채점과 사람 검토를 분리한다. 그리고 다음 배포부터 골든셋 통과를 조건으로 건다.

참고 자료:

골든셋 구축은 평가 프로젝트가 아니라 운영 체계 설계다. AX LABS는 이 지점을 AX Ops 안에서 설계하고 굴린다. AX Ops 방법론 →