[실전 성능 01] 왜 측정부터 하는가

내가 개발한 커뮤니티 사이트를 몇 달 굴리다 보니, 어느 날부터 사람들이 느리다고 말하기 시작했다. 그런데 정작 내 컴퓨터에서는 멀쩡히 빨랐다. 이 간극이 성능 최적화를 시작한 이유였다. 이번 편은 코드를 고치기 전에 왜 측정부터 해야 하는지에 대한 이야기다.

1. 체감과 지표는 다르다

처음에 나는 성능을 감으로 판단했다. 내 노트북에서 페이지가 순식간에 뜨니까 사이트가 빠른 줄 알았다. 그런데 이건 완전한 착각이었다. 나는 개발자라 브라우저에 캐시가 잔뜩 쌓여 있었고, 사무실 인터넷은 빨랐으며, 무엇보다 방금 배포한 코드라 모든 자원이 로컬에 데워져 있었다. 실제 방문자는 처음 오는 사람이고, 캐시가 비어 있고, 지하철에서 느린 모바일 데이터로 접속한다. 나와 그들은 애초에 완전히 다른 환경에 있었던 것이다.

체감은 이렇게 사람마다 다르고, 같은 사람도 상황마다 다르다. 어떤 사람은 첫 글자가 늦게 떠서 느리다고 느끼고, 어떤 사람은 화면이 떴는데 버튼이 안 눌려서 느리다고 느낀다. 또 어떤 사람은 스크롤하다가 이미지가 뒤늦게 끼어들면서 읽던 위치가 밀려 짜증을 낸다. 이 세 가지는 전부 느리다는 한 단어로 묶이지만, 원인도 해법도 완전히 다르다. 감으로는 이걸 도저히 구분할 수 없었다.

더 곤란한 건 내가 나쁜 표본이라는 사실이었다. 개발자는 자기 사이트를 하루에도 수십 번 열기 때문에 브라우저와 시스템에 온갖 캐시가 남아 있다. 그 상태에서 재는 속도는 세상 누구의 경험도 대변하지 못했다. 시크릿 창을 열고 네트워크를 느린 회선으로 강제한 뒤에야 나는 처음으로 사용자와 비슷한 화면을 봤고, 그제야 사람들이 느리다고 한 이유를 실감했다.

그래서 나는 규칙을 하나 세웠다. 느낌으로 고치지 말고 숫자로 고치자는 것이었다. 무엇이 얼마나 느린지 수치로 잡히지 않으면, 아무리 코드를 만져도 그게 나아진 건지 나빠진 건지조차 알 수 없다. 측정 없는 최적화는 불 꺼진 방에서 벽을 더듬는 것과 같았다. 나는 이 규칙을 지키기 시작하면서부터 헛수고가 눈에 띄게 줄었고, 무엇보다 내가 한 일에 확신을 가질 수 있게 되었다. 확신은 곧 속도였다.

2. 지표가 있어야 개선을 증명한다

측정의 진짜 가치는 개선을 증명하는 데 있었다. 예를 들어 이미지 처리 방식을 바꿨다고 치자. 감으로는 빨라진 것 같지만, 실은 다른 곳이 느려져서 전체적으로는 손해일 수도 있다. 숫자가 없으면 이런 착시에 그대로 속는다. 나는 변경 전 수치를 먼저 기록하고, 변경 후 같은 조건에서 다시 재는 습관을 들였다. 그래야 이 커밋이 무엇을 얼마나 바꿨는지 떳떳하게 말할 수 있었다.

또 하나 배운 건, 좋아 보이는 변경이 실제로는 아무 효과가 없는 경우가 흔하다는 점이었다. 나는 한동안 자바스크립트 번들을 열심히 줄였는데, 정작 사용자들이 느끼던 병목은 서버가 첫 응답을 늦게 주는 것이었다. 번들을 아무리 줄여도 첫 바이트가 늦으면 소용이 없었다. 측정을 해보고 나서야 내가 엉뚱한 곳에 힘을 쓰고 있었다는 걸 알았다. 가장 무거운 것부터 손대야 하는데, 무엇이 가장 무거운지는 재봐야만 나온다.

측정은 우선순위를 정해주는 도구였다. 시간과 체력은 한정돼 있으니, 효과가 큰 순서대로 고쳐야 한다. 그 순서를 정하는 유일하게 정직한 방법이 측정이었다. 나는 이걸 깨닫고 나서 최적화 작업 시간의 절반을 재는 데 쓰게 되었고, 오히려 전체 작업이 빨라졌다.

측정은 또한 멈출 시점을 알려줬다. 성능은 파고들면 끝이 없어서, 목표 없이 손대면 사소한 이득을 위해 며칠을 태우게 된다. 나는 각 지표에 통과선을 정해두고, 그 선을 넘으면 그만두고 다음 문제로 넘어갔다. 숫자가 있으니 어디까지가 충분한지도 판단할 수 있었다. 완벽한 성능보다 충분히 좋은 성능을 여러 곳에 골고루 확보하는 편이 사용자 경험 전체로 보면 훨씬 이득이었다.

3. 실험실 데이터와 현장 데이터

