웹 앱이 느려졌을 때 성능 디버깅하는 법

웹 애플리케이션의 성능 저하는 여러 원인이 겹칠 수 있다. 번들 크기 증가, 렌더링 최적화 누락, 외부 리소스 로드 지연, 부정확한 설정. 사용자는 "느리다"고만 보고하지만, 개발자는 정확히 어느 부분이 느린지 찾아야 한다.

문제의 경계 정하기

언제부터 느려졌는지, 어떤 페이지에서만 느린지, 특정 작업 후에만 느린지 파악한다. 각각의 원인이 다르다.

로컬과 운영 환경 비교

로컬 개발 서버와 운영 배포 사이에는 큰 차이가 있다. 로컬은 개발 모드로 실행되고, 운영은 최적화된 프로덕션 빌드다.

• 확인할 것: 빌드 설정, 번들 크기, 캐시 정책
• 비교 기준: 이전에 정상이던 성능
• 기록할 것: 로드 시간, 렌더링 프레임, CPU 사용률

빌드 검증

빌드 과정에서 최적화가 제대로 이루어지는지 확인한다.

npm run build
# 빌드 크기, 청크 수, 최적화 결과 확인

응답 확인

API 응답 시간, 브라우저 캐시 동작, 네트워크 지연을 확인한다. 정상적인 응답이 느린 것인지, 예상 밖의 크기 응답이 오는 것인지 구분해야 한다.

# Chrome DevTools Network 탭에서 각 리소스의 로드 시간 확인
# 또는 curl로 응답 시간 측정
curl -w '@curl-format.txt' -o /dev/null -s https://example.com

사용자 영향 확인

성능 개선은 실제 사용자가 느끼는 속도를 기준으로 진행해야 한다. 로컬에서의 개선이 운영에서도 효과가 있는지 확인한다.

위험한 최적화 피하기

성능을 높인다고 무분별하게 캐시 정책을 강화하거나 기능을 제거하면 안 된다. 각 변경의 부작용을 함께 확인한다.

완료 기준

1. 느린 부분을 구체적인 수치로 설명할 수 있는가
2. 로컬과 운영의 성능 차이를 이해할 수 있는가
3. 개선 전후를 비교했을 때 실제로 나아졌는가

성능은 측정이 가능할 때만 개선이 검증된다. 추측이 아닌 구체적인 수치를 기반으로 진행하는 것이 중요하다.