성능 점수보다 다시 설명할 수 있는 측정 기록을 남기기

블로그와 모바일 화면을 만들며 이미지 최적화, 코드 분할, 불필요한 렌더링을 줄이는 작업을 했다. 포트폴리오에는 과거 측정 기록도 남겼다. 그런데 시간이 지난 뒤 그 숫자를 다시 쓰려면 먼저 물어야 한다. 어느 화면을 어떤 조건에서 측정한 결과였을까.

숫자에는 시점과 조건이 붙어야 한다

한 번 측정한 점수는 그때의 코드와 콘텐츠, 환경에 대한 결과다. 글과 이미지가 늘어나거나 공통 스크립트가 추가되면 같은 사이트라도 달라질 수 있다. 과거 결과를 현재 모든 페이지의 성능처럼 표현하면 기록의 의미가 바뀐다.

이 회고에서는 과거 점수를 현재 보장처럼 옮기지 않는다. 오히려 다음 측정에서는 경로, 변경 전후의 코드, 기기 조건, 측정 일시를 함께 남기고 싶다. “빨라졌다”는 문장보다 다른 사람이 같은 조건을 따라갈 수 있는 기록이 중요하다.

최적화 전에 병목을 구분하기

첫 화면이 늦는 이유가 큰 이미지인지, 자바스크립트 실행인지, 외부 요청인지에 따라 할 일이 달라진다. React.memo를 적용했다고 모든 로딩 문제가 줄어드는 것은 아니다. 이미지가 화면을 밀어내는 문제와 컴포넌트가 자주 다시 그려지는 문제도 다른 축이다.

지금이라면 하나의 대표 사용자 흐름을 정하고 그 안에서 가장 큰 지연을 찾겠다. 변경을 여러 개 동시에 넣으면 무엇이 효과가 있었는지 분리하기 어렵다. 원인을 좁힌 뒤 필요한 변경을 하고 같은 조건으로 다시 비교하는 쪽이 다음 작업의 근거가 된다.

실험실 점수와 사용자 경험 사이

정해진 환경에서의 검사는 회귀를 찾는 데 유용하다. 하지만 실제 사용자는 다른 네트워크와 기기, 저장된 상태로 접속한다. 당시 프로젝트 회고에도 실사용 성능 모니터링이 충분하지 않았다는 아쉬움을 남겼다. 이를 도구 하나의 점수로 덮고 싶지는 않다.

성능 작업에서 내게 남은 기준은 최적화 기법을 많이 적용하는 것이 아니다. 문제를 설명하고, 바꾼 이유를 기록하고, 결과의 범위를 넘어서 말하지 않는 것이다. 다음 포트폴리오에는 좋은 숫자만 적기보다 그 숫자를 만든 조건과 아직 확인하지 못한 부분까지 함께 남기겠다.

관련 기록: Toris Blog 개발 경험