AI 에이전트 Core Web Vitals: 필드 데이터가 모든 것을 바꾸는 이유

AI 코딩 에이전트는 이제 MCP 서버를 통해 웹 성능 데이터에 연결할 수 있습니다. 에이전트는 자동화된 루프 내에서 감사를 실행하고, 병목 현상을 추적하며, 코드 수정안을 생성합니다. 이 작업을 위해 Chrome DevTools, Lighthouse, Real User Monitoring의 세 가지 MCP 서버 유형이 존재합니다. 데이터 소스는 해당 수정 사항이 사용자에게 실질적인 도움을 줄지, 아니면 Google이 무시하는 합성 점수(synthetic score)만 개선할지를 결정합니다.

최근 검토: 2026년 3월, Arjen Karel

현재 AI 에이전트가 Core Web Vitals로 할 수 있는 작업

Model Context Protocol (MCP)은 AI 도구가 외부 데이터 소스에 연결하는 방식을 표준화합니다. Core Web Vitals 작업에는 세 가지 유형의 서버가 중요합니다.

Chrome DevTools MCP는 에이전트에게 Chrome의 디버깅 표면에 대한 직접적인 제어 권한을 부여합니다. Google은 2025년 말에 이를 공개 프리뷰로 출시했습니다. 이 서버는 성능 추적을 실행하고, LCP 단계별 분석을 수행하며, 렌더링 차단 리소스를 식별하고, 원시 추적 데이터를 에이전트가 구문 분석할 수 있도록 간결한 요약본으로 압축합니다.

Lighthouse MCP 서버는 에이전트가 프로그래밍 방식으로 전체 감사를 실행할 수 있게 해줍니다. GitHub에는 여러 구현체가 존재합니다. 수많은 페이지에 걸쳐 대량 감사를 수행할 때 유용합니다. 결과는 랩(lab) 데이터입니다. 즉, 시뮬레이션된 기기와 네트워크 연결 환경에서 수행된 합성 테스트 결과입니다.

RUM MCP 서버는 실제 방문자의 Real User Monitoring 데이터에 에이전트를 연결합니다. CoreDash는 현재 MCP 서버가 내장된 유일한 상업용 RUM 플랫폼으로, MCP 호환 코딩 에이전트에게 실시간 필드 데이터를 노출합니다.

이 세 가지 서버가 공통적으로 지원하는 워크플로우는 측정-수정-재측정의 반복 루프입니다. 에이전트는 병목 현상을 식별하고, 코드 수정안을 생성 및 적용한 후, 다시 테스트합니다. 에이전트가 사용하는 데이터의 유형에 따라 해당 수정 사항이 실제 사용자에게 도움이 될지가 결정됩니다.

Lighthouse만 사용하는 에이전트의 문제점

Google은 검색 순위에 Lighthouse 점수를 사용하지 않습니다. Google은 실제 Chrome 사용자의 28일 기준 CrUX 필드 데이터를 사용합니다. Lighthouse를 실행하고, 코드를 변경한 뒤, 다시 Lighthouse를 실행하는 에이전트는 검색 가시성 확보에 전혀 의미 없는 루프를 완료한 것일 뿐입니다.

랩 데이터와 필드 데이터 간의 격차는 실재합니다. 2025 Web Almanac에 따르면, 모바일 웹사이트의 52%가 필드 데이터 기준으로 최소 하나 이상의 Core Web Vitals 기준을 통과하지 못합니다. 이들 사이트 중 상당수는 Lighthouse에서 양호한 점수를 받습니다.

INP는 가장 큰 사각지대입니다. INP는 전체 사용자 세션 동안 발생하는 실제 클릭, 탭, 키보드 입력에 사이트가 얼마나 빠르게 반응하는지 측정합니다. 랩 환경에서는 이를 대체할 수 있는 지표가 없습니다. Lighthouse는 Total Blocking Time(TBT)을 대리 지표로 사용하지만, TBT는 페이지 로드 중의 스레드 차단만을 측정합니다. 반면 INP는 예측할 수 없는 순간에 발생하는 실제 상호작용의 응답 시간을 측정합니다. 에이전트가 TBT를 "수정"했다고 해서 실제 INP가 개선되었다는 보장은 없습니다.

