3장. 평가 설계

학습 목표

• 실제 사용 분포를 대표하고 경계 사례와 드문 고위험 사례를 따로 다루는 평가 세트를 구성한다.
• 코드 채점, LLM 채점, 사람 채점의 장단점을 비교하고 기준마다 맞는 채점 방식을 고른다.
• LLM 채점기를 사람 채점과 대조해 보정하고, 점수 상승이 실제 개선인지 가린다.
• 역량 평가와 회귀 평가, 오프라인 평가와 온라인 지표의 역할을 구분해 함께 설계한다.
• 평가 결과를 유형별로 읽고 출시, 조건부 출시, 보류 가운데 하나를 근거와 함께 정한다.

들어가며

어느 팀이 상담 봇의 새 프롬프트를 배포하며 이렇게 말했습니다. "예시 열 개를 돌려 봤는데 확실히 좋아졌어요." 일주일 뒤, 해외 주문 문의에서만 배송비를 틀리게 안내하는 문제가 발견됐습니다. 열 개의 예시에는 해외 주문이 하나도 없었습니다. OpenAI는 이런 방식을 "느낌으로 하는 평가(vibe-based evals)"라 부르며 대표적인 실패 패턴으로 꼽습니다.

평가는 AI 기능의 품질을 숫자로 확인하는 유일한 방법이고, 그 숫자가 출시 판단의 근거가 됩니다. 그래서 평가 설계는 개발자만의 일이 아닙니다. 무엇을 성공으로 볼지(2장)를 정한 기획자가, 그 성공을 어떤 데이터와 채점으로 확인할지까지 책임져야 합니다. OpenAI는 평가를 일찍, 자주 하는 평가 주도 개발을 권하고, 평가는 끝이 있는 일이 아니라 계속되는 과정이라고 말합니다.

이 장은 평가 세트를 꾸리는 법에서 시작해 세 가지 채점 방식과 그 고르는 순서, LLM 채점기를 믿을 수 있게 만드는 법을 봅니다. 그다음 역량 평가와 회귀 평가, 오프라인 평가와 온라인 지표를 구분하고, 마지막으로 평가 결과를 읽고 출시를 판단하는 법을 다룹니다.

핵심 개념

평가란 무엇인가

평가(eval)는 모델이나 기능의 성능을 재는 구조화된 시험입니다. OpenAI의 정의도 같습니다. 평가는 세 부분으로 이뤄집니다. 시험 문제에 해당하는 평가 세트, 답을 매기는 채점 방식, 그리고 합격선에 해당하는 성공 기준입니다.

비유하자면 평가는 운전면허 시험입니다. 시험 코스(평가 세트)가 실제 도로와 비슷해야 하고, 채점관(채점 방식)이 일관돼야 하며, 합격선(성공 기준)이 미리 정해져 있어야 합니다. 시험 코스가 주차장뿐이면 합격해도 도로에서 사고가 납니다. 채점관이 기분에 따라 점수를 주면 같은 실력이 다르게 평가됩니다.

평가 과정의 다섯 단계

OpenAI는 평가 과정을 다섯 단계로 설명합니다.

1. 평가 목표 정의. 무엇을 확인하려는가. 2장의 성공 기준에서 온다.
2. 데이터 수집. 그 목표를 확인하는 데 어떤 데이터가 필요한가.
3. 지표 정의. 성공 기준이 충족됐는지 어떻게 확인할 것인가.
4. 실행과 비교. 평가를 돌리고 버전 사이를 비교한다.
5. 지속 평가. 변경이 있을 때마다 평가를 다시 돌린다.

앞 단계의 결과가 다음 단계의 입력입니다. 목표 없이 데이터를 모으면 무엇을 모을지 모르고, 데이터 없이 지표를 정하면 무엇에 붙일지 모릅니다. 마지막 단계가 빠지면 평가는 출시 전 한 번의 행사로 끝나고, 이후의 변경은 다시 느낌으로 판단하게 됩니다.

평가 세트의 대표성

