Google Lighthouse 완전 가이드: 점수 해석, 한계, 올바른 활용법

Google Lighthouse란 무엇이며, 실제로 무엇을 위한 도구인가?

Google Lighthouse는 Google이 개발한 오픈소스 감사 도구로, 2017년부터 Chrome DevTools에 기본 내장되어 있습니다. 작동 방식은 다음과 같습니다. 통제된 환경에서 페이지를 로드하고, 일련의 기술 지표를 측정한 뒤, 점수와 실행 가능한 권장 사항이 포함된 구조화된 보고서를 생성합니다.

Lighthouse는 최대 5개 카테고리를 감사합니다. Performance, 접근성, SEO, Best Practices, 그리고 PWA — 마지막 항목은 Lighthouse 12(2024년 5월)에서 제거되었습니다. 각 카테고리는 0에서 100 사이의 점수를 제공합니다.

Lighthouse가 하지 않는 것: 실제 사용자의 경험을 측정하는 것입니다. 모든 Lighthouse 보고서는 lab data입니다. 가상 머신에서 에뮬레이션된 기기와 시뮬레이션된 연결을 사용하는 표준화된 조건에서 생성된 합성 데이터입니다. 이것이 다른 모든 내용보다 먼저 내면화해야 할 근본적인 한계입니다.

Lab data vs field data: 모든 것을 바꾸는 구분

Lighthouse = 표준화된 조건에서의 진단. CrUX = 실제 사용자 현실.

PageSpeed Insights는 두 가지를 결합합니다. 페이지 상단은 CrUX field data(출처에 충분한 트래픽이 있을 경우 제공)를 표시하고, 하단은 Lighthouse lab 보고서를 포함합니다. 이 두 섹션을 혼동하는 것이 performance 점수에 대한 오해의 대부분을 차지합니다.

Lighthouse 감사 실행 방법

상황과 재현성 요구 수준에 따라 세 가지 방법이 있습니다.

Chrome DevTools

1. Chrome에서 대상 페이지 열기
2. F12 → Lighthouse 탭
3. 카테고리와 프로필(Mobile 또는 Desktop) 선택
4. 페이지 로드 분석 클릭

재현 가능한 실행을 위해: 시크릿 창을 열고 모든 Chrome 확장 프로그램을 비활성화하십시오. 광고 차단기나 비밀번호 관리자가 페이지 동작을 변경하여 결과를 왜곡할 수 있습니다.

PageSpeed Insights

PageSpeed Insights는 별도 설치가 필요 없습니다. URL을 입력하면 30초 내에 Lighthouse lab 보고서와 CrUX field data가 포함된 보고서를 얻을 수 있습니다. 첫 번째 검토를 위한 가장 빠른 방법이며, 두 출처를 나란히 보여주는 유일한 도구입니다.

Node.js CLI

CI/CD 감사나 인증이 필요한 페이지의 경우:

npm install -g lighthouse

# 표준 감사, 모바일 프로필, HTML 보고서
lighthouse https://example.com \
  --output html \
  --output-path ./report.html \
  --throttling-method=simulate \
  --emulated-form-factor=mobile

# 인증 필요 페이지 (세션 쿠키 예시)
lighthouse https://example.com/dashboard \
  --extra-headers '{"Cookie": "session=abc123"}' \
  --output json

--budget-path 옵션을 사용하면 performance 임계값을 초과할 경우 CI 빌드를 실패시킬 수 있어, 배포마다 성능 저하를 방지하는 데 유용합니다.

변동성: 연속 실행 결과가 다른 이유

동일한 감사를 두 번 연속 실행하면 Performance 점수가 10–15점 다를 수 있습니다. 세 가지 원인이 있습니다.

• CPU jitter: 가상 머신이 실행 시 다른 프로세스와 리소스를 공유함
• 연결 상태: 시뮬레이션된 throttling에서도 리소스는 실제 로컬 네트워크를 통해 서버까지 전달됨
• 네트워크 캐싱: 첫 번째 실행에서 CDN 연결이 시작되어 두 번째 실행 시 이미 연결된 상태일 수 있음

실용적인 규칙: 단일 실행으로 결론을 내리지 마십시오. 최소 3회 연속 실행하여 중앙값을 사용하십시오.

5개 점수 카테고리 해석

각 Lighthouse 감사는 최대 5개의 별도 점수를 생성합니다. Performance 점수만이 수치 복합 지표입니다. 나머지 4개는 가중치가 적용된 이진(pass/fail) 감사를 집계합니다.

Performance 점수 상세

점수는 단순 평균이 아닙니다. 각 지표에 가중치가 적용되고, 극단값을 압축하기 위해 로그 곡선으로 변환됩니다. 현재 가중치(Lighthouse 12 기준):

