AI 업무 평가의 성공률이 90%에서 92%가 됐다면 ‘2% 개선’이라고 적어도 될까? 성공률 차이는 2퍼센트포인트(%p), 성공률의 상대 증가는 약 2.22%, 실패율의 상대 감소는 20%다. 세 표현은 같은 변화를 서로 다른 기준으로 계산한다. 보고서에는 무엇의 변화인지와 기준 분모를 함께 적어야 한다.
이 글의 성공·실패 건수는 모두 설명용 합성 수치다. 실제 모델이나 프롬프트를 실행해 얻은 성능이 아니며, 개선의 통계적 유의성이나 원인을 입증하는 자료도 아니다. 성공·실패가 서로 겹치지 않고 전체를 빠짐없이 나누는 이진 판정을 가정한다.
같은 1,000건이라도 세 계산은 답이 다르다
이전 판본은 1,000건 중 900건, 수정 판본은 1,000건 중 920건이 성공했다고 하자. 각각 실패는 100건과 80건이다. 영국 하원도서관의 백분율 계산 안내는 비율 사이의 차이와 시작값 대비 상대 변화를 구별한다. 이 원칙을 합성 평가에 적용하면 다음과 같다.
| 질문 | 계산 | 결과 |
|---|---|---|
| 성공률이 몇 퍼센트포인트 올랐나? | 92% − 90% | +2%p |
| 이전 성공률에 비해 얼마나 늘었나? | (92 − 90) ÷ 90 × 100 | 약 +2.22% |
| 이전 실패율에 비해 얼마나 줄었나? | (10 − 8) ÷ 10 × 100 | 20% 감소 |
2퍼센트포인트는 두 성공률을 직접 뺀 차이다. 약 2.22%는 이전 성공률 90%를 기준으로 삼는다. 실패율 감소 20%는 이전 실패율 10%가 기준이다. ‘실패율이 20% 감소했다’고 해서 성공률이 20% 올랐거나 최종 실패율이 20%가 됐다는 뜻은 아니다.
독자에게는 ‘합성 평가 각 1,000건에서 성공률 90% → 92%, +2%p. 이전 실패율 10% 대비 실패율은 20% 감소’처럼 기준값을 함께 보여 주는 표현이 명확하다. 성공의 정의나 평가 대상이 다르면 산술 차이는 계산할 수 있어도 같은 조건의 성능 향상이라고 해석할 근거는 부족하다.
실패율 감소와 실패 건수 감소를 구별한다
이번에는 수정 판본의 평가량이 2,000건이고 성공이 1,840건이라고 바꿔 보자. 성공률은 여전히 92%, 실패율은 8%다. 실패율은 이전 10%보다 상대적으로 20% 낮지만, 실패 건수는 100건에서 160건으로 60건 늘었다. 처리량이 두 배이므로 비율 감소와 총건수 증가가 동시에 가능하다.
| 평가 묶음 | 성공 / 전체 | 실패 건수 | 실패율 |
|---|---|---|---|
| 이전 | 900 / 1,000 | 100 | 10% |
| 수정: 같은 평가량 | 920 / 1,000 | 80 | 8% |
| 수정: 두 배 평가량 | 1,840 / 2,000 | 160 | 8% |
그러므로 마지막 행을 보고 ‘실패 건수를 20% 줄였다’고 쓰면 잘못이다. ‘같은 평가량 1,000건을 기준으로 환산하면 실패율 차이 2%p는 20건에 해당한다’는 계산과 실제 발생 건수도 구별한다. 실제 운영에서 얼마를 줄일지는 요청량·구성·판정 기준이 유지되는지에 달려 있다.
본문 코드로 같은 분모와 다른 분모를 검산한다
다음 JavaScript를 Windows의 Node.js v24.15.0에서 본문 복사 텍스트로 실행했다. 소수 출력은 네 자리까지 반올림한다. 검정이나 신뢰구간 계산은 하지 않는다.
const before = { success: 900, total: 1000 };
const comparisons = [
{ name: "sameN", success: 920, total: 1000 },
{ name: "doubleN", success: 1840, total: 2000 }
];
const round4 = x => Number(x.toFixed(4));
const oldRate = before.success / before.total;
const oldFailureRate = 1 - oldRate;
for (const after of comparisons) {
const newRate = after.success / after.total;
const newFailureRate = 1 - newRate;
console.log(JSON.stringify({
name: after.name,
percentagePoints: round4((newRate - oldRate) * 100),
relativeSuccessIncreasePct: oldRate === 0 ? null
: round4((newRate - oldRate) / oldRate * 100),
relativeFailureReductionPct: oldFailureRate === 0 ? null
: round4((oldFailureRate - newFailureRate) / oldFailureRate * 100),
failuresBefore: before.total - before.success,
failuresAfter: after.total - after.success
}));
}{"name":"sameN","percentagePoints":2,"relativeSuccessIncreasePct":2.2222,"relativeFailureReductionPct":20,"failuresBefore":100,"failuresAfter":80}
{"name":"doubleN","percentagePoints":2,"relativeSuccessIncreasePct":2.2222,"relativeFailureReductionPct":20,"failuresBefore":100,"failuresAfter":160}이전 성공률이 0이면 성공률의 상대 변화는 0으로 나누게 되어 정의되지 않는다. 이전 실패율이 0일 때의 상대 실패율 감소도 마찬가지다. 위 코드는 그 경우 null을 반환한다. 이는 ‘변화가 0%’라는 뜻이 아니며, 퍼센트포인트와 원래 건수를 별도로 보고해야 한다.
2%p 차이가 재현될지는 이 산술만으로 알 수 없다
45/50에서 46/50으로 바뀌어도 90% → 92%다. 하지만 성공 한 건이 달라진 비교와 위의 900/1,000 → 920/1,000은 표본 수가 다르다. 같은 비율 차이만으로 불확실성까지 같다고 볼 수 없다. NIST의 비율 신뢰구간 안내도 표본 수·실패 건수와 계산 방법을 다룬다. 여기서는 신뢰구간이나 두 비율의 차이에 대한 검정을 계산하지 않았으므로 유의한 개선이라고 결론 내리지 않는다.
비교 설계도 먼저 확인한다. 같은 1,000개 입력을 두 판본에 넣었다면 어떤 입력이 성공에서 실패로, 실패에서 성공으로 바뀌었는지 대응 관계를 남긴다. 서로 다른 요청 묶음을 비교했다면 기간·난도·언어·사용자 구성 차이를 살펴야 한다. 같은 표본을 여러 번 실행한 결과도 독립된 새 입력과 같게 취급하지 않는다. 맞는 불확실성 평가 방법은 그 설계에 따라 선택해야 한다.
기존 프롬프트 변경 후 회귀 평가는 대표 입력·예외 묶음과 새 실패를 어떻게 비교할지 설명한다. 이 글이 보탠 것은 동일한 90% → 92%를 세 공식으로 해석하고, 분모가 달라질 때 실패율과 총 실패 건수가 반대로 움직일 수 있음을 직접 검산하는 방법이다.
변경 뒤 운영 이상이 생겼다면 품질 문제를 좁히는 운영 신호로 돌아가 실패 유형과 요청 조건을 본다. 비율 상승 하나만으로 변경이 원인이라고 확정하거나 중요한 새 실패를 상쇄했다고 판단하지 않는다.
자주 묻는 질문
보고서에 하나만 쓰려면 무엇이 좋나요?
성공률 전후 값과 분자·분모를 먼저 적고 차이는 %p로 표현하면 기준을 확인하기 쉽다. 상대 변화를 덧붙일 때는 ‘성공률의 상대 증가’ 또는 ‘실패율의 상대 감소’처럼 대상을 명시한다.
성공률이 100%라면 실패율 감소를 계산할 수 있나요?
이전 실패율이 0%이면 상대 감소의 기준이 0이므로 정의되지 않는다. 이후에도 실패가 0건이었다면 두 관측 건수와 기간을 적는다. 관측된 실패 0건을 앞으로도 실패하지 않는다는 보장으로 읽지 않는다.
평가 대상 구성이 달라도 2%p 향상이라고 쓸 수 있나요?
관측 성공률의 차이가 2%p라고는 쓸 수 있다. 다만 쉬운 입력이 늘었거나 판정 기준이 달라졌다면 동일 조건의 모델 개선을 입증한 것은 아니다. 비교 대상과 기준의 차이를 같이 밝혀야 한다.
“성공률 90%에서 92%: 2%p와 실패율 20% 감소의 차이”에 대한 2개의 생각