Claude 문서의 첫 번째 평가 설계 원칙은 "과제에 맞춰라"입니다. 평가가 실제 작업의 분포를 반영해야 한다는 뜻입니다. OpenAI도 운영 트래픽의 패턴을 충실히 재현하지 못하는 평가 세트를 "편향된 설계"라는 실패 패턴으로 듭니다.

대표성을 확인하는 가장 쉬운 방법은 비교표입니다.

이런 표에서 큰 차이가 보이면, 평가 점수는 실제 성능을 말해 주지 못합니다. 팀원이 머릿속으로 쓴 질문은 표준어 완결 문장이 많고, 실제 사용자는 줄임말과 오타, 섞인 언어로 묻습니다. 평가 세트의 바탕은 실제 요청에서 무작위로 뽑은 표본이어야 합니다.

경계 사례와 드문 고위험 사례

대표 표본만으로는 부족합니다. Claude 문서는 평가에 경계 사례를 꼭 넣으라고 하며 네 가지를 예로 듭니다. 관련 없거나 존재하지 않는 입력, 지나치게 긴 입력, 채팅이라면 부실하거나 해롭거나 관련 없는 사용자 입력, 그리고 사람끼리도 판정이 갈리는 애매한 사례입니다. OpenAI도 평가 데이터에 전형적인 사례, 경계 사례, 적대적 사례를 함께 넣으라고 합니다.

애매한 사례를 "채점이 일관되지 않는다"는 이유로 빼고 싶은 유혹이 있습니다. 하지만 실제 운영에서 가장 자주 틀리는 것이 바로 그런 사례입니다. 빼지 말고 별도 표시를 붙여 넣고, 그 묶음의 결과를 따로 봅니다.

드물지만 피해가 큰 사례(긴급 요청, 안전 관련 질문, 금액이 큰 거래)는 무작위 표본에서 몇 건밖에 나오지 않습니다. 0.4%짜리 유형은 1,000건짜리 표본에 네 건쯤 들어갈 뿐이라 그 유형의 성능을 판정할 수 없습니다. 이런 사례는 따로 모아 충분한 수로 별도 묶음을 만들고, 전체 점수와 따로 합격 여부를 판정합니다.

평가 세트의 출처와 크기

평가 데이터는 여러 곳에서 옵니다. OpenAI는 운영 기록, 도메인 전문가가 만든 데이터, 합성 데이터, 구입한 데이터를 들고, 개발하면서 기록을 남겨 좋은 평가 사례를 캐내라고 합니다.

크기는 "많을수록 좋다"와 "시작은 작게"를 함께 기억합니다. Claude 문서는 자동 채점이 가능하다면 개별 채점의 정밀도가 조금 낮더라도 질문 수가 많은 쪽이, 사람이 손으로 채점한 소수의 고품질 평가보다 낫다고 합니다. Anthropic의 에이전트 평가 글은 실제 실패에서 뽑은 간단한 과제 20~50개면 좋은 출발이라고 말합니다. 작게 시작해 운영에서 찾은 실패로 키워 나가는 것이 현실적인 길입니다.

보류 세트와 과적합

같은 평가 세트를 보면서 프롬프트를 수십 번 고치면, 프롬프트가 그 세트에 맞춰져 점수가 실제 성능보다 높아집니다. 시험 문제를 미리 보고 공부한 학생의 점수가 실력을 말해 주지 못하는 것과 같습니다.

Google PAIR 가이드는 테스트 세트를 모델이 본 적 없는 데이터로 두어야 실제로 얼마나 잘 작동하는지 알 수 있다고 설명하고, Claude 문서의 기준 예시도 보류된 테스트 세트(held-out test set)에서 성능을 판정합니다. 실무에서는 평가 세트를 둘로 나눕니다. 고칠 때 보는 개발 세트와, 고칠 때 보지 않고 최종 판정에만 쓰는 보류 세트입니다. 개발 세트 점수는 크게 올랐는데 보류 세트 점수가 그대로라면, 그 개선은 세트에 맞춘 결과일 가능성이 큽니다.

세 가지 채점 방식

