런칭한 기능을 위한 계층형 AI 평가(eval) 프로그램 설계하기

바이브 체크는 출시 전략이지 운영 전략이 아닙니다

팀이 AI 기능을 바이브 체크(내부 데모 몇 번과 슬랙 스레드의 "괜찮아 보여요")로 출시하면, 실패는 나중에 프로덕션에서 표면화되고 비용을 키우며 신뢰를 깎아냅니다. 평가(eval)는 팀이 바이브를 출시 이후에도 살아남는 측정 계약으로 대체하는 방법입니다. 프롬프트는 무한히 논쟁할 수 있지만 평가는 그 논쟁을 숫자로 전환하기 때문에, 평가 설계는 AI 프로덕트 매니저(product manager)의 정의적 스킬로 빠르게 자리잡고 있습니다.

요구되는 것은 완벽한 커버리지가 아닙니다. 무엇을 출시하고 무엇을 롤백할지 결정할 만큼의 신호입니다. 작동하는 평가 프로그램은 방금 한 변경이 기능을 개선했는지, 아니면 기존 케이스를 조용히 깨뜨렸는지 알려줍니다.

단일 티어로는 표면을 다 덮을 수 없습니다

대부분의 팀은 한 가지 평가 방식을 잡고 모든 것을 그 안에 욱여넣습니다. 사람 리뷰는 확장이 어렵고, 코드 평가는 주관적 실패를 놓치며, LLM 저지(judge)는 보정하지 않으면 표류합니다. 해결책은 가장 좋은 티어를 고르는 것이 아니라, 각 실패 모드를 실제로 맞는 티어에 배정하는 것입니다.

사람 평가는 판단을 잡습니다. 톤, 브랜드 보이스, "이게 실제로 도움이 되는가", 엣지 케이스(edge case) 적정성. 인라인 thumbs up/down에 주간 30개 샘플 전문가 리뷰를 더합니다. 데이터는 풍부하지만 비싸고 희소하므로, 사람만이 답할 수 있는 질문에 아껴 쓰세요.

코드 평가는 결정론적 실패를 잡습니다. 포맷 깨짐, 스키마 불일치, 레이턴시 예산, 비용 상한, PII 패턴. 싸고 빠르며 하드 통과/실패를 줍니다. 문제 공간의 좁은 단면을 다루지만 그 단면은 완벽하게 다룹니다.

LLM 저지는 열린 결과의 품질을 잡습니다. 환각(hallucination), 검색 관련성, 요약 일관성. 확장 가능하고 자연어로 점수를 설명하며, 작은 라벨링 세트로 보정하여 점수에 의미가 생기도록 합니다.

Anthropic의 평가 도구 문서는 LLM 저지 패턴을 정리합니다 (대규모 점수를 신뢰하기 전에 사람 라벨에 대비해 저지를 검증하는 방법 포함). Anthropic의 리서치 페이지는 프로덕션 팀이 채점 루브릭을 설계하는 방식을 알려주는 정렬과 평가 방법론 자료를 모아둡니다.

Design a tiered AI eval program prompt 작동 방식

프롬프트는 6단계로 진행됩니다. Step 1은 사용자 관점에서 기능이 잘못될 수 있는 5-8가지 방식을 프로덕션 예시 한 줄과 함께 나열하도록 강제합니다. "사용자 관점" 프레이밍이 중요합니다. 모델 관점에서 실패 모드를 나열하는 팀은 어떤 사용자도 불평하지 않은 추상적 지표를 얻게 됩니다.

Step 2는 각 실패 모드에 티어를 배정합니다. 톤과 브랜드 보이스는 사람 리뷰. 포맷과 레이턴시는 코드 평가. 환각과 도움도는 LLM 저지. 배정마다 한 줄 근거가 규율입니다. 이를 건너뛰는 팀은 이미 인프라를 갖춘 티어로 기본 회귀하는 경향이 있습니다.