LCP + TBT = 점수의 55%. 이 두 지표를 개선하면 가장 큰 변화가 생깁니다. INP는 lab 점수 계산에 포함되지 않습니다. INP는 실제 사용자 인터랙션이 필요한 field-only Core Web Vital입니다.

색상 구간은 세 가지 임계값을 따릅니다. 초록색(90–100), 주황색(50–89), 빨간색(0–49).

접근성: 자동화된 감사의 한계

접근성 점수 100점은 사이트가 완전히 접근 가능하다는 의미가 아닙니다. 자동화 도구는 WCAG 문제의 약 30–40%만 감지합니다. 나머지, 즉 논리적 포커스 순서, 의미론적으로 비어있는 대체 텍스트, 복잡한 컴포넌트의 키보드 내비게이션 등은 스크린 리더를 사용한 수동 테스트가 필요합니다.

SEO: 시작점이지, 감사가 아님

Lighthouse의 SEO 점수는 기초 항목을 다룹니다. <title> 태그와 meta description 존재 여부, 이미지의 alt 속성, 크롤 가능한 링크, 유효한 robots.txt. 콘텐츠 품질, 링크 프로필, field Core Web Vitals, 크롤 구조에 대해서는 아무것도 알려주지 않습니다. 심각한 오류를 감지하는 데 유용한 신호일 뿐, 그 이상은 아닙니다.

중요한 performance 지표: LCP, INP, CLS, TBT, FCP, Speed Index

⏱️ ↓

0 ms

TTFB

🖼️ ↓

0 s

LCP

📐 ↓

0

CLS

🎯 ↑

0 /100

Score

6개 지표가 Performance 점수를 구성합니다. 세 개는 공식 Core Web Vitals(LCP, INP, CLS)로 Google의 랭킹 신호로 사용됩니다.

전체 정의, 측정 메커니즘, 개선 전략은 Lighthouse가 측정하는 Core Web Vitals 페이지를 참조하십시오.

LCP — 뷰포트에서 가장 큰 요소(히어로 이미지, 텍스트 블록, poster가 있는 동영상)가 표시되는 시간입니다. CDN 품질, 이미지 최적화, render-blocking 리소스에 가장 큰 영향을 받는 지표입니다.

INP — 사용자 인터랙션(클릭, 키보드 입력)에 대한 반응성입니다. 2024년 3월 FID를 대체하여 Core Web Vital이 되었습니다. field에서만 측정 가능하며, lab에서는 Lighthouse가 TBT를 근사치로 사용합니다.

CLS — 시각적 안정성: 예기치 않은 레이아웃 이동을 누적합니다. 크기가 선언되지 않은 이미지, font-display가 없는 웹폰트, 늦은 DOM 주입(쿠키 배너, 서드파티 위젯)으로 인해 발생합니다.

TBT — FCP와 TTI 사이에서 메인 스레드가 50ms 이상 차단된 총 시간입니다. INP의 불완전한 proxy입니다. TBT가 낮은 페이지도 로드 후 무거운 JavaScript handler가 트리거되면 INP가 높을 수 있습니다.

Lighthouse의 한계: 점수가 말해주지 않는 것

대부분의 가이드가 무시하는 섹션입니다. 이를 이해하는 것이 Lighthouse의 초보적 활용과 전문적 활용을 구분합니다.

Throttling 프로필이 실제 사용자층과 다름

기본적으로 Lighthouse 모바일은 호스트 머신보다 CPU가 4배 느린 Moto G4와 Slow 4G 연결(1.6 Mbps, 150ms 지연)을 시뮬레이션합니다. 이 프로필은 전 세계 하위 기기 스펙트럼을 나타내도록 설계되었습니다. 개발자가 모든 사용자를 위해 최적화하도록 유도하기 위함입니다.

하지만 실제 사용자층이 최신 기기와 빠른 연결을 사용한다면, 이 프로필은 체계적으로 비관적입니다. 점수는 실제 사용자 경험보다 기계적으로 낮게 나타나며, 실제로는 사용자 경험을 개선하지 않는 최적화에 우선순위를 둘 위험이 있습니다.

실행은 항상 cold cache 상태

Lighthouse는 브라우저 캐시 없이 페이지를 로드합니다. 실제 재방문 사용자는 부분적으로 warm 캐시, 이미 연결된 CDN, 메모리에 있는 리소스를 가지고 있습니다. Lighthouse가 측정하는 첫 번째 로드는 최악의 경우입니다. 성능 저하 신호로는 적합하지만, 평균적인 사용자 경험의 척도로는 오해의 소지가 있습니다.

Lab에서 빨간 점수, field에서 초록 Core Web Vitals

그 차이는 극적일 수 있습니다.

◆Retour terrain·8 ans · 35+ clients

현장 경험 — Lighthouse 점수 < 50, CHANEL에서 검증된 Core Web Vitals.