Claude 문서는 채점 방식을 세 가지로 나눕니다.

Anthropic의 에이전트 평가 글도 비슷하게 정리합니다. 코드 채점은 빠르고 싸고 객관적이며 재현 가능하지만 정답과 표현만 다른 올바른 답에 약하고, 모델 채점은 결과가 매번 조금씩 달라질 수 있어 사람 채점과의 보정이 필요하며, 사람 채점은 정답 기준(gold standard)이지만 비싸고 느립니다.

채점 방식을 고르는 순서

Claude 문서의 원칙은 "가장 빠르고, 가장 믿을 만하며, 가장 확장 가능한 방법을 고르라"입니다. 기준마다 다음 순서로 묻습니다.

1. 정답이 정해져 있고 대조할 수 있는가? → 코드 채점.
2. 판단이 필요하지만 루브릭으로 적을 수 있는가? → LLM 채점(사람과 대조해 신뢰도 확인 후).
3. 루브릭이 아직 없거나 전문 판단이 필요한가? → 사람이 대표 표본을 채점해 기준(루브릭과 기준 데이터)을 만든다. 루브릭으로 옮기기 어려운 전문 품질이라면 전문가의 블라인드 비교 자체를 출시 전 평가로 쓴다.

한 기능 안에서도 기준마다 방식이 다릅니다. 환불 안내 답변이라면 "금액이 주문 시스템 값과 같은가"는 코드로, "정책 해석이 맞는가"와 "어조가 가이드에 맞는가"는 루브릭을 준 LLM 채점기로, 그 채점기의 보정과 애매한 사례는 사람이 맡습니다. 하나의 방식으로 모든 기준을 채점하려 하면 비용이나 신뢰도 중 하나를 잃습니다.

LLM 채점기를 믿을 수 있게 만들기

Claude 문서는 LLM 채점의 요령으로 세 가지를 듭니다. 상세하고 명확한 루브릭을 줄 것, "정답/오답"이나 "1~5점"처럼 구체적인 출력을 요구할 것, 점수를 내기 전에 추론하게 할 것. 같은 문서의 예제 코드에는 결과를 만든 모델과 다른 모델로 평가하는 것이 일반적으로 권장된다는 설명도 있습니다.

[루브릭 예: 환불 안내 답변의 정책 해석]
정답(correct): 주문일·상품 상태·결제 수단에 맞는 환불 가능 여부와 기한을 안내했다.
오답(incorrect): 환불 가능 여부나 기한이 정책과 다르거나, 정책에 없는 조건을 덧붙였다.
판정이 어려우면 "unsure"로 판정한다.
출력: 먼저 판단 근거를 한두 문장으로 쓰고, 마지막 줄에 correct / incorrect / unsure 중 하나만 쓴다.

루브릭만으로는 부족합니다. OpenAI는 사람의 평가로 자동 채점을 보정하고, LLM 채점기가 더 빠르고 싸면서 사람의 판정과 꾸준히 일치할 때 규모를 키우라고 합니다. 순서는 이렇습니다. 사람이 대표 표본을 루브릭으로 채점하고, 같은 표본을 LLM 채점기로 채점해 일치도를 보고, 어긋나는 기준은 루브릭을 고치고, 일치도가 목표를 넘으면 전체에 쓰되 주기적으로 사람 표본과 다시 대조합니다.

LLM 채점기에는 알려진 편향이 있습니다. OpenAI는 LLM 채점기의 편향으로 응답의 제시 순서에 따른 위치 편향을 들고, 더 믿을 만한 방식으로 쌍 비교나 통과/실패 판정을 권합니다. 쌍 비교를 쓸 때는 두 응답의 순서를 바꿔 두 번 채점해 위치 편향을 줄입니다. 내용과 관계없이 긴 답을 더 좋게 보는 경향(길이 편향)도 흔합니다. 그래서 점수가 크게 뛰면 먼저 채점 기록을 직접 읽어 봅니다. Anthropic은 많은 시도의 기록과 점수를 읽어 보지 않으면 채점이 제대로 작동하는지 알 수 없다고 말합니다.