Step 3은 골든 셋(golden set)을 만듭니다. 실제 트래픽을 반영하는 50-150개 입력으로, 60 percent 일반 케이스, 25 percent 기존 실패 케이스, 15 percent 적대적/엣지 케이스 비중. 프로덕션 로그(익명화)에서 가져오는 것은 비협상 사항입니다. 합성만으로 구성된 골든 셋은 팀의 상상력을 테스트하지 프로덕트의 현실을 테스트하지 않습니다.

Step 4는 LLM 저지 루브릭을 작성합니다. 프롬프트는 명시적 통과/실패 정의, 고정된 점수 스케일, 저지에 입력할 정확한 텍스트 스니펫을 강제합니다. 모호한 루브릭은 일관성 없는 점수를 만들고, 일관성 없는 점수는 모든 점수를 논쟁으로 만듭니다.

Step 5는 케이던스를 배선합니다. AI 표면을 건드리는 모든 PR에 코드 평가, 주간 30개 프로덕션 샘플 사람 리뷰, 월간 골든 셋 갱신. 케이던스가 프로그램을 살아 있게 합니다. 평가 스위트를 한 번 만들고 떠난 팀은 한 분기 안에 그 스위트가 부패하는 것을 보게 됩니다.

Step 6은 릴리즈 게이트 임계값을 설정합니다. 숫자가 없으면 모든 회귀가 판단 호출이 되고, 대부분의 판단 호출은 출시 쪽으로 기웁니다.

코드 평가가 LLM 저지보다 나을 때

확장된다는 이유로 LLM 저지를 모든 곳에 쓰고 싶어집니다. 더 싼 선택은 종종 코드 평가입니다. 실패 모드에 결정론적 정확성 신호(유효한 JSON, 응답 길이가 상한 이하, 레이턴시가 예산 이하, PII 패턴 미일치)가 있다면 코드 평가가 무료로 잡고 밀리초 안에 실행됩니다. LLM 저지는 결정론적 로직이 결정할 수 없는 케이스에만 남겨두세요.

Amplitude의 SaaS 지표 글은 같은 원리를 프로덕트 분석에 적용합니다. 측정이 싼 것을 먼저 계측하고, 싼 신호가 답할 수 없는 질문에만 비싼 측정을 아끼는 것입니다. 같은 휴리스틱이 AI 품질에도 적용됩니다.

When to use it

• 바이브 체크로 AI 기능을 출시했고, 사용자로부터 테스트하지 않은 실패에 대해 듣고 있습니다.
• 두 번 연속의 PR이 지난주에 작동하던 프로덕션 동작을 깨뜨렸는데 어느 것도 플래그를 띄우지 못했습니다.
• 새 모델 버전이 나왔지만 비교 데이터가 없어 업그레이드 여부를 판단할 수 없습니다.
• 요청당 비용이 오르고 있는데 릴리즈 전에 스파이크를 잡는 평가 게이트가 없습니다.
• 규제기관, 고객, 임원이 품질을 어떻게 측정하는지 묻고 있는데 한 페이지로 답할 게 없습니다.

Common pitfalls

• 단일 티어 커버리지. 한 티어로 모든 실패 모드를 다룰 수 없습니다. 모드별로 티어를 배정하세요.
• 합성만의 골든 셋. 프로덕션 로그 없이는 평가가 상상력을 테스트하지 현실을 테스트하지 않습니다. 익명화하고 실제 트래픽을 포함하세요.
• 보정되지 않은 LLM 저지. 30-50개 사람 라벨 예시로 보정하지 않은 저지는 신호가 아니라 숫자만 만들어냅니다.
• 킬 스위치 없는 평가 스위트. 회귀가 릴리즈를 막을 수 없다면 그 스위트는 장식입니다.

Sources

• Anthropic eval tool documentation - Anthropic
• Anthropic Research - Anthropic
• SaaS metrics that matter - Amplitude
• The most important PM skill - Silicon Valley Product Group
• Retention engagement growth: the silent killer - Reforge