평가, 메트릭, 회귀 테스트

Claude 애플리케이션은 "대체로 잘 답한다"는 인상만으로 출시할 수 없다. 데모에서는 한두 번 좋은 답이 나오면 충분해 보인다. 그러나 실제 제품에서는 사용자가 다른 질문을 던지고, 문서가 바뀌고, 도구가 실패하고, 비용 제한이 걸리고, 정책 위반을 유도하는 입력이 들어온다. 이때 필요한 것은 더 긴 프롬프트가 아니라 반복 가능한 평가 체계다.

평가는 모델을 불신하기 위한 절차가 아니다. 팀이 "좋은 결과"의 의미를 같은 방식으로 이해하게 만드는 제품 언어다. 프롬프트를 바꾸기 전과 후, 모델을 바꾸기 전과 후, 검색 인덱스를 교체하기 전과 후에 같은 기준으로 다시 시험할 수 있어야 한다.

AI 생성 이미지

평가 단위를 쪼개야 한다

가장 단순한 평가는 입력 하나와 출력 하나를 비교하는 방식이다. 예를 들어 "이 문서를 세 줄로 요약하라"는 입력에 대해 결과가 맞는지 보는 식이다. 하지만 Claude를 제품에 연결하면 평가 대상은 최종 답변보다 넓어진다.

특히 도구를 쓰는 에이전트형 시스템에서는 한 번의 실행 안에 검색, 계산, API 호출, 중간 판단, 오류 복구가 모두 들어간다. Anthropic은 에이전트 평가를 설명하면서 평가 단위를 task, trial, grader, transcript 또는 trace, outcome, evaluation harness로 나누어 볼 것을 제안한다.¹ 이 관점은 Claude 애플리케이션을 제품 수준으로 관리할 때 매우 유용하다.

이렇게 쪼개면 평가 질문이 선명해진다. "최종 답이 맞았는가?"뿐 아니라 다음 질문을 따로 볼 수 있다.

• 올바른 문서를 검색했는가?

• 필요할 때 도구를 호출했는가?

• 도구 오류가 났을 때 복구했는가?

• 근거 없는 내용을 지어내지 않았는가?

• 답변은 정책상 허용 가능한가?

• 같은 task를 여러 번 실행해도 안정적인가?

• 비용과 지연 시간은 허용 범위 안에 있는가?

실패의 위치를 알아야 개선도 가능하다. 검색이 틀렸는데 프롬프트만 고치면 효과가 작다. 도구 스키마가 모호한데 모델을 바꾸면 비용만 늘어난다. 평가는 문제를 모델 탓, 프롬프트 탓, 데이터 탓, 제품 설계 탓으로 나누어 보는 장치다.

성공 기준은 관찰 가능해야 한다

평가를 만들기 전 먼저 정할 것은 success criteria, 즉 성공 기준이다. "좋은 답변", "전문적인 답변", "친절한 답변"은 기준이 아니다. 사람마다 다르게 해석하기 때문이다. 제품에서 쓸 수 있는 기준은 관찰 가능해야 한다.

예를 들어 고객지원 답변의 성공 기준은 이렇게 바꿀 수 있다.

작업별로 봐야 할 기준도 다르다.

문서 요약은 핵심 누락, 왜곡, 근거 위치가 중요하다. 분류 작업은 라벨 정확도와 애매한 사례 처리 방식이 중요하다. RAG 답변은 groundedness, 즉 답변이 제공된 문서에 의해 뒷받침되는지가 중요하다. 도구 사용 에이전트는 최종 답변뿐 아니라 도구 선택, 호출 순서, 입력값, 실패 복구를 봐야 한다. 안전 관련 기능은 올바른 거절과 과잉거절을 함께 봐야 한다.

좋은 성공 기준은 자동 채점과 사람 평가로 연결된다.

• 형식 준수: JSON 스키마 검사, 필수 필드 검사

• 정확성: 참조 정답과 비교, 단위 테스트, 계산 결과 검증

• 완전성: 필수 항목 포함 여부 검사

• 근거성: 답변 문장과 문서 조각의 일치 여부 확인

• 안전성: 금지 조언, 개인정보 노출, 정책 위반 표현 탐지

