[실전 성능 15] 무엇을 재고 있나

지난 편에서 봇을 발견하고 다스린 이야기를 했다. 그 발견의 바탕에는 측정이 있었다. 사실 이 시리즈 내내 재보라는 말을 반복했는데, 정작 어떤 도구로 어떻게 재는지는 미뤄뒀다. 이번 편은 그 측정 도구들과, 그것들이 실제로 무엇을 세고 있는지, 그리고 숫자를 잘못 읽게 만드는 함정을 정리한다.

1. 도구마다 세는 것이 다르다

측정을 시작하며 처음 당황한 건 도구마다 숫자가 다르다는 점이었다. 같은 사이트인데 어떤 도구는 접속자를 아주 크게, 다른 도구는 훨씬 작게 보여줬다. 처음엔 어느 게 맞는지 몰라 혼란스러웠다. 알고 보니 둘 다 맞았고, 다만 세는 대상과 방식이 달랐다. 숫자가 다른 게 아니라 정의가 다른 것이었다.

어떤 도구는 네트워크 관문에서 오가는 모든 요청을 셌다. 여기에는 사람은 물론 봇, 그리고 각종 자동 요청이 다 포함됐다. 그래서 이 숫자는 컸다. 반면 다른 도구는 브라우저에서 실제로 페이지가 열릴 때만 셌다. 봇은 대개 브라우저처럼 동작하지 않으니 이 숫자에서는 빠졌다. 그래서 이 숫자는 실제 사람에 가까웠다.

이 차이를 모르고 두 숫자를 비교하면 엉뚱한 결론에 이르렀다. 큰 숫자를 보고 사람이 많이 온다고 착각하거나, 두 숫자가 다르다고 도구가 고장 났다고 오해했다. 나는 각 도구가 무엇을 세는지 정확히 알고 나서야 숫자를 제대로 읽을 수 있었다. 도구를 쓰기 전에 그 도구의 정의부터 이해하는 게 순서였다.

그래서 나는 목적에 따라 도구를 골라 썼다. 실제 사람의 방문을 알고 싶으면 브라우저 기반 숫자를, 봇을 포함한 전체 부하를 알고 싶으면 네트워크 관문 숫자를 봤다. 두 숫자의 차이 자체가 봇의 규모를 알려주는 정보이기도 했다. 어느 하나가 옳은 게 아니라 각자 다른 질문에 답하는 도구였다. 나는 두 숫자가 다르다고 어느 쪽을 버리는 대신 그 차이를 읽는 법을 익혔고, 서로 다른 정의를 가진 숫자를 나란히 놓고 비교할 때 비로소 트래픽의 실체가 입체적으로 보였다.

2. 실험실과 현장을 나누기

측정 도구는 크게 두 부류로도 나뉘었다. 하나는 내가 직접 조건을 정해 재는 실험실 도구였다. 브라우저 개발자 도구로 네트워크와 처리 속도를 강제로 조절하며 재면, 조건을 고정한 깨끗한 측정이 나왔다. 이건 원인을 파고들 때 좋았다. 같은 조건에서 반복하니 내가 바꾼 것의 효과가 또렷이 보였다.

다른 하나는 실제 사용자들의 브라우저에서 자동으로 수집되는 현장 도구였다. 이건 진짜 사용자들이 다양한 기기와 회선에서 겪는 실제 경험을 담았다. 내가 상상 못 한 느린 환경의 고통이 여기에 잡혔다. 실험실에서는 안 보이던 문제가 현장 데이터에서 드러나곤 했다. 진짜 성능은 결국 이 현장 숫자로 판단해야 했다.

두 도구는 상호 보완적이었다. 현장 도구로 문제가 있다는 걸 발견하고, 실험실 도구로 그 원인을 파고들고, 고친 뒤 다시 현장 도구로 결과를 확인하는 흐름이었다. 실험실만 보면 현실을 놓치고, 현장만 보면 원인을 못 찾았다. 나는 두 도구를 오가며 발견과 진단과 검증을 이어갔다. 어느 하나로는 부족했다. 현장 도구가 어디가 아픈지 알려주는 청진기였다면 실험실 도구는 왜 아픈지 들여다보는 현미경이었고, 진단부터 치료 확인까지 이어가려면 두 도구를 함께 손에 쥐어야 했다.

특히 조심한 건 실험실 숫자에 안심하지 않는 것이었다. 내 좋은 기기의 실험실 측정은 늘 낙관적이었다. 그 숫자만 보면 다 괜찮아 보였지만, 현장에서는 느린 기기 사용자들이 여전히 고생하고 있었다. 나는 실험실에서 통과해도 현장 숫자가 통과선을 넘을 때까지 안심하지 않았다. 진실은 현장에 있었다.

3. 평균이라는 함정

현장 데이터를 볼 때 가장 큰 함정은 평균이었다. 성능 숫자를 평균 내면 실제보다 훨씬 좋아 보였다. 대부분 빠른데 소수만 느리면, 평균은 그 소수의 고통을 희석해서 괜찮은 것처럼 보이게 했다. 나는 평균만 보고 문제없다고 판단했다가, 실은 상당수 사용자가 고생하고 있던 걸 뒤늦게 안 적이 있었다.

