PageSpeed는 90점인데 서치콘솔 CWV 보고서는 '개선 필요'라고 합니다 — 랩 데이터와 필드 데이터가 다른 이유

PageSpeed Insights에서 성능 점수 90점을 받았는데, 같은 사이트의 서치콘솔 코어 웹 바이탈 보고서에는 "URL 개선 필요"라는 빨간 딱지가 떠 있는 경우가 있다. 담당자 입장에서는 둘 중 뭘 믿어야 할지 헷갈릴 수밖에 없다. 결론부터 말하면 둘은 애초에 다른 걸 재는 도구다. 점수가 어긋나는 게 이상한 게 아니라, 원래 다른 걸 측정하니까 어긋날 수 있는 구조다. 이 글에서는 두 지표가 왜 갈리는지, 그리고 실무에서 어느 쪽을 기준으로 작업 우선순위를 잡아야 하는지 진단 순서로 정리한다.

같은 페이지, 다른 판정 — 무엇이 다른가

PageSpeed Insights 점수는 특정 시점에 구글 서버가 그 페이지를 한 번 로딩해보고 매긴 점수다. 서치콘솔 코어 웹 바이탈 보고서는 반대로 최근 28일 동안 실제 사용자들의 크롬 브라우저에서 수집된 데이터를 모아 만든 판정이다. 전자는 랩(Lab) 데이터, 후자는 필드(Field) 데이터라고 부른다. 같은 페이지라도 "구글 서버가 한 번 열어봤을 때"와 "지난 한 달간 진짜 방문자들이 겪은 경험"은 다를 수밖에 없고, 이 차이가 곧 점수 불일치로 나타난다.

실무에서 자주 나오는 오해가 하나 있다. PSI 점수가 좋으면 CWV 보고서도 곧 따라올 거라고 기대하는 것이다. 방향은 맞지만 시차가 있다. 필드 데이터는 28일 이동평균이라서 오늘 서버를 고쳐도 보고서 색깔이 바로 바뀌지 않는다. 이 시차를 모르고 "고쳤는데 왜 아직도 빨간색이냐"고 재작업을 반복하는 게 가장 흔한 시간 낭비다.

랩 데이터는 시뮬레이션이라는 걸 기억한다

PageSpeed Insights와 라이트하우스는 정해진 네트워크 조건, 정해진 기기 사양을 흉내 내서 딱 한 번 페이지를 로딩한다. 이 환경은 실제 방문자의 회선이나 기기와 다를 수 있다. 예를 들어 사무실 와이파이에서 개발자가 확인하는 화면과, 지방에서 LTE로 접속하는 실제 사용자의 화면은 로딩 조건 자체가 다르다. 랩 데이터는 "이 페이지의 코드와 리소스 구조가 얼마나 무거운가"를 진단하는 데는 유용하지만, "실제로 사용자가 얼마나 기다렸는가"를 보여주지는 않는다.

그래서 랩 데이터는 원인 진단 도구로 쓰는 게 맞다. 어떤 이미지가 LCP를 늦추는지, 어떤 스크립트가 메인 스레드를 막고 있는지는 PSI의 진단 섹션에서 구체적으로 짚어준다. 반면 "우리 사이트가 코어 웹 바이탈을 통과했는가"라는 판정 자체는 랩 데이터가 아니라 필드 데이터 몫이다.

필드 데이터는 28일치 실사용자 평균이다

서치콘솔 코어 웹 바이탈 보고서와 PSI 하단의 "필드 데이터" 섹션은 크롬 사용자 경험 리포트(CrUX)를 기반으로 한다. 실제로 크롬을 쓰는 사용자들이 그 페이지를 방문했을 때 측정된 LCP·INP·CLS 값을 모아 75번째 백분위수로 판정한다. 문제는 이 데이터가 특정 URL 하나가 아니라 트래픽이 충분한 URL에 대해서만 쌓인다는 점이다. 방문자가 적은 페이지는 애초에 개별 데이터가 없어서 "URL 그룹" 단위로 묶여 판정된다.

