느낌에 의존하지 않는 정량적인 튜닝

"컴퓨터 사양이 좋아서 잘 돌아간다" 혹은 "내 모바일에서는 부드럽지 않다"는 식의 주관적인 평가로는 웹 서비스 성능 이슈를 근본적으로 진단할 수 없습니다. 크롬 개발자 도구의 강력한 성능(Performance) 패널을 사용하면 데이터 교환, 렌더링 태스크, 레이아웃 계산 과정을 실시간 밀리초 단위 프로파일링을 통해 병목을 시각화할 수 있습니다.

1. Performance 탭을 이용한 녹화 분석

화면 스크롤이 끊기거나 페이지 전환 랙이 생기는 구간에서 녹화를 활성화한 뒤 동작을 수행해 봅니다. 타임라인 차트에 빨간색 삼각형 경고가 보인다면 Long Task(50ms 이상 점유하는 작업)가 발생한 것입니다. 해당 작업의 Call Stack 호출 내역을 파고들면 원인을 유발한 정확한 자바스크립트 코드 라인을 찾을 수 있습니다.

2. 메모리 릭(Memory Leak) 추적 기법

페이지를 탐색할수록 힙 메모리가 누적되어 기기가 멈추는 현상은 흔히 해제되지 않는 전역 이벤트 리스너나 클로저 상태 때문에 발생합니다. 개발자 도구의 Memory 탭에서 Heap Snapshot을 주기적으로 촬영해 소멸하지 않는 객체를 확인하여 메모리 해제 로직을 보완해야 합니다.

프로파일링 기록을 남기는 습관

성능 문제를 고칠 때는 “고친 것 같다”가 아니라 수정 전후 기록을 남기는 것이 중요합니다. Chrome DevTools의 Performance 녹화, Lighthouse 점수, 실제 기기 테스트 결과를 함께 기록하면 같은 문제가 반복될 때 빠르게 원인을 좁힐 수 있습니다.

분석 순서

  • 문제가 발생하는 사용자 행동을 하나로 좁히고 짧게 녹화합니다.
  • Main 스레드의 Long Task와 레이아웃 재계산 구간을 확인합니다.
  • 수정 후 같은 조건으로 다시 녹화해 작업 시간이 실제로 줄었는지 비교합니다.

프로파일링은 개발자의 감각을 대체하는 것이 아니라, 감각을 검증 가능한 데이터로 바꾸는 과정입니다.

Frontend Note 실무 노트

Chrome DevTools 성능 분석은 녹화 버튼을 누르는 것보다 시나리오를 좁히는 일이 먼저입니다. “사이트가 느리다”는 너무 넓습니다. “검색어 입력 후 카드 목록이 갱신될 때 1초 멈춘다”, “글 상세에서 첫 스크롤이 버벅인다”처럼 행동을 하나로 정해야 기록을 해석할 수 있습니다.

Performance 탭에서는 Main 스레드의 긴 작업, Recalculate Style, Layout, Paint 구간을 봅니다. Network 탭에서는 큰 이미지와 늦은 스크립트를 확인합니다. Coverage 탭은 첫 화면에 필요 없는 JavaScript와 CSS가 얼마나 로드되는지 보여줍니다. 세 탭을 같이 보면 병목이 다운로드인지 실행인지 렌더링인지 분리할 수 있습니다.

1. 문제 행동 하나를 정한다.
2. 5초 이내로 짧게 녹화한다.
3. Long Task와 Layout 구간을 표시한다.
4. 수정 후 같은 조건으로 다시 녹화한다.

분석 결과는 팀이 다시 볼 수 있게 남겨야 합니다. 스크린샷, 측정 조건, 수정 전후 수치를 PR에 첨부하면 성능 개선이 개인 감각이 아니라 재현 가능한 작업이 됩니다. 이 기록이 쌓이면 다음 장애에서도 원인을 더 빨리 찾을 수 있습니다.

기록을 해석하는 순서

Performance 탭에서 녹화 결과를 열면 많은 색상과 막대가 보여 처음에는 복잡해 보입니다. 먼저 가장 긴 노란색 스크립트 작업을 찾고, 그 작업이 사용자 입력 직후에 발생했는지 확인합니다. 다음으로 보라색 레이아웃 작업이 반복되는지 봅니다. DOM 크기나 스타일 계산이 문제라면 JavaScript를 줄여도 체감 개선이 작을 수 있습니다.

Network 탭에서는 파일 크기와 시작 시간을 봅니다. 큰 JavaScript가 늦게 도착하는지, 폰트가 렌더링을 막는지, 이미지가 너무 큰지 확인합니다. Coverage 탭에서는 첫 화면에 쓰이지 않는 코드가 얼마나 로드되는지 확인합니다. 이 세 가지를 같이 보면 “다운로드가 느린지, 실행이 느린지, 렌더링이 느린지”를 분리할 수 있습니다.

문제: 검색 결과 입력 후 700ms 멈춤
원인: input 이벤트마다 전체 목록 정렬
수정: 정렬 결과 memo 처리, 입력 디바운스 적용
검증: INP 310ms -> 160ms