에이전트가 작성한 33,596개의 풀 리퀘스트 연구(Alam 외, 2026년 1월)에 따르면, AI가 생성한 수정 PR의 전체 병합률은 65%인 것으로 나타났습니다. 3분의 1 이상은 인간 리뷰어에 의해 거부됩니다. 성능 관련 수정에는 랩 데이터만으로는 제공할 수 없는 컨텍스트가 필요합니다.

랩 데이터에서는 얻을 수 없는 필드 데이터만의 이점

Real User Monitoring은 모든 기기를 사용하는 모든 방문자로부터 성능 데이터를 수집합니다. 에이전트가 Lighthouse 대신 RUM에 연결하면 세 가지가 바뀝니다.

먼저 실제 고객에게 어떤 페이지가 진정으로 느린지 파악할 수 있습니다. 4G 환경에서 시뮬레이션된 Moto G Power 기기를 사용한 합성 테스트에서 어떤 페이지의 점수가 낮게 나왔는지가 중요한 것이 아닙니다. 여러분의 사용자들은 독일에서 광랜을 사용하는 iPhone 사용자일 수도 있고, 혼잡한 모바일 네트워크 환경인 인도네시아의 보급형 안드로이드 사용자일 수도 있습니다. 필드 데이터는 그들이 실제로 경험하는 바를 반영합니다.

CoreDash는 에이전트에게 요소 수준의 원인 분석(attribution)을 제공합니다. 느린 LCP를 유발한 특정 요소, 느린 INP의 원인이 되는 JavaScript 파일(Long Animation Frames 데이터를 통해 파악), 그리고 이동이 발생한 DOM 노드 등을 정확히 짚어냅니다. 에이전트는 추측 없이 지표에서부터 정확한 코드까지 추적합니다.

마지막으로 수정 사항이 효과가 있었는지 검증할 수 있습니다. 변경 사항을 배포한 후 에이전트는 필드 데이터를 쿼리하여 실제 사용자가 개선을 경험했는지 확인합니다. 이 단계는 대부분의 AI 워크플로우에서 완전히 생략되지만, 검색 순위에 영향을 미치는 유일하게 중요한 단계입니다.

완전한 워크플로우는 다음과 같습니다: 필드 데이터에서 문제를 찾고, Chrome에서 원인을 추적하며, 코드를 수정하고, 다시 필드 데이터로 검증합니다. 조사는 에이전트가 수행하며, 배포할 내용은 여러분이 결정합니다.

다음 단계

CWV Superpowers는 이 전체 워크플로우를 자동화하는 무료 Claude Code 스킬입니다. 설정에는 단 2분이 소요됩니다. 이 스킬은 CoreDash 필드 데이터에 연결하여 가장 심각한 병목 현상을 식별하고, Chrome에서 근본 원인을 추적하여 해결책을 생성합니다.

특정 지표의 경우: LCP 진단 가이드는 에이전트가 4단계를 거쳐 느린 Largest Contentful Paint를 정확한 코드 변경까지 추적하는 과정을 설명합니다. INP 진단 가이드는 랩 환경에서 시뮬레이션할 수 없기 때문에 AI 에이전트가 가장 어려워하는 지표를 다룹니다.

진단의 기본 개념은 비례적 추론(proportional reasoning)입니다. 에이전트는 절대적인 임계값을 초과하는 단계가 아니라 전체 시간 중 가장 큰 비중을 차지하는 단계를 병목으로 식별합니다. 이 방식은 어떤 수정 사항이 실질적인 성과를 내는지 판가름하는 기준을 바꿉니다.