그래서 업계는 평균 대신 백분위수를 봤다. 방문을 느린 순서로 줄 세웠을 때 4분의 3 지점, 즉 75 백분위수의 값을 기준으로 삼았다. 이는 방문의 4분의 3이 그 값보다 좋아야 통과라는 뜻이었다. 소수의 빠른 접속으로는 이 기준을 못 넘겼다. 대다수가 실제로 좋은 경험을 해야만 통과하는 엄격한 기준이었다.

이 기준을 받아들이니 시선이 달라졌다. 잘 나오는 대다수가 아니라 못 나오는 뒤쪽을 봤다. 성능이 나쁜 하위 사용자들을 끌어올리는 것이 지표를 개선하는 길이었다. 이들은 대개 느린 기기나 회선을 쓰는 사람들이라, 백분위수를 챙긴다는 건 곧 소외되기 쉬운 사용자를 챙긴다는 뜻이었다. 숫자가 배려의 방향을 가리켰다. 평균을 좇으면 이미 잘 쓰는 다수를 더 챙기게 되지만, 백분위수를 좇으면 가장 힘든 소수를 끌어올리게 되니, 어떤 지표를 보느냐가 곧 누구를 위해 일하느냐를 결정했다.

백분위수는 문제의 규모도 알려줬다. 뒤쪽 값이 통과선에서 얼마나 벗어났는지 보면 얼마나 심각한지 가늠됐다. 조금 넘었으면 미세 조정으로 되지만, 크게 벗어났으면 근본적인 손질이 필요했다. 나는 이 거리로 작업의 무게를 정했다. 평균 하나로는 알 수 없던 분포의 정보가 판단을 정교하게 만들었다.

4. 무엇이 무거운지 찾기

측정의 실용적인 목적은 무엇이 가장 무거운지 찾는 것이었다. 성능을 개선할 곳은 많지만 시간은 한정되니, 가장 효과가 큰 곳부터 손봐야 했다. 그러려면 각 요소가 얼마나 부담을 주는지 재서 순위를 매겨야 했다. 나는 무거운 조회나 느린 자원을 측정으로 찾아 목록을 만들고, 가장 위부터 공략했다.

이 순위는 종종 예상을 벗어났다. 무거울 줄 알았던 게 사소하고, 사소할 줄 알았던 게 큰 부담인 경우가 많았다. 짐작으로 덤볐다면 엉뚱한 곳에 힘을 썼을 것이다. 측정이 짐작을 바로잡아줬다. 나는 이 경험을 거듭하며 재기 전에는 무엇이 병목인지 단정하지 않는 습관을 굳혔다. 데이터가 늘 직관보다 정확했다.

무거운 것을 찾는 도구는 요청별로 부담을 갈라 보여줬다. 어떤 조회가 자원을 많이 쓰는지, 어떤 자원이 로딩을 늦추는지 갈라 보니 범인이 드러났다. 뭉뚱그린 전체 숫자로는 안 보이던 것이 갈라 보면 보였다. 나는 항상 전체를 구성 요소로 쪼개서 봤다. 쪼개야 어디를 고쳐야 할지가 나왔다. 전체 로딩이 느리다는 사실만으로는 손댈 곳을 알 수 없었지만, 그 시간을 여러 단계로 갈라 각 단계의 몫을 보면 가장 굵은 마디가 드러났고 그제야 공략 지점이 분명해졌다.

찾은 다음에는 고치고 다시 쟀다. 가장 무거운 걸 고치면 그 부담이 줄고, 이제 다른 것이 가장 무거운 자리로 올라왔다. 그럼 그다음을 공략했다. 이 반복으로 부담이 큰 순서대로 하나씩 걷어냈다. 측정과 개선을 번갈아 하며 사이트가 점점 가벼워졌다. 한 번에 다 하는 게 아니라 순서대로 쌓아가는 과정이었다.

5. 숫자를 겸손하게 읽기

측정 도구를 다루며 얻은 태도는 겸손이었다. 숫자는 강력하지만 잘못 읽으면 오히려 해로웠다. 도구가 무엇을 세는지, 평균의 함정은 없는지, 내 좋은 기기의 착시는 아닌지 늘 의심하며 읽었다. 숫자를 맹신하지 않고 그 숫자가 어떻게 만들어졌는지 따지는 것이 정확한 판단의 조건이었다.

동시에 숫자를 무시하지도 않았다. 감으로 판단하던 시절의 헤맴을 기억하니, 숫자의 가치를 알았다. 겸손하게 읽되 진지하게 받아들이는 균형이 필요했다. 숫자가 내 직관과 다를 때, 나는 대개 숫자를 믿었다. 다만 그 숫자가 정말 내가 생각한 그것을 재고 있는지는 꼭 확인했다. 믿되 검증하는 태도였다.

측정은 또한 사용자를 잊지 않게 해줬다. 숫자 뒤에는 실제로 느린 화면을 견디는 사람이 있었다. 백분위수의 뒤쪽 값은 지금 이 순간 고생하는 누군가의 경험이었다. 나는 숫자를 볼 때 그 뒤의 사람을 떠올렸다. 지표는 사람을 위한 대리자이지 그 자체가 목적이 아니라는 걸 측정 도구 앞에서 계속 되새겼다.

이렇게 무엇을 어떻게 재는지까지 정리했다. 이제 이 시리즈를 마무리할 때다. 다음 마지막 편에서는 지금까지 다룬 모든 것을 하나의 지속적인 루틴으로 엮는다. 한 번의 최적화로 끝나지 않고, 성능을 계속 좋은 상태로 유지하는 습관과 절차를 정리하며 시리즈를 닫겠다.