최적화하기 전에 측정하세요: Paul Irish의 속도 작업 흐름

최적화하기 전에 측정하지 않으면 왜 보통 시간이 낭비될까

수정부터 시작하면 성능 작업이 무작위로 느껴집니다. 어느 날은 파일을 축소하고, 다음 날에는 캐싱을 조정하고, 또 다른 날에는 라이브러리를 제거합니다. 가끔은 효과가 있지만, 가끔은 아무 변화도 없고 이유를 모릅니다.

가장 큰 위험은 잘못된 것을 최적화하는 것입니다. 페이지가 JavaScript 때문에 메인 스레드가 막혀 느린데 이미지 압축에 몇 시간을 쓰면 거의 효과가 없습니다. 또는 실제 지연은 긴 API 호출, 계속해서 재레이아웃되는 레이아웃, 또는 하나의 차단 스크립트인데 사용자에게는 눈에 띄지 않는 부분만 빨라질 수 있습니다.

또한 "느껴지는 속도"로 판단하는 함정이 있습니다. 스피너 같은 플라시보 효과나 다른 네트워크, 기기, 시간대에서의 테스트로 인해 "더 빠르게 느껴질" 수 있습니다. "더 빠르다"는 같은 동작을 같은 조건에서 했을 때 수치가 나아진 경우를 말합니다.

간단한 약속 하나가 대부분을 해결합니다: 최적화하기 전에 측정하고, 그다음 결정하세요. 성능을 측정 문제로 다루면 추측을 멈추고 학습을 시작합니다.

실용적인 루프는 이렇게 생겼습니다: 개선할 한 가지 사용자 행동을 고르고, 재현 가능한 조건에서 기준선을 기록하고, 설명할 수 있는 한 가지 변경을 하고, 다시 측정해 숫자가 개선될 때만 변경을 유지합니다.

Paul Irish와 먼저 측정하는 습관

Paul Irish는 웹 성능 분야에서 널리 알려진 목소리 중 하나입니다. 브라우저 도구와 성능 가이드에 대한 그의 작업은 직관적인 아이디어를 대중화하는 데 기여했는데, 그것은 바로: 처음 할 일은 무엇이 느린지 짐작하는 것이 아니라 그것을 증명하는 것이다 라는 점입니다.

그 사고방식은 팀 역학을 바꿉니다. "항상 이미지 때문이야" 또는 "프레임워크 탓일 거야" 같은 습관적 주장 대신 증거에서 시작합니다. 타임라인, 느린 쿼리, 긴 작업을 지적할 수 있으면 대화는 비난에서 해결로 바뀝니다.

"최적화 전에 측정"은 또한 성능 논쟁을 가라앉힙니다. 측정할 대상을 합의하고, "더 나아짐"의 기준을 합의하며, 숫자가 움직일 때만 축하하기 때문입니다.

이 방법은 작은 사이트와 대형 앱 모두에 통합니다. 단일 기준선은 마케팅 페이지에서 무작위한 마이크로 최적화를 멈추게 할 수 있고, 큰 제품에서는 일관된 측정이 성능이 끝없는 할 일 목록으로 변하는 것을 막아줍니다.

이를 현실화하는 간단한 방법은 성능을 버그 리포트처럼 다루는 것입니다: 재현 단계, 관찰한 메트릭, 그리고 한 가지 변경과 그 결과를 명확히 적습니다. 두 사람이 다르면 측정을 다시 실행하고 데이터에 맡기세요.

성능을 계측 문제로 보기

먼저 성능을 계측 문제로 다루세요: 사용자가 실제로 무엇을 경험하는지 관찰할 방법을 추가하세요. 보이지 않으면 의견만으로 논쟁하게 됩니다. 이것이 먼저 측정하라는 진짜 의미입니다.

계측은 화려할 필요가 없습니다. 같은 위치에서 일관되게 몇 가지 신호를 모아 기본 질문에 답할 수 있게 하는 것입니다:

• 무엇이 느리게 느껴지나?
• 시간이 어디로 가나?
• 우리의 변경이 도움이 되었나?

보통 두 가지 종류의 데이터가 필요합니다.

랩 데이터는 제어된 설정에서 캡처됩니다: 특정 노트북이나 테스트 기기, 안정된 네트워크 프로필, 매번 같은 단계. 재현이 쉬워 디버깅에 좋습니다.