PR에는 위처럼 문제, 원인, 수정, 검증 결과를 남기는 것이 좋습니다. 성능 개선은 시간이 지나면 왜 바꿨는지 잊히기 쉽습니다. 기록이 있으면 다음 리팩터링 때 같은 병목을 되살리지 않을 수 있습니다.

체크리스트

  • 같은 기기와 네트워크 조건에서 비교했는가?
  • 녹화 시간이 너무 길어 원인이 흐려지지 않았는가?
  • 수정 전후 스크린샷이나 수치를 PR에 남겼는가?
  • 성능 개선이 접근성이나 사용성을 해치지 않았는가?

참고 자료와 업데이트 기준

Frontend Note의 글은 실무 적용 관점에서 작성하며, 관련 기술의 공식 문서와 브라우저 지원 현황이 바뀌면 내용을 다시 점검합니다. 특히 프레임워크 버전, API 정책, 성능 측정 방식은 시간이 지나며 달라질 수 있으므로 적용 전에는 최신 문서를 함께 확인하는 것을 권장합니다.

  • MDN Web Docs에서 웹 표준과 브라우저 동작을 확인합니다.
  • web.dev에서 성능, 접근성, 사용자 경험 기준을 확인합니다.
  • React 공식 문서에서 React 관련 API와 권장 패턴을 확인합니다.

프로파일링 기록을 팀 자산으로 남기는 법

DevTools 프로파일링은 문제를 찾은 사람만 이해하고 끝나기 쉽습니다. 하지만 느린 화면은 다시 느려질 가능성이 높기 때문에 기록을 남겨야 합니다. 좋은 기록에는 측정한 URL, 브라우저 버전, 네트워크 조건, 재현 동작, 가장 오래 걸린 함수, 수정 전후 수치가 포함됩니다. 스크린샷 한 장보다 어떤 사용자 행동에서 병목이 나타났는지를 적는 것이 더 중요합니다. 예를 들어 검색어 입력 후 500개 항목 필터링에서 180ms Long Task 발생처럼 남기면 다음 개발자가 바로 재현할 수 있습니다.

성능 수정 후에는 숫자가 좋아졌는지뿐 아니라 기능이 그대로인지 확인해야 합니다. memo를 추가해 렌더링을 줄였지만 props 비교가 틀려 화면이 갱신되지 않는 경우도 있습니다. 이미지 지연 로딩을 넣었지만 첫 화면 핵심 이미지까지 늦게 뜨면 LCP가 나빠질 수 있습니다. DevTools는 원인을 찾는 도구이고, 최종 판단은 실제 사용자 흐름에서 해야 합니다. 그래서 Frontend Note의 성능 글은 기록, 수정, 재측정, 회귀 방지 순서로 읽히도록 구성합니다.

실무 적용 전 최종 점검

이 글의 내용을 프로젝트에 적용하기 전에는 현재 코드의 목적과 사용자 흐름을 먼저 확인해야 합니다. 같은 패턴이라도 관리자 화면, 공개 랜딩 화면, 입력이 많은 폼 화면에서는 우선순위가 다릅니다. 관리자 화면은 반복 작업 속도와 오류 복구가 중요하고, 공개 화면은 초기 로딩과 접근성이 중요하며, 폼 화면은 검증 메시지와 상태 보존이 중요합니다. 따라서 예제 코드를 그대로 붙이기보다 어떤 파일에서 책임을 나눌지, 어떤 값이 외부 입력인지, 실패했을 때 사용자가 무엇을 보게 되는지를 함께 검토하는 것이 좋습니다.

작업 후에는 변경 전후를 비교할 수 있는 작은 기록을 남깁니다. 수정한 컴포넌트, 확인한 브라우저, 실패 케이스, 되돌리는 방법을 적어 두면 다음 배포에서 같은 문제를 빨리 찾을 수 있습니다. 특히 React와 TypeScript 코드는 타입 오류가 사라져도 런타임 흐름이 틀릴 수 있고, CSS 수정은 특정 화면 폭에서만 깨질 수 있습니다. 그래서 로컬 확인, 빌드 확인, 실제 화면 확인을 분리해 진행하는 습관이 필요합니다. Frontend Note의 예시는 이 과정을 돕기 위한 출발점이며, 팀의 코드 스타일과 배포 방식에 맞게 작게 조정해서 사용하는 편이 안전합니다.

작게 적용하는 연습 방법

처음 적용할 때는 전체 화면을 한 번에 바꾸지 말고 작은 컴포넌트 하나를 골라 실험하는 편이 좋습니다. 변경 범위를 좁히면 원인을 추적하기 쉽고, 기존 사용자 흐름에 주는 영향도 줄일 수 있습니다. 예제 코드를 적용한 뒤에는 정상 케이스뿐 아니라 빈 데이터, 긴 텍스트, 느린 네트워크, 모바일 화면을 함께 확인합니다. 이런 조건에서 문제가 없다면 같은 패턴을 다른 화면으로 확장해도 유지보수 부담이 적습니다.