• 비용: 입력·출력 토큰, 도구 호출 수, 캐시 적중률

• 지연 시간: 전체 응답 시간, 첫 토큰 시간, 도구별 대기 시간

모든 항목을 하나의 점수로 합치면 위험하다. 평균 점수 92점이어도 개인정보를 한 번 노출하면 출시하면 안 된다. 그래서 평가표에는 전체 점수와 별도로 출시 차단 조건을 두어야 한다. 예를 들어 "정책 위반 0건", "근거 없는 법률 조언 0건", "JSON 파싱 실패율 1% 미만"처럼 정한다.

평가셋은 작은 현실이어야 한다

평가셋은 모델이 맞혀야 할 시험지가 아니다. 제품이 실제로 마주칠 현실의 축소판이다. 따라서 예쁜 정상 사례만 넣으면 안 된다. 실제 사용자 질문, 엣지 케이스, 과거 실패, 도구 오류, 검색 실패, 정책 위반 유도, 과잉거절 사례를 함께 넣어야 한다.

평가셋은 보통 다음 층으로 나누어 관리한다.

각 평가 케이스에는 입력만 저장하지 말고 기대 행동도 함께 적어야 한다.

평가 케이스 ID: refund_023
작업: 환불 정책 기반 고객 답변
입력: 고객 문의 + 환불 정책 문서 조각
기대 행동:
- 정책 문서에 있는 조건만 근거로 답한다.
- 환불 가능 여부가 불확실하면 상담원 확인으로 에스컬레이션한다.
- 고객에게 내부 정책 ID를 노출하지 않는다.
자동 채점:
- JSON 스키마 통과
- evidence 필드에 문서 ID 포함
- 금지 표현 없음
사람 평가:
- 고객이 이해하기 쉬운가
- 불확실성을 적절히 표현했는가
출시 차단:
- 문서에 없는 환불 약속을 하면 실패

이런 형식은 번거로워 보이지만, 나중에 팀의 시간을 크게 줄인다. 새로운 프롬프트가 나왔을 때 "느낌상 좋아졌다"가 아니라 "환불 엣지 케이스에서는 좋아졌지만 과잉거절이 늘었다"고 말할 수 있다.

평가셋을 만들 때는 데이터 분포도 중요하다. 쉬운 사례 90개와 어려운 사례 10개를 섞어 평균을 내면 어려운 문제의 실패가 가려진다. 고위험 사례는 별도 그룹으로 보고, 통과 기준도 더 엄격하게 잡아야 한다.

자동 평가와 사람 평가는 역할이 다르다

자동 평가는 빠르고 일관적이다. 수백 개 케이스를 매번 실행할 수 있고, CI/CD에 넣을 수도 있다. 그러나 모든 품질을 자동으로 판정할 수는 없다. 사람 평가는 느리지만 맥락, 유용성, 미묘한 환각, 사용자 만족도를 더 잘 본다.

자동 평가에 적합한 항목은 다음과 같다.

• JSON, XML, Markdown 표 등 출력 형식 준수

• 필수 필드와 금지 필드 존재 여부

• 정답이 명확한 분류·추출·계산

• 참조 문서 ID 또는 조항 번호 포함 여부

• 도구 호출 여부와 입력값 검증

• 금지어, 개인정보 패턴, 비밀값 노출 탐지

• 토큰 사용량, 비용, 지연 시간, 오류율

사람 평가에 적합한 항목은 다르다.

• 답변이 실제 업무에 도움이 되는가

• 사용자 상황을 제대로 이해했는가

• 불확실성을 정직하게 표현했는가

• 근거는 있지만 결론이 과장되지 않았는가

• 거절해야 할 요청을 안전하게 거절했는가

• 거절하지 않아도 되는 요청을 과잉거절하지 않았는가

• 말투가 브랜드와 상황에 맞는가

LLM을 평가자로 쓰는 방식도 가능하다. 예를 들어 Claude나 다른 모델에게 루브릭을 주고 답변을 채점하게 할 수 있다. 이를 흔히 LLM-as-judge라고 부른다. 다만 이 방식은 사람 평가를 완전히 대체하지 않는다. 먼저 사람 평가와 비교해 어느 정도 일치하는지 확인해야 한다. 특히 법무, 의료, 금융, 안전 정책처럼 실패 비용이 큰 영역에서는 모델 평가자의 점수를 참고값으로 두고, 최종 기준은 사람 검토와 규칙 기반 검사로 보완해야 한다.

