AI 평가 루브릭 실전 설계

AI 기능을 운영에 올리면서 평가 루브릭이 없으면 이상한 반복이 생깁니다. 프롬프트를 바꾸고 모델을 바꾸고 도구 연결을 조정하는데도, 시스템이 실제로 더 좋아졌는지 누구도 분명하게 말하지 못합니다.

프로덕션 루브릭이 답해야 하는 질문

좋은 루브릭은 주관적인 감상을 반복 가능한 출시 기준으로 바꿉니다.

많은 팀이 정확도 점수 하나부터 만들지만, 실전에서는 그것만으로는 부족합니다. 법률 답변의 환각, 출처 누락, 지나치게 장황한 설명은 같은 결함으로 다뤄지면 안 됩니다.

예를 들면 다음처럼 나눌 수 있습니다.

이렇게 해야 평가가 제품 리스크와 바로 연결됩니다.

강한 평가표는 보통 세 층으로 나뉩니다.

이 구조를 쓰면 한 지표만 올리다가 다른 중요한 속성을 망치는 일을 줄일 수 있습니다.

행복 경로 프롬프트만 모아놓은 벤치마크로는 부족합니다. 다음이 포함돼야 합니다.

목적은 학술적 완성도가 아니라 출시 신뢰도입니다.

모델, 프롬프트, 도구 흐름을 바꾸기 전에는 항상 같은 루브릭으로 기존 시스템과 비교해야 합니다. 다음과 같으면 막아야 합니다.

최고의 평가 루브릭은 보고서가 아니라, 팀이 AI를 안전하게 출시하는 운영 체계의 일부입니다.

AI 에이전트는 많이 기억할수록 좋아 보이지만, 실제 운영에서는 메모리 예산과 요약 규칙이 품질을 좌우합니다.

모델 API가 단순 텍스트 응답을 넘어 도구 호출 플랫폼으로 바뀌고 있습니다. Responses API와 Remote MCP를 제품 관점에서 어떻게 봐야 하는지 정리합니다.

불안정한 테스트를 단순 재시도로 덮지 않고 신뢰도, 소유권, 격리 기준으로 관리하는 방법을 정리합니다.

모바일 안정성은 단순히 크래시를 줄이는 것이 아니라, 어느 수준까지 허용하고 언제 출하를 멈출지 결정하는 운영 문제입니다.