프롬프트와 도구를 연결하면 짧은 시간 안에 에이전트 데모를 만들 수 있다. 운영 단계에서는 프롬프트, 모델, 도구를 바꿀 때 품질이 실제로 좋아졌는지, 기존 기능이 함께 나빠지지는 않았는지 확인하는 일이 더 중요해진다. 몇 가지 예시를 눈으로 확인하는 것만으로는 다양한 사용 사례의 변화를 찾기 어렵다.
사용 사례가 늘면 일부 예시를 눈으로 보는 방식만으로 모든 회귀를 찾기 어렵다. 핵심 작업과 자주 발생한 실패를 고정된 평가 세트로 관리해야 변경 전후를 같은 기준으로 비교할 수 있다.
최종 답과 실행 과정을 함께 평가한다
에이전트의 실패는 최종 답만 봐서는 놓치기 쉽다. 같은 단계를 반복하거나, 설명한 계획과 실제 도구 호출이 어긋나도 마지막 문장만 자연스러우면 통과한 것처럼 보일 수 있다. 그래서 결과와 함께 실행 경로도 평가해야 한다.
최종 출력만 보는 평가는 실행 과정의 문제를 놓칠 수 있다. 운영 중 발견된 실패를 평가 데이터에 계속 추가해야 같은 문제가 다시 생겼는지 확인할 수 있다. 평가 세트가 실제 실패 유형을 담지 못하면 높은 통과율도 운영 품질을 충분히 설명하지 못한다.
LLM 심판도 먼저 검증한다
LLM으로 출력 품질을 채점하면 많은 사례를 빠르게 평가할 수 있다. 하지만 채점 모델도 일관성과 편향을 확인하지 않으면 기준으로 쓰기 어렵다.
LLM 심판의 판정은 모델과 temperature, 답변 제시 순서에 따라 달라질 수 있다. 긴 답을 선호하는 장황함 편향, 제시 순서에 영향을 받는 위치 편향, 같은 계열 모델의 출력을 높게 평가하는 경향도 보고돼 있다. 따라서 한 모델의 점수를 객관적인 정답처럼 사용해서는 안 된다.
사람이 라벨링한 표본으로 채점 모델의 판정 일치율을 먼저 확인한다. 이후에도 경계 사례를 정기적으로 사람이 다시 보고, 모델이나 채점 프롬프트가 바뀌면 일치율을 재측정해야 한다.
평가 세트와 배포 기준을 함께 관리한다
기본 평가 루프는 세 부분으로 구성할 수 있다.
- 고정된 핵심 세트. 반드시 맞아야 하는 사례를 회귀 기준선으로 둔다. 중요한 점수가 떨어지면 원인을 확인하기 전까지 배포를 멈춘다.
- 운영 실패 세트. 실제 서비스에서 발견된 실패를 재현 가능한 형태로 추가한다.
- 배포 기준. 품질과 비용, 지연의 허용 범위를 정하고 자동 검사와 사람 검토 결과를 함께 사용한다.
평가 루프는 반복 검수의 일부를 자동화한다. 작은 팀이 모든 배포를 수작업으로 확인하기는 어려우므로 고정 사례와 실제 실패 사례를 함께 실행하고, 중요한 지표가 기준 아래로 내려가면 배포를 멈추게 할 수 있다. 다만 자동 평가는 표본 밖의 문제를 모두 찾지는 못하므로 위험이 큰 변경에는 사람 검토도 남겨야 한다.
평가 데이터는 운영하면서 쌓인다
모델이나 프롬프트 자체는 짧은 시간 안에 바꿀 수 있지만 변경 효과를 판별할 평가 데이터는 운영하면서 쌓인다. 실패 사례를 재현하고 채점 기준을 보완해야 다음 변경에서 같은 문제를 더 빨리 찾을 수 있다.
평가 루프는 모델 변경의 효과와 회귀를 같은 기준으로 비교하게 해준다. 실제 실패 사례를 계속 평가 세트에 넣고 배포 기준을 관리하면 작은 팀도 반복 검수의 부담을 줄일 수 있다. 다음 배포를 결정할 때는 인상만 기록하지 말고, 변경 전후의 기준선과 운영 지표를 함께 확인해야 한다.