FID의 시대는 끝났습니다: INP 최적화가 SEO 순위를 가르는 새로운 열쇠

페이지 로딩은 빠른데, 막상 버튼을 누르면 반응이 느린 사이트를 경험한 적 있으신가요? 이제 구글은 이러한 '사용자의 답답함'을 구체적인 순위 지표로 활용하기 시작했습니다. 기존의 FID(최초 입력 지연)가 INP(다음 페인트에 대한 상호작용)로 완전히 대체되면서, 웹사이트의 사용자 경험(UX) 평가 기준이 한 단계 더 진화했습니다.

TL;DR

• FID의 종말, INP의 부상: 이제 페이지의 '첫 인터랙션'이 아닌 '모든 인터랙션'의 반응 속도가 코어 웹 바이탈의 핵심 지표가 되었습니다.
• INP는 UX이자 AEO 시그널: 느린 반응 속도는 사용자를 이탈시킬 뿐만 아니라, AI 검색엔진이 '신뢰할 수 없는 출처'로 판단하게 만드는 결정적 요인입니다.
• 최적화의 핵심은 '작업 분산': 무거운 서드파티 스크립트나 복잡한 JavaScript 실행을 메인 스레드에서 분리하는 것이 INP 점수 개선의 출발점입니다.

코어 웹 바이탈, 무엇이 완전히 바뀌었나? (FID vs INP)

가장 큰 변화는 단연 INP(Interaction to Next Paint)의 도입입니다. 기존 FID(First Input Delay)는 사용자가 페이지와 '처음' 상호작용할 때의 지연 시간만 측정했습니다. 하지만 실제 사용자는 페이지에 머무르며 수많은 클릭과 입력, 탭을 시도합니다. INP는 이러한 '모든' 상호작용에 대한 페이지의 전반적인 반응성을 측정하는 지표입니다.

실제 웹사이트를 진단해 보면, LCP(가장 큰 콘텐츠 렌더링 시간)나 CLS(누적 레이아웃 이동) 점수는 '좋음'인데 유독 상호작용 관련 지표만 낮은 경우가 많습니다. 이는 INP가 기존 FID보다 훨씬 더 포괄적이고 엄격하게 사용자 경험을 측정하기 때문입니다. 아래 표를 통해 두 지표의 차이점을 명확히 알 수 있습니다.

INP, 왜 단순한 속도 지표가 아닌가?

INP 점수가 낮다는 것은 단순히 '사이트가 느리다'는 의미를 넘어섭니다. 이는 사용자가 원하는 작업을 수행할 때마다 지속적인 불편함을 겪고 있다는 직접적인 증거입니다. 이러한 부정적인 경험은 이탈률 증가와 전환율 하락으로 직결됩니다.

더 중요한 것은 AI 검색 시대의 새로운 관점입니다. 생성형 AI는 사용자 질문에 답하기 위해 웹 콘텐츠를 인용할 때, 해당 정보의 신뢰도뿐만 아니라 '사용자 경험의 품질'까지 고려합니다. 구글이 공식화한 바에 따르면, 빠른 속도(CWV)와 우수한 UX는 AI 검색 노출(AEO, Answer Engine Optimization)에 직접적인 영향을 미칩니다. INP 점수가 낮은 사이트는 AI 크롤러에게 '사용자에게 불편함을 주는 품질 낮은 페이지'라는 신호를 보내고, 결국 AI 답변에서 인용될 기회를 잃게 됩니다.

Google Search Central 문서에 따르면, "INP가 낮다는 것은 페이지가 사용자의 요구에 안정적으로 빠르게 반응하지 못한다는 것을 의미할 수 있습니다." 이는 검색 순위뿐 아니라 AI의 콘텐츠 평가에도 반영될 수 있다는 강력한 암시입니다.

'나쁨' 등급의 주범, 서드파티 스크립트 관리 전략

INP 점수를 저하시키는 가장 흔한 원인은 바로 메인 스레드를 차단하는 무거운 JavaScript, 특히 서드파티 스크립트(예: 분석 도구, 광고, SNS 위젯)입니다. 사용자가 버튼을 클릭해도 메인 스레드가 다른 작업을 처리하느라 바쁘면 화면 반응은 지연될 수밖에 없습니다.

메인 스레드를 막는 범인 찾기

