LLM 에이전트 회귀 테스트 구축법: 골든셋·비용·지연 시간을 함께 보는 평가 파이프라인

요약: LLM 에이전트 품질은 “답이 좋아 보인다”로 관리할 수 없습니다. 모델을 바꾸고, 프롬프트를 고치고, 도구를 추가할 때마다 예전에는 되던 작업이 조용히 망가질 수 있습니다. 실무 개발팀에는 골든셋, 자동 평가, 비용·지연 지표, 실패 샘플 리뷰가 묶인 회귀 테스트 파이프라인이 필요합니다.

에이전트 회귀는 일반 소프트웨어 회귀보다 늦게 발견된다

일반 코드 회귀는 테스트가 빨리 잡아줍니다. 함수가 잘못된 값을 반환하거나 API가 500을 내면 CI에서 드러납니다. LLM 에이전트 회귀는 더 애매합니다. 답은 그럴듯하고, 로그도 성공처럼 보이고, 사용자는 며칠 뒤 “요즘 결과가 이상하다”고 말합니다.

예를 들어 고객 문의 분류 에이전트가 “환불 요청”을 “일반 문의”로 조금 더 자주 분류하기 시작해도 처음엔 티가 안 납니다. 코드 리뷰 에이전트가 보안 이슈를 놓치기 시작해도 PR 몇 개가 지나야 알 수 있습니다. 문서 요약 에이전트가 숫자를 틀리게 옮겨도 사람이 원문을 대조하지 않으면 그대로 배포됩니다.

그래서 LLM 에이전트는 배포 전후에 같은 입력을 반복해보고 결과 차이를 추적해야 합니다. 모델 변경, 프롬프트 변경, tool schema 변경, retrieval index 변경은 모두 회귀 테스트 대상입니다.

골든셋은 크기보다 대표성이 중요하다

많은 팀이 평가셋을 만들 때 처음부터 1,000개 샘플을 목표로 잡습니다. 그러다 라벨링 비용 때문에 포기합니다. 시작은 30~100개면 충분합니다. 중요한 건 샘플 수가 아니라 실제 실패 유형을 담는 것입니다.

좋은 골든셋은 다음 범주를 포함합니다.

• 정상 케이스: 제품이 가장 자주 받는 평범한 요청.
• 경계 케이스: 애매한 표현, 불완전한 입력, 다의어.
• 위험 케이스: 개인정보, 결제, 권한, 삭제, 외부 발송.
• 장문 케이스: 긴 문서, 긴 로그, 여러 파일 diff.
• 공격 케이스: prompt injection, 정책 우회, 도구 오남용 유도.
• 회귀 케이스: 과거에 실제로 실패했던 샘플.

각 샘플에는 입력만 있으면 부족합니다. 기대 행동을 적어야 합니다. 정답 문장 하나가 아니라 “반드시 포함해야 할 요소”, “절대 하면 안 되는 행동”, “허용 가능한 출력 범위”를 함께 저장합니다. 에이전트는 생성형이기 때문에 문자열 일치만으로 평가하면 너무 쉽게 실패하거나 너무 쉽게 통과합니다.

예시는 다음과 같습니다.

• 입력: 고객이 환불과 재구독을 동시에 언급한 문의.
• 기대: 환불 의도와 재구독 의도를 모두 태깅한다.
• 금지: 결제 취소 실행 도구를 자동 호출하지 않는다.
• 허용: 상담원에게 확인 질문을 생성하는 것은 가능.

이 정도 구조가 있어야 사람이 평가 기준을 공유할 수 있습니다.

평가는 정답률 하나로 끝내면 안 된다

LLM 평가에서 accuracy만 보면 중요한 문제가 빠집니다. 에이전트는 비용, 지연, 도구 호출, 안전성까지 함께 봐야 합니다. 같은 정확도라도 10배 비싸거나, p95 지연이 30초이거나, 불필요한 write 도구를 자주 호출하면 제품에 넣기 어렵습니다.

기본 평가 지표는 다섯 묶음으로 나눌 수 있습니다.

1. 품질: task_success, required_points_covered, hallucination_flag.
2. 안전: forbidden_action_called, sensitive_data_leaked, policy_violation.
3. 도구 사용: tool_call_count, wrong_tool_call, missing_tool_call.
4. 비용: input_tokens, output_tokens, cached_tokens, estimated_cost.
5. 성능: time_to_first_token, total_latency, retry_count.

여기서 특히 중요한 건 forbidden_action_called입니다. 답변 품질이 좋아도 금지된 도구를 호출했다면 실패입니다. 반대로 정확도가 조금 낮아도 안전하게 “확인 필요”로 멈춘 출력은 운영상 더 나을 수 있습니다.

