브라우저 렌더링 속도가 간헐적으로 느렸던 이유
문제 상황
프로젝트에 도면목록 탭이 있다.
사용자가 업로드한 도면을 목록에서 보고, 클릭하면 상세 모달에서 결함 마커를 생성/수정할 수 있는 구조다.
원래는 마커 위치를 수정한 뒤 저장 버튼으로 일괄 저장했는데, UX와 레거시 동작을 맞추기 위해 위치 자동 저장으로 변경했다.
그 이후부터 도면목록 탭에서 화면이 간헐적으로 무거워지는 느낌이 생겼다.
처음 가설
처음에는 아래를 의심했다.
- 자동 저장으로 인한 API 중복 호출
- 드래그 이벤트 증가로 인한 렌더 병목
- 모달 진입 시점의 불필요한 리렌더
즉, "우리 코드가 느려졌다"가 첫 가설이었다.
실제로 측정한 값
체감만으로 판단하지 않기 위해 Chrome Performance와 React DevTools Profiler로 측정했다.
- LCP: 1.07s (Core Web Vitals 기준 good 범위)
- 도면 목록 조회 API: 13ms
- 모달 클릭 후 렌더 duration: 19.3ms
숫자만 보면 "데이터를 불러와 리스트를 띄우는 과정" 자체는 병목이 아니었다.
반전 포인트
테스트 중 이상한 패턴을 발견했다.
Network 탭이 열려 있을 때만 렉이 발생했다.
탭을 닫으면 같은 동작에서도 체감이 훨씬 가벼웠다.
원인은 앱 코드가 아니라, DevTools가 관찰/기록을 수행하면서 생기는 오버헤드였다.
왜 Network 탭에서 느려졌나
Network 탭이 열려 있으면 브라우저는 앱 실행 외에도 아래 작업을 지속한다.
- 요청/응답 패킷 기록
- 헤더 파싱
- waterfall 타임라인 계산/렌더링
- 리소스 단위 메타데이터 갱신
모달 진입 시 큰 이미지나 여러 리소스가 함께 로드되면, 이 기록 작업이 CPU/메모리를 추가로 사용한다.
결과적으로 앱 렌더가 느린 것처럼 보이는 "관찰자 효과(Observer Effect)"가 발생한다.
반대로 Profiler 중심으로 볼 때는 패킷 로깅 부하가 상대적으로 적어 체감 렉이 줄어든다.
실무에서 언제 등장하는가
이 문제는 보통 아래 상황에서 자주 나온다.
- 이미지/캔버스/도면처럼 리소스가 큰 화면
- 모달 진입 시 네트워크 요청이 여러 개 동시에 발생하는 화면
- 드래그/스크롤 등 고빈도 UI 이벤트가 있는 화면
즉, "화면이 느리다"는 증상이 보여도, 항상 앱 로직부터 범인이라고 단정하면 오진하기 쉽다.
이번 경험에서 정리한 기준
- 체감 성능 이슈는 먼저 도구 오버헤드 여부를 분리해서 본다.
- DevTools 탭 상태(열림/닫힘)별로 같은 시나리오를 재현한다.
- 지표(LCP, API, render duration)와 체감을 분리해 해석한다.
핵심은 "느린 화면"이 아니라 "무엇이 느려 보이게 만들었는지"를 구분하는 것이다.
정리
이번 케이스의 결론은 단순하다.
- 틀린 가설: 자동 저장 코드가 직접 렌더 병목을 만든다
- 실제 원인: DevTools Network 탭 관찰 오버헤드
- 얻은 교훈: 성능 분석에서 측정 도구 자체가 결과를 왜곡할 수 있다
앞으로 비슷한 증상을 보면, 최적화 코드부터 들어가기 전에 "관찰 환경"부터 먼저 확인할 것이다.