RUM이란? 실제 사용자가 경험한 홈페이지 속도를 측정하는 방법 쉽게 이해하기

개발 PC는 빠른데 사용자는 느릴 수 있습니다

자동 테스트도 통과했는데 「모바일만 느려요」「집에서는 늦게 떠요」「특정 나라에서만」 같은 말이 나옵니다. 방문자는 기기·브라우저·인터넷·지역·화면 크기·통신망이 모두 다릅니다. RUM(Real User Monitoring)은 그 실제 환경에서 로딩·반응·화면 안정성 같은 성능 데이터를 모으는 방식입니다. 비유하면 직원이 빈 식당에서 주문 테스트하는 것과, 점심시간 손님의 대기 시간을 조사하는 것의 차이입니다.

합성 모니터링과 무엇이 다른가

합성 모니터링은 서울·Chrome·고정 네트워크처럼 정해진 조건의 가상 사용자가 로그인 등을 반복합니다. RUM은 부산 Safari 아이폰, 일본 모바일망 Android처럼 실제 방문자의 다양성을 봅니다. 합성 = 검사원 반복 시험, RUM = 실제 고객 경험 — 어느 쪽이 무조건 우월하지 않고 목적이 다릅니다. 업타임은 「열렸는가」, RUM은 「연 사람이 얼마나 빨리 썼는가」에 가깝습니다.

Synthetic → 고정 환경 반복 검사
RUM       → 실제 기기·망·지역 현장 데이터
Lab(Lighthouse) → 실험실 조건 비교
Field(RUM)      → 도로 위 운전자 경험

어떻게 모으고 무엇을 보는가

페이지에 측정 코드가 있으면 방문자가 별도 버튼을 누를 필요 없이, 접속·스크롤·클릭·이동 과정에서 브라우저가 성능을 보내고 RUM 시스템이 집계합니다. 로딩·주요 콘텐츠 표시·입력 반응·레이아웃 흔들림, 페이지·기기·브라우저·국가별 비교가 대표적입니다. 「평균 2초」만보다 분포가 중요합니다. 90명은 1초, 10명은 8초면 평균은 괜찮아 보여도 일부는 매우 나쁩니다. 그래서 p75 같은 백분위수를 함께 봅니다.

Core Web Vitals · LCP · INP · CLS

RUM으로 현장의 Core Web Vitals를 모을 수 있습니다. LCP는 큰 주요 콘텐츠가 화면에 뜨기까지 — 히어로 이미지·제목 등이 늦게 뜨면 나쁩니다(큰 이미지·느린 서버·CSS/JS·폰트·망). INP는 클릭·입력 후 화면이 반응하기까지 — 첫 화면은 빠른데 메뉴만 2초 멈출 수 있고, 무거운 JS가 원인일 수 있습니다. CLS는 읽다 이미지가 늦게 들어와 제목이 밀리는 것처럼 레이아웃이 덜컥 움직이는 정도 — 이미지 크기·비율을 미리 두면 도움이 됩니다. CWV만으로 서버 오류·결제·검색·외부 API 전부를 설명하진 않습니다.

기기·지역·페이지 · CDN·Trace와의 연결

데스크톱 1.3초·모바일 3.9초면 큰 JS·이미지·이동통신을 의심합니다. Safari만 느린 페이지, 한국은 빠르고 유럽만 느린 패턴도 현장 데이터에서 드러납니다. RUM은 측정이고, 해외 정적 파일이 느리면 CDN이 개선 후보입니다. 「상품 상세만 느림」을 찾은 뒤 분산 추적으로 추천 API 2초를 파면 「사용자가 느낀 문제 → 서버 원인」이 이어집니다. 서버 HTML은 빠른데 화면만 느리면 프론트 쪽을 봅니다. 서버 CPU가 낮아도 사용자 경험은 나쁠 수 있습니다.

방문량 · Lab · 개인정보 · 부하

방문이 거의 없으면 기기·지역 비교가 어렵고, 신규 사이트는 초기에 데이터가 없습니다 — 출시 전엔 Lab·자동화·합성을 쓰고, 운영 후 RUM을 보태면 됩니다. Lighthouse류 Lab은 수정 전후 같은 조건 비교에 좋고, RUM은 현실 다양성에 좋습니다. 비밀번호·토큰·카드·URL의 이메일은 수집하지 말고 마스킹합니다. RUM 스크립트·전송이 본 서비스를 무겁게 만들지 않게 하고, RUM 서버 장애 시에도 홈페이지는 동작해야 합니다. 대량 트래픽은 샘플링·보관 기간·필요 지표만으로 비용을 조절합니다. JS 오류는 에러 트래킹이 더 전문적일 수 있고, 제품에 함께 들어가기도 합니다.

배포 · SEO · 한계

배포 전후 p75·모바일 비율을 비교하고 Release와 묶으면 회귀를 찾기 쉽습니다. Canary에 성능을 넣을 수 있으나 RUM은 방문이 쌓여야 하므로 즉각 판단에는 다른 지표도 함께 씁니다. SEO 전용 도구는 아니고, 설치만으로 빨라지지 않으며 개선 작업이 필요합니다. 검색엔진 현장 데이터와 숫자가 달라도 수집 방식·기간이 다를 수 있습니다. 한계는 실제 사용자가 있어야 하고, 이미 경험한 뒤 데이터가 온다는 점 — 사용자보다 먼저 잡으려면 합성이 유리합니다. 합성으로 「지금 정상인가」, RUM으로 「실제 경험은 좋은가」에 답합니다.

자주 묻는 질문

정리

RUM은 실제 사용자가 실제 기기와 네트워크에서 경험한 성능을 측정하는 방법입니다. 개발 PC·자동 테스트는 빠른데 모바일만 느린 현실을 드러냅니다. 서버가 요청을 받고 첫 바이트를 보내기까지의 시간은 TTFB 가이드에서 이어서 볼 수 있습니다 — 느림이 브라우저 화면 이전의 서버 응답부터인지 볼 때 유용합니다.