이 지점에서 실무자들이 자주 놓치는 게 있다. 내가 확인하려는 그 페이지 하나가 문제가 아니라, 같은 템플릿을 쓰는 페이지군 전체가 하나의 그룹으로 묶여 평가된다는 사실이다. 상세페이지 템플릿 하나가 느리면, 그 템플릿을 쓰는 수백 개 URL이 한꺼번에 "개선 필요"로 표시될 수 있다. 반대로 그 그룹 안의 일부 페이지만 고쳐서는 그룹 판정이 바뀌지 않는다.

URL 그룹 판정이 대표 페이지를 끌어내리는 구조

서치콘솔 보고서 화면에서 URL을 클릭하면 "이 URL과 유사한 URL 목록"이 함께 뜬다. 이게 바로 그룹이다. 그룹 판정은 그룹 내 URL 중 상당수가 기준을 통과해야 좋음으로 바뀐다. 그래서 랩 데이터로 특정 페이지 하나를 완벽하게 고쳐도, 같은 템플릿을 쓰는 다른 페이지들이 여전히 느리면 그룹 전체 판정은 그대로 남는다. 반대로 내가 손도 안 댄 페이지가 갑자기 "양호"로 바뀌는 것도, 같은 그룹의 다른 페이지들이 개선된 결과일 수 있다.

이 구조를 모르면 "분명히 고쳤는데 서치콘솔은 왜 아직도 빨간색이냐"는 질문에 답을 못 한다. 답은 간단하다. 그룹 단위로 판정하기 때문에, 그 템플릿을 쓰는 페이지들을 전수 점검해야 그룹 판정이 움직인다. 이미지 용량이나 폰트 로딩처럼 템플릿 공통 요소를 고치는 게 개별 페이지 튜닝보다 훨씬 효율적인 이유가 여기에 있다.

실무에서 확인하는 순서

점수가 어긋날 때는 다음 순서로 좁혀가는 게 가장 빠르다.

첫째, PSI 하단의 필드 데이터 섹션을 먼저 본다. 이 페이지에 대한 실사용자 데이터가 있는지, 아니면 "이 URL에 사용할 수 있는 필드 데이터 없음"으로 나오는지 확인한다. 데이터가 없다면 서치콘솔 판정은 그룹 단위로 이루어진 것이다.

둘째, 서치콘솔에서 해당 URL을 클릭해 유사 URL 그룹을 확인한다. 그룹에 몇 개 URL이 묶여 있는지, 그 URL들이 같은 템플릿·같은 컴포넌트를 쓰는지 본다.

셋째, 그룹 내에서 실제 방문 트래픽이 많은 URL 위주로 랩 데이터를 뽑아 공통 병목을 찾는다. 이미지 압축이 안 됐거나, 외부 스크립트가 렌더링을 막고 있거나, 폰트 로딩 방식이 레이아웃을 흔드는 경우가 대부분이다.

넷째, 공통 병목을 템플릿 레벨에서 고치고, 배포 후 최소 28일은 기다린 뒤 그룹 판정 변화를 본다. 이 기간 동안 랩 데이터 점수만 보고 "다 고쳤다"고 보고하지 않는다.

점검 순서 요약

PSI 점수와 서치콘솔 CWV 보고서가 다르게 나오는 건 오류가 아니라 서로 다른 걸 재는 두 도구의 정상적인 결과다. 랩 데이터는 원인을 짚어주는 진단 도구, 필드 데이터는 실제 사용자 경험을 보여주는 판정 기준이라고 나눠서 쓰면 헷갈릴 일이 줄어든다. 요약하면 ① PSI 필드 데이터 섹션으로 실사용자 데이터 유무 확인 → ② 서치콘솔에서 URL 그룹 범위 확인 → ③ 그룹 공통 병목을 랩 데이터로 진단 → ④ 템플릿 레벨 수정 후 28일 대기 → ⑤ 그룹 판정 재확인. 이 순서를 지키면 "분명히 고쳤는데 왜 안 바뀌냐"는 질문에 스스로 답할 수 있다. LCP·INP·CLS 각 지표를 무엇부터 손대야 하는지는 코어 웹 바이탈 수정 우선순위 정리를 참고하고, 워드프레스 기반 사이트라면 워드프레스 속도 점검 체크리스트부터 확인하는 걸 권한다. 이미지가 LCP 병목인 경우가 많으니 이미지 SEO 우선순위도 함께 보면 도움이 된다.