사람 평가를 쓸 때는 루브릭을 짧고 명확하게 만든다.

평가자가 여러 명이면 같은 샘플을 일부 겹쳐 평가하게 한다. 평가자마다 점수가 크게 다르면 루브릭이 모호하다는 뜻이다. 이때는 모델을 고치기 전에 평가 기준부터 고쳐야 한다.

배치 테스트와 회귀 테스트로 변경을 관리한다

Claude 애플리케이션은 작은 변경에도 결과가 달라질 수 있다. 시스템 프롬프트 한 줄, 모델 버전, temperature, 도구 설명, RAG 청크 크기, 검색 랭킹 방식, max_tokens가 모두 영향을 준다. 그래서 변경 전후를 같은 평가셋으로 반복 실행하는 batch testing이 필요하다.

배치 테스트는 다음 순서로 운영한다.

1. 고정된 평가셋을 준비한다.

2. 현재 프로덕션 설정을 기준선으로 실행한다.

3. 새 프롬프트, 모델, 도구, 인덱스 설정을 적용해 다시 실행한다.

4. trial별 점수, 최종 답변, transcript, 도구 호출, 비용, 지연 시간을 비교한다.

5. 개선된 영역과 나빠진 영역을 분리한다.

6. 출시 차단 조건을 통과한 경우에만 카나리 배포로 넘긴다.

회귀 테스트의 목적은 "더 좋아졌는가?"보다 "예전에 되던 것이 아직 되는가?"에 가깝다. capability 평가에서는 낮은 통과율에서 시작해 점차 개선할 수 있다. 반면 회귀 테스트는 통과율이 매우 높아야 한다. 과거에 이미 해결한 실패가 다시 나타난다면 사용자에게는 명백한 품질 저하다.

에이전트 시스템에서는 최종 답변만 비교하면 부족하다. 최종 답이 우연히 맞아도 중간 과정이 위험할 수 있다.

예를 들어 고객지원 에이전트가 최종적으로 맞는 답을 냈더라도, 중간에 잘못된 고객 계정을 조회했거나 불필요한 개인정보를 도구에 보냈다면 실패로 봐야 한다. 코드 수정 에이전트가 테스트를 통과했더라도, 허용되지 않은 파일을 수정했다면 실패다. 연구 보조 에이전트가 그럴듯한 보고서를 냈더라도, 낮은 품질의 출처만 사용했다면 감점해야 한다.

따라서 transcript와 trace를 함께 저장한다. 여기에는 최소한 다음 항목이 들어간다.

• 평가 케이스 ID

• 모델명과 버전

• 시스템 프롬프트 버전

• 사용자 입력과 제공 문서 ID

• 도구 스키마 버전

• 검색 인덱스 버전

• 파라미터 설정

• 도구 호출 목록과 결과

• 최종 답변

• stop reason

• 토큰 사용량과 지연 시간

• 자동 채점 결과

• 사람 평가 결과

• 실행 날짜와 배포 후보 버전

이 기록이 있어야 나중에 "왜 어제는 통과했는데 오늘은 실패했는가"를 추적할 수 있다.

운영 로그를 평가 루프로 되돌린다

출시 전 평가셋은 아무리 잘 만들어도 현실 전체를 담을 수 없다. 제품이 출시되면 사용자는 예상하지 못한 방식으로 질문한다. 문서도 바뀐다. 정책도 바뀐다. 특정 시즌에는 문의 유형이 몰린다. 이 변화를 데이터 분포 변화라고 볼 수 있다.

그래서 운영 이후의 평가 루프가 필요하다.

첫째, 온라인 로그에서 실패 후보를 찾는다. 사용자가 재질문을 많이 한 대화, 상담원에게 에스컬레이션된 사례, 낮은 평점을 받은 답변, 도구 오류가 발생한 trial, 비용이 비정상적으로 높았던 요청을 모은다. 개인정보와 민감 정보는 마스킹하거나 제거한 뒤 평가 후보로 저장한다.

