■ 성공 기준

success criteria : specific · measurable · achievable · relevant + 여러 차원4.1 본편

표시가 없는 문장은 공식 문서에서 확인한 내용이에요. 다른 표시는 읽는 법

왜 배우나 — 시험이 요구하는 것

시험 목표 4.1 평가 지표 정하기 · D4 평가 16%
Define evaluation metrics (accuracy, latency, cost, safety, security)

이 개념으로 푸는 판단 (할 수 있어야 하는 것)

4.1① "감정 분류를 잘하게" — 성공 기준을 어떻게 적나? — 모호한 목표를 측정 가능한 성공 기준으로 바꾸기
1.1② "챗봇 넣자" 는 요청, 무엇부터 적나? — 해법보다 결과·범위·성공 기준을 먼저 정하기
6.1② 성공 기준을 어떻게 적나 — SMART 로? 숫자 하나로? — 성공 기준의 요건 (Anthropic 4가지 + 여러 차원)

한눈에

성공 기준(success criteria)은 "잘 되게"를 합격·불합격이 갈리는 문장으로 바꾼 것이다. 좋은 성공 기준은 4가지를 갖춘다

구체적
측정 가능
달성 가능
관련

기준 한 문장에 지표 + 임계값 + 잴 데이터(held-out 테스트 셋) + 기준선 대비를 넣는다. 그리고 대부분은 여러 차원을 같이 기준으로 건다

공식 순서에서는 성공 기준을 먼저 정한다. 그 기준을 재는 eval 은 그다음이다

비유 SLO 문서와 같다. "빠르게"가 아니라 "이 엔드포인트, 요청 95% 가 200ms 미만" 으로 쓴다. 가용성 하나로 "성공"이라 하지 않고, 오류율과 지연(latency)을 같이 기준으로 건다

'감정을 잘 분류해야 한다' 대신 'held-out 트윗 10,000개에서 F1 0.85 이상, 기준선보다 5% 개선'처럼 쓴다. 좋은 기준은 구체적·측정 가능·달성 가능·관련 4가지이고 기한은 없다. — 그림으로 보기 (AI 생성 · Codex · 누르면 크게)

ELI5

달리기 시합에서 "잘 달려"라고만 하면 누가 이겼는지 못 정해요.

"100m 를 15초 안에"처럼 숫자로 정해야 해요.
어느 운동장에서 잴지도 미리 정해요.
달리기만 보지 않고, 넘어지지 않았는지도 같이 봐요.
지금 다리로 닿을 수 있는 기록이어야 해요.

개념 설명

영상 — 합격 기준에 무엇을 더할까? (약 43초 · 소리 없음 · 자막). F1 0.92 · 응답 450ms · 99.8% · 93% 는 그림용 가정(지어낸 숫자) · held-out 을 '고칠 때 안 본' 으로 풀어 씀 작은 화면에서는 전체화면(⛶)으로 보세요.

원리

왜 기준이 먼저인가

기준이 없으면 프롬프트를 고친 뒤 "좋아졌나"를 판정할 수 없다. 공식 순서는 아래와 같다.
- 성공 기준(success criteria)을 정의한다
- 그 기준을 재는 eval 을 설계한다
- 고치고 다시 잰다
늦게 정하면 운영(production) 중인 시스템에서 기준을 거꾸로 캐내야 한다. 초기에 eval 을 쓰면 팀이 "성공이 뭔지"를 글로 적게 된다.

좋은 기준 4가지 — 각각이 막는 실패

구체적 : 무엇을 잘해야 하는지 흐린 실패를 막는다. "좋은 성능"이 아니라 "정확한 감정 분류"로 쓴다.
측정 가능 : 판정할 수 없는 실패를 막는다. 숫자나 일관되게 쓰는 정성 척도(Likert · 루브릭)를 쓴다. 안전·윤리도 숫자로 쓴다.
달성 가능 : 영원히 불합격인 목표를 막는다. 벤치마크 · 이전 실험 · 연구 · 전문가 지식에 기댄다.
관련 : 쓸모없는 지표를 올리는 일을 막는다. 앱 목적과 사용자 요구에 맞춘다.
공식은 이 4가지뿐이다. 'SMART' 의 기한은 없다.

