웹 성능 점검

코드 모양이나 점수 하나로 성능을 판단하지 않는다. 사용자가 느끼는 문제를 재현하고, 같은 조건에서 전후를 측정해 가장 큰 병목부터 다룬다.

초보자를 위한 용어

• 기준선: 변경 전이나 이전 버전의 측정값이다. 달리기 기록을 개선하려면 이전 기록이 필요한 것과 같다.
• 실험실 측정: 정해진 기기와 네트워크 조건을 흉내 내 반복하는 검사다.
• 실사용 측정: 실제 사용자의 기기와 네트워크에서 모인 결과다. 조건이 다양하므로 분포로 본다.
• LCP: 화면의 주요 내용이 보이기까지 걸린 시간을 나타내는 지표다.
• INP: 클릭이나 입력 뒤 화면이 반응하기까지의 지연을 나타내는 지표다.
• CLS: 읽거나 누르려던 화면이 갑자기 밀리는 정도를 나타내는 지표다.
• TTFB: 요청을 보낸 뒤 서버에서 첫 응답이 오기까지의 시간이다.
• 번들: 브라우저가 받아 실행하는 자바스크립트와 관련 파일 묶음이다.
• 성능 예산: 이 이상 느려지거나 커지지 않도록 프로젝트가 정한 한도다.

지표의 공식 기준값은 바뀔 수 있다. 합격·불합격 판단이 필요하면 측정 시점의 공식 문서와 프로젝트 기준을 확인한다.

먼저 지킬 원칙

• 기본은 읽기와 측정이다. 코드·설정·의존성·캐시를 바꾸거나 산출물을 삭제하지 않는다.
• 수정은 사용자가 요청했을 때만 수행한다.
• 프로젝트에 이미 설치된 명령과 도구를 우선한다. 점검을 위해 새 패키지나 전역 최신 도구를 몰래 설치하지 않는다.
• 같은 환경과 흐름을 비교한다. 서로 다른 기기·네트워크·캐시 상태의 숫자를 직접 비교하지 않는다.
• 한 번의 측정값보다 반복 결과와 변동 폭을 본다.
• 실험실 결과를 실제 사용자 전체의 결과라고 말하지 않는다.
• 정적 코드 패턴은 조사 단서일 뿐 느림의 증거가 아니다.
• 측정 전 개선율을 만들거나, 측정하지 못한 영역을 정상으로 추정하지 않는다.
• 운영 부하 테스트, 캐시 삭제, 외부 보고서 업로드는 비용·장애·정보 노출 위험이 있으므로 별도 승인 없이 실행하지 않는다.
• 주소의 검색어, 화면 내용, 토큰, 개인정보를 외부 분석 도구나 로그에 보내지 않는다.

1. 사용자가 느끼는 문제를 고른다

느린 화면 또는 동작:
사용자가 하는 행동:
예상한 결과:
느리다고 느끼는 시점:
영향받는 기기·브라우저·네트워크:
최근 변경:

전체 사이트를 한꺼번에 측정하지 않는다. 중요한 흐름이나 재현 가능한 증상부터 시작한다.

2. 맞는 측정 방식을 고른다

관련 없는 측정을 체크리스트처럼 전부 실행하지 않는다.

3. 비교 조건을 기록한다

측정 페이지와 사용자 흐름:
버전 또는 커밋:
브라우저와 기기 조건:
네트워크 조건:
로그인 상태:
캐시 상태:
데이터 상태:
측정 도구와 버전:
반복 횟수:

비교 기준은 다음 순서로 고른다.

1. 프로젝트가 정한 성능 예산이나 운영 목표
2. 같은 조건에서 측정한 이전 버전 또는 기준 브랜치
3. 측정 시점의 공식 권장 기준

비교 가능한 기준이 없으면 절대값과 조건만 기록하고 임의 점수로 통과를 선언하지 않는다.

4. 반복 측정한다

• 준비 실행과 실제 기록을 구분한다.
• 같은 조건으로 여러 번 측정한다.
• 대표값뿐 아니라 가장 빠른 값과 느린 값의 차이도 본다.
• 백그라운드 앱, 개발 서버의 추가 작업, 브라우저 확장처럼 결과를 흔드는 조건을 기록한다.
• 로그인 전후나 모바일·데스크톱처럼 경험이 다른 집단은 분리한다.