실사용자 데이터는 다양한 기기, 위치, 연결 품질에서 사용자가 실제로 겪는 경험입니다. 우선순위를 정할 때 유용합니다.

전문가가 아니어도 페이지 로드 주요 지표(예: 첫 번째 콘텐츠 표시), 긴 작업과 메인 스레드 차단, 느린 네트워크 요청, 비용이 큰 렌더링 작업(레이아웃, 스타일, 페인트), 서버 응답 시간을 측정할 수 있습니다.

이 신호들은 보통 몇 곳에 있습니다: 랩 프로파일링을 위한 브라우저 개발자 도구, 백엔드 타이밍을 위한 서버 로그와 트레이스, 그리고 실사용자 데이터를 위한 애널리틱스나 RUM 대시보드. 예를 들어 체크아웃이 느리게 느껴진다면 DevTools는 브라우저가 거대한 카트 UI를 렌더링하느라 바쁘다고 보여줄 수 있고 서버 로그는 API가 빠르다고 할 수 있습니다. 계측이 없으면 백엔드를 최적화하고도 실제 문제를 고치지 못할 수 있습니다.

1단계: 반복 가능한 기준선 설정

최적화하기 전에 측정하려면 신뢰할 수 있는 시작점이 필요합니다. 기준선은 같은 동작을 같은 방식으로 같은 조건에서 측정한 값입니다.

하나의 실제 사용자 여정부터 시작하세요. "사이트 전체"가 아니라 한 문장으로 설명할 수 있는 것, 예를 들어 "홈페이지를 열고 첫 제품 그리드까지 스크롤" 또는 "로그인해서 대시보드에 도달" 같은 것을 고르세요. 좁게 정하면 숫자가 더 안정되고 다음 단계도 명확해집니다.

다음으로 여정에 맞는 1~3개의 메트릭을 고르세요. 페이지 뷰의 일반적 조합은 LCP(주요 콘텐츠가 나타나는 속도)와 TTFB(서버 응답 속도)입니다. 체크아웃 같은 흐름에서는 1단계 완료 시간과 결제 호출의 API 응답 시간을 함께 추적할 수 있습니다. 메트릭이 너무 많으면 선택 편향이 쉬워집니다.

테스트 설정을 적어 두어 다른 사람이 재현할 수 있게 하세요. 작은 차이도 결과를 크게 바꿀 수 있습니다:

• 기기 및 브라우저(버전 포함)
• 네트워크(와이파이 vs 4G, 스로틀링 온/오프)
• 캐시 상태(콜드 vs 웜)
• 위치 및 테스트 데이터(지역, 계정 유형, 장바구니 크기)
• 실행 횟수(예: 5회 실행 후 중앙값 사용)

마지막으로 대상 사용자에 맞는 "충분히 좋은" 기준을 정의하세요. 예: "중급형 폰에서 4G 기준 LCP 2.5초 이하." Koder.ai를 쓴다면 테스트 전에 스냅샷을 찍어 기준선을 특정 버전에 묶어두는 것이 도움이 됩니다.

2단계: 느려지는 현상을 의도적으로 재현하기

프로파일링 전에 문제를 다시 발생시킬 수 있게 하세요. 재현할 수 없다면 결과를 믿을 수 없습니다.

가정이 아니라 사람들이 느끼는 증상에서 시작하세요. 첫 렌더가 느린가요? 클릭 후 멈추나요? 폼 제출 후 긴 기다림이 있나요? 사용자가 불평하는 순간 하나를 골라 거기에 집중하세요.

빠르게 한 번 실행해 느려짐이 실제로 반복되는지 확인하세요. 다른 모든 것을 동일하게 유지하세요: 같은 페이지, 같은 기기, 가능하면 같은 네트워크. 그런 다음 트리거와 정확히 언제 느려지는지 적으세요(예: "결제 클릭 후 버튼이 1초 멈춤" 또는 "제품 목록 등장 시 스크롤이 끊김").

반복 가능하게 유지하는 간단한 방법은 작은 스크립트입니다: 새 탭에서 페이지 열기, 지연이 발생하는 행동 수행, 느려지는 정확한 지점 기록, 한 번 더 반복해 확인.

기록은 한두 번의 기준선 녹화만 캡처하세요. 목적은 "예, 느려짐이 있고 바로 여기서 발생한다"는 증거를 확보하는 것입니다.