기준 문장의 조각 (공식 예)

지표는 F1, 임계값은 0.85 이상, 데이터는 held-out 트윗 10,000개, 기준선은 지금보다 5% 개선이다.
held-out 셋은 고칠 때 안 본 셋이다. 고칠 때 보던 셋으로만 재면, 그 셋에 맞춘 개선(과적합)을 진짜 개선으로 착각한다.
기준선이 있어야 "개선"인지 "그대로"인지 가릴 수 있다.

여러 차원

대부분은 한 숫자로 끝나지 않는다. 정확도를 올리다 안전·지연(latency)·비용이 나빠지면, 한 숫자만 보는 기준은 그것을 못 본다.
오류도 무게가 다르다. 공식 예는 "오류의 90% 는 큰 오류가 아닌 불편 수준"을 따로 기준으로 건다. 그래서 오류 심각도도 기준이 된다.
운영 지표(응답 시간 ms · 가동률 %)도 성공 기준의 차원이다.

에이전트

에이전트는 말로 끝나지 않는다. 성공은 시도가 끝난 뒤 환경의 최종 상태(outcome)다.
실행마다 결과가 달라서 한 번 돌려 보고 판정하지 않는다. 그래서 pass@k · pass^k 를 쓴다.

핵심 질문 두 개

이 문장만 보고 기계가 합격·불합격을 가를 수 있나?
이 숫자 하나만 좋아지고 다른 게 나빠지면, 기준이 그것을 잡나?

규칙과 판단

숫자가 없으면 지표와 임계값(어조는 Likert·루브릭), 데이터·기준선이 없으면 held-out 셋과 기준선을 붙이고, 지표가 하나뿐이면 여러 차원으로 넓힌 뒤 eval 을 설계한다. — 그림으로 보기 (AI 생성 · Codex · 누르면 크게)

갈림길

①② 기준 문장 고치기 [4.1①]

숫자가 있나?"잘 분류해야" · "안전한 출력"

아니오

어떤 주제인가?성능 · 안전·윤리 · 어조

성능·정확도 ("잘 분류해야")

지표 + 임계값

나쁜 예는 "모델이 감정을 잘 분류해야 한다" 다. 좋은 예는 F1 0.85 이상이다(측정 가능·구체적)

안전·윤리

숫자로 바꾼다

"안전한 출력" 은 나쁜 예다. 10,000회 중 콘텐츠 필터 유해 플래그 0.1% 미만이 좋은 예다

어조처럼 주관적

잘 정의된 정성 척도

Likert 1~5 나 전문가 루브릭을 쓴다. 정성 척도는 정량과 함께 일관되게 쓸 때 가치가 있다

예

무엇이 빠졌나?데이터·기준선 · 기한

데이터·기준선

셋·기준선을 붙인다

held-out 테스트 셋(다양한 트윗 10,000개)과 "지금 기준선보다 5% 개선" 을 붙인다

기한(Time-bound) 이라는 지적

공식 4가지에 없다

SMART 의 기한(Time-bound)은 공식 4가지에 없다

셋·기준선이 다 있다

↓ 아래 「차원 점검」 갈림길로 이어짐

다음 물음 — 지표가 하나뿐인가?

③④ 차원 점검 [4.1①] [1.6②]

지표가 하나뿐인가?정확도만 · F1 만

예

여러 차원으로 건다

공식 예는 다음을 같이 건다. F1 0.85 이상이다. 출력 99.5% 가 무해하다. 오류의 90% 는 불편 수준이다. 응답 95% 가 200ms 미만이다

아니오

목표가 이룰 만하고 쓸모 있나?

프런티어 모델 역량 밖

달성 가능하게

업계 벤치마크 · 이전 실험 · AI 연구 · 전문가 지식에 기댄다

앱 목적과 상관이 약하다

⑤ 에이전트면 [4.1①] [4.1③]

판정에서 무엇이 걸리나?마지막 말 · 실행마다 다르다

에이전트가 "완료"라고 말한다

결과로 판정한다

성공은 시도가 끝난 뒤 환경의 최종 상태다. "예약됐어요"라고 말해도 DB 에 예약이 있어야 성공이다