사람 채점의 자리

사람 채점은 피할 수 있으면 피하라는 말이 사람 채점을 없애라는 뜻은 아닙니다. 사람 채점은 세 곳에서 꼭 필요합니다. 처음 루브릭을 만들고 기준 데이터를 세울 때, LLM 채점기를 보정할 때, 그리고 정답이 없고 전문 판단이 필요한 출시 전 비교에서입니다.

사람 채점도 일관성을 관리해야 합니다. Google PAIR 가이드는 사람이 라벨을 해석하는 방식의 차이를 찾아내는 일이 모델 개발을 현실에 대비시킨다고 설명합니다. 두 평가자가 같은 표본을 따로 채점해 일치도를 보고, 갈린 사례를 함께 읽으며 루브릭을 고칩니다. 두 버전을 비교할 때는 평가자가 어느 버전인지 모르게 나란히 보여 주는 블라인드 비교가 편향을 줄입니다.

역량 평가와 회귀 평가

Anthropic은 평가를 목적에 따라 둘로 나눕니다.

역량 평가에서 충분히 잘하게 된 과제는 회귀 묶음으로 "졸업"시켜 계속 돌리며 성능이 떨어지는지 감시합니다. 역량 평가에서 해결 가능한 모든 과제를 통과해 더 이상 개선 여지를 보여 주지 못하는 상태를 Anthropic은 평가 포화라고 부릅니다. 포화된 평가는 변별력을 잃으므로, 운영에서 찾은 새 실패로 어려운 과제를 보충합니다.

오프라인 평가와 온라인 지표

오프라인 평가는 준비한 평가 세트로 사용자에게 내보내지 않고 결과를 재는 평가입니다. 빠르고 반복할 수 있지만, 평가 세트가 담지 못한 상황과 사용자 행동은 알 수 없습니다. 온라인 지표는 실제 운영에서 재는 지표입니다. 재생성 클릭, 상담원 전환, 이탈, 신고, 구매 전환이 그렇습니다.

Anthropic은 가장 효과적인 팀이 방법을 섞어 쓴다고 설명합니다. 빠른 반복에는 자동 평가를, 실제 결과 확인에는 운영 모니터링을, 충분한 트래픽이 있을 때 큰 변경의 검증에는 A/B 실험을, 자동 평가가 놓치는 부분에는 사용자 피드백과 기록 검토를, 보정에는 주기적인 사람 검토를 씁니다.

오프라인 점수가 좋은데 온라인 지표가 움직이지 않으면, 평가 세트에 없는 상황이 실제에 있다는 신호입니다. 실제 기록을 읽어 빠진 상황을 찾고 평가 세트에 더합니다.

한 번 성공과 매번 성공

같은 과제를 여러 번 시도할 때 성공을 세는 방법도 요구사항에 따라 다릅니다. Anthropic은 k번 시도 중 적어도 한 번 성공할 확률을 pass@k로, k번 모두 성공할 확률을 pass^k로 설명합니다. 시도마다 성공 확률이 p로 같고 서로 독립이라면 pass^k는 p의 k제곱이어서, 한 번 성공률이 90%여도 세 번 연속 성공은 약 73%에 그칩니다. 사람이 여러 후보 가운데 하나를 고르는 기능(문구 후보 제안)이라면 pass@k가, 고객이 매번 같은 품질의 답을 받아야 하는 기능(자동 응대 에이전트)이라면 pass^k가 맞는 지표입니다. 같은 점수라도 무엇을 세느냐에 따라 출시 판단이 달라집니다.

평가 결과로 출시 여부 판단하기

평가 결과를 받으면 숫자를 보기 전에 세 가지를 먼저 확인합니다.

1. 평가 세트가 실제를 대표하는가. 대표하지 않으면 점수가 높아도 근거가 아니다.
2. 채점이 믿을 만한가. LLM 채점기가 사람과 대조됐는가, 점수 상승이 길이 같은 엉뚱한 요인 때문은 아닌가.
3. 보류 세트에서 확인했는가. 개발 세트에서만 오른 점수는 과적합일 수 있다.