3단계: 프로파일링으로 주요 병목 찾기

느려짐을 재현할 수 있게 되면 추측을 멈추세요. 프로파일러(대부분 사람에게는 브라우저의 Performance 패널)를 열고 느린 상호작용을 한 번 녹화하세요. 목표는 모든 문제를 찾는 것이 아니라 시간이 어디로 가는지 배우는 것입니다.

가장 큰 시간 블록부터 보세요. 작은 스파이크는 실제일 수 있지만 보통 눈에 띄는 지연을 설명하지 않습니다.

녹화를 읽는 유용한 방법은 시간을 몇 개의 버킷으로 그룹화하는 것입니다: 네트워크 및 로딩(요청 대기), 메인 스레드 스크립팅(긴 JavaScript 작업), 렌더링 및 페인트(레이아웃·스타일 작업), 유휴 간격(다른 것을 기다림), 반복 작업(같은 비싼 단계가 반복됨).

흔한 실수는 느린 서버 응답과 느린 클라이언트 작업을 혼동하는 것입니다. 타임라인에 요청 대기 중 긴 간격이 보이면 병목은 네트워크나 백엔드일 가능성이 큽니다. 긴 작업이 메인 스레드에 보이면 네트워크가 빠르더라도 프런트엔드 문제입니다.

무엇도 바꾸기 전에 관찰한 내용을 바탕으로 짧고 테스트 가능한 가설을 적으세요. 예: "API 응답이 도착한 직후 JSON 파싱으로 메인 스레드가 막혀서 페이지가 느리게 느껴진다." 이 한 문장이 다음 단계를 이끕니다.

4단계: 의도적으로 한 가지를 변경하기

가능성 있는 병목을 찾았으면 모든 것을 고치려는 충동을 참으세요. 인과관계를 연결할 수 있도록 변수 하나만 바꿔야 합니다.

변경은 작고 되돌리기 쉬워야 합니다. 대규모 리팩터링은 결과를 흐리게 합니다: 성능이 좋아지면 이유를 모릅니다. 나빠지면 되돌리기도 위험합니다.

좋은 한 가지 변경 예시는 구체적이고 테스트 가능해야 합니다. 차단 렌더링을 유발하는 서드파티 스크립트 하나를 지연시키거나 제거하기, 느린 페이지의 한 장황한 이미지 압축하기, 비싼 DB 쿼리 하나에 캐싱 추가하기, 무거운 UI 컴포넌트 하나를 분할해 초기 렌더 작업을 줄이기, 프로파일에서 본 핫 루프 하나의 작업량 줄이기 등이 있습니다.

코드를 건드리기 전에 무엇을 왜 바꿨는지, 그리고 무엇이 개선되리라 예상하는지 적으세요(예: "메인 스레드 시간 감소" 또는 "DB 시간 절반 단축").

팀이 스냅샷과 롤백을 지원하는 플랫폼(Koder.ai 같은)을 쓴다면 변경 직전에 스냅샷을 찍어 "작고 되돌리기 쉬움"을 현실로 만드세요.

5단계: 영향 검증하고 소음에 속지 않기

한 가지를 변경했으면 그것이 실제로 도움이 되었는지 증명하세요.

기준선에 사용한 것과 정확히 같은 테스트 설정을 다시 실행하세요: 동일한 기기, 동일한 브라우저 버전, 동일한 경로와 흐름, 동일한 실행 횟수. 동일한 메트릭으로 전후를 비교하세요. 중간에 새 메트릭을 추가해 더 좋아 보이는 수치만 보는 실수는 하지 마세요.

노이즈는 팀이 성능으로 다툴 때 가장 흔한 원인입니다. 캐시 콜드/웜 차이, 확장 프로그램·백그라운드 프로세스, 다른 네트워크 조건이나 VPN 설정, 서버 변동(한가한 시간 vs 바쁜 시간), 배포 직후와 안정 상태의 차이를 주의하세요.

중앙값이 개선되었으나 최악의 경우가 더 나빠졌다면 그것은 실제 트레이드오프입니다. 사용자에게 무엇이 중요한지 결정하고 결정 내용을 문서화하세요: 변경 유지, 되돌리기, 또는 새 가설을 세워 다시 테스트.

성능 작업을 불가능하게 만드는 흔한 함정

