중앙값

숫자 여러 개를 한 개로 줄여 말해야 하는 자리는 매일 생깁니다. 응답 시간이 어떠냐, 사용자가 문서를 몇 개 만드냐, 계약 규모가 얼마냐 같은 질문에 값을 전부 읽어 줄 수는 없으니 대표하는 숫자 하나를 고릅니다. 그 자리를 오래 평균이 맡았습니다. 모두 더해 개수로 나누면 되니 계산이 쉽고, 모든 값이 조금씩 반영된다는 점도 그럴듯했습니다.

문제는 평균이 멀리 떨어진 값 하나에 끌려간다는 데 있습니다. 페이지덱에서 실제로 이런 일이 있었습니다. 태오가 서버 응답 시간 다섯 건을 재서 평균 1.5초라고 보고했는데, 원래 값은 0.3, 0.4, 0.3, 6.2, 0.3초였습니다. 네 건은 0.4초 안에 끝났고 한 건만 6.2초가 걸렸습니다. 1.5초를 겪은 요청은 한 건도 없는데 보고서에는 1.5초가 적혀 있었습니다.

이런 숫자로는 판단을 못 합니다. 1.5초를 0.8초로 줄이자는 목표를 세우면 잘 돌아가는 네 건을 손보게 되고, 정작 6.2초짜리 한 건이 왜 그랬는지는 끝내 묻지 않습니다. 중앙값은 이 문제를 계산 방식에서 아예 끊어 냅니다. 값을 더하는 대신 줄을 세워 가운데 것을 집으면, 끝에 있는 값이 6.2초든 60초든 가운데 자리는 그대로입니다.

값을 작은 것부터 큰 것까지 늘어놓고 가운데 자리의 값을 집습니다.

계산은 두 단계로 나뉘고, 개수가 홀수냐 짝수냐에 따라 두 번째 단계가 갈립니다.

1. 값을 크기순으로 정렬합니다. 원래 순서나 시간 순서는 버립니다. 앞의 다섯 건을 정렬하면 0.3, 0.3, 0.3, 0.4, 6.2가 됩니다.
2. 개수가 홀수면 정확히 가운데 있는 값을 그대로 씁니다. 다섯 개라면 세 번째 값이고, 위 예시의 중앙값은 0.3초입니다.
3. 개수가 짝수면 가운데 두 값을 더해 2로 나눕니다. 여섯 건이 0.3, 0.3, 0.4, 0.5, 1.1, 6.2라면 세 번째와 네 번째인 0.4와 0.5의 한가운데인 0.45초가 중앙값입니다.

가운데 자리가 몇 번째인지는 개수에 1을 더해 2로 나누면 나옵니다. 값이 999개면 500번째가 중앙값입니다.

여기서 눈여겨볼 것은 계산에 실제로 쓰인 값이 한두 개뿐이라는 점입니다. 6.2초를 60초로 바꿔도, 0.3초를 0.01초로 바꿔도 중앙값 0.3초는 그대로입니다. 순위만 바뀌지 않으면 값이 얼마나 크고 작은지는 결과에 닿지 않습니다. 다른 값들과 동떨어진 값, 곧 이상치에 끌려가지 않는다는 성질이 여기서 나옵니다.

같은 성질이 약점이기도 합니다. 중앙값은 가운데 밖에서 무슨 일이 벌어지는지 전혀 말해 주지 않습니다. 6.2초짜리 요청이 하나든 스무 개 중 아홉 개든 중앙값은 비슷하게 나옵니다.

중앙값 자체에는 높고 낮음의 기준이 없습니다. 응답 시간이라면 낮을수록 좋고 사용자당 문서 수라면 높을수록 좋으니, 좋은 수준은 무엇을 쟀느냐가 정합니다. 대신 이 값을 제대로 쓰고 있는지 판단하는 기준은 따로 있습니다.