가장 먼저 할 일은 Chrome 개발자 도구나 PageSpeed Insights를 통해 어떤 작업이 메인 스레드를 오래 점유하는지 확인하는 것입니다. '성능(Performance)' 탭에서 긴 작업(Long Tasks)으로 표시되는 부분을 찾아 어떤 스크립트가 원인인지 분석해야 합니다.

작업 분산으로 응답성 확보하기

원인을 찾았다면, 해당 작업을 메인 스레드에서 분리하여 즉각적인 사용자 입력에 방해가 되지 않도록 만들어야 합니다. 예를 들어, setTimeout을 이용해 긴 작업을 작은 단위로 나누거나, 중요하지 않은 스크립트는 Web Worker를 사용해 백그라운드 스레드에서 처리할 수 있습니다.

다음은 긴 작업을 분산시켜 INP를 개선하는 간단한 JavaScript 예시입니다.

// 최적화 전: 긴 작업이 메인 스레드를 500ms 이상 점유
function longRunningTask() {
  for (let i = 0; i < 100000; i++) {
    // 복잡하고 무거운 계산 시뮬레이션
  }
  updateUI();
}

// 최적화 후: setTimeout으로 작업을 분할하여 메인 스레드 양보
function processChunk(start, count) {
  for (let i = start; i < start + count; i++) {
    // 부분 작업 수행
  }
}

function runTasksInChunks() {
  let i = 0;
  const total = 100000;
  const chunkSize = 1000;

  function doChunk() {
    if (i < total) {
      processChunk(i, chunkSize);
      i += chunkSize;
      setTimeout(doChunk, 0); // 다음 청크 실행 전 브라우저에 제어권 양보
    } else {
      updateUI();
    }
  }
  doChunk();
}

💡 잠깐, 우리 사이트도 점검해 볼까요? INP를 포함한 코어 웹 바이탈의 현주소가 궁금하신가요? 어떤 기술적 요소가 우리 사이트의 SEO와 AEO 기회를 막고 있는지 SearchTune OS가 정밀하게 분석해 드립니다. 복잡한 리포트 없이, actionable한 개선 항목을 바로 확인하세요. 👉 무료 SEO·AEO·GEO 진단 받기

INP 개선을 위한 3단계 실천 가이드

INP 최적화는 단번에 끝나는 작업이 아니라, 지속적인 측정과 개선의 과정입니다. 다음 3단계를 꾸준히 반복하는 것이 중요합니다.

1. 측정 (Measure): 먼저 구글 서치 콘솔의 '코어 웹 바이탈' 보고서나 PageSpeed Insights를 통해 현재 우리 사이트의 INP 상태를 정확히 파악해야 합니다. 필드 데이터(실제 사용자 데이터)와 실험실 데이터(시뮬레이션 데이터)를 모두 참고하여 문제 URL 그룹을 식별합니다.

2. 분석 (Analyze): 문제가 되는 페이지를 찾았다면, Chrome 개발자 도구의 'Performance' 탭을 활용해 어떤 요소가 상호작용을 지연시키는지 심층 분석합니다. 'Interactions' 레인에서 긴 INP를 유발하는 특정 상호작용과 그 원인이 되는 긴 작업(Long Tasks)을 찾아냅니다.

3. 최적화 (Optimize): 분석 결과를 바탕으로 실질적인 최적화를 진행합니다. 사용하지 않는 JavaScript/CSS 코드를 제거하고, 서드파티 스크립트 로드를 지연시키거나(lazy-load), 위에서 소개한 것처럼 긴 작업을 작은 단위로 분할하여 메인 스레드의 부담을 줄여주는 것이 핵심입니다.

✅ 실행 체크리스트

INP 최적화를 시작하기 전, 아래 항목들을 먼저 점검하고 실행 계획을 세워보세요.

• 구글 서치 콘솔에서 INP '개선이 필요함' 또는 '나쁨' URL 목록 확인하기
• PageSpeed Insights로 주요 페이지(메인, 상품 상세, 블로그 글) INP 점수 개별 측정하기
• 사용하지 않는 플러그인이나 위젯 비활성화/삭제하기
• Google Analytics, 광고 스크립트 등 필수 서드파티 스크립트 외에 불필요한 스크립트 목록 작성하기
• 이미지 최적화(WebP 포맷 사용, 적절한 사이즈 제공)가 되어 있는지 확인하기
• 개발팀과 함께 긴 작업(Long Tasks)을 유발하는 JavaScript 기능 파악하기
• 중요하지 않은 JavaScript의 async 또는 defer 속성 적용 검토하기