성능 작업은 잘못된 것을 측정하거나 한 번에 너무 많은 것을 바꿀 때 혼란스러워집니다. 앱이 개선되어도 명확한 승리를 얻지 못하고 많은 노력을 낭비할 수 있습니다.

한 가지 흔한 실수는 단일 점수를 목표로 삼는 것입니다. 점수는 유용할 수 있지만 사용자는 "92"라는 점수를 경험하지 않습니다. 사용자는 "페이지가 2초 만에 콘텐츠를 표시한다"거나 "구매 탭이 즉시 반응한다" 같은 것을 경험합니다. 사용자에게 보이는 결과 하나를 일관되게 측정하세요.

또 다른 함정은 강력한 노트북에서만 테스트하는 것입니다. 많은 느려짐은 중급형 폰이나 불안정한 네트워크, CPU가 바쁠 때 드러납니다. 가장 좋은 기기에서만 프로파일하면 병목을 놓칠 수 있습니다.

혼란은 보통 다음과 같은 패턴에서 옵니다: 쉬운 것만 개선, 여러 수정을 한 번에 묶음, 매번 다른 테스트 경로 사용, "느껴지게 더 빠르다"며 재테스트 건너뜀, 동일한 기준선 재실행 없이 승리 선언.

채팅 기반 플랫폼(예: Koder.ai)으로 앱을 만들 때도 같은 규율이 필요합니다: 한 가지 변경, 그리고 정확히 같은 흐름에서 검증해 결과를 신뢰하세요.

재사용 가능한 빠른 체크리스트

습관 하나만 유지한다면 이걸 유지하세요: 최적화 전에 측정하세요. 목표는 끝없는 데이터가 아니라 신뢰할 수 있는 반복 가능한 루프입니다.

정확한 사용자 여정을 이름으로 정하세요. "홈페이지가 느리다"는 모호합니다. "제품 페이지에서 Buy 클릭 후 확인 화면까지"처럼 반복 가능한 클릭 경로를 주면 됩니다.

이 체크리스트를 사용하세요:

• 누구나 반복할 수 있게 여정을 짧은 스크립트로 적기.
• 설정 고정(기기, 브라우저, 네트워크, 가능하면 위치).
• 기준선 숫자와 기준선 녹화 캡처.
• 프로파일링, 가장 큰 병목 선택, 한 가지 변경.
• 재테스트, 새 숫자 기록, 결정 작성.

차분한 성능 작업은 단순합니다: 하나의 경로, 하나의 설정, 한 가지 변경, 하나의 검증된 결과.

예시: 추측 없이 느린 체크아웃 고치기

흔한 불만: 고객이 "Pay"를 클릭한 직후 체크아웃이 느리게 느껴진다. 사람들은 이미지나 폰트, 버튼을 짐작하기 시작합니다. 대신 재현 가능한 테스트로 다루세요.

다시 실행할 수 있는 기준선을 설정하세요. 한 기기와 한 경로(cart -> checkout -> Pay -> confirmation)를 고르고 네트워크 스로틀링을 켭니다(예: Fast 3G)—모든 실행에서 동일하게 유지하세요. 측정할 단순한 숫자 하나만 고릅니다: "Pay 클릭부터 확인 화면 표시까지 시간."

그 순간을 프로파일하고 시간이 어디로 가는지 보세요. 보통 세 가지 버킷 중 하나를 결정하게 됩니다: 네트워크(긴 요청 또는 너무 많은 요청), 서버(결제 호출이 느리며 브라우저는 유휴), 또는 메인 스레드(브라우저가 JavaScript를 실행하느라 UI를 갱신하지 못함).

프로파일에서 결제 클릭 이후 브라우저가 분석 요청과 사기 방지 스크립트 호출을 먼저 보내고 결제 요청이 그 뒤에 대기하는 것으로 나온다고 가정해 보세요. 이건 "모든 것을 빠르게 만들자" 문제가 아닙니다. 하나의 차단 단계 문제입니다.

의도적으로 한 가지를 변경하세요. 예: 결제 요청을 즉시 시작하게 하고 분석은 확인 화면이 보인 뒤에 전송하세요.

동일한 설정으로 검증하세요: 동일한 스로틀링, 동일한 단계, 여러 번 실행. 확인 시간(confirmation time)이 줄고 에러가 늘어나지 않으면 실제 개선입니다. 환불, 재시도, 더블 서브밋 방지 기능이 깨지지 않았는지도 확인하세요.