자동 평가와 사람 리뷰를 섞어야 한다

모든 샘플을 사람이 매번 채점하면 느립니다. 모든 샘플을 LLM judge에 맡기면 신뢰가 떨어집니다. 현실적인 방식은 계층형 평가입니다.

첫 단계는 규칙 기반 검사입니다. JSON schema, 필수 필드, 금지 단어, 도구 호출 여부, URL 형식, 숫자 범위처럼 기계적으로 확인할 수 있는 항목을 검사합니다. 이 단계는 빠르고 일관됩니다.

두 번째 단계는 LLM judge입니다. 요약 품질, 답변 완성도, 근거 충실도처럼 규칙만으로 보기 어려운 항목을 채점합니다. 이때 judge prompt도 버전 관리해야 합니다. judge가 바뀌면 점수 분포도 바뀌기 때문입니다.

세 번째 단계는 사람 리뷰입니다. 전체 샘플이 아니라 실패 샘플, 점수 변화가 큰 샘플, 위험 케이스만 사람이 봅니다. 이렇게 하면 비용을 줄이면서도 중요한 회귀를 놓칠 확률을 낮출 수 있습니다.

평가 결과는 PR 코멘트나 배포 대시보드에 요약되어야 합니다. “평균 87점”보다 “지난 버전 대비 환불 케이스 4개 중 2개 실패, forbidden_action 1건 발생”이 훨씬 유용합니다.

프롬프트와 도구 스키마도 버전 관리해야 한다

에이전트 회귀의 원인은 모델 변경만이 아닙니다. 시스템 프롬프트 한 줄, retrieval chunk size, tool description, temperature, timeout, top_p, 모델 라우팅 정책이 모두 결과를 바꿉니다. 그런데 많은 팀이 이 설정을 코드 밖 환경변수나 대시보드에서 바꿉니다. 그러면 나중에 어떤 변경이 회귀를 만들었는지 추적하기 어렵습니다.

최소한 아래 항목은 버전으로 남겨야 합니다.

• model name과 버전.
• system prompt.
• tool schema와 tool description.
• retrieval 설정: index 버전, chunk size, top_k.
• generation 설정: temperature, reasoning effort, max output.
• safety policy와 approval rule.
• eval dataset 버전.
• judge prompt 버전.

이 정보가 있어야 “지난주엔 됐는데 오늘 안 된다”를 조사할 수 있습니다. 에이전트 운영에서 재현성은 선택이 아니라 비용 절감 도구입니다.

CI에 넣을 기준은 단순하고 엄격해야 한다

처음부터 복잡한 점수 체계를 CI gate로 넣으면 팀이 싫어합니다. 작은 기준으로 시작하는 편이 낫습니다.

예를 들어 배포 차단 조건은 다음처럼 잡을 수 있습니다.

• 위험 샘플에서 forbidden action 1건 이상 발생하면 차단.
• 전체 task_success가 기준선 대비 5%p 이상 하락하면 차단.
• p95 latency가 2배 이상 증가하면 경고 또는 차단.
• estimated_cost가 50% 이상 증가하면 승인 필요.
• JSON schema 실패율이 0이 아니면 차단.

이 기준은 명확합니다. 개발자가 왜 막혔는지 알 수 있고, 예외 승인도 기록하기 쉽습니다. 품질 점수 1~2점 변동까지 모두 차단하면 결국 eval을 우회하게 됩니다. 안전과 구조적 실패는 엄격하게, 품질 미세 변동은 리뷰로 넘기는 균형이 좋습니다.

오늘 적용할 체크리스트

• 실제 사용자 요청과 과거 실패 사례에서 30~100개 골든셋을 만듭니다.
• 각 샘플에 기대 행동, 금지 행동, 허용 범위를 함께 기록합니다.
• accuracy뿐 아니라 안전, 도구 사용, 비용, 지연 지표를 같이 저장합니다.
• 규칙 기반 검사, LLM judge, 사람 리뷰를 계층형으로 구성합니다.
• 프롬프트, tool schema, retrieval 설정, judge prompt를 버전 관리합니다.
• 위험 샘플 forbidden action은 1건만 나와도 배포 차단합니다.
• 비용과 p95 latency 변화도 PR 또는 릴리즈 리포트에 표시합니다.
• 실패 샘플은 다음 골든셋에 추가해 평가셋을 계속 키웁니다.

LLM 에이전트는 배포 후에도 계속 변하는 시스템입니다. 회귀 테스트가 없으면 품질 저하는 감으로만 발견됩니다. 골든셋과 비용·지연 지표를 함께 보는 파이프라인을 만들면 모델을 바꿀 때도 자신 있게 비교하고, 나빠진 부분을 숫자로 잡아낼 수 있습니다.