둘째, 사용자 피드백을 평가 기준과 연결한다. "별로예요"라는 피드백만으로는 고치기 어렵다. 가능하면 사용자가 이유를 선택하게 한다.

• 답이 틀림

• 근거가 부족함

• 너무 장황함

• 내 상황을 이해하지 못함

• 거절이 부적절함

• 형식이 맞지 않음

• 응답이 느림

셋째, A/B 테스트를 쓴다. 새 프롬프트나 모델이 오프라인 평가에서 좋아 보여도 실제 사용자 만족도는 다를 수 있다. 일부 트래픽에만 새 설정을 적용하고, 품질 점수, 재질문율, 에스컬레이션율, 비용, 지연 시간을 함께 본다. 단, 안전이나 개인정보와 관련된 변경은 A/B 테스트 전에 강한 오프라인 게이트를 통과해야 한다.

넷째, 새 실패 사례를 회귀 세트에 편입한다. 운영 중 발견한 중요한 실패는 한 번 고치고 잊으면 안 된다. 평가 케이스로 만들고, 기대 행동과 출시 차단 조건을 붙인다. 이렇게 해야 같은 실패가 다음 배포에서 다시 나타나지 않는다.

평가 루프는 다음처럼 순환한다.

운영 로그 수집
→ 실패 후보 선별
→ 개인정보 마스킹
→ 평가 케이스 작성
→ 프롬프트·RAG·도구 개선
→ 배치 테스트
→ 회귀 테스트
→ 카나리 배포
→ 다시 운영 로그 확인

이 루프가 자리 잡으면 Claude 애플리케이션은 감으로 운영되는 기능에서 관리 가능한 제품으로 바뀐다.

최소 평가 체계부터 시작한다

처음부터 거대한 평가 플랫폼을 만들 필요는 없다. 작은 팀이라면 스프레드시트와 스크립트만으로도 시작할 수 있다. 중요한 것은 도구의 화려함이 아니라 같은 질문을 반복해서 던지고, 같은 기준으로 채점하고, 결과를 기록하는 습관이다.

최소 평가 체계는 다음 다섯 가지면 충분하다.

1. 평가 케이스 30개: 정상 사례, 엣지 케이스, 과거 실패를 섞는다.

2. 성공 기준 표: 정확성, 완전성, 형식, 근거성, 안전성, 비용, 지연 시간을 정의한다.

3. 자동 검사 스크립트: 형식, 필수 필드, 금지 표현, 비용 한도를 검사한다.

4. 사람 평가 루브릭: 유용성, 맥락 적합성, 과잉거절, 미묘한 환각을 본다.

5. 변경 비교 리포트: 배포 전후 점수, 실패 케이스, 비용 변화를 남긴다.

이후 제품이 커지면 평가셋을 늘리고, trace 저장을 자동화하고, CI/CD와 연결하고, 대시보드를 만든다. 하지만 출발점은 단순하다. "무엇이 성공인가"를 적고, "그 성공이 계속 유지되는가"를 반복해서 확인하는 것이다.

Claude를 제품에 넣는 순간 프롬프트는 코드처럼 관리되어야 한다. 모델 설정은 인프라처럼 기록되어야 한다. 검색 인덱스와 도구 스키마는 배포 대상처럼 검증되어야 한다. 평가, 메트릭, 회귀 테스트는 그 모든 변경을 안전하게 움직이게 하는 품질 안전망이다.

체크리스트

• 평가 단위를 task, trial, grader, trace, outcome으로 나누어 정의했는가?

• 작업별 성공 기준이 관찰 가능한 문장으로 쓰였는가?

• 자동 채점 항목과 사람 평가 항목을 분리했는가?

• 정상 사례뿐 아니라 엣지 케이스, 과거 실패, 정책 위반 유도, 과잉거절 사례를 포함했는가?

• 모델·프롬프트·도구·RAG 변경 전후를 같은 평가셋으로 비교하는가?

• 최종 답변뿐 아니라 도구 호출과 trace를 저장하는가?

• 비용, 토큰, 지연 시간, 오류율을 품질 지표와 함께 보는가?

• 운영 중 발견한 실패를 회귀 테스트 세트에 추가하는가?

참고

¹Demystifying evals for AI agents