측정에는 크게 두 종류가 있었다. 하나는 내 손으로 브라우저 개발자 도구를 열어 재는 실험실 측정이고, 다른 하나는 실제 방문자들의 브라우저에서 수집되는 현장 측정이었다. 둘은 목적이 서로 달랐다. 실험실 측정은 조건을 고정할 수 있어서 원인을 파고들 때 좋았다. 같은 네트워크, 같은 기기로 반복하면 내가 바꾼 게 효과가 있었는지 깨끗하게 비교됐다.

반면 현장 측정은 진짜 사용자들이 겪는 현실을 담았다. 세상에는 오래된 저가 안드로이드 폰도 있고, 산속의 느린 회선도 있다. 내가 아무리 좋은 기기로 재도 그들의 고통은 안 보인다. 그래서 진짜 성능은 현장 데이터로 판단해야 했다. 나는 실험실에서 원인을 찾고, 현장에서 결과를 확인하는 식으로 둘을 나눠 썼다.

중요한 건 현장 데이터를 볼 때 평균에 속지 않는 것이었다. 평균은 소수의 아주 빠른 접속에 끌려가서 실제보다 낙관적으로 보였다. 그래서 업계는 75 백분위수를 본다. 방문의 4분의 3이 좋은 경험을 해야 통과로 치는 것이다. 나는 이 기준을 받아들였다. 상위권만 빠른 게 아니라 대다수가 만족해야 비로소 빠른 사이트라고 부를 수 있었다.

두 데이터가 어긋날 때가 오히려 값진 순간이었다. 실험실에서는 빠른데 현장에서는 느리다면, 내가 못 가진 기기나 네트워크에서 문제가 나는 것이다. 나는 그럴 때 접속 기기와 지역 분포를 뒤져서 특정 조건에서만 터지는 병목을 찾아냈다. 두 시선을 겹쳐 봐야 사각지대가 줄었다. 어느 한쪽만 믿으면 반드시 놓치는 사용자가 생겼고, 그 소수가 종종 가장 크게 실망하고 떠나는 사람들이었다.

4. 측정하지 않으면 생기는 일

측정 없이 개발하던 시절 나는 같은 실수를 반복했다. 좋다는 기법을 여기저기서 주워다 무작정 적용했고, 그러다 오히려 느려진 걸 몇 주 뒤에야 발견하곤 했다. 원인을 찾으려 해도 그때는 이미 여러 변경이 뒤섞여서 어느 것이 범인인지 알 수 없었다. 측정이 없으니 되돌릴 지점도 없었다.

더 큰 문제는 사용자 이탈이 조용히 일어난다는 점이었다. 느려서 떠난 사람은 항의하지 않고 그냥 다시 안 온다. 나는 그 손실을 눈으로 볼 수 없었다. 지표를 붙이고 나서야 특정 페이지에서 사람들이 유독 빨리 나간다는 걸 알게 됐고, 그 페이지가 바로 첫 화면이 늦게 뜨는 곳이었다. 숫자가 없었다면 영영 몰랐을 일이다.

측정은 팀 안의 논쟁도 정리해줬다. 혼자 만들 때도 어제의 나와 오늘의 나가 다투는데, 근거가 감이면 목소리 큰 쪽이 이긴다. 숫자를 올려두면 토론이 짧아지고 결정이 정확해졌다. 이건 협업이 늘수록 더 크게 체감됐다. 지표는 서로 다른 주장을 하나의 사실 위에 세워주는 공용어 같은 역할을 했다.

그래서 나는 무엇을 고치기 전에 항상 재는 것부터 했다. 지금 상태를 숫자로 박아두고, 목표 숫자를 정하고, 고친 뒤 다시 재서 비교했다. 이 지루한 절차가 결국 가장 빠른 길이었다. 어림짐작으로 헤매는 것보다 훨씬 적은 노력으로 훨씬 큰 개선을 얻었다.

5. 이 시리즈에서 다룰 것

이 시리즈는 내가 커뮤니티 사이트를 만들면서 성능을 재고 고친 경험을 순서대로 풀어낸다. 먼저 무엇을 재야 하는지, 즉 로딩 속도와 시각 안정성과 반응성이라는 세 가지 핵심 지표를 살펴본다. 그다음 이미지와 폰트처럼 실제로 화면을 늦추는 요소들을 하나씩 다룬다.

이어서 렌더링을 막는 자원과 번들 크기, 그리고 서버가 첫 응답을 빨리 주도록 만드는 캐시와 서버 렌더링 이야기로 넘어간다. 마지막에는 사람이 아닌 봇이 성능과 비용에 주는 부하, 그리고 이 모든 걸 지속적으로 재는 루틴까지 정리할 생각이다. 전부 내가 직접 겪고 고친 것들이라, 교과서보다 실수담에 가깝다.

미리 한 가지만 약속해두겠다. 이 시리즈의 어떤 편도 재보라는 말을 빼놓지 않을 것이다. 기법 자체보다 그 기법이 내 사이트에서 실제로 효과가 있었는지 확인하는 습관이 훨씬 중요하기 때문이다. 남의 성공 사례가 내 환경에서도 통한다는 보장은 어디에도 없었다.

이번 편의 결론은 단순하다. 성능 최적화의 첫걸음은 코드가 아니라 자로 재는 일이었다. 다음 편에서는 그 자에 해당하는 핵심 웹 지표가 무엇이고, 왜 하필 세 개인지, 그리고 각 숫자가 사용자의 어떤 경험을 대변하는지를 본격적으로 뜯어보겠다.