세 가지를 통과하면 결과를 유형별로 읽습니다. 전체 점수가 기준을 넘어도 특정 유형이 크게 미달할 수 있습니다. 그때의 선택지는 세 가지입니다.

기능의 핵심 가치(예: 상담 처리 시간 절감)를 출시 전에 확인해야 한다면, 그 기준은 개선 목표가 아니라 차단 기준에 넣어 둡니다. NIST AI RMF는 시스템이 의도한 목적과 목표를 달성하는지, 개발이나 배포를 진행할지를 판단하라고 합니다(MANAGE 1.1). 이 판단은 결과를 보기 전에 합의한 기준으로 내려야 합니다. 결과를 본 뒤 기준을 정하면 숫자에 맞춰 기준을 고르게 됩니다.

평가 계획서

평가 계획서는 한 장으로 씁니다.

[평가 계획서]
대상 기능과 버전:
성공 기준(2장에서): 차단 기준 / 개선 목표
평가 세트: 출처, 크기, 유형별 구성(실제 비율 대비), 경계 사례 묶음, 고위험 묶음, 각 묶음에서 떼어 둔 보류 세트
채점: 기준별 방식(코드/LLM/사람), LLM 채점기 보정 방법과 일치도 목표
회귀 묶음: 구성, 실행 시점(변경마다), 통과 조건
온라인 지표: 출시 후 볼 지표와 알림 기준
판정 규칙: 출시 / 조건부 출시 / 보류의 조건
일정과 담당자:

깊이 읽기

점수가 오르면 좋아진 것인가

평가 점수가 올랐다는 보고를 받으면 네 가지 가능성을 차례로 지웁니다. 첫째, 채점기가 엉뚱한 특징을 보상했을 수 있습니다. 답이 길어지자 LLM 채점기 점수가 오르는 일은 흔합니다. 기록 표본을 사람이 직접 읽어 확인합니다. 둘째, 같은 세트에 맞춰 고쳤을 수 있습니다. 보류 세트에서도 올랐는지 봅니다. 셋째, 평가 세트가 바뀌었을 수 있습니다. 문항을 추가하거나 빼면 점수의 의미가 달라지므로 버전을 남깁니다. 넷째, 무작위 변동일 수 있습니다. 같은 평가를 여러 번 돌려 흔들림의 폭을 알아 둡니다.

이 네 가지를 지운 뒤에 남는 상승이 실제 개선입니다. 이 순서를 지키는 팀은 "점수는 올랐는데 고객 불만은 그대로"라는 상황을 훨씬 덜 겪습니다.

평가 세트의 수명

평가 세트는 만들고 끝나는 자산이 아닙니다. OpenAI는 평가를 끝이 아닌 여정이라 부르며 평가 세트를 시간이 지나며 키우라고 하고, Anthropic은 포화된 평가가 개선 여지를 보여 주지 못한다고 경고합니다. 평가 세트의 수명 주기는 이렇습니다.

1. 실제 실패 20~50건과 대표 표본으로 시작한다.
2. 운영에서 찾은 새 실패를 회귀 묶음에 더한다.
3. 잘하게 된 역량 과제는 회귀 묶음으로 졸업시킨다.
4. 사용자와 입력의 분포가 바뀌면 대표 표본을 다시 뽑는다.
5. 버전을 남겨 이전 결과와 비교할 수 있게 한다.

"한 번 만들면 바꾸지 않는다"는 원칙은 비교 가능성을 지키려는 좋은 의도에서 나오지만, 분포가 바뀐 세상에서 낡은 시험지로 계속 시험을 보게 만듭니다. 비교 가능성은 버전 관리로 지키고, 세트는 계속 키웁니다.

온라인 지표의 귀속 문제