저는 4년간 CHANEL의 웹 퍼포먼스를 지원했습니다. chanel.com의 모바일 Lighthouse 점수는 빨간색이었습니다. PSI 조건에서 FCP 5.9s, LCP 14.6s, Speed Index 7.2s. 사전 지식이 없는 클라이언트라면 "느린 사이트, 즉시 수정 필요"로 읽을 보고서였습니다. 실제 field 현실은 정반대였습니다. CrUX 데이터에서 LCP 1.7s, INP 177ms, CLS 0. Core Web Vitals 전반에서 합격 — 럭셔리 업계 최고의 웹 퍼포먼스 점수 중 하나였습니다. 이유는 다음과 같습니다. PSI는 Slow 4G 환경에서 구식 Moto G4를 에뮬레이션하는데, 이는 CHANEL의 실제 사용자층(프리미엄 기기와 빠른 연결 사용)과는 전혀 무관한 프로필입니다. 실제 기기에서는 edge CDN이 몇 밀리초 내에 에셋을 제공하고, 4년간 배포된 최적화(현대적 이미지 포맷, INP 최적화)가 중요한 곳에서 결과를 만들어냅니다. 교훈: Lighthouse의 throttling 프로필은 전 세계 하위 스펙트럼을 위해 보정되어 있습니다. 사용자층이 프리미엄 기기를 사용한다면, lab 점수는 항상 실제 field 결과보다 낮게 나타납니다. 결론을 내리기 전에 항상 CrUX와 교차 확인하십시오.

TTI 사례: 작동하지 않아서 지표를 제거한 경우

Lighthouse 9까지는 Performance 점수에 **Time To Interactive (TTI)**가 포함되었습니다. "페이지가 인터랙티브해지는 시점"을 측정한다고 하는 지표였습니다. 점수의 10%를 차지했습니다. Lighthouse 10(2023년 2월)에서 TBT로 교체되며 제거되었습니다. 이유는? TTI가 근본적으로 불안정하고 실제 사용자 경험과 상관관계가 낮았기 때문입니다.

근본적인 문제: TTI는 Long Task(50ms를 초과하는 JS 작업)가 없는 5초 창과 최대 2개의 병렬 다운로드 리소스를 기다립니다. 실제로 51ms짜리 단일 작업이 카운터를 초기화했습니다. 이러한 극단적인 임계값 효과로 인해 서드파티 JavaScript의 사소한 변동에도 매우 민감했습니다. analytics, 위젯, A/B test가 포함된 실제 사이트에서 TTI는 연속 실행 간에 크게 변동했습니다.

Boris Schapira가 지표 분석에서 요약했듯이: TTI는 "페이지가 인터랙티브해지기 전 시간"을 측정하는 것이 아닙니다. 특정 시점부터 더 이상 jank가 없다는 보장입니다. "Time To Interactive"를 액면 그대로 읽는 사람에게는 중요하고 반직관적인 차이입니다.

이는 Lighthouse의 지표가 시간이 지남에 따라 발전하고, 현재 지표도 최종적이지 않다는 구체적인 예시입니다. TTI를 대체한 TBT도 field INP의 불완전한 proxy입니다. 로드 시 메인 스레드 압박을 측정하지만, 실제 인터랙션에 대한 반응성은 측정하지 않습니다.

Lighthouse가 전혀 포착하지 못하는 것

• 실제 INP: 인터랙션에는 실제 사용자가 필요합니다. 로드 후 무거운 JS handler가 트리거될 경우 TBT는 INP를 안정적으로 예측하지 못합니다.
• 지리적 성능: 로컬 머신에서의 단일 실행입니다. WebPageTest를 사용하면 파리, 뭄바이, 상파울루에서 테스트할 수 있습니다. CDN이 제대로 설정되지 않은 사이트에서는 LCP 차이가 정기적으로 3초를 초과합니다.
• 멀티 페이지 성능: Lighthouse는 한 번에 하나의 URL을 감사합니다. 내부 내비게이션(SPA 전환, prefetch, Service Worker)은 포착되지 않습니다.
• 실제 페이지 상태: 활성 A/B test, 개인화, 장바구니 내용, 푸시 알림 등은 합성 실행에서 재현되지 않습니다.

언제 어떤 도구를 사용할 것인가

PSI와 WebPageTest의 사용 사례별 선택 방법은 WebPageTest vs PageSpeed Insights 비교를 참조하십시오. 전문적인 웹 퍼포먼스 감사를 위해 Lighthouse는 출발점이지만, 유일한 도구는 아닙니다.

FAQ

참고 자료

• Lighthouse — 공식 GitHub 저장소
• Lighthouse 문서 — Chrome Developers
• PageSpeed Insights
• Web.dev — Core Web Vitals 및 웹 지표
• Chrome UX Report (CrUX) — 문서
• Measuring Interactivity with TTI — Boris Schapira