Lighthouse vs RUM: 성능을 어떻게 제대로 측정하나요?

Question

IT Interview Practice · Accepted Answer

랩(lab)과 필드(field) 데이터 **둘 다**로 측정하세요 — 이들은 서로 다른 질문에 답합니다. **Lighthouse**는 랩(합성적이고 재현 가능, 디버깅용)이고, **RUM**은 필드(실제 사용자, 진실용)입니다. 하나만 신뢰하면 엉뚱한 것을 최적화하게 됩니다.

## 랩 vs 필드

| | 랩 (Lighthouse) | 필드 / RUM |
|--|------------------|-------------|
| 출처 | 고정된 기기/네트워크의 합성 실행 1회 | 실제 방문, 모든 기기/네트워크 |
| 적합 용도 | 디버깅, CI 회귀 게이트, 반복 가능 | 사용자가 *실제로* 경험하는 것 |
| INP | 측정 불가 (실제 상호작용 없음) | 방문 전반에 걸쳐 측정 |
| 약점 | 실제 트래픽을 반영하지 못함 | 노이즈 많음, 볼륨 필요, 디버깅 어려움 |

Lighthouse는 깨끗한 머신에서 스로틀링된 로드 1회를 실행합니다 — 문제 *재현*에는 훌륭하지만 p75를 아는 데는 쓸모없습니다. **특히 INP**는 세션에 걸친 실제 상호작용이 필요하므로 필드에서만 포착할 수 있습니다.

## web-vitals 라이브러리로 필드 데이터 수집

```js
import { onLCP, onCLS, onINP } from "web-vitals";

function send(metric) {
  // Attribution 빌드는 어떤 요소/상호작용이 원인인지 알려줌
  navigator.sendBeacon("/rum", JSON.stringify({
    name: metric.name, value: metric.value, id: metric.id,
  }));
}
onLCP(send); onCLS(send); onINP(send); // 각 지표가 확정될 때 보고
```

이것은 검색 순위를 좌우하는 Google의 **CrUX**(Chrome User Experience Report)와 동일한 방법론입니다 — CrUX는 랩이 아니라 실제 사용자 p75입니다.

## 둘을 함께 쓰는 법

- **RUM**으로 실제 회귀를 감지하고 p75(순위가 쓰는 값)를 파악.
- **CI의 Lighthouse**를 배포 *전에* 회귀를 잡는 가드레일로 사용.
- RUM을 기기/국가/연결별로 세분화 — 평균값은 저사양 안드로이드가 느린 꼬리라는 사실을 숨깁니다.

## 왜 중요한가

시니어의 신호는 랩 ≠ 필드임을, 순위가 필드 p75를 쓴다는 것을, INP가 필드에서만 실제라는 것을 아는 것입니다. 실제 p75가 나쁜데 Lighthouse 점수만 최적화하는 것은 이 질문이 드러내려는 고전적 함정입니다.

출처	고정된 기기/네트워크의 합성 실행 1회	실제 방문, 모든 기기/네트워크
적합 용도	디버깅, CI 회귀 게이트, 반복 가능	사용자가 실제로 경험하는 것
INP	측정 불가 (실제 상호작용 없음)	방문 전반에 걸쳐 측정
약점	실제 트래픽을 반영하지 못함	노이즈 많음, 볼륨 필요, 디버깅 어려움

랩 vs 필드

web-vitals 라이브러리로 필드 데이터 수집

둘을 함께 쓰는 법

왜 중요한가

관련 질문