돌릴 때마다 결과가 다르다

여러 번 시도한다

자세한 것은 ◆ pass@k vs pass^k 에 있다

규칙 원문 ①②③④⑤ (갈림길로 그린 규칙)

①
좋은 기준은 4가지를 갖춘다 [4.1①]
- 구체적(Specific) : "좋은 성능" 대신 "정확한 감정 분류" 처럼 쓴다
- 측정 가능(Measurable) : 정량 지표나 잘 정의된 정성 척도를 쓴다. 정성 척도는 정량과 함께 일관되게 쓸 때 가치가 있다. 윤리·안전 같은 모호한 주제도 숫자로 쓴다. "안전한 출력" 은 나쁜 예다. 10,000회 중 콘텐츠 필터 유해 플래그 0.1% 미만이 좋은 예다
- 달성 가능(Achievable) : 업계 벤치마크 · 이전 실험 · AI 연구 · 전문가 지식에 기댄다. 현재 프런티어 모델 역량에 비해 비현실적이면 안 된다
- 관련(Relevant) : 앱 목적과 사용자 요구에 맞춘다. 인용 정확도는 의료 앱에서는 중요하고, 일상 챗봇에서는 덜 중요하다
SMART 의 기한(Time-bound)은 공식 4가지에 없다
②
기준 한 문장을 조립한다 (공식 감정 분석 예) [4.1①]

나쁜 예 : "모델이 감정을 잘 분류해야 한다"

좋은 예는 세 조각으로 이루어진다
- F1 0.85 이상(측정 가능·구체적)
- held-out 테스트 셋, 다양한 트윗 10,000개(관련)
- 지금 기준선보다 5% 개선(달성 가능)
held-out 셋은 고칠 때 안 본 셋이다. 이 셋으로 "훈련용" eval 에 과적합했는지 가려낸다

재는 수단 예는 아래와 같다
- 과제별 : F1 · BLEU · perplexity
- 일반 : 정확도 · 정밀도 · 재현율
- 운영 : 응답 시간(ms) · 가동률(%)
- A/B(기준 모델·이전 버전과 비교) · 엣지 케이스 무오류 처리 비율
- Likert 척도 · 전문가 루브릭
③
여러 차원 : 대부분은 여러 성공 기준으로 다차원 평가를 한다 [4.1①] [1.6②]

공식 예(held-out 트윗 10,000개)는 아래를 같이 건다
- F1 0.85 이상
- 출력 99.5% 가 무해하다
- 오류의 90% 는 큰 오류가 아닌 불편 수준이다
- 응답 95% 가 200ms 미만이다
"불편" 과 "큰 오류" 의 뜻도 따로 정의해야 한다

흔한 기준은 아래와 같다(공식 목록이고, 전부는 아니다)
- 과제 충실도(드물고 어려운 입력 포함)
- 일관성
- 관련성·논리
- 톤·스타일
- 개인정보 보호
- 맥락 활용
- 지연
- 가격
가이드 목표 4.1 의 차원은 정확도 · 지연 · 비용 · 안전 · 보안이다. 보안(인젝션 성공률 같은 것)을 재는 법은 공식 목록에 없다 업계 일반

고객지원 목표치는 ■ impact metrics 에 있다. 지연 차원은 ◆ TTFT vs 응답 완료 지연 에 있다. 가격 차원은 ■ per-request cost 에 있다
언제 : 만들기 전에 정한다. 성공 기준을 먼저 정하고, 그 기준을 재는 eval 을 설계한다. 늦으면 운영 중인 시스템에서 기준을 거꾸로 캐내야 한다 (본문 = ■ 문제 정의 · 규칙 ④)
⑤
에이전트면 : 과제(task)는 입력과 성공 기준이 정해진 테스트 하나다 [4.1①] [4.1③]

성공은 말이 아니라 결과(outcome)다. 곧 시도가 끝난 뒤 환경의 최종 상태다. "예약됐어요"라고 말해도 DB 에 예약이 있어야 성공이다