출시 뒤 지표가 좋아졌다고 해서 기능 덕분이라고 말할 수는 없습니다. 같은 기간에 계절, 행사, 다른 기능의 변경이 함께 일어나기 때문입니다. Google SRE는 시간이 관측 지표를 바꾸는 가장 큰 요인 가운데 하나라고 지적합니다. 출시 전후 비교는 평일과 주말, 행사 기간과 평상시를 섞어 비교하게 만들 수 있습니다.

효과를 기능에 귀속하려면 같은 기간에 기능을 본 집단과 보지 않은 집단을 무작위로 나눠 비교해야 합니다. 그래서 사업 지표에 대한 효과는 A/B 실험으로 잽니다. 트래픽이 충분하지 않으면 실험의 힘이 부족하므로, 그때는 운영 지표와 기록 검토, 사용자 인터뷰를 함께 보고 결론의 확실성을 낮춰 보고합니다.

실무 장면

푸른길자전거의 고장 신고 봇

공유 자전거 서비스 '푸른길자전거'는 고장 신고를 받는 대화형 봇을 만들었습니다. 개발팀은 팀원이 쓴 질문 200건으로 평가해 정답률 95%를 보고했습니다. 기획자는 숫자를 보기 전에 세 가지를 확인했습니다.

먼저 대표성입니다. 실제 신고 기록을 보니 35%가 사진 한 장과 "이거 안 돼요" 같은 짧은 문장이었는데, 평가 세트에는 그런 신고가 없었습니다. 기획자는 지난 두 달 신고에서 무작위로 400건을 뽑아 평가 세트를 다시 꾸렸습니다. 다음은 고위험 사례입니다. 브레이크 고장 신고는 전체의 1%였지만 그 자전거를 즉시 운행 중지해야 했습니다. 브레이크 신고 80건을 따로 모아 "운행 중지 안내 누락 0건"을 별도 합격 기준으로 두었습니다.

채점은 기준마다 나눴습니다. 고장 부위 분류는 정답 라벨과 코드로 대조하고, 안내 문장의 친절함은 루브릭을 준 LLM 채점기로 매기되 정비 팀장이 채점한 100건과 먼저 대조했습니다. 다시 평가한 결과 전체 정답률은 88%, 브레이크 묶음은 운행 중지 안내 누락 3건이었습니다. 버린 안은 "전체 정답률이 기준 85%를 넘었으니 출시"였습니다. 브레이크 묶음이 별도 기준을 넘지 못했으므로, 팀은 브레이크 관련 표현이 나오면 봇이 아니라 즉시 운행 중지 절차로 넘기는 규칙을 넣고 다시 평가해 통과한 뒤 출시했습니다.

별책서재의 도서 소개문

출판사 '별책서재'는 신간 소개문을 AI로 쓰는 기능의 두 버전 가운데 하나를 골라야 했습니다. 정답 라벨은 없었고, 좋은 소개문인지는 편집자의 판단이 필요했습니다. 출시 전이라 독자에게 내보낼 수도 없었습니다.

기획자는 코드 채점을 쓸 수 있는 부분부터 골라냈습니다. 저자명·출간일·쪽수가 도서 정보와 같은지는 코드로 확인했습니다. 나머지 "책의 핵심을 왜곡하지 않는가"와 "읽고 싶게 만드는가"는 편집자 세 명이 신간 60권의 두 버전을 어느 버전인지 모르는 상태로 나란히 비교하게 했습니다. 제시 순서는 책마다 바꿔 위치 편향을 줄였습니다.

편집자들은 B 버전을 60권 중 41권에서 더 낫다고 골랐고, 왜곡 사례는 A가 7건, B가 2건이었습니다. 팀은 B를 골랐고, 편집자 세 명의 판정 180건(60권 × 3명)을 루브릭으로 정리해 다음부터는 LLM 채점기를 그 판정과 대조한 뒤 쓰기로 했습니다. 버린 안은 "독자 클릭률로 A/B 실험"이었습니다. 출시 전이었고, 클릭률은 왜곡 여부를 알려 주지 못하기 때문입니다. 출시 뒤 클릭률은 별도의 온라인 지표로 추적하기로 했습니다.

자주 틀리는 지점