Lighthouse 같은 실험실 도구의 점수는 원인을 찾는 단서다. 실제 사용자 입력이 없는 결과를 실사용 INP라고 부르지 않는다. 실사용 데이터는 여러 사용자의 분포와 수집 조건을 확인한다.

5. 가장 큰 병목을 실제 위치까지 추적한다

측정값이 느린 이유를 요청, 파일, 컴포넌트, 쿼리까지 좁힌다.

로딩

• 주요 이미지가 지나치게 크거나 늦게 발견되는가
• 사용하지 않는 코드가 첫 화면에 함께 전달되는가
• 폰트나 스타일이 화면 표시를 오래 막는가
• 연속된 요청 때문에 다음 요청이 늦게 시작되는가

인터랙션

• 한 번의 클릭에서 긴 자바스크립트 작업이 실행되는가
• 같은 계산이나 렌더링이 불필요하게 반복되는가
• 화면에 보이지 않는 많은 요소를 동시에 처리하는가

서버와 데이터

• 서버 자체 처리인지 외부 API나 데이터베이스 대기인지 구분되는가
• 같은 데이터를 반복해서 가져오는가
• 느린 쿼리나 과도한 응답 크기가 실제 추적에서 확인되는가

use client, 인라인 함수, 특정 이미지 태그, 캐시 부재 같은 코드 모양만 보고 원인이라고 단정하지 않는다.

6. 가장 작은 수정 하나를 고른다

사용자가 수정을 요청한 경우에만 적용한다.

확인된 병목:
근거가 된 측정:
수정할 한 가지:
기능·화질·신선도·권한에 미치는 영향:
다시 측정할 조건:
되돌릴 기준:

캐시는 데이터 신선도와 사용자별 권한을 먼저 확인한다. 이미지 압축은 필요한 화질을 보존하고, 코드 분할은 실제 흐름에서 추가 요청이 더 느려지지 않는지 본다.

7. 같은 조건으로 재측정한다

• 수정 전과 같은 페이지, 동작, 환경을 사용한다.
• 기능이 그대로 작동하는지 확인한다.
• 목표 지표가 좋아졌는지 확인한다.
• 다른 지표나 사용자 경험이 나빠지지 않았는지 본다.
• 차이가 자연 변동보다 분명한지 판단한다.

전후 자료가 없으면 “개선됐다”고 말하지 않는다.

판정

• 회귀 확인: 비교 가능한 기준보다 악화했고 병목이 재현됐다.
• 개선 확인: 같은 조건에서 목표 지표가 좋아졌고 기능 회귀가 확인되지 않았다.
• 확인 범위에서 회귀 없음: 조사한 흐름과 환경에서는 악화 근거가 없다.
• 판단 불충분: 기준선, 실행 환경, 실사용 자료 또는 재현이 부족하다.

출력 형식

## 점검 대상
- 페이지·동작:
- 환경과 조건:
- 비교 기준:

## 측정 결과
| 항목 | 기준선 | 현재 | 변동 폭 | 해석 |
|---|---:|---:|---:|---|

## 확인된 병목
- 위치:
- 근거:
- 영향 범위:

## 수정한 경우
- 최소 변경:
- 전후 결과:
- 기능 확인:

## 미측정 영역
- 확인하지 못한 조건이나 사용자 집단:

## 판정
회귀 확인 / 개선 확인 / 확인 범위에서 회귀 없음 / 판단 불충분

초보자가 바로 쓸 요청 예시

모바일에서 첫 화면이 느려.
코드는 아직 바꾸지 말고, 같은 조건으로 측정해서
서버·이미지·자바스크립트 중 어디가 가장 큰 병목인지 찾아줘.

최근 변경 뒤 상품 목록 클릭이 느려졌어.
이전 버전과 현재 버전을 같은 조건에서 비교하고,
실제로 악화된 구간만 알려줘.

첫 화면의 큰 이미지가 병목인지 확인한 뒤 맞다면 최소한으로 고쳐줘.
수정 전후를 다시 측정하고 화질과 화면 기능도 함께 확인해줘.