INP는 더 이상 개발자만의 영역이 아닙니다. 기획자, 마케터, 운영자 모두가 INP의 중요성을 이해하고 개선에 동참해야 합니다. 우수한 INP 점수는 더 나은 사용자 경험, 높은 전환율, 그리고 강력한 SEO/AEO 경쟁력으로 이어지는 가장 확실한 투자입니다. SearchTune OS와 함께라면 기술적인 장벽 없이도 우리 사이트의 사용자 경험을 한 단계 끌어올릴 수 있습니다. 지금 바로 첫걸음을 시작해 보세요.

자주 묻는 질문

Q. INP 점수의 구체적인 기준은 무엇이며, '좋음' 등급은 몇 밀리초(ms)인가요?

구글 공식 가이드에 따르면, INP 점수는 세 가지 등급으로 나뉩니다. 200ms 미만은 '좋음', 200ms와 500ms 사이는 '개선이 필요함', 그리고 500ms를 초과하면 '나쁨'으로 평가됩니다. 이 수치는 페이지에서 발생한 모든 상호작용 중 가장 긴 것들을 제외하고 98번째 백분위수에 해당하는 값으로, 대부분의 사용자가 경험하는 반응성을 대표합니다.

Q. INP가 중요해졌다고 해서 LCP나 CLS의 중요도는 낮아진 것인가요?

그렇지 않습니다. LCP(가장 큰 콘텐츠 페인트), CLS(누적 레이아웃 이동), INP(다음 페인트에 대한 상호작용)는 모두 코어 웹 바이탈을 구성하는 3대 핵심 지표입니다. LCP는 로딩 속도, CLS는 시각적 안정성, INP는 상호작용 반응성을 담당하며, 세 가지 모두 사용자 경험을 평가하는 데 필수적입니다. 다만 INP가 기존 FID를 대체하는 새로운 지표인 만큼, 현재 많은 웹사이트에서 최적화가 시급한 과제로 떠오른 것입니다.

Q. INP 최적화를 위해 가장 먼저 확인해야 할 코드는 무엇인가요?

대부분의 경우, 무거운 서드파티(third-party) JavaScript 코드가 주된 원인입니다. 특히 실시간 데이터 분석을 위한 구글 애널리틱스(GA4), 페이스북 픽셀 같은 마케팅 추적 스크립트, A/B 테스트 도구, 광고 관련 스크립트 등이 메인 스레드를 점유하여 INP를 저하시키는 경우가 많습니다. 또한, 복잡한 CSS 애니메이션이나 대규모 DOM 변경을 유발하는 자체 개발 스크립트도 주요 점검 대상입니다.

Q. INP가 AEO(답변 엔진 최적화)에 미치는 구체적인 영향은 무엇인가요?

AI 답변 엔진은 신뢰할 수 있고 유용한 정보를 제공하는 동시에, 사용자에게 쾌적한 경험을 주는 출처를 선호합니다. INP 점수가 나쁜 페이지는 AI에게 '사용자가 정보를 소비하는 과정에 불편함을 주는 페이지'라는 부정적 신호를 보냅니다. 이는 AI가 해당 페이지의 콘텐츠를 답변으로 인용하거나 추천할 확률을 낮추는 요인으로 작용할 수 있습니다. 즉, 우수한 INP는 양질의 콘텐츠와 더불어 AEO의 기본 전제 조건이 됩니다.

Q. 모든 JavaScript에 Web Worker를 적용하는 것이 INP 개선에 항상 효과적인가요?

아닙니다. Web Worker는 메인 스레드와 분리된 별도의 스레드에서 스크립트를 실행해 유용하지만, 모든 상황에 적합한 것은 아닙니다. Web Worker 생성 및 통신에는 일정한 오버헤드(부하)가 발생하며, DOM에 직접 접근할 수 없는 제약이 있습니다. 따라서 사용자 인터페이스(UI)를 직접 조작하지 않는 장시간 실행 작업(예: 대용량 데이터 처리, 복잡한 계산)에 선택적으로 사용하는 것이 가장 효과적입니다. 무분별한 사용은 오히려 성능을 저하시킬 수 있습니다.