1. "예시 몇 개로 확인하면 충분하다." 느낌으로 하는 평가는 대표적인 실패 패턴입니다. 실제 분포를 대표하는 평가 세트가 필요합니다.
2. "애매한 사례는 빼야 채점이 깔끔하다." 애매한 사례는 실제에서 가장 자주 틀리는 경계 사례입니다. 표시해 넣고 따로 봅니다.
3. "전체 정확도가 높으면 드문 유형도 괜찮다." 0.4%짜리 고위험 유형은 전체 점수에 묻힙니다. 별도 묶음과 별도 기준이 필요합니다.
4. "사람 채점은 비싸니 쓰지 않는다." 사람 채점은 전체에 쓰지 않을 뿐, 기준 데이터와 채점기 보정에는 꼭 필요합니다.
5. "LLM 채점 점수가 올랐으니 좋아졌다." 보정되지 않은 채점기는 길이 같은 엉뚱한 특징을 보상할 수 있습니다. 기록을 읽고 사람과 대조합니다.
6. "같은 평가 세트로 계속 고치면 확실해진다." 그 세트에 맞춰질 뿐입니다. 보류 세트로 최종 판정합니다.
7. "평가 세트는 한 번 만들면 바꾸지 않는다." 비교 가능성은 버전으로 지키고, 세트는 운영에서 찾은 실패로 키웁니다.
8. "출시 후 지표가 좋아졌으니 기능 덕분이다." 같은 기간의 다른 요인을 분리하려면 무작위 비교가 필요합니다.

한눈에 정리

공식 문서로 확인하기

• Claude Docs — Define success criteria and build evaluations: 평가 설계 원칙, 경계 사례, 세 가지 채점 방식과 LLM 채점 요령.
• OpenAI — Evaluation best practices: 평가 과정 다섯 단계, 평가 주도 개발, 실패 패턴, 사람 보정, 위치 편향. 이 페이지는 OpenAI의 Evals 플랫폼이 2026년 10월 31일 읽기 전용, 11월 30일 종료된다고 함께 알리고 있으나 원칙은 플랫폼과 무관합니다.
• Anthropic — Demystifying evals for AI agents: 역량 평가와 회귀 평가, pass@k와 pass^k, 채점 방식의 장단점, 평가 포화, 방법의 조합.
• Google PAIR Guidebook — Data Collection + Evaluation: 테스트 세트, 대표성, 라벨 해석의 차이.
• Google SRE Workbook — Canarying Releases: 대조군 비교와 시간 요인.
• NIST AI RMF — Core: MANAGE 1.1(목적 달성과 배포 진행 여부의 판단), MEASURE 2.4(운영 중 모니터링).

셀프 체크

3-1. OpenAI가 설명하는 평가 과정 다섯 단계를 순서대로 쓰라.

3-2. Claude 문서가 평가에 넣으라고 하는 경계 사례 네 가지를 쓰라.

3-3. 코드 채점, LLM 채점, 사람 채점의 한계를 각각 한 문장으로 쓰라.

3-4. 도서 대출 안내 봇의 답변 가운데 "반납 기한 날짜"와 "안내 말투"를 평가하려 한다. 두 기준에 맞는 채점 방식을 각각 고르고 이유를 쓰라.

3-5. 역량 평가와 회귀 평가의 목적과 기대 통과율을 비교하고, 역량 과제가 회귀 묶음으로 옮겨 가는 시점을 설명하라.

3-6. 개발 세트 점수는 70%에서 93%로 올랐는데 보류 세트 점수는 71%에서 73%로 올랐다. 무엇을 의심해야 하는가?

3-7. 사람이 여러 후보 가운데 하나를 고르는 기능과, 고객이 매번 같은 품질의 답을 받아야 하는 기능에 각각 맞는 성공 집계 방식을 쓰라.

3-8. (설계) 지금 맡은 AI 기능 하나의 평가 계획서를 이 장의 양식으로 쓰되, 성공 기준(차단 기준과 개선 목표)마다 채점 방식과 그 이유를 한 줄씩 붙이라.

실습 과제