대화형 에이전트도 여러 차원으로 잰다
- 티켓 해결(상태 확인)
- 10턴 미만(기록 제약)
- 어조(LLM 루브릭)
실행마다 결과가 달라서 여러 번 시도한다. 자세한 것은 ◆ pass@k vs pass^k 에 있다

더 깊이 : 판단 규칙 · 상황 변수 (설명)

판단 규칙

조건	답	근거
목표가 "잘 되게" · "좋은 성능" 같은 말이다	구체적 과제와 숫자 지표로 바꾼다	define-success en-full (Specific — "good performance" 대신 "accurate sentiment classification")
안전·윤리처럼 모호한 차원이다	숫자로 쓴다. 예를 들어 10,000회 중 유해 플래그 0.1% 미만이다	define-success en-full
어조·공감처럼 주관적 차원이다	잘 정의된 정성 척도(Likert · 전문가 루브릭)를 정량과 함께 쓴다	define-success en-full
기준 문장을 쓸 때	지표 + 임계값 + held-out 셋 + 기준선 대비를 넣는다	define-success en-full
지표를 하나만 걸려 한다	여러 차원을 건다 (정확도 · 안전 · 오류 심각도 · 지연 …)	define-success en-full "Most use cases need multidimensional evaluation along several success criteria."
목표치를 어디서 정하나	업계 벤치마크 · 이전 실험 · AI 연구 · 전문가 지식에서 정한다. 프런티어 역량 안에서 정한다	define-success en-full
어떤 차원을 넣을지 모른다	흔한 기준 목록에서 고른다 : 과제 충실도 · 일관성 · 관련성·논리 · 톤·스타일 · 개인정보 · 맥락 활용 · 지연 · 가격	define-success en-full (목록은 전부 아님)
에이전트 과제의 성공을 판정한다	환경 최종 상태(outcome)로 판정한다. 마지막 말로 판정하지 않는다	demystifying-evals
대화형 에이전트다	상태 확인 + 턴 수 제약 + 어조 루브릭을 같이 건다	demystifying-evals
언제 정하나	만들기 전에 정한다	define-success en-full · demystifying-evals

상황 변수

변수	값	답 쪽	등급	근거
차원의 성격	정답이 뚜렷하다(분류)	정량 지표(정확도 · F1)		define-success en-full
차원의 성격	주관적이다(어조 · 공감)	Likert · 루브릭을 정량과 함께 쓴다		define-success en-full
차원의 성격	모호한 안전·윤리다	비율 숫자와 시행 횟수를 적는다		define-success en-full
앱 목적	의료	인용 정확도가 중요하다		define-success en-full
앱 목적	일상 챗봇	인용 정확도는 덜 중요하다		define-success en-full
기준선	있다	"기준선보다 N% 개선" 으로 쓴다		define-success en-full
기준선	없다(새 제품)	벤치마크 · 이전 실험 · 전문가 지식으로 절대 목표를 정한다		define-success en-full · 뒤집히는 때 3
과제 종류	맥락에 넣어 준 회사·상품 정보 · 견적	100% 가 공식 목표다		customer-support-chat-full · 뒤집히는 때 1
과제 종류	자동 해결률처럼 문의 복잡성에 좌우된다	100% 가 아니다 (deflection 70~80%)		■ impact metrics
시스템 모양	에이전트(도구·상태 변경)	결과(환경 상태)로 보고 여러 번 시도한다		demystifying-evals
차원	보안(인젝션 등)	가이드는 차원으로 든다. 재는 법은 공식 목록에 없다	업계 일반	미해결 1

연습 문제

고객지원 Agent 의 합격 기준 초안은 "held-out 문의 5,000건에서 문의 분류 F1 0.85 이상지표 하나, 지금 기준선보다 5% 개선" 한 줄뿐이다. 팀장은 기한(Time-bound)이 빠졌다며 SMART 로 고치자고 한다. 기준에 무엇을 더할까?

시험 대비

함정

