Lighthouse 성능 자동화
7가지 지표를 정량적으로 측정하는 방법
웹 성능을 평가할 수 있는 도구는 다양하지만, 그중에서도 Google에서 제공하는 Lighthouse는 신뢰성과 객관성 면에서 가장 널리 인정받는 도구 중 하나입니다. Lighthouse는 페이지의 성능을 단순히 점수로만 평가하는 것이 아니라, 사용자가 실제로 체감하는 로딩 속도, 반응성, 안정성과 같은 요소들을 다양한 수치로 시각화해줍니다. 이러한 특성은 특히 품질을 중요하게 생각하는 QA 엔지니어에게 유용하게 작용합니다.
하지만 단 한 번의 측정만으로 성능을 판단하는 것은 위험할 수 있습니다. 네트워크 환경, 브라우저 상태, 백엔드 응답 시간 등 외부 변수에 따라 결과는 달라질 수 있습니다. 그렇기 때문에 반복적인 측정을 통해 평균값을 확보하고, 성능 변화의 흐름을 수치로 분석하는 방식이 훨씬 더 신뢰할 수 있습니다. 성능 테스트에서 중요한 것은 ‘느린 것 같다’는 감각이 아니라, ‘수치상으로 느려졌다’는 명확한 데이터입니다.
이러한 배경에서 저는 Lighthouse를 Python으로 자동화하여, 정해진 횟수만큼 반복 측정을 수행하고 각 회차의 결과를 로그 파일로 저장하는 구조를 만들었습니다.
물론 Lighthouse는 크롬 브라우저의 개발자 도구에서도 쉽게 사용할 수 있습니다. 브라우저를 열고 DevTools 패널에서 Lighthouse 탭을 선택하면, 단일 페이지에 대한 성능 리포트를 바로 생성할 수 있습니다. 이 방법은 빠르고 접근성도 좋지만, 반복 측정이나 결과 비교, 기준값 기반의 해석에는 한계가 있습니다. 단 한 번의 실행으로 나오는 결과는 일시적인 상황에 따라 달라질 수 있고, 측정값을 누적하거나 자동으로 기록하는 기능도 제공하지 않기 때문입니다.
반면, 코드로 Lighthouse를 자동화하면 원하는 횟수만큼 반복 측정을 수행하고, 결과를 파일로 저장하며, 각 수치가 기준상 어떤 수준인지 자동으로 해석할 수 있습니다. 로그를 기반으로 시간에 따른 성능 변화를 추적하거나, 릴리즈 전후의 품질 비교를 체계적으로 수행할 수 있다는 점에서 큰 장점이 있습니다. 자동화는 단순히 실행을 반복하는 것이 아니라, 데이터를 쌓고 해석할 수 있게 만든다는 점에서 QA 엔지니어에게 특히 중요한 방식이라 할 수 있습니다.
테스트에 사용한 페이지는 lighthouse_test.html이라는 정적 HTML 파일로, 측정 대상의 구조를 제어할 수 있도록 직접 제작했습니다. 실서비스 페이지의 경우 대부분 성능이 이미 최적화되어 있어 특정 지표가 과도하게 낮게 나오거나, 실험에 필요한 수치 변화가 관찰되지 않는 경우가 있기 때문입니다.
해당 테스트 페이지의 구성 방식이나 실험 구조는 다음 글에서 더 자세히 다룰 예정입니다. 이번 글에서는 Lighthouse를 통해 어떤 항목을 측정할 수 있는지, 그리고 각 항목이 의미하는 바가 무엇인지에 집중하고자 합니다.
Lighthouse로 측정 가능한 7가지 주요 성능 지표
Lighthouse는 페이지 로딩과 관련된 다양한 단계를 지표화하여 수치로 보여줍니다. Google은 이 지표들에 대해 ‘빠름’, ‘보통’, ‘느림’의 기준값을 함께 제시하고 있으며, 이를 통해 사용자 경험의 질을 정량적으로 평가할 수 있습니다.
• TTFB (Time to First Byte): 브라우저가 서버로부터 첫 번째 바이트를 받기까지 걸리는 시간으로, 서버 응답 속도를 나타냅니다. 0.2초 미만이면 빠른 편입니다.
• FCP (First Contentful Paint): 사용자가 페이지에서 처음으로 무언가를 시각적으로 인식할 수 있는 시점입니다. 1.8초 이하면 이상적입니다.
• LCP (Largest Contentful Paint): 페이지 내 가장 큰 콘텐츠(예: 이미지, 타이틀 등)가 표시되는 시점으로, 주 콘텐츠의 렌더링 완료 시점을 나타냅니다. 2.5초 이하면 좋은 성능으로 평가됩니다.
• CLS (Cumulative Layout Shift): 페이지 로딩 중 예기치 않은 레이아웃 변경의 누적 정도를 측정하는 지표입니다. 값이 낮을수록 시각적으로 안정적인 페이지로 간주됩니다.
• TTI (Time to Interactive): 페이지가 완전히 상호작용 가능한 상태가 되는 시점입니다. 사용자의 클릭이나 입력에 즉시 반응할 수 있어야 하며, 3.8초 이하가 권장됩니다.
• TBT (Total Blocking Time): 콘텐츠가 처음 표시된 이후부터 상호작용이 가능해질 때까지, 메인 스레드가 사용자 입력을 차단한 시간의 총합입니다. JavaScript 실행이 사용자 경험에 미치는 영향을 반영합니다.
• Speed Index: 콘텐츠가 얼마나 빠르게 시각적으로 렌더링되는지를 나타내는 지표로, 3.4초 이하일 경우 빠른 페이지로 평가됩니다.
이러한 지표들은 단일 수치로도 의미가 있지만, 반복 측정을 통해 평균값을 도출하고 시간에 따른 추이를 기록해두면 훨씬 더 큰 가치를 가집니다. 예를 들어, 동일한 구조의 페이지에서 리소스 하나를 변경했을 뿐인데 특정 지표가 악화되었다면, 그 자체로 의미 있는 분석 포인트가 될 수 있습니다.
성능을 수치로 말할 수 있다는 것의 의미
실제 테스트에서는 각 측정 지표에 대해 Lighthouse가 반환한 수치를 로그로 남기고, 해당 수치가 기준상 어느 수준에 해당하는지를 함께 해석하는 방식으로 정리했습니다. ‘빠름’, ‘보통’, ‘느림’이라는 해석이 함께 제공되면 개발자나 디자이너와의 커뮤니케이션에서도 훨씬 명확한 논의가 가능해집니다. 예를 들어, “이건 좀 느려요”라는 말보다 “FCP가 2.9초로 기준치를 초과했습니다”라고 말하는 것이 훨씬 설득력 있고 구체적인 피드백이 됩니다.
Lighthouse는 단순히 리포트를 만들어주는 도구를 넘어, 사용자 경험을 수치로 설명할 수 있게 해주는 정량적 분석 도구입니다. 자동화 구조를 갖추고 나면, 코드 변경이 성능에 어떤 영향을 주는지 추적할 수 있고, 릴리즈 전후의 품질 비교 역시 훨씬 명확하게 수행할 수 있습니다.
특히 QA 엔지니어 입장에서는 테스트 결과에 대한 설명력과 객관성을 동시에 높일 수 있다는 점에서 매우 강력한 도구가 될 수 있습니다. 반복 측정을 통해 수치를 확보하고, 기준값과 비교하여 성능의 흐름을 해석하는 능력은 사용자 경험을 개선하고 품질을 설계하는 데 중요한 역할을 하게 됩니다.
성능을 이야기할 때, 이제는 감각이 아닌 수치로 말할 수 있어야 합니다. Lighthouse는 그 수치를 만드는 데 가장 적합한 도구입니다.
