개념
서버가 빨라도 느리게 느껴질 수 있다
레슨 3에서 배운 k6는 서버 응답 시간을 측정했다. 하지만 사용자가 실제로 체감하는 속도는 서버 응답뿐 아니라 브라우저가 그 응답을 받아 화면에 그리는 과정 전체에 좌우된다 — 이미지가 느리게 뜨거나, 레이아웃이 갑자기 움직이거나, 버튼을 눌렀는데 반응이 늦으면, 서버는 빨랐어도 사용자는 "느리다"고 느낀다.
Core Web Vitals — 구글이 정의한 세 지표
1. LCP(Largest Contentful Paint) — 가장 큰 콘텐츠가 그려지는 시간
화면에서 가장 눈에 띄는 요소(보통 큰 이미지나 제목)가 렌더링되기까지 걸리는 시간이다. "이 페이지가 다 로딩됐다"고 사용자가 느끼는 시점에 가장 가깝다.
기준: 2.5초 이내면 좋음, 4초 이상이면 나쁨2. INP(Interaction to Next Paint) — 조작에 반응하는 속도
버튼을 클릭했을 때, 화면이 그 반응을 보여주기까지 걸리는 시간이다. "눌렀는데 아무 반응이 없다"고 느끼는 답답함이 바로 이 지표가 나쁠 때 생긴다.
기준: 200ms 이내면 좋음, 500ms 이상이면 나쁨3. CLS(Cumulative Layout Shift) — 레이아웃이 얼마나 갑자기 움직이는가
페이지가 로딩되는 도중 요소들이 갑자기 밀리거나 튀는 정도를 측정한다.
> 기사를 읽으려고 막 탭을 누르려는 순간, 위에 광고 배너가 갑자기
> 나타나면서 화면이 아래로 밀려 엉뚱한 곳(광고)을 누르게 되는 경험
> — 이게 CLS가 나쁜 전형적인 사례다.왜 이 세 지표를 특별히 강조하는가
성능을 측정할 수 있는 지표는 수십 가지가 있지만, Core Web Vitals는 **"사용자가 실제로 체감하는 것"**에 최대한 가깝게 좁힌 지표라는 점에서 특별하다. 로딩 속도(LCP), 반응성(INP), 시각적 안정성(CLS) 이 세 축은, 사용자가 "이 페이지 쓰기 편하다/불편하다"고 느끼는 경험의 핵심을 구성한다.
측정 방법 — 실험실 데이터 vs 현장 데이터
실험실 데이터(Lab Data): 개발자가 특정 환경에서 직접 측정 (Lighthouse 등)
현장 데이터(Field Data): 실제 사용자들의 실제 기기·네트워크에서 수집된 데이터실험실 데이터는 일관되고 재현 가능하지만, 실제 사용자 환경(느린 네트워크, 오래된 기기)과 다를 수 있다는 한계가 있다. 현장 데이터는 실제 경험을 반영하지만, 통제된 비교(예: 배포 전후 비교)에는 실험실 데이터가 더 적합하다. 두 데이터를 함께 봐야 정확한 그림이 나온다.
QA가 확인할 수 있는 최소한의 것
전문 성능 엔지니어가 아니어도, 브라우저 개발자 도구의 Lighthouse 탭이나 무료 온라인 도구로 특정 페이지의 Core Web Vitals 점수를 확인할 수 있다. "이 페이지 LCP가 5초 넘게 나온다"는 사실 하나만 발견해도, 릴리스 전에 성능 이슈를 미리 짚어낼 수 있다.
실무에서 왜 필요한가
Core Web Vitals는 구글 검색 순위에도 영향을 주는 지표라서, 비즈니스 관점에서도 중요하게 다뤄진다. QA가 "이 페이지, 로딩은 빠른데 이미지 때문에 레이아웃이 계속 튄다"처럼 구체적으로 짚어낼 수 있으면, 단순 기능 검증을 넘어 서비스의 실질적 사용성 개선에 기여할 수 있다.