정확도, 지연시간, 비용, 안전성, 보안은 서로 맞물려 움직이는 다섯 축입니다. 이 수업에서는 각 축을 태스크에 맞게 조작적으로 정의하는 방법과, 기준값을 남의 숫자가 아니라 자기 시스템의 기준선에서 끌어내는 절차를 다룹니다.
지표를 먼저 정의해야 하는 이유
프로 수준의 평가에서 가장 흔한 실패는 측정 도구가 부실한 것이 아니라 무엇을 성공으로 볼지 합의되지 않은 것입니다. 지표가 없으면 개선 여부를 판정할 수 없고, 판정할 수 없으면 반복 개선 루프 자체가 돌지 않습니다.
Anthropic 공식 문서의 「Define your success criteria」는 좋은 기준의 조건으로 구체성, 측정 가능성, 달성 가능성, 태스크 관련성을 듭니다. 여기서 실무적으로 가장 자주 깨지는 것이 측정 가능성입니다. "답변이 자연스러울 것" 같은 기준은 사람마다 다르게 읽히므로 지표가 될 수 없습니다.
지표를 정의한다는 것은 곧 조작적 정의(operational definition)를 고정한다는 뜻입니다. 조작적 정의란 "이 값을 어떤 입력에, 어떤 절차로, 무엇과 비교해 계산하는가"를 코드 수준까지 못 박는 것입니다.
- 나쁜 정의: "요약 정확도 90%"
- 조작적 정의: "홀드아웃 200건에 대해, 각 요약이 원문의 필수 항목 5개를 모두 담았는지 규칙 기반으로 채점하고, 5개 모두 포함된 비율"
두 문장은 같은 말처럼 보이지만, 뒤쪽만이 두 사람이 각자 계산해도 같은 숫자가 나옵니다. 시험에서는 "어느 기준이 평가 지표로 쓸 수 있는가"를 고르게 하거나, 모호한 기준을 조작적 정의로 바꾸는 선택지를 묻습니다.
다섯 축과 그 사이의 긴장
요강이 지목하는 다섯 축은 독립적이지 않습니다. 하나를 밀면 다른 하나가 밀립니다. 아키텍트의 일은 다섯 개를 모두 최대화하는 것이 아니라 어느 축을 어디까지 양보할지 정하는 것입니다.
| 축 | 대표적 측정 대상 | 밀었을 때 밀리는 것 |
|---|---|---|
| 정확도 | 정답 일치율, 필수 항목 포함률, 근거 인용 정확도 | 지연시간, 비용 |
| 지연시간 | 첫 토큰까지 시간, 전체 완료 시간의 분위수 | 정확도(단계 축소 시) |
| 비용 | 요청당 입력·출력 토큰, 캐시 적중 비율 | 정확도(모델 등급 하향 시) |
| 안전성 | 거부해야 할 요청의 거부율, 유해 출력 발생률 | 유용성(과잉 거부) |
| 보안 | 권한 초과 호출 시도, 민감정보 노출 경로 | 개발 속도, 편의성 |
지연시간은 평균이 아니라 분위수로 보는 것이 원칙입니다. 평균은 소수의 느린 요청을 가려버립니다. p50과 p95를 함께 보면 "대체로 빠른데 가끔 아주 느린" 상태와 "전반적으로 느린" 상태를 구분할 수 있고, 두 상태의 처방이 서로 다릅니다.
안전성 지표에서 자주 놓치는 것이 과잉 거부(over-refusal) 입니다. 유해 출력만 세면 "모든 요청을 거부하는 시스템"이 만점을 받습니다. 거부해야 할 것을 거부한 비율과 거부하지 말아야 할 것을 거부한 비율을 함께 보아야 지표가 방향을 잃지 않습니다. 시험 함정으로 "안전성은 유해 출력 발생률 하나로 충분하다"는 선택지가 나옵니다.
태스크 유형별로 채점 방식이 갈린다
같은 "정확도"라도 태스크에 따라 계산 방식이 달라집니다. 채점 방식을 잘못 고르면 지표가 실제 품질과 어긋나 움직입니다.
- 정답이 하나인 태스크(분류, 추출) — 코드로 정확히 비교할 수 있습니다. 가장 저렴하고 재현성이 높습니다.
- 정답이 여럿인 태스크(요약, 재작성) — 문자열 일치로는 채점할 수 없습니다. 필수 항목 체크리스트처럼 구조를 검사하는 규칙으로 바꾸거나 심판 모델을 씁니다.
- 정답을 정의하기 어려운 태스크(상담 응대, 설계 제안) — 사람 평가가 최종 기준이 되고, 자동 지표는 그 대리 지표(proxy)로만 씁니다.
구조화된 출력을 요구하면 채점 가능한 형태로 태스크를 끌어올 수 있습니다.
# 요약을 자유 텍스트로 받으면 채점이 어렵다.
# 필수 항목을 스키마로 강제하면 규칙 기반 채점이 가능해진다.
schema = {
"type": "object",
"properties": {
"decision": {"type": "string"},
"owner": {"type": "string"},
"due_date": {"type": "string"},
"risks": {"type": "array", "items": {"type": "string"}},
},
"required": ["decision", "owner", "due_date", "risks"],
}
def score(pred: dict, gold: dict) -> float:
keys = ["decision", "owner", "due_date"]
hit = sum(1 for k in keys if pred.get(k) == gold.get(k))
return hit / len(keys)
여기서 얻는 것은 점수 자체가 아니라 점수가 흔들리지 않는다는 성질입니다. 같은 입력에 같은 점수가 나와야 개선과 회귀를 구분할 수 있습니다. 대리 지표를 쓸 때는 그것이 대리 지표임을 문서에 남겨야 합니다. 대리 지표가 목표로 승격되는 순간, 팀은 지표만 올리고 품질은 올리지 않는 방향으로 최적화하게 됩니다.
기준값은 기준선에서 끌어낸다
"정확도 몇 퍼센트를 넘겨야 하는가"에는 보편적인 정답이 없습니다. 업계 관행 숫자를 그대로 가져오는 것은 근거가 아니라 인용일 뿐입니다. 기준값은 다음 순서로 자기 시스템에서 끌어냅니다.
- 현행 기준선 측정 — 지금 운영 중인 방식(사람이 하거나, 기존 규칙 기반 시스템이거나, 단순 프롬프트)의 점수를 같은 데이터셋으로 먼저 잰다.
- 의사결정 임계 확인 — 이 기능을 쓰는 쪽이 어느 수준부터 사람 검토 없이 신뢰하는지 확인한다. 이것은 기술이 아니라 업무 규칙이다.
- 오류 비용의 비대칭 반영 — 거짓 양성과 거짓 음성 중 어느 쪽이 더 비싼지에 따라 임계를 옮긴다.
- 합의와 기록 — 정한 값과 그 근거를 문서에 남기고, 재검토 시점을 함께 적는다.
3번이 프로 수준에서 특히 중요합니다. 환불 자동 승인처럼 틀렸을 때 금전 손실이 나는 태스크는 보수적으로, 초안 생성처럼 사람이 어차피 검토하는 태스크는 공격적으로 임계를 잡습니다. 같은 정확도 숫자라도 태스크에 따라 합격일 수도 불합격일 수도 있습니다.
기준값에는 재검토 시점을 반드시 붙입니다. 모델이 바뀌고 데이터 분포가 바뀌면 한때 타당했던 임계가 낡습니다. 시험에서는 "한 번 정한 임계는 시스템 수명 동안 유지해야 일관성이 확보된다"는 선택지가 오답으로 등장합니다.
시험 함정
- "자연스러운 답변"처럼 사람마다 다르게 읽히는 기준을 평가 지표로 제시하는 선택지 — 지표는 두 사람이 각자 계산해도 같은 값이 나와야 합니다.
- 지연시간을 평균으로만 관리하는 선택지 — 평균은 꼬리 지연을 가리므로 p50과 p95를 함께 봅니다.
- 안전성을 유해 출력 발생률 하나로 정의하는 선택지 — 과잉 거부율을 함께 보지 않으면 모두 거부하는 시스템이 만점을 받습니다.
- 업계 관행 수치를 그대로 목표값으로 삼는 선택지 — 기준값은 자기 시스템의 기준선과 오류 비용에서 끌어내야 합니다.
- 요약처럼 정답이 여럿인 태스크를 문자열 완전 일치로 채점하는 선택지 — 구조 검사나 심판 모델로 바꿔야 합니다.
- "한 번 정한 임계는 바꾸지 않는 것이 일관성"이라는 선택지 — 모델과 데이터 분포가 바뀌면 임계도 재검토 대상입니다.
실습 시나리오
실제 시험과 같은 형식의 시나리오 문제입니다.
문서 요약 기능의 품질을 "정확도"로 관리하기로 했는데, 주간 회의마다 같은 수치를 두고 해석이 엇갈립니다. 아키텍트가 가장 먼저 할 일은 무엇입니까?
빌드 연습 · 지표 정의서 작성하기
약 40분1.태스크 한 개 선정
담당 중인 기능 하나를 골라 입력과 출력의 형태를 한 문단으로 적습니다.
기대 결과 · 입력 예시와 출력 예시가 각각 한 건 이상 구체적으로 적혀 있습니다.
2.다섯 축 조작적 정의
정확도, 지연시간, 비용, 안전성, 보안 각각에 대해 계산 절차를 한 줄씩 적습니다.
기대 결과 · 각 정의에 측정 대상 데이터, 계산 방법, 비교 기준이 모두 들어 있습니다.
3.채점 코드 작성
정확도 지표를 계산하는 함수를 실제로 구현하고 예시 5건에 돌려 봅니다.
기대 결과 · 같은 입력에 두 번 돌렸을 때 동일한 값이 나옵니다.
4.기준선 측정
현재 운영 방식의 점수를 같은 데이터로 측정해 기록합니다.
기대 결과 · 개선 목표가 아니라 현재 값이 숫자로 남아 있습니다.
5.임계와 재검토 시점 합의
오류 비용의 비대칭을 반영해 임계를 정하고 재검토 시점을 함께 적습니다.
기대 결과 · 임계값 옆에 그 값을 고른 근거와 다음 재검토 날짜가 적혀 있습니다.