숫자·단위·비트
120ms에서 90ms로 줄면 몇 퍼센트 감소인가요?
사용할 도구
개선 보고에 '25% 빨라짐', '33% 빨라짐', '원래의 75%'가 함께 나올 수 있습니다. 같은 측정도 분모와 대상이 다르면 결과가 다릅니다. 계산 실수부터 찾기 전에 기준과 설명하는 변화를 확인하세요.
비율 도구로 예시 처리 시간 120ms와 90ms를 비교합니다. 실제 서비스를 측정하지 않고 입력 값으로 계산합니다. 측정 조건이 다른 두 값도 계산되므로 결과가 나온다고 공정한 비교가 된 것은 아닙니다.
줄어든 30ms를 원래 120ms로 나누기
증감률 모드에서 이전 120, 이후 90을 넣으면 -25%입니다. 식은 (90-120)÷120×100입니다. 음수는 시간이 줄었다는 뜻이므로 '처리 시간 25% 단축'으로 설명할 수 있습니다. 성능 악화라는 뜻이 아닙니다.
before = 120 ms
after = 90 ms
difference = -30 ms
change = -25%입력 전 단위를 맞추세요. 120ms와 0.09초를 120과 0.09로 넣으면 도구는 단위 차이를 모릅니다. 비율 자체는 무차원이지만 원래 두 값은 같은 척도여야 합니다. ms·초, byte·KB를 먼저 통일하세요.
75%가 됨과 75% 감소는 다릅니다
비율 모드에서 부분 90, 기준 120이면 75%입니다. 새 시간이 원래의 얼마인지 뜻합니다. 75%가 남았으니 25% 줄었습니다. '감소율' 제목 아래 75%를 그대로 붙이면 안 됩니다.
120ms에서 75% 감소했다면 90ms가 아니라 30ms입니다. 짧은 문구라도 '원래의 75%', '25% 감소', '75% 감소'를 구분하세요. 계산이 맞아도 설명이 다른 양을 가리키면 개선 폭을 오해하게 됩니다.
원래로 돌아가는 변화율은 같지 않습니다
이전 90, 이후 120으로 바꾸면 약 33.3333% 증가입니다. 차이는 같은 30ms지만 분모가 90입니다. 증감률은 대칭이 아니므로 비교를 뒤집으면 부호만 달라지지 않습니다.
100을 20% 늘리면 120, 다시 20% 줄이면 96입니다. 두 번째 기준이 커져 100으로 돌아가지 않습니다. 할인이나 용량 변화율을 단순히 더하고 빼기 전에 기준이 같은지 보고 단계 순서대로 계산하세요.
시간이 25% 줄면 처리량은 몇 퍼센트 늘까요?
다른 대기 없이 한 건씩 순차 처리한다고 가정하면 120ms는 초당 약 8.333건, 90ms는 약 11.111건입니다. 처리량은 약 33.333% 늘며 시간 25% 감소와 모순이 아닙니다. 역수를 비교하기 때문입니다.
실제 서비스에는 병렬 처리, 큐, 외부 호출, 다른 병목이 있습니다. 역수 모델로 서버 용량 33% 증가를 보장하지 못합니다. 측정 사실인 건당 시간 25% 단축과 같은 조건의 순차 처리량 약 33% 증가 모델을 구별하세요.
오류율 2%에서 1%는 1% 개선일까요, 50%일까요?
비율끼리 직접 차이는 퍼센트포인트로 표현합니다. 2%에서 1%는 1퍼센트포인트 하락이고 기존 2% 기준으로는 50% 감소입니다. 증감률에 2와 1을 넣으면 -50%입니다. '1% 하락'만 쓰면 의미가 모호합니다.
원래 건수도 중요합니다. 100건 중 2건→1건과 10만 건 중 2000건→1000건은 비율 변화가 같아도 증거량이 다릅니다. 도구는 통계적 유의성이나 원인을 판단하지 않습니다. 우연인지 개선 효과인지는 비율만으로 결론 내리지 마세요.
0건에서 1건은 몇 퍼센트 증가일까요?
기준이 0이면 0으로 나눠야 하므로 일반 증감률 결과를 거부합니다. 0→1을 100% 증가라 쓰면 부적절합니다. '0건에서 1건 증가'나 '새로 1건 발생'처럼 실수량과 상태를 설명하세요.
작은 0이 아닌 기준도 큰 비율을 만듭니다. 1→10은 900% 증가지만 늘어난 것은 9건입니다. 비율만 강조하면 규모가 안 보입니다. 작은 기준이나 음수 기준에서는 공식의 의미가 맞는지 특히 확인하고 절대 차이도 쓰세요.
개선 보고에는 원래 두 값을 남기세요
'평균 120ms→90ms, 30ms 단축, 기존 대비 25% 감소'라고 쓰면 기준과 규모가 드러납니다. 평균끼리, 중앙값끼리, 같은 조건으로 비교하세요. 새 최속 한 건과 예전 평균·최악 값을 비교하면 계산이 맞아도 개선 증거는 아닙니다.
도구는 입력 값의 계산을 확인합니다. 기준 선택, 개선의 정의, 증거 강도는 별도 판단입니다. 역방향 증감률, 남은 비율, 절대 차이를 비교한 뒤 결론을 쓰면 숫자만 맥락 없이 전달되는 일을 줄일 수 있습니다.
두 오류율을 그대로 평균 내도 될까요?
오전에 100건 중 10건 오류면 10%, 오후에 900건 중 9건이면 1%입니다. 두 비율의 평균은 5.5%지만 하루 전체는 1,000건 중 19건이므로 1.9%입니다. 시간대별 요청 수가 다른데 같은 비중으로 평균 내면 의미가 달라집니다. 원래 건수를 먼저 합쳐 부분 19, 기준 1,000으로 확인하세요. 비율만 모으면 전체를 복원할 분모를 잃습니다.
개선 전후를 비교할 때도 모집단을 맞춰야 합니다. 전체 요청 오류율과 특정 기능 오류율은 같은 대상을 측정하지 않습니다. 기간, 기능 범위, 실패 정의를 먼저 확인하세요. 숫자를 입력할 수 있다고 비교의 의미까지 성립하는 것은 아닙니다. 집계 조건이 달라졌다면 값과 함께 기록해 개선과 정의 변경을 구별할 수 있게 하세요.