프론트엔드 개발자에게 '성능'은 오랫동안 하나의 질문이었다. "이 페이지, 빠른가?" 그런데 2025년을 지나면서 이 질문은 두 갈래로 나뉘기 시작했다. 하나는 여전히 사용자 경험의 문제고, 다른 하나는 AI가 이 콘텐츠를 얼마나 신뢰하고 인용할 수 있는가의 문제다. 만드는 것(Core Web Vitals)과 찾히는 것(GEO), 이 두 기준을 동시에 이해하지 않으면 프론트엔드 개발자의 역할은 절반만 수행된 셈이다.
여전히 절반은 실패하고 있다: Core Web Vitals의 현실
dev.to에 공개된 웹 성능 학습 가이드가 인용한 2025 Web Almanac 데이터는 꽤 냉정하다. 모바일 페이지의 48%, 데스크톱 페이지의 56%만이 세 가지 Core Web Vitals 기준을 모두 통과한다. 절반이 넘는 사이트가 사용자에게 느리거나 불안정한 경험을 제공하고 있다는 뜻이다. 그리고 그 실패는 개발자의 눈이 아니라 사용자의 손 위에서 일어난다.
Core Web Vitals는 세 가지 '느낌'을 측정한다. LCP(Largest Contentful Paint)는 "페이지가 나타났나?", INP(Interaction to Next Paint)는 "탭했을 때 반응하나?", CLS(Cumulative Layout Shift)는 "레이아웃이 튀지 않나?"다. 중요한 건 이것이 합성 지표가 아니라 실제 사용자 기반의 인지 지표라는 점이다. Google은 이 수치를 검색 랭킹에 반영하고, 브라우저는 Performance API를 통해 무료로 노출한다.
특히 주목할 지점은 INP다. 2024년 3월 FID를 대체한 이 지표는 현재 Core Web Vitals 중 가장 까다롭다. 43%의 사이트가 200ms 기준을 통과하지 못한다. 원인은 대부분 명확하다. 메인 스레드를 점유하는 긴 태스크, 무거운 React 렌더링, 최적화되지 않은 이벤트 핸들러. 해법도 구체적이다. useTransition으로 비긴급 업데이트를 분리하거나, scheduler.yield()로 브라우저에 페인트 기회를 양보하거나, 무거운 연산을 Web Worker로 오프로드하는 것이다.
측정 전략도 중요하다. Lighthouse는 트렌드 파악용, CrUX는 Google 랭킹의 실제 기준, RUM(Real User Monitoring)은 프로덕션 디버깅의 진실이다. web-vitals 라이브러리로 onLCP, onINP, onCLS를 수집해 analytics 엔드포인트로 보내는 설정은 2분이면 끝난다. 이 데이터 없이 최적화한다는 건 눈 감고 운전하는 것과 같다.
SEO 이후: AI에게 인용되는 콘텐츠의 조건
성능의 두 번째 축은 덜 알려져 있지만 빠르게 현실이 되고 있다. GEO(Generative Engine Optimization)는 Google 크롤러가 아닌 ChatGPT, Claude, Perplexity 같은 LLM이 콘텐츠를 인용할 때의 논리를 이해하고 거기에 맞게 콘텐츠를 설계하는 것이다. dev.to에 공개된 GEO 가이드는 이 차이를 명쾌하게 정리한다. SEO는 발견을 최적화하고, GEO는 추출과 인용을 최적화한다.
LLM은 백링크를 세지 않는다. 키워드 밀도도 분석하지 않는다. 대신 타임스탬프가 붙은 사실, 명확한 저자 정보, 여러 번의 파싱을 견디는 구조화된 데이터를 패턴 매칭한다. "오늘날 빠르게 변화하는 엔터프라이즈 자동화 환경에서 기업들은 전례 없는 도전에 직면해 있습니다" 같은 문장은 LLM에게 무의미하다. 반면 "멀티 에이전트 시스템은 Groq와 Claude 엔드포인트를 라우팅할 때 p99 레이턴시 1.2초로 시간당 12,000건의 요청을 처리한다"는 문장은 인용 가능하다.
프론트엔드 관점에서 GEO는 기술 구현의 문제다. JSON-LD 구조화 데이터에 @type: TechArticle, datePublished, author 속성을 명시하는 것은 LLM 파싱 파이프라인에서 살아남기 위한 마크업이다. JavaScript 렌더링에 의존하는 SPA는 LLM 크롤러가 raw HTML만 가져갈 경우 콘텐츠가 통째로 증발한다. 정적 HTML 생성이 Core Web Vitals의 LCP를 개선하는 것과 동시에 GEO 가시성도 높인다는 사실은 우연이 아니다.
또 하나의 핵심은 URL 안정성이다. GEO 가이드는 URL 단축기, Medium이나 Substack 같은 외부 플랫폼, 2년마다 재구조화되는 기업 블로그를 명시적으로 경계한다. ChatGPT가 6개월 뒤에 내 콘텐츠를 인용할 때 그 URL이 404를 반환한다면, 인용 체인 전체가 끊긴다. Vercel이나 Netlify의 불변 배포 패턴, 영구 URL 설계, 콘텐츠 주소 기반 스토리지는 이제 단순한 배포 전략이 아닌 GEO 인프라다.
두 기준이 만나는 지점
흥미로운 건 두 최적화가 서로 모순되지 않는다는 점이다. 서버사이드 렌더링으로 첫 페인트를 앞당기는 것은 LCP를 개선하면서 동시에 LLM 크롤러에 파싱 가능한 HTML을 제공한다. 이미지에 명확한 alt 텍스트를 달고 제목 구조를 의미론적으로 설계하는 것은 접근성과 CLS를 함께 잡으면서 LLM의 콘텐츠 이해도를 높인다. 폰트를 font-display: swap으로 처리하고 next/font로 서브셋팅하는 것은 LCP를 지키는 동시에 텍스트 콘텐츠를 조기에 노출시킨다.
결국 두 기준의 교집합은 이것이다. "콘텐츠가 최대한 빨리, 최대한 완전하게, 최대한 신뢰 가능한 형태로 도달해야 한다." 사용자에게든, AI에게든.
전망: 성능의 정의가 넓어진다
프론트엔드 개발자의 성능 체크리스트는 조용히 확장되고 있다. Lighthouse 점수와 CrUX 데이터를 읽는 것은 기본이 됐다. 여기에 JSON-LD 구조화 데이터 설계, URL 아키텍처의 내구성, 저자 엔티티 그래프 구축이 추가되고 있다. GEO 측정 도구는 아직 SEO의 Search Console 수준에 미치지 못하지만, AI 검색 엔진에서의 인용 추적은 이미 실무 워크플로우로 자리잡는 중이다.
만드는 것과 찾히는 것. 이 두 기준을 동시에 설계하는 개발자가 앞으로의 웹을 만들어갈 것이다. Core Web Vitals가 "사용자가 이 페이지를 어떻게 느끼는가"를 묻는다면, GEO는 "AI가 이 콘텐츠를 얼마나 신뢰하고 인용하는가"를 묻는다. 두 질문 모두 결국 같은 방향을 가리킨다. 진짜 가치 있는 것을 제대로 만들어라.