첫째는 평균과 나란히 놓고 보는 것입니다. 둘이 비슷하면 값들이 가운데 모여 있다는 뜻이고 어느 쪽을 써도 됩니다. 둘이 크게 벌어지면 한쪽 꼬리가 길다는 신호입니다. 평균 1.5초에 중앙값 0.3초라면 위쪽으로 튄 소수가 평균을 끌어올린 것이고, 이때 팀이 봐야 할 것은 대푯값이 아니라 그 소수입니다.

둘째는 값이 얼마나 흩어져 있는지를 함께 적는 것입니다. 중앙값만 적으면 값들이 가운데 붙어 있는지 양 끝으로 갈려 있는지 구분되지 않습니다. 가운데를 말하는 숫자 옆에 퍼짐을 말하는 숫자, 곧 표준편차나 백분위수를 같이 두면 그 구분이 생깁니다.

셋째는 값의 개수입니다. 중앙값은 순위로 계산하는 값이라 개수가 적으면 한 건만 들어와도 가운데 자리가 통째로 옮겨 갑니다. 다섯 건으로 낸 중앙값을 분기 목표의 근거로 쓰지 않습니다. 전체를 대표하도록 뽑은 표본이 수백 건은 되어야 다음 달에도 비슷한 값이 나옵니다.

"평균 말고 중앙값으로 다시 뽑아 주세요. 큰 계약 두 건이 숫자를 다 끌고 갔어요."

소수의 큰 값이 평균을 왜곡했으니 그 영향을 받지 않는 값으로 보자는 요청입니다.

"평균은 1.5초인데 중앙값은 0.3초예요. 느린 쪽이 따로 있다는 뜻이죠."

두 값의 격차 자체를 문제의 위치를 가리키는 단서로 쓰는 말입니다.

"중앙값이 올라갔다고 다 좋아진 건 아니에요. 아래쪽이 빠져나갔을 수도 있어요."

가운데 값이 움직인 이유가 개선이 아니라 이탈일 수 있다고 짚는 말입니다.

페이지덱에서 이 숫자가 가장 자주 오가는 자리는 지현과 태오가 함께 보는 성능 점검 회의입니다. 태오가 응답 시간을 평균과 중앙값 두 줄로 올리면 지현이 둘의 격차부터 봅니다. 격차가 크면 그달의 과제는 전체를 빠르게 만드는 것이 아니라 느린 요청이 어떤 상황에서 생기는지를 찾는 쪽으로 정해집니다.

같은 숫자가 요금제 논의에도 들어옵니다. 수아가 계약 규모를 보고할 때 평균 계약액만 올리면 대형 계약 한두 건이 숫자를 밀어 올려서, 실제로 들어오는 계약이 어느 크기인지 규원이 판단하기 어렵습니다. 중앙값을 함께 적으면 대부분의 계약이 어느 선에 있는지가 드러납니다.

중앙값이 평균보다 정확한 숫자라고 여기는 오해가 가장 흔합니다. 평균이 왜곡되는 사례를 몇 번 겪고 나면 그렇게 정리하기 쉽습니다. 하지만 두 값은 서로 다른 질문에 답합니다. 총합이 중요한 자리에서는 평균이 맞습니다. 서버 비용이 사용량 합계로 매겨진다면 사용자당 평균 사용량에 인원을 곱해야 다음 달 청구서가 나오고, 중앙값에 인원을 곱한 값은 아무 의미가 없습니다. 정확한 쪽을 고르는 문제가 아니라 질문에 맞는 쪽을 고르는 문제입니다.

중앙값을 쓰면 이상치가 처리된다고 생각하는 것도 잦은 오해입니다. 튀는 값에 흔들리지 않으니 문제가 사라진 것처럼 보이기 때문입니다. 실제로는 그 값이 그대로 남아 있고 보고서에서만 가려집니다. 6.2초가 걸린 요청은 여전히 매일 일어나고 그 요청을 보낸 사용자는 여전히 6.2초를 기다립니다. 중앙값만 올려 두고 넘어가면 몇 달 뒤 이탈이 늘어난 다음에야 원인을 찾게 됩니다. 튀는 값은 가려 두는 것이 아니라 왜 생겼는지 따로 보는 것입니다.