"모델이 감정을 잘 분류해야 한다" 같은 말을 기준으로 쓰는 것은 함정이다. 숫자 · 데이터 · 기준선이 없다
"안전한 출력" 을 기준으로 쓰는 것은 함정이다. 10,000회 중 0.1% 미만처럼 숫자로 쓴다
정확도 하나만 기준으로 거는 것은 함정이다. 대부분은 여러 차원으로 잰다
'SMART' 로 외워 기한(Time-bound)을 찾는 것은 함정이다. 공식은 4가지다
현재 프런티어 모델로 닿지 않는 목표는 함정이다. 목표는 달성 가능해야 한다
"어조는 주관적이라 못 잰다" 는 함정이다. Likert · 루브릭 같은 잘 정의된 정성 척도를 정량과 함께 쓴다
오류 비율만 걸고 오류의 무게는 안 보는 것은 함정이다. 공식 예는 "오류의 90% 는 불편 수준"처럼 심각도도 기준으로 건다
고칠 때 보던 셋으로 합격을 판정하는 것은 함정이다. held-out 셋을 쓴다
에이전트의 마지막 말("완료했습니다")로 성공을 판정하는 것은 함정이다. 환경 최종 상태로 판정한다

신호

"Building a successful LLM-based application starts with clearly defining your success criteria and then designing evaluations to measure performance against them."

"Use quantitative metrics or well-defined qualitative scales."

"Less than 0.1% of outputs out of 10,000 trials flagged for toxicity by the content filter."

"Your success metrics should not be unrealistic to current frontier model capabilities."

"Most use cases need multidimensional evaluation along several success criteria."

"The sentiment analysis model should achieve an F1 score of at least 0.85 (Measurable, Specific) on a held-out test set"

"which is a 5% improvement over the current baseline (Achievable)."

"A flight-booking agent might say “Your flight has been booked” at the end of the transcript, but the outcome is whether a reservation exists in the environment’s SQL database."

성공 기준은 보통 지표·임계값·held-out 셋·기준선을 담지만, 답이 맥락에 다 있으면 100% 목표도 되고, 드문 사건은 시행 횟수도 넣으며, 새 제품은 벤치마크로 절대 목표를 둔다는 그림. — 그림으로 보기 (AI 생성 · Codex · 누르면 크게) — 자세한 조건은 아래 '더 깊이'에 있어요

더 깊이 : 뒤집히는 때 · 오답 재료 (설명)

뒤집히는 때

1. "100% 목표는 비현실이라 오답" 이 틀리는 때

조건 : 과제가 좁은 사실 전달이다. 맥락에 넣어 준 회사·상품 정보를 그대로 말하거나, 견적을 맞게 내는 일이다.
판단 : 공식 고객지원 가이드는 이 두 칸에 100% 정확도를 목표로 둔다. 답이 맥락 안에 다 있어서 프런티어 역량 밖이 아니다. "달성 가능"은 "100% 금지"가 아니라 "과제에 비춰 현실적"이라는 뜻이다.
근거 : customer-support-chat-full · define-success en-full
대조 : 문의 복잡성에 좌우되는 자동 해결률(deflection)은 70~80% 가 공식 목표다. 그래서 거기서는 100% 가 오답이다 (■ impact metrics).

2. 시행 횟수가 작으면 0.1% 기준은 못 잰다

조건 : 유해 출력 0.1% 미만을 기준으로 걸었다. 그런데 시험 셋이 800회다.
계산 : 0.1% × 800 = 0.8개다. 1개만 나와도 1 ÷ 800 = 0.125% 라 불합격이고, 0개면 합격이다. 합격 여부가 출력 1개에 달린다. 공식 예처럼 10,000회면 0.1% = 10개까지 허용된다. 그래서 1~2개 차이로 판정이 뒤집히지 않는다.
전제 : 시행은 서로 독립이다. 콘텐츠 필터 판정은 고정이다.
등급 : 계산 (0.1%·10,000회는 확인). "공식 예가 시행 횟수를 같이 적은 이유가 이것"은 추론.
근거 : define-success en-full
처방 : 드문 사건을 비율로 걸 때는 시행 횟수도 기준 문장에 넣는다.

3. 기준선이 없는 새 제품

조건 : 처음 만드는 분류기라서 "지금 기준선"이 없다.
판단 : "기준선보다 5% 개선"을 쓸 수 없다. 그래서 달성 가능 근거를 업계 벤치마크 · 이전 실험 · AI 연구 · 전문가 지식에서 가져와 절대 목표로 쓴다. 첫 버전이 나오면 그것이 다음 버전의 기준선이 된다.
등급 : (근거 4가지) · 업계 일반("첫 버전이 기준선")
근거 : define-success en-full · demystifying-evals ("you get baselines and regression tests for free")

4. 여러 차원이 서로 부딪칠 때

조건 : 기준은 F1 0.9 이상과 응답 95% 300ms 미만이다. 더 큰 모델로 F1 0.92 가 됐다. 그러나 95번째 응답 시간이 450ms 다.
판단 : 한 차원만 통과하면 불합격이다. 여러 차원을 건 이유가 바로 이 충돌을 드러내는 것이다. 다음 조치는 둘 중 하나다. 지연 lever(조절 수단, ■ 지연 줄이기 lever)로 지연 차원을 되찾는다. 또는 기준 자체를 다시 협의한다.
등급 : (다차원) · 업계 일반(충돌 처리 순서)
근거 : define-success en-full

오답 재료

오답	왜 끌리나	왜 틀리나	근거
"모델이 감정을 잘 분류해야 한다"	목표가 분명해 보인다	숫자 · 데이터 · 기준선이 없어서 판정할 수 없다. 공식이 든 '나쁨' 예 그대로다	define-success en-full
"안전한 출력을 낸다"	안전은 숫자로 못 잴 것 같다	공식 '나쁨' 예다. 10,000회 중 0.1% 미만처럼 숫자로 쓴다	define-success en-full
정확도(F1) 하나만 건 기준	가장 중요한 숫자 하나면 충분해 보인다	대부분 다차원이다. 공식 좋은 예는 F1 + 무해 + 오류 심각도 + 지연을 건다	define-success en-full
'SMART' 5요소, 기한(Time-bound)을 찾는 보기	흔히 외우는 목표 틀이다	공식은 4가지다(구체적 · 측정 가능 · 달성 가능 · 관련)	define-success en-full
"어조는 주관적이라 사람이 전부 채점"	주관적이면 사람이 해야 할 것 같다	잘 정의된 정성 척도로 잰다. 채점 수단 고르기는 ■ grader 고르기 에 있다	define-success en-full
"정확도 99.99% 를 목표로"	높을수록 좋아 보인다	프런티어 역량에 비해 비현실적이면 안 된다	define-success en-full
"100% 목표는 늘 오답"	달성 가능을 과하게 외웠다	맥락 정보 · 견적 정확도는 공식 목표가 100% 다	뒤집히는 때 1
에이전트가 "완료"라고 답했으니 성공	말이 곧 결과 같다	성공은 환경 최종 상태다	demystifying-evals
"기준은 운영하면서 정한다"	빨리 내보내고 싶다	만들기 전에 정한다. 늦으면 운영 중인 시스템에서 거꾸로 캐내야 한다	demystifying-evals

참고

더 깊이 : 출처 · 상태 · 미해결 (참고)

출처

상태

업계 일반 1줄(보안 차원 재는 법)

미해결

보안 차원 : 가이드 목표 4.1 은 security 를 지표 차원으로 든다. 그러나 define-success 의 흔한 기준 목록에는 보안 항목이 없다(가까운 것은 개인정보 보호다). 인젝션 성공률 같은 보안 지표는 업계 일반이다. 목록도 "(근거 확인 필요 — Anthropic 문서 없음)" 으로 표시해 두었다.
"5% improvement over the current baseline" 이 상대(0.85 ÷ 1.05 ≈ 기준선 0.81)인지 절대(0.85 − 0.05 = 기준선 0.80)인지는 공식 문장에 없다. 시험에 숫자로 나오면 지문 표현을 따른다(추론).
한국어판 define-success(ko)에는 예시 아코디언(감정 분석 좋은/나쁜 예 · 지표 예 · 흔한 기준 설명)이 빠져 있다. 그래서 카드의 예시·지표 목록은 영어 full 판으로만 확인했다.
목록 4.1① 의 두 영어 신호("Most use cases need…" · "Less than 0.1%…")는 원문에서 찾았다. 목록의 "held-out 데이터셋 · 기준선